The following actions are supported by ACL filter policies:
drop
Allows operators to deny traffic to ingress or egress the system.
IPv4 packet-length and IPv6 payload-length conditional drop
Traffic can be dropped based on IPv4 packet length or IPv6 payload length by specifying a packet length or payload length value or range within the drop filter action (the IPv6 payload length field does not account for the size of the fixed IP header, which is 40 bytes).
This filter action is supported on ingress IPv4 and IPv6 filter policies only, if the filter is configured on an egress interface the packet-length or payload-length match condition is always true.
This drop condition is a filter entry action evaluation, and not a filter entry match evaluation. Within this evaluation, the condition is checked after the packet matches the entry based on the specified filter entry match criteria.
Packets that match a filter policy entry match criteria and the drop packet-length-value or payload-length-value are dropped. Packets that match only the filter policy entry match criteria and do not match the drop packet-length-value or drop payload-lengthvalue are forwarded with no further matching in following filter entries.
Packets matching this filter entry and not matching the conditional criteria are not logged, counted, or mirrored.
IPv4 TTL and IPv6 hop limit conditional drop
Traffic can be dropped based on a IPv4 TTL or IPv6 hop limit by specifying a TTL or hop limit value or range within the drop filter action.
This filter action is supported on ingress IPv4 and IPv6 filter policies only. If the filter is configured on an egress interface the packet-length or payload-length match condition is always true.
This drop condition is a filter entry action evaluation, and not a filter entry match evaluation. Within this evaluation, the condition is checked after the packet matches the entry based on the specified filter entry match criteria.
Packets that match filter policy entry match criteria and the drop ttl-value or hop-limit-value are dropped. Packets that match only the filter policy entry match criteria and do not match the drop ttl-value or hop-limit-value are forwarded with no further match in following filter entries.
Packets matching this filter entry and not matching the conditional criteria are not logged, counted, or mirrored.
Pattern conditional drop
Traffic can be dropped when it is based on a pattern found in the packet header or data payload. The pattern is defined by an expression, mask, offset-type, and offset-value match in the first 256 bytes of a packet.
The pattern expression is up to 8 bytes long. The offset-type-value identifies the starting point for the offset-value and the supported offset type values are:
layer-3: layer 3 IP header
layer-4: layer 4 protocol header
data: data payload for TCP or UDP protocols
dns-qtype: DNS request or response query type
The content of the packet is compared with the expression/mask value found at the offset-type-value and offset-value as defined in the filter entry. For example, if the pattern is expression 0xAA11, mask 0xFFFF, offset-type data, offset-value 20, then the filter entry compares the content of the first 2 bytes in the packet data payload found 20 bytes after the TCP/UDP header with 0xAA11.
This drop condition is a filter entry action evaluation, and not a filter entry match evaluation. Within this evaluation, the condition is checked after the packet matches the entry based on the specified filter entry match criteria.
Packets that match a filter policy's entry match criteria and the pattern, are dropped. Packets that match only the filter policy's entry match criteria and do not match the pattern, are forwarded without a further match in subsequent filter entries.
This filtering capability is supported on ingress IPv4 and IPv6 policies using FP4-based line cards, and cannot be configured on egress. A filter entry using a pattern, is not supported on FP2 or FP3-based line cards. If programmed, the pattern is ignored and the action is forward.
Packets matching this filter entry and not matching the conditional criteria are not logged, counted, or mirrored.
drop-extracted-traffic — Traffic extracted to the CPM can be dropped using ingress IPv4 and IPv6 filter policies based on filter match criteria. Any IP traffic extracted to the CPM is subject to this filter action, including routing protocols, snooped traffic, and TTL expired traffic.
Packets that match the filter entry match criteria and extracted to the CPM are dropped. Packets that match only the filter entry match criteria and are not extracted to the CPM are forwarded with no further match in the subsequent filter entries.
Cflowd, log, mirror, and statistics apply to all traffic matching the filter entry, regardless of drop or forward action.
forward
Allows operators to accept traffic to ingress or egress the system and be subject to regular processing.
forward-when
Allows operators to accept a conditional filter action.
Pattern conditional accept
Traffic can be accepted based on a pattern found in the packet header or data payload. The pattern is defined by an expression, mask, offset-type, and offset-value match in the first 256 bytes of a packet. The pattern expression is up to 8 bytes long. The offset-type identifies the starting point for the offset-value and the supported offset types are:
layer-3: Layer 3 IP header
layer-4: Layer 4 protocol header
data: data payload for TCP or UDP protocols
dns-qtype: DNS request or response query type
The content of the packet is compared with the expression/mask value found at the offset-type and offset-value defined in the filter entry. For example, if the pattern is expression 0xAA11, mask 0xFFFF, offset-type data, and offset-value 20, then the filter entry compares the content of the first 2 bytes in the packet data payload found 20 bytes after the TCP/UDP header with 0xAA11.
This accept condition is a filter entry action evaluation, and not a filter entry match evaluation. Within this evaluation, the condition is checked after the packet matches the entry based on the specified filter entry match criteria. Packets that match a filter policy's entry match criteria and the pattern, are accepted. Packets that match only the filter policy's entry match criteria and do not match the pattern, are dropped without a further match in subsequent filter entries.
This filtering capability is supported on ingress IPv4 and IPv6 policies using FP4-based line cards and cannot be configured on egress. A filter entry using a pattern is not supported on FP2 or FP3-based line cards. If programmed, the pattern is ignored and the action is drop.
Packets matching this filter entry and not matching the conditional criteria are not logged, counted, or mirrored.
fc
Allows operators to mark the forwarding class (FC) of packets. This command is supported on ingress IP and IPv6 filter policies. This filter action can be combined with the rate-limit value action.
Packets matching this filter entry action bypass QoS FC marking and are still subject to QoS queuing, policing and priority marking.
The QPPB forwarding class takes precedence over the filter FC marking action.
rate-limit
This action allows operators to rate-limit traffic matching a filter entry match criteria using IPv4, IPv6, or MAC filter policies.
If multiple interfaces (including LAG interfaces) use the same rate-limit filter policy on different FPs, then the system allocates a rate limiter resource for each FP; an independent rate limit applies to each FP.
If multiple interfaces (including LAG interfaces) use the same rate-limit filter policy on the same FP, then the system allocates a single rate limiter resource to the FP; a common aggregate rate limit is applied to those interfaces.
Note that traffic extracted to the CPM is not rate limited by an ingress rate-limit filter policy while any traffic generated by the router can be rate limited by an egress rate-limit filter policy.
rate-limit filter policy entries can coexist with cflowd, log, and mirror regardless of the outcome of the rate limit. This filter action is not supported on egress on 7750 SR-a.
Rate limit policers are configured with MBS equals CBS equals 10 ms of the rate and high-prio-only equals 0.
Interaction with QoS: Packets matching an ingress rate-limit filter policy entry bypass ingress QoS queuing or policing, and only the filter rate limit policer is applied. Packets matching an egress rate-limit filter policy bypass egress QoS policing, normal egress QoS queuing still applies.
Traffic can be rate limited based on the IPv4 packet length and IPv6 payload length by specifying a packet-length value or payload-length value or range within the rate-limit filter action. The IPv6 payload-length field does not account for the size of the fixed IP header, which is 40 bytes.
This filter action is supported on ingress IPv4 and IPv6 filter policies only and cannot be configured on egress access or network interfaces.
This rate-limit condition is part of a filter entry action evaluation, and not a filter entry match evaluation. It is checked after the packet is determined to match the entry based on the configured filter entry match criteria.
Packets that match a filter policy’s entry match criteria and the rate-limit packet-length-value or rate-limit payload-length-value are rate limited. Packets that match only the filter policy’s entry match criteria and do not match the rate-limit packet-length-value or rate-limit payload-length-value are forwarded with no further match in subsequent filter entries.
Cflowd, logging, and mirroring apply to all traffic matching the ACL entry regardless of the outcome of the rate limiter and regardless of the packet-length-value or payload-length-value.
IPv4 TTL and IPv6 hop-limit conditional rate limit
Traffic can be rate limited based on the IPv4 TTL or IPv6 hop-limit by specifying a TTL or hop limit value or range within the rate-limit filter action using ingress IPv4 or IPv6 filter policies.
The match condition is part of action evaluation (for example, after the packet is determined to match the entry based on other match criteria configured). Packets that match a filter policy entry match criteria and the rate-limit ttl or hop-limit value are rate limited. Packets that match only the filter policy entry match criteria and do not match the rate-limit ttl or hop-limit value are forwarded with no further matching in the subsequent filter entries.
Cflowd, logging, and mirroring apply to all traffic matching the ACL entry regardless of the outcome of the rate-limit value and the ttl-value or hop-limit-value.
Pattern conditional rate limit
Traffic can be rate limited when it is based on a pattern found in the packet header or data payload. The pattern is defined by an expression, mask, offset-type, and offset-value match in the first 256 bytes of a packet. The pattern expression is up to 8 bytes long. The offset-type-value identifies the starting point for the offset-value and the supported offset type values are:
layer-3: layer 3 IP header
layer-4: layer 4 protocol header
data: data payload for TCP or UDP protocols
dns-qtype: DNS request or response query type
The content of the packet is compared with the expression/mask value found at the offset-type-value and offset-value defined in the filter entry. For example, if the pattern is expression 0xAA11, mask 0xFFFF, offset-type data, and offset-value 20, then the filter entry compares the content of the first 2 bytes in the packet data payload found 20 bytes after the TCP/UDP header with 0xAA11.
This rate limit condition is a filter entry action evaluation, and not a filter entry match evaluation. Within this evaluation, the condition is checked after the packet matches the entry based on the specified filter entry match criteria.
Packets that match a filter policy's entry match criteria and the pattern, are rate limited. Packets that match only the filter policy's entry match criteria and do not match the pattern, are forwarded without a further match in subsequent filter entries.
This filtering capability is supported on ingress IPv4 and IPv6 policies using FP4-based line cards and cannot be configured on egress. A filter entry using a pattern is not supported on FP2 or FP3-based line cards. If programmed, the pattern is ignored and the action is forward.
Cflowd, logging, and mirroring apply to all traffic matching this filter entry regardless of the pattern value.
Traffic extracted to the CPM can be rate limited using ingress IPv4 and IPv6 filter policies based on filter match criteria. Any IP traffic extracted to the CPM is subject to this filter action, including routing protocols, snooped traffic, and TTL expired traffic.
Packets that match the filter entry match criteria and are extracted to the CPM are rate limited by this filter action and not subject to distributed CPU protection policing.
Packets that match only the filter entry match criteria and are not extracted to the CPM are forwarded with no further match in the subsequent filter entries.
Cflowd, logging, and mirroring apply to all traffic matching the ACL entry regardless of the outcome of the rate limit or the extracted conditional match.
forward ‟Policy-based Routing/Forwarding (PBR/PBF) action”
Allows operators to allow ingress traffic but change the regular routing or forwarding that a packet would be a subject to. The PBR/PBF is applicable to unicast traffic only. The following PBR or PBF actions are supported (See CLI section for command details):
egress-pbr
Enabling egress-pbr activates a PBR action on egress, while disabling egress-pbr activates a PBR action on ingress (default).
The following subset of the PBR actions (defined as follows) can be activated on egress: redirect-policy, next-hop router, and esi.
Egress PBR is supported in IPv4 and IPv6 filter policies for ESM only. Unicast traffic that is subject to slow-path processing on ingress (for example, IPv4 packets with options or IPv6 packets with hop-by-hop extension header) does not match egress PBR entries. Filter logging, cflowd, and mirror source are mutually exclusive of configuring a filter entry with an egress PBR action. Configuring pbr-down-action-override, if supported with a specific PBR ingress action type, is also supported when the action is an egress PBR action. Processing defined by pbr-down-action-override does not apply if the action is deployed in the wrong direction. If a packet matches a filter PBR entry and the entry is not activated for the direction in which the filter is deployed, action forward is executed. Egress PBR cannot be enabled in system filters.
esi
Forwards the incoming traffic using VXLAN tunnel resolved using EVPN MP BGP control plane to the first service chain function identified by ESI (Layer 2) or ESI/SF-IP (Layer 3). Supported with VPLS (Layer 2) and IES/VPRN (Layer 3) services. If the service function forwarding cannot be resolved, traffic matches an entry and action forward is executed.
For VPLS, no cross-service PBF is supported; that is, the filter specifying ESI PBF entry must be deployed in the VPLS service where BGP EVPN control plane resolution takes place as configured for a specific ESI PBF action. The functionality is supported in filter policies deployed on ingress VPLS interfaces. BUM traffic that matches a filter entry with ESI PBF is unicast forwarded to the VTEP:VNI resolved through PBF forwarding.
For IES/VPRN, the outgoing R-VPLS interface can be in any VPRN service. The outgoing interface and VPRN service for BGP EVPN control plane resolution must again be configured as part of ESI PBR entry configuration. The functionality is supported in filter policies deployed on ingress IES/VPRN interfaces and in filter policies deployed on ingress and egress for ESM subscribers. Only unicast traffic is subject to ESI PBR; any other traffic matching a filter entry with Layer 3 ESI action is subjected to action forward.
When deployed in unsupported direction, traffic matching a filter policy ESI PBR/PBF entry is subject to action forward.
lsp
Forwards the incoming traffic onto the specified LSP. Supports RSVP-TE LSPs (type static or dynamic only), MPLS-TP LSPs, or SR-TE LSPs. Supported for ingress IPv4/IPv6 filter policies and only deployed on IES SAPs or network interfaces. If the configured LSP is down, traffic matches the entry and action forward is executed.
mpls-policy
Redirects the incoming traffic to the active instance of the MPLS forwarding policy specified by its endpoint. This policy is applicable on any ingress interface (egress is blocked). The traffic is subject to a plain forward if no policy matches the one specified, or if the policy has no programmed instance, or if it is applied on non-L3 interface.
next-hop
Changes the IP destination address used in routing from the address in the packet to the address configured in this PBR action. The operator can configure whether the next-hop IP address must be direct (local subnet only) or indirect (any IP). This functionality is supported for ingress IPv4/IPv6 filter policies only, and is deployed on Layer 3 interfaces. If the configured next-hop is not reachable, traffic is dropped and a ‟ICMP destination unreachable” message is sent. If the indirect keyword is not specified but the IP address is a remote IP address, traffic is dropped.
interface
Forwards the incoming traffic onto the specified IPv4 interface. Supported for ingress IPv4 filter policies in global routing table instance. If the configured interface is down or not of the supported type, traffic is dropped.
redirect-policy
Implements PBR next-hop or PBR next-hop router action with ability to select and prioritize multiple redirect targets and monitor the specified redirect targets so PBR action can be changed if the selected destination goes down. Supported for ingress IPv4 and IPv6 filter policies deployed on Layer 3 interfaces only. See section Redirect policies for further details.
remark dscp
Allows an operator to remark the DiffServ Code Points of packets matching filter policy entry criteria. Packets are remarked regardless of QoS-based in-/out-of- profile classification and QoS-based DSCP remarking is overridden. DSCP remarking is supported both as a main action and as an extended action. As a main action, this functionality applies to IPv4 and IPv6 filter policies of any scope and can only be applied at ingress on either access or network interfaces of Layer 3 services only. Although the filter is applied on ingress the dscp remarking effectively performed on egress. As an extended action, this functionality applies to IPv4 and IPv6 filter policies of any scope and can be applied at ingress on either access or network interfaces of Layer 3 services, or at egress on Layer 3 subscriber interfaces.
router
Changes the routing instance a packet is routed in from the upcoming interface’s instance to the routing instance specified in the PBR action (supports both GRT and VPRN redirect). It is supported for ingress IPv4/IPv6 filter policies deployed on Layer 3 interfaces. The action can be combined with the next-hop action specifying direct/indirect IPv4/IPv6 next hop. Packets are dropped if they cannot be routed in the configured routing instance. For further details, see section ‟Traffic Leaking to GRT” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN.
sap
Forwards the incoming traffic onto the specified VPLS SAP. Supported for ingress IPv4/IPv6 and MAC filter policies deployed in VPLS service. The SAP that the traffic is to egress on must be in the same VPLS service as the incoming interface. If the configured SAP is down, traffic is dropped.
sdp
Forwards the incoming traffic onto the specified VPLS SDP. Supported for ingress IPv4/IPv6 and MAC filter policies deployed in VPLS service. The SDP that the traffic is to egress on must be in the same VPLS service as the incoming interface. If the configured SDP is down, traffic is dropped.
srte-policy
Redirects the incoming traffic to the active instance of the SR-TE forwarding policy specified by its endpoint and color. This policy is applicable on any ingress interface (egress is blocked). The traffic is subject to a plain forward if no policy matches the one specified, or if the policy has no programmed instance, or if it is applied on non-L3 interface.
vprn-target
Redirects the incoming traffic in a similar manner to combined next-hop and LSP redirection actions, but with greater control and slightly different behavior. This action is supported for both IPv4 and IPv6 filter policies and is applicable on ingress of access interfaces of IES/VPRN services. See Filter policy advanced topics for further details.
forward ‟isa action”
ISA processing actions allow operator to allow ingress traffic and send it for ISA processing as per specified ISA action. The following ISA actions are supported (see CLI section for command details):
gtp-local-breakout
Forwards matching traffic to NAT instead of being GTP tunneled to the mobile operator’s PGW or GGSN. The action applies to GTP-subscriber-hosts. If filter is deployed on other entities, action forward is applied. Supported for IPv4 ingress filter policies only. If ISAs performing NAT are down, traffic is dropped.
nat
Forwards matching traffic for NAT. Supported for IPv4/IPv6 filter policies for Layer 3 services in GRT or VPRN. If ISAs performing NAT are down, traffic is dropped. (see CLI for options).
reassemble
Forwards matching packets to the reassembly function. Supported for IPv4 ingress filter policies only. If ISAs performing reassemble are down, traffic is dropped.
tcp-mss-adjust
Forwards matching packets (TCP Syn) to an ISA BB group for MSS adjustment. In addition to the IP filter, the operator also needs to configure the mss-adjust-group command under the Layer 3 service to specify the bb-group-id and the new segment-size.
http-redirect
Implements the HTTP redirect captive portal. HTTP GET is forwarded to CPM card for captive portal processing by router. See the HTTP redirect (captive portal) section for more information.
ignore-match
This action allow the operator to disable a filter entry, as a result the entry is not programmed in hardware.
In addition to the above actions:
An operator can select a default-action for a filter policy. The default action is executed on packets subjected to an active filter when none of the filter’s active entries matches the packet. By default, filter policies have default action set to drop but operator can select a default action to be forward instead.
An operator can override default action applied to packets matching a PBR/PBF entry when the PBR/PBF target is down using pbr-down-action-override. Supported options are to drop the packet, forward the packet, or apply the same action as configured for the filter policy's default-action. The override is supported for the following PBR/PBF actions. For the last three actions, the override is supported whether in redundancy mode or not.
forward esi (Layer 2 or Layer 3)
forward sap
forward sdp
forward next-hop [indirect] router
Table: Default behavior when a PBR/PBF target is down defines default behavior for packets matching a PBR/PBF filter entry when a target is down.
| PBR/PBF action | Default behavior when down |
|---|---|
forward esi (any type) |
Forward |
forward lsp |
Forward |
forward mpls-policy |
Forward |
forward next-hop (any type) |
Drop |
forward redirect-policy |
Forward when redirect policy is shutdown |
forward redirect-policy |
Forward when destination tests are enabled and the best destination is not reachable |
forward redirect-policy |
Drop when destination tests are not enabled and the best destination is not reachable |
forward sap |
Drop |
forward sdp |
Drop |
forward srte-policy |
Forward |
forward router |
Drop |
forward vprn-target |
Forward |