Zusammenfassung

  • LOCAL_PREF bewertet zulässige BGP-Pfade nach der Politik des eigenen autonomen Systems. Ein hoher Wert bestätigt weder die Herkunft noch die Sicherheit einer Route.
  • Die interne Verteilung kann zahlreiche Ausgangsentscheidungen beeinflussen. Entscheidend sind die betroffene Routenmenge, konsistente Weiterleitung und belastbare Rückkehrbedingungen, nicht allein die Konfigurationszeile.

Ein längerer Weg gewinnt

Zwei Grenzrouter, A und B, lernen im folgenden hypothetischen Beispiel jeweils eine nutzbare Route zum selben Präfix. Der AS-Pfad über A enthält weniger Stationen. Beide Routen bestehen die Importprüfung, ihre nächsten Hops sind erreichbar. Für eine Auswahl nach dem hier betrachteten Cisco-Verfahren sei außerdem der zuvor verglichene WEIGHT gleich. Zunächst erhalten beide Pfade LOCAL_PREF 100. Eine geänderte Importregel weist nun dem Pfad über B den Wert 200 zu. Wo beide Alternativen unter diesen Voraussetzungen verglichen werden, gewinnt B vor dem kürzeren AS-Pfad.

Das Beispiel beschreibt keinen beobachteten Ausfall. Es isoliert eine Entscheidung: Die Organisation hat ihre eigene Rangfolge geändert, nicht die Geografie des Netzes. Der längere Pfad wurde dadurch weder schneller noch vertrauenswürdiger. Ebenso wenig folgt daraus, dass jeder Router zwingend denselben Ausgang verwenden muss. Sichtbare Alternativen, frühere Auswahlkriterien und die Weiterleitungsarchitektur bleiben relevant. Cisco beschreibt die Reihenfolge seines Auswahlverfahrens.

Die Beschränkung auf dasselbe Präfix ist wesentlich. Ein hoher Wert für ein zusammengefasstes Netz verdrängt beim Weiterleiten nicht automatisch eine installierte spezifischere Route. BGP-Auswahl zwischen Kandidaten und längste Präfixübereinstimmung für ein Paket beantworten unterschiedliche Fragen. Wer beides vermischt, überschätzt die Reichweite einer Änderung und untersucht im Fehlerfall womöglich den falschen Eintrag.

LOCAL_PREF ist als vier Oktette lange vorzeichenlose Zahl standardisiert. Höher bedeutet bevorzugt. Die eigene Politik bestimmt den Rang eingehender externer Routen; intern wird er mitgeteilt. Bei gewöhnlichem EBGP wird das Attribut nicht ausgesendet und ein empfangenes ignoriert. BGP-Konföderationen bilden die ausdrücklich genannte Ausnahme. Das ist eine begrenzte gemeinsame Semantik, keine weltweit vorgegebene Rangordnung von Geschäftsbeziehungen. RFC 4271, Abschnitte 5.1.5 und 9.1.1.

Eine Zahl mit mehreren Auftraggebern

Ein Einkaufsteam möchte günstigeren Transit nutzen. Der Netzbetrieb braucht Reserven für Wartung. Ein Sicherheitsteam will bestimmte Routen ausschließen oder geringer bewerten. Alle drei Anliegen können dieselbe Importpolitik berühren. Im fertigen Routingeintrag ist aber nur das Ergebnis sichtbar. Die Zahl verrät nicht mehr, welcher Auftraggeber welchen Zielkonflikt entschieden hat.

Deshalb gehört zur Konfiguration eine nachvollziehbare Bedeutung. Eine Klasse kann beispielsweise bevorzugte Kundenrouten bezeichnen; eine andere kann einen verbleibenden Ersatzweg markieren. Solche Klassen sind lokale Vereinbarungen. Sie gelten nicht schon deshalb beim Nachbarn, weil dort dieselben Zahlen vorkommen. Die oft anzutreffende 100 ist ebenfalls keine Protokollgarantie: RFC 4277 nennt sie als verbreiteten Standardwert, hält aber ausdrücklich fest, dass kein allgemeiner Standardwert definiert ist.

