JNCIP-ENT: Routing Policies in Junos
26.06.2026 5 Min. Lesezeit
Routing Policies sind in Junos kein ergänzendes Feature, sondern der Mechanismus, mit dem Routingverhalten tatsächlich kontrolliert wird. Während Protokolle wie OSPF oder BGP definieren, wie Informationen ausgetauscht werden, bestimmen Policies, welche dieser Informationen akzeptiert, verändert oder verworfen werden. Ohne dieses Konzept wäre Routing ausschließlich durch Protokolllogik gesteuert und kaum an reale Anforderungen anpassbar.
Der Aufbau einer Policy folgt einem einfachen, aber strikt eingehaltenen Prinzip. Eine Policy besteht aus mehreren Termen, die sequenziell ausgewertet werden. Jeder Term enthält eine Bedingung und eine Aktion. Sobald eine Route die Bedingung eines Terms erfüllt, wird die zugehörige Aktion ausgeführt. Entscheidend ist dabei, dass die Abarbeitung in diesem Moment standardmäßig endet. Die nachfolgenden Terme werden nicht mehr betrachtet, es sei denn, das Verhalten wird explizit anders definiert. Diese Eigenschaft führt dazu, dass die Reihenfolge der Terme oft wichtiger ist als deren Inhalt.
Ein häufiger Fehler besteht darin, Policies wie klassische Filterketten zu betrachten, bei denen mehrere Regeln nacheinander ausgewertet werden und sich gegenseitig ergänzen. In Junos ist das Gegenteil der Fall. Der erste passende Term bestimmt das Ergebnis vollständig. Das führt dazu, dass scheinbar spezifischere Terme nie zur Geltung kommen, wenn davor bereits ein allgemeinerer Term greift. Eine Route, die durch einen frühen Term akzeptiert wird, erreicht die späteren Terme nicht mehr, selbst wenn diese eine differenziertere Behandlung vorsehen würden.
Die Match-Kriterien innerhalb eines Terms sind flexibel und können unterschiedlich granular sein. Sie reichen von einfachen Eigenschaften wie dem verwendeten Protokoll bis hin zu präzisen Prefix-Filtern oder Community-Matches. Besonders wichtig ist das Verständnis der Prefix-Filter, da hier häufig falsche Annahmen getroffen werden. Ein Ausdruck wie „orlonger“ bedeutet, dass alle spezifischeren Präfixe eingeschlossen sind, während „exact“ ausschließlich auf den exakt angegebenen Netzbereich zutrifft. Die Kombination dieser Optionen erlaubt eine sehr feine Steuerung, erfordert jedoch ein genaues Verständnis der Auswirkungen.
Die Aktionen innerhalb einer Policy gehen über einfaches Akzeptieren oder Verwerfen hinaus. Sie können Attribute verändern, etwa die Local Preference im BGP anpassen oder den Next-Hop modifizieren. Diese Veränderungen wirken sich direkt auf die spätere Entscheidungslogik aus. Eine Policy ist damit nicht nur ein Filter, sondern auch ein Werkzeug zur gezielten Manipulation des Routingverhaltens.
Ein wesentlicher Aspekt, der oft übersehen wird, ist der Unterschied zwischen Import- und Export-Policies. Eine Import-Policy wird angewendet, wenn eine Route empfangen wird. Sie bestimmt, ob und in welcher Form diese Route in die Routing-Entscheidung einfließt. Eine Export-Policy hingegen wirkt, wenn der Router selbst Routen an Nachbarn weitergibt. Sie beeinflusst also, wie andere Geräte das eigene Netzwerk sehen. Diese Trennung ist entscheidend, da dieselbe Regel in unterschiedlichem Kontext völlig andere Auswirkungen haben kann.
In der Praxis zeigt sich dieser Unterschied besonders deutlich bei Manipulationen von Routing-Attributen. Wird beispielsweise die Local Preference verändert, hat dies nur dann Einfluss auf die interne Auswahl von Pfaden, wenn die Änderung im Import stattfindet. Erfolgt sie im Export, sehen nur externe oder nachgelagerte Systeme diesen Wert, während die eigene Entscheidung unverändert bleibt. Ähnlich verhält es sich mit dem Next-Hop. Eine Änderung im Export beeinflusst lediglich die Nachbarn, nicht jedoch die eigene Weiterleitung.
Ein weiterer wichtiger Punkt ist das implizite Verhalten am Ende einer Policy. Wenn keine explizite Entscheidung getroffen wird, greift ein Standardverhalten, das je nach Kontext variieren kann. Wird eine Route von keiner Regel erfasst, kann dies dazu führen, dass sie verworfen wird, obwohl keine explizite „reject“-Anweisung vorhanden ist. Dieses implizite Verhalten wird häufig übersehen und führt dann zu Situationen, in denen Routen verschwinden, ohne dass eine offensichtliche Regel dafür verantwortlich ist.
Die Kombination aus expliziten und impliziten Entscheidungen macht Policies besonders mächtig, aber auch fehleranfällig. Kleine Änderungen in der Reihenfolge oder im Match-Kriterium können große Auswirkungen haben. Eine Policy, die auf den ersten Blick logisch erscheint, kann durch ihre Struktur genau das Gegenteil des gewünschten Effekts bewirken. Deshalb ist es wichtig, nicht nur den Inhalt einzelner Terme zu betrachten, sondern immer die gesamte Verarbeitungskette im Blick zu behalten.
Ein typisches Beispiel ist eine Policy, die zunächst alle BGP-Routen akzeptiert und in einem späteren Term bestimmte Präfixe speziell behandeln will. In einem solchen Fall greift der erste Term bereits für alle Routen, sodass der zweite Term nie erreicht wird. Die gewünschte Differenzierung findet nicht statt, obwohl sie formal korrekt definiert wurde. Dieses Verhalten ist kein Fehler im System, sondern eine direkte Folge der Auswertungslogik.
Ein weiteres häufiges Szenario betrifft die Kombination von Match-Kriterien. Wenn mehrere Bedingungen innerhalb eines Terms definiert sind, müssen alle erfüllt sein, damit der Term greift. Eine scheinbar harmlose Ergänzung kann dazu führen, dass ein Term plötzlich nicht mehr matcht und dadurch eine komplett andere Regel zur Anwendung kommt. Auch hier zeigt sich, dass die Wirkung einer Policy nicht isoliert aus einzelnen Elementen verstanden werden kann.
Im täglichen Betrieb sind Policies das zentrale Werkzeug, um Routingverhalten gezielt zu steuern. Sie entscheiden darüber, welche Routen bevorzugt werden, welche als Backup dienen und welche vollständig ausgeblendet werden. Gleichzeitig sind sie die häufigste Ursache für unerwartetes Verhalten, da ihre Wirkung immer im Kontext der gesamten Konfiguration gesehen werden muss.
Die eigentliche Herausforderung besteht darin, die lineare Struktur der Abarbeitung mit der oft komplexen Zielsetzung in Einklang zu bringen. Wer Policies schreibt, definiert nicht nur Regeln, sondern legt eine Entscheidungslogik fest, die strikt und deterministisch ausgeführt wird. Das Verständnis dieser Logik ist daher entscheidend, um Routing nicht nur zu konfigurieren, sondern gezielt zu beherrschen.