cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
31023
Views
75
Helpful
12
Replies
Beginner

Real Purpose of Route-Distinguishers

Hi All,

I have a quick question regarding route-distinguishers.  In an ISP cloud using MP-iBGP VPNv4 to carry customer routes, do the route-distinguishers on different PE routers (each servicing the same customer at different locations) need to have the same route distinguishers on the VRFs of the different PE routers?

Secondly, are route-distinguishers carried in MP-BGP VPNv4 advertisments?  I guess this boils down to...what is the real purpose of route-distinguishers.

Any insight would be very helpful!

David    

3 ACCEPTED SOLUTIONS

Accepted Solutions
Hall of Fame Cisco Employee

Real Purpose of Route-Distinguishers

Hello David,

do the route-distinguishers on different PE routers (each servicing the  same customer at different locations) need to have the same route  distinguishers on the VRFs of the different PE routers?

The values of route distinguishers (RDs) can be largely arbitrary. The must be unique for different VRFs on the same PE, but for two corresponding VRFs on two different PEs, they may or may not be the same, it does not really matter. In simpler deployments, they can be the same, but in larger or more complex VPNs, it is more probable that they differ.

Secondly, are route-distinguishers carried in MP-BGP VPNv4 advertisments?

Yes, they are, as part of al network addresses that are in a particular VRF and are advertised to another PEs.

Allow me to explain the process of advertising the routes from one PE to another, and let me start first by talking about the other attribute configured in VRF - the Route Target (RT).

The RT is a BGP attribute of a route - technically, it is an extended  community attribute. Being an attribute means that this value is a  property of the route that further specifies how it shall be processed  but does not form a part of the route's network address or mask. It is included along with the advertisement of that network to a BGP peer but just as with other BGP attributes (next hop, local preference, metric, AS_PATH, etc.), it is just a property of the advertised network, not an address part. Certain  BGP attributes do not need always to be present, or can be present multiple  times in an update for a route. The RT in particular is used to say into  which VRFs can the particular route be imported. Saying that a route has  an export RT of 1:1 and 1:2 means that the route can be imported to any  VRF that imports routes with either 1:1 or 1:2.

The presence of the RT and the possibility of having multiple RTs for a  single update allows for great flexibility in designing MPLS VPNs with  several locations and partial visibilities between them. However, having  only RTs would not be sufficient.

Consider two VRFs on a single router, V1 and V2, each of them containing  a single network 10.0.0.0/8. For now, assume that there is no concept of RD. If BGP  sends the routes from this router to a peer, it always sends them in  some sequence. Let's assume that the first routes sent are the ones from  one VRF, say V1, then routes from another VRF, say V2, are advertised.  V1 uses RT of 1:1, V2 uses RT of 1:2.

Now imagine how the BGP updates would look on the wire: first, an update  comes, saying that there is a network 10.0.0.0/8 with the RT set to 1:1.  What would the neighboring router do? It would place the route into the  corresponding VRF V1. Now, a second update comes in (or a second entry  from the single update is processed), and guess what - it says that  there is the same network 10.0.0.0/8, just with the RT set to 1:2. So  what would the neighboring router do? It would consider this second  update to be a  replacement of the previous update - the same network  but different attributes! So it would  remove the network 10.0.0.0/8  from the VRF V1 and add it to VRF V2!

This would happen because for BGP, the network and its netmask are  so-called keys in its database. An update to a network is performed  simply by sending the update about this network again, with new  attributes explicitly specified. There is no need to first withdraw the  route. And because BGP does not see the difference between the network  10.0.0.0/8 from V1 and 10.0.0.0/8 from V2, it gets confused because it  thinks that the information about the same network simply got updated.

This is where RD comes into play - by extending the formal network  address for all routes in a particular VRF using a unique value. If V1  has the RD also set to 1:1 (it may very well be different from RTs and  usually it is) and V2 has RD set to 1:2, then the route from V1 will be  advertised as 1:1:10.0.0.0/8 while the same route from V2 will be  advertised as 1:2:10.0.0.0/8. For BGP, it is now immediately obvious  that these two networks are not the same. The trick here, therefore, is  to use the RD to temporarily extend the IP addresses of networks in a  VRF with unique values to work around the BGP's attitude to  identical-looking networks. However, the RD is not used to sort routes  into different VRFs after receiving them through BGP, and exists purely  within the BGP communication.

