04-01-2023
04:10 AM
- last edited on
05-15-2023
10:11 PM
by
Translator
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.
Solved! Go to Solution.
04-02-2023 11:44 AM
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,
04-02-2023 11:53 AM - edited 04-02-2023 11:54 AM
"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 ?
04-02-2023
12:03 PM
- last edited on
05-15-2023
10:43 PM
by
Translator
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,
04-02-2023 12:33 PM
"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.
04-02-2023 12:50 PM
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,
04-02-2023 01:09 PM
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.
04-02-2023 02:34 PM
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,
04-02-2023
02:56 PM
- last edited on
05-15-2023
10:29 PM
by
Translator
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.
04-02-2023
03:16 PM
- last edited on
05-15-2023
10:30 PM
by
Translator
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,
04-02-2023 03:45 PM
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
04-03-2023 02:40 AM
@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 ?
04-03-2023
02:43 AM
- last edited on
05-15-2023
10:33 PM
by
Translator
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
04-03-2023
06:42 AM
- last edited on
05-15-2023
10:34 PM
by
Translator
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,
04-03-2023 09:57 AM
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.
04-03-2023 10:09 AM
You are very welcome @franklaszlo and thanks for the feedback
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide