Zusammenfassung

  • Optionale transitive Attribute lassen neue BGP-Informationen ältere Systeme durchqueren, die ihre Semantik nicht kennen. Nimmt ein solcher Sprecher den Pfad an und kündigt ihn weiter an, muss er das Attribut erhalten und Partial setzen; ein späteres AS darf diese Spur nicht löschen.
  • Partial ist ein bleibender Hinweis auf unvollständige semantische Obhut, keine Integritätsprüfung. Das Bit nennt weder den unwissenden Hop noch authentifiziert es den Ursprung, prüft den Wert oder belegt Zustimmung zur kodierten Politik.
  • RFC 7606 kann ein fehlerhaftes Attribut verwerfen oder die betroffenen Routen wie zurückgezogen behandeln, während die Sitzung bestehen bleibt. Deshalb müssen Rohbytes, Fehleraktion, RIB-Ergebnis und Pakete gemeinsam beobachtet werden.

Um 02:10 Uhr erprobt ein Betreiber zwischen zwei kontrollierten Standorten ein neues Policy-Attribut. Der Ursprung läuft auf der neuen Software, der Transit dazwischen erkennt den Typcode nicht, der empfangende Rand wurde gerade aktualisiert und kennt ihn.

Das UPDATE ist äußerlich korrekt: Flags, Typ, Länge, Wert und ein IPv4-Präfix. Der Transit kann das Attribut abgrenzen, besitzt aber keinen Decoder. Weil Optional und Transitive gesetzt sind, übernimmt er den Pfad, erhält die Bytes, setzt Partial und kündigt ihn weiter an.

Beim Empfänger ändert sich die Lage. Sein Decoder kennt den Typ und entdeckt, dass der Wert gegen dessen Spezifikation verstößt. Die vorgesehene Aktion lautet treat-as-withdraw. Die Route verschwindet aus dem Adj-RIB-In, doch TCP und KEEPALIVEs laufen weiter. Der Transit zählt das Präfix weiterhin. Nur der Kundenpfad hinter dem Empfänger fällt aus.

Das Szenario ist konstruiert, die Zuständigkeitsgrenze nicht. BGP soll künftige Informationen durch ältere Sprecher tragen können, ohne ein synchrones weltweites Upgrade zu verlangen. Dadurch kann ein Router Semantik korrekt transportieren, die er nicht prüfen kann. Ein späteres Upgrade kann dasselbe Objekt erstmals verstehen – und zu Recht ablehnen.

Vier Bits, vier verschiedene Aussagen

Die oberen vier Bits des Attribute-Flags-Oktetts erfüllen getrennte Aufgaben. Optional unterscheidet Erweiterungen von well-known Attributen, die jede Implementierung erkennen muss. Transitive bestimmt, ob ein unbekanntes optionales Attribut eine BGP-Grenze überschreiten darf. Partial bezeichnet die Information eines optionalen transitiven Attributs als unvollständig. Extended Length wählt lediglich ein ein- oder zweioktettiges Längenfeld. Die unteren vier Bits sind reserviert.

Bei well-known Attributen ist Transitive gesetzt, Partial muss aber null sein. Ein optionales nichttransitives Attribut kann zwischen unterstützenden Systemen nützlich sein; ein unwissender Empfänger ignoriert es still und gibt es nicht weiter. Auch dort ist Partial null.

Die Erweiterungsreserve liegt im optionalen transitiven Fall. RFC 4271 erwartet nicht, dass jedes System jedes Attribut versteht. Ein Pfad mit einem unbekannten Attribut dieser Klasse sollte akzeptiert werden. Wird er weitergegeben, muss das Attribut mitreisen und Partial auf eins gesetzt sein.

Das ist eine enge Zusage: Byte-Verwahrung, kein semantisches Verständnis. Der Router kennt Grenzen, Typ und Flags. Er weiß nicht, ob der Wert geschäftlich autorisiert, authentisch, intern wohlgeformt oder für einen künftigen Parser ungefährlich ist.

Extended Length liefert keine Inhaltsprüfung. Es ändert nur die Breite des Längenfelds. Ein Objekt kann sauber eingerahmt und dennoch in seiner inneren Grammatik falsch sein. Der alte Knoten bewahrt es gerade deshalb, weil ihm die Prüfung fehlt.

Partial ist kein Vertrauenswert

Der Name klingt nach beschädigt, ungeprüft oder wenig vertrauenswürdig. Das Protokoll meint etwas Präziseres. Ein Sprecher, der ein unbekanntes optionales transitives Attribut weitergibt, setzt Partial. Erkennt ein späterer Sprecher das Attribut und ist Partial bereits gesetzt, darf er es nicht löschen. Auch ein Nicht-Ursprung, der ein solches Attribut neu anhängt, setzt das Bit.

