Summary

  • RFC 4456 lets route reflectors break ordinary iBGP's no-readvertisement rule. ORIGINATOR_ID and CLUSTER_LIST bound that exception by identifying a route's internal origin and reflection path.
  • A matching local identifier is a receive-side authority to ignore an advertisement. The rule prevents loops when identities describe the real topology; a duplicate router ID or cluster ID can make legitimate reachability look returned.
  • Proof must join exact UPDATE attributes and rejection reason to client roles, RIBs, each reflector's output, FIB state and packets. An Established session is not evidence that an NLRI survived reflection.

A green session, an absent prefix

Consider a synthetic AS with eastern and western reflection domains. Each region has two redundant reflectors. Inside a region, the pair deliberately shares one cluster ID, which is correct: either reflector can recognize a route already handled by its peer in the same logical cluster.

During consolidation, automation copies the eastern value 10.0.0.42 to the western pair. The regions remain separate levels in the intended reflection graph. A route from an eastern client reaches the west carrying 10.0.0.42 in CLUSTER_LIST. The western reflector compares the list with its local value and ignores the advertisement.

No TCP failure is required. No NOTIFICATION announces that the route was invalid. KEEPALIVEs continue, the eastern originator still has the prefix, and other clients may still see an alternative. A dashboard organized around session state can remain completely green. At one receive boundary, however, the protocol has classified valid information as returned information.

The incident is synthetic, but the mechanism is normative. The failure is not that BGP has a loop check. The failure is that configuration assigned one symbol to two different realities.

The exception that made iBGP scale

Base iBGP avoids a dangerous recursion by not advertising a route learned from one internal peer to another. That simple rule demands a full mesh if every speaker must hear every external route. Route reflection scales the system by appointing speakers that may violate the ordinary restriction in a controlled way.

RFC 4456 distinguishes clients from non-clients. A reflector sends a best path learned from a non-client to its clients. A best path learned from a client may go to clients and non-clients. Other reflectors are still internal peers and can occupy either role.

The role is not negotiated in the protocol. The document describes manual configuration as the simplest arrangement. That is a significant authority boundary: one side can believe a relationship is a reflector-client relationship while the other side carries a different topology model. The OPEN exchange proves AS and identifier information; it does not prove that both operators agree about the client's place in the reflection graph.

Reflection also reduces information. Under the baseline design, the RR chooses its best path and reflects that result. Clients do not automatically receive every candidate the reflector considered. ORR and ADD-PATH can change perspective or multiplicity, but they do not erase the need to know whether a received route is returning through the reflection system.

Two identities guard the exception

ORIGINATOR_ID is optional, non-transitive and four octets long. When reflecting a route, an RR places the BGP Identifier of the router that originated the route inside the AS into this attribute. It should not replace a value already present. A router recognizing its own BGP Identifier there should ignore the route.

CLUSTER_LIST is also optional and non-transitive. It is an ordered sequence of four-octet cluster identities. Each reflector must prepend its local cluster ID when it reflects a route, creating the attribute if necessary. If a receiving RR finds its local cluster ID anywhere in the list, it should ignore the advertisement.

The two controls answer different questions. ORIGINATOR_ID asks whether the route has returned to the internal speaker that first supplied it. CLUSTER_LIST asks whether it has returned through a reflection domain already represented in its history. Neither value authenticates a router, proves ownership of an IP address or certifies the route's external origin.

RFC 6286 makes the distinction sharper. A BGP Identifier is a nonzero four-octet value unique within the AS; it need not be an assigned IPv4 address. Dotted-quad notation is a display convention, not evidence that the value is a reachable loopback. A cluster ID is likewise a protocol label. Treating these labels as incidental configuration understates their power: equality can remove reachability.

When equal is correct—and when it is destructive

One cluster may contain multiple redundant RRs. RFC 4456 explicitly permits those reflectors to share one configured cluster ID. If one member receives a route already reflected by another member, discarding it is precisely the desired result. The shared value describes an intended equivalence class.

The same equality is destructive if the reflectors are not interchangeable members of that cluster. A copied configuration pattern, merged inventory, recycled router ID, per-neighbor override or incomplete hierarchical migration can extend the equivalence class without changing the physical topology. The protocol cannot know the intention. It sees only a local value inside a list and applies the safety rule.

ORIGINATOR_ID has a parallel hazard. Two speakers inside one AS must not share a BGP Identifier. If they do, a route originated by one can be rejected by the other as its own returning route. The packets do not need to loop before the false positive occurs; identity collision is sufficient.

This is why “globally unique” is the wrong design shorthand. Cluster IDs need the right scope, not universal uniqueness. Redundant members share; distinct reflection domains do not collide along valid paths. BGP Identifiers need AS-wide uniqueness. The inventory must record both rules rather than putting every four-octet label into one address pool.

