Route Distinguisher Clarification

[leerobert]

Hello,

I understand that RD's are combined with IPv4 addresses so that two VPNs going through the same PE/P infrastructure can have overlapping addresses. I also understand that a single VPN cannot have overlapping addresses. But here is my query - Why cant one always use the same RD across all VRFs in a single VPN ? As per some cisco guides, this is not practical for some hub-and-spoke topologies. Anyone care to explain ?

Thanks

[romccallum]

ok if i were to create a typical vpn (any-any) I would use

ip vrf typical

rd 10:1

ro bo 10:1

the above config would be on every PE router that terminated this vpn.

Hub and spoke vpn

On the hub site I would do

ip vrf hub

rd 10:1

ro export 10:1

ro import 10:2

ro import 10:3

spoke site

ip vrf spoke1

rd 10:2

ro e 10:2

ro i 10:1

ip vrf spoke2

rd 10:3

ro e 10:3

ro i 10:1

It just makes things simple in my eyes.

[leerobert]

Hello,

I assume that for the spoke sites, I could use a the same export route-target value, and then on the hub site, I would only have one import statement.

[Harold Ritter]

Another case in which you don't want all PEs to have the same RD is when you want to loadbalance to a destination owned by a site connected to two different PEs and a RR is used in the core.

In such a case, configuring both PEs with the same RD would cause the advertisement for the specific destination coming from both PEs to have exactly the same VPNv4 address and the RR to select one of the two to advertise it to the remaining PEs, which would prevent loadbalancing.

Hope this helps,

[leerobert]

There is also an issue with BGP best-path-selection, when hub and spoke sites on the same PE share the same rd value - I think its referred to in the Cisco book on MPLS/VPN architectures - Thoughts ?

[leerobert]

Took a second look at the chapter, and here is what I think now - Obviously the hub and spoke sites on the same PE cant have the same RD, beacuse then they would be in the same VRF, and that would defeat the whole purpose of a hub-n-spoke toplogy. So it would make sense that what the book is referring to is that the spokes that are on the same physical PE as the hub site, must have a different RD from the RDs used for spoke sites on other PEs.... If that is not done then the BGP path selection process on the PE with hub and spoke sites will compare routes being exported by the hub vrf and the routes coming from the other remote spokes before importing the information into the spoke VRF on the PE that is connected to both hub and spoke sites...

[dknov]

Hi hritter,

I agree with you that using different RDs in this case would indeed allow BGP loadsharing, however it might raise a different issue in case VPNv4 updates which contain RD value which is different from RD value of VRF instance where this update is imported. In this case VPNv4 prefixes will be imported into a proper VRF and additionally into NULL VRF, of NULL BGP table (I hope it's a correct term for it).

When you're talking about many-many updates it will create serious resource consumption and I was wondering if there is an official Cisco "say" on this? The answer might be as simple as to keep this type of service to its minimum to conserve resources...

Thanks,

David