Some L2VPN Routes Vanish After You Add Route Reflectors

Sessions stay up, the IGP is stable, and yet a handful of L2VPN routes never appear on two of the four provider edges. That pattern belongs to a reflection problem rather than a transport one, because a broken session fails wholesale while a reused reflection boundary fails selectively. The physical ring has nothing to do with it; the logical distribution graph is where those routes stopped. Finding that point does not require rebuilding the control plane.

The loss is selective, which narrows the search

Four provider edges on a physical ring need six logical sessions for a full mesh, since each router pairs with the other three. Those sessions ride the routed transport, so the cabling says nothing about how many adjacencies exist or which of them reflect. When two edges miss a specific set of prefixes while everything else converges, the cable is not the suspect.

Selective loss points at loop prevention, policy or relationship direction, where some routes cross a boundary and others are dropped on the way. Total loss points at the session or the address family. Deciding which of those two you are looking at is the first useful step, and it takes one command.

What reflection actually changes

Route reflection relaxes the rule that an iBGP speaker may not re-advertise a route learned from another iBGP speaker. RFC 4456 expresses the exception through the relationship between the speaker and the source of the route, and the direction of that relationship matters more than most summaries suggest. A route learned from a client may be reflected to other clients and to non-clients, while a route learned from a non-client may be reflected only to clients. Read the asymmetry twice, because it explains how adding a client relationship can hide a design error: it opens a path the topology never intended to exist.

The CLUSTER_LIST attribute records reflection history, and a reflector finding its own cluster ID in that list must ignore the advertisement. That is loop prevention, and it is also the mechanism that deletes routes when identifiers are reused by accident. ORIGINATOR_ID plays a related role by naming the router that first advertised the route.

Reused cluster IDs are how routes disappear

A small network invites a shortcut: give each router a cluster ID equal to its loopback, add one more reflector later, and reuse an existing loopback because it is conveniently at hand. If that identifier now appears at two independent reflection stages, the second stage sees its own ID in CLUSTER_LIST and discards the route. Nothing logs an error, because discarding is the correct response to a loop.

Redundant reflectors serving one cluster are the legitimate exception, sharing an ID on purpose so either can serve the same clients. The identifier has to match the reflection design rather than distinguish chassis names.

Draw the intended graph before touching any configuration: who originates the prefix, which client relationship permits the first reflection, which reflector carries it to the next stage, and where the last client sits. Every hop in that graph is a place where a reused identifier, a missing client relationship or a policy filter can stop the route. With the graph drawn, a missing route has a location instead of a mystery.

Resist making every neighbour a client

The quick repair for a missing route is to make every neighbour a client of every reflector. Propagation returns, and the design stops telling you anything: it multiplies the routes each speaker carries while hiding which relationship was meant to do the work.

A small network usually needs one of two shapes. A full iBGP mesh is six sessions for four routers with no reflection at all, and a designated pair of reflectors serving the remaining edges is the other. Both are easier to reason about than a partial mesh in which every router reflects a little. Pick the shape by scale and failure behaviour, not by the cabling diagram.

Check the address family before blaming reflection

A TCP session on port 179 proves the two speakers can talk, and nothing about whether the VPN address family exchanged a single route. Establish session state, then the family, then the individual prefix.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Those three outputs separate an adjacency problem from an exchange problem from a missing-prefix problem. If the family shows no prefixes at all, inspect the neighbour's activate state and export policy before you look at reflection. If prefixes appear on one edge but not another, compare the cluster list and originator on the receiving side, then walk the graph from the previous section.

Keep next-hop reachability and forwarding state outside that check. A reflected route with an unreachable next hop is present and unusable, which reads like a reflection failure until you look at the next-hop column. Resolve the next hop, confirm the forwarding entry, and only then decide whether the distribution graph needs another reflector.