Verstehen von Routenfiltern für die Verwendung in Routingrichtlinien-Übereinstimmungsbedingungen
Ein Routenfilter ist eine Sammlung von Übereinstimmungs-Präfixen. Wenn Sie ein Übereinstimmungs-Präfix angeben, können Sie eine genaue Übereinstimmung mit einer bestimmten Route oder einer weniger präzisen Übereinstimmung angeben. Sie können entweder eine gemeinsame Aktion konfigurieren, die für die gesamte Liste gilt, oder eine Aktion, die mit jedem Präfix verknüpft ist.
Da die Konfiguration von Routenfiltern das Einrichten von Präfixen und Präfixlängen umfasst, sollten Sie vor der Konfiguration ein umfassendes Verständnis der IP-Adressierung einschließlich Supernetting und der Bewertung von Routenfiltern haben (hier erläutert: Bewertung von Routenfiltern in Routing-Richtlinienüberstimmungsbedingungen).
In diesem Abschnitt werden die folgenden Themen behandelt:
Radix-Bäume
Um den Betrieb eines Routenfilters zu verstehen, müssen Sie mit einem Gerät vertraut sein, das zur Binären Zahlenabgleichung verwendet wird, das als Radixbaum bekannt ist (manchmal auch als Patricia Trie oder Radix Trie bezeichnet). Ein Radix-Tree verwendet binäre Suche, um IP-Adressen (Routen) zu identifizieren. Denken Sie daran, dass es sich bei einer IP-Adresse um eine 32-Bit-Zahl handelt, die im gestrichelten Dezimalformat dargestellt wird, um menschenfreundliches Verständnis zu bieten. Diese 8-Bit-Gruppierungen können jeweils einen Wert zwischen 0 und 255 haben. Ein Radixbaum kann eine grafische Darstellung dieser binären Zahlen sein.
In Abbildung 1beginnt der Radix-Tree ohne konfigurierten Wert (beginnt bei 0) und befindet sich an der linken Position der binären IP-Adresse. Dies wird als 0/0 dargestellt, was oft als Standardroute bezeichnet wird.

Da dies binär ist, kann jedes Bit nur einen von zwei möglichen Werten haben – eine 0 oder eine 1. Wenn Sie die linke Zweigstelle nach unten bewegen, entspricht dies einem Wert von 0, während die Bewegung nach rechts einen Wert von 1 darstellt. Der erste Schritt wird in Abbildung 2dargestellt. An der ersten Position hat das erste Oktett der IP-Adresse einen Wert von 00000000 oder 10000000 – jeweils eine 0 oder 128. Dies wird durch Abbildung 2 die Werte 0/1 und 128/1 dargestellt.

Der zweite Schritt wird in Abbildung 3gezeigt. Diese zweite Ebene des Baumes hat vier mögliche Binärwerte für das erste Oktett: 0000000, 01000000, 10000000 und 11000000. Diese Dezimalwerte von 0, 64, 128 und 192 werden durch die IP-Adressen 0/2, 64/2, 128/2 und 192/2 am Radixbaum dargestellt.

Dieser Schritt-für-Schritt-Prozess dauert 33 Ebenen an, um alle möglichen IP-Adressen darzustellen.
Die Radix Tree-Struktur ist hilfreich, wenn eine Gruppe von Routen ausfindig wird, die alle dieselben wichtigsten Bits haben. Abbildung 4 zeigt den Punkt im Radix-Tree, der das 192.168.0.0/16-Netzwerk darstellt. Alle Routen, die spezifischer als 192.168.0.0/16 sind, werden im hervorgehobenen Abschnitt angezeigt.