Ignored is not malformed

A well-formed UPDATE carrying a local cluster ID is not a corrupt UPDATE. The receiver recognizes the attribute, concludes that the route has returned and ignores the advertisement. RFC 7606's malformed-attribute handling is a different branch: it addresses encoding or structural errors.

This distinction matters in telemetry. A generic error counter can hide four materially different events: a parser rejected malformed bytes; import policy denied the route; the originator check matched; or the cluster check matched. Only the last two prove that reflection identity exercised authority.

The evidence record should therefore retain the raw attribute bytes, decoded ordered list, local values used for comparison and exact disposition. A message such as “not installed” is too late and too broad. The route may have failed before best-path selection, lost to another candidate, remained in Adj-RIB-In but not Loc-RIB, or reached Loc-RIB without being advertised onward.

The labels also influence preference

Even when no hard match occurs, reflection attributes affect the late stages of the Decision Process. RFC 4456 says that ORIGINATOR_ID stands in for the advertising speaker's BGP Identifier at the relevant tie-break. It also inserts a preference for the route with the shorter CLUSTER_LIST, treating absence as length zero.

That length is not a measure of latency or physical hops. It counts reflection identities carried by one representation. A topology redesign, per-neighbor cluster feature or implementation difference can change the list without changing the packet path. Reading “shorter cluster list” as “better network” confuses a loop history with service quality.

This also means an identity migration can change outcomes without triggering the hard discard case. Two otherwise equal candidates can reverse order after their cluster-list lengths change. The migration test must compare complete candidate sets and best-path reasons, not only verify that sessions and prefix counts remain nonzero.

Adjacent controls do not repair a false match

Optimal Route Reflection lets an RR choose from a logical IGP location closer to the client. It addresses whose perspective drives selection. It does not permit the RR to accept an advertisement already classified as returned by a local identity.

ADD-PATH can advertise more than one path for an NLRI when capability and direction agree. More candidates can reduce some information-loss problems. Every advertised path still carries its own attributes and remains subject to reflection-loop rules.

RFC 7964 and RFC 3345 address persistent oscillation associated with reduced routing information, MED comparison and topology. Oscillation is repeated decision change. A false cluster match may instead produce stable absence. The remedies differ.

TCP-AO or another protected transport can demonstrate that bytes came through an authenticated session. RPKI origin validation can test whether an AS is authorized to originate a prefix. Neither proves that a local cluster map is correct. Authentication protects the statement; it does not repair its semantics.

Build an identity ledger, not a diagram

The minimum record is machine-readable. For every AS, VRF and AFI/SAFI, store each speaker's BGP Identifier, default and explicit cluster IDs, per-neighbor overrides, reflector-client direction, redundancy group, hierarchy level, software release and change owner. Give each intended shared identity an explanation: these devices are interchangeable members of this cluster, under these failure conditions.

For an affected prefix, attach the source peer, raw ORIGINATOR_ID, complete ordered CLUSTER_LIST, syntax result, semantic match, import-policy result, candidate rank, Loc-RIB result and advertised result per neighbor. Then attach downstream Adj-RIB-In, FIB next hop and packet evidence.

That chain separates seven questions:

  • Did the source originate the route and with which BGP Identifier?
  • Which reflector first created ORIGINATOR_ID?
  • Which reflector prepended each cluster value?
  • Which receiver compared the value and ignored the route?
  • Did another valid candidate survive?
  • Which neighbors received a route after the decision?
  • Did the intended traffic still reach its destination?

The final question cannot be answered by a route collector alone. The first six cannot be reconstructed from a ping.

Canary the graph before changing the labels

Start with an intended reflection graph, not a device list. Declare which reflectors are redundant members of one cluster, which connect distinct clusters, which act as clients at a higher tier and which address families follow each edge. Simulate every valid source-to-client path. An intended path must not encounter its own originator or cluster identity before its destination.

Canaries must originate from every client class and traverse every redundant pair, inter-cluster edge, hierarchy level, vendor family and release boundary. Capture UPDATEs on both sides of each reflector. Check order as well as membership: each new reflection should prepend the expected value while preserving the prior sequence.

Pause if an unrelated cluster shares an identity, an intended route gains a local match, a prefix disappears while sessions remain healthy, or two releases construct different lists for the same scenario. Roll back when protected reachability is lost, a real loop is no longer rejected, modeled output and observed Adj-RIB-Out differ, or packets leave their approved path.

Rollback is not the act of restoring a configuration line. It is complete only after bounded route replay or re-evaluation has removed the false state from downstream RIBs, the expected candidate is selected and packet behavior has returned.

Sources