Route leaking between VRFs and next-hops

Unanswered Question
Jul 1st, 2007

I'm trying to leak some static routes out of one VRF into several others. This is mainly to help get around issues with FWSM shared interfaces and load-balancing the firewalled traffic. Anyway, to try and ease the administration of the static routes I would like to export them from one VRF to a couple of others.

Taking just one destination for now...

The source VRF is connected to one interface of the firewall (there are many, but in this case irrelevent), and the destination VRF is on another. The route I would like to propagate is a recursive static route, with the next hop known by both VRFs to be beyond the firewall.

When the route appears in the destination VRF routing table the next hop is shown as out of the source VRF, and in fact the traffic then appears to "jump" VRFs and exit from the source VRF - not really what I want to happen at all!

I thought of tackling this alternatively using policy based routing (but VRFs don't support this) and "eBGP" between the VRFs (can't work as the router-is is the same and it's just plain contorted).

I tried using the import-map to rewrite the next-hop but that didn't seem to work either.

Any suggestions welcome

ip vrf SOURCE

rd 172.21.17.193:1

route-target export 172.21.17.193:1

route-target import 172.21.17.193:1

!

ip vrf DESTINATION

rd 172.21.17.193:2

import map DESTINATION_IMPORT_MAP

route-target export 172.21.17.193:2

route-target import 172.21.17.193:2

route-target import 172.21.17.193:1

!

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
swaroop.potdar Sun, 07/01/2007 - 15:49

Although you have given a elaborate explanation of what is happening, it would be difficult to exactly visualize the problem without a diagram and a diagram would help explain the path of data flow and what and where you are trying to manipulate.

HTH-Cheers,

Swaroop

jonathanstevens Mon, 07/02/2007 - 07:30

Ok ... ASCII diagram attempt...

VFW = context within FWSM (failover pair with two groups one homed in each chassis)

VRF = VRF within chassis

MSFC = Default routing table within 6500

MSFC MSFC

| |

-------

|

VFW

|

VRF1 | VRF2

| \ | / |

| -| - |

| / | \ |

VFW--VRF3--VFW

| |

DEST1 DEST2

Each VRF connects to both frontend VFWs and provide the logic to send traffic to either DEST1s or DEST2s.

I wanted to add a static route to one VRF (say VRF3) and then propogate it to the other VRFs using export import. My plan was to use a recursive route to two imaginary destinations. Each VRF would have two static routes e.g.

ip route vrf VRF1 10.69.0.1 255.255.255.255 VWF1

ip route vrf VRF1 10.69.0.2 255.255.255.255 VWF1

ip route vrf VRF2 10.69.0.1 255.255.255.255 VWF1

ip route vrf VRF2 10.69.0.2 255.255.255.255 VWF1

ip route vrf VRF3 10.69.0.1 255.255.255.255 VWF1

ip route vrf VRF3 10.69.0.2 255.255.255.255 VWF1

To add a destination via either VFW I would then add

ip route vrf VRW3 10.129.4.0 255.255.252.0 10.69.0.1 or .2

then export those routes and import them into the other VRFs.

I do not want to leak traffic between the VRFs just the next-hop routing information.

I'll post this to check the diagram...

jonathanstevens Mon, 07/02/2007 - 07:33

OK great - NetPro stole the spaces, so try again with .s

.MSFC...MSFC

...|.....|

...-------

......|

.....VFW

......|

VRF1..|...VRF2

.|..\.|./...|

.|...-|-....|

.|../.|..\..|

VFW--VRF3--VFW

.|..........|

DEST1.... DEST2

Hope that makes sense better.

jonathanstevens Mon, 07/02/2007 - 07:37

Might be ok if you copy and paste into notepad or context and use a Courier font.

Anyway, I'm beginning to think that I might have to rewrite the BGP RD community to make the route "of" the destination VRF... is that allowed in an import-map?

jonathanstevens Mon, 07/02/2007 - 07:52

Here is a very basic config example and also a show that demonstrates what I am struggling with

Router#sh run (snipped)

ip vrf VRF1

rd 1.1.1.1:1

route-target export 1.1.1.1:1

route-target import 1.1.1.1:1

!

ip vrf VRF2

rd 2.2.2.2:2

route-target export 2.2.2.2:2

route-target import 2.2.2.2:2

route-target import 1.1.1.1:1

!

!

interface Loopback0

ip address 10.10.10.1 255.255.255.0

!

interface Loopback1

ip vrf forwarding VRF1

ip address 1.1.1.1 255.255.255.0

!

interface Loopback2

ip vrf forwarding VRF2

ip address 2.2.2.2 255.255.255.0

!

!

router bgp 65001

no bgp default ipv4-unicast

bgp log-neighbor-changes

!

address-family ipv4 vrf VRF1

redistribute static metric 100 route-map REDIST_MAP

no auto-summary

no synchronization

exit-address-family

!

ip route vrf VRF1 10.69.0.1 255.255.255.255 1.1.1.10

ip route vrf VRF1 10.128.4.0 255.255.252.0 10.69.0.1

ip route vrf VRF2 10.69.0.1 255.255.255.255 2.2.2.10

!

ip prefix-list REDIST_LIST seq 5 permit 10.128.0.0/16 le 22

!

route-map REDIST_MAP permit 10

match ip address prefix-list REDIST_LIST

!

Router#sh ip bgp vpnv4 all

BGP table version is 4, local router ID is 10.10.10.1

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 1.1.1.1:1 (default for vrf VRF1)

*> 10.128.4.0/22 10.69.0.1 100 32768 ?

Route Distinguisher: 2.2.2.2:2 (default for vrf VRF2)

*> 10.128.4.0/22 10.69.0.1 100 32768 ?

Router#show ip route vrf VRF1

Routing Table: VRF1

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

1.0.0.0/24 is subnetted, 1 subnets

C 1.1.1.0 is directly connected, Loopback1

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

S 10.69.0.1/32 [1/0] via 1.1.1.10

S 10.128.4.0/22 [1/0] via 10.69.0.1

Router#show ip route vrf VRF2

Routing Table: VRF2

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

2.0.0.0/24 is subnetted, 1 subnets

C 2.2.2.0 is directly connected, Loopback2

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

S 10.69.0.1/32 [1/0] via 2.2.2.10

B 10.128.4.0/22 [20/100] via 10.69.0.1 (VRF1), 00:02:23

Router#

It is that last route in the VRF2 that points out of VRF1 that I have the problem with.

I want the route in VRF2, but I do not want the traffic forwarded out of VRF1.

swaroop.potdar Mon, 07/02/2007 - 21:11

Well, if I understand correctly from you explanation you want to propogate a destination route to all VRF's on the FWSM.

I believe you are trying to automate or reduce provisiong overheads.

But I believe even if the method of importing routes form the adjacent VRF and modfying the next-hop outside the MPLS domain worked, which it doesnt, you would still end up typing more config lines than simply configuring the static routes in each VRF pointing to the external destination.

Just a thought, why dont you simply run an IGP for each FW context advertise this destination into the IGP and re-advertise this into the VRF at the FWSM VRF head end.

I personally feel if you have a big network you may look at provisioning tools like ISC as well if it helps.

HTH-Cheers,

Swaroop

jonathanstevens Tue, 07/03/2007 - 02:39

Yes you're pretty much right there. It is about putting the work in on the initial build to help reduce the overhead as the service expands (regular addition of the static routes). Rather unfortunately the FWSM is running in multiple context mode so it cannot run any routing protocols (save a weird BGP Stub feature that I cannot see how to use resiliently - could you peer with an HSRP address???? - yuk).

At present each route addition would need to be entered four times on each of the 6500s, plus another in one of the contexts (all in addition to the original configuration of the destination on one of the outer contexts) - and that's just for the local site. Obviously between sites I have no problem as I have a host of options there.

It's one of those where a good subnetting design will really help - but I'm also rather tied by the history of the environment.

To be honest, I know that this is not really what VRFs are for - but they're there and they solve problems - well, nearly...

I found a document entitled

BGP Support for IP Prefix Import from Global

Table into a VRF Table

Do you think this might be a method? I haven't got a router with the feature available to test on right now, but I guess it could also have the same issue as the original solution - ie traffic leaking as opposed to just route leaking.

Actions

This Discussion