Aktionen zum Beenden des Firewall-Filters

Firewall-Filter unterstützen eine Reihe von Aktionen zum Beenden für jede Protokollfamilie. Eine filterbeendende Aktion stoppt die gesamte Auswertung eines Firewall-Filters für ein bestimmtes Paket. Der Router führt die angegebene Aktion aus, und es werden keine zusätzlichen Begriffe untersucht.

HINWEIS:

Sie können die next term Aktion nicht mit einer beendenden Aktion im gleichen Filterbegriff konfigurieren. Sie können die next term Aktion jedoch mit einer anderen nicht beendenden Aktion im selben Filterbegriff konfigurieren.

Kann unter Junos OS und Junos OS Evolvednext term nicht als letzter Termin der Aktion angezeigt werden. Ein Filterbegriff, bei dem next term als Aktion angegeben, aber keine Übereinstimmungsbedingungen konfiguriert sind, wird nicht unterstützt.

Bei Routern der MX-Serie mit MPCs müssen Sie den Filterzähler für Nur-Trio-Übereinstimmungsfilter initialisieren, indem Sie die entsprechende SNMP-MIB durchlaufen, z. B show snmp mib walk name ascii. . . Dadurch wird Junos gezwungen, die Filterzähler zu erlernen und sicherzustellen, dass die Filterstatistiken angezeigt werden. Diese Anleitung gilt für alle Firewallfilter im erweiterten Modus, Filter mit flexiblen Bedingungen und Filter mit bestimmten Beendigungsaktionen. Weitere Informationen finden Sie in den Themen, die unter "Zugehörige Dokumentation" aufgeführt sind.

Tabelle 1 Beschreibt die Beendigungsaktionen, die Sie in einem Firewallfilterbegriff angeben können.

