Junos-Exportrichtlinie: Der Name ist nicht die Match-Bedingung

Eine Richtlinie namens EXPORT-STATIC wählt nichts über den Namen aus. Lesen Sie die Anbindung, die geordneten Terme und die Aktionen, und vergleichen Sie dann die angekündigte Sicht.

Jemand hat eine Richtlinie EXPORT-STATIC genannt, sie angebunden und fragt sich nun, warum ein Präfix aus der VPN-Routinginstanz das ferne Ende nie erreicht. Der Name hat keinen Einfluss auf die Auswahl. Eine Richtlinie besteht aus einer Definition plus einer Anbindung, und was sie exportiert, bestimmen ihre Match-Bedingungen, ihre geordneten Terme und der Kontext, der sie verwendet. Lesen Sie diese drei in dieser Reihenfolge, und das Rätsel fällt meist auf einen Term zusammen, der nie gepasst hat.

Der Name ist eine Bezeichnung, keine Bedingung

Junos interpretiert Richtliniennamen nicht. Eine Richtlinie, die man sinnvollerweise statischen Export nennen würde, kann auf das Protokoll static passen, sie kann auf ein Adresspräfix passen, oder sie kann auf nichts passen und alles durchlassen, was vorbeikommt. Die Bezeichnung ist eine Dokumentation, die von demjenigen geschrieben wurde, der sie angelegt hat, und sie ist genau so verlässlich wie die Erinnerung dieser Person an die Absicht.

Behandeln Sie ein überraschendes Exportergebnis als Aufforderung, die Definition zu lesen, nicht als Beweis dafür, dass die Anbindung defekt ist. Lesen Sie die Definition und lassen Sie sie der Bezeichnung widersprechen.

Finden Sie die Anbindung vor den Termen

Eine korrekte Definition an der falschen Stelle angebunden verändert einen anderen Austausch. Stellen Sie fest, welche Routinginstanz, welches Protokoll und welcher Nachbar oder welche Gruppe tatsächlich auf die Richtlinie verweisen, denn eine unter einer BGP-Gruppe angebundene Richtlinie wirkt nicht auf eine andere, und eine an der Instanz angebundene Richtlinie gilt nicht zwangsläufig für jedes Protokoll darin. Junos unterscheidet diese Ebenen, und ein fehlender Export auf Gruppenebene ist häufig, wenn die Absicht auf Instanzebene ausgedrückt wurde.

Schreiben Sie den Anbindungspfad auf, bevor Sie einen einzigen Term lesen. Die Hälfte dieser Untersuchungen endet dort, mit unberührter Definition und verschobener Exportanweisung. Notieren Sie die Differenz im Änderungsprotokoll, damit niemand sie als Fehler zurücknimmt.

Terme werden in Reihenfolge ausgewertet, und die erste Entscheidung gewinnt

Terme laufen vom ersten bis zum letzten, und ein Term, der akzeptiert oder ablehnt, ist eine abschließende Entscheidung. Ein späterer Term, der wie die beabsichtigte Ausnahme aussieht, läuft nie, wenn ein früherer Term bereits das Schicksal der Route entschieden hat, weshalb eine Richtlinie von oben nach unten korrekt lesbar sein kann und sich dennoch entgegen der Absicht verhält. Prüfen Sie die Reihenfolge gegen die Route, die Sie interessiert, nicht gegen die Reihenfolge, in der die Terme getippt wurden.

Ein Term, der seine Aktion weglässt, beendet nicht; die Auswertung setzt sich zum nächsten Term fort, und das endgültige Ergebnis hängt davon ab, was folgt, und vom anwendbaren Standard. Das ist ein wirklich nützliches Konstrukt und eine verlässliche Quelle der Überraschung, wenn es unbeabsichtigt ist.

Ein Beispiel, das nur statische Routen exportiert, mit der Anbindung an der Gruppe:

policy-options {
    policy-statement EXPORT-STATIC {
        term statics { from protocol static; then accept; }
    }
}
protocols bgp group TO-PEER { export EXPORT-STATIC; }

Ein Präfix, das per OSPF gelernt statt als statische Route konfiguriert wurde, besteht das Match nicht und fällt durch, wie die Richtlinie auch heißt.

Aktionen ändern eine Kopie, nicht die ursprüngliche Route

Richtlinienaktionen wirken auf die Route in der Form, in der sie für diese Ankündigung ausgewertet wird, also auf eine Kopie und nicht auf den Eintrag in der Routing-Tabelle. Ein lokales show route kann daher eine Route mit einem Satz von Attributen anzeigen, während die exportierte Version andere trägt, und das Original wird durch den Export nicht umgeschrieben. Diese Unterscheidung erklärt mehrere Auseinandersetzungen darüber, wessen Ausgabe korrekt ist: beide sind es, und sie beschreiben verschiedene Objekte. Sagen Sie, welche Sicht Sie zitieren, wann immer zwei Ingenieure über ein Routenattribut uneinig sind.

Akzeptieren und Ablehnen sind abschließende Entscheidungen; Attributänderungen sind es nicht zwangsläufig. Nehmen Sie nicht an, dass das Setzen einer Community die Richtlinie beendet, denn die Auswertung kann in Terme weiterlaufen, die Sie nicht bedacht haben.

Vergleichen Sie die angekündigte Sicht mit der Erwartung

Verwenden Sie die protokollspezifische Sicht auf dem tatsächlichen Peer, etwa show route advertising-protocol bgp 192.0.2.1, und lesen Sie sie im richtigen Routinginstanz-Kontext. Eine in einer VRF vorhandene Route hat nicht zwangsläufig die Exportrichtlinie passiert, und eine Route, die in der angekündigten Ausgabe erscheint, ist nicht zwangsläufig von der Gegenseite akzeptiert worden. Das sind drei getrennte Zustände, und sie scheitern unterschiedlich.

Akzeptieren Sie das Design mit einem Präfix, das angekündigt werden muss, und einem, das lokal bleiben muss. Das gibt der Richtlinie einen prüfbaren Vertrag und vermeidet die alternative Lösung, den Export zu erweitern, bis endlich eine einzelne benannte Route erscheint.

Ähnliche Artikel