Zusammenfassung

  • RFC 2439 machte Instabilität zu einem lokalen Zustandswert: Rückzüge erhöhten die Merit-Zahl einer Route, exponentielles Abklingen senkte sie; getrennte Suppress- und Reuse-Schwellen bestimmten, wann der Pfad ausgesetzt und wann er wieder verwendbar wurde.
  • Spätere Betriebserfahrung zeigte, dass dieses Gedächtnis ein gut angebundenes Präfix auch während normaler Konvergenz bestrafen konnte. RFC 7196 schaffte Damping nicht ab, sondern empfahl vorsichtigere Schwellen und einen optionalen Modus, der nur rechnet und nicht unterdrückt.

Die Vergangenheit einer Route blieb gegenwärtig

In den 1990er Jahren beschrieben BGP-Updates nicht nur erreichbare Ziele. Ihr Volumen beanspruchte auch Rechenzeit beim empfangenden Router und bei Peers, die weitergeleitete Ankündigungen erhielten. RFC 2439 sollte wiederholte Änderungen eindämmen, ohne die Konvergenz relativ stabiler Routen zu verzögern. Das Standards-Track-Dokument berichtete bei seiner Veröffentlichung 1998 bereits von kommerziellen Implementierungen. Das ist ein Befund über jene Zeit, keine Aussage zu heutigen Konfigurationen. RFC 2439 RFC-2439-Eintrag

Die entscheidende Neuerung war, mehr als nur das jüngste UPDATE zu speichern. Ein Router, der eine Route von einem externen Peer erhielt, konnte für eine Routenidentität einen Merit-Wert führen. Jeder Übergang von erreichbar zu nicht erreichbar erhöhte die Strafe; solange die Route stabil blieb, sank der akkumulierte Wert exponentiell. Der Wert diagnostizierte weder ein defektes Kabel noch böse Absicht eines Peers. Er hielt fest, welche Änderungen ein Router kürzlich beobachtet hatte, und beeinflusste, ob dieser den Pfad nutzte oder ankündigte. RFC 2439

Damit entstand eine zeitliche Lücke zwischen zurückgekehrter Erreichbarkeit und erneuter Verwendbarkeit. Die Cutoff- oder Suppress-Schwelle bestimmte, wann eine Route zurückgehalten wurde. Eine niedrigere Reuse-Schwelle legte fest, wann sie zurückkehren durfte; eine maximale Hold-down-Zeit begrenzte die Unterdrückung. Erreichbarkeit, Strafwert, Unterdrückungszustand und Best-Path-Auswahl hingen zusammen, waren aber nicht dieselbe Aussage. Ein Peer konnte eine Route erneut ankündigen, während der empfangende Router sie weiterhin unterdrückte. RFC 2439

Gedächtnis nach Vorgeschichte statt allgemeiner Warteuhr

RFC 2439 unterschied stabilitätsabhängiges Damping von einer festen Ankündigungsrate. Das Minimum Route Advertisement Interval taktet BGP-Updates; Damping richtet sich nach der jeweiligen Änderungsgeschichte einer Route. Solange ihr Wert unter der Cutoff-Schwelle liegt, kann der Pfad nutzbar bleiben. Nach der Unterdrückung wird er erst wieder verwendet, wenn der sinkende Wert unter die Reuse-Schwelle fällt. Verschiedene Routen müssen daher nicht nach jeder Änderung dieselbe Zeit warten. RFC 2439 BGP-4

Die Parameter haben unterschiedliche Aufgaben. Die Halbwertszeit bestimmt, wie schnell der Wert bei erreichbarer Route sinkt; im nicht erreichbaren Zustand kann die Implementierung eine andere Rate oder keine Abklingrate nutzen. Eine höhere Cutoff-Schwelle toleriert mehr Änderungen. Eine niedrigere Reuse-Schwelle verlangt längere Stabilität vor der Rückkehr. Im Beispiel von RFC 2439 kann eine Route unter bestimmten Parametern nach zwei oder drei Rückzügen unterdrückt werden und danach etwa eineinhalb bis zweieinhalb Halbwertszeiten stabil angekündigt sein müssen, bevor sie wieder verwendet wird. Das gilt unter den Beispielannahmen, nicht als Zusage für jeden Router. RFC 2439

Auch der Anwendungsort war begrenzt. RFC 2439 zielte auf Updates, die von externen Peers empfangen wurden, und warnte, dass Damping von iBGP-gelernten oder bereits ausgewählten Routen Schleifen verursachen könne. Die Routenidentität sollte mindestens das NLRI und standardmäßig auch den AS_PATH umfassen. Eine Strafe, die nur am Präfix hängt, erzählt eine andere Geschichte als eine Strafe für einen bestimmten Pfad zu diesem Präfix. RFC 2439

Implementierungsdetails verteilten die Kosten neu

Der Betriebsbericht RFC 4277 von 2006 stellte fest, dass die damals untersuchten Implementierungen die Historie entgegen der Vorgabe aus RFC 2439 nicht nach eindeutigem NLRI oder AS_PATH führten. In einem dicht vermaschten Netz könne das ein Ziel übermäßig stark unterdrücken, im Extremfall schon nach einem einzigen Fehler; solche negativen Effekte seien beobachtet worden. Das ist ein begrenzter, dem Bericht zugeordneter Befund, keine Aussage über alle Router. RFC 4277 behandelte außerdem Peer-Session-Damping bei anhaltenden Fehlern getrennt vom Damping einzelner Routen. RFC 4277 RFC 2439

2014 beschrieb RFC 7196 weitere Kosten: Eine topologisch reich vernetzte Umgebung kann während normaler Konvergenz mehr UPDATEs erzeugen und damit gerade gut angebundene Präfixe bestrafen. In der zitierten Wochenmessung unterdrückte eine Schwelle von 6.000 gegenüber 2.000 90 Prozent weniger Präfixe und senkte die UPDATE-Rate gegenüber keinem Damping geschätzt um 19 Prozent. Bei 12.000 waren 0,22 Prozent der Präfixe gedämpft; die durchschnittliche stündliche Update-Rate sank um 11 Prozent. Das sind Ergebnisse des zitierten Messzeitraums, keine universellen Vorhersagen. RFC 7196

RFC 7196 empfahl mindestens 6.000 für weniger zerstörerisches, aber noch etwas aggressives Damping und 12.000 für einen konservativen Betrieb. Zugleich sollten Implementierungen bestehende konfigurierbare Standardwerte nicht ändern, damit etablierte Betriebsabläufe nicht brechen. Ein Testmodus durfte außerdem berechnen, welche Routen unterdrückt würden, ohne sie tatsächlich zu sperren. Die Antwort von 2014 lautete: messen und justieren – nicht, dass Damping immer schädlich sei oder eine Zahl zu jeder Topologie passe. RFC 7196

Die Geschichte ist kein einfacher Wechsel von „Damping an“ zu „Damping aus“. RFC 2439 ließ die Vergangenheit einer Route ihre unmittelbare Wiederverwendung beeinflussen. RFC 4277 zeigte, dass die von einer Implementierung gespeicherte Routenidentität die Strafe ausweiten konnte. RFC 7196 behandelte normale Konvergenz und gute Konnektivität als Kosten, die vor einer Unterdrückung gemessen werden sollten. Ein Damping-Wert beweist weder einen physischen Defekt noch einen bösartigen Ursprung oder einen flächendeckenden Dienstausfall. RFC 2439 RFC 4277 RFC 7196 Scalable Routing Design Principles Datatracker-Eintrag RFC 2439

Quellen