So the RT says into which VRF a route can and possibly will be imported.  The RD helps BGP understand that network X from one VRF is not the same  as the network X from another VRF. Both RT and RD have the same format  but that is their only similarity. RD must be present exactly once in  each VRF on a single PE and needs to be unique. RT must be present at least once in  each VRF and does not need to be unique (if VRF route leaking is  desired). RD becomes a part of the network address within BGP updates,  RTs are carried as attributes of these networks. RDs are never used to  sort routes among VRFs - that is the purpose of RTs. That is also the reason why the RD may or may not be the same in two corresponding VRFs on two different PEs - it actually does not matter.

Please feel welcome to ask further!

Best regards,

Peter

Hall of Fame Cisco Employee

Re: Real Purpose of Route-Distinguishers

Hello David,

With the possibility of different VRFs (on the same PE) having identical  routes, I gather it would be necessary to have different RDs on the  VRFs residing on the same PE.  Is this correct?

Absolutely correct. It is required to make the same-looking networks unique within BGP updates. I have also indicated that in my first reply:

The values of route distinguishers (RDs) can be largely arbitrary. The must be unique for different VRFs on the same PE... [cut]

Sorry for the typo, BTW: it should say "They must be unique..."

IOS won't allow you to configure two VRFs with the same RD anyway:

R1(config)#ip vrf V1

R1(config-vrf)#rd 1:1

R1(config-vrf)#exit

R1(config)#ip vrf V2

R1(config-vrf)#rd 1:1

% RD 1:1 already in use by VRF V1

R1(config-vrf)#

Best regards,

Peter

Cisco Employee

Real Purpose of Route-Distinguishers

Hi,

Everything said by David is correct.

Just to add, often the service provider chooses unique RD for the VRF on each PE router. So, there is no RD per VRF in this case. This helps in immediately identifying the originating PE router by looking at the RD. Second, in some cases having different RDs for the same network in the same VRF helps load balancing schemes where the route reflector can then advertise both vpnv4 prefixes as they are unique (same network, but different RD). The route reflector can only advertise the best path of a network, even if there are multiple paths in the BGP table for that network.

Thanks,

Luc

12 REPLIES 12
Hall of Fame Cisco Employee

Real Purpose of Route-Distinguishers

Hello David,

do the route-distinguishers on different PE routers (each servicing the  same customer at different locations) need to have the same route  distinguishers on the VRFs of the different PE routers?

The values of route distinguishers (RDs) can be largely arbitrary. The must be unique for different VRFs on the same PE, but for two corresponding VRFs on two different PEs, they may or may not be the same, it does not really matter. In simpler deployments, they can be the same, but in larger or more complex VPNs, it is more probable that they differ.

Secondly, are route-distinguishers carried in MP-BGP VPNv4 advertisments?

Yes, they are, as part of al network addresses that are in a particular VRF and are advertised to another PEs.

Allow me to explain the process of advertising the routes from one PE to another, and let me start first by talking about the other attribute configured in VRF - the Route Target (RT).

The RT is a BGP attribute of a route - technically, it is an extended  community attribute. Being an attribute means that this value is a  property of the route that further specifies how it shall be processed  but does not form a part of the route's network address or mask. It is included along with the advertisement of that network to a BGP peer but just as with other BGP attributes (next hop, local preference, metric, AS_PATH, etc.), it is just a property of the advertised network, not an address part. Certain  BGP attributes do not need always to be present, or can be present multiple  times in an update for a route. The RT in particular is used to say into  which VRFs can the particular route be imported. Saying that a route has  an export RT of 1:1 and 1:2 means that the route can be imported to any  VRF that imports routes with either 1:1 or 1:2.

