[c-nsp] VRF route leaking

[Mike]

On 05/06/2015 06:53 AM, Nathan Ward wrote:
> On 6 May 2015 at 23:16:29, Mike (mike-cisconsplist at tiedyenetworks.com(mailto:mike-cisconsplist at tiedyenetworks.com)) wrote:
>> In my configuration,I have an ASR1000 and I am intending to do it all on
>> one box - terminate pppoe/ipoe subscribers, some mpls vpns, and bgp with
>> 2 transits. I don't know how to gauge whether I 'care' about ram usage,
>> but being efficient certainly can't hurt. I am just trying to wrap my
>> head around the idea that if I want it all on one box, I have to import
>> the entire internet table into every vrf that wants to route packets to
>> / from the internet. That just seems silly. I know having a second box
>> only for internet would greatly simplify things but thats not were I'm
>> at today.
> Sure, understandable. Yeah if you import the entire table it eats a bit of RAM each time. Depending how many times you want to do it, it may/may not be a problem.
>
> Why do you want more than one VRF? Do you have some cases where customers need some sort of access to private resources or something? Is that just a few customers that need that private access, or is that all customers?

Not ALL of my subscribers will terminate on this single ASR, I have 
another router (7201) that terminates another group of users, therefore, 
they need to exchange routes with each other. PPPoE customers have /32 
netmasks mostly, with relatively fewer having /29's or smaller, and they 
tend come and go with some regularity, I just felt that it would be 
efficient to keep them and the routing updates constrained to a separate 
table.

> Worth noting, even if you do decide to do a single VRF, keep the routes in the VRF and not in global - makes it much easier to grow to a multi-box L3VPN solution later, and do multiple-VRF stuff if you find you have some requirement for it later on.

I have decided already to keep the global table clear of everything 
except loopbacks and directly connected interface routes. No reason for 
my layer 3 switches to know about the internet or thousands of 
individual pppoe subscriber routes since all I'll be asking them to do 
is support mpls.

> Yep you can thing of a VASI like that, or maybe like an internal GRE tunnel or something. Anyway you get the idea.
>
> It seems like a pretty dirty solution, but it would work. I’ve found that Cisco tend to recommend against VASI unless it’s really needed.

Is there a solid reason why not do it? I mean, performance? I likely 
won't have huge numbers of these.

> Given you only have the one router, you don’t need to be advertising individual subscriber prefixes, just their supernets, so you could get away with static routes over the VASIs.

More than 1 router will be involved, but the basic idea is the same.

>
>
> Perhaps you can put the majority of your subscribers who just need Internet access directly in to your Internet VRF, or perhaps in to a Subscriber VRF that imports all Internet routes, and then for customers that have specific private connectivity requirements you do the VASIs and VRFs for them, with the “outside” end in the same VRF as your other subscribers.
>
> Giving private clouds access to Internet over VASI interfaces is a pretty common solution, because you can do NAT and whatever else there so the customer runs private addressing within their cloud. Putting lots of subscriber traffic over a VASI just to get the packets in to the right VRF is pretty uncommon.

I did think about putting the subscribers in the internet vrf but for 
reasons of churn and added table complexity I decided against it. Any 
customer that has mpls service would more than likely have internet with 
me as well and at that level, I can arrange to provide them with both 
services over the same connection or provide a seperate connection for 
internet only.

Thank you.