Re: [c-nsp] Sanely leaking a locally sourced default route from one VRF into another

2012-12-12 Thread Adam Vitkovsky
I've leaked the default from inet into resi using a combination of 'import route-target' statements and 'import map' statements on the PEs as required. I believe the easiest solution is as follows. On the RR PE that originates the default route configure vrf resi. Than create a static default

Re: [c-nsp] Sanely leaking a locally sourced default route from one VRF into another

2012-12-12 Thread Andriy Bilous
Apparently you can short-circuit VRFs with a GRE tunnel and run RIP (for example) through it. =) interface Loopback1000 ip address 3.3.3.3 255.255.255.255 ! interface Loopback1001 ip address 4.4.4.4 255.255.255.255 ! interface Tunnel1 ip vrf forwarding inet ip address 5.5.5.1 255.255.255.0

Re: [c-nsp] Sanely leaking a locally sourced default route from one VRF into another

2012-12-12 Thread Adam Vitkovsky
Except I have 4 upstream connections on that router and statically routing to any one of them is a potential risk for blackholing traffic if said upstream goes down. Right, though you should be able to use next hop availability tracking to take care of the blackholing issue. Unfortunately I

[c-nsp] Sanely leaking a locally sourced default route from one VRF into another

2012-12-11 Thread Jason Lixfeld
Hi folks, I have an edge-facing PE router that has a full table inside vrf inet. That edge PE speaks MP-BGP as an RR to a few other PEs that don't have the capacity to handle a full table but need access to the world via vrf inet. Those PEs receive internal+default from this edge PE to

Re: [c-nsp] Sanely leaking a locally sourced default route from one VRF into another

2012-12-11 Thread Saku Ytti
On (2012-12-11 11:17 -0500), Jason Lixfeld wrote: The issue now is that I have vrf resi that I need to anchor to this edge-facing PE router and vrf resi needs access to the world via vrf inet too. The other devices inside vrf resi could be considered managed CEs for all intents and