big issue!!!Full mesh vs Hub-Spoke vs Hybrid topology using RD+RT MPLS

[cisc0.ameer]

hello all

sorry my question i've tried not to ask duplicate question but as i have seen in most forums and websites definition of RD (route distinguisher ) and route-target is defined but cause little bit confusing i dig into deeper and maybe i figure out something fantastic(at least for myself)

just how you interpretation it ?

i find that in Full Mesh scenario RD values on PEs can be same to RT(import and export)

but after full mesh when ever Hub and Spokes topology or more complicated scenario come in when we will use RT values as a parameter for determinate which Networks should receive and send with PEs ....SO

RD no longer playing role among our configuration ...let me i clarify this but before i still confused when we could use from RT whats need for RD because in a Real scenario Question i saw did not use RD values in any PEs!!!!!but how possible ? just playing with RT values .

one trainer told RD will not playing much role in a scenario which contains RT and does not full mesh (specific Route we want to receive and vice-versa )

this problem annoying me too much ! because in real scenario configuration i saw RD did not use ,  just under vrf we had something like for example 65002:2 , 65002:3 , 65002:4 and so on .......just played with RT(import and export)

i asked this but did not get full comprehensive informing !!!! where we will use RD but insist on RT , in which situation should just define RD but important key is a   RT ....

i hope i did not tell hectic !!!and confused you

my problem is suppose we have 10 PEs consequently 10 RD was defined ! but never use this RD values in others PEs ! so why we have to define this ! this is first and foremost

and second one is it correct when we DO not have full mesh scenario just Defined RD and RT comes in and playing role?

[Giuseppe Larosa]

Hello cisc0.ameer,

most of the confusion is caused by configuration examples that use in simple cases the same value for RD and for RT.

The RD is really important, because the RD is part of the VPNv4 prefix and it is not a BGP attribute:

Actually, the VPNv4 prefix 96 bit wide is made of :

64 bits of RD followed by 32 bits of IPv4 IP subnet.

The RD allows for address overlapping support in different VRFs / different customer VPN.

The RD duty is to make the VPNv4 address unique in the single PE and in the backbone.

The RT are used for importing or exporting VPNv4 prefixes into/from a VRF routing table.

The RD are needed locally in a single PE and are used also on remote PE when importing prefixes.

The importing of VPNv4 prefixes in a VRF is decided by route targets values associated to the VPNv4 prefix. These are BGP attributes of the MP NLRI of type extended community.

The RD is still important because in case of multihomed VRF site the two PE nodes using a different RD can have both VPNv4 prefixes propagated by route reflector servers (for the different RD the RRS see them as different not comparable) and remote PE can even install multipath if configured for doing so at bgp AF vrf <name> level with maximum-paths eibgp <n>.

Just to make an example, in VRF lite you can configure a VRF without using RT, if you are not using MP BGP, but the RD is still a needed command (it may be auto-assigned automatically but it is still required).

I think documents should use different values for RD and RT also in the simple examples to make clear from beginning they are different and have different usage.

RD and RT have in common the format of their values.

Hope to help

Giuseppe

[cisc0.ameer]

hello sir

as you mentioned

The RD is still important because in case of multihomed VRF site the two PE nodes using a different RD can have both VPNv4 prefixes propagated by route reflector servers (for the different RD the RRS see them as different not comparable) and remote PE can even install multipath if configured for doing so at bgp AF vrf <name> level with maximum-paths eibgp <n>.

1-did you mean if we have Route-Reflector server in our topology we can assigned RD values in each PE but not necessary to use that RD in other PEs ?   in this case we can have different RD value but using RT /

do i understand correctly ?

RD here has a duty for making locally routing table unique for local PE

2-what you mean by :not comparable

RRS see them as different not comparable

3- just for clarifying for last time in Full Mesh scenario usually if we assign RD value like 100:1

in other PE we generally use 100:1 ...am i right ?because you mentioned

The RD are needed locally in a single PE and are used also on remote PE when importing prefixes.
(this is correct i think in case 
we have full mesh scenario because in my scenario it used different RD and never used it in other PEs ) 

thanks and regards

[Giuseppe Larosa · Accepted solution]

Hello cisc0.ameer,

I try to answer to your questions:

>> 1-did you mean if we have Route-Reflector server in our topology we can assigned RD values in each PE but not necessary to use that RD in other PEs ?   in this case we can have different RD value but using RT /

Your understanding is correct in case of a multihomed VRF site using two different RD values on the two PE nodes serving the site provide the benefits that both sets of VPNv4 routes are propagated even if using Route Reflector servers.

>>

2-what you mean by :not comparable

RRS see them as different not comparable

As I have explained in my previous post the VPNv4 is made by prepending the 64 bit RD to the IPv4 subnet.

So, from the point of view of the RRS the two VPNv4 prefixes:

65000:1001:10.10.10.0/24      RT 65000:500

65000:1002:10.10.10.0/24      RT 65000:500

are two different not comparable VPNv4 prefixes, as a result of this the RRS does not perform a best path choice and both of them are propagated to all other PE nodes and other RRS. (this is the key point making the VPNv4 prefixes different so that they are not compared for best path selection otherwise only the routes of one PE node will be propagated by RRS usually the one generated by PE node with lower BGP router-id)

The remote PE nodes will import both VPNv4 routes because of the same route-target value.

At this point the remote PE node can even install both paths via PE1 and PE2 if configured for doing that.

By default the remote PE will install only a single route the BGP best path ( likely the route originated by the PE node with the lowest BGP router-id if the IGP metric to next-hop is the same).

>>

3- just for clarifying for last time in Full Mesh scenario usually if we assign RD value like 100:1

in other PE we generally use 100:1 ...am i right ?because you mentioned

The RD are needed locally in a single PE and are used also on remote PE when importing prefixes.
(this is correct i think in case 
we have full mesh scenario because in my scenario it used different RD and never used it in other PEs ) 

Let me say again in a any to any VPN = Full Mesh the habit is to use the same RD on all PE nodes.

But the connectivity model is decided by RT values.

using a single route-target value for importing and exporting creates an any to any connectivity model the simplest one.

RD values are only used to support address overlapping on same PE node and also for allowing differentiation of VPNv4 prefixes on RRS as explained above for multihomed VRF sites when looking from the point of view of a remote PE node. This is the sense of my sentence. I'm sorry it it was causing confusion.

However, I would like to make you aware that RD can be populated in a different manner:

RD:    two bytes cannot be configured and are chosen depending on the format used for the RD configurable fields:

Possible options for RD are the following:

a) two bytes AS number followed by a 32 bit integer value example:  65000:1001

You know this already.

b) four bytes IP address of the loopback address PE node followed by 16 bit integer

Example:   PE:loop0 address is 172.16.255.21/32  a possible RD is 172.16.255.21:1001

where PE:loop0 is the BGP router-id, MPLS LDP RID and OSPF RID (if OSPF is used).

When using this second convention in building RD values we have the advantage of immediately be able to read the originator PE loopback address. So this format is handy and used in some environments.

Hope to help

Giuseppe

[cisc0.ameer]

Hello sir

Amazing answer !

too much thanks

very helpful

regards

best wishes