Zusammenfassung

  • Der MinRouteAdvertisementIntervalTimer begrenzt, wie häufig ein BGP-Speaker demselben Peer Änderungen für dasselbe Ziel ankündigt. Der lokale Entscheidungsprozess läuft währenddessen weiter.
  • Wechselt die lokale Auswahl im Intervall mehrfach, verlangt RFC 4271 am Ende die Ankündigung des zuletzt gewählten Pfades. Der Nachbar erhält den aktuellen Stand, nicht die vollständige lokale Geschichte.
  • Ein kurzes Intervall erkauft Frische mit mehr UPDATEs und verteilter Rechenarbeit; ein langes bündelt Unruhe, kann aber Ausfall-, Ersatz- oder Reparaturwissen verzögern.

Ein Präfix genügt als Beispiel. Um 10:00:00 wird Pfad A gewählt und angekündigt. Vier Sekunden später fällt A aus, B wird bester Pfad. Nach weiteren fünf Sekunden bevorzugt eine lokale Policy C. Das lokale RIB hat drei Zustände gesehen, das FIB womöglich mehrere verwendet. Der Peer hört möglicherweise nur A und danach C. B war betrieblich real, wurde aber nie zu einer externen Aussage.

Diese zeitliche Verdichtung ist das Minimum Route Advertisement Interval, MRAI. RFC 4271 beschreibt die Mindestzeit zwischen aufeinanderfolgenden UPDATEs an einen Peer, wenn sie einen gemeinsamen Satz von Zielen betreffen. Der Wert wird je Peer festgelegt, die begrenzende Wirkung gilt je Ziel. Eine gemeinsame Kadenz bedeutet nicht, dass alle voneinander unabhängigen Präfixe logisch in einer einzigen Warteschlange stehen müssen.

Die Spezifikation fordert auch kein buchstäbliches Timerobjekt für jedes Ziel. Dieser Zustand könnte selbst unvertretbar groß werden. Eine andere Planung ist zulässig, wenn sie den Mindestabstand und zugleich eine konstante Obergrenze für die Verzögerung garantiert. Gemeinsamer Vertrag ist das von außen beobachtbare Zeitverhalten, nicht die interne Datenstruktur.

Während des Wartens stoppt die BGP-Entscheidung nicht. Eingehende UPDATEs werden bewertet, der beste Pfad kann wechseln, das lokale Forwarding kann folgen. Warten muss nur die nächste Aussage an diesen Nachbarn über das betroffene Ziel. Gab es mehrere Auswahlen, wird bei Ablauf die letzte angekündigt. Der Empfänger kennt damit das jüngste erlaubte Ergebnis, aber nicht zwangsläufig dessen Entstehung.

Die Ersparnis ist konkret. Ein kurzlebiger Zwischenzustand löst nicht bei jedem nachgelagerten Router eine Nachricht und erneute Auswahl aus. RFC 4271 ordnet MRAI der Kontrolle des Routing-Overheads zu und nennt UPDATE-Bandbreite sowie Rechenaufwand des Decision Process. Der Wunsch eines Systems nach sofortiger Mitteilung kann andernfalls zur Arbeit vieler fremder Systeme werden.

Die historische Forschung erklärt die Vorsicht. Die SIGCOMM-Studie von 1997 zur Routing-Instabilität fand in den untersuchten Austauschpunktdaten weit mehr pathologische Ankündigungen, als dauerhafte Topologieänderungen erwarten ließen. Ihre Zahlen sind keine Beschreibung des Jahres 2026. Sie zeigen aber, dass BGP sehr viel Arbeit transportieren kann, ohne proportional stabiles Wissen zu erzeugen.

Die SIGCOMM-Studie von 2000 zur verzögerten Konvergenz zeigte die Gegenrechnung. Passive Messungen und kontrollierte Fehlereinspeisungen ergaben, dass interdomain Ausfall, Umschaltung und Reparatur Minuten dauern konnten. Unabhängige Auswahl und Path Exploration verursachten vorübergehenden Verlust und Verzögerung. MRAI war nicht die einzige Ursache; dennoch kann ein Mechanismus, der Nachrichten einspart, auch das Eintreffen verteilten Wissens verlängern.

Ein kleiner Wert ist deshalb nicht automatisch besser. Er kann einen brauchbaren Ersatz früher zeigen, aber auch jede Zwischenstufe der Path Exploration an viele Entscheidungsprozesse exportieren. Synchronisierte Peers erzeugen Lastspitzen. RFC 4271 empfiehlt daher für MRAI und andere Timer Jitter: Nicht nur die durchschnittliche Menge, auch Gleichzeitigkeit entscheidet über die Belastung.

Ein großer Wert ist nicht automatisch sicherer. Er kann flüchtige Auswahlwechsel zusammenfassen, zugleich aber eine gültige Reparatur zurückhalten, während Kunden des Nachbarn Erreichbarkeit verlieren. Der Sender verwendet vielleicht schon C, während der Empfänger noch auf A, einen früheren Rückzug oder gar keinen Pfad reagiert. Schutz ohne Frischebudget verlagert lokale Kosten nach außen.

Erste Ankündigungen und Withdrawals verlangen genaue Sprache. RFC 4271 definiert Abstände zwischen relevanten aufeinanderfolgenden UPDATEs, keine universelle volle Wartezeit vor jeder ersten Ankündigung. Vorherige Werbung, aktiver Scheduler und Implementierung bestimmen den Effekt. Die Behauptungen, Withdrawals seien immer sofort oder immer verzögert, sind ohne Plattform- und Versionsbeleg gleichermaßen unhaltbar.