Konfigurieren von Routenfiltern
Das Thema "Konfigurieren von Routenfiltern" beschreibt das Junos OS-Standardverhalten. Die Walkup-Funktion, die in diesem Thema nicht behandelt wird, ändert die in diesem Thema diskutierten Bewertungsergebnisse, indem der Router kürzere Übereinstimmungsbedingungen berücksichtigen kann, die innerhalb derselben Laufzeit konfiguriert sind. Weitere Informationen finden Sie Walkup für Routenfilter – Übersicht unter.
Um einen Routenfilter zu konfigurieren, fügen Sie mindestens eine oder route-filter
source-address-filter
mehrere Anweisungen ein:
[edit policy-options policy-statement policy-name term term-name from] route-filter destination-prefix match-type { actions; }
Die route-filter
Option wird normalerweise verwendet, um eine eingehende Route-Adresse mit dem Ziel-Präfix eines beliebigen Typs zusammenzugleichen, außer für Unicast-Quelladressen.
Die destination-prefix
Adresse ist das Ip-Version 4 (IPv4) oder IP Version 6 (IPv6)-Adresspräfix, das als prefix/prefix-length
angegeben angegeben ist. Wenn Sie ein IPv4-Präfix auslassen prefix-length
, lautet der Standard /32. Wenn Sie ein IPv6-Präfix weglassen prefix-length
, lautet der Standard /128. In einer from
Anweisung angegebene Präfixe müssen entweder alle IPv4-Adressen oder alle IPv6-Adressen sein.
Die source-address-filter
Option wird normalerweise verwendet, um eine eingehende Route-Adresse mit Unicast-Quelladressen in Multiprotocol BGP (MBGP) und Multicast Source Discovery Protocol (MSDP)-Umgebungen abgleicht.
source-address-filter source-prefix match-type { actions; }
source-prefix
Adresse ist das IPv4- oder IPv6-Adressenpräfix, das als prefix/prefix-length
angegeben angegeben ist. Wenn Sie ein IPv4-Präfix auslassen prefix-length
, lautet der Standard /32prefix-length
. Wenn Sie ein IPv6-Präfix weglassen prefix-length
, lautet der Standard /128. In einer from
Anweisung angegebene Präfixe müssen entweder alle IPv4-Adressen oder alle IPv6-Adressen sein.
match-type
ist der Typ der Übereinstimmung, der auf das Quell- oder Zielpräfix angewendet wird. Es kann einer der Übereinstimmungstypen sein, die in Tabelle 1aufgeführt sind. Beispiele für die Übereinstimmungstypen und die Ergebnisse, wenn sie mit verschiedenen Routen präsentiert werden, finden Sie unter Tabelle 2.
actions
sind die zu ergreifenden Aktionen, wenn eine Routenadresse den kriterien entspricht, die für ein Zielübereinstimmungspräfix (als Teil einer route-filter
Option angegeben) oder für ein Quellübereinstimmungspräfix (als Teil einer destination-address-filter
Option angegeben) angegeben sind. Die Aktionen können aus einer oder mehreren der in Aktionen in Routing-Richtlinienbedingungenbeschriebenen Aktionen bestehen.
In einem Routenfilter können Sie Aktionen auf zwei Arten festlegen:
In der
route-filter
option odersource-address-filter
: Diese Aktionen werden unmittelbar nach dem Auftreten einer Übereinstimmung ausgeführt, und diethen
Anweisung wird nicht ausgewertet.In der
then
Anweisung: Diese Aktionen werden ausgeführt, nachdem eine Übereinstimmung erfolgt, aber für die odersource-address-filter
Optionroute-filter
werden keine Aktionen angegeben.
Die upto
Typen und prefix-length-range
Übereinstimmungen sind ähnlich, da beide die wichtigsten Bits angeben und eine Reihe von Präfixlängen angeben, die übereinstimmen können. Der Unterschied besteht darin, dass upto
Sie einen oberen Grenzwert nur für den Prefix-Längenbereich angeben können, während Sie sowohl untere prefix-length-range
als auch obere Grenzwerte angeben können.
Weitere Beispiele für diese Routenfilter-Übereinstimmungstypen finden Sie unter Beispiele für Routenfilter.
Übereinstimmungstyp |
Übereinstimmungskriterien |
---|---|
|
Alle folgenden Punkte sind wahr:
Anmerkung:
Der Mit Wenn die längste Übereinstimmungssuche auf einem Routenfilter durchgeführt wird, bewertet die Suche einen Weitere Informationen zu diesem Routenfilter-Übereinstimmungstyp finden Sie unter Bewertung eines Adressmasken-Übereinstimmungstyps. Konfigurationen mit Routenfiltern, die den Übereinstimmungstyp |
|
Alle folgenden Punkte sind wahr:
|
|
Alle folgenden Punkte sind wahr:
|
|
Alle folgenden Punkte sind wahr:
|
|
Alle folgenden Punkte sind wahr:
|
|
Alle folgenden Punkte sind wahr:
Sie verwenden den Übereinstimmungstyp in den |
|
Alle folgenden Punkte sind wahr:
|
Abbildung 5 zeigt den detaillierten Radix-Tree für die Route 192.168.0.0/16.

Abbildung 6 und Tabelle 2 den Betrieb der verschiedenen Routenfilter-Übereinstimmungstypen zu demonstrieren.

