Zusammenfassung

  • Eine BGP-Konföderation stellt mehrere Member-AS nach außen als einen AS Confederation Identifier dar. AS_CONFED_SEQUENCE und AS_CONFED_SET halten den internen Durchlauf fest, müssen aber vor jeder Anzeige an einen echten externen Nachbarn entfernt werden.
  • Diese Bereinigung ist ein Interoperabilitätsvertrag, kein Beweis für eine einheitliche Betriebsrealität. LOCAL_PREF, MED, NEXT_HOP, Candidate Visibility, Member Identity und Route Reflection können Erreichbarkeit ändern, während der öffentliche AS_PATH stabil bleibt.
  • Leadership darf diese Kompression nur zulassen, wenn vor der Sanitisation ein vollständiger Pfadnachweis existiert, jede Grenze einen Owner hat, RIB/FIB und Pakete geprüft werden und eine Member-AS-Migration Identität, Policy und Route State zurücksetzen kann.

Um 01:40 Uhr beginnt der letzte Schritt einer internen Neuordnung. Border Router Delta soll Member-AS 65021 verlassen und in 65031 wechseln. Beide gehören zu Confederation AS 64500. Für Transit Provider, Kunden und Peering-Partner soll sich nichts ändern. Eine interne Aufteilung darf nicht das gesamte Internet zu neuen Policies zwingen.

Das Change-System meldet Erfolg. Deltas externe Sessions sind grün. Ein öffentlicher Route Collector zeigt weiterhin 64500. Die öffentliche Origin Authorization ist gleich geblieben. Das Management-Dashboard wertet die unveränderte Identität als Kontinuität.

Neighbor Echo besitzt noch die alte Karte. Delta sendet OPEN als 65031; Echo erwartet den Confederation Peer 65021. Auf einer Plattform entsteht keine Adjacency. Über einen Ersatzweg bleibt eine Route vorhanden, deren NEXT_HOP im neuen IGP nicht auflösbar ist. An einem weiteren Entscheidungspunkt hat sich durch den Umbau die Menge der MED-Kandidaten verändert. Der Customer Peer ist Established, doch der brauchbare Pfad erreicht die FIB nicht.

Der Vorfall ist synthetisch. Die Mechanismen sind normativ. RFC 5065 verlangt, Member-AS-Historie am externen Rand zu entfernen. Der öffentliche AS_PATH hat die entscheidende Information nicht versehentlich verloren. Er enthält absichtlich nur die Aussage, die externe Nachbarn benötigen. Das Governance-Problem entsteht, wenn die Organisation diese reduzierte Aussage als Beweis für eine interne Entscheidung verwendet.

Drei Identitäten mit getrennten Aufgaben

Der AS Confederation Identifier ist die global sichtbare Nummer der gesamten Konföderation. Ein Member-AS bildet darin eine interne Routing- und Policy-Domäne. Seine Member-AS Number identifiziert diese Domäne gegenüber anderen Mitgliedern.

Für OPEN und AS_PATH zu einem Nichtmitglied verwendet der Router den Confederation Identifier. Zwischen Mitgliedern verwendet er die jeweilige Member-AS Number. Solche Sessions funktionieren auf dem Wire als EBGP, aber mehrere Regeln behandeln die empfangenen Routen wie interne Information derselben Konföderation.

Die Trennung löst ein Skalierungsproblem. Ein einziges großes AS würde ohne Route Reflection ein vollständiges IBGP Mesh benötigen. Member-AS reduzieren die globale Anzahl der Sessions und schaffen regionale oder funktionale Policy-Grenzen. Innerhalb jedes Mitglieds bleibt jedoch ein eigenes Mesh- oder RR-Design nötig. IGP, Team und Failure Budget können ebenfalls unterschiedlich sein.

Eine öffentliche Nummer liefert daher die minimale Koordinationsaussage: AS 64500 spricht. Sie sagt nicht, welches Mitglied eine Route angenommen, wer LOCAL_PREF gesetzt, welches IGP den Next Hop erreicht oder welches Gerät Pakete tatsächlich weitergeleitet hat. Der Identifier kann kohärente Verwaltung repräsentieren; er erzeugt sie nicht.

Die interne Spur wird zuerst aufgebaut und dann entfernt

AS_CONFED_SEQUENCE ist eine geordnete Liste der durchlaufenen Member-AS. AS_CONFED_SET ist ein ungeordneter Satz, etwa im Zusammenhang mit Aggregation. Wenn ein Speaker eine gelernte Route an ein anderes Mitglied weitergibt, stellt er seine eigene Member-AS Number der Sequence voran oder erzeugt ein neues Segment.

