Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Walkup für Routenfilter – Übersicht

Verwenden Sie die Walkup-Funktion, wenn Sie Bedenken bezüglich der Richtlinienleistung aufgrund von geteilten Routenfiltern über mehrere Richtlinienbedingungen haben. Die Walkup-Funktion ermöglicht die Konsolidierung von Routenfiltern unter einem Richtlinienüberlegung.

Standardmäßig wertet Junos mehrere Routenfilter in einem Richtlinienauszugsbegriff aus, indem zuerst das Präfix mit der längsten Übereinstimmung findet, und anschließend werden die mit dem Routenfilter verbundenen Bedingungen, wie der Prefix-Bereich, bewertet. Wenn die Route-Filterbedingung falsch ist (z. B. das Präfix nicht in dem angegebenen Bereich), dann ist der gesamte Begriff falsch, auch wenn es potenziell kürzere Routenfilter-Präfixe gibt. Aufgrund dieses Verhaltens kann es Leistungsprobleme geben, wenn Routenfilter in einzelne Richtlinienauszugsbedingungen aufgeteilt werden. Die Walkup-Funktion ändert das Verhalten der Standardroutenfilter.

Einige automatisierte Richtlinientools, beispielsweise solche, die für autonome System-Border-Router im Border Gateway Protocol (BGP) verwendet werden, zerlegen aufgrund des Standard-Routenfilterverhaltens in mehrere Begriffe. Routenfilter werden auch für andere Routing-Protokolle verwendet als BGP; ist die Walkup-Funktion nicht auf BGP beschränkt.

Anmerkung:

Technisch gesehen BGP sich nicht auf Routen genauso wie OSPF oder IS-IS. BGP Routen werden besser als NLRI-Aktualisierungen (Network Layer Reachability Information) bezeichnet. In den meisten Dokumentationen wird jedoch der Begriff "Route" verwendet und hier verwendet.

Route-Filter bestehen aus drei großen Teilen:

  1. Ein Präfix und eine Präfixlänge (z. B. 10.0.0.0/8 )

  2. Eine Übereinstimmungsbedingung (z. B. exact )

  3. Eine Aktion, die ausgeführt wird, wenn beide vorherigen Teile – Präfix- und Übereinstimmungsbedingung – beide auf true beurteilen (z. B. accept )

Der 10.0.0.0/8 exact accept Routenfilter funktioniert also nur dann und wenn das präfixe exakt 10.0.0.0/8 ist. Dieser Routenfilter weist Routen mit allen anderen längeren Präfixen aus, obwohl es möglicherweise andere Routenfilterbedingungen in der Richtlinienkette gibt, die 10.0.0.0/10 die Route 10.0.0.0/10 akzeptieren.

Anmerkung:

Obwohl der Route und die Variationen nicht speziell für die Dokumentation reserviert sind, wird in diesem Thema der private RFC 1918-Adressraum verwendet, weil dieser Adressbereich Flexibilität und realistische Szenarien 10.0.0.0/810.0.0.0/8 bietet.

Routenfilter können in einem einzigen Richtlinienauszugsbegriff kombiniert werden. In diesem Fall wird die Auswertung immer komplexer. Stellen Sie sich die folgende Routing-Richtlinie vor:

Beachten Sie, 10.0.0.0/8 orlonger dass der Filter den Eigenen Bereich 10.0.0.0/16 prefix-length-range /22-/24 enthält. Das heißt, jede Route mit einem Präfix von 8 oder mehr Bits kann auch eine Route mit einem Präfix in einem Bereich zwischen 10.0.0.0 22 und 24 Bits sein.

Standardmäßig ist die Auswertung eines Richtlinienauszugsaus begriffs mit mehreren Routenfiltern ein zweistufiger Prozess:

  1. Die Richtlinien-Framework-Software führt eine Suche mit der längsten Übereinstimmung in der Liste basierend auf Präfix- und Prefix-Längenwerten durch.

  2. Die Software berücksichtigt die Route-Filterbedingung ( orlongerexact und so weiter). Die Route erfüllt entweder die Routefilterbedingung (Erfolg) oder nicht die Bedingungen für den Routenfilter (Fehler).

Basierend auf den Ergebnissen dieser beiden Schritte wird die von der Übereinstimmung oder dem Ausfall ermittelte Aktion auf die Route angewendet. In bedeutet dies, dass alle als "wahr" bezeichneten Routen akzeptiert und alle Route, die im Begriff "falsch" ist, Route-Filter-ARouteFilter-1 abgelehnt werden. Diese Route wird zu einer verborgenen (gefilterten) Route.

