An interviewer asks: What is the difference between RD and RT in MPLS L3VPN, and must they match? The short answer: a Route Distinguisher (RD) makes an IPv4 prefix distinct in the VPNv4 address family, while a Route Target (RT) is a BGP extended community used to control which VRFs are eligible to import a VPN route.[1]
RD and RT do not have to be equal, and two PEs do not need matching RDs to exchange routes for the same VPN. What matters for import eligibility is that an exported route carries an RT accepted by the receiving VRF; selection and other policy still apply.[1]
RD vs RT: the comparison to remember
This article focuses on the interview distinction, especially the misleading cases where the numbers look identical, rather than repeating a complete MPLS deployment guide.
| Question | Route Distinguisher (RD) | Route Target (RT) |
|---|---|---|
| What problem does it solve? | Distinguishes otherwise identical IPv4 prefixes in VPNv4.[1] | Controls route distribution and VRF import eligibility.[1] |
| Where does it appear? | Part of the VPNv4 address carried in routing information.[1] | An extended-community attribute attached to the route.[1] |
| Can one VPN route have several? | One RD per VPNv4 route.[1] | Multiple RTs can be attached to one route.[1] |
| Must it match a remote VRF's RD? | No; RD equality is not the import test.[1] | A route RT must match an import RT, subject to other policy and selection.[1] |
| Is it the MPLS forwarding label? | No.[1] | No.[1] |
A useful memory aid is RD = route identity; RT = route distribution policy. It is a teaching shortcut, not a statement that every VPN has exactly one identifier.
How large is an RD?
The RD is an 8-byte field, not a 32-bit field; RFC 4364 defines a VPN-IPv4 address as an 8-byte RD followed by a 4-byte IPv4 address.[1]
The familiar colon-separated display is an administrative representation, not evidence that RD and RT perform the same job.[1]
Worked example: different RDs, shared RT
The following values describe a fictional, isolated lab; they are not production configuration or captured router output.
| VRF location | Locally originated prefix | RD | Export RT | Import RT |
|---|---|---|---|---|
| BLUE on PE-A | 10.10.10.0/24 | 65000:101 | 65000:100 | 65000:100 |
| BLUE on PE-B | 10.20.20.0/24 | 65000:102 | 65000:100 | 65000:100 |
| RED on PE-A | 10.10.10.0/24 | 65000:201 | 65000:200 | 65000:200 |
BLUE and RED deliberately reuse a prefix. Their different RDs make their VPNv4 advertisements distinct, while the configured RT sets keep the routes eligible for different VRFs.[1]
For the BLUE route traveling from PE-A to PE-B, the conceptual control-plane sequence is:
- PE-A learns
10.10.10.0/24in BLUE through its configured CE-facing routing method.[1] - PE-A creates a VPNv4 advertisement using RD
65000:101, attaches export RT65000:100, and distributes a VPN label with the route.[1] - MP-BGP carries the advertisement toward PE-B, directly or through a route reflector.[1]
- PE-B's BLUE VRF accepts RT
65000:100, so the received route is eligible for import even though BLUE's local RD there is65000:102.[1] - If route selection and forwarding resolution succeed, traffic can use the resulting VRF route; the return direction needs its own usable route.[1]
Read the schematic 65000:101 + 10.10.10.0/24 as RD plus IPv4 prefix, not as an extra header attached to each customer IP packet.
What if the RT is wrong but the RD matches?
Suppose a receiving VRF imports only 65000:999, while the advertisement carries only 65000:100. The route fails this RT import test even if the receiving VRF happens to use RD 65000:101.[1]
Changing the RD to match the far end is not a repair for a missing import RT. Diagnose the policy instead of making identifiers look symmetrical.
What if two advertisements have the same RD and prefix?
They represent paths to the same VPNv4 prefix, so BGP route preference selects among them; with different RDs, they are distinct VPNv4 prefixes.[1]
This is why RD design is more than a cosmetic naming decision. Do not promise that changing the RD alone enables load balancing: distinguish keeping separate VPNv4 routes from selecting and installing paths for an IPv4 prefix inside a VRF.
Do RD or RT travel inside user packets?
In the MPLS forwarding model, the ingress PE uses the customer's VRF route and sends traffic toward the egress PE using the VPN label plus the required backbone transport encapsulation.[1]
The egress label binding determines the relevant forwarding treatment, which may involve a VRF lookup or a more specific forwarding action depending on label allocation.[1]
Neither an RD nor an RT is the MPLS label, and the core does not inspect RT communities on every customer packet to decide VPN membership.[1]
Also, VPN isolation is not encryption: the RFC explicitly states that this architecture does not by itself encrypt data or provide integrity protection.[1]
A practical verification checklist
Use this as a read-only investigation plan. The table deliberately names evidence rather than pretending one CLI syntax works across IOS XE, IOS XR and Junos.
| Check | Evidence to capture | Question it answers |
|---|---|---|
| Source VRF | Exact prefix, mask, selected route and CE next hop | Did the source PE learn the intended route? |
| Source VPNv4 advertisement | RD, prefix, exported RTs, VPN label and BGP next hop | What identity and policy actually left the source? |
| Destination VPNv4 view | The same RD/prefix and received extended communities | Did the advertisement reach the receiving PE? |
| Destination VRF policy | Import RTs and additional filters | Is that route eligible for this VRF? |
| Destination routing/forwarding | Selected IPv4 route, resolved next hop and label transport | Can the PE actually forward it? |
| Reverse path | Corresponding evidence for the return prefix | Is connectivity bidirectional? |
These are recommended operational checks derived from the separation of route distribution, VRF selection and forwarding in RFC 4364.[1]
If the VPNv4 route exists but the VRF route does not, investigate RT import policy and route selection before changing transport. If the route is installed but application traffic fails, investigate forwarding resolution, the reverse path and security policy rather than assuming another RT will fix it.
Safety rule: do not import every tenant RT as a quick test in production. Write down the exact prefixes that should become reachable and the VRFs that must remain isolated before approving an import-policy change.
Common interview pitfalls
- “The RD identifies which VPN can import the route.” The RD provides distinct route identities; the RT mechanism controls import eligibility.[1]
- “RD must equal RT.” Similar-looking values are a configuration convention, not a protocol requirement.[1]
- “All RTs on a route must match.” The basic eligibility test requires an intersection between the route's RTs and the VRF's import targets, not equality of the entire sets.[1]
- “A matching RT guarantees an installed route.” The route must still pass the relevant decision processes and policy.[1]
- “Different RDs solve overlapping addresses after route leaking.” Distinct VPNv4 identities do not make two unrelated systems with the same destination address unambiguous in one ordinary IPv4 forwarding context.[1]
- “Import and export targets must be identical.” They are separate sets and can differ, supporting more selective connectivity patterns.[1]
The short interview answer
An RD makes an IPv4 prefix unique in VPNv4, allowing overlapping prefixes to be carried as distinct routes.[1]
An RT is an extended community used for route distribution and VRF import eligibility; a route can have multiple RTs.[1]
RD and RT do not need to match, and different PEs can use different RDs for the same VPN while sharing the appropriate RT policy.[1]
I verify the exported RT and receiving import policy first, then route selection, forwarding and the return path—not just whether the BGP session is up.
Lab idea: change one field at a time
Use the fictional BLUE/RED table in a disposable lab. Establish baseline BLUE connectivity, then remove only BLUE's matching import RT on PE-B. Record which VPNv4 and VRF views change on your platform. Restore the policy, then change only the originating RD during a planned lab test and compare the advertised VPNv4 identity.
Treat an RD change as a routing change, not a harmless display edit. Save before/after output and observe actual convergence; no router lab was executed for this article.
Related reading
- MPLS L3VPN basics: VRFs, route targets and provider transport
- MPLS L3VPN route-target troubleshooting: missing VRF routes
- BGP neighbor states
Summary
Remember the three separate questions: Which VPNv4 route is this? Where may it be imported? How will packets be forwarded? RD, RT policy and label forwarding answer different parts of that chain.[1]
Preparing for a network engineering interview? Explain the different-RD/shared-RT example aloud, then describe what you would check if the route reached VPNv4 but never appeared in the destination VRF.
Post a Comment