Diese Information verhindert Loops. Findet ein Mitglied seine eigene Nummer in einem Confederation Segment, behandelt es die Route wie einen normalen Pfad mit dem eigenen AS. Enthält der gewöhnliche Pfad den lokalen Confederation Identifier, erkennt der Speaker ebenfalls die Rückkehr zur eigenen externen Identität.

Am echten Außenrand gilt die umgekehrte Regel. Sämtliche AS_CONFED_SEQUENCE- und AS_CONFED_SET-Segmente müssen entfernt werden. Danach wird der Confederation Identifier als normaler AS_SEQUENCE-Eintrag vorangestellt. RFC 6793 verbietet Confederation Segments auch in AS4_PATH, damit die Four-Octet-Kompatibilität kein internes Leck erzeugt.

Ein externer Collector erhält damit eine wahre, aber komprimierte Aussage. Er kann bestätigen, dass die Route AS 64500 durchlaufen hat. Er kann nicht rekonstruieren, ob intern 65021, 65017 und 65009 beteiligt waren. Das schützt Außenstehende vor unnötiger Topologiekomplexität und verpflichtet den Betreiber zugleich, den letzten unbereinigten Pfad selbst aufzubewahren.

Kompression ist keine Täuschung. Falsch ist nur, von der komprimierten Ansicht Antworten auf eine Frage zu verlangen, deren Daten definitionsgemäß entfernt wurden.

Membership ist ausführbare Übereinstimmung

Ein gemeinsames Diagramm bildet keine BGP-Adjacency. Beide Enden müssen Local AS, Peer AS und Confederation Membership übereinstimmend konfigurieren. Die aktuelle Juniper-Referenz weist ausdrücklich darauf hin, dass sich eine Adjacency nicht bildet, wenn zwei Nachbarn sich über ihre Zugehörigkeit zur Konföderation uneinig sind.

RFC 5065 setzt weitere Invarianten. Eine Route eines anderen Member-AS sollte mit AS_CONFED_SEQUENCE beginnen. Ein Speaker darf Confederation Segments nicht an einen externen Nachbarn senden. Jedes interne Mitglied muss die Segmenttypen verstehen; externe Router brauchen die Erweiterung nicht, weil sie diese Segmente nie sehen sollten.

Moderne Fehlerbehandlung kann die Session erhalten. RFC 7606 behandelt einen malformed AS_PATH in der Regel als withdraw. Die betroffenen NLRI verschwinden, während TCP und KEEPALIVE weiterlaufen. Das begrenzt den Blast Radius, trennt aber Session Health von Route Health. Unterschiedliche interne Zustände können Unreachability, suboptimale Wege oder langlebige Forwarding Loops erzeugen.

Die Beweiskette umfasst deshalb Konfiguration, beobachtetes OPEN, Segmenttyp, Policy-Ergebnis, Adj-RIB-In, Loc-RIB, rekursive Auflösung, FIB und Paket. Ein grüner Peer beweist nur, dass das Gespräch fortgesetzt wird.

Auf der Leitung extern, in der Entscheidung intern

Zwischen Member-AS entsteht eine EBGP Session. Im Schritt IBGP-versus-EBGP wird eine Route desselben Confederation-Verbunds dennoch als intern behandelt. CONFED_SEQUENCE und CONFED_SET zählen nicht zur AS_PATH Length.

LOCAL_PREF darf die Member-Grenze überschreiten. NEXT_HOP und MED dürfen unverändert bleiben. Diese Regeln lassen mehrere Member wie ein gemeinsames Policy-System arbeiten. Gleichzeitig übertragen sie Voraussetzungen, die nicht überall gelten müssen.

Bei einem gemeinsamen IGP kann der unveränderte Next Hop überall erreichbar sein. Mit unabhängigen IGPs kann die rekursive Auflösung fehlen. RFC 5065 nennt ausdrücklich die Möglichkeit, NEXT_HOP per Policy zu setzen. Eine formal akzeptierte BGP Route kann somit nie in Hardware erscheinen.

Die normale MED-Betrachtung überspringt Confederation Segments und schaut auf den ersten gewöhnlichen AS_SEQUENCE. Implementierungen können zusätzliche Vergleiche zwischen Member-Pfaden erlauben. Ändert eine Migration die sichtbaren Kandidaten, kann auch der Winner wechseln, obwohl öffentliche Attribute unverändert wirken.

Ein Runbook muss daher pro AFI/SAFI Attribute Treatment, Next-Hop Scope, MED-Regeln, Candidate Source und Owner beschreiben. Die Kurzbezeichnung „confed EBGP“ reicht nicht.

Eine dauerhafte Oszillation hinter einem stabilen Pfad

