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 hinsichtlich der Richtlinienleistung haben, weil die Routingfilter über mehrere Richtlinienbedingungen verteilt sind. Die Walkup-Funktion ermöglicht die Konsolidierung von Routenfiltern unter einem Richtlinienbegriff.

Standardmäßig wertet Junos mehrere Routenfilter in einem Richtlinienanweisungsbegriff aus, indem zuerst das Präfix mit der längsten Übereinstimmung ermittelt und dann die an den Routenfilter angehängten Bedingungen ausgewertet werden, z. B. der Präfixbereich. Wenn die Routenfilterbedingung false ist (z. B. wenn das Präfix nicht im angegebenen Bereich liegt), ist der gesamte Begriff false, auch wenn es potenziell echte Präfixe für kürzere Routenfilter gibt. Aufgrund dieses Verhaltens kann es zu Performance-Problemen kommen, wenn Routenfilter in einzelne Richtlinienanweisungsbegriffe aufgeteilt werden. Die Walkup-Funktion ändert das standardmäßige Verhalten des Routenfilters.

Einige automatisierte Richtlinientools – z. B. diejenigen, die im Border Gateway Protocol (BGP) für autonome System-Border-Router verwendet werden – unterteilen Routenfilter aufgrund des Standardverhaltens des Routenfilters in mehrere Begriffe. Routing-Filter werden auch in anderen Routing-Protokollen als BGP verwendet. Die Walkup-Funktion ist nicht auf BGP-Routenfilter beschränkt.

HINWEIS:

Technisch gesehen behandelt BGP Routen nicht auf die gleiche Weise wie OSPF oder IS-IS. BGP-"Routen" werden korrekter als NLRI-Updates (Network Layer Reachability Information) bezeichnet. Der Begriff "Route" wird jedoch in den meisten Dokumentationen verwendet und wird hier verwendet.

Routenfilter bestehen aus drei Hauptteilen:

  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 – das Präfix und die Übereinstimmungsbedingung – beide als wahr ausgewertet werden (z. B. accept)

Der 10.0.0.0/8 exact accept Routenfilter ist also genau dann erfolgreich, wenn das betrachtete Präfix genau ist 10.0.0.0/8 . Dieser Routenfilter lehnt Routen mit allen anderen längeren Präfixen ab, z. B 10.0.0.0/10. , obwohl es möglicherweise andere Routenfilterbegriffe in der Richtlinienkette gibt, die die 10.0.0.0/10 Route akzeptieren.

HINWEIS:

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

Routenfilter können in einem einzigen Richtlinienanweisungsbegriff kombiniert werden. In diesem Fall wird die Auswertung komplexer. Beachten Sie die folgende Routingrichtlinie:

Beachten Sie, dass der 10.0.0.0/8 orlonger Filter den 10.0.0.0/16 prefix-length-range /22-/24 Filter in seinem Gültigkeitsbereich enthält. Das heißt, jede 10.0.0.0 Route mit einem Präfix von 8 Bit oder länger kann auch eine Route mit einem Präfix im Bereich zwischen 22 und 24 Bit sein.

Standardmäßig erfolgt die Auswertung eines Richtlinienanweisungsbegriffs mit mehreren Routenfiltern in zwei Schritten:

  1. Die Richtlinienframework-Software führt basierend auf Präfix- und Präfixlängenwerten eine Suche nach der längsten Übereinstimmung in der Liste durch.

  2. Die Software berücksichtigt die Bedingung des Routenfilters (orlonger, exact, usw.). Die Route erfüllt entweder die Routenfilterbedingung (Erfolg) oder stimmt nicht mit der Routenfilterbedingung überein (Fehler).

Basierend auf den Ergebnissen dieser beiden Schritte wird die Aktion, die durch die Übereinstimmung oder den Fehler bestimmt wird, auf die Route angewendet. In Route-Filter-Abedeutet dies, dass jede Route, die "wahr" ist, akzeptiert wird und jede Route, die RouteFilter-1 im Begriff "falsch" ist, abgelehnt wird. Diese Route wird zu einer ausgeblendeten (gefilterten) Route.

Betrachten Sie beispielsweise, was passiert, wenn die Route 10.0.0.0/18 von der Richtlinienanweisung RouteFilter-Aausgewertet wird:

Zunächst wird die 10.0.0.0/18 Route anhand des RouteFilter-1 Begriffs bewertet. Da 10.0.0.0/16 länger als 10.0.0.0/8ist, stimmt die 10.0.0.0/18 Route mit dem längeren und spezifischeren Routenpräfix überein. Als Nächstes schlägt die Übereinstimmung fehl, da die 10.0.0.0/18 Route nicht mit der Bedingung prefix-length-range /22-/24 übereinstimmt. Die Routenübereinstimmung schlägt also in der RouteFilter-1 Laufzeit fehl, und die Richtlinie untersucht die nächste Laufzeit, die Standardlaufzeit. Die 10.0.0.0/18 Route wird durch die Standardbedingung zurückgewiesen.

Dadurch wird die 10.0.0.0/18 Route ausgeblendet (gefiltert). (Die 10.0.0.0/18 Route kann weiterhin mit dem show route hidden Befehl gefunden werden.)

Das Problem besteht darin, dass der Benutzer möglicherweise tatsächlich möchte, dass die 10.0.0.0/18 Route akzeptiert und nicht abgelehnt wird. Natürlich könnte auch ein Routenfilter mit einer 10.0.0.0/18 exact Konfiguration hinzugefügt werden. In einer Backbone-Routing-Tabelle 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, die dem Netzwerk hinzugefügt wird, abgestimmt ist.

Die standardmäßige Problemumgehung, um das richtige Verhalten aus der Beispiel-Routing-Richtlinie zu erzielen, besteht darin, für jeden Routingfilter einen separaten Begriff zu konfigurieren. Dies geschieht häufig wie folgt:

Jetzt wird die 10.0.0.0/18 Route akzeptiert, da sie zwar immer noch die RouteFilter-1 Übereinstimmungsbedingung erfüllt, aber mit dem neuen RouteFilter-2 Begriff übereinstimmt (10.0.0.0/8 ist die längste Übereinstimmung, und die Bedingung orlonger ist wahr). Das Problem bei diesem Ansatz besteht darin, dass die Auswertung der vollständigen Routing-Richtlinie jetzt mehr Zeit in Anspruch nimmt, als wenn mehrere Routenfilter gruppiert werden. Diese Methode macht auch die Wartung komplexer.

Die Probleme mit dem Ansatz "Ein-Begriff-pro-Route-Filter" werden mit der walkup-Anweisung und dem Feature gelöst. Walkup ändert das Standardverhalten der Routenfilterauswertung global oder pro Richtlinie.

Die Walkup-Funktion ermöglicht es Begriffen mit mehreren Routenfiltern, den Bewertungsprozess so zu "walken", dass sie sowohl weniger spezifische Routen als auch die längste Übereinstimmung enthält. Mit anderen Worten, der Walkup-Knopf ändert das Standardverhalten von "Wenn einer fehlschlägt, schlägt der Begriff fehl" in "Wenn einer übereinstimmt, stimmt der Begriff überein".

Betrachten Sie die Anwendung der Walkup-Funktion auf die Beispielrichtlinienanweisung (Sie können Walk-up auch global auf alle konfigurierten Richtlinien anwenden):

Dies geschieht, wenn das Routenpräfix 10.0.0.0/18 von der Richtlinienanweisung RouteFilter-Aausgewertet wird:

Das Standardverhalten wird durch den Walkup-Regler geändert. Wie zuvor stimmt die 10.0.0.0/18 Route mit dem längeren und spezifischeren Routenpräfix überein, da 10.0.0.0/16 es länger als 10.0.0.0/8ist. Wie zuvor schlägt diese Übereinstimmung fehl, da die 10.0.0.0/18 Route nicht der Bedingung prefix-length-range /22-/24 entspricht. Diesmal wird der Prozess jedoch mit einem "Walk up" fortgesetzt und der weniger spezifische 10.0.0.0/8 Routenfilter untersucht. Die Routenbedingung von orlonger stimmt mit diesem Filter überein und daher wird die Route vom RouteFilter-1 Begriff akzeptiert.

Dies kann (für eine BGP-Route) durch den show route protocol bgp 10.0.0.0/18 Befehl überprüft werden. Diesmal ist die Route nicht ausgeblendet.

Wenn Sie die Walkup-Funktion global aktivieren, können Sie sie lokal für jede Richtlinie einzeln mit der [edit policy-options policy-statements policy-statement-name defaults route-filter no-walkup] Anweisung außer Kraft setzen.

Verwandte Themen