Ein Default ist damit eine wirksame Entscheidung ohne zwingend sichtbaren Auftraggeber. Nach einer Migration kann eine zuvor explizite Klasse aus der Konfiguration verschwinden und durch das Verhalten der neuen Plattform ersetzt werden. Ein erfolgreicher Syntaxcheck erkennt den geschäftlichen Bedeutungsverlust nicht. Für eine Prüfung muss deshalb auch dokumentiert sein, was mit Routen geschieht, die keine spezifische Regel treffen.

Juniper unterscheidet in seiner Dokumentation zwischen der allgemeinen Routenpräferenz beziehungsweise administrativen Distanz und BGP LOCAL_PREF. Die Richtungen der Bevorzugung sind nicht austauschbar. Die Dokumentation erklärt außerdem, wie Junos mit dem Wert 100 beim Export nach BGP beziehungsweise mit fehlendem Attribut umgeht. Eine nahe beieinander angezeigte Zahl ist deshalb noch kein gleicher Steuerungsparameter. Juniper: Local Preference for BGP Routes.

Der Kunde darf anfragen, der Provider muss entscheiden

Die interne Grenze macht externe Einflussnahme nicht unmöglich. Ein Provider kann Communities definieren, mit denen Kunden eine Behandlung ihrer Ankündigungen anfordern. Der Kunde wählt dann eine dokumentierte Kennzeichnung; die Importpolitik des Providers übersetzt sie in dessen eigene Präferenz. Dieses Verfahren ist in RFC 1998 beschrieben. Übertragen wird dabei eine Anfrage an eine vereinbarte Funktion, nicht LOCAL_PREF über gewöhnliches EBGP.

Die operative Zuständigkeit bleibt beim Provider. Er muss festlegen, von welchen Nachbarn er solche Kennzeichnungen akzeptiert, für welche Präfixe sie gelten und welche Klassen erreichbar sind. Ein Zahlenwert in einer Community ist kein Beweis für eine Berechtigung. Übernimmt ein Team eine Zuordnung aus einem alten Kundenvertrag ungeprüft in eine neue Schnittstelle, kann eine beabsichtigte Ausnahme plötzlich zum allgemeinen Vorrang werden.

Auch andere BGP-Merkmale verteilen Entscheidungsrechte anders. MED ist ein externes, in seiner Anwendung begrenztes Signal für den gewünschten Eintritt in eine benachbarte AS. AIGP bildet eine akkumulierte Metrik unter einer begrenzten administrativen Vereinbarung ab. LOCAL_PREF ist dagegen der lokal zugewiesene Rang. Wer alle drei als bloße Wegkosten behandelt, verliert aus dem Blick, wessen Information vorliegt und wer sie verbindlich in die eigene Auswahl übersetzt.

Large Communities ändern an diesem Verantwortungsmodell nichts. Sie bieten einen strukturierten Namensraum für Informationen und angeforderte Aktionen. RFC 8195 beschreibt darunter lokale Präferenzklassen und räumlich begrenzte Anwendungen. Der größere Namensraum erleichtert die Beschreibung. Er ersetzt weder die Prüfung des Absenders noch die Entscheidung, ob die Aktion am konkreten Eingang zulässig ist.

Auch die Sicherheitsprüfung hat eine andere Aufgabe. Herkunftsvalidierung kann in die lokale Auswahlpolitik eingehen; LOCAL_PREF selbst validiert keinen Ursprung und authentifiziert keinen Partner. RFC 6483 trennt Validierungszustand und lokale Behandlung. Eine Sicherheitsentscheidung darf daher nicht nur als hoher Wert erscheinen. Sonst lässt sich später nicht unterscheiden, ob eine Route geprüft wurde oder lediglich eine attraktive Geschäftsklasse traf.

Konsistenz heißt nicht Zahlenuniformität

Innerhalb eines AS wird die Rangfolge zur Koordinationsaufgabe. Grenzrouter, Route Reflectors und weitere BGP-Sprecher müssen gemeinsam eine tragfähige Weiterleitung ermöglichen. Wenn ein Sprecher die intern empfangene Präferenz neu berechnet, kann dies dauerhafte Schleifen verursachen; davor warnt RFC 4271. Daraus folgt jedoch keine universelle Vorschrift, dass überall stets derselbe Wert stehen muss. RFC 4272 weist ausdrücklich auf das Fehlen einer solchen Anforderung hin.

