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

[Justin Shore]

Brett Frankenberger wrote:
> 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.)

I cracked open my MPLS books last night and found a similar solution 
with an IP next-hop in the MPLS & VPN Arch book.  It set the next-hop to 
be an IP in the global VRF by using the 'global' keyword.

ip default vrf VRFx 0.0.0.0  0.0.0.0 1.2.3.4 global

It has the same problems as the other solution I found for setting the 
next-hop to be an exit interface.  I want the Ps to make a routing 
decision to determine the exit path for the packet, not hardcode it to 
go one way or another (and possibly have a iBGP-meshed BR1 decide that 
the better exit point would be another BR and route that back to the 
core P to get to BR2.  This is why I was wondering if the target 
interface or IP could be a loopback on the Ps.  I really need to lab 
these ideas.

> 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.)

I thought about that and I could do that.  It's an added expense though.

> 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.

This is a thought.  I haven't tried it on 7600s either but it's worth 
trying to see if it would work.

> 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.

I originate a default in my IGP on each BR currently.  I'm thinking 
about moving that into iBGP though.  I'll originate a default on the Ps 
in the VRF with MP-iBGP.  This touches on the problem I outlined above 
talking about the Ps making the decision on exit path.  My Ps are part 
of the iBGP mesh with full tables from the BRs.  In theory they should 
make the same routing decision for a given packet that a BR will do when 
it receives that same packet milliseconds later.

I'm going to try the importing of the default in the VRF statement.  I 
think that will work but I'll find out for sure with my testing.  If it 
doesn't then I may have to try the tunneling solution.  I may have to 
settle for inefficient routing for a few months until the ASR comes in 
and then do tunnels on it.  Either way I think I'm on the right track.

Thanks for the insight
  Justin