> 
> On Apr 30, 2015, at 12:41 PM, Mike <[email protected]> 
> 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.
_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to