Zusammenfassung

  • Route Flap Damping (RFD) reagierte auf eine reale Grenze der frühen Internet-Infrastruktur: Wiederholte BGP-Änderungen konnten knappe Rechenleistung auf Routern verbrauchen und weitere Instabilität auslösen.
  • Der Strafzähler unterschied nicht zwischen einem dauerhaft fehlerhaften Anschluss und der Suche nach Alternativpfaden, die BGP nach einem normalen Rückzug durchführt. Deshalb konnte ein repariertes Präfix in Netzen unterdrückt bleiben, die sein Inhaber nicht kontrollierte.
  • Die wirksame Autorität lag nicht bei einer einzelnen Organisation. RFC-Autoren beschrieben den Mechanismus, Hersteller machten aus Parametern ausführbares Verhalten, Betreiber entschieden über seinen Einsatz.
  • Nach Messungen der Konvergenzschäden führte der operative Weg von abgestimmten Parametern über eine breite Empfehlung zum Abschalten zu vorsichtigeren Schwellen. Ein selektiver Algorithmus wurde nicht zum üblichen Nachfolger, den die späteren Dokumente festhielten.

Drei Zustandswechsel, die wie drei Fehler aussahen

RIPE-229 schildert eine Wartung, an der sich der ganze Konflikt ablesen lässt. Ein geplanter Softwarewechsel erforderte einen Neustart: ein Flap. Die neue Software stürzte ab: ein zweiter. Der Betreiber lud die alte Version erneut: ein dritter. Innerhalb von zehn Minuten hatte sich der Zustand dreimal geändert. Tatsächlich hatte das Netz eine Änderung ausprobiert, einen Fehler erkannt und den bekannten Zustand wiederhergestellt.

Ein Strafzähler sah diese Absicht nicht. An manchen Transit- und Peering-Grenzen galten aggressive, nach Präfixlänge abgestufte Einstellungen. Laut Dokument wurden /24-Routen des Betreibers und seiner Kunden dort länger als drei Stunden unterdrückt. Die Behebung des Problems erzeugte genau die Signale, mit denen der Mechanismus problematisches Verhalten erkennen sollte.

Die Erfahrung floss in eine koordinierte Empfehlung ein. Bei RIPE 27 entschieden die Beteiligten, eine Unterdrückung nicht vor dem vierten aufeinanderfolgenden Flap zu beginnen und die maximale Dauer nach dem letzten Flap auf eine Stunde zu begrenzen. Das war milder als das beobachtete Verhalten. Es bedeutete aber weiterhin, dass eine funktionierende /24 nach Überschreiten der Schwelle eine Stunde lang fehlen konnte.

Warum RFD zunächst die vernünftige Wahl war

Die Gegenüberstellung „Damping oder gar kein Problem“ wäre für die frühen 1990er Jahre falsch. Die Routingtabellen wuchsen, die Pfade zwischen Providern wurden dichter, und jeder Rückzug musste von Geräten verarbeitet werden, deren Reserven mit heutigen Routern nicht vergleichbar waren. Eine Update-Welle konnte Sitzungen überlasten; abgebrochene Sitzungen erzeugten neue Updates und verschärften das Problem.

Die Betriebsdokumente datieren die Entwicklung von RFD auf 1993 und Implementierungen in Cisco-, ISI/RSd- und GateD-Software auf 1995. Als RFC 2439 im November 1998 erschien, beschrieb er eine Technik, die bereits in kommerziellen Produkten vorhanden und weit verbreitet war. Die Ziele waren präzise: Rechenlast verringern, anhaltende Oszillation begrenzen und normalerweise gut funktionierende Routen nicht unnötig verzögern.

Betreiber konnten Update-Lärm hinnehmen, Sitzungen begrenzen oder schließen, Damping mit eigenen Werten konfigurieren oder gemeinsame Parameter übernehmen. Die gemeinsame Variante setzte sich durch, weil sie lokale Autonomie mit besserer Vorhersagbarkeit verband. Bereits vorhandene Zähler neu einzustellen war billiger und leichter rückgängig zu machen, als BGPs Umgang mit Pfadereignissen grundlegend neu zu bauen.

Koordination war keine zentrale Weisungsbefugnis

Nach RIPE 26 entstand bei RIPE 27 eine Taskforce. Parameter von Tony Barber bei UUNET dienten als Grundlage für RIPE-178; RIPE-229 änderte die Empfehlung nach den Erfahrungen mit langer Unterdrückung. Dieser Ablauf zeigt, dass kein einzelnes Dokument den Mechanismus erfand oder allein legitimierte.

RFC 2439 beschrieb Strafwerte, ihren zeitlichen Zerfall sowie Suppress- und Reuse-Schwellen. Er gab IETF oder RIPE jedoch keine Kontrolle über fremde Router. Hersteller bestimmten, welche Schalter verfügbar waren und welche Voreinstellungen ausgeliefert wurden. Betreiber aktivierten die Funktion und entschieden, welche Routen ihr Netz akzeptierte. Diese lokale Befugnis ist technisch real; ihre Kosten blieben nicht lokal.

Hier trennen sich formelle Regel und tatsächlicher Betrieb. Ein Standard dokumentiert eine Möglichkeit. Software macht sie ausführbar. Eine Konfiguration setzt sie gegenüber einem konkreten Präfix durch. Wird die gesamte Kette nur „Konsens“ genannt, bleibt unklar, wer für einen falschen Ausschluss verantwortlich ist. Fachliche Koordination kann eine Entscheidung legitimieren, ersetzt aber weder eine zentrale rechtliche Ermächtigung noch den Nachweis fair verteilter Folgen.

