Zusammenfassung

  • Treat-as-withdraw hält eine BGP-Sitzung in geeigneten Fehlerfällen aufrecht, entfernt aber jede in der fehlerhaften UPDATE enthaltene Route aus Adj-RIB-In.
  • Die richtige Maßnahme hängt von der Lesbarkeit der NLRI, der betroffenen Attributsemantik, der lokalen Policy und der tatsächlichen Plattform ab. Ein grüner Peerstatus ist kein Erfolgsnachweis.

Was ein einzelner Logeintrag nicht zeigt

Das folgende Szenario ist ausdrücklich illustrativ. Eine UPDATE trägt mehrere ansonsten gewöhnliche Routen und ein fehlerhaftes Pfadattribut. Es gibt keinen benannten Betreiber, keine echten Präfixe, keine angenommene Anzahl und keinen behaupteten Softwarefehler. Entscheidend ist nur die Nachrichtenstruktur: Eine UPDATE kann mehrere Ziele mit demselben Satz an Pfadattributen bündeln. Diese Attribute gelten für alle enthaltenen NLRI. RFC 4271.

Nach der grundlegenden Fehlerbehandlung von RFC 4271 kann ein UPDATE-Fehler eine NOTIFICATION, die Beendigung der Sitzung und damit den Verlust sämtlicher über diesen Peer gelernter Routen auslösen. Das vernichtet auch gültigen Zustand aus anderen Nachrichten. RFC 7606 ersetzt diesen breiten Eingriff für bestimmte Fehler durch begrenztere Maßnahmen. Bei treat-as-withdraw bleiben Sitzung und TCP-Verbindung bestehen, während alle Routen der anstößigen UPDATE so behandelt werden, als seien sie zurückgezogen worden. RFC 7606.

Der Logeintrag „TreatAsWithdraw“ sagt deshalb weder „nur ein schlechtes Präfix entfernt“ noch „Erreichbarkeit bewahrt“. Sind mehrere NLRI in der Nachricht, sind sie gemeinsam betroffen. Für einige kann ein alternativer Pfad ausgewählt werden, für andere keiner. Die Maßnahme repariert das Attribut nicht. Sie tauscht eine unzuverlässige Routenbehauptung gegen den bekannten Verlust der enthaltenen Routen.

Ebenso wenig ist sie identisch mit dem Verwerfen der UPDATE. BGP aktualisiert Zustand inkrementell. Würde der Empfänger eine Änderung einfach ignorieren, könnte ein älterer, inzwischen ungültiger Pfad installiert bleiben. Treat-as-withdraw verändert Adj-RIB-In bewusst. Dass die Sitzung keinen Flap zeigt, ist also gerade kein Beleg dafür, dass die Route unverändert blieb.

Die Stärke einer Maßnahme ist ihr Zustandsverbrauch

RFC 7606 ordnet vier Handlungen von stark nach schwach. Der Sitzungsreset beendet die gesamte Sitzung. AFI/SAFI disable begrenzt den Eingriff auf eine Adressfamilie, kann aber alle Routen dieser Familie entfernen und weitere Ankündigungen für sie auf der laufenden Sitzung ignorieren. Die in RFC 4760 beschriebene Familiengrenze ist daher viel breiter als eine einzelne fehlerhafte UPDATE.

Treat-as-withdraw entfernt alle Routen der identifizierten Nachricht. Attribute discard entfernt dagegen nur das fehlerhafte Attribut und verarbeitet die UPDATE weiter. Letzteres darf nach RFC 7606 ausschließlich für Attribute eingesetzt werden, die Auswahl oder Installation nicht beeinflussen. Die lokale Policy kann diese Voraussetzung verändern: Ein Attribut, das im Standardfall lediglich informativ ist, kann in einer Importregel zum Entscheidungssignal werden. Sein Wegfall wäre dann keine semantisch neutrale Reparatur.