Eine bewusst regionale Politik kann sinnvoll sein. Sie muss aber an ihrer Weiterleitungsarchitektur geprüft werden. Ein Router darf einen Ausgang bevorzugen, ohne dass der nächste Router die Pakete aufgrund seiner abweichenden Sicht zurückschickt. Ebenso wenig beweisen identische Werte identische Entscheidungen: Die sichtbaren Kandidaten oder spätere Auswahlmerkmale können verschieden sein. Eine Zahleninventur allein ist somit weder ein vollständiger Fehlernachweis noch ein Entlastungsbeweis.

Für Junos beginnt das dokumentierte Auswahlverfahren mit der Auflösbarkeit des nächsten Hops und unterscheidet die BGP-Auswahl von der aktiven Route in der Routingtabelle. Diese Implementierungsdetails sind wichtig, gerade weil sie nicht unbesehen zur universellen Reihenfolge erklärt werden dürfen. Juniper: BGP Overview. Praktisch muss die Untersuchung von der bevorzugten Ankündigung bis zur installierten Weiterleitungsentscheidung reichen.

Der gefährliche Fehler ist syntaktisch korrekt

Ein LOCAL_PREF-Wert 200 statt 100 ist kein beschädigtes Paket. Die Protokollfehlerbehandlung kann daher eine sachlich falsche, aber gültig codierte Regel nicht retten. RFC 7606, Abschnitt 7.5 unterscheidet das Verwerfen eines extern empfangenen Attributs von der Behandlung einer intern empfangenen falschen Attributlänge als zurückgezogene Route. Diese technischen Fehlerfälle sind etwas anderes als ein zu weit gefasster Policy-Treffer.

Gerade die Treffermenge bestimmt das Risiko. Eine Regel kann im Änderungsantrag mit einem einzigen Beispielpräfix erklärt werden und tatsächlich sämtliche Routen einer Community erfassen. IPv4 und IPv6 können verschieden betroffen sein; eine gemeinsame Policy kann an mehreren Eingängen hängen. Vor einer Änderung sollte deshalb die reale Menge ermittelt werden, einschließlich ungewollter Treffer und der Routen, die unverändert bleiben müssen.

Eine nützliche Gegenprobe liefert geplante Wartung. RFC 8326 beschreibt GRACEFUL_SHUTDOWN und empfiehlt eine niedrige Präferenz, gewöhnlich 0, damit Alternativen übernehmen können. Null zieht eine Route nicht zurück. Fehlt eine zulässige Alternative, kann sie weiterhin gewinnen. Der Betreiber muss also zunächst Alternativen und Konvergenz nachweisen, bevor er aus einer gesenkten Zahl einen geleerten Link ableitet.

Vom Beschluss zum Paket

Die Prüfung beginnt vor dem Router: Wer hat die Änderung beauftragt, welche Präfixe sind gemeint, welcher beobachtbare Zustand rechtfertigt den Abbruch? Danach folgen die tatsächlich empfangenen Alternativen, die angewandte Importregel und die berechneten Werte. Ein Vergleich an mehreren internen Standorten zeigt, ob die erwartete Information ankommt und welcher Pfad jeweils ausgewählt wird.

Darauf muss der Blick in die FIB folgen, also die tatsächlich verwendete Weiterleitungstabelle: aufgelöster nächster Hop, Ausgang und gegebenenfalls mehrere installierte Wege. Paketmessungen aus relevanten Eingangsregionen ergänzen diese Sicht. Ein einzelner Traceroute ist keine vollständige Verkehrsabrechnung; wiederholte Messungen und Ausgangszähler helfen, den Kontrollzustand mit der Nutzung zu verbinden. Öffentliche Routensammler können die gewöhnlich nicht exportierte interne Präferenz nicht unmittelbar belegen.

Das gilt auch rückwärts. Eine zurückgespielte Konfiguration muss die Routen erneut bewerten lassen; Route Refresh kann dabei den notwendigen Zustand erneut anfordern, bestimmt aber nicht die Auswahlpolitik. Erst wenn ausgewählte Routen, FIB und Pakete wieder zum beabsichtigten Zustand passen, ist die Rückkehr nachgewiesen. Der betriebliche Wert von LOCAL_PREF liegt nicht in der Größe seiner Zahl, sondern darin, dass sich eine lokale Entscheidung begrenzen, beobachten und verantworten lässt.