Summary

  • BGP speakers both listen on TCP port 179 and may actively connect. When both initiate simultaneously, two valid TCP connections can exist for one configured peering; RFC 4271 requires one to close.
  • The peers compare BGP Identifiers and preserve the connection initiated by the higher-valued Identifier. RFC 6286 adds an AS-number tie-break for external peers that legitimately use identical Identifiers.
  • The rule is deterministic, not authenticating. Safe operation depends on unique and stable identifier assignment, transport authentication, collision-specific telemetry and a canary that predicts the surviving socket before routes move.

Consider an illustrative maintenance scenario. Maintenance ends at both sites at 02:00. Automation enables the neighbours at almost the same instant. Router A opens TCP toward B while B opens TCP toward A. Each active attempt reaches the other's listener. For a short interval there are two four-tuples that are mirror images, two TCP state machines, two BGP finite-state machines and two valid OPEN messages.

This is not TCP simultaneous open. In that case crossed SYNs can converge into one TCP connection. Here two separate TCP connections have completed. BGP cannot merge their sequence spaces, OPEN negotiation, timers and update history. Keeping both would create two authorities for one configured peering. One must lose.

The retained connection is chosen, not discovered

RFC 4271 defines a connection collision when the source address of one BGP connection is the destination of the other, and vice versa, for the same speakers. The implementation normally identifies the peer after receiving OPEN, because that message carries the remote BGP Identifier. Until resolution, each connection has its own FSM.

The selection convention is precise. Treat both BGP Identifiers as four-octet unsigned integers. Preserve only the connection initiated by the speaker with the higher-valued Identifier. If the local Identifier is lower, the local system closes its already existing OpenConfirm connection and accepts the newly received connection initiated by the remote, higher-ID system. Otherwise it closes the new connection and retains its existing one.

The apparent inversion can confuse packet analysis. “Existing” and “new” are local descriptions, so each end sees the sockets from the opposite perspective. The shared comparison makes both systems converge on the same transport. The point is not that a high number represents a superior router. It merely supplies an ordering stable enough to prevent packet timing from deciding which session survives.

RFC 4486 assigns Cease subcode 7, Connection Collision Resolution, for a NOTIFICATION sent because of that decision. The notification helps explain why a socket closed, but it is not the complete proof. Operators must also identify the retained four-tuple and show that it continued through OPEN, KEEPALIVE and route exchange.

A configured peering, not every parallel session

Parallel TCP connections are not automatically a collision. RFC 4271 allows more than one configured peering between the same speakers when different address pairs are deliberately used. A multihop session, an interface-address session and a loopback-address session may be separate policy objects. The collision set is defined by the reversed address pair and configured peer identity, not by two routers merely sharing an AS relationship.

This boundary matters in automation. A cleanup routine that groups all sessions by remote ASN and retains only one can destroy intentional redundancy. Conversely, a system that keys solely on transient local port may treat two halves of one collision as independent peers. The inventory must state which local address, remote address, routing instance and peer policy constitute one configured peering.

Active and passive are also temporary transport roles. Both BGP speakers must be able to listen, and both may try to connect. Once the retained session is Established, routing semantics do not depend on which endpoint supplied TCP port 179. A firewall rule that assumes one organization is permanently the caller can therefore break recovery without changing any BGP policy.

RFC 6286 separated the Identifier from an IPv4 address

The original BGP definition described the Identifier as a valid IPv4 unicast address selected by the speaker and required it to be the same for every local interface and peer. That model became awkward for IPv6-only systems and for routers whose meaningful identity should not follow one interface address.

RFC 6286 revises the Identifier to a nonzero four-octet unsigned integer unique within an autonomous system. It need not be a syntactically valid IPv4 unicast address. An Identifier chosen under the older rule still fits the new definition, so migration does not require renumbering every existing router.

The revision creates one important corner case. Two speakers in different ASes may legitimately have the same Identifier because uniqueness is AS-wide, not Internet-wide. If an external connection collision has equal Identifiers, RFC 6286 preserves the connection initiated by the speaker with the larger AS number. The extension covers four-octet AS numbers as well.

That tie-break is external only. Two speakers inside one AS sharing an Identifier violate the uniqueness requirement; AS number cannot rescue the ambiguity because both values are the same. For a confederation, RFC 6286 treats the whole confederation as one AS for this purpose.

Compatibility must be staged. A speaker cannot assume it may share an Identifier with an external neighbour until the neighbour supports the revised collision rule. Otherwise equal Identifiers can lead to inconsistent or implementation-specific handling precisely when deterministic agreement is needed.

The four-octet value carries several kinds of state

