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

[Ross Halliday]

> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Jason Lixfeld
> Sent: Wednesday, December 12, 2012 2:59 PM
> To: <cisco-nsp at puck.nether.net> NSP
> Subject: [c-nsp] route-target import on non-leaking PEs
> 
> Hi all,
> 
> PE1 and PE2 are MP-BGP neighbors.  Both have MP-BGP configs for vrf 1 and
> vrf 2.  PE1 leaks routes from vrf 2 (rt 1:2) into vrf 1 (rt 1:1) using
> route-target import 1:2 in the vrf definition for vrf 1.
> 
> It seems that if I want those imported routes in vrf 1 on PE2, I have to
> add route-target import 1:2 in the vrf definition for vrf 1 on PE2 as
> well.
> 
> This seems like a scaling nightmare if I have 100-odd routers that need
> access to those routes.

Yes, that is correct. The VRFs really are isolated instances on the individual routers - the only thing that makes them common is that they are configured with the same RTs. Also BGP isn't going to redistribute routes under another route distinguisher like the way I think you thought it would.

> 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? 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

>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.

Is this what you're looking for? Or trying to avoid? Can you be a little more specific?

Ross