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.

[Harold Ritter]

Hi @franklaszlo ,

> So I assume, this RT community value is set when route is exported, or not ?

That is correct.

> If yes, then it assumes that the routes do have their RT 100:1 set on export, does it not ?

That is also correct.

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

I was referring to the locally exported routes, not the routes coming from other PEs.

Regards,

[franklaszlo]

"I was referring to the locally exported routes, not the routes coming from other PEs."  - So when I am exporting routes, I do attach the export RT(s) to them to let other parties match on this value and perform filtering, like importing.

But since I am exporting _all_routes_ from a vrf including those that were imported from other vrfs, what is preventing unwanted route leaking between vrfs ?

We all know that this works as expected, so my logic must be broken, but where ? 

[Harold Ritter · Accepted solution]

Hi @franklaszlo ,

> I do attach the export RT(s) to them to let other parties match on this value and perform

> filtering, like importing.

That is correct.

exporting _all_routes_ from a vrf

including those that were imported from other vrfs

Routes imported in a vrf from VPNv4 will not be exported back to VPNv4. 

Regards,

[franklaszlo]

"Routes imported in a vrf from VPNv4 will not be exported back to VPNv4. " - That must be the clue, I did not know this fact (where is it documented btw, just asking). So only routes originated locally - via redistribution or network statement - will be exported ? If yes, that explains.

[Harold Ritter]

Hi @franklaszlo ,

> where is it documented btw, just asking

Let me check if I can find a good document explaining that.

> So only routes originated locally - via redistribution or network statement - will be exported ?

That is correct. It can also be routes received from the CE via BGP.

Regards,

[MHM Cisco World]

One of vrf leaking uses case is

There is resources in vrf (we called it shared) all other vrf must access this shared vrf,

So we use vrf leaking + shared vrf

Now we want vrfA and vrfB access vrfShared

If we use route target both in vrf Shared then both vrfA and vrfB will leaking route between each other,

Solution what link you shared and what I use in my previous post (the one with colored import/export).

Sure there are other case but for your Q case this is answer. 

[Harold Ritter]

Hi @MHM Cisco World ,

> If we use route target both in vrf Shared then both vrfA and vrfB will leaking route between > each other,

Once vrf Shared import routes from vrfA or vrfB it will not export these routes back to vrf A or B. The vrf Shared can advertise an aggregate route and be used as a transit between vrf A and vrf B though.

Regards,

[MHM Cisco World]

It confuse but I will try explain it here

vrfA vrfB export prefix to vrfshared

So both use export x:x 

If we use

route-targer

both in vrfshared then 

Export/import x:x

The vrfA vrfB now need to import prefix (local to vrfshared not learn from any other vrf) to import we need import x:x since the export of shared x:x

This end that vrfA and vrfB now have import/export x:x this meaning all prefix between vrf exchange and that what not we need here.

So we need special export in vrfA and vrfB and import for vrfshared.

[Harold Ritter]

@MHM Cisco World ,

The import/export process is very flexible and offers many options. It could be as simple as this:

vrf A: import 109:1 and 109:3 export 109:1

vrf B: import 109:2 and 109:3 export 109:2

vrf Shared: import 109:1, 109:2 and 109:3 export 109:3

This way Shared imports all routes from A, B and itself.

A import all routes from Shared and itself.

B import all routes from Shared and itself.

A does not import from B and B does not import from A.

Regards,

[MHM Cisco World]

And that what was try to explain here to @franklaszlo 

Use of import/ export to prevent direct exchange between two vrf and make both access to shared vrf and shared vrf access to both vrf.

It simply what you config in one vrf as export is same as what you config in other vrf for import.

Thanks 

[franklaszlo]

@Harold Ritter I think your reply contradicts this article on PacketLife, the original source of confusion for me.

In that article, I quote :

"VRFs Customer_A and Customer_B will now import routes exported from VRF Shared in addition to their own "native" routes. To complete our VRF configuration, VRFs Customer_A and Customer_B also need to export their native routes to VRF Shared. But wait a minute. If we configure the customer VRFs to export to 65000:300, they'll end up learning each other's routes, because both are already importing 65000:300. We don't want that!"

So what is the truth at the end ?

[MHM Cisco World]

My Previous reply 

it confuse but I will try explain it here

vrfA vrfB export prefix to vrfshared

So both use export x:x 

If we use

route-targer

both in vrfshared then 

Export/import x:x

The vrfA vrfB now need to import prefix (local to vrfshared not learn from any other vrf) to import we need import x:x since the export of shared x:x

This end that vrfA and vrfB now have import/export x:x this meaning all prefix between vrf exchange and that what not we need here.

So we need special export in vrfA and vrfB and import for vrfshared

[Harold Ritter]

Hi @franklaszlo ,

There is no contradiction between this article and what I have said so far. What they mention is that if you import/export 65000:300 from A and B, routes will not only be shared between A and shared and B and shares, but also between A and B. my proposed strategy is different than their proposed strategy, but as I mentioned in my last post, the import/export process is very flexible and offer many possibilities:

vrf A: import 109:1 and 109:3 export 109:1

vrf B: import 109:2 and 109:3 export 109:2

vrf Shared: import 109:1, 109:2 and 109:3 export 109:3

This way Shared imports all routes from A, B and itself.

A import all routes from Shared and itself.

B import all routes from Shared and itself.

A does not import from B and B does not import from A.

Regards,

[franklaszlo]

All in all, the key point is that routes imported from VPNv4 will not be exported back to VPNv4. Thank you @Harold Ritter for pointing this out. Also appreciate all the efforts by @MHM Cisco World , thank you.

[Harold Ritter]

You are very welcome @franklaszlo and thanks for the feedback