[c-nsp] Internet in VRF

[Jason Lixfeld]

> 
> On Apr 30, 2015, at 12:41 PM, Mike <mike-cisconsplist at tiedyenetworks.com> wrote:
> 
> I think I want to have my default routing table carry mostly loopbacks and direct interface connected routes, while I want to stuff everything else into VRF's. Those other VRF's are likely to be Internet (full tables), Subscribers (all the /32's for PPPoE subscribers), and the odd vrf for any mpls vpn customers.  The challenge is that - I think - I would want to only leak a default route into any other non-Internet VRF that requires shared service access to it, which should keep the table sizes down. My question is, does this sound reasonable? Is there any reason I wouldn't want to set things up this way?

I’ve been doing this for years on ME3600s, 7600s, A9Ks and A1Ks.  Except, I don’t separate my Internet customers into a different VRF than the Internet VRF.  Internet and all Internet customers are in the same VRF.  VOIP is in another VRF, IPTV in another, Management in another, etc.  Putting sub-sets of customers who require the same services inside different VRFs and having to leak between the two is more complexity than we need.  We don’t sell L3VPNs, so leaking between VRFs is never something I’ve had to worry much about.

I do have one application where I need to leak between two VRFs on an A9K.  That is a royal pain in the ass which requires a loopback cable because IOS and XR by default inherit the next hop of the route when it’s leaked, instead of providing a knob to adjust this behaviour.

Overall, I love the design.  It shrinks failure domains very nicely.  If someone fat fingers something in a VRF, it’s limited to that VRF and the global table is left completely intact.  Alternatively, with one huge routing table, one fat enough finger and you’re in quite the pickle.  Since everything is in a VRF, the global table is pretty much completely hands off except for device M-A-C events, but those are far less frequent than other config M-A-C events which happen inside these VRFs.  A stable global table means stable MPLS underpinnings.  Stable MPLS underpinnings mean stable EoMPLS/VPLS/NG-MVPN.