Tabelle 1: Beenden von Aktionen für Firewallfilter
Beenden der Aktion	Beschreibung	Protokolle
`accept`	Akzeptieren Sie das Paket.	`family any` `family inet` `family inet6` `family mpls` `family vpls` `family ccc` `family bridge` `family ethernet-switching` (nur für Switches der EX-Serie)
`decapsulate gre [ routing-instance instance-name ]`	Aktivieren Sie an einer kundenorientierten Schnittstelle auf einem Router der MX-Serie, der am Provider-Edge (PE) eines IPv4-Transportnetzwerks installiert ist, die Entkapselung von GRE-Paketen (Generic Routing Encapsulation), die über einen filterbasierten GRE-Tunnel transportiert werden. Sie können einen Filterbegriff konfigurieren, der diese Aktion mit einer Übereinstimmungsbedingung paart, die eine Paket-Header-Übereinstimmung für das GRE-Protokoll enthält. Fügen Sie für einen IPv4-Filter die `protocol gre` Übereinstimmungsbedingung (oder `protocol 47`) hinzu. Schließen Sie den Filter an den Eingang einer logischen Ethernet-Schnittstelle oder einer aggregierten Ethernet-Schnittstelle auf einer modularen Schnittstellenkarte (MIC) oder einem modularen Portkonzentrator (MPC) im Router an. Wenn Sie einen Commit für eine Konfiguration ausführen, die einen Entkapselungsfilter an eine Schnittstelle anfügt, die filterbasiertes GRE-Tunneling nicht unterstützt, gibt das System eine Syslog-Warnmeldung aus, dass die Schnittstelle den Filter nicht unterstützt. Wenn die Schnittstelle ein übereinstimmendes Paket empfängt, führen Prozesse, die auf der Paketweiterleitungs-Engine ausgeführt werden, die folgenden Vorgänge aus: Entfernen Sie den äußeren GRE-Header. Leiten Sie das innere Nutzlastpaket an sein ursprüngliches Ziel weiter, indem Sie eine Zielsuche durchführen. Standardmäßig verwendet die Paketweiterleitungs-Engine die Standard-Routing-Instanz, um Nutzlastpakete an das Zielnetzwerk weiterzuleiten. Wenn es sich bei der Nutzlast um MPLS handelt, führt die Paketweiterleitungs-Engine eine Routensuche in der MPLS-Pfadroutingtabelle mithilfe der Routenbezeichnung im MPLS-Header durch. Wenn Sie die `decapsulate` Aktion mit einem optionalen Routing-Instanznamen angeben, führt die Paketweiterleitungs-Engine eine Routensuche auf der Routing-Instanz durch, und die Instanz muss konfiguriert werden. HINWEIS: Auf MX960-Routern `decapsulate` werden GRE-, IP-in-IP- und IPv6-in-IP-Tunneling-Pakete entkapselt. Sie konfigurieren diese Aktion auf Hierarchieebene `[edit firewall family inet filter filter-name term term-name]` . Weitere Informationen finden Sie unter Grundlegendes zu filterbasiertem Tunneling in IPv4-Netzwerken und Komponenten des filterbasierten Tunnelings in IPv4-Netzwerken.	`family inet`
`decapsulate l2tp [ routing-instance instance-name ] [ forwarding-class class-name ] [ output-interface interface-name ] [ cookie l2tpv3-cookie ] [ sample ]`	Aktivieren Sie an einer kundenorientierten Schnittstelle auf einem Router der MX-Serie, der am Provider-Edge (PE) eines IPv4-Transportnetzwerks installiert ist, die Entkapselung von L2TP-Paketen (Layer 2 Tunneling Protocol), die durch einen filterbasierten L2TP-Tunnel transportiert werden. Sie können einen Filterbegriff konfigurieren, der diese Aktion mit einer Übereinstimmungsbedingung paart, die eine Paket-Header-Übereinstimmung für das L2TP-Protokoll enthält. Für IPv4-Datenverkehr sind ein Eingabe-Firewall-Filter `$junos-input-filter` und ein Ausgabe-Firewall-Filter `$junos-output-filter` an die Schnittstelle angefügt. Schließen Sie den Filter an den Eingang einer logischen Ethernet-Schnittstelle oder einer aggregierten Ethernet-Schnittstelle auf einer modularen Schnittstellenkarte (MIC) oder einem modularen Portkonzentrator (MPC) im Router an. Wenn Sie einen Commit für eine Konfiguration ausführen, die einen Entkapselungsfilter an eine Schnittstelle anfügt, die kein filterbasiertes L2TP-Tunneling unterstützt, gibt das System eine Syslog-Warnmeldung aus, dass die Schnittstelle den Filter nicht unterstützt. Der Remote-Tunnelendpunkt sendet ein IP-Tunnelpaket, das eine Ethernet-MAC-Adresse in der Nutzlast enthält. Wenn die MAC-Zieladresse des Nutzlastpakets die MAC-Adresse des Routers enthält, wird das Ethernet-Paket in ausgehender Richtung an das Netzwerk gesendet und so verarbeitet und weitergeleitet, als ob es am Kundenport empfangen würde. Wenn die Quell-MAC-Adresse des Nutzlastpakets die MAC-Adresse des Routers enthält, wird das Ethernet-Paket in ausgehender Richtung in Richtung des Kundenports übertragen. Wenn der Tunnel das konfigurierte Empfangscookie nicht enthält, findet keine Paketinjektion statt. In einem solchen Fall wird jedes empfangene Tunnelpaket auf die gleiche Weise gezählt und verworfen, wie Pakete, die mit einem falschen Cookie ankommen, gezählt und verworfen werden. Die folgenden Parameter können mit der `decapsulate l2tp` Aktion angegeben werden: `routing-instance instance-name`—Standardmäßig verwendet die Paketweiterleitungs-Engine die Standard-Routing-Instanz, um Nutzlastpakete an das Zielnetzwerk weiterzuleiten. Wenn es sich bei der Nutzlast um MPLS handelt, führt die Paketweiterleitungs-Engine eine Routensuche in der MPLS-Pfadroutingtabelle mithilfe der Routenbezeichnung im MPLS-Header durch. Wenn Sie die `decapsulate` Aktion mit einem optionalen Routing-Instanznamen angeben, führt die Paketweiterleitungs-Engine eine Routensuche auf der Routing-Instanz durch, und die Instanz muss konfiguriert werden. `forwarding-class class-name`—(Optional) Klassifizieren Sie l2TP-Pakete in der angegebenen Weiterleitungsklasse. `output-interface interface-name`—(Optional) Aktivieren Sie bei L2TP-Tunneln die Duplizierung des Pakets und das Senden an den Kunden oder das Netzwerk (basierend auf der MAC-Adresse in der Ethernet-Nutzlast). `cookie l2tpv3-cookie`—(Optional) Geben Sie für L2TP-Tunnel das L2TP-Cookie für die duplizierten Pakete an. Wenn der Tunnel das konfigurierte Empfangscookie nicht enthält, findet keine Paketinjektion statt. In einem solchen Fall wird jedes empfangene Tunnelpaket auf die gleiche Weise gezählt und verworfen, wie Pakete, die mit einem falschen Cookie ankommen, gezählt und verworfen werden. `sample`—(Optional) Stichprobe des Pakets. Junos OS testet keine Pakete, die vom Router stammen. Wenn Sie einen Filter konfigurieren und ihn auf die Ausgabeseite einer Schnittstelle anwenden, werden nur die Transitpakete abgetastet, die diese Schnittstelle durchlaufen. Pakete, die von der Routing-Engine an die Paketweiterleitungs-Engine gesendet werden, werden nicht abgetastet. HINWEIS: Die `decapsulate l2tp` Aktion, die Sie auf Hierarchieebene `[edit firewall family inet filter filter-name term term-name]` konfigurieren, verarbeitet keinen Datenverkehr mit IPv4- und IPv6-Optionen. Infolgedessen wird Datenverkehr mit solchen Optionen durch die Entkapselung der L2TP-Paketfunktionalität verworfen.	`family inet`
`discard`	Verwerfen Sie ein Paket im Hintergrund, ohne eine ICMP-Nachricht (Internet Control Message Protocol) zu senden. Verworfene Pakete stehen für die Protokollierung und Stichprobenentnahme zur Verfügung.	`family any` `family inet` `family inet6` `family mpls` `family vpls` `family ccc` `family bridge` `family ethernet-switching` (nur für Switches der EX-Serie)
`encapsulate template-name`	Aktivieren Sie an einer kundenorientierten Schnittstelle auf einem Router der MX-Serie, der am Provider-Edge (PE) eines IPv4-Transportnetzwerks installiert ist, filterbasiertes GRE-Tunneling (Generic Routing Encapsulation) unter Verwendung der angegebenen Tunnelvorlage. Sie können einen Filterbegriff konfigurieren, der diese Aktion mit den entsprechenden Übereinstimmungsbedingungen paart, und dann den Filter an den Eingang einer logischen Ethernet-Schnittstelle oder einer aggregierten Ethernet-Schnittstelle auf einer modularen Schnittstellenkarte (MIC) oder einem modularen Portkonzentrator (MPC) im Router anfügen. Wenn Sie einen Commit für eine Konfiguration ausführen, die einen kapselnden Filter an eine Schnittstelle anfügt, die filterbasiertes GRE-Tunneling nicht unterstützt, gibt das System eine Syslog-Warnmeldung aus, dass die Schnittstelle den Filter nicht unterstützt. Wenn die Schnittstelle ein übereinstimmendes Paket empfängt, verwenden Prozesse, die auf der Paketweiterleitungs-Engine ausgeführt werden, Informationen in der angegebenen Tunnelvorlage, um die folgenden Vorgänge auszuführen: Fügen Sie einen GRE-Header an (mit oder ohne Tunnelschlüsselwert, wie in der Tunnelvorlage angegeben). Fügen Sie einen Header für das IPv4-Transportprotokoll an. Leiten Sie das resultierende GRE-Paket von der Tunnelquellschnittstelle an das Tunnelziel (den Remote-PE-Router) weiter. Die angegebene Tunnelvorlage muss mit der `tunnel-end-point` Anweisung unter der `[edit firewall]` Hierarchieebene or `[edit logical-systems logical-system-name firewall]` konfiguriert werden. Weitere Informationen finden Sie unter Grundlegendes zu filterbasiertem Tunneling in IPv4-Netzwerken.	`family inet` `family inet6` `family any` `family mpls`
`encapsulate template-name` (für L2TP-Tunnel)	Aktivieren Sie an einer kundenorientierten Schnittstelle auf einem Router der MX-Serie, der am Provider-Edge (PE) eines IPv4-Transportnetzwerks installiert ist, filterbasiertes L2TP-Tunneling mithilfe der angegebenen Tunnelvorlage. Sie können einen Filterbegriff konfigurieren, der diese Aktion mit den entsprechenden Übereinstimmungsbedingungen paart, und dann den Filter an den Eingang einer logischen Ethernet-Schnittstelle oder einer aggregierten Ethernet-Schnittstelle auf einer modularen Schnittstellenkarte (MIC) oder einem modularen Portkonzentrator (MPC) im Router anfügen. Wenn Sie einen Commit für eine Konfiguration ausführen, die einen kapselnden Filter an eine Schnittstelle anfügt, die filterbasiertes GRE-Tunneling nicht unterstützt, gibt das System eine Syslog-Warnmeldung aus, dass die Schnittstelle den Filter nicht unterstützt. Wenn die Schnittstelle ein übereinstimmendes Paket empfängt, verwenden Prozesse, die auf der Paketweiterleitungs-Engine ausgeführt werden, Informationen in der angegebenen Tunnelvorlage, um die folgenden Vorgänge auszuführen: Fügen Sie einen L2TP-Header an (mit oder ohne Tunnelschlüsselwert, wie in der Tunnelvorlage angegeben). Fügen Sie einen Header für das IPv4-Transportprotokoll an. Leiten Sie das resultierende L2TP-Paket von der Tunnelquellschnittstelle an das Tunnelziel (den Remote-PE-Router) weiter. Die angegebene Tunnelvorlage muss mithilfe der `tunnel-end-point` Anweisung in der `[edit firewall]` Anweisungshierarchie oder `[edit logical-systems logical-system-name firewall]` konfiguriert werden.	`family inet`
`exclude-accounting`	Schließen Sie das Paket von der Aufnahme in genaue Abrechnungsstatistiken für getunnelte Abonnenten auf einer L2TP-LAC aus. Wird in der Regel in Filtern verwendet, die DHCPv6- oder ICMPv6-Kontrolldatenverkehr entsprechen Wenn diese Pakete nicht ausgeschlossen werden, betrachtet der Mechanismus zur Erkennung von Leerlauf-Timeouts diese Pakete als Datenverkehr, sodass das Timeout nie abläuft. (Das Leerlauftimeout wird mit den `client-idle-timeout` Anweisungen und `client-idle-timeout-ingress-only` in den Sitzungsoptionen des Zugriffsprofils konfiguriert.) Der Begriff schließt aus, dass Pakete nicht in die Zählung einbezogen werden, sowohl für die familiengenaue Abrechnung als auch für die servicegenaue Abrechnung. Die Pakete sind weiterhin in den Statistiken der Sitzungsschnittstelle enthalten. Der Begriff ist sowohl für als auch `inetinet6` für Familien verfügbar, wird jedoch nur für `inet6`verwendet.	`family inet` `family inet6`
`logical-system logical-system-name`	Leiten Sie das Paket an das angegebene logische System weiter. HINWEIS: Diese Aktion wird auf Paketübertragungs-Routern der PTX-Serie nicht unterstützt.	`family inet` `family inet6`
`reject message-type`	Lehnen Sie das Paket ab und geben Sie eine ICMPv4- oder ICMPv6-Nachricht zurück: Wenn no `message-type` angegeben ist, wird standardmäßig eine `destination unreachable` Meldung zurückgegeben. If `tcp-reset` als angegeben `message-type`ist, `tcp-reset` wird nur zurückgegeben, wenn es sich bei dem Paket um ein TCP-Paket handelt. Andernfalls wird die Nachricht mit dem `administratively-prohibited` Wert 13 zurückgegeben. Wenn eine andere `message-type` Meldung angegeben wird, wird diese Nachricht zurückgegeben. HINWEIS: Abgelehnte Pakete können abgetastet oder protokolliert werden, wenn Sie die `sample` Aktion "Oder `syslog` " konfigurieren. Für MX2K-MPC11E durchlaufen ICMP-Ablehnungsnachrichten Ausgangsfilter, Policer und CoS-Konfigurationen (Class of Service) und werden daher in diesen Statistiken berücksichtigt. Das Gleiche gilt für `destination unreachable` Nachrichten. Der `message-type` kann einer der folgenden Werte sein: `address-unreachable`, `administratively-prohibited`, `bad-host-tos`, `bad-network-tosbeyond-scopefragmentation-neededhost-prohibitedhost-unknownhost-unreachablenetwork-prohibitednetwork-unknownnetwork-unreachableno-routeport-unreachableprecedence-cutoffprecedence-violationprotocol-unreachablesource-host-isolatedsource-route-failedtcp-reset` Auf PTX1000 Routern wird die Ablehnungsaktion nur für Eingangsschnittstellen unterstützt.	`family inet` `family inet6`
`routing-instance instance-name`	Leiten Sie das Paket an die angegebene Routinginstanz weiter.	`family inet` `family inet6`
`topology topology-name`	Leiten Sie das Paket an die angegebene Topologie weiter. HINWEIS: Diese Aktion wird auf Paketübertragungs-Routern der PTX-Serie nicht unterstützt. Jede Routinginstanz (primärer oder virtueller Router) unterstützt eine Standardtopologie, an die alle Weiterleitungsklassen weitergeleitet werden. Für Multitopologie-Routing können Sie einen Firewallfilter auf der Eingangsschnittstelle so konfigurieren, dass er eine bestimmte Weiterleitungsklasse, z. B. beschleunigte Weiterleitung, mit einer bestimmten Topologie abgleicht. Der Datenverkehr, der der angegebenen Weiterleitungsklasse entspricht, wird dann der Routingtabelle für diese Topologie hinzugefügt.	`family inet` `family inet6`

HINWEIS:

Konfigurieren Sie discard bei den Switch-Modellen QFX5120-48Y und QFX5120-32C die Aktion explizit so, dass eine BFD-Sitzung unterbrochen wird. Beachten Sie jedoch, dass die BFD-Sitzung nicht heruntergefahren wird, wenn vor der discard Aktion eine port-mirrorAktion konfiguriert ist.

Aktionen zum Beenden des Firewall-Filters

Verwandte Themen