I think it’s a popular enough option these days in carrier networks that the larger vendors do plan for it somewhat at this point. In the beginning there were issues with how labels are allocated (per-VRF or per-prefix) which leads to lots of potential issues. The ability for the box to look deep enough into the packet as well to get good entropy for load balancing. If you are doing something like seamless MPLS and carrying 3+ labels on a packet some gear may have issues. You also may run into issues with not being able to impose enough labels for something like FRR/backup tunnels on an ingress node. Like I said though, there are some large carriers doing this today so vendors have solved most of those issues by now.
I wouldn’t get crazy with route leaking, if you want to carry Internet in a VRF, just carry Internet in a VRF and not separate things into a bunch of different ones. It always comes down to what problem are you really trying to solve. Phil -----Original Message----- From: Mike Date: Friday, May 1, 2015 at 16:43 To: "[email protected]" Subject: Re: [c-nsp] Internet in VRF >===================================================== >On 05/01/2015 12:00 PM, Mark Tinka wrote: >> >> On 30/Apr/15 18:41, Mike wrote: >>> Hi, >>> >>> I'd like to ask for the collective opinion on routing in service >>> provider network serving broadband subscribers: >>> >>> I have an ASR1k and will be terminating PPPoE broadband >>> subscribers here. I'll also be terminating my primay internet feed >>> (BGP) here, and I the future I will have 3 providers and will be >>> multihomed. I also will have some MPLS vpns for certain customers. >>> >>> 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 like simple. >> >> Internet routes in a VRF is not simple - too dependent on hardware and >> software capabilities, without having to worry about what the vendors do >> with the hardware or the software in future revisions. >> >> I know a few ISP's that went this router back in 2003, when MPLS was >> all-the-rage; they're finding that tearing down this wall of complexity >> is the way forward, but alas, mighty painful. >> > >What exactly are the downsides? I don't have 100's of routers and >transits and peerings and such, but if I'm going to be painting myself >into a corner I'd like to know about it before it do it. > >Thank you. > >_______________________________________________ >cisco-nsp mailing list [email protected] >https://puck.nether.net/mailman/listinfo/cisco-nsp >archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
