↓ Skip to main content
KAZULOG.INFO
  1. Network Articles/
  2. MPLS-VPN Articles/

MPLS VPN RD (Route Distinguisher)

Table of Contents

What an RD Is in MPLS VPN

An RD (Route Distinguisher) is an 8-byte value prepended to an IPv4 prefix to make it unique. Section 4.1 of RFC 4364 defines a VPN-IPv4 address as an 8-byte RD followed by a 4-byte IPv4 address, 12 bytes in total.

An RD is needed because overlapping customer addresses still have to be distinct prefixes inside BGP. Customer A’s 10.1.1.0/24 and customer B’s 10.1.1.0/24 are the same prefix as far as BGP is concerned, and only one of them would survive. With RDs they become 65001:1:10.1.1.0/24 and 65001:2:10.1.1.0/24, and both can exist.

An RD does not identify a VPN. Section 4.1 of RFC 4364 puts it this way:

An RD is simply a number, and it does not contain any inherent information; it does not identify the origin of the route or the set of VPNs to which the route is to be distributed. The purpose of the RD is solely to allow one to create distinct routes to a common IPv4 address prefix.

What decides which VRF a route goes to is the RT (Route Target), and the lab below demonstrates the difference. The RT itself is covered in MPLS VPN RT.

The RD Types (0, 1, and 2)

An RD is a 2-byte Type followed by a 6-byte Value, and the type decides how those six bytes are split (RFC 4364, section 4.2).

TypeValue layoutExampleWhere it fits
02-byte AS number + 4-byte number65001:1Providers with a two-octet AS number. The most common
14-byte IP address + 2-byte number1.1.1.1:2When a router’s address is used to keep values distinct per device
24-byte AS number + 2-byte number4259905537:1Providers with a four-octet AS number

The type makes no functional difference. All that matters is that the value is unique; its contents carry no meaning. Section 4.2 explains that this structure lets every service provider administer its own numbering space without colliding with anyone else’s.

Configuring an RD on IOS XR

On IOS XR the RD is configured under router bgp, per VRF. It does not go under the VRF definition (vrf <name>).

Configuring an RD (IOS XR)
router bgp 65001
 vrf CUST-A
  rd 65001:1
  address-family ipv4 unicast
   redistribute static
  !
 !
!

There are three ways to write the value.

FormMeaning
rd <AS number>:<number>Type 0 (or type 2 with a four-octet AS number)
rd <IP address>:<number>Type 1
rd autoAssigns the router ID plus a number counting up from 0

Because rd auto uses the router ID, the same VPN ends up with a different RD on each PE. Whether that is a good design is covered in MPLS VPN RD design.

Without an RD the routes of a VRF never reach MP-BGP. Conversely, creating a VRF on its own needs no RD at all (MPLS VPN VRF).

An RD Cannot Be Changed Later

An RD can be neither changed nor removed while the address family of that VRF is active. IOS XR rejects the attempt:

The error when changing an RD
!!% 'BGP' detected the 'warning' condition 'The RD cannot be changed or removed while a VRF address family is active'

Changing it therefore means removing the address family, changing the RD, and putting the address family back. And because an IOS XR commit is pseudo-atomic, that sequence cannot be done in a single commit (the final state still has an active address family, so it is rejected for the same reason). Two commits are required.

While the address family is gone, the routes of that VRF disappear from MP-BGP and traffic stops. An RD is not a value to change casually once the service is running; it belongs in the design.

Lab Setup

Eight XRd routers, with customer A and customer B using exactly the same addresses — not only the LANs but the PE-CE links too.

NodeRole
PE1 / PE2Hold VRF CUST-A (RD 65001:1) and CUST-B (RD 65001:2). The RTs are 65001:100 and 65001:200
P1 / P2Core only (OSPF area 0 + LDP). They run no BGP
CE-A1 / CE-B1Site 1. Both use LAN 10.1.1.0/24 and 172.16.1.2 towards the PE
CE-A2 / CE-B2Site 2. Both use LAN 10.1.2.0/24 and 172.16.2.2 towards the PE

PE-CE routing is static, redistributed into the VRF’s BGP with redistribute static. The RTs never change; only the RDs move.

STEPActionWhat it shows
0Initial stateThe same 10.1.1.0/24 under two RDs. The P routers hold no VPN routes
1Try to change the RD of CUST-B on PE1It is rejected
2Remove the address family of CUST-BCustomer B’s traffic stops
3Set a type 1 RD (1.1.1.1:2) and restore the address familyTraffic recovers. A different RD still reaches the VRF because the RT matches
4Remove the address family again(preparation for rd auto)
5Switch to rd autoRouter ID plus 0 is assigned automatically

The Same Prefix Split by RD (STEP 0)

The BGP table on PE1 is grouped by RD.

STEP 0: show bgp vpnv4 unicast on PE1
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:1 (default for vrf CUST-A)
Route Distinguisher Version: 14
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?
Route Distinguisher: 65001:2 (default for vrf CUST-B)
Route Distinguisher Version: 15
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?

Processed 4 prefixes, 4 paths

10.1.1.0/24 and 10.1.2.0/24 each appear twice, and the total is Processed 4 prefixes. To BGP these are four separate prefixes that differ only in their RD. The (default for vrf CUST-A) note says which VRF that RD belongs to.

The P routers in the core run no BGP at all.

STEP 0: looking at the VPNv4 table on P1
RP/0/RP0/CPU0:P1#show bgp vpnv4 unicast
Sun Sep 20 06:27:01.056 UTC
% BGP instance 'default' not active

The packets show the same thing. In a VPNv4 UPDATE between PE1 and P1, the RD and the label sit inside the MP_REACH_NLRI.

STEP 0: a VPNv4 UPDATE (excerpt from tshark -V)
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
                1... .... = Optional: Set
                .0.. .... = Transitive: Not set
                ..0. .... = Partial: Not set
                ...1 .... = Extended-Length: Set
                .... 0000 = Unused: 0x0
            Type Code: MP_REACH_NLRI (14)
            Length: 32
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Labeled VPN Unicast (128)
            Next hop:  RD=0:0 IPv4=2.2.2.2
                Route Distinguisher: 0:0
                IPv4 Address: 2.2.2.2
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                BGP Prefix
                    Prefix Length: 112
                    Label Stack: 24005 (bottom)
                    Route Distinguisher: 65001:1
                    MP Reach NLRI IPv4 prefix: 10.1.2.0
Download the pcap of the packet in the tshark output above (a type 0 RD)

An RD is part of the NLRI, not a path attribute. It travels as part of the prefix itself rather than as information attached to the route.

Rejected, and Not Changeable Without an Outage (STEP 1 and 2)

In STEP 1, changing the RD of CUST-B on PE1 to 1.1.1.1:2 fails to commit.

STEP 1: the output of show configuration failed
RP/0/RP0/CPU0:PE1(config)#show configuration failed
Sun Sep 20 06:31:37.073 UTC
!! SEMANTIC ERRORS: This configuration was rejected by 
!! the system due to semantic errors. The individual 
!! errors with each failed configuration command can be 
!! found below.


router bgp 65001
 vrf CUST-B
  rd 1.1.1.1:2
!!% 'BGP' detected the 'warning' condition 'The RD cannot be changed or removed while a VRF address family is active'
 !
!
end

In STEP 2 the address family is removed, and customer B’s traffic stops.

STEP 2: reachability from CE-B1 to the other site of customer B
RP/0/RP0/CPU0:CE-B1#ping 10.1.2.1 source 10.1.1.1 count 50 timeout 1
Sun Sep 20 09:06:57.309 UTC
Type escape sequence to abort.
Sending 50, 100-byte ICMP Echos to 10.1.2.1 timeout is 1 seconds:
..................................................
Success rate is 0 percent (0/50)

Customer A is unaffected. Only the VRF that was touched goes down.

A Different RD Still Works if the RT Matches (STEP 3)

STEP 3 sets the type 1 RD 1.1.1.1:2 and restores the address family. Only CUST-B on PE1 was changed; CUST-B on PE2 still uses 65001:2.

STEP 3: the BGP table on PE1 (mixed RDs)
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:1 (default for vrf CUST-A)
Route Distinguisher Version: 14
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?
Route Distinguisher: 65001:2
Route Distinguisher Version: 18
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?
Route Distinguisher: 1.1.1.1:2 (default for vrf CUST-B)
Route Distinguisher Version: 20
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?

Processed 5 prefixes, 5 paths

The routes PE1 advertises carry the new RD (1.1.1.1:2) and the routes it receives from PE2 carry the original one (65001:2); both sit in the same table under different RDs. Customer B’s traffic recovers all the same.

That is because a route is imported when the RT matches, whatever the RD is. Distribution is decided by the RT, not by the RD — exactly what the text from RFC 4364 quoted above says, now visible on a live device.

The RD in the packets changes to the type 1 form as well.

STEP 3: a VPNv4 UPDATE (excerpt from tshark -V)
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
                1... .... = Optional: Set
                .0.. .... = Transitive: Not set
                ..0. .... = Partial: Not set
                ...1 .... = Extended-Length: Set
                .... 0000 = Unused: 0x0
            Type Code: MP_REACH_NLRI (14)
            Length: 32
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Labeled VPN Unicast (128)
            Next hop:  RD=0:0 IPv4=1.1.1.1
                Route Distinguisher: 0:0
                IPv4 Address: 1.1.1.1
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                BGP Prefix
                    Prefix Length: 112
                    Label Stack: 24006 (bottom)
                    Route Distinguisher: 1.1.1.1:2
                    MP Reach NLRI IPv4 prefix: 10.1.1.0
Download the pcap of the packet in the tshark output above (a type 1 RD)

rd auto Counts From Router ID Plus 0 (STEP 5)

STEP 4 removes the address family once more, and STEP 5 switches to rd auto.

