[c-nsp] VRF route leaking

[Nathan Ward]

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?

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.

> Someone in this thread mentioned the cisco VASI interfaces and this
> seems like a solution. It appears, and some limited testing confirms,
> that it acts like an internal bridge with one end in one vrf and one end
> in another. This model would seem to be a lot more manageable; I put one
> end in the Internet table, and the other in my subscriber table. Then a
> default route in the subscriber table points to the VASI interface. Then
> I can populate the Internet table by importing the subscriber table or,
> more likely, advertising static summary routes for my subscriber address
> space that points across the VASI interface. I'm wondering why this
> wouldnt be the right solution.

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.  

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.


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.

--
Nathan Ward