07-18-2019 08:54 AM
hello
as i've searched i reached to one document but parts of that confused me :
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
both customers A and B need to import routes from a third VRF named Shared. We can configure the two customer VRFs to also import routes tagged with the Shared VRF's export RT of 65000:300
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!
The solution here is to export using a different RT than the one used for import. You can pick whatever number you want. To illustrate this point, we'll use 65000:1234
and NOW configuration something looks like :
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:12347
my question is i can't realize what this sentence : "they'll end up learning each other's routes, because both are already importing 65000:300 " meaning exactly ?
later it tell possible to import 65000:100 & 65000:200 but morely i mean that way import other value
Solved! Go to Solution.
07-18-2019 10:15 AM - edited 07-18-2019 10:16 AM
Hello cisc0.ameer,
first of all, you have an issue with route targets and not with route distinguishers.
>> 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!
If you do this you have an any to any VPN with Customer_A that learns Customer_B routes and viceversa and also communication is direct.
By using a different RT value like the one proposed RT:65000:1234 you build a so called Hub and Spoke connectivity with VRF Shared acting as the Hub and the two VRFs Customer_A and Customer_B not able to communicate to each other directly and not learning respective routes from vrf Shared.
Actually an imported VPNv4 prefix cannot be re-exported to the backbone with different RT attributes attached to it.
This is why the additional RT value works to build a constrained Hub and Spokes connectivity model.
Hint:
think of RT values as colors like RED, BLUE and so on.
You can represent each VRF site with the RT values used for importing and exporting.
Graphically you can see an Hub and Spoke MPLS L3 VPN as using two route targets values for importing and exporting on the hub site.
A more complex connectivity model called Hub and Spoke Central services can be built using two different VRFs on Hub PE node and having traffic going via an external customer device like a Firewall.
Hope to help
Giuseppe
07-18-2019 10:15 AM - edited 07-18-2019 10:16 AM
Hello cisc0.ameer,
first of all, you have an issue with route targets and not with route distinguishers.
>> 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!
If you do this you have an any to any VPN with Customer_A that learns Customer_B routes and viceversa and also communication is direct.
By using a different RT value like the one proposed RT:65000:1234 you build a so called Hub and Spoke connectivity with VRF Shared acting as the Hub and the two VRFs Customer_A and Customer_B not able to communicate to each other directly and not learning respective routes from vrf Shared.
Actually an imported VPNv4 prefix cannot be re-exported to the backbone with different RT attributes attached to it.
This is why the additional RT value works to build a constrained Hub and Spokes connectivity model.
Hint:
think of RT values as colors like RED, BLUE and so on.
You can represent each VRF site with the RT values used for importing and exporting.
Graphically you can see an Hub and Spoke MPLS L3 VPN as using two route targets values for importing and exporting on the hub site.
A more complex connectivity model called Hub and Spoke Central services can be built using two different VRFs on Hub PE node and having traffic going via an external customer device like a Firewall.
Hope to help
Giuseppe
07-18-2019 01:13 PM
07-21-2019 03:06 AM
hello sir
again thanks for your for clearing problem:
just now i get it
if we use 65000:300 and Export because in other PE we did import 65000:300 as you correctly mentioned Yes direct connecting will be done ! consequently the Hub and Spokes topology bollixed up !
so for keeping this topology in order to not connecting Customer_A and Customer_B directly connect we have to export something else like 65000:1234 and exported on the shared VRF
07-21-2019 07:08 AM - edited 07-21-2019 07:11 AM
Hello cisco0.ameer,
yes your understanding is correct:
to avoid direct communication between VRF Customer_A and VRF Customer_B a different RT value like RT:65000:1234 has to be used as export on Spoke sites and as import on Hub Site Shared.
RT 6500:300 is used for export in site Shared and for import on sites Customer_A and Customer_B.
Otherwise you defeat / break the Hub and Spokes connectivity model and you have the any to any (of full mesh).
Hope to help
Giuseppe
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