Zusammenfassung

  • BGP lauscht auf TCP 179 und darf aktiv verbinden. Bei gleichzeitigem Start können zwei vollständige TCP-Verbindungen ein Peering darstellen; RFC 4271 verlangt die Schließung einer.
  • Erhalten bleibt die Verbindung, die der Sprecher mit dem höheren BGP Identifier begann. Bei gleichen Kennungen externer Peers entscheidet RFC 6286 mit der höheren AS-Nummer.
  • Die Ordnung ist deterministisch, aber nicht authentisierend. Nötig sind eindeutige stabile Werte, Transportschutz und ein Canary, der den Gewinner vorhersagt.

Nach einer Wartung öffnet A zu B und B zu A. Beide Versuche erreichen den Listener des anderen. Kurz existieren zwei gespiegelte Vier-Tupel, zwei TCP-Sequenzräume, zwei BGP-FSMs und zwei OPENs.

Das ist nicht TCP Simultaneous Open, bei dem gekreuzte SYNs zu einer Verbindung konvergieren. Hier bestehen zwei getrennte TCP-Verbindungen. BGP kann ihre Historien nicht verschmelzen; beide zu behalten hieße doppelte Autorität.

Eine gemeinsame Wahl statt eines Rennens

RFC 4271 definiert die Kollision über vertauschte Quell- und Zieladressen derselben Sprecher. OPEN liefert den entfernten Identifier. Die Werte werden als vorzeichenlose Vier-Oktett-Zahlen verglichen; die vom Sprecher mit dem höheren Wert initiierte Verbindung bleibt.

Ist der lokale Wert kleiner, schließt das System seine bestehende OpenConfirm-Verbindung und akzeptiert die vom entfernten System initiierte. Andernfalls schließt es die neue. „Bestehend“ und „neu“ sind lokale Perspektiven, doch beide Enden wählen denselben Transport. Der höhere Wert bezeichnet keine wichtigere Organisation.

RFC 4486 reserviert Cease-Untercode 7 Connection Collision Resolution. Er erklärt den Abbau, beweist aber nicht allein den Gewinner. Vier-Tupel, OPEN, KEEPALIVE und Routenaustausch vervollständigen den Nachweis.

Parallel ist nicht automatisch kollidierend

Unterschiedliche konfigurierte Adresspaare können absichtlich mehrere Peerings bilden. Eine Bereinigung nach ASN würde Redundanz zerstören; eine Trennung nur nach flüchtigem Port würde die Kollision übersehen. Inventar muss Adressen, Routinginstanz und Policy verbinden. Aktiv und passiv sind vorübergehende TCP-Rollen, keine Organisationshierarchie.

RFC 6286 löste die Kennung von IPv4

RFC 6286 definiert einen von null verschiedenen Vier-Oktett-Wert, der innerhalb eines AS eindeutig ist, aber keine gültige IPv4-Unicast-Adresse sein muss. Alte Werte bleiben gültig.

Verschiedene AS dürfen denselben Wert verwenden. Bei externer Kollision mit Gleichstand bleibt die Verbindung des Sprechers mit der höheren AS-Nummer. Innerhalb eines AS ist Gleichheit weiterhin ungültig; eine Konföderation zählt als ein AS. Externe Gleichheit ist erst sicher, wenn beide Seiten die Revision unterstützen.

Ein kleiner Wert wirkt über mehrere Ebenen

Der Identifier erscheint auch bei Aggregation, Route Reflection und späten Pfadvergleichen. Eine Änderung kann Sitzungen, reflektierte Identität und Diagnose verändern.

FRRouting dokumentiert bgp router-id und einen möglichen ungültigen Automatikwert 0.0.0.0 ohne Schnittstellendaten. BIRD verlangt ebenfalls nonzero und AS-weite Eindeutigkeit, wählt aber anders. Daher gehören effektiver Wert, Prozess, VRF, AS, Quelle und Lebensdauer in ein Inventar.

Clones und Ersatzgeräte können Werte duplizieren; schnittstellenbasierte Defaults können sich bewegen. Konfigurationsabsicht und im OPEN beobachteter Wert müssen beide aufgezeichnet werden.

Deterministische Bereinigung kann trotzdem schwingen

Eine einzelne Kollision ist oft gesund: zwei Sockets erscheinen, eine wird verworfen, eine erreicht Established. Jeder Cease als Ausfall wäre ein Fehlalarm. Nur Established zu betrachten verschweigt dagegen Wiederholungen.

Ein instabiler Identifier, eine Firewall gegen den erwarteten Gewinner, ungleiche Konfiguration oder Neustartautomation können den Zyklus Verbindung–Verwerfen–Scheitern–Wiederholen erzeugen. Jeder Durchlauf kann Routen zurückziehen und CPU, Logs und TCP-State belasten.

Die Regel garantiert Einigkeit über den Soll-Gewinner, nicht dessen Firewall-, Schlüssel- oder KEEPALIVE-Fähigkeit. Telemetrie muss beide Sockets als ein Ereignis gruppieren und auf Wiederholung sowie Routenbewegung alarmieren.

Ordnung ist keine Authentisierung

Der Identifier im OPEN ist eine Behauptung. RFC 4272 beschreibt begrenzt, wie ein Angreifer mit passender TCP/BGP-Sequenz, Timing und gewinnendem Wert eine legitime Verbindung verdrängen könnte. Ein beliebiges OPEN genügt nicht; Sequenzen, Peer-Zulassung und Authentisierung bleiben Hürden.

RFC 2385 definiert TCP MD5, RFC 5925 TCP-AO. Beide schützen Transportsegmente unter Schlüsseln, nicht UPDATE-Policy. Ein legitimer Peer kann weiterhin eine Kennung duplizieren. Schlüsselabdeckung und -wechsel gehören deshalb zur selben Änderungskontrolle.

Der Canary sagt den Gewinner voraus

Zuerst genau ein Peering mit Adressen, AS, Identifiers und Schlüsseln dokumentieren. Dann beide Seiten begrenzt gleichzeitig initiieren lassen und SYNs, Vier-Tupel, OPEN und FSM erfassen. Vor Beobachtung den Gewinner nach Identifier oder im kompatiblen externen Gleichstand nach AS berechnen.

Cease 7, Socket-Schluss, FSM-Entsorgung und Retry werden erfasst. Danach müssen erwartete Import-/Exportrouten, keine Duplikate, FIB und gegebenenfalls Pakete stimmen. Rollback stellt einen bekannten eindeutigen Wert und Schlüsselzustand wieder her; wiederholtes Clear ist kein Verfahren.