Die Spezifikation weist deshalb bestimmten Fehlern bestimmte Handlungen zu. Fehlerfälle bei ORIGIN, AS_PATH, NEXT_HOP, MED oder LOCAL_PREF führen in den überarbeiteten Regeln zu treat-as-withdraw; spezifizierte Fehler bei ATOMIC_AGGREGATE oder AGGREGATOR zu attribute discard. Treten gleichzeitig mehrere Attributfehler auf, gilt die stärkste vorgeschriebene Handlung. Ein Betreiber darf nicht den angenehmsten Eintrag aus der Liste wählen.

Auch Duplikate zeigen, wie eng die Regeln sind. Ein doppeltes MP_REACH_NLRI oder MP_UNREACH_NLRI verlangt weiterhin eine NOTIFICATION wegen einer fehlerhaften Attributliste. Bei anderen doppelten Attributen bleibt die erste Ausprägung erhalten, spätere werden verworfen. „Fehlertoleranz an“ ist somit kein einheitlicher Modus, in dem jede unverständliche Nachricht überlebt.

Erst die Zielgrenze, dann die mildere Behandlung

Treat-as-withdraw setzt voraus, dass der Empfänger die vollständigen NLRI-Felder lokalisieren und erfolgreich parsen kann. Ist nicht zuverlässig erkennbar, welche Ziele die Nachricht enthält, fehlt die Menge, die zurückgezogen werden soll. Dann bleiben Reset nach RFC 4271 und/oder AFI/SAFI disable nach RFC 4760 erforderlich. Besonders Längenfehler können die Grenze zwischen Attributen und nachfolgenden NLRI unklar machen.

Das ist keine konservative Geschmacksfrage, sondern eine Informationsgrenze. Der Empfänger darf nur gezielt Zustand entfernen, wenn er den Zielzustand bestimmen kann. Eine mildere Maßnahme ohne parsebare NLRI wäre kein präzises Containment. Sie könnte unbekannte Teile einer Nachricht stehen lassen oder gültigen Zustand ohne nachvollziehbare Zuordnung verändern.

Moderne Attribute bringen eigene Definitionen mit. Bei BGP Large Communities verlangt RFC 8092 treat-as-withdraw, wenn die Wertlänge kein positives Vielfaches von zwölf Oktetten ist. Doppelte Community-Werte allein sind dagegen nicht fehlerhaft und werden still dedupliziert. Die Reaktion folgt also dem normativ beschriebenen Fehler, nicht der bloßen Auffälligkeit eines Werts.

RFC 6793 wählt für bestimmte fehlerhafte oder kontextwidrige AS4_PATH- und AS4_AGGREGATOR-Fälle attribute discard samt lokaler Protokollierung. Die Übergangsattribute besitzen eine eigene Semantik im Zusammenspiel alter und neuer BGP-Sprecher. RFC 7607 verbietet AS 0 an festgelegten Stellen und verweist je nach Attribut auf RFC 7606 oder RFC 6793. Beide Beispiele zeigen: Capability-Kontext und Attributbedeutung entscheiden, nicht eine pauschale Härteskala.

Das aktuelle IANA-Register der BGP-Parameter ordnet Attributcodes, Fehlercodes und Subcodes ihren Spezifikationen zu. Ein registrierter Code macht ein Attribut identifizierbar. Er ermächtigt aber nicht dazu, eine beliebige lokale Discard- oder Withdraw-Regel zu erfinden. Die verlinkte Spezifikation bleibt die Entscheidungsgrundlage.

Ein grüner Peer kann einen internen Konflikt überdecken

Auf einer EBGP-Grenze kann die begrenzte Wirkung attraktiv erscheinen: Die vielen gültigen Routen des Nachbarn bleiben erhalten. Innerhalb von IBGP entsteht jedoch ein weiteres Risiko. RFC 7606 warnt, dass treat-as-withdraw dort inkonsistente Routenbilder, lang anhaltende Weiterleitungsschleifen oder Blackholes hervorrufen kann. Unterschiedliche Releases, wirksame Einstellungen oder Verteilungspfade können denselben fehlerhaften Zustand verschieden behandeln.

