• No results found

Table 22: Terminating Actions for Firewall Filters (continued)

Protocols Description

Terminating Action

family inet At a customer-facing interface on an MX Series router installed at the provider edge

(PE) of an IPv4 transport network, enable de-encapsulation 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 theprotocol gre (orprotocol 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:

Remove the outer GRE header.

Forward the inner payload packet to its original destination by performing destination lookup.

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 thedecapsulateaction with an optional routing instance name, the Packet Forwarding Engine performs route lookup on the routing instance, and the instance must be configured.

NOTE: Thedecapsulateaction that you configure at the[edit firewall family inet filter filter-name term term-name]hierarchy level does not process traffic with IPv4 and IPv6 options. As a result, traffic with such options is discarded by the de-encapsulation of GRE packets functionality.

For more information, see Understanding Filter-Based Tunneling Across IPv4 Networks and Components of Filter-Based Tunneling Across IPv4 Networks.

decapsulate gre [ routing-instance instance-name ]

Chapter 2: Firewall Filter Match Conditions and Actions

Table 22: Terminating Actions for Firewall Filters (continued)

At a customer-facing interface on an MX Series router installed at the provider edge

(PE) of an IPv4 transport network, enable de-encapsulation of Layer 2 tunneling protocol (L2TP) packets transported through a filter-based L2TP tunnel.

You can configure a filter term that pairs this action with a match condition that includes a packet header match for the L2TP protocol. For IPv4 traffic, an input firewall filter

$junos-input-filterand an output firewall filter$junos-output-filterare attached to the interface. 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 L2TP tunneling, the system writes a syslog warning message that the interface does not support the filter.

The remote tunnel endpoint sends an IP tunnel packet that contains an Ethernet MAC address in the payload. If the destination MAC address of the payload packet contains the MAC address of the router, the Ethernet packet is sent in the outgoing direction towards the network, and it is processed and forwarded as though it is received on the customer port. If the source MAC address of the payload packet contains the MAC address of the router, the Ethernet packet is transmitted in the outgoing direction towards the customer port. If the tunnel does not contain the receive-cookie configured, packet injection does not happen. In such a case, any received tunnel packet is counted and dropped in the same manner in which packets that arrive with a wrong cookie are counted and dropped.

The following parameters can be specified with thedecapsulate l2tpaction:

routing-instance instance-name—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 decapsulateaction with an optional routing instance name, the Packet Forwarding Engine performs route lookup on the routing instance, and the instance must be configured.

forwarding-class class-name—(Optional) Classify l2TP packets to the specified forwarding class.

output-interface interface-name—(Optional) For L2TP tunnels, enable the packet to be duplicated and sent towards the customer or the network (based on the MAC address in the Ethernet payload).

cookie l2tpv3-cookie—(Optional) For L2TP tunnels, specify the L2TP cookie for the duplicated packets. If the tunnel does not contain the receive-cookie configured, packet injection does not happen. In such a case, any received tunnel packet is counted and dropped in the same manner in which packets that arrive with a wrong cookie are counted and dropped.

sample—(Optional) Sample the packet. Junos OS does not sample packets originating from the router. If you configure a filter and apply it to the output side of an interface, then only the transit packets going through that interface are sampled. Packets that are sent from the Routing Engine to the Packet Forwarding Engine are not sampled.

NOTE: Thedecapsulate l2tpaction that you configure at the[edit firewall family inet filter filter-name term term-name]hierarchy level does not process traffic with IPv4 and IPv6 options. As a result, traffic with such options is discarded by the de-encapsulation of L2TP packets functionality.

Table 22: Terminating Actions for Firewall Filters (continued)

Protocols Description

Terminating Action

family any

family inet

family inet6

family mpls

family vpls

family ccc

family bridge

family ethernet-switching (for EX Series switches only) Discard a packet silently, without sending an Internet Control Message Protocol (ICMP)

message. Discarded packets are available for logging and sampling.

discard

family inet

family inet6

family any

family mpls 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:

1. Attach a GRE header (with or without a tunnel key value, as specified in the tunnel template.

2. Attach a header for the IPv4 transport protocol.

3. Forward the resulting GRE packet from the tunnel source interface to the tunnel destination (the remote PE router).

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]hierarchy level. For more information, see Understanding Filter-Based Tunneling Across IPv4 Networks.

encapsulate template-name

Chapter 2: Firewall Filter Match Conditions and Actions

Table 22: Terminating Actions for Firewall Filters (continued)

At a customer-facing interface on an MX Series router installed at the provider edge

(PE) of an IPv4 transport network, enable filter-based L2TP 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:

1. Attach an L2TP header (with or without a tunnel key value, as specified in the tunnel template).

2. Attach a header for the IPv4 transport protocol.

3. Forward the resulting L2TP packet from the tunnel source interface to the tunnel destination (the remote PE router). The specified tunnel template must be configured using thetunnel-end-pointstatement under the[edit firewall]or[edit logical-systems logical-system-name firewall]statement hierarchy. Direct the packet to the specified logical system.

NOTE: This action is not supported on PTX Series Packet Transport Routers.

logical-system logical-system-name

family inet

family inet6 Reject the packet and return an ICMPv4 or ICMPv6 message:

If nomessage-typeis specified, adestination unreachablemessage is returned by default.

Iftcp-resetis specified as themessage-type,tcp-resetis returned only if the packet is a TCP packet. Otherwise, theadministratively-prohibitedmessage, which has a value of 13, is returned.

If any othermessage-typeis specified, that message is returned.

NOTE: Rejected packets can be sampled or logged if you configure thesampleorsyslog action.

Themessage-typecan 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, ortcp-reset.

reject message-type

family inet

family inet6 Direct the packet to the specified routing instance.

routing-instance instance-name

Table 22: Terminating Actions for Firewall Filters (continued)

Protocols Description

Terminating Action

family inet

family inet6 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.

topology topology-name

Related Documentation

Guidelines for Configuring Firewall Filters on page 22