export-import route-target

[franklaszlo]

I know there are a dozen of articles and examples revolving around this topic, however there are two questions I still can't find the answer for.

#1, when exporting routes from a vrf, what happens with the

route-target

community that is already existing for the given prefix because say it was imported from another vrf ? Since all routes are exported from a vrf (assume no filtering) the vrf will contain routes imported from other vrfs, so will these be also exported ?

As an example, if a vrf is importing for RTs 100:1 and 100:2 and exporting as 100:3,

    route-target import 100:1

    route-target import 100:2

    route-target import 100:3

    route-target export 100:3

what happens with 100:1 and 100:2 communities on export ? Will the exported routes contain 100:3 only and thus 100:1 and 100:2 disappear on export, or will 100:3 be added to community list resulting routes having RTs 100:1, 100:3 and 100:2, 100:3 respectively, or ?

#2, yet another confusing scenario is exporting for multiple RTs, like this:

route-target export 100:3
route-target export 100:100

In this case, will every single route entry in a given vrf be exported twice in two distinct NLRIs, one attached the RT 100:3 and the other having RT 100:100 or a single NLRI is constructed having both 100:3 and 100:100 RTs included ? 

So combined with question#1, why does this exporting scheme resolves the shared vrf import-export scenario discussed in this PacketLife article ?

Thank you.

[MHM Cisco World]

I get you Q after check link this VRF leaking 
answer with lab soon 

[franklaszlo]

Thank you @MHM Cisco World but this was not the question

[MHM Cisco World]

I check you can really add two export to one prefix and it will list in Extended-Comm 

[MHM Cisco World]

ip vrf Customer_A
 rd 65000:100
 route-target export 65000:100 
 route-target import 65000:100
 route-target import 65000:300
!
ip vrf Customer_B
 rd 65000:200
 route-target export 65000:200
 route-target import 65000:200
 route-target import 65000:300
!
ip vrf Shared
 rd 65000:300
 route-target export 65000:300
 route-target import 65000:300

the export must same to import in other PE/VRF here the export is not same
so you can use 65000:100 and 65000:200

ip vrf Customer_A
 rd 65000:100
 route-target export 65000:100
 route-target export 65000:1234
 route-target import 65000:100
 route-target import 65000:300
!
ip vrf Customer_B
 rd 65000:200
 route-target export 65000:200
 route-target export 65000:1234
 route-target import 65000:200
 route-target import 65000:300
!
ip vrf Shared
 rd 65000:300
 route-target export 65000:300
 route-target import 65000:1234

Or you can easy add other export with it same import  in two VRF's and shared VRF.

[franklaszlo]

Let me go through the config as per my understanding - where is the fault in my logic ?

1: Both VRF Customer_A and VRF Customer_B export their routes to Shared_VRF using RT 65000:1234, and Shared_VRF is importing them both. At the end of the day, Shared_VRF will contain all the routes from both customers, right ?

2: Then Shared_VRF exports all of its routes (those that were imported from Customer_A and also from Customer_B) using RT 65000:300, which is then imported into both Customer_A and Customer_B VRF.

So what is preventing Customer_A to learn the prefixes of Customer_B via the import from Shared_VRF ? Where is the filtering mechanism, I can't understand.

[Harold Ritter]

Hi @franklaszlo ,

1: Correct

2: routes imported into a VRF can't be exported back to VPNv4.

> Customer_A to learn the prefixes of Customer_B

These two VRFs will not learn each other routes, unless they are specifically configured to import/export from each other. 

Regards,

[Kanan Huseynli]

Hi,

simple because, imported route will not have export

route-target

if it is locally exported.

Take simple router with VRF A,B and SHARED. One loopback interface per VRF A,B (loopback1, loopback2). Export them with different RT (1000:1,1000:2) and import (1000:1,1000:2) on SHARED. Plus, add export RT (1000:1000) on SHARED and import RT (1000:1000) on A, B.

If you check

show bgp vpnv4 unicast vrf SHARED {loopback1 or 2} 

you will not see 1000:1000 RT on local device for SHARED VRF, that's why A,B don't import each other's prefixes.

Router#sh bgp vpnv4 unicast vrf A 1.1.1.1/32  >> Lo1 in VRF A
BGP routing table entry for 1000:1:1.1.1.1/32, version 2
Paths: (1 available, best #1, table A)
Not advertised to any peer
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (100.100.100.100)
Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:1000:1
mpls labels in/out 20/nolabel(A)
rx pathid: 0, tx pathid: 0x0




BGP routing table entry for 1000:1000:1.1.1.1/32, version 5
Paths: (1 available, best #1, table SHARED)
Not advertised to any peer
Refresh Epoch 1
Local, imported path from 1000:1:1.1.1.1/32 (A)
0.0.0.0 (via A) from 0.0.0.0 (100.100.100.100)
Origin IGP, metric 0, localpref 100, weight 32768, valid, external, best
Extended Community: RT:1000:1 > there is not 1000:1000 as addition
mpls labels in/out nolabel/nolabel(SHARED)
rx pathid: 0, tx pathid: 0x0

[Harold Ritter]

Hi @franklaszlo ,

1- 100:1 and 100:2 are just used to match routes that will be imported in the VRF. These route targets exported communities will not appear on exported routes.

2- The same the exported route will be tagged with multiple route target extended communities.

Regards,

[MHM Cisco World]

but shared VRF do that, it import/export the route. 
I never use

route-target

both in VRF leaking but I will check and share result here. 
thanks 

[Harold Ritter]

Hi @MHM Cisco World ,

A VRF route is only imported and exported once.

Regards,

[MHM Cisco World]

sorry so I can not use

route-target

both in shared VRF ?
what I understand from the link @franklaszlo  shared that he use different import value to not make route direct exchange between VRF but via shared VRF. 

[Harold Ritter]

Hi @MHM,

Sorry I had misread the question. I just updated the post as follow:

1- 100:1 and 100:2 are just used to match routes that will be imported in the VRF. These route targets exported communities will not appear on exported routes.

Thanks for pointing that out.

Regards,

[MHM Cisco World]

You are welcome,
Yes I was misread his Q too.
thanks for all support.

[franklaszlo]

Many thanks  @Harold Ritter and @MHM Cisco World for all your effort with this topic, much appreciated.

My base understanding is, that route targets are extended community values that are set on routes when exported and sent in BGP updates together with the route, right ? So I assume, this RT community value is set when route is exported, or not ?

@Harold Ritter 

"100:1 and 100:2 are just used to match routes that will be imported in the VRF"

I understand that when specifying

route-target import 100:1,

it literally means the following (please correct if mistaken) : check all VPNV4 routes in VPNV4 BGP table, and import only the routes to the VRF routing table that has their extended community RT set to - or containing - 100:1. Is this not the case ? If yes, then it assumes that the routes do have their RT 100:1 set on export, does it not ?

"These route targets exported communities will not appear on exported routes."

If export community does not appear on routes, how does the far end router match on it ? If I configure

route-target export 100:3

then I believe this community value must be set on the routes in routing updates, otherwise I really don't understand how is it possible to filter them  at remote ?

I think @MHM Cisco World testing above just showcased this: