!!!! RD vs RT in mpls !!!!

Hi Please help me out regarding the difference between RD and RT.

As per documents they state RD will be mapped to bgp attribute to avoid duplicity of ip address because mp-bgp is the best protocol to carry routes between ce and pe.

RT is used to push the concerned routes into the proper VRF.

Here are my doubts:

Cant we use RD alone since it is also avoiding duplicity and making routes unique.

Please specify any good document for my basic understanding,how much ever i put in but i am getting lost some where.

any good document which refers packet level exposure.I am really thankfull.

Comments

  • The RD is only used for making routes unique. It takes an IPv4 prefix and uses the RD value (8 bytes) to make a VPNv4 prefix. Thanks to this Customer A and Customer B may use the same subnets like 10.0.0.0/24 and the prefixes will still be unique. The RD has nothing to do with what VPN the prefixes belong to. The RD is usually chosen depending on the loopback of the router or the ASN of the enterprise. You can use numbers like 192.168.1.1:1 or 3200:1234.

    The RT value is a 64-bit extended community that defines the VPN. We can build different kind of topologies through import and export of RT values. We could use RT 1:1 for VPN A and 2:2 for VPN B and a Hub that has 100:1. Then we would import 100:1 on spokes and export 1:1 and 2:2 from the VPNs. Then the Hub will import 1:1 and 2:2. This would be a hub and spoke topology where spokes don't have direct communication.

    Check out these links:

    http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_cfg_layer3_vpn_ps6441_TSD_Products_Configuration_Guide_Chapter.html

    http://blog.initialdraft.com/archives/1537/

  • Hi,

    RDs and RTs serve different purposes. RDs are prepended to an IPv4 route to make it unique while it is transported via MP-BGP. RD+IPv4 route is called a VPNv4 prefix.

    MPLS VPNs allow you to build logical network topologies. RTs are the tool to build those topologies. RTs are extended BGP community attributes that tag a routes when they leave the PE router. On the receiving PE you can decide based on the RT if you want to import the route into the VRF or not.

    I hope that doesn`t add to the confusion ;-)

    I would recommend to read chapter 7 on MPLS VPNs in the CiscoPress book MPLS Fundamentals[1]

     

    Best regards,

    Jochen

    1) http://www.amazon.com/MPLS-Fundamentals-Luc-Ghein/dp/1587051974

  • It's pretty easy when you say the full words.

     

    Route Target = what VPN is this route getting into? i.e. the target of the route.

    Route Distinguisher = How can I distinguish between 2 different routes in the core? How do I make them unique?

  • So RD is only used when PE transfer data to CE. it is used in PE locally.

    RT is used when PE transfer data to PE.it is used entire MPLS network.

    relationship between PE and CE is configured at PE.

    Is my understanding correct?

  • No, they are not  used in the communication with the CE. They are used in MPBGP which runs between the PEs.

    The RD is added to the prefix so that the NLRI becomes something like 65000:1234:10.0.0.0/24. Then another customer could also have 10.0.0.0/24 and that becomes 65000:5678:10.0.0.0/24. So this is how the PEs can send the two same routes through BGP but still keep them unique.

    The route target is added by the PE, it's a community tagged to the route. Other PEs look at this community to see if the route should be imported to any of its locally configured VRFs.

  • why is RT needed, even though RD can decide local customer and decide PE at other side?

    It looks function of RD and RT is redundant.

  • The Route target and the route distinguisher are 2 completely separate values used in MPLS VPNs. The route target a BGP extended community attribute used to import and export VPNv4 routes from PE to PE. If R1 is a PE facing R2 who is also a PE, R1 will export an RT and if R2 has a VRF that is importing the same RT that R1 exported R2 will import that RT and receive the route. The route target is an extended community used to control what enters or exits a VRF table on a PE. It is for PE to PE traffic for incoming and outgoing routes. An exception is VPNv4 Route reflection, another topic altogether.

    The route distinguisher on the other hand is a MP-BGP specific value used to make a route unique or distinguish it. By prepending the RD to a customer route the SP is able to separate customer A traffic from customer B traffic. Most customers I work with that use L3 VPN use the 10.0.0.0/8 range, therefore the RD is used to make the routes unique.

    The common confusion is that both the RD and the RT can have the exact same format. But the have 2 completely different functions. One important thing that helped me was this, came from the MPLS ATC:
    This minimum configuration is called “VRF Lite”
    I.e. VRFs without any MPLS config
    VRFs do not always mean MPLS
    MPLS does not always mean VRFs

    I could start digging into VRFs and load balancing MPLS over multiple PEs with unique RDs but that would complicate it. What you must fundamentally understand, presuming your after CCIE, is how each technology works and what its purpose is. If you still think that RD and RT are redundant you will have a difficult time getting any MPLS deployment up and running. 

    To give you an example of the differences think of it like this, I recently was asked by a customer how MPLS L3 VPN works. With MPLS it's provider dependent, a VRF is created for your routes, an RD is generated to make your routes different than everybody elses. The RT is per PE, to determine which PE you may or may not send VPNv4 traffic to or from. You can a full mesh where all PEs close to your locations will import and export RTs to enable a full mesh. A hub and spoke where the HQ peered PE would import and export all the spoke PE RTs, the spoke peered PEs would export their RTs to the hub PE but only import the HQ peered PE RT. Then you could go partial mesh and mix and match based on your needs. The Hub and spoke, central services VPN, is typical for MSPs that monitor networks devices.

    The company I am consulting at now has 305 sites globally and MPLS VPN is their primary WAN connection. They have a partial mesh where the US and UK sites send and receive traffic for everything but all of the other regions just import and export traffic to the the US and UK sites

    If you have access to the CCIE v5 ATC, Brian explains how this works pretty well, I would recommend going through the videos.

    HTH
    Rob 


    On Sunday, January 18, 2015 1:06 AM, trickyfool <[email protected]> wrote:


    why is RT needed, even though RD can decide local customer and decide PE at other side?

    It looks function of RD and RT is redundant.



    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx


  • Little bit clear compare to before.

    1.RD is added to IP and it will make unique VPNv4 prefix.
    2.By above unique VPNv4 prefix, MPBGP can understand each IP uniquely.
    3.RT is added to MPBGP attirubute and used when PE sends traffic to other PE.
    4.PE router will see both RD and RT when it received packet from other PE,
    originally from other CE not connected this PE. And will send it proper interface.

    Am I right?

  • Little bit clear compare to before.
    1.RD is added to IP and it will make unique VPNv4 prefix.

    Correct, the RD is a 64 bit value prepended to an IPv4 address from the customer, making the VPNv4 route a 96 bit address.

    2.By above unique VPNv4 prefix, MPBGP can understand each IP uniquely.

    Correct, the PEs would see the route as 1.1.1.1:1:10.1.1.1/24 for example

    3.RT is added to MPBGP attirubute and used when PE sends traffic to other PE.

    Don't confuse MP_BGP for BGP extended communities activated under an address family. The RT is used by BGP to import and export routes from PEs. If a PE receives a VPNv4 route and does not have a route target locally configured that matches the one seen int eh VPNv4 update, it will be dropped. 

    4.PE router will see both RD and RT when it received packet from other PE,
    originally from other CE not connected this PE. And will send it proper interface.
    Am I right?

    When the CE sends a route update to the PE it's connected to, the PE has a VRF configured with an RD and RT value. The RD is specific to the customer, the RT is unique to the PE, these values are added to the IPv4 route the customer just sent in. As the route is checked against the RIB and FIB, since the outgoing interface is label forwarded, the CEF process then switches the packet to the outgoing interface to have a label imposed or push in between the layer 2 and 3 headers. This is why L3 VPN is considered a layer 2.5 encap. At this point the label forwarded packet is now ready to head over the Provider core and is MPLS forwarded through the core. The P routers, not running BGP just IGP and LDP forward the labeled prefix. The destination PE receives this route, the RIB sees the destination and signals CEF to switch it to the outgoing interface, which is not MPLS, therefore the label is removed or dispositioned or popped and the traffic is forward to the customer as IP.

    Now, the above is high level look at it. The customer sees this: trace to the remote CE device, the PE receives the packet as described above. you will see 2 labels added to the route, a transport label and a VPN label. The transport label should change on a per hop basis through the providers core, the VPN label should remain the same as the VPN label is a label bound to an individual route the customer advertised to the provider. The P router one hop before the PE destination should perform PHP or penultimate hop popping which is the transport label removal as the route is forwarded to the PE via IP. The VPN label is there and is removed by the PE before heading to the customer. The PHP process is used to make the MPLS forwarding more efficient and doesn't have any effects unless you need QoS markings to be end to end over MPLS. Then removing PHP will allow QoS markings from reaching PE to PE without being stripped off. 

    Hopefully that clarifies it for you. Again, the MPLS section in the ATC is covered to this detail with live demos, i recommend it as that's how I learned how this stuff works. Brian's explanation helped a lot, makes MPLS tshooting really easy.

    HTH
    Rob


    On Wednesday, January 21, 2015 5:30 AM, trickyfool <[email protected]> wrote:


    Little bit clear compare to before.

    1.RD is added to IP and it will make unique VPNv4 prefix.
    2.By above unique VPNv4 prefix, MPBGP can understand each IP uniquely.
    3.RT is added to MPBGP attirubute and used when PE sends traffic to other PE.
    4.PE router will see both RD and RT when it received packet from other PE,
    originally from other CE not connected this PE. And will send it proper interface.

    Am I right?



    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx



  • rriker and daniel.dib,

    Thank you

    Now I under stand outline of MPLS.

    I will check INE video later.

     

  • The difference is clear, thanks to all of you, but I don't understand why noone who is trying to explain the difference ever tries to explain why we need RT if RD already uniquely identifies the prefix? Why can't the prefix that has RD prepended to it be used to simply import it into a VRF or export it out of a VRF? Why another parameter in the form of extended BGP community RT is needed at all?

  • @Martinl what do you mean by you do not have to export or import all routes? If you use route-target export 2:1 at site A and then import them using route-target import 2:1 aren't you importing all routes from vrf SITE_A into vrf SITE_B? Why this needs to be done using extended BGP community RT? Why RT is introduced for doing this? They could've just used RD to achieve the same purpose.

  • JoeMJoeM ✭✭✭

    Hello NetworkSoda,
    This is one of those things that you just need to accept, as it will drastically ease your efforts of troubleshooting or designing. This is just how it was designed.

    **RD ** is locally significant to the local VRF instance and router. As Martinl showed in his example above, the RD can be different on all of the routers exchanging prefixes between themselves.

    **RT ** is how the router will pick and choose which routes are exported or imported.

    Route-Distinguisher
    vs
    Route-TARGET

  • @JoeM I am going to blindly take your word on it as what you stated is the only thing that makes any sense as of now.

    @Martinl it still doesn't make sense as to why you cannot do the same using RD because it already identifies the prefix uniquely

  • @JoeM @Martinl I just realized that the actual difference between RD and RT is that RD is used to uniquely identify a customer prefix whereas and RT is used to uniquely identify a customer site within an MPLS L3 VPN. As simple as that. Its like first identify a prefix uniquely by tagging it with the RD and then further identify what site it belongs to also uniquely by tagging it with the RT. Its just that generally all customer sites are tagged with the same RT, thats why the confusion. So basically with RT's you can distinguish the same prefix uniquely between two different sites that belong to the same customer.

  • JoeMJoeM ✭✭✭

    Maybe an instructor has thoughts on this. I only think of RT's as a way to trade prefixes. Export and Import with TARGETS between the PE's.

    • EXPORT a single RT from us to the mpls network (we can use whatever number we like)
    • IMPORT one or more RT's from the mpls network (from one or more locations)

    import/export strategies are with the RT.

  • @JoeM I think the answer is that RD is applied/prepended to all prefixes within a VPN/VRF. But RT is applied/tagged to each BGP UPDATE message which groups all those MP_REACH_NLRIs (VPNv4 addresses) together. This gives us the ability to advertise the same set of VPNv4 addresses with different RTs which would be required in certain special situations. RD cannot be used in the same way because RD is applied/prepended to individual prefixes and not the BGP UPDATE message as a whole.

    So basically with RT you can advertise the same set of information differently. The information in our case is the collection of VPNv4 addresses which are formed using RD. RT just tags the collection differently every time you use the export statement. This ability to bunch information and advertise differently everytime is not possible only using RD.

  • peetypeety ✭✭✭

    JoeM begged me to come back and chime in here.

    Gotta have an RD for the VRF to function; some platforms require that. The VRF creates VPNv4 routes in its tables from the RD plus 16 bits of magic sauce plus 32 bits of network to create a 96-bit route entry (with a mask). BGP can toss that into MP-BGP, but that entry alone doesn't carry any information about what VRF(s) that route belongs to.

    The RT gets translated into an extended-community, and that's where the PEs make the association between VPNv4 and VRF. At the originating PE, the VPNv4 route gains an extended community for each export tag. At the destination PE, the VPNv4 route is deposited into VRFs that have import matches for those extended communities.

    RD exists to distinguish the routes, which can be very useful in multipath situations, particularly with route reflection in use. RT exists to associate routes to/from VRFs, which can be very useful in VPN overlay scenarios.

  • JoeMJoeM ✭✭✭

    haha Peety, you didn't have to tell everyone that I "begged". lol

    Glad to see you back. Really appreciate your input on this. I knew you were the right guy. Thanks!

Sign In or Register to comment.