Zusammenfassung

  • Der BGP-MED ist ein optionales, nicht transitives und bewusst schwaches Attribut. Ein niedrigerer Wert wirkt nur innerhalb der Kandidatenmenge und Policy des empfangenden Netzes.
  • Ein Update oder Looking Glass mit dem gewünschten Wert beweist nicht, dass alle relevanten Router diesen Eingang gewählt, in die FIB übernommen oder Produktionsverkehr darüber geleitet haben.
  • Eine belastbare Ingress-Aussage verbindet Anzeigen, Import-Policy, vergleichbare Kandidaten, Best Paths, Forwarding-Zustand und Verkehrsmessungen in einem festgelegten Beobachtungsfenster.

Die kleinere Zahl und der unveränderte Link

Angenommen, ein Netz senkt während eines Wartungsfensters den MED an einem von zwei Interconnects. Ein Route Collector zeigt den neuen Wert. Der Change scheint beinahe abgeschlossen: Das Attribut ist sichtbar, die kleinere Zahl wirkt eindeutig, und keine Route wurde zurückgezogen. Die Interface-Zähler zeigen jedoch weiterhin, dass der Großteil des eingehenden Verkehrs am anderen Standort ankommt.

Das bedeutet nicht, dass BGP den MED ignoriert hat. Das empfangende Netz könnte einen anderen LOCAL_PREF vergeben, einen kürzeren AS_PATH bevorzugt, den MED beim Import normalisiert, ihn nur zwischen Routen desselben benachbarten AS verglichen oder auf verschiedenen Routern verschiedene Pfade gewählt haben. Das beobachtete Update beweist eine engere Tatsache: Ein bestimmter Speaker hat ein bestimmtes Attribut angekündigt. Es beweist weder die vollständige entfernte Entscheidung noch die daraus folgende Paketbewegung.

Präferenzsignal statt Steuerbefehl

RFC 4271 definiert MULTI_EXIT_DISC als optionales, nicht transitives Vier-Oktett-Maß zur Unterscheidung mehrerer Ein- oder Austrittspunkte zum selben benachbarten AS. Wenn alle anderen Faktoren gleich sind, soll der kleinere Wert bevorzugt werden. Jede Einschränkung zählt: Das Attribut ist optional, wird nicht an ein weiteres benachbartes AS weitergegeben und nach der Grundregel nur zwischen Routen desselben benachbarten AS verglichen. „Alle anderen Faktoren gleich“ setzt MED außerdem hinter Policy-Entscheidungen, die eine Route bereits vorher ausschließen können.

Die Entscheidungsgewalt liegt beim empfangenden Netz. RFC 4271 verlangt einen lokalen Mechanismus zum Entfernen des MED und erlaubt, empfangene Werte vor der Pfadauswahl lokal zu verändern. Ein Peer kann den Wert übernehmen, ersetzen, im vorgesehenen Vergleich ignorieren oder ihn aufgrund einer implementierungsspezifisch erweiterten Policy anders vergleichen. Der Absender kann eine Präferenz äußern; er kann sich nicht selbst die Entscheidungsgewalt auf der Gegenseite verleihen.

Auch ein fehlender MED braucht eine explizite Vereinbarung. Die aktuelle Basisspezifikation behandelt eine Route ohne Attribut im definierten Vergleich wie den kleinstmöglichen Wert. RFC 4451 dokumentiert historische Unterschiede zwischen Implementierungen und Spezifikationen, darunter die gegenteilige Behandlung eines fehlenden MED. Viele Betreiber setzen den MED deshalb am Ingress auf einen festen Wert zurück. Ein Dashboard mit 50 gegenüber 100 bleibt unvollständig, solange es nicht zeigt, wie fehlende Werte behandelt und wo Werte normalisiert wurden.

Die Kandidatenmenge ist der eigentliche Nenner

MED hat nur für Routen Bedeutung, die bis zu seiner Vergleichsstufe gelangen. Eine Route mit kleinerem MED kann zuvor gegen LOCAL_PREF, AS_PATH-Länge oder ein anderes Policy-Ergebnis verlieren. Eine Route aus einem anderen benachbarten AS gehört nach der Grundregel nicht in denselben MED-Vergleich. Wer den Vergleich über mehrere autonome Systeme aktiviert, ändert diese Annahme und kann nicht vergleichbare Metrikräume vermischen.

RFC 4451 warnt vor stark unterschiedlichem MED-Verhalten und davor, dass Werte verschiedener autonomer Systeme unbeabsichtigte, gewichtete Entscheidungen erzeugen können. Das Dokument beschreibt außerdem, wie Route-Reflection- und Confederation-Topologien die fehlende Gesamtordnung sichtbar machen und anhaltende Oszillation begünstigen können. Die relevante Evidenz ist deshalb kein Screenshot einer einzelnen Route, sondern die vollständige Kandidatenmenge auf den Routern, deren Entscheidung zählt: einschließlich der Attribute, die frühere Stufen überstanden, und der Frage, ob alle Router dieselben Alternativen sahen.

Vom gewählten Pfad zum bewegten Verkehr

Ein Best-Path-Datensatz ist stärker als ein Update, aber noch kein Verkehrsbeleg. Der gewählte Next Hop muss in der Forwarding Plane installiert sein. Equal-Cost- oder Per-Flow-Verfahren können Verkehr verteilen. Nachfrage kann sich während der Beobachtung ändern. Ein Withdrawal, Session Reset oder Topologieereignis kann zeitgleich mit der MED-Änderung Verkehr verlagern.

Die Schlusskette muss sichtbar bleiben: Die Anzeige belegt, was gesendet wurde. Der Importzustand belegt, was akzeptiert oder umgeschrieben wurde. Der Entscheidungszustand belegt die Auswahl eines Routers. Der Forwarding-Zustand belegt dessen Installation. Interface-Zähler oder Flow-Samples belegen, wo Pakete in einem benannten Zeitraum liefen. Keine Stufe darf die Beweiskraft der nächsten vorwegnehmen.

RFC 4451 fügt eine zeitliche Warnung hinzu. Aus IGP-Metriken abgeleitete MEDs können eine interne Metrikänderung in weitreichenden BGP-Update-Churn verwandeln. Ein Session Reset kann angekündigte Werte und Verkehrsmuster ändern. Eine Zusicherung von vor dem Reset oder von einem einzelnen Route Reflector ist daher nicht unbegrenzt übertragbar.

Quellen