Denken Sie beispielsweise darüber nach, was passiert, wenn 10.0.0.0/18 die Route durch die Richtlinienbeschreibung ausgewertet RouteFilter-A wird:

Zunächst wird 10.0.0.0/18 der Route nach dem Begriff RouteFilter-1 bewertet. Weil 10.0.0.0/16 diese Route länger ist als 10.0.0.0/8 diese, entspricht sie der längeren und 10.0.0.0/18 spezifischeren Routenpräzde. Als nächstes schlägt die Übereinstimmung fehl, da 10.0.0.0/18 die Route nicht mit der Bedingung übereinstimmen prefix-length-range /22-/24 wird. Also schlägt das Routen-Match im Term fehl, und die Richtlinie untersucht den RouteFilter-1 nächsten Begriff, den Standardbegriff. Der 10.0.0.0/18 Route wird durch den Standardbegriff abgelehnt.

Dadurch bleibt die 10.0.0.0/18 Route verborgen (gefiltert). (Die 10.0.0.0/18 Route kann immer noch mit dem Befehl gefunden show route hidden werden.)

Das Problem ist, dass der Benutzer vielleicht möchte, dass der Weg akzeptiert 10.0.0.0/18 oder nicht abgelehnt wird. Natürlich kann ein Routenfilter mit einer 10.0.0.0/18 exact Konfiguration hinzugefügt werden. In einer Backbone-Routingtabelle mit 100.000 oder mehr Einträgen ist es jedoch nicht möglich, einen Routenfilter zu konfigurieren, der auf jede mögliche Route oder jede mögliche neue Route dem Netzwerk hinzugefügt wird.

Um das korrekte Verhalten der Beispiel-Routingrichtlinie zu erreichen, wird standardmäßig ein separater Begriff für jeden Routenfilter konfiguriert. Dies wird häufig wie folgt durchgeführt:

Jetzt wird die Route akzeptiert, da sie zwar immer noch die Übereinstimmungsbedingung ausfällt, sie jedoch dem neuen Begriff entspricht ( die längste Übereinstimmung und die Bedingung 10.0.0.0/18RouteFilter-1 ist RouteFilter-210.0.0.0/8orlonger wahr). Das Problem bei diesem Ansatz ist, dass die vollständige Routing-Richtlinie jetzt mehr Zeit zur Bewertung benötigt, als wenn mehrere Routenfilter gruppiert werden. Diese Methode macht die Wartung auch komplexer.

Die Probleme mit dem Ansatz eines 1-Term-Filters pro Route werden mit der Walkup-Anweisung und der Funktion gelöst. Walkup ändert das Standardverhalten der Bewertung von Routenfiltern weltweit oder auf Richtlinienbasis.

Die Walkup-Funktion ermöglicht Begriffe mit mehreren Routenfiltern zum "Walk-up" des Bewertungsprozesses, um wenigerspezifische Routen sowie die längste Übereinstimmung zu umfassen. Mit anderen Worten, der Walkup-Knopf ändert das Standardverhalten von "wenn einer ausfällt, dann schlägt der Begriff fehl" in dann, wenn "ein Treffer, dann der Begriff entspricht".

Berücksichtigen Sie die Anwendung der Walkup-Funktion auf die Beispiel-Richtlinienausstellung (Sie können das Walk-up auch global auf alle konfigurierten Richtlinien anwenden):

Dies geschieht, wenn das Routen-Präfix 10.0.0.0/18 durch die Richtlinienbeschreibung ausgewertet RouteFilter-A wird:

Das Standardverhalten wird durch den Walkup-Knopf geändert. Wie bereits zuvor entspricht 10.0.0.0/18 die Route dem längeren und spezifischeren Routen-Präfix, 10.0.0.0/16 da diese länger ist als 10.0.0.0/8 . Wie bereits zuvor schlägt diese Übereinstimmung fehl, da 10.0.0.0/18 die Route nicht mit der Bedingung übereinstimmen prefix-length-range /22-/24 wird. Dieses Mal wird der Prozess jedoch durch einen "Walk-up" fortsetzt und den weniger spezifischen 10.0.0.0/8 Routenfilter untersucht. Der Route-Zustand entspricht diesem Filter, und daher wird die Route orlonger vom Begriff RouteFilter-1 akzeptiert.

Dies kann durch den Befehl verifiziert werden (für eine BGP show route protocol bgp 10.0.0.0/18 Route). Diese Route ist jedoch nicht verborgen.

Wenn Sie die Walkup-Funktion global aktivieren, können Sie sie lokal auf Richtlinienbasis mit der Anweisung [edit policy-options policy-statements policy-statement-name defaults route-filter no-walkup] ändern.