The presence of the RT and the possibility of having multiple RTs for a  single update allows for great flexibility in designing MPLS VPNs with  several locations and partial visibilities between them. However, having  only RTs would not be sufficient.

Consider two VRFs on a single router, V1 and V2, each of them containing  a single network 10.0.0.0/8. For now, assume that there is no concept of RD. If BGP  sends the routes from this router to a peer, it always sends them in  some sequence. Let's assume that the first routes sent are the ones from  one VRF, say V1, then routes from another VRF, say V2, are advertised.  V1 uses RT of 1:1, V2 uses RT of 1:2.

Now imagine how the BGP updates would look on the wire: first, an update  comes, saying that there is a network 10.0.0.0/8 with the RT set to 1:1.  What would the neighboring router do? It would place the route into the  corresponding VRF V1. Now, a second update comes in (or a second entry  from the single update is processed), and guess what - it says that  there is the same network 10.0.0.0/8, just with the RT set to 1:2. So  what would the neighboring router do? It would consider this second  update to be a  replacement of the previous update - the same network  but different attributes! So it would  remove the network 10.0.0.0/8  from the VRF V1 and add it to VRF V2!

This would happen because for BGP, the network and its netmask are  so-called keys in its database. An update to a network is performed  simply by sending the update about this network again, with new  attributes explicitly specified. There is no need to first withdraw the  route. And because BGP does not see the difference between the network  10.0.0.0/8 from V1 and 10.0.0.0/8 from V2, it gets confused because it  thinks that the information about the same network simply got updated.

This is where RD comes into play - by extending the formal network  address for all routes in a particular VRF using a unique value. If V1  has the RD also set to 1:1 (it may very well be different from RTs and  usually it is) and V2 has RD set to 1:2, then the route from V1 will be  advertised as 1:1:10.0.0.0/8 while the same route from V2 will be  advertised as 1:2:10.0.0.0/8. For BGP, it is now immediately obvious  that these two networks are not the same. The trick here, therefore, is  to use the RD to temporarily extend the IP addresses of networks in a  VRF with unique values to work around the BGP's attitude to  identical-looking networks. However, the RD is not used to sort routes  into different VRFs after receiving them through BGP, and exists purely  within the BGP communication.

So the RT says into which VRF a route can and possibly will be imported.  The RD helps BGP understand that network X from one VRF is not the same  as the network X from another VRF. Both RT and RD have the same format  but that is their only similarity. RD must be present exactly once in  each VRF on a single PE and needs to be unique. RT must be present at least once in  each VRF and does not need to be unique (if VRF route leaking is  desired). RD becomes a part of the network address within BGP updates,  RTs are carried as attributes of these networks. RDs are never used to  sort routes among VRFs - that is the purpose of RTs. That is also the reason why the RD may or may not be the same in two corresponding VRFs on two different PEs - it actually does not matter.

Please feel welcome to ask further!

Best regards,

Peter

Beginner

Real Purpose of Route-Distinguishers

Peter,

With the possibility of different VRFs (on the same PE) having identical routes, I gather it would be necessary to have different RDs on the VRFs residing on the same PE.  Is this correct?

Hall of Fame Cisco Employee

Re: Real Purpose of Route-Distinguishers

Hello David,

With the possibility of different VRFs (on the same PE) having identical  routes, I gather it would be necessary to have different RDs on the  VRFs residing on the same PE.  Is this correct?

Absolutely correct. It is required to make the same-looking networks unique within BGP updates. I have also indicated that in my first reply:

The values of route distinguishers (RDs) can be largely arbitrary. The must be unique for different VRFs on the same PE... [cut]

Sorry for the typo, BTW: it should say "They must be unique..."

IOS won't allow you to configure two VRFs with the same RD anyway:

R1(config)#ip vrf V1

R1(config-vrf)#rd 1:1

R1(config-vrf)#exit

R1(config)#ip vrf V2

R1(config-vrf)#rd 1:1

% RD 1:1 already in use by VRF V1

R1(config-vrf)#

Best regards,

Peter

Cisco Employee

Real Purpose of Route-Distinguishers

Hi,