Interne und externe Beziehungen haben verschiedene Ziele. RFC 4271 betont schnelle Konvergenz innerhalb eines AS und empfiehlt für iBGP ein kürzeres Intervall oder den Verzicht auf das Verfahren bei intern versandten Routen. Das ist kein Befehl, überall null einzustellen. Es erkennt an, dass ein AS seine frischen Entscheidungen nicht kohärent nutzen kann, wenn die eigene Verteilung sie unnötig verbirgt.

Die Vorschläge von 30 Sekunden für eBGP und fünf Sekunden für iBGP werden oft als universelle Defaults zitiert. Das sind sie nicht. RFC 4273 macht einen verwaltbaren Timer je Peer sichtbar und wiederholt die Vorschläge; Produkte unterscheiden Kontexte. Die zitierte Cisco-IOS-Dokumentation nennt für die behandelten Familien 30 Sekunden bei gewöhnlichem eBGP, null bei iBGP und null bei eBGP in einer VRF. Andere Plattformen und Releases dürfen abweichen.

Konfigurationshierarchien schaffen weitere Scheinsicherheit. Ein Wert kann aus Address Family, Neighbor, Peer Group, Neighbor Group oder Session Group stammen. Vorrangregeln können bewirken, dass die gelesene Zeile nicht die wirksame ist. Betriebsdaten wie die von IOS XR gemeldete Mindestzeit zwischen Ankündigungsläufen sind stärkere Belege als die Absicht der übergeordneten Konfiguration.

Auch der wirksame Wert beweist noch keine Wirkung. Für dasselbe NLRI müssen Zeitpunkte von lokalem Best Path, Adj-RIB-Out-Änderung, MRAI-Warteschlange, gesendetem UPDATE, Peer-Empfang sowie FIB- und Erreichbarkeitsereignis zusammengeführt werden. Erst dann lässt sich erkennen, wie viele Zwischenentscheidungen verdichtet wurden und ob eine davon Verlust vermieden hätte. Weniger UPDATEs allein sind kein Gesundheitsnachweis.

MRAI ist nicht Route Flap Damping. Damping speichert historische Instabilität als abklingende Strafe und kann eine Route unterdrücken. MRAI bewertet die Geschichte der Route nicht; es ordnet Aussagen an einen Peer zeitlich. Eine Route kann lokal ausgewählt und benutzt werden, während ihre Ankündigung wartet. Sie wurde nicht gedämpft.

MRAI ist ebenso wenig ein Liveness-Timer. HoldTimer und Keepalive entscheiden über das Fortbestehen der BGP-Sitzung. BFD kann einen Forwarding-Fehler früh erkennen. Frühe Erkennung beschleunigt die lokale Auswahl, garantiert aber nicht, dass das daraus entstehende UPDATE die Ausgangskadenz umgeht. RFC 7938 verlangt deshalb, MRAI in der Ereignisfortpflanzung von Rechenzentren zu berücksichtigen.

ADD-PATH verändert, was gesagt werden kann, nicht wann jede Aussage hinaus darf. Mehrere Pfade eines NLRI können unter eigenen Kennungen bestehen und Alternativen sichtbar machen, die Best-only-Ankündigungen verbergen. Dadurch wird nicht jede lokale Zwischenauswahl wertvoll und der Ausgangsscheduler verschwindet nicht. Sichtbarkeit und Kadenz bleiben getrennte Stellflächen.

In einer BGP-Beziehung liegt somit eine asymmetrische zeitliche Delegation. Der Sender entscheidet, wie häufig Änderungen offengelegt werden; der Empfänger trägt das Alter des Wissens. Er kann während des Intervalls kein UPDATE erzwingen. Er kann Ankunftsabstände messen, Erwartungen vereinbaren, Upstreams diversifizieren und festlegen, wie viel veraltetes Wissen er toleriert.

Heng Lus Prinzip der minimalen Anfangsspezifikation passt zu dieser Grenze. Das gemeinsame Protokoll muss genug Zeitverhalten definieren, um Interoperabilität und begrenzte Last zu sichern. Es soll Netzen mit verschiedenen Prozessoren, Topologien, Peerrollen und Kundenfolgen keinen Einheitswert aufzwingen. Die Wahl bleibt lokal, weil Kosten lokal sind — sofern ihre Wirkung für die Betroffenen sichtbar bleibt.

Die Primatstellung des laufenden Codes liefert den Rechenschaftstest. Der konfigurierte Wert ist Absicht. Wirksame Vererbung, Scheduler, UPDATE-Trace, Beobachtung des Peers und Paketlieferung sind das System. Zeigt die laufende Evidenz, dass ein „schützender“ Timer Kundenausfall verlängert, verteidigt ein erfolgreicher Commit die Entscheidung nicht.

Drei Auswahlen in einer Nachricht sind weder Täuschung noch gereinigte Wahrheit. Es ist eine Scheduling-Entscheidung. Die letzte Route ist die jüngste lokale Antwort zum erlaubten Zeitpunkt, keine zertifizierte stabile Zukunft. Führung beginnt damit, den Tausch zu benennen: weniger Kontrollarbeit gegen älteres verteiltes Wissen.

Quellen