BGP erzeugte zusätzliche Flaps aus einem einzigen Rückzug

Die wichtigste Kritik stützte sich nicht auf eine Vermutung über Absichten, sondern auf Messungen. Mao und Mitautoren zeigten 2002 auf der SIGCOMM, dass ein Rückzug nicht als einzelnes Ereignis durch das Netz läuft. Während der Konvergenz probiert BGP alternative Pfade. Änderungen von Pfaden und Attributen können dadurch zusätzliche Strafen erzeugen, obwohl am Ursprung kein neuer Fehler auftrat.

In den untersuchten Topologien konnte ein Rückzug mit anschließender Wiederankündigung reichen, um ein Präfix bis zu einer Stunde zu unterdrücken. Ein gemessener Vorfall erzeugte 41 sichtbare Pfadänderungen. RFD bewertete damit nicht nur das Verhalten eines Anschlusses, sondern zugleich Topologie, Nachrichtentakt und die eigene Pfadsuche des Protokolls.

Die Forscher schlugen einen selektiven Algorithmus vor. Ereignisse, die wahrscheinlich zur Pfadexploration gehörten, sollten nicht wie unabhängige Fehler bestraft werden; eine Zeitgrenze sollte echten Dauerfehlern dennoch begegnen. Das war die sachnähere Reparatur. Sie erforderte aber komplexere Implementierungen. Höhere Schwellen oder das Abschalten waren einfacher auszurollen, zu erklären und zurückzunehmen.

Erst abschalten, später vorsichtig neu einstellen

RIPE-378 empfahl 2006, RFD nach den bestehenden Empfehlungen nicht zu verwenden. Das Dokument verwies auf fehlende Nachfrage der Provider nach dem selektiven Verfahren, fehlende Aktivität der Hersteller und stärkere Routerprozessoren. Es behauptete nicht, Routing-Lärm sei bedeutungslos geworden. Es stellte fest, dass die geerbte Abwägung zwischen Lastschutz und Konvergenzschaden nicht mehr trug.

Ein Entwurf einer Einsatzumfrage von 2012 liefert begrenzte, nicht repräsentative Hinweise. Unter 63 selbst ausgewählten Teilnehmern nutzten 13 RFD, 49 nicht; 15 Nichtnutzer verwiesen auf RIPE-378. Die Zahlen sind keine Weltzählung. Sie zeigen aber, wie ein Betriebsdokument ohne Weisungsgewalt zum Koordinationspunkt für Abschaltentscheidungen werden konnte.

Die Geschichte endete nicht mit einem endgültigen Verbot. RIPE-580 verglich später konservativere Parameter, und RFC 7196 beschrieb 2014, wie Damping wieder nutzbar werden könne. In der Messwoche von RIPE-580 verringerte eine Schwelle von 6000 die BGP-Update-Rate um etwa 19 Prozent und dampfte rund 90 Prozent weniger Präfixe als die alte Schwelle von 2000. Bei 12000 wurden 0,22 Prozent der Präfixe gedämpft, während die Update-Rate noch um etwa 11 Prozent sank. Die neue Selektivität entstand durch Zahlen, nicht durch den vorgeschlagenen Algorithmus.

RFC 7196 warnte davor, Voreinstellungen stillschweigend zu ändern. Der Betriebszustand sollte eine bewusste Entscheidung bleiben. Für eine Tabelle existiert ein verifiziertes, als informativ eingestuftes Erratum; es ändert die Kernaussage nicht. Beides markiert eine Grenze: Selbst eine bessere Zahl ist kein verlässlicher Schutz, wenn niemand belegen kann, welche Implementierung und Konfiguration tatsächlich entscheidet.

Das Netz mit dem Zähler trug nicht dieselbe Rechnung

Ein RIR dokumentiert die Zuteilung eines Nummernressource. Das Ursprungsnetz kann eine Route über seine Verbindungen ankündigen. Weder Register noch Ursprung besitzen jedoch einen allgemeinen Anspruch darauf, dass jedes entfernte Netz die Route sofort akzeptiert. Der entfernte Betreiber kontrolliert Filter, Auswahlregeln und Damping. Der Hersteller kontrolliert Voreinstellungen und Beobachtbarkeit. Standardisierungsgremien und Betriebsgemeinschaften verfügen über Koordinations- und Überzeugungsmacht, nicht über den Schalter.

Der dämpfende Betreiber profitiert von weniger Updates und geringerer lokaler Last. Auch Nachbarn können profitieren, wenn eine echte Update-Welle endet. Das Risiko eines Fehlalarms tragen dagegen der Präfixinhaber und dessen Nutzer. Sie wissen oft nicht, welches Netz unterdrückt, wie hoch die Strafe ist oder wann die Wiederverwendungsschwelle erreicht wird.

Die Abstufung nach Präfixlänge verband das Ziel der Aggregation mit höheren Kosten für kleine Netze. Ausnahmen für sogenannte „Golden Networks“, darunter bestimmte DNS-Root- und TLD-Infrastrukturen, zeigten, dass die Folgen eines Fehlers als ungleich erkannt wurden. Die Ausnahme schuf zugleich eine Legitimationsfrage: Wer bestimmt, welche Infrastruktur besonders geschützt wird, während andere Präfixe unter der normalen Regel bleiben?

Quellen