cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
170
Views
10
Helpful
4
Replies
Highlighted
Beginner

RD value problem

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

Everyone's tags (4)
1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Expert

Re: RD value problem

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

 

4 REPLIES 4
Hall of Fame Expert

Re: RD value problem

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

 

Beginner

Re: RD value problem

so many thanks sir for this much of prefect and patient answering
yes i got confused about this values let me i have to focus on it

let me i ask about it if make for me any doubt
thanks again
Beginner

Re: RD value problem

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

Hall of Fame Expert

Re: RD value problem

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

 

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards