RD vs RT in an MPLS VPN: uniqueness versus import policy

A route distinguisher makes overlapping prefixes distinct; a route target controls which routes a VRF may import. Follow one MPLS route through both roles.

Two customer sites can advertise 10.20.0.0/24 and both remain valid inside one provider network. The route distinguisher keeps those advertisements distinct; the route target decides which customer VRF may take a copy. They appear next to each other in configuration and do completely different jobs. Confusing the two leads to changes that look reasonable and fix nothing.

Follow one route from the customer edge to a remote VRF and the division becomes concrete: identity is attached before the route enters BGP, and distribution policy is evaluated when the route reaches the receiving provider edge.

A VPN-IPv4 route is an RD plus an IPv4 prefix

RFC 4364 defines the VPN-IPv4 address family as an eight-byte route distinguisher followed by a four-byte IPv4 address. The RD is prepended to the customer prefix, so two identical prefixes from different sites become two different BGP routes.

That construction is the whole uniqueness mechanism. The provider does not need the customers to agree on non-overlapping address space, and a route from one site cannot silently replace an identical prefix from another site.

The RD format itself is an administrator-chosen value, commonly an autonomous system number and a local number. Its numeric shape is a convention, not a signal that the two fields share a meaning with a route target that happens to use the same digits.

The RD makes overlapping prefixes distinguishable

Consider two advertisements for the same prefix. Site A carries RD 65000:101 and Site B carries RD 65000:202, both for 10.20.0.0/24. BGP now holds two VPN-IPv4 routes that can be compared, filtered and selected independently.

The RD does not say which VRF should receive either route, and it does not identify a customer or a service. It is an identity field for the route, not a membership list. A VRF's own RD has no requirement to match the RD of a route it imports.

This is why changing an RD to match another site's number fixes nothing. If a route is missing on the far side, matching the digits creates a different identity problem rather than repairing the import decision.

The RT is a BGP attribute, not a packet tag

An export policy attaches one or more route targets to the route as BGP extended-community attributes. The receiving provider edge compares those attributes with the import policy of each VRF. The RT travels with the route through the control plane. The comparison happens entirely in routing policy, before any customer packet is forwarded.

Customer data packets do not carry the RT. Once a route is installed in a VRF, forwarding uses that VRF's table and the MPLS label stack that the architecture assigns. The provider edge is not reading a route target from each customer packet.

A route may carry several RTs, and a VRF may import several. The configuration often looks like a short block:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

Read that block as two separate statements. The export line controls what is attached to routes leaving this VRF; the import line controls what this VRF is willing to consider. Matching numbers are convenient, not mandatory.

Import eligibility is not installation

A route can be eligible for a VRF and still not appear in its forwarding table. Eligibility is a filter; the normal BGP decision process then compares eligible routes and selects one. An older or less preferred route can lose to another eligible path.

Check the selected route, not only the import policy. A VRF that imports RT 65000:500 and shows no route for 10.20.0.0/24 may have received the route and rejected it during selection, or may never have received it at all.

This distinction also matters when an unexpected prefix appears. An overly broad import policy can pull in routes the site did not intend to use, and uniqueness of the RD does nothing to prevent that. Distribution scope is an RT policy question.

Debug a missing route in control-plane order

Start with the advertisement: does the originating VRF export the intended RT, and does the route exist as a VPN-IPv4 route on the route reflector or receiving PE? Then check the attribute as received, not as configured on the sender.

Next compare the receiving VRF's import list with the route's actual RT values. Finally inspect the selected route in that VRF and the label binding. Each step answers a different question, and jumping to the RD usually skips the one that is wrong.

Record the RD, the exported RT, the imported RT and the selected next hop for the working and failing sites. Four values side by side turn a vague "the VPN is not passing routes" into the exact control-plane step that differs.

Skyldar greinar