[c-nsp] route-target import on non-leaking PEs

[Jason Lixfeld]

On 2012-12-12, at 3:14 PM, Ross Halliday <ross.halliday at wtccommunications.ca> wrote:

>> Also BGP isn't going to redistribute routes under another route distinguisher like the way I think you thought it would.

The RD is common to both PEs as they share the same VRFs and the same VRF config, so I think that in this case the BGP would carry the routes between the two PEs.  At least it seems to.  The routes seem to be in vpnv4 under the correct RD.

>> How do folks work around this?  Set the rt to 1:1 using an import map in
>> the definition for vrf 1 on PE1?
> 
> This depends really on what you're trying to accomplish. Is this some kind of common service VRF?

A services VRF might be one way to describe it.

> The way I've approached this is by creating 'service' RTs that I add to VRFs where required. For example:
> 
> ip vrf voip-sbc
> rd 1:100
> route-target export 1:101
> route-target import 1:102
> !
> ip vrf voip-customer-a
> rd 2:1234
> route-target both 2:1234
> route-target import 1:101
> route-target export 1:102
> !
> ip vrf voip-customer-b
> rd 3:5678
> route-target both 3:5678
> route-target import 1:101
> route-target export 1:102

In my case, I've always used a common RD, import and export RT inside any given VRF.  My particular implementation started off as one Internet VRF and one management VRF, so using common RD and RTs didn't seem to really matter.  I see you've done it differently in that for each VRF, your RD, import and export RT for your services VRF are unique where your customer RD and RTs are the same.  I don't understand why you've done that so I think I need to hit the books again to try and understand why it might matter.

> From a provisioning setup this is really straight forward... pick and choose what the VRF needs access to when you build it. Keeps things simple and hands away from the actual service VRFs.

That's interesting.  I've seen this done before, but I'm not really sure if it's the solution I'm looking for.  I'm moderately green to this VRF leaking stuff.

> Is this what you're looking for? Or trying to avoid? 

What I'm trying to avoid is having to rewrite a bunch of vrf config on the 100 or so routers that have a config already applied to it.  Maybe it's unavoidable though.  If it is, it's gotta get done if it's the right way to do it.

> Can you be a little more specific?

Sure.  I carry the entire Internet routing table inside a VRF.  I suppose for all intents and purposes this could be considered the 'services' VRF you spoke of.  I have another VRF, call it the customer VRF, which needs Internet access, so through the Internet VRF.  I'm trying to just stick a default route from the Internet VRF into the Customer VRF to accomplish that.  Naturally, Internet destinations would need to know how to send their return traffic back to the customer VRF, so those Customer VRF routes would have to get leaked into the Internet VRF for reachability.

Not sure if that helps clarify or helps confuse :)