[c-nsp] Inserting a default route into a MPLS/VPN pointing out of the VRF

[Brett Frankenberger]

On Mon, Oct 19, 2009 at 04:49:40PM -0500, Justin Shore wrote:
>
> I've come across route-leaking examples but they all require me to point  
> traffic to an outward-facing interface.  Ie, I can't just point the  
> default route to a specific upstream-facing interface.  Is there another  
> way?  I can't see a solution with importing routes at the route-target  
> level.  Can I point it to a loopback outside of the VRF?
>
>  [ ... ]
>
> This is probably a simple process but I haven't had to do it before  
> without the FWSM which made it trivially easy.  What simple solution  
> have I overlooked and will kick myself for missing later?

Cisco has no support for:
   ip route vrf vrfX x.x.x.x/x next-hop next-hop vrfY
where the traffic in vrfX matching that route would be sent over into vrfY
(and then forwarded according to vryY's forwarding table).  (Some other
vendors can do that.)  (In your case, you want "vrfY" to be "global",
but that's not doable either.)

The only clean way is to connect via an interface.  For example,
connect a cable from GIa/b to GIc/d and then configure:
   int GIa/b
    ip address x.x.x.1/30
   int GIc/d
    ip vrf forwarding vrfX
    ip address x.x.x.2/30
   ip route vrf vrfX 0.0.0.0/0 GIc/d x.x.x.1
(obviosuly I'm not using exact IOS commands above, but you get the
idea.)
    
On some platforms, this can be done with tunnels instead of physical
interfaces to avoid using two physical ports and dealing with the risk 
that those ports might fail:
    int lo1
     ip address z.z.z.10/32
    int lo2
     ip address x.x.x.20/32
    int tun1
     ip address x.x.x.1/30
     tunnel source lo1
     tunnel destination x.x.x.20
    int tun2
     ip vrf forwarding vrfX
     ip address x.x.x.2/30
     tunnel source lo2
     tunnel destination x.x.x.20
    ip route vrf vrfX 0.0.0.0/0 tun2 
How well this works depends on how tunnels are implemented on the
platform you're using.  It works fine on software-based routers. 
ASR1000s worked OK in my testing. Never tried 6500/7600s.

Note that the suggestion to leak default from your global table into
the VRF potentially fails on two accounts.  First, you might or might
not have a default in your global table.  Second, if you do, leaking
that would direct all internet traffic to follow the default route,
and, assuming you have default plus a lot of more other routes in your
global table, you wouldn't want traffic covered by a more-specific in
the global table to follow the default if it originated in vrfX.  That
is, with a global table of:
     100.0.0.0/8    -> A
     0.0.0.0/0      -> B
if you import only 0.0.0.0/0 into a vrf, then all traffic matching the
default in that VRF will be sent to B, even traffic traffic to
100.0.0.0/8.

     -- Brett