Supported Platforms
Related Documentation
- ACX, EX, M, MX, PTX, T Series
- Guidelines for Configuring Firewall Filters
- EX, M, MX, T Series
- Firewall Filter Nonterminating Actions
Firewall Filter Terminating Actions
Firewall filters support a set of terminating actions for each protocol family. A filter-terminating action halts all evaluation of a firewall filter for a specific packet. The router performs the specified action, and no additional terms are examined.
![]() | Note: You cannot configure the next term action with a terminating action in the same filter term. However, you can configure the next term action with another nonterminating action in the same filter term. |
Table 1 describes the terminating actions you can specify in a firewall filter term.
Table 1: Terminating Actions for Firewall Filters
Terminating Action | Description | Protocols |
---|---|---|
accept | Accept the packet. |
|
decapsulate gre [ routing-instance instance-name ] | At a customer-facing interface on an MX Series router installed at the provider edge (PE) of an IPv4 transport network, enable decapsulation of generic routing encapsulation (GRE) packets transported through a filter-based GRE tunnel. You can configure a filter term that pairs this action with a match condition that includes a packet header match for the GRE protocol. For an IPv4 filter, include the protocol gre (or protocol 47) match condition. Attach the filter to the input of an Ethernet logical interface or aggregated Ethernet interface on a Modular Interface Card (MIC) or Modular Port Concentrator (MPC) in the router. If you commit a configuration that attaches a de-encapsulating filter to an interface that does not support filter-based GRE tunneling, the system writes a syslog warning message that the interface does not support the filter. When the interface receives a matched packet, processes that run on the Packet Forwarding Engine perform the following operations:
By default, the Packet Forwarding Engine uses the default routing instance to forward payload packets to the destination network. If the payload is MPLS, the Packet Forwarding Engine performs route lookup on the MPLS path routing table using the route label in the MPLS header. If you specify the decapsulate action with an optional routing instance name, the Packet Forwarding Engine performs route lookup on the routing-instance, and the instance must be configured. For more information, see Understanding Filter-Based Tunneling Across IPv4 Networks and Components of Filter-Based Tunneling Across IPv4 Networks. |
|
discard | Discard a packet silently, without sending an Internet Control Message Protocol (ICMP) message. Discarded packets are available for logging and sampling. |
|
encapsulate template-name | At a customer-facing interface on an MX Series router installed at the provider edge (PE) of an IPv4 transport network, enable filter-based generic routing encapsulation (GRE) tunneling using the specified tunnel template. You can configure a filter term that pairs this action with the appropriate match conditions, and then attach the filter to the input of an Ethernet logical interface or aggregated Ethernet interface on a Modular Interface Card (MIC) or Modular Port Concentrator (MPC) in the router. If you commit a configuration that attaches an encapsulating filter to an interface that does not support filter-based GRE tunneling, the system writes a syslog warning message that the interface does not support the filter. When the interface receives a matched packet, processes that run on the Packet Forwarding Engine use information in the specified tunnel template to perform the following operations:
The specified tunnel template must be configured using the tunnel-end-point statement under the [edit firewall] or [edit logical-systems logical-system-name firewall] statement hierarchy. For more information, see Understanding Filter-Based Tunneling Across IPv4 Networks. |
|
logical-system logical-system-name | Direct the packet to the specified logical system. Note: This action is not supported on PTX Series Packet Transport Routers. |
|
reject message-type | Reject the packet and return an ICMPv4 or ICMPv6 message:
Note: Rejected packets can be sampled or logged if you configure the sample or syslog action. The message-type can be one of the following values: address-unreachable, administratively-prohibited, bad-host-tos, bad-network-tos, beyond-scope, fragmentation-needed, host-prohibited, host-unknown, host-unreachable, network-prohibited, network-unknown, network-unreachable, no-route, port-unreachable, precedence-cutoff, precedence-violation, protocol-unreachable, source-host-isolated, source-route-failed, or tcp-reset. |
|
routing-instance instance-name | Direct the packet to the specified routing instance. Note: This action is not supported on PTX Series Packet Transport Routers. |
|
topology topology-name | Direct the packet to the specified topology. Note: This action is not supported on PTX Series Packet Transport Routers. Each routing instance (master or virtual-router) supports one default topology to which all forwarding classes are forwarded. For multitopology routing, you can configure a firewall filter on the ingress interface to match a specific forwarding class, such as expedited forwarding, with a specific topology. The traffic that matches the specified forwarding class is then added to the routing table for that topology. |
|
Related Documentation
- ACX, EX, M, MX, PTX, T Series
- Guidelines for Configuring Firewall Filters
- EX, M, MX, T Series
- Firewall Filter Nonterminating Actions
Published: 2013-08-28
Supported Platforms
Related Documentation
- ACX, EX, M, MX, PTX, T Series
- Guidelines for Configuring Firewall Filters
- EX, M, MX, T Series
- Firewall Filter Nonterminating Actions