Everything said by David is correct.

Just to add, often the service provider chooses unique RD for the VRF on each PE router. So, there is no RD per VRF in this case. This helps in immediately identifying the originating PE router by looking at the RD. Second, in some cases having different RDs for the same network in the same VRF helps load balancing schemes where the route reflector can then advertise both vpnv4 prefixes as they are unique (same network, but different RD). The route reflector can only advertise the best path of a network, even if there are multiple paths in the BGP table for that network.

Thanks,

Luc

Hall of Fame Cisco Employee

Re: Real Purpose of Route-Distinguishers

Hello Luc,

Thank you very much for joining!

This helps in immediately identifying the originating PE router by looking at the RD

Yes, especially if used in the form IP-ADDRESS:NN.

Second, in some cases having different RDs for the same network in the  same VRF helps load balancing schemes where the route reflector can then  advertise both vpnv4 prefixes as they are unique (same network, but  different RD). The route reflector can only advertise the best path of a  network, even if there are multiple paths in the BGP table for that  network.

Exactly. This is precisely what I meant in my first post when I wrote:

In simpler deployments, they [RDs on corresponding VRFs on different PEs] can be the same, but in larger or more complex VPNs, it is more probable that they differ.

By the way, a few years ago, you have been leading a WebEx session about basic MPLS for Cisco Networking Academy instructors. I had the pleasure of attending it... it is so nice to meet you again here!

Best regards,

Peter

Beginner

Real Purpose of Route-Distinguishers

Gentlemen,

Thank you so much for taking your time to clarify this to me.  These explanations have really really clarified my understanding of RDs.  Also, Luc, thank you for writing the MPLS Fundamentals book!  I am currently reading this book in preparation for my MPLS exam.  It looks like I will need go through some of the topics more than just once

Warm Regards,

David

Beginner

Hi Peter, Luc,Sorry to open

Hi Peter, Luc,

Sorry to open up this old discussion but I would like to know how BGP processes VPNv4 routes when each PE router uses a different RD for a particular VRF.

Consider Router R1 receiving VPNv4 prefix with RD 192.168.1.2:10000 for IPv4 prefix 192.168.64.0/18 from R2 and VPNv4 prefix with RD 192.168.1.3:10000 for the same prefix, but R1 is configured with RD 192.168.1.1:10000.

From a Cisco book, the steps taken by a PE router are as follows-

"

1. Takes all routes with the same route-target as any of the import statement within the VRF.

2. Considers all routes that have the same route-distinguisher as the one assigned to the VRF being processed.

3. Creates new BGP paths with a route-distinguisher that is equal to the route-distinguisher configured from the VRF that is being processed.

All the routes are now compared and at this point, the BGP route selection process is executed.

" 

My question is - R1 sees two independent paths - one each from R2 and R3. How is step-3 executed?

Beginner

Okay found the answer - R1

Okay found the answer - R1 will create a copy of both "imported" routes from R2 and R3 and run a BGP best path selection process.

 

Thanks.

-AB

Beginner

Re: Real Purpose of Route-Distinguishers

If following condition is met.. what will be end result:

 

PE1 - VRFA - prefix:1.1.1.0 - rd 1:1

PE2 - VRFB - prefix:1.1.1.0 - rd 1:1

 

if these routes are shared with a third PE and if exchanged bw these PEs. in this case how the BGP will differentiate the prefix

 

#copied from 

 

https://supportforums.cisco.com/t5/mpls/same-rd-same-prefix/td-p/1251820

 

Highlighted
Beginner

Hi Peter,

Hi Peter,

That was very good explanation, I had few confusion and it has gone away after reading your post. Thank you once again.

BR//

Olly

wholehearted thanks Peter..

wholehearted thanks Peter...crisp,clear and to the point....clarified my doubts

Hall of Fame Cisco Employee

Hi,

Hi,

It's a pleasure! I am grateful to know that this aging post was actually helpful.

Best regards,
Peter

CreatePlease to create content
Content for Community-Ad
July's Community Spotlight Awards
This widget could not be displayed.