Two PEs, One Prefix: Why the RD Decides Visibility

Two edge routers that advertise the same customer prefix describe one VPNv4 destination until something separates them, and the separator is the route distinguisher. It qualifies the prefix; it does not decide who imports the result, which is the route target's job. Allocate RDs from the set of routes that must stay distinguishable across every domain where those advertisements can meet, not from the file layout of a single box. The number you pick is an identity that later reviews will depend on, so it belongs in an inventory before it goes into a configuration.

An RD Plus a Prefix Is One Destination

An RD plus an IPv4 prefix forms the VPNv4 destination that the control plane compares. Give two PEs the same prefix for different customers and, without different RDs, they advertise paths to one destination. Nothing on a display tells you that grouping is wrong, because the platform is doing exactly what the identity says. Change the RD on one of them and the old advertisement is withdrawn while a new one appears under a different identity. Anything downstream that keyed on the old identity, from route selection to a saved operator filter, now refers to something that no longer exists.

Several paths per destination is ordinary BGP behaviour, not a symptom. A speaker can hold multiple received paths while selecting one best path for forwarding, and the gap between received and selected is where visibility questions live. When a path seems to have vanished, confirm whether the identity it belonged to still exists before you look at the session.

Same RD, Same Destination, Different Paths

Send one RD and one prefix from two routers on behalf of the same service and both are offering paths to a single destination, usually with different next hops. Which of those a route reflector passes on is a decision about the reflector: its path selection, its advertisement capability, and any policy layered over it. Neither edge router controls that choice. Give the two advertisements distinct RDs and each becomes its own destination, so both can survive a control plane that otherwise carries only the selected path for one identity.

Visibility and multipath meet in the receiving VRF, but they are not the same decision, and a reflector carrying two identities has not configured a second installed path. The VRF installs what its import policy admits and its own maximum-path setting allows. Check that setting separately when you want the second path used rather than merely visible.

A Local Uniqueness Rule Is Not a Policy

Giving every PE and routing instance its own RD is a sound convention: it names the origin, keeps unrelated services from colliding on an identity, and gives the inventory a stable key. Some platforms only require uniqueness inside the box and explicitly permit routers to share an RD for the same VPN instance. That permission is an implementation constraint, not a cross-network rule you can delegate to a vendor. If the domain spans teams, write the allocation policy yourself.

Membership never comes from the digits. A pattern such as 65000:12 for one PE and 65000:13 for another is a habit, while matching export and import targets such as 65000:112 are what put a route into a VRF. Treat the RD as the identity of a route and the route target as the permission that carries it into a VRF.

Prove the Change on the VRF, Not the Display

Before you touch an RD, write down four things: what the PE advertises today, what the reflector reflects, what the receiving VRF imports, and which path it selects. A new RD withdraws one advertisement and introduces another, so the change shows up on both sides of the session and is easy to misread if you only watch the advertising side. Acceptance should rest on the reachability you wanted, not on an extra line appearing in a prefix list. The table below keeps the three identifiers from blurring into each other during that review.

Start on the advertising PE and compare both identities for the same prefix before you remove anything. The IOS commands below answer three questions in order: is the old advertisement still there, is the new identity visible to the reflector, and does the VRF select the prefix.

show bgp vpnv4 unicast rd 65000:12 203.0.113.0/24
show bgp vpnv4 unicast rd 65000:13 203.0.113.0/24
show ip route vrf CUSTOMER-A 203.0.113.0/24

Other platforms print the same information under different syntax, and the questions survive that change. If the new identity is missing at the reflector while the PE lists it as advertised, the reflector's policy or advertisement capability is the first suspect, not the numbering.

Record the PE, instance, RD, export and import targets, and prefix ownership in one place, because the next allocation is a lookup rather than a guess only when that record exists. Keep the old RD until the new identity is visible in the receiving VRF, then withdraw it in a second step so each stage stays reversible.