Same /24 for Two Customers? VPNv4 Needs an RD and a Label
Two tenants can advertise the same /24 only because the RD gives each route its own identity. The label answers a different question: how to forward.
Two tenants both number their branch 10.50.0.0/24, and after a change one tenant's route disappears from the provider edge while the other keeps working. The simplification behind that ticket is usually dropping the route distinguisher because "the label already identifies the customer". It does not. The RD and the label answer two different questions, and the gap only becomes visible when overlapping addresses force it.
One route where there should be two
Plain IPv4 unicast compares two paths to the same prefix and installs the better one. 10.50.0.0/24 from tenant A and 10.50.0.0/24 from tenant B are one key, so one wins and the other survives only as a backup path. The protocol did what it was told; the control plane was asked to store two different routes under a single identifier.
The result looks like a missing route rather than an error: the PE that lost the contest still forwards its own tenant locally, so an intra-site ping succeeds and the inter-site test fails. Count the entries for that prefix in the VPNv4 table before touching any policy.
The RD turns one key into two
An eight-byte route distinguisher is prepended to the IPv4 prefix, and the object that BGP carries becomes a VPN-IPv4 address instead of an IPv4 prefix. Two tenants can hold the same 32 bits because the 64 bits in front differ. Format types exist for an AS-based RD and for an address-based one, and the choice belongs to the originating PE. An AS-based RD is common when the PEs share an AS, an address-based one when they do not.
Do not read the RD as a membership tag. Route targets govern import and export, and they decide which VRFs may install the route; the RD only guarantees that the route has an identity of its own. Giving each VRF its own RD is the common practice because it keeps that mapping readable in a looking glass.
The label is a local forwarding instruction
Every advertisement also carries an MPLS label, and its meaning is scoped to the router that allocated it. Another PE may hand out the same number for an unrelated destination. That is exactly why the label cannot stand in for customer identity: the number is only correct next to the next hop and the forwarding state that installed it.
Allocation granularity varies with implementation and design: some platforms assign one label per VRF, others per prefix, and the label may identify a forwarding action rather than a customer. Two different labels reaching the same destination are not a contradiction, and the same label number at two PEs is not either.
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
Why one cannot replace the other
Reading an advertisement means looking at four things together: the RD-qualified prefix, the route targets, the next hop and the label. Reading a user packet means looking at the stack that was installed from that information. A healthy design shows both sides matching, and a broken one usually has one side right and the other stale. That comparison separates an identity problem from a forwarding problem.
The tidy contrast between control plane and data plane is a teaching device, not a description of the encoding. RFC 8277 puts the label inside the labeled NLRI, so the advertisement itself carries the binding; using it for forwarding is the later, separate step.
When a tenant route goes missing, check in this order: two VPNv4 entries for the prefix, the correct route target on each, a resolvable next hop, and a label that the receiving PE has state for. Fixing identity with a forwarding value, or the reverse, will pass one check and fail the next.