Die Spur sagt damit: Eine lückenlose semantische Obhut vom Ursprung bis hierher darf nicht angenommen werden. Sie nennt nicht das unwissende AS, liefert keine Abfolge des Verstehens, meldet keine erlaubte Wertänderung und beweist keine Berechtigung des Senders.

Partial ist auch nicht authentifiziert. Es ist ein Bit im UPDATE und erbt die Vertrauensgrenze der Sitzung und des Betriebswegs. Es ersetzt weder Ursprungsvalidierung noch Beziehungs- und Importpolitik, Transportschutz, Konfigurationsherkunft oder Datenebenenbeweis.

Sein Wert liegt in dieser Bescheidenheit. Es bewahrt die Aussage, dass das Objekt eine Grenze ohne vollständige semantische Kontrolle überschritten hat. Daraus folgt Untersuchung und eine eng begrenzte Regel, nicht automatisches Vertrauen oder pauschale Ablehnung.

Ein Upgrade verschiebt die Erkennungsgrenze

„Unbekannt“ ist relativ zu Implementierung, Release, Adressfamilie und aktivierter Funktion. Dieselben Bytes können am Dienstag undurchsichtig und am Mittwoch parsebar sein.

Solange der Typ unbekannt ist, wird sein Inhalt nicht validiert. Sobald er erkannt wird, gelten die spezifischen Regeln für Flags, Länge, Unterstrukturen, Bedeutung und Fehleraktion. Ein Wert, der monatelang unbemerkt transportiert wurde, kann am ersten Decoder oder nach einem lokalen Upgrade attribute discard oder treat-as-withdraw auslösen.

Das ist nicht automatisch eine Regression. Die neue Software entdeckt vielleicht erstmals einen echten Fehler. Auch der alte Transit hat nicht zwingend versagt. Der Vorfall entsteht aus asynchroner Einführung, opakem Transport und einer neu aktiven semantischen Grenze.

Darum gehört vor ein Upgrade ein Bestand aller Routen mit unbekannten Attributen: Code, Flags, Länge, Werthash, Nachbar, AFI/SAFI, betroffene NLRI und Partial. Danach wird geprüft, welche Codes nun erkannt werden, welche Validierung läuft, welche Aktion folgt und welche Routen sich verändern.

Ohne diese Daten heißt der Ausfall bloß „Softwareproblem“. Mit ihnen lassen sich Parserfehler, korrekte Ablehnung, zu breite Eindämmung und ein vertragswidriger Sender trennen.

Eine erhaltene Sitzung ist kein erhaltener Dienst

Das ursprüngliche BGP-4-Fehlermodell konnte wegen eines fehlerhaften Attributs die ganze Sitzung zurücksetzen und damit auch gültige, unbeteiligte Routen entfernen. Optionale transitive Attribute vergrößerten das Problem: unwissende Router konnten einen ungeprüften Wert an viele Systeme auffächern, die ihn verstanden.

RFC 7606 begrenzt zahlreiche Fehler auf drei relevante Aktionen. Session reset bleibt am stärksten. Treat-as-withdraw entfernt die Routen des fehlerhaften UPDATE aus dem Adj-RIB-In und hält die Sitzung. Attribute discard entfernt nur das Attribut und verarbeitet die Route weiter.

Das ist keine einfache Schweregradskala. Attributverwerfen kann irreführender sein als Rückzug: Die Route bleibt, aber eine für Auswahl oder Installation gedachte Semantik fehlt. Deshalb ist discard nur für Attribute vorgesehen, die diese Entscheidungen nicht beeinflussen, sofern keine sorgfältige attributspezifische Analyse etwas anderes ergibt.

Treat-as-withdraw zeigt den Fehler als Routenverlust, bleibt jedoch für sitzungszentrierte Überwachung unsichtbar. Der Nachbar ist Established, der Hold Timer läuft, KEEPALIVEs kommen. Keiner dieser Werte beweist, dass das NLRI noch vorhanden ist.

Widersprechen Optional oder Transitive der Spezifikation eines bekannten Attributs, verlangt RFC 7606 gewöhnlich treat-as-withdraw, sofern die Attributnorm keine andere Behandlung nennt. Doppelte MP_REACH_NLRI oder MP_UNREACH_NLRI führen für alle Routen im UPDATE zu treat-as-withdraw, während die Sitzung bestehen bleibt; bei den meisten anderen Duplikaten werden spätere Vorkommen verworfen. Treffen mehrere Fehler zusammen, gilt die stärkste Aktion.

„RFC-7606-Unterstützung“ allein ist daher kein Nachweis. Entscheidend sind die konkrete Klassifikation, die attributspezifische Regel und das resultierende Routenset. Eine Plattform kann die Sitzung korrekt retten und dennoch einen ernsten Dienstausfall verursachen.

Die lokale Grenze behält ihre Eindämmungsbefugnis

Die Standardweitergabe schützt Erweiterbarkeit. Sie zwingt einen Betreiber nicht, jeden unbekannten Code durch jede Produktionsgrenze zu lassen. Herkunft, Ressourcenwirkung und Folgen für nachgelagerte Systeme können vorab verlangt werden.

