Zusammenfassung

  • RFC 8654 lässt einen Receiver bis zu 65.535 Oktette zusagen, ausgenommen OPEN und KEEPALIVE; der Sender nutzt die Größe erst nach Empfang der Capability vom Peer.
  • Das Versprechen endet an dieser Session. Für einen 4.096-Peer dürfen nur nach RFC 7606 verwerfbare Attribute entfallen; passt es dann nicht, wird nicht gesendet und eine frühere Route zurückgezogen.
  • Sichere Einführung vereinheitlicht iBGP vor externer Abhängigkeit, misst Encoded Size und Ressourcen und erhält eine Legacy-Darstellung für Rollback.

Capability 6 erscheint am Ingress, das große UPDATE liegt in der RIB. Ein anderer Border kann es nicht exportieren, weil der Nachbar die Fähigkeit nicht angekündigt hat und der Attribute-Satz allein zu groß ist. Ein lokaler Erfolg wurde fälschlich zur Pfadzusage.

RFC 4271 begrenzt trotz Zwei-Oktett-Length auf 19 bis 4.096. RFC 8654 erhöht den ausgehandelten Höchstwert auf 65.535 und definiert Code 6 mit Länge null. Die Anzeige verspricht Empfang und Verarbeitung auf dieser Session, nicht im ganzen AS.

Ein Speaker darf Extended Messages nur senden, nachdem er die Capability empfangen hat. RFC 5492 macht Fähigkeiten zur Session-Vereinbarung und lässt dem Betreiber die Hoheit, Unterstützung zu verlangen. Wer die Funktion nicht ankündigt, darf sie trotz vorhandener Implementierung nicht heimlich tolerant annehmen.

OPEN und KEEPALIVE bleiben ausgenommen. RFC 9072 erweitert stattdessen die bisher 255 Oktette langen Optional Parameters in OPEN mit Typ 255 und Zwei-Oktett-Länge. Ein großes OPEN ist kein Beweis für große UPDATEs.

Obergrenze ist kein Packziel

ADD-PATH ergänzt vier Oktette je NLRI, Large Communities zwölf je Wert, VPN und weitere Erweiterungen mehr. Diese Bytes können Policy-Semantik tragen und sind kein Füllmaterial.

Bei kleinem Attribute-Satz lassen sich Präfixe auf mehrere UPDATEs verteilen. Überschreitet der Attribute-Block selbst 4.096, hilft NLRI-Splitting nicht. TCP segmentiert Transport, nicht BGP-Bedeutung.

Am Legacy-Egress dürfen nur Attribute aus RFC 7606s enger attribute discard-Klasse entfernt werden. Auswahl- oder Installationsrelevantes bleibt unangetastet; lokale Policy kann auch scheinbar neutrale Felder entscheidend machen. Ist das UPDATE weiter zu groß, wird es nicht gesendet und eine bereits beworbene NLRI withdrawn.

Damit kann dieselbe Route an einem Border erscheinen und am anderen fehlen. Reflectors können verschiedene Außenbilder erzeugen, ein Backup kann gerade beim Failover unadvertisierbar werden. RFC 8654 verlangt deshalb einheitliche Fähigkeit aller relevanten iBGP Speakers.

Auch die Parserlast wächst

65.535 bindet Buffer, Queue, Parser, Validation, Policy und Logs. RFC 8654 nennt Resource Exhaustion; wiederholtes Umformatieren für Legacy-Egress kostet CPU. Authentifizierung macht valide, teure Daten nicht billig.

FRRouting führt RFC 8654 als implementiert, BIRD 3.3.0 trennt Enable und Require. Das sind prüfbare Claims, keine Beweise für Negotiation oder Headroom.

Belege gehören zu einer Session-Epoche: lokale und empfangene Capabilities, Peer, AFI/SAFI, Running Build, Inbound/Outbound Length, Attribute und NLRI. Outcomes werden als Repack, Discard, Suppress, Withdrawal, Bad Message Length oder Policy Reject klassifiziert.

Ein empfangenes UPDATE beweist weder FIB noch Pakete. Selection, rekursive Auflösung, Hardware und gemessener Verkehr schließen die Kette.