Präfix |
192.168/16 genau |
192.168/16 länger |
192.168/16 oder höher |
192.168/16 bis /24 |
192.168/16 prefix-length-range/18 – /20 |
192.168/16 through192.168.16/20 |
192.168/19 address-mask255.255.0.0 |
---|---|---|---|---|---|---|---|
10.0.0.0/8 |
– |
– |
– |
– |
– |
– |
– |
192.168.0.0/16 |
Match |
– |
Match |
Match |
– |
Match |
– |
192.168.0.0/17 |
– |
Match |
Match |
Match |
– |
Match |
– |
192.168.0.0/18 |
– |
Match |
Match |
Match |
Match |
Match |
– |
192.168.0.0/19 |
– |
Match |
Match |
Match |
Match |
Match |
Match |
192.168.4.0/24 |
– |
Match |
Match |
Match |
– |
– |
– |
192.168.5.4/30 |
– |
Match |
Match |
– |
– |
– |
– |
192.168.12.4/30 |
– |
Match |
Match |
– |
– |
– |
– |
192.168.12.128/32 |
– |
Match |
Match |
– |
– |
– |
– |
192.168.16.0/20 |
– |
Match |
Match |
Match |
Match |
Match |
– |
192.168.192.0/18 |
– |
Match |
Match |
Match |
Match |
– |
– |
192.168.224.0/19 |
– |
Match |
Match |
Match |
Match |
– |
Match |
10.169.1.0/24 |
– |
– |
– |
– |
– |
– |
– |
10.170.0.0/16 |
– |
– |
– |
– |
– |
– |
– |
Bewertung von Routenfiltern in Routing-Richtlinienüberstimmungsbedingungen
Während der Routenfilterauswertung vergleicht die Richtlinien-Framework-Software die Quelladresse jeder Route mit den Ziel-Präfixen im Routenfilter. Die Auswertung erfolgt in zwei Schritten:
Die Richtlinien-Framework-Software führt eine Suche nach der längsten Übereinstimmung durch, was bedeutet, dass die Software nach dem Präfix in der Liste mit der längsten Länge sucht.
Bei der Suche nach der längsten Übereinstimmung werden nur die
prefix
Komponenten desprefix-length
konfigurierten Übereinstimmungspräfixes und nicht diematch-type
Komponente berücksichtigt. Der folgende Beispielroutenfilter veranschaulicht diesen Punkt:from { route-filter 192.168.0.0/14 upto /24 reject; route-filter 192.168.0.0/15 exact; } then accept;
Die längste Übereinstimmung für die Kandidatenroute 192.168.1.0/24 ist der zweite Routenfilter 192.168.0.0/15, der nur auf Prefix- und Prefix-Länge basiert.
Wenn eine eingehende Route mit einem Präfix übereinstimmt (am längsten zuerst), treten die folgenden Aktionen auf:
Der Routenfilter stoppt die Bewertung anderer Präfixe, selbst wenn der Übereinstimmungstyp ausfällt.
Die Software untersucht den Typ und die Aktion, die mit diesem Präfix verknüpft sind.
Wenn eine Route-Quelladresse anhand eines Übereinstimmungskriterien ausgewertet wird, bei dem der Übereinstimmungstyp address-mask
verwendet wird, enthalten beide Schritte der Evaluierung den konfigurierten Netzmaskenwert. Weitere Informationen finden Sie unter Bewertung eines Adressmasken-Übereinstimmungstyps.
Wenn in Schritt 1 Route 192.168.1.0/24 ausgewertet würde, würde dies nicht übereinstimmen. Es entspricht dem längsten Präfix 192.168.0.0/15, aber es entspricht exact
nicht . Der Routenfilter ist beendet, weil er mit einem Präfix übereinstimmte, aber das Ergebnis ist eine fehlgeschlagene Übereinstimmung, da der Übereinstimmungstyp fehlgeschlagen ist.
Wenn eine Übereinstimmung auftritt, wird die mit dem Präfix angegebene Aktion ausgeführt. Wenn eine Aktion nicht mit dem Präfix angegeben ist, wird die Aktion in der then
Anweisung ausgeführt. Wenn keine aktion angegeben ist, wertet die Software den nächsten Begriff oder die Routing-Richtlinie aus, falls vorhanden, oder führt die accept
von der Standardrichtlinie festgelegte Aktion bzw reject
. Aktion aus. Weitere Informationen zu den Standardrouting-Richtlinien finden Sie unter Standard-Routing-Richtlinien.
Wenn Sie im Routenfilter mehrere Präfixe angeben, muss nur ein Präfix übereinstimmen, damit eine Übereinstimmung auftritt. Die Routenfilterabgleichung ist in der Regel ein logischer ODER-Vorgang.
Wenn keine Übereinstimmung auftritt, wertet die Software den nächsten Begriff oder die Routing-Richtlinie aus, falls vorhanden, oder führt die accept
von der Standardrichtlinie festgelegte Oder reject
Aktion aus.
Vergleichen Sie beispielsweise das Präfix 192.168.254.0/24 mit dem folgenden Routenfilter:
route-filter 192.168.0.0/16 orlonger; route-filter 192.168.254.0/23 exact;
Das Präfix 192.168.254.0/23 wird als das längste Präfix festgelegt. Wenn die Software 192.168.254.0/24 mit dem längsten Präfix bewertet, tritt eine Übereinstimmung ein (192.168.254.0/24 ist eine Teilmenge von 192.168.254.0/23). Aufgrund der Übereinstimmung zwischen 192.168.254.0/24 und dem längsten Präfix wird die Auswertung fortgesetzt. Wenn die Software jedoch den Übereinstimmungstyp auswertet, tritt eine Übereinstimmung nicht genau zwischen 192.168.254.0/24 und 192.168.254.0/23 auf. Die Software kommt zu dem Schluss, dass der Begriff nicht mit dem nächsten Begriff oder der Routing-Richtlinie übereinstimmt oder die accept
in der Standardrichtlinie festgelegte oder reject
ausgeführte Aktion vornimmt.
Die Walkup-Funktion ermöglicht Begriffe mit mehreren Routenfiltern zum "Walk-up" des Evaluierungsprozesses, um weniger spezifische Routen sowie die längste Übereinstimmung einzubeziehen. Mit anderen Worten, die Aktivierung von Walkup ändert das Standardverhalten von "Wenn ein Versagen, dann schlägt der Begriff fehl" auf "Wenn eine Übereinstimmung, dann der Begriff übereinstimmungen". Weitere Informationen zu dieser walkup Funktion finden Sie unter Walkup für Routenfilter – Übersicht.
- Wie sich die Präfixreihenfolge auf die Routenfilterauswertung auswirkt
- Bewertung eines Adressmasken-Übereinstimmungstyps
- Häufiges Konfigurationsproblem bei der Suche nach der längsten Übereinstimmung
Wie sich die Präfixreihenfolge auf die Routenfilterauswertung auswirkt
Die Reihenfolge, in der die Präfixe angegeben werden (von oben nach unten), spielt in der Regel keine Rolle, da die Richtlinien-Framework-Software den Routenfilter scannt, der nach dem längsten Präfix während der Evaluierung sucht. Eine Ausnahme von dieser Regel ist, wenn Sie das gleiche Zielpräfix mehrmals in einer Liste verwenden. In diesem Fall ist die Reihenfolge der Präfixe wichtig, da die Liste identischer Präfixe von oben nach unten gescannt wird und der erste Übereinstimmungstyp, der der Route entspricht, gilt.
Die Walkup-Funktion ermöglicht Begriffe mit mehreren Routenfiltern zum "Walk-up" des Evaluierungsprozesses, um weniger spezifische Routen sowie die längste Übereinstimmung einzubeziehen. Mit anderen Worten, die Aktivierung von Walkup ändert das Standardverhalten von "Wenn ein Versagen, dann schlägt der Begriff fehl" auf "Wenn eine Übereinstimmung, dann der Begriff übereinstimmungen". Weitere Informationen zu dieser walkup Funktion finden Sie unter Walkup für Routenfilter – Übersicht.
Im folgenden Beispiel werden verschiedene Übereinstimmungstypen für das gleiche Präfix angegeben. Die Route 0.0.0.0/0 wird abgelehnt, die Route 0.0.0.0/8 mit markiert next-hop self
und die Route 0.0.0.0/25 wird abgelehnt.
route-filter 0.0.0.0/0 upto /7 reject; route-filter 0.0.0.0/0 upto /24 next-hop self; route-filter 0.0.0.0/0 orlonger reject;
Bewertung eines Adressmasken-Übereinstimmungstyps
Mit address-mask
dem Übereinstimmungstyp der Routing-Richtlinie können Sie eingehende IPv4- oder IPv6-Routenadressen auf einem konfigurierten Netzmaskenwert zusätzlich zur Länge eines konfigurierten Ziel-Übereinstimmungs-Präfixes abgleichen. Während der Routenfilterauswertung wird ein Übereinstimmungstyp address-mask
anders als andere Routing-Richtlinienübereinstimmungstypen unter Berücksichtigung des konfigurierten Netzmaskenwerts verarbeitet:
Wenn eine Suche mit der längsten Übereinstimmung einen Übereinstimmungstyp der
address-mask
Routing-Richtlinie auswertet, wird dieprefix-length
Komponente des konfigurierten Übereinstimmungs-Präfixes nicht berücksichtigt. Stattdessen wird bei der Suche die Anzahl der zusammenhängenden Bits hoher Ordnung im konfigurierten Netzmaskenwert berücksichtigt.Wenn eine eingehende IPv4- oder IPv6-Routenadresse anhand eines Routenfilter-Übereinstimmungskriterien ausgewertet wird, der den Übereinstimmungstyp der
address-mask
Routing-Richtlinie verwendet, ist die Übereinstimmung erfolgreich, wenn die folgenden Werte identisch sind:Die bitweise logische AND des konfigurierten Netzmaskwerts und die eingehende IPv4- oder IPv6-Routenadresse
Das bitweise logische AND des konfigurierten Netzmaskenwerts und des konfigurierten Ziel-Übereinstimmung-Präfixes
Eine Beispielkonfiguration eines Routenfilters, der zwei address-mask
Übereinstimmungstypen enthält, finden Sie unter Bewertung eines Adressmasken-Übereinstimmungstyps mit Longest-Match-Suche.
Häufiges Konfigurationsproblem bei der Suche nach der längsten Übereinstimmung
Ein häufiges Problem beim Definieren eines Routenfilters ist ein kürzeres Präfix, das mit einem längeren, ähnlichen Präfix in der gleichen Liste übereinstimmen soll. Stellen Sie sich beispielsweise vor, dass das Präfix 192.168.254.0/24 mit dem folgenden Routenfilter verglichen wird:
route-filter 192.168.0.0/16 orlonger; route-filter 192.168.254.0/23 exact;
Da die Policy Framework-Software die Suche nach der längsten Übereinstimmung durchführt, wird das Präfix 192.168.254.0/23 als das längste Präfix festgelegt. Eine genaue Übereinstimmung findet nicht zwischen 192.168.254.0/24 und 192.168.254.0/23 exakt statt. Die Software bestimmt, dass der Begriff nicht übereinstimmt und weitergeht mit dem nächsten Begriff oder der Routing-Richtlinie, falls vorhanden, oder die von der accept
Standardrichtlinie festgelegte Oder reject
Aktion. (Weitere Informationen zu den Standardrouting-Richtlinien finden Sie unter Standard-Routing-Richtlinien.) Das kürzere Präfix 192.168.0.0/16 oder länger, das Sie anpassen wollten, wird versehentlich ignoriert.
Eine Lösung für dieses Problem besteht darin, das Präfix 192.168.0.0/16 oder länger aus dem Routenfilter zu entfernen und es in einen anderen Begriff zu verschieben, bei dem es das einzige Präfix oder das längste Präfix in der Liste ist.
Eine weitere Lösung ist die Aktivierung der walkup Funktion. Weitere Informationen finden Sie Walkup für Routenfilter – Übersicht unter.
Beispiele für Routenfilter
Die Beispiele in diesem Abschnitt zeigen nur Fragmente von Routing-Richtlinien. Normalerweise würden Sie diese Fragmente mit anderen Begriffen oder Routingrichtlinien kombinieren.
Denken Sie in allen Beispielen daran, dass die folgenden Aktionen für nicht übereinstimmende Routen gelten:
Bewerten Sie gegebenenfalls den nächsten Begriff.
Bewerten Sie ggf. die nächste Richtlinie.
Führen Sie die
accept
in der Standardrichtlinie angegebene Aktionreject
aus. Weitere Informationen zu den Standardrouting-Richtlinien finden Sie unter Standard-Routing-Richtlinien.
Die folgenden Beispiele zeigen, wie Route-Filter für verschiedene Zwecke konfiguriert werden:
- Ablehnen von Routen mit bestimmten Ziel-Präfixen und Maskenlängen
- Ablehnen von Routen mit einer Maskenlänge von mehr als acht
- Ablehnen von Routen mit Maskenlänge zwischen 26 und 29
- Routen von bestimmten Hosts ablehnen
- Akzeptieren von Routen mit einem definierten Satz von Präfixen
- Ablehnen von Routen mit einem definierten Satz von Präfixen
- Ablehnen von Routen mit Präfixen, die länger als 24 Bits sind
- Ablehnen von PIM-Multicast-Datenverkehrs-Joins
- Ablehnen von PIM-Datenverkehr
- Akzeptieren eingehender IPv4-Routen durch Anwenden einer Adressmaske auf die Routenadresse und das Ziel-Übereinstimmungs-Präfix
- Akzeptieren eingehender IPv4-Routen mit ähnlichen Mustern, aber unterschiedlichen Präfixlängen
- Bewertung eines Adressmasken-Übereinstimmungstyps mit Longest-Match-Suche
Ablehnen von Routen mit bestimmten Ziel-Präfixen und Maskenlängen
Weisen Sie Routen mit dem Ziel-Präfix 0.0.0.0 und einer Maskenlänge von 0 bis 8 zurück, und akzeptieren Sie alle anderen Routen:
[edit] policy-options { policy-statement policy-statement from-hall2 { term 1 { from { route-filter 0.0.0.0/0 upto /8 reject; } } then accept; } }
Ablehnen von Routen mit einer Maskenlänge von mehr als acht
Ablehnen von Routen mit einer Maske von /8 und höher (d. h. /8, /9, /10 usw.), bei denen die ersten 8 Bits auf 0 festgelegt sind und Routen mit einer Länge von weniger als 8 Bits akzeptieren:
[edit] policy-options { policy-statement from-hall3 { term term1 { from { route-filter 0/0 upto /7 accept; route-filter 0/8 orlonger; } then reject; } } }
Ablehnen von Routen mit Maskenlänge zwischen 26 und 29
Routen mit dem Ziel-Präfix 192.168.10/24 und einer Maske zwischen /26 und /29 ablehnen und alle anderen Routen akzeptieren:
[edit] policy-options { policy-statement from-customer-a { term term1 { from { route-filter 192.168.10/24 prefix-length-range /26–/29 reject; } then accept; } } }
Routen von bestimmten Hosts ablehnen
Weisen Sie eine Reihe von Routen von bestimmten Hosts zurück, und akzeptieren Sie alle anderen Routen:
[edit] policy-options { policy-statement hosts-only { from { route-filter 10.125.0.0/16 upto /31 reject; route-filter 0/0; } then accept; } }
Sie verwenden den Übereinstimmungstyp in den through
meisten Routing-Richtlinienkonfigurationen nicht. Sie sollten sich ein Tool zur Gruppierung einer zusammenhängenden Gruppe von exakten Übereinstimmungen überlegen through
. Anstatt beispielsweise vier genaue Übereinstimmungen anzugeben:
from route-filter 0.0.0.0/1 exact from route-filter 0.0.0.0/2 exact from route-filter 0.0.0.0/3 exact from route-filter 0.0.0.0/4 exact
Sie könnten sie mit der folgenden einzigen Übereinstimmung darstellen:
from route-filter 0.0.0.0/1 through 0.0.0.0/4
Akzeptieren von Routen mit einem definierten Satz von Präfixen
Akzeptieren Sie ausdrücklich eine begrenzte Anzahl von Präfixen (im ersten Begriff) und weisen Sie alle anderen (in der zweiten Amtszeit) zurück:
policy-options { policy-statement internet-in { term 1 { from { route-filter 192.168.231.0/24 exact accept; route-filter 192.168.244.0/24 exact accept; route-filter 192.168.198.0/24 exact accept; route-filter 192.168.160.0/24 exact accept; route-filter 192.168.59.0/24 exact accept; } } term 2 { then { reject; } } }
Ablehnen von Routen mit einem definierten Satz von Präfixen
Einige Gruppen von Präfixen ablehnen und die verbleibenden Präfixe akzeptieren:
[edit policy-options] policy-statement drop-routes { term 1{ from { # first, reject a number of prefixes: route-filter default exact reject; # reject 0.0.0.0/0 exact route-filter 0.0.0.0/8 orlonger reject; # reject prefix 0, mask /8 or longer route-filter 10.0.0.0/8 orlonger reject; # reject loopback addresses } route-filter 10.105.0.0/16 exact { # accept 10.105.0.0/16 as-path-prepend “1 2 3”; accept; } route-filter 192.0.2.0/24 orlonger reject; # reject test network packets route-filter 172.16.233.0/3 orlonger reject; # reject multicast and higher route-filter 0.0.0.0/0 upto /24 accept; # accept everything up to /24 route-filter 0.0.0.0/0 orlonger accept; # accept everything else } } } }
Ablehnen von Routen mit Präfixen, die länger als 24 Bits sind
Alle Präfixe länger als 24 Bits ablehnen. Sie würden diese Routing-Richtlinie in einer Abfolge von Routing-Richtlinien in einer export
Anweisung installieren. Der erste Begriff in diesem Filter übergibt auf allen Routen mit einer Präfixlänge von bis zu 24 Bits. Der zweite, unbenannte Begriff weist alles andere zurück.
[edit policy-options] policy-statement 24bit-filter { term acl20 { from { route-filter 0.0.0.0/0 upto /24; } then next policy; } then reject; }
Wenn Sie in diesem Beispiel angeben route-filter 0.0.0.0/0 upto /24 accept
würden, würden übereinstimmende Präfixe sofort akzeptiert und die nächste Routing-Richtlinie in der export
Anweisung nie ausgewertet.
Wenn Sie die Anweisung in den then reject
Begriff acl20
einbeziehen würden, würden Präfixe über 24 Bits niemals abgelehnt, da die Policy Framework-Software bei der Bewertung des Begriffs die nächste Anweisung auswertet, bevor sie die then reject
Aussage erreicht.
Ablehnen von PIM-Multicast-Datenverkehrs-Joins
Konfigurieren Sie eine Routing-Richtlinie für das Ablehnen von Protocol Independent Multicast (PIM)-Multicast-Datenverkehrs-Joins für ein Quellziel-Präfix von einem Nachbarn:
[edit] policy-options { policy-statement join-filter { from { neighbor 10.14.12.20; source-address-filter 10.83.0.0/16 orlonger; } then reject; } }
Ablehnen von PIM-Datenverkehr
Konfigurieren Einer Routing-Richtlinie zum Ablehnen von PIM-Datenverkehr für ein Quellziel-Präfix von einer Schnittstelle:
[edit] policy-options { policy-statement join-filter { from { interface so-1/0/0.0; source-address-filter 10.83.0.0/16 orlonger; } then reject; } }
Für PIM gelten die folgenden Richtlinienqualifizierer:
interface
— Schnittstelle, über die ein Join empfangen wirdneighbor
— Quelle, von der ein Join stammtroute-filter
—Gruppenadressesource-address-filter
— Quelladresse, für die ein Join abgelehnt werden soll
Weitere Informationen zum Importieren eines PIM-Join-Filters in einer PIM-Protokolldefinition finden Sie im Benutzerhandbuch für Junos OS Multicast Protocols.
Akzeptieren eingehender IPv4-Routen durch Anwenden einer Adressmaske auf die Routenadresse und das Ziel-Übereinstimmungs-Präfix
Akzeptieren Sie eingehende IPv4-Routen mit einem Ziel-Präfix von 10.1.0/24 und dem dritten Byte eine gleichmäßige Zahl von 0 bis 14, einschließlich:
[edit] policy-options { policy-statement from_customer_a { term term_1 { from { route-filter 10.1.0.0/24 address-mask 255.255.241.0; } then { ... reject; } } } }
Der Routenfilter im Begriff term_1
der Routing-Richtlinien entspricht den folgenden eingehenden IPv4-Routenadressen:
10.1.0.0/24
10.1.2.0/24
10.1.4.0/24
10.1.6.0/24
10.1.8.0/24
10.1.10.0/24
10.1.12.0/24
10.1.14.0/24
Die bitweise logische AND des Netzmaskenwerts und der Routenadresse des Kandidaten muss mit dem bitweisen logischen UND dem Netzmaskenwert und der Präfixadresse übereinstimmen. Das heißt, wenn das Netmask-Bit-Muster 255.255.241.0 ein festgelegtes Bit enthält, muss die eingehende IPv4-Routenadresse, die ausgewertet wird, mit dem Wert des entsprechenden Bit in der Ziel-Präfixadresse 10.1.0.0/24 übereinstimmen.
Die ersten beiden Bytes des Netzmaskenwerts sind binär 1111 1111 1111 1111, was bedeutet, dass eine Kandidatenroutenadresse die Übereinstimmung nicht schlägt, wenn die ersten beiden Bytes nicht 10.1 sind.
Das dritte Byte des Netmask-Werts ist binär 1111 0001, was bedeutet, dass eine Kandidatenroutenadresse die Übereinstimmung fehlschlägt, wenn das dritte Byte größer als 15 (Dezimalzahl), eine ungerade Zahl oder beides ist.
Die Prefix-Länge der Übereinstimmungs-Prefix-Adresse ist 24 (Dezimal), was bedeutet, dass eine Kandidatenroutenadresse die Übereinstimmung fehlschlägt, wenn ihre Präfixlänge nicht genau 24 ist.
Nehmen wir als Beispiel an, dass die in der Richtlinie getestete Kandidatenroutenadresse 10.1.8.0/24 ist (binär 0000 1010 0000 0001 0000 1000).
Wenn der Netzmaskenwert auf diese Routenadresse des Kandidaten angewendet wird, ist das Ergebnis binär 0000 1010 0000 0001 0000 0000.
Wenn der Netzmaskenwert auf die konfigurierte Ziel-Prefix-Adresse angewendet wird, ist das Ergebnis auch binär 0000 1010 0000 0001 0000 0000.
Da die Ergebnisse von BEIDEN UND Vorgängen gleich sind, wird die Übereinstimmung mit den zweiten Übereinstimmungskriterien fortgesetzt.
Da die Präfixlängen der Kandidatenadresse und die konfigurierte Ziel-Prefix-Adresse gleich sind (24 Bits), ist die Übereinstimmung erfolgreich.
Nehmen wir als weiteres Beispiel an, dass die in der Richtlinie getestete Kandidatenroutenadresse 10.1.3.0/24 ist (binär 0000 1010 0000 0001 0000 0011).
Wenn der Netzmaskenwert auf diese Kandidatenroutenadresse angewendet wird, ist das Ergebnis binär 0000 1010 0000 0001 0000 0001.
Wenn der Netzmaskenwert jedoch auf die konfigurierte Ziel-Präfixadresse angewendet wird, ist das Ergebnis binär 0000 1010 0000 0001 0000 0000 0000.
Da die Ergebnisse der beiden UND-Vorgänge unterschiedlich sind (im dritten Byte), schlägt die Übereinstimmung fehl.
Akzeptieren eingehender IPv4-Routen mit ähnlichen Mustern, aber unterschiedlichen Präfixlängen
Akzeptieren Sie eingehende IPv4-Routenadressen des Formulars 10.*.1/24 oder 10.*.1.*/32:
[edit] policy-options { policy-statement from_customer_b { term term_2 { from { route-filter 10.0.1.0/24 address-mask 255.0.255.0; route-filter 10.0.1.0/32 address-mask 255.0.255.0; } then { ... reject; } } } }
Die Übereinstimmungskriterien 10.0.1.0/24 address-mask 255.0.255.0
des Routenfilters entsprechen einer eingehenden IPv4-Routenadresse des Formulars 10.*.1/24. Die Präfixlänge der Route muss genau 24 Bits lang sein, und jeder Wert ist im zweiten Byte akzeptabel.
Die Übereinstimmungskriterien 10.0.1.0/32 address-mask 255.0.255.0
des Routenfilters entsprechen einer eingehenden IPv4-Routenadresse des Formulars 10.*.1.*/32. Die Präfixlänge der Route muss genau 32 Bits lang sein, und jeder Wert ist im zweiten Byte und im vierten Byte akzeptabel.
Bewertung eines Adressmasken-Übereinstimmungstyps mit Longest-Match-Suche
In diesem Beispiel wird veranschaulicht, wie eine Suche nach der längsten Übereinstimmung einen Routenfilter bewertet, der zwei address-mask
Übereinstimmungstypen enthält. Betrachten Sie den im folgenden Begriff term_3
der Routing-Richtlinie konfigurierten Routenfilter:
[edit] policy-options { policy-statement from_customer_c { term term_3 { from { route-filter 10.0.1.0/24 address-mask 255.0.255.0; route-filter 10.0.2.0/24 address-mask 255.240.255.0; } then { ... } } } }
Angenommen, die eingehende IPv4-Route-Quelladresse 10.1.1.0/24 wird anhand des im Richtlinienbegriff term_3
konfigurierten Routenfilters getestet:
Der Nachschlagebaum mit der längsten Übereinstimmung für den Begriff
term_3
der Routing-Richtlinie enthält zwei Übereinstimmungs-Präfixe: ein Präfix für10.0.1.0/24 address-mask 255.0.255.0
und ein Präfix für10.0.2.0/24 address-mask 255.240.255.0
. Bei der Suche nach der Struktur nach der Longest-Prefix-Übereinstimmung nach einem Kandidaten berücksichtigt die Suche nach der längsten Übereinstimmung die Anzahl der zusammenhängenden Bits mit hoher Reihenfolge in den konfiguriertennetmask-value
statt der Länge des konfiguriertendestination-prefix
:Bei den ersten Kriterien für die Übereinstimmung des Routenfilters ist der Eintrag für die Suche nach der längsten Übereinstimmung 10.0.0.0/8, da der Netzmaskenwert 8 zusammenhängende hochgeordnete Bits enthält.
Für die Übereinstimmungskriterien des zweiten Routenfilters ist der Eintrag für die Suche nach der längsten Übereinstimmung 10.0.0.0/12, da der Netzmaskenwert 12 zusammenhängende Bits hoher Ordnung enthält.
Für die Kandidatenroutenadresse 10.1.1.0/24 gibt die Suche nach der längsten Übereinstimmung den Baumeintrag 10.0.0.0/12 zurück, der den Übereinstimmungskriterien
10.0.2.0/24 address-mask 255.240.255.0
des Routenfilters entspricht.Nachdem nun das Prefix
term_3
mit der längsten Übereinstimmung für die Routenadresse des Kandidaten identifiziert wurde, wird die Routenadresse des Kandidaten anhand der Übereinstimmungskriterien10.0.2.0/24 address-mask 255.240.255.0
für den Routenfilter bewertet:Um die eingehende IPv4-Routenadresse 10.1.1.0/24 zu testen, wird der Netzmaskenwert 255.240.255.0 auf 10.1.1.0/24 angewendet. Das Ergebnis ist 10.0.1.0.
Zum Testen der konfigurierten Ziel-Präfixadresse 10.0.2.0/24 wird der Netzmaskenwert 255.240.255.0 auf 10.0.2.0/24 angewendet. Das Ergebnis ist 10.0.2.0.
Da die Ergebnisse unterschiedlich sind, schlägt die Routenfilter-Übereinstimmung fehl. Es werden keine Aktionen durchgeführt, unabhängig davon, ob sie mit den Übereinstimmungskriterien oder mit der
then
Anweisung angegeben sind. Die eingehende IPv4-Routenadresse wird nicht anhand anderer Übereinstimmungskriterien bewertet.