Aktuelle Juniper-Dokumentation zeigt zwei unterschiedliche Entscheidungen: unbekannte optionale transitive Attribute entfernen und die Route behalten oder Routen mit solchen Attributen zurückziehen. Bestimmte Codes können ausgenommen und Regeln global, gruppen- oder nachbarbezogen gesetzt werden. Readback zeigt verworfene Attribute und solche, die Rückzüge auslösten.

Diese Funktionen sind lokale Implementierungsregeln, keine universellen BGP-Gesetze. Attributentfernung kann Pakete erhalten und zugleich notwendige Semantik löschen. Pauschaler Routenrückzug kann eine schrittweise Einführung in einen Ausfall verwandeln. Eine zu breite Ausnahme öffnet die ursprüngliche Exposition.

Die richtige Frage lautet: Welcher Code darf über welche Beziehung und AFI/SAFI gehen, nach welchem Beweis, mit welcher Aktion bei Unsicherheit? Kunde, Route Server, interner Reflektor, Peer und Labor brauchen nicht dieselbe Antwort.

Cisco NX-OS dokumentiert die nötige Sicht: Präfixe mit unbekannten oder verworfenen Attributen auflisten und für eine Route Flag, Typ, Länge und Wert anzeigen. Ein Gesamtzähler kann ein harmloses Experiment nicht von einem fehlerhaften Objekt an Hunderttausenden Routen unterscheiden.

Weitergabe ist Verwahrung, nicht Zustimmung

Ein unwissender Router, der das Attribut erhält, stimmt seiner Bedeutung nicht zu. Er erfüllt einen Informations-Transportvertrag. Wer beides verwechselt, behauptet falsche kommerzielle oder sicherheitliche Verantwortung.

Soll ein Attribut eine Serviceklasse ausdrücken, kann aus seiner Beförderung durch ein unwissendes Transit-AS weder Leistungserbringung noch Anspruchsprüfung oder Haftung abgeleitet werden. Partial verwandelt Mitführen nicht in Einwilligung. Der Empfänger behält eigene Verträge und Regeln.

Unbekannt bedeutet auch nicht feindlich, und ein IANA-Code bedeutet nicht sicher. Das Register gibt dem Objekt eine stabile Identität. Es beweist weder normgerechte Sender noch fehlerfreie Parser, Ressourcenpfade oder Entscheidungslogik.

Praktische Datensouveränität gilt selbst für opaque Bytes. Das Netz entscheidet über Logging, Mandantengrenzen, Export, Routenaktion und Aufbewahrung für Ermittlungen. Undurchsichtig bedeutet nicht herrenlos.

Die Beweiskette sollte Hashes der eingehenden und ausgehenden Bytes behalten, nicht nur CLI-Text. Anzeigen können Flags normalisieren, Werte kürzen oder Attribute ausblenden. Roh-UPDATE sowie Pre- und Post-Policy-Adj-RIB zeigen gemeinsam, ob das Objekt erhalten, verändert oder entfernt wurde.

Der Canary muss Nichtwissen sichtbar machen

Ein zufälliger Code gehört nicht in die öffentliche Routingtabelle. Der Test findet im Labor, in einer kontrollierten bilateralen Beziehung oder nach dem Verfahren der echten Erweiterung statt: wenige Präfixe, bekannter Code, reversible Policy und unabhängige Paketsonden.

Vier Stufen werden festgehalten: Ursprungs-UPDATE mit exakten Bytes; unwissender Hop mit Partial vorher und nachher sowie Ausgangs-UPDATE; erkennender Hop mit Decoder-Version, Validierung, Aktion und Adj-RIB-In; Datenebene mit gewählter Route, FIB und Paketen.

Zu testen sind ein gültiger Wert, ein äußerlich korrekt gerahmter aber semantisch falscher Wert und ein unbekanntes nichttransitives Kontrollattribut. So wird Klassifikation statt bloßer Anwesenheit geprüft.

Danach wird der zuvor unwissende Hop aktualisiert und dasselbe UPDATE erneut gespielt. Ein anderes Ergebnis kann korrekt sein. Genau diese Wiederholung zeigt das Produktionsrisiko: Erkennung verschiebt die Validierungsgrenze.

Rollback benötigt zwei unabhängige Hebel. Einer entfernt oder korrigiert das Attribut an der Quelle, der andere enthält den Typ an der Grenze, ohne fremde Sitzungen zurückzusetzen. Braucht einer davon einen Notfall-Code-Release, ist der Versuch nicht bereit.

Der Unterschied zwischen geschriebenem Mechanismus und eingesetztem Nachweis ist hier wörtlich. Der Standard liefert den Mechanismus; die eingesetzte Kette entscheidet über Bytes und Route. Der Beweis besteht aus UPDATE, Partial-Übergang, lokaler Aktion, RIB und zugestelltem Paket.