Enhance your Career in Networking With IPinBits!!!​

MPLS : Route-Target

We already saw how RD works previously, if you want to read once more click here –> RD article, lets move to Route-Target or RT, why we need and what is the significance of it.

  • Route-Target or RT, is also 64-bit extended community, which is used by MPBGP, to export/import VPNV4 prefixes.
  • RT also uses the format ASN: NN, similar to RD.
  • RT is exchanged in MP-BGP, while sending update messages.
  • Once the RT is configured in the VRF’s, in MP-BGP, we need to activate extended communities and send.
  • We will check the configuration in our L3 VPN config article which will be coming soon as well.

Significance of Route-Target:

Let’s take the same topology of MPLS to understand better.

Let’s take the same topology to understand better.

  • RT works with the control plane with MP-BGP.
  • Above you can see the VRF A and VRF B has the customer prefixes, these prefixes are used by MPBGP which works as transport protocol between PE-PE to carry VPNV4 prefixes, RD makes them unique.
  • Now the question is once these prefixes are exported from “VRF to MPBGP”, how does the remote PE router know which VRF its needs to export, or who wants this prefix, obviously we know the relevant PE’s where this customer are connected needs this.
  • This is where RT comes into the picture, now carefully read this line most important part:

“VRF Routes / VPNV4 routes (96 Bits prefixes) are exported into MP-BGP (on same PE)

MP-BGP carries this VPNV4 route inside ISP, RT is also send as part of Extended Communities

Remote PE once its receives the VPNV4 Prefix via MPBGP, matches the RT (Received with the NLRI prefix), against its own VRF, once the RT is matched, its export the route to exact VRF where the match occurred.

  • So basically, RT is used when there is PE-PE route exchange from VRF-to MPBGP and MP-BGP to VRF (Interview question).
  • Let’s check our lab topology, to verify the above theory.
  • We have two VRF’s, R-1-PE1 has sent the routes (1:1:11.11.11.0 , 1:2:11.11.11.0 –96 bits) to R-5-PE2, now the question is how would R-5-PE2 now which VRF it needs to export, so here is where RT plays an important role.
  • R-5-PE2 will match RT which was sent with the above routes against the VRF’s if it finds the exact match it will export to that particular VRF’s.
  • Make sure the import and export of one customer VRF matches the other side import export VRF’s then only the routes will be propagated into the VRF’s
  • Lets check in the lab the above same thing, R-1-PE1 has send two same prefixes i.e

10.0.0.0/24 + RD 1:1 (VPNV4) + Extended Community ( both import/export 1:1)

10.0.0.0/24 + RD 1:2 (VPNV4). + Extended Community (both import/export 1:2)

Now R1-PE1 will send this VPNV4 prefixes along, R-5-PE2 receives this VPNV4 prefixes via MPBGP, R-5PE2 will match the above RT against the VRF’s and places them accordingly to the respective VRF.

R-1-PE1#show ip bgp vpnv4 all 10.0.0.0/24   
BGP routing table entry for 1:1:10.0.0.0/24, version 6
Paths: (2 available, best #1, table Customer-A-Site1)
  Advertised to update-groups:
     7          5         
  Refresh Epoch 1
  65000
    10.0.0.2 (via vrf Customer-A-Site1) from 10.0.0.2 (111.111.111.1)
      Origin IGP, metric 0, localpref 100, valid, external
      Extended Community: RT:1:1
      mpls labels in/out 110/nolabel
      rx pathid: 0, tx pathid: 0
BGP routing table entry for 1:2:10.0.0.0/24, version 4
Paths: (1 available, best #1, table Customer-B-Site1, RIB-failure(17))
  Advertised to update-groups:
     5         
  Refresh Epoch 1
  65100
    10.0.0.2 (via vrf Customer-B-Site1) from 10.0.0.2 (31.31.31.1)
      Origin IGP, metric 0, localpref 100, valid, external, best
      Extended Community: RT:1:2
      mpls labels in/out 113/nolabel
      rx pathid: 0, tx pathid: 0x0
R-5-PE2#show ip bgp vpnv4 all 10.0.0.0
BGP routing table entry for 1:1:10.0.0.0/24, version 28
Paths: (1 available, best #1, table Customer-A-Site2)
  Advertised to update-groups:
     4         
  Refresh Epoch 1
  Local
    1.1.1.1 (metric 5) (via default) from 1.1.1.1 (1.1.1.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:1:1
      mpls labels in/out nolabel/110
      rx pathid: 0, tx pathid: 0x0
BGP routing table entry for 1:2:10.0.0.0/24, version 26
Paths: (1 available, best #1, table Customer-B-Site2)
  Advertised to update-groups:
     3         
  Refresh Epoch 1
  65100
    1.1.1.1 (metric 5) (via default) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Extended Community: RT:1:2
      mpls labels in/out nolabel/113
      rx pathid: 0, tx pathid: 0x0
R-5-PE2#


Same packet capture to check how is RT sent via MPBGP to its peers in UPDATE messages as extended Communities in path attributes.

This is all about Route-target basics, stay tuned for our next article on L3 VPN packet flow !!!!!!!.

Related blog posts