Why one EVPN tenant can show several route distinguishers
Two RDs in one tenant are not a conflict. Walk from the CLI output to the MAC-VRF or IP-VRF that originated the route, then check RT import and VNI.
You filter the EVPN table for one tenant, and the routes carry two different route distinguishers. The first instinct is a configuration conflict, and that instinct is usually wrong. A tenant name is a business label, not a single control-plane object, so the bridging context and the routing context inside it can legitimately advertise under separate identifiers. Walk one route at a time from the output back to the local service object that originated it, and the second RD stops looking like a mistake.
Start at the output that confused you
Pick one route rather than the whole table. Note its route type, its RD, its exported route targets, and the next hop. Those four fields are enough to identify which local object advertised it and which remote policy should import it.
On a NX-OS-style device the detail view is reached with show bgp l2vpn evpn route-type 2 detail or show bgp l2vpn evpn route-type 5 detail. On Junos the same information lives in show route table bgp.evpn.0 detail. Different syntax, same fields.
Do not start by making every displayed number equal. Equalising RDs is the change that breaks import policy on a working fabric.
Give each identifier its job
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
A MAC-VRF holds MAC forwarding information for a bridging service. An IP-VRF supplies an IP routing context for a routed service. A tenant can include both, which is why one tenant can produce more than one RD without any misconfiguration.
RFC 7432 assigns the advertising MAC-VRF's RD to its EVPN NLRI and requires distinct RDs across MAC-VRFs on the same PE. Route-target procedures are separate: they allow one or more RT attributes and rely on import policy for membership. RD equality is not what creates shared membership, and treating it that way is the root of this confusion.
Walk one route from advertisement to import
Follow the route in one direction. Confirm the route type, the originating service, the RD, the exported RTs, and then the import policy on the receiving PE. Each step answers a different question, and a failure at any step looks like the same missing prefix on the far side.
Once the route is present, inspect the installed forwarding context and the VNI mapping. Matching a VNI on both ends demonstrates that the data plane agrees; it does not demonstrate that the control plane imported the route through the intended policy.
If the route appears on the remote PE but no traffic flows, the problem has moved past EVPN. Check the VNI-to-VLAN or VNI-to-VRF binding and the underlay path before editing route targets again. Start at the mapping, then the underlay, and only then the control plane. Reverting a route-target change to chase a data-plane fault is a reliable way to break a working import.
Layer 3 prefixes are still EVPN routes
An IP prefix in the EVPN table is not ordinary IPv4-unicast BGP. The EVPN IP Prefix route is its own route type, and MAC/IP plus IP-prefix advertisements travel in the EVPN address family, which RFC 7432 identifies as AFI 25 and SAFI 70.
That distinction matters when you compare a route in the EVPN table with one in the unicast table. They can describe the same destination and still be produced, filtered and imported by different policy. Reading one as evidence about the other is how a correct fabric looks broken during a migration.
Check the vendor's derivation before comparing numbers
RFC 9136 extends EVPN with IP Prefix routes and specifies whether the applicable RD comes from the MAC-VRF or the IP-VRF context. That is why an L2 service label and a routed service label in the same output should be read against the objects they belong to, not reduced to one RD per tenant.
Automatic RD and RT derivation is vendor-specific. Read the deployed vendor's reference for the formula in use; an auto-generated value seen on one switch is not a universal encoding, and comparing two vendors' numbers rarely proves anything.
Finish with a written trace for the route you started with: type, originating object, RD, exported RT, importing policy, installed VNI. Six fields explain the advertisement to whoever reads the ticket next, and none of them requires making the tenant's numbers match.