RFC 5065 warnt vor doppelten Anzeigen, Ressourcenverschwendung, Flaps und verzögerter Konvergenz. Confederations und Route Reflectors können verschiedenen Entscheidungspunkten verschiedene Kandidaten zeigen. Zusammen mit bestimmten MED-Konstellationen entsteht die in RFC 3345 beschriebene Persistent Route Oscillation.

Ein Router wählt A und verbreitet B nicht mehr. Das Fehlen von B verändert die Wahl eines anderen Routers. Dessen neue Anzeige lässt B wieder erscheinen und kippt die erste Entscheidung zurück. Jeder lokale Schritt kann regelkonform sein, während das Gesamtsystem keinen stabilen Zustand findet.

Extern bleibt davon nur der Gewinner übrig, der nach Export Policy und Segmentbereinigung ausgegeben wird. Der Collector sieht weder den verlorenen Kandidaten noch seine Member-AS-Spur.

Topologiegerechte IGP Metrics, konsistente Tie-Breaks, Duplicate Filter und vollständigere Candidate Distribution helfen in bestimmten Designs. Keines dieser Mittel beweist universell, dass alle Knoten dieselbe relevante Auswahl sehen. Für eine reproduzierbare Diagnose braucht man Candidate Set, vergleichbare MED, Reject Reason und Topology Epoch an jedem Entscheidungspunkt.

Private Nummern brauchen ein Kollisionsregister

RFC 6996 reserviert 64512–65534 und 4200000000–4294967294 für Private Use. Betreiber nutzen diese Bereiche häufig für Member-AS, weil ihre Segmente am Außenrand verschwinden. RFC 5065 schreibt private Nummern jedoch nicht vor.

Private bedeutet nicht global eindeutig. Zwei getrennte Unternehmen können beide 65021 verwenden. Durch Fusion oder temporären Interconnect treffen die Scopes aufeinander. Loop Detection, AS-Path Filter, Logs und Ownership verbinden dann eine Zahl mit zwei Bedeutungen.

Ein Member-AS-Register muss Nummer, Owner, Region, IGP Domain, RR Cluster, AFI/SAFI, Four-Octet Capability und Retirement Plan enthalten. Technische Due Diligence vergleicht diese Bestände vor der Verbindung der Netze.

remove-private ist nicht dieselbe Funktion. Juniper dokumentiert, dass Private-AS Removal erst nach Entfernung der Confederation Member Segments stattfindet. Ein sauberer externer Pfad beweist nicht automatisch beide Kontrollen.

Belege müssen vor der Sanitisation entstehen

Pro Adjacency und AFI/SAFI gehören Local Member-AS, erwarteter Peer, Confederation Identifier, beobachtetes OPEN, Capabilities, rohe AS_PATH Segments, Policy Version, LOCAL_PREF, MED, NEXT_HOP, Best-Path Reason und Error Action in den Ledger.

Die Stufen werden verbunden: Pre- und Post-Policy Adj-RIB-In, Loc-RIB Candidates, Pre- und Post-Policy Adj-RIB-Out zum nächsten Mitglied sowie der bereinigte externe Export. Hashes von Topology und Policy ordnen die Entscheidung dem ausgeführten Zustand zu.

Danach folgen Recursion, FIB/ASIC und Paketpfad. Ein korrektes Segment beweist keinen erreichbaren Next Hop. Eine FIB Entry beweist nicht den beabsichtigten Egress. Der öffentliche Collector bestätigt die letzte Aussage, nicht die verborgene Entscheidung.

Alerts sollten Divergenzen melden: OPEN passt nicht zur Membership, externer Peer sendet Confed Segment, internes Segment fehlt, private Nummer kollidiert, Treat-as-Withdraw tritt bei lebender Session auf, Best Path ändert sich ohne öffentliche Änderung oder ein MED Cycle wiederholt sich.

Renumbering ist eine Protokollmigration

Eine Member-AS-Änderung betrifft Path Prepend, Loop Identity, Policy Matches, Telemetry, Peer Classification und möglicherweise das RR Domain. Der Old-to-New Plan umfasst Router, Sessions, Policies, Communities, Monitoring, Collectors und Owners.

Ein Canary begrenzt sich auf eine redundante Grenze, eine AFI/SAFI und kontrollierte Präfixe. Vor und nach dem Change vergleicht er OPEN, Segments, Candidates, Selection, Recursion, FIB und Pakete in beide Richtungen. Die Beobachtungszeit muss MED Cycles und verzögerte RR-Effekte sichtbar machen.

Rollback stellt Number, Membership List, Peer Type, Policies, Reflection Relationship, Labels und Route State wieder her. Es definiert auch den Umgang mit stale routes. Nur den Konfigurationstext zurückzubringen, ohne Forwarding zu beweisen, ist kein vollständiger Rollback.