BGP Identifier is not confined to collision resolution. It appears in aggregation identity, route-reflection attributes and some route-selection comparisons. A router-ID change is therefore not cosmetic metadata. It may reset sessions, change reflected-route identity, alter diagnostic continuity and influence late best-path tie-breaks depending on the implementation and topology.

FRRouting documents an explicit bgp router-id and warns that without interface information an automatic value may remain 0.0.0.0, which is invalid for establishing BGP. BIRD documents a four-byte nonzero router ID that should be unique within an AS, with its own default selection. The differing defaults are a reason to pin and inventory the effective value, not to assume a fleet-wide convention.

Virtual routing instances complicate the ownership surface. A platform may hold several BGP processes or VRFs with their own selection rules. A cloned virtual router may inherit an Identifier. A replacement appliance may boot before its intended loopback exists and select a different value. An interface-derived default can move when addresses or availability change.

The safe record is explicit: BGP process, routing instance, local AS, configured Identifier, observed OPEN Identifier, source of the value, uniqueness domain and intended lifetime. The record should survive hardware replacement and be reviewed alongside route-reflector cluster identity and authentication keys.

Deterministic cleanup can still become churn

A single collision resolved in milliseconds may be entirely healthy. Both endpoints observe two sockets, apply the same comparison, discard the same logical connection and continue on the survivor. Monitoring that declares every Cease or TCP close an outage will turn correct state cleanup into a false incident.

The opposite blind spot is more dangerous. Monitoring only the final Established badge can miss continuous collision recurrence. Unstable identifiers, mismatched peer configuration, a firewall dropping one retained direction, or automation that repeatedly restarts the listener can produce a loop: two connections form, one is discarded, the intended survivor fails, and both retry.

Every cycle can withdraw routes, rerun best-path selection and propagate changes. If both peers reconnect aggressively, CPU, logging and TCP state increase. A deterministic tie-break guarantees agreement about which connection should survive; it does not guarantee that the chosen connection can pass the firewall, authenticate, sustain KEEPALIVEs or carry routes.

This is why collision telemetry needs an episode identity. Group the two sockets, the two OPENs and the one retained session into one event. Record the reason for the discarded socket without counting it as a separate peering outage. Alarm on recurrence, failure of the predicted survivor, Identifier drift, unexpected equal-ID fallback or route churn after resolution.

The Identifier orders connections; it does not authenticate speakers

The remote Identifier arrives inside OPEN. By itself, that four-octet value is a claim. It does not cryptographically prove the sender's organization, router or right to peer. A legitimate peer can also be misconfigured with a duplicate or changed value.

RFC 4272 describes a bounded attack: if an outsider can complete the necessary TCP/BGP sequence at the right time and choose an Identifier that wins collision resolution, it may cause the legitimate connection to be discarded. This is not achieved by throwing an arbitrary OPEN at port 179. TCP sequence state, timing, configured peer admission and any transport authentication remain relevant barriers.

RFC 4272 cites the TCP MD5 Signature Option as a countermeasure for the transport attack it describes. RFC 5925 later defines TCP-AO with stronger algorithm and key-management structure. Neither mechanism validates UPDATE policy or makes the BGP Identifier an identity certificate. A correctly authenticated neighbour can still advertise bad routes, duplicate an Identifier or run faulty restart automation.

Transport protection therefore belongs to the same governance record as collision handling: which peer addresses a key covers, who can rotate it, how overlap is staged, which algorithm is deployed and how an authentication failure differs from collision Cease 7. Losing key synchronization during a router-ID migration can make a correct collision rule look broken.

A collision canary must predict the survivor

The test begins with a deliberate one-peering boundary. Confirm the exact local and remote addresses, AS numbers, configured Identifiers and authentication state. Verify that a second address pair is not an intended independent peering.

Then cause both speakers to initiate concurrently in an isolated or low-blast-radius environment. Capture both SYN flows, completed TCP four-tuples, OPEN messages and per-connection FSM states. Before looking at the result, calculate which speaker has the higher Identifier—or, for a supported external equal-ID case, the higher AS number—and therefore which initiated connection must remain.

During resolution, record the Cease subcode if emitted, socket closure, FSM disposal and retry counters. The predicted connection must reach OpenConfirm and Established while the other disappears. A packet capture alone is not enough if the routing daemon's mapping between sockets and peer objects is unknown; daemon state and logs complete the control-plane evidence.

Afterward, compare expected import and export routes, message counters and Adj-RIB state. Ensure there are no duplicate advertisements, unexplained withdrawals or repeated collision cycles. If the test claims service continuity, verify FIB next hops and packets. Established proves only that one control-plane session survived.

Rollback is not “clear the neighbour until it stays up.” Restore a known unique Identifier, known key state and one documented peer address pair. Coordinate restarts so old and new identity are not alternated by automation. Re-run the collision calculation and preserve the evidence.