STEP 5: the BGP table on PE1
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 65001:1 (default for vrf CUST-A)
Route Distinguisher Version: 14
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?
Route Distinguisher: 65001:2
Route Distinguisher Version: 18
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?
Route Distinguisher: 1.1.1.1:0 (default for vrf CUST-B)
Route Distinguisher Version: 25
*> 10.1.1.0/24        172.16.1.2               0         32768 ?
*>i10.1.2.0/24        2.2.2.2                  0    100      0 ?

Processed 5 prefixes, 5 paths

PE1’s router ID is 1.1.1.1 and the numbering starts at 0. Because auto uses the router ID, the same VPN gets a different RD on every PE.

STEP 5: a VPNv4 UPDATE (excerpt from tshark -V)
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
                1... .... = Optional: Set
                .0.. .... = Transitive: Not set
                ..0. .... = Partial: Not set
                ...1 .... = Extended-Length: Set
                .... 0000 = Unused: 0x0
            Type Code: MP_REACH_NLRI (14)
            Length: 32
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Labeled VPN Unicast (128)
            Next hop:  RD=0:0 IPv4=1.1.1.1
                Route Distinguisher: 0:0
                IPv4 Address: 1.1.1.1
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                BGP Prefix
                    Prefix Length: 112
                    Label Stack: 24006 (bottom)
                    Route Distinguisher: 1.1.1.1:0
                    MP Reach NLRI IPv4 prefix: 10.1.1.0
Download the pcap of the packet in the tshark output above (an RD from rd auto)

Whether to keep one RD per VRF or to use a different one per PE is a design choice. Splitting them lets a route reflector keep more than one path, at the cost of more routes to hold. That trade-off is covered in MPLS VPN RD design.

Verification Config and show Output

For every STEP, the following files were collected from all eight routers, split per router. The verification config is the ..._run.txt file (the final state is the one from the last STEP).

FileContent
..._show.txtshow version, show interface description, show route, plus VPNv4 and VRF commands on the PEs, core commands on the P routers, and routing tables on the CEs
..._ping.txtThe ping and traceroute results for that STEP
..._log.txtshow logging limited to that STEP
..._run.txtshow running-config at that STEP (that is, the verification config)
..._commit.cfgThe configuration committed in that STEP (only for routers that were changed)
..._failed.cfgThe rejected configuration and its error (STEP 1 only)

STEP 0: initial state (CUST-A uses rd 65001:1, CUST-B uses rd 65001:2)

Routershowpingsyslogrunning-config
PE1showpinglogrun
PE2showpinglogrun
P1showpinglogrun
P2showpinglogrun
CE-A1showpinglogrun
CE-A2showpinglogrun
CE-B1showpinglogrun
CE-B2showpinglogrun

STEP 1: the RD change is rejected

Routershowpingsyslogrunning-configrejected
PE1showpinglogrunfailed
PE2showpinglogrun—
P1showpinglogrun—
P2showpinglogrun—
CE-A1showpinglogrun—
CE-A2showpinglogrun—
CE-B1showpinglogrun—
CE-B2showpinglogrun—

STEP 2: remove the address family of CUST-B (customer B’s traffic stops)

Routershowpingsyslogrunning-configcommitted
PE1showpinglogruncommit
PE2showpinglogrun—
P1showpinglogrun—
P2showpinglogrun—
CE-A1showpinglogrun—
CE-A2showpinglogrun—
CE-B1showpinglogrun—
CE-B2showpinglogrun—

STEP 3: set a type 1 RD and restore the address family

Routershowpingsyslogrunning-configcommitted
PE1showpinglogruncommit
PE2showpinglogrun—
P1showpinglogrun—
P2showpinglogrun—
CE-A1showpinglogrun—
CE-A2showpinglogrun—
CE-B1showpinglogrun—
CE-B2showpinglogrun—

STEP 4: remove the address family again

Routershowpingsyslogrunning-configcommitted
PE1showpinglogruncommit
PE2showpinglogrun—
P1showpinglogrun—
P2showpinglogrun—
CE-A1showpinglogrun—
CE-A2showpinglogrun—
CE-B1showpinglogrun—
CE-B2showpinglogrun—

STEP 5: switch to rd auto (final state)

Routershowpingsyslogrunning-configcommitted
PE1showpinglogruncommit
PE2showpinglogrun—
P1showpinglogrun—
P2showpinglogrun—
CE-A1showpinglogrun—
CE-A2showpinglogrun—
CE-B1showpinglogrun—
CE-B2showpinglogrun—

The packet capture was taken on the PE1-P1 link across all the STEPs.

Download the full capture from the PE1-P1 link

References

RFCTitleSummary
RFC 4364BGP/MPLS IP Virtual Private Networks (VPNs)VPN-IPv4 addresses and the RD (4.1), RD types 0, 1 and 2 (4.2), and the RT deciding distribution (4.3.1)
RFC 4760Multiprotocol Extensions for BGP-4The MP_REACH_NLRI that carries VPNv4 prefixes

Books: Luc De Ghein, MPLS Fundamentals (Cisco Press, 2006), Chapter 7; Mobeen Tahir et al., Cisco IOS XR Fundamentals (Cisco Press, 2009), Chapter 9

Test environment: Cisco IOS XRd 26.1.1 (Cisco Modeling Labs)

Related Articles