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

Andriy Bilous andriy.bilous at gmail.com
Wed Dec 12 09:49:34 EST 2012


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
 tunnel source Loopback1000
 tunnel destination 4.4.4.4
!
interface Tunnel2
 ip vrf forwarding resi
 ip address 5.5.5.2 255.255.255.0
 tunnel source Loopback1001
 tunnel destination 3.3.3.3

router rip
 version 2
 passive-interface FastEthernet0/1
 no auto-summary
 !
 address-family ipv4 vrf resi
  redistribute connected
  network 5.0.0.0
  no auto-summary
 exit-address-family
 !
 address-family ipv4 vrf inet
  redistribute static route-map DEFAULT
  network 5.0.0.0
  no auto-summary
 exit-address-family

R3#sh ip route vrf inet 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0 (connected), candidate default
path
  Redistributing via rip
  Advertised by bgp 65400
                rip route-map DEFAULT
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1

R3#sh ip route vrf resi 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "rip", distance 120, metric 1, candidate default path
  Redistributing via rip
  Last update from 5.5.5.1 on Tunnel2, 00:00:19 ago
  Routing Descriptor Blocks:
  * 5.5.5.1, from 5.5.5.1, 00:00:19 ago, via Tunnel2
      Route metric is 1, traffic share count is 1

In your setup you should also take care of the path back into vrf resi.
Works in GNS3, but might as well fail on the hardware forwarding platform.


On Wed, Dec 12, 2012 at 1:30 PM, Jason Lixfeld <jason at lixfeld.ca> wrote:

>
> On 2012-12-12, at 4:36 AM, Adam Vitkovsky <adam.vitkovsky at swan.sk> wrote:
>
> >> 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.
>
> This is already the case.  I guess that wasn't clear from my original post?
>
> > Than create a static default route in that vrf resi and for the next hop,
> > use the interface that points to internet and IP of the eBGP neighbor
> (you
> > can use tracking next-hop and floating static backup default route).
> > Than advertise the static via MP-BGP to all other PEs with vrf resi.
>
> 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.
>
> > There should be a mechanism to accomplish extranet vpn on destination
> PEs as
> > well -but I'm not sure how would I accomplish that.
> > We should be looking for some articles regarding extranet vrfs
> > I'd love to hear any ideas.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list