Die empfohlene Reaktion besteht darin, betroffene Routen bis zum Ingress zurückzuverfolgen und die Quelle des fehlerhaften Zustands dort zu filtern. Eine Behandlung an jedem nachgelagerten Knoten einzeln kann die Divergenz konservieren. Route Reflectors müssen in die Prüfung einbezogen werden: Welche Version wurde weitergegeben, welche verborgen, welche erneut angekündigt?

Der Kontrollpfad endet nicht in Loc-RIB. Eine entfernte Route kann in der FIB noch nicht verschwunden sein; eine Ersatzroute kann ausgewählt, aber wegen eines unauflösbaren Next Hops nicht installiert sein. Paketproben aus relevanten Eingangsbereichen und Ausgangszähler zeigen, ob die Dienstwirkung dem erwarteten Zustandswechsel folgt. Eine Stichprobe darf nicht für jede NLRI der gebündelten Nachricht sprechen.

Forensik ist kein Nebenprodukt des Monitorings

RFC 7606 verlangt Debugging-Möglichkeiten, die die betroffenen NLRI nennen und die vollständige fehlerhafte UPDATE für die Ursachenanalyse aufbewahren. Der Nachweis beginnt daher mit der empfangenen PDU, Peer und Richtung, AFI/SAFI sowie Attributcode, Flags und Länge. Erst damit lässt sich die protokollierte Handlung auf die wirkliche Nachricht zurückführen. Das bloße Verschwinden einer Route beweist keinen Syntaxfehler.

BMP Route Mirroring kann eine empfangene Nachricht wortgetreu spiegeln und eine als treat-as-withdraw behandelte Errored PDU kennzeichnen. RFC 7854 kennt zugleich die Meldung Messages Lost. Puffer können erschöpft sein, Mirroring kann ausgewählt oder begrenzt werden und kostet Ressourcen. Ein fehlender Datensatz ist deshalb nur dann aussagekräftig, wenn auch der Verluststatus bekannt ist.

Offizielle Herstellerdokumente helfen bei der konkreten Umsetzung, aber nicht bei einer universellen Defaultbehauptung. Cisco IOS XR beschreibt Fehlerklassen, TreatAsWithdraw und DiscardAttr sowie Syslogs mit Neighbor-, Längen-, Attribut-, Familien- und NLRI-Kontext. Junos dokumentiert Reset, versteckte Routen, treat-as-withdraw, attribute discard und releasespezifische Einstellungen. Nokia SR OS beschreibt update-fault-tolerance und den Unterschied zur älteren Behandlung. Syntax, Vererbung und Voreinstellung bleiben plattform- und releasespezifisch.

Die saubere Ersatznachricht schließt den Fall noch nicht

Nach der Korrektur beim Sender muss der Empfänger eine gültige Ersatz-UPDATE sehen. Danach sind Adj-RIB-In, verborgener oder abgelehnter Zustand, Loc-RIB, nachgelagerte Ankündigungen und FIB erneut zu vergleichen. Paketmessungen prüfen die Erreichbarkeit. Der Wiederaufbau ist erst belegt, wenn keine veraltete Route, keine Wiederholung der fehlerhaften Nachricht und keine Divergenz zwischen Knoten zurückbleibt.

Ein sofortiger Reset kann denselben Fehler erneut importieren, solange der Sender nicht korrigiert ist. Eine tolerante Behandlung kann wiederum eine Folge aus Entfernen und Wiederankündigen erzeugen. Diese Oszillation hält die Sitzung grün und verbraucht zugleich Diagnosepuffer. Erfolgsmetriken brauchen deshalb eine Routebene: Welche NLRI verschwanden, welche kamen sauber zurück, und welchen Weg nahmen die Pakete danach?

RFC 7606 macht Fehler nicht harmlos. Es ermöglicht, den Verbrauch gültigen Routingzustands genauer an die erkennbare Fehlergrenze anzupassen. Verantwortliches Handeln heißt, diese Grenze zu belegen. Wer nur den Peerstatus misst, verwechselt die Fortsetzung des Gesprächs mit der Verlässlichkeit dessen, was darin gesagt wurde.