[c-nsp] VRF route leaking

[Mike]

On 05/05/2015 11:07 PM, Nathan Ward wrote:
> On 6 May 2015 at 06:43:59, Mike 
> (mike-cisconsplist at tiedyenetworks.com(mailto:mike-cisconsplist at tiedyenetworks.com)) 
> wrote:
> > Hi,
> >
> > Now that I set off a very interesting fire storm about Internet in
> > a vrf, I have the next question, which is how do I accomplish it?
> >
> > I envision two vrf for example -
> >
> > internet - contains all my best paths and maybe including a default
> > route
> > subscribers - contains all of my internet subscriber routes, mostly
> > /32's (ipoe/pppoe customers), with a small number of /29's and larger.
> >
> > What would a simple config look like that lets my subscribers route
> > via the internet? Do I have to import the whole internet table into
> > subscribers, or ?
>
> 4 options off the top of my head, short answer, “it depends”.
>
> Do you care about RAM usage on your BNG?
> What does the rest of your network look like?
> Do you have a separate border router where the Internet comes in?
>
> If you do, you can generate a default on your border(s) in the 
> Internet VRF, and advertise that to a “default route only” RT (with 
> VRF export policy) and import that RT in to your subscribers VRF. Make 
> sure you set per-VRF label mode on your border router. This will get a 
> default in to your subscribers VRF, packets will follow it to your 
> border where they’ll do another route lookup (per-VRF label mode does 
> this) and get sent to whichever peering/transit partner is best.
>
> Instead of having a “default route only” RT, you could use an import 
> filter on the subscribers VRF to only accept a default from the 
> Internet RT, however, that prevents you from getting much gain from 
> using rt-filter on routers where you only want the default. If you use 
> a “default route only” RT, you can turn on rt-filter and only have 
> your full table on routers that actually care about it, which is handy 
> if you’ve got low-RAM or low-CPU boxes in your BGP network.
>
> I’m not sure if you can on Cisco, but on Juniper you can do a static 
> route to another VRF, with the next-table parameter when configuring 
> the route. My understanding is you can only do static routes to or 
> from global on Cisco. If you find you can do this however, you could 
> do a static default route from your subscribers VRF in to your 
> Internet VRF.
>
> Of course, you could just import the whole Internet table in to your 
> subscribers VRF. That’s by far the simplest, just keep an eye on your RAM.
>
> You also need to leak your subscriber routes in to your Internet VRF, 
> so that inbound packets can get to your subs.
> What platform are you running? See my recent thread about subscriber 
> redistribution on ASR9000 if that’s what you’re running, and if you’ve 
> got peering/transit/non-BNG stuff on the same box as your BNG.

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.

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.

Thank you for the feedback.

Mike-