Zusammenfassung

  • Nach einem HA-Upgrade eines Firewall-Paars hatte Router B 121 Sekunden lang keine BGP-Präfixe, obwohl die Sitzungen Established meldeten und der Verkehr weiter zur Firewall lief.
  • Paketmitschnitte und ein Labortest des Vortragenden führten den Stillstand auf einen Fehler beim IPv6-Peerkontext und einen TCP Reset zurück. Das Warten auf IPv6-End-of-RIB verzögerte auch die Installation der IPv4-Routen.

Established klang beruhigend. Die Routingtabelle war deutlicher: 121 Sekunden lang null Präfixe.

Diesen Vorfall schilderte Marian Rychtecký auf der NANOG 98. Während des Hochverfügbarkeits-Upgrades eines Firewall-Paars kehrten die BGP-Sitzungen in den Zustand Established zurück, Router B erhielt jedoch keine Präfixe. Der Verkehr wurde weiterhin zur Firewall geschickt. Dort waren die erwarteten Routen noch nicht installiert; die Pakete verschwanden fast zwei Minuten lang im schwarzen Loch.

Die entscheidende Zahl sind 121 Sekunden. End-of-RIB traf nahe am 120-Sekunden-Reconnect-Timer ein. Der Timer war ein Hinweis, aber keine vollständige Erklärung. Rychteckýs Fehlersuche ergab, dass die IPv4-Wiederherstellung auf eine bestimmte IPv6-BGP-Sitzung wartete. Graceful Restart behandelte den ausgehandelten Peer-Zustand erst nach dem End-of-RIB-Marker als abgeschlossen. Eine festhängende Sitzung in einer Adressfamilie hielt so die Routen der anderen zurück.

Paketmitschnitte zeigten einen TCP Reset auf der neuen Sitzung. Im Labortest wurde die erwartete IPv6-Peer-Adresse 2001:db8:1::2 als 2001:db8:1: gespeichert. Das Betriebssystem konnte die Verbindung nicht dem richtigen VRF- und BGP-Kontext zuordnen und schickte einen Reset zurück. Während eines Teils des Failovers galt die alte TCP-Verbindung noch als aktiv; die neue Sitzung lief in diesen Altzustand hinein.

Die Aussage ist präziser als „Graceful Restart kann scheitern“. Eine grüne BGP-Sitzung belegte weder eine gefüllte Routingtabelle noch funktionierende Weiterleitung. Der Firewall-Upgrade löste den Vorfall aus. Die falsch gelesene Peer-Adresse und das Warten über Adressfamilien hinweg erklären den Mechanismus. Leere RIB und verworfene Pakete waren die Folgen.

Der Vortragende berichtet, dass ein kürzerer Verbindungstimer in diesem Fall den Verbindungsaufbau und den End-of-RIB-Austausch beschleunigte. Das ist eine für diese Konfiguration gemeldete Übergangslösung, kein allgemeiner Sollwert: Eine verkürzte Wartezeit kann an anderer Stelle ein neues Fehlerfenster öffnen. Ein belastbarer Test muss die ganze Kette abdecken: TCP-Neuverbindung, End-of-RIB je Adressfamilie, Routeninstallation und tatsächliche Paketzustellung.

Die Folien nennen weder Gerätemodelle noch Firmwareversionen oder Messwerte zu verlorener Kundenkommunikation; erst diese Unterlagen würden zeigen, ob ein einzelner Implementierungsfehler oder ein verbreitetes Muster vorlag.

Quellen