Filter policies

This section defines packet match criteria supported on SR OS for IPv4, IPv6, and MAC filters. Supported criteria types depend on the hardware platform and filter direction, see your Nokia representative for more information.

General notes:

• If multiple unique match criteria are specified in a single filter policy entry, all criteria must be met in order for the packet to be considered a match against that filter policy entry (logical AND).

• Any match criteria not explicitly defined is ignored during match.

• An ACL filter policy entry with match criteria defined, but no action configured, is considered incomplete and inactive (an entry is not downloaded to the line card). A filter policy must have at least one entry active for the policy to be considered active.

• An ACL filter entry with no match conditions defined matches all packets.

• Because an ACL filter policy is an ordered list, entries should be configured (numbered) from the most explicit to the least explicit.

This section describes the IPv4 and IPv6 match criteria supported by SR OS. The criteria are evaluated against the outer IPv4 or IPv6 header and a Layer 4 header that follows (if applicable). Support for match criteria may depend on hardware or filter direction. Nokia recommends not configuring a filter in a direction or on hardware where a match criterion is not supported because this may lead to unwanted behavior. Some match criteria may be grouped in match lists and may be autogenerated based on the router configuration; see Filter policy advanced topics for more information.

IPv4 and IPv6 filter policies support three different filter types, including normal, source MAC, and packet length, with each supporting a different set of match criteria.

The match criteria available using the normal filter type are defined in this section. Layer 3 match criteria include:

• DSCP

  Match the specified DSCP command option against the Differentiated Services Code Point/Traffic Class field in the IPv4 or IPv6 packet header.

• source IP, destination IP, or IP

  Match the specified source or destination IPv4 or IPv6 address prefix against the IP address field in the IPv4 or IPv6 packet header. The user can optionally configure a mask to be used in a match. The ip command can be used to configure a single filter-policy entry that provides non-directional matching of either the source or destination (logical OR).

• flow label

  Match the specified flow label against the Flow label field in IPv6 packets. The user can optionally configure a mask to be used in a match. This operation is supported on ingress filters.

• protocol

  Match the specified protocol against the Protocol field in the IPv4 packet header (for example, TCP, UDP, IGMP) of the outer IPv4. ‟*” can be used to specify TCP or UDP upper-layer protocol match (Logical OR).

• Next Header

  Match the specified upper-layer protocol (such as, TCP, UDP, IGMPv6) against the Next Header field of the IPv6 packet header. ‟*” can be used to specify TCP or UDP upper-layer protocol match (Logical OR).

  Use the following command to match against up to six extension headers.

  configure system ip ipv6-eh max

  Use the following command to match against the Next Header value of the IPv6 header.

  configure system ip ipv6-eh limited

MAC filter policies support three different filter types with normal, ISID, and VID each supporting a different set of match criteria.

The following list describes the MAC match criteria supported by SR OS or switches for all types of MAC filters (normal, ISID, and VID). The criteria are evaluated against the Ethernet header of the Ethernet frame. Support for match criteria may depend on H/W or filter direction as described in the following description. Match criteria is blocked if it is not supported by a specified frame-type or MAC filter type. Nokia recommends not configuring a filter in a direction or on hardware where a match condition is not supported as this may lead to unwanted behavior.

You can configure the following MAC filter policy entry match criteria:

• frame format

  The filter searches to match a specific type of frame format. For example, configuring frame-type ethernet_II matches only ethernet-II frames.

• source MAC address

  The filter searches to match source MAC address frames. The user can optionally configure a mask to be used in a match.

• destination MAC address

  The filter searches to match destination MAC address frames. The user can optionally configure a mask to be used in a match.

• 802.1p frames

  The filter searches to match 802.1p frames. The user can optionally configure a mask to be used in a match.

• Ethernet II frames

  The filter searches to match Ethernet II frames. The Ethernet type field is a two-byte field used to identify the protocol carried by the Ethernet frame.

• source access point

  The filter searches to match frames with a source access point on the network node designated in the source field of the packet. The user can optionally configure a mask to be used in a match.

• destination access point

  The filter searches to match frames with a destination access point on the network node designated in the destination field of the packet. The user can optionally configure a mask to be used in a match.

• specified three-byte OUI

  The filter searches to match frames with the specified three-byte OUI field.

• specified two-byte protocol ID

  The filter searches to match frames with the specified two-byte protocol ID that follows the three-byte OUI field.

• ISID

  The filter searches to match for the matching Ethernet frames with the 24-bit ISID value from the PBB I-TAG. This match criterion is mutually exclusive of all the other match criteria under a specific MAC filter policy and is applicable to MAC filters of type ISID only. The resulting MAC filter can only be applied on a BVPLS SAP or PW in the egress direction.

• inner-tag or outer-tag

  The filter searches to match Ethernet frames with the non-service delimiting tags, as described in the VID MAC filters section. This match criterion is mutually exclusive of all other match criteria under a specific MAC filter policy and is applicable to MAC filters of type VID only.

An NGE node supports IPv4 exception filters. See Router encryption exceptions using ACLs for information about IP exception filters supported by NGE nodes.

The following actions are supported by ACL filter policies:

• drop

  Allows users 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-length value 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 or drop hop limit value are dropped. Packets that match only the filter policy entry match criteria and do not match the drop TTL value or drop 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 command identifies the starting point for the offset value and the supported offset-type command options 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 as defined in the filter entry. For example, if the pattern is expression 0xAA11, mask 0xFFFF, offset-type data, offset-value 20, 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 the drop or forward action.

• forward

  Allows users to accept traffic to ingress or egress the system and be subject to regular processing.

• accept a conditional filter action

  Allows users to accept a conditional filter action. Use the following commands to configure a conditional filter action:

  • MD-CLI

    configure filter ip-filter entry action accept-when
    configure filter ipv6-filter entry action accept-when

  • classic CLI

    configure filter ip-filter entry action forward-when
    configure filter ipv6-filter entry action forward-when

  • 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 users 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 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 users 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 limitedby 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.

  • Kilobits-per-second and packets-per-second rate limit

    The rate-limit action can be defined using kilobits per second or packets per second supported on both ingress and egress filter policies. The packets per second rate limit is not supported using a MAC filter policy and not supported on 7750 SR-a.

  • IPv4 packet-length and IPv6 payload-length conditional rate limit

    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 command identifies the starting point for the offset value and the supported offset-type command options 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 command option 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 and FP5-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 system forwards the packet.

    Cflowd, logging, and mirroring apply to all traffic matching this filter entry regardless of the pattern value.

  • extracted traffic conditional rate limit

    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 and Policy-based Forwarding (PBR/PBF) actions

  Allows users to allow ingress traffic but change the regular routing or forwarding that a packet would be subject to. The PBR/PBF is applicable to unicast traffic only. The following PBR or PBF actions are supported (See Configuring filter policies with CLI for more information):

  • 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, the system forwards the packet. 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 address

    Changes the IP destination address used in routing from the address in the packet to the address configured in this PBR action. The user 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 indirect 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 the 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 a user to remark the DiffServ Code Points (DSCP) of packets matching filter policy entry criteria. Packets are remarked regardless of QoS-based in- or 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. See section ‟Traffic Leaking to GRT” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN for more information.

  • 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.

• ISA forward processing actions

  ISA processing actions allow users to allow ingress traffic and send it for ISA processing as per specified ISA action. See Configuring filter policies with CLI for command details. The following ISA actions are supported:

  • GTP local breakout

    Forwards matching traffic to NAT instead of being GTP tunneled to the mobile user’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.

    For classic CLI options, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Classic CLI Command Reference Guide.

    For MD-CLI options, see 7450 ESS, 7750 SR, 7950 XRS, and VSR MD-CLI Command Reference Guide.

  • 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 for MSS adjustment

    Forwards matching packets (TCP SYN) to an ISA BB group for MSS adjustment. In addition to the IP filter, the user also needs to configure the MSS adjust group under the Layer 3 service to specify the 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 user to disable a filter entry, as a result the entry is not programmed in hardware.

In addition to the preceding actions:

• A user 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 the user can select a default action to be forward instead.

• A user 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

  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.

  Table 1. Default behavior when a PBR/PBF 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

A number of parameters determine the behavior of a packet after it has been matched to a defined criterion or set of criteria:

• the action configured by the user

• the context in which a filter policy is applied. For example, applying a filter policy in an unsupported context can result in simply forwarding the packet instead of applying the configured action.

• external factors, such as the reachability (according to specific test criteria) of a target

Use the following commands to display how a packet is handled by the system.

show filter ip
show filter ipv6
show filter mac

This section describes the key information displayed as part of the output for the preceding show commands, and how to interpret the information.

From a configuration point of view, the show command output displays the main action (primary and secondary), as well as the extended action.

The ‟PBR Target Status” field shows the basic information that the system has of the target based on simple verification methods. This information is only shown for the filter entries which are configured in redundancy mode (that is, with both primary and secondary main actions configured), and for ESI redirections. Specifically, the target status in the case of redundancy depends on several factors; for example, on a match in the routing table for next-hop redirects, or on VXLAN tunnel resolution for ESI redirects.

The ‟Downloaded Action” field specifically describes the action that the system performs on the packets that match the criterion (or criteria). This typically depends on the context in which the filter has been applied (whether it is supported or not), but in the case of redundancy, it also depends on the target status. For example, the downloaded action is the secondary main action when the target associated with the primary action is down. In the nominal (for example, non-failure condition) case the ‟Downloaded Action” reflects the behavior a packet is subject to. However, in transient cases (for example, in the case of a failure) it may not be able to capture what effectively happens to the packet.

The output also displays relevant information such as the default action when the target is down (see Default behavior when a PBR/PBF target is down) as well as the overridden default action when pbr‑down‑action‑override has been configured.

show filter ip effective-action
show filter ipv6 effective-action
show filter mac effective-action

The criteria for determining when a target is down. While there is little ambiguity on that aspect when the target is local to the system performing the steering action, ambiguity is much more prominent when the target is distant. Therefore, because the use of effective-action triggers advanced tests, a discrepancy is introduced compared to the action when effective-action command option is not used. This is, for example, be the case for redundant actions.

Filter policies support per-entry, packet/byte match statistics. The cumulative matched packet/Byte counters are available per ingress and per egress direction. Every packet arriving on an interface/service/subscriber using a filter policy increments ingress or egress (as applicable) matched packet/Byte count for a filter entry the packet matches (if any) on the line card the packet ingresses/egresses. For each policy, the counters for all entries are collected from all line cards, summarized and made available to an operator.

Filter policies applied on access interfaces are downloaded only to line cards that have interfaces associated with those filter policies. If a filter policy is not downloaded to any line card, the statistics show 0. If a filter policy is being removed from any of the line cards the policy is currently downloaded to (as result of association change or when a filter becomes inactive), the associated statistics are reset to 0.

Downloading a filter policy to a new line card continues incrementing existing statistics.

Operational notes:

Conditional action match criteria filter entries for ttl, hop-limit, packet-length, and payload-length support logging and statistics when the condition is met, allowing visibility of filter matched and action executed. If the condition is not met, packets are not logged and statistics against the entry are not incremented.

Notes related to filter log summarization:

• The implementation of the feature applies to filter logs with destination syslog.

• Summarization logging is the collection and summarization of log messages for one specific log ID within a period of time.

• The summarization interval is 100 seconds.

• Upon activation of a summary, a mini-table with source and destination address and count is created for each type (IPv4, IPv6, and MAC).

• Every received log packet (because of filter match) is examined for source or destination address.

• If the log packet (source/destination address) matches a source/destination address entry in the mini-table, from a packet received previously, the summary counter of the matching address is incremented.

• If source or destination address of the log messages does not match an entry already present in the table, the source/destination address is stored in a free entry in the mini-table.

• In case the mini-table has no more free entries, only total counter is incremented.

• At expiry of the summarization interval, the mini-table for each type is flushed to the syslog destination.

Filter policies can be used to control how cflowd sampling is performed on an IP interface. If an IP interface has cflowd sampling enabled, a user can exclude some flows for interface sampling by configuring filter policy rules that match the flows and by disabling interface sampling as part of the filter policy entry configurations. Use the following commands to disable interface sampling:

• MD-CLI

  configure filter ip-filter entry interface-sample false
  configure filter ipv6-filter entry interface-sample false

• classic CLI

  configure filter ip-filter entry interface-disable-sample
  configure filter ipv6-filter entry interface-disable-sample

If an IP interface has cflowd sampling disabled, a user can enable cflowd sampling on a subset of flows by configuring filter policy rules that match the flows and by enabling cflowd sampling as part of the filter policy entry configurations. Use the following commands to enable cflowd sampling on a subset of flows:

• MD-CLI

  configure filter ip-filter entry filter-sample true
  configure filter ipv6-filter entry filter-sample true

• classic CLI

  configure filter ip-filter entry filter-sample
  configure filter ipv6-filter entry filter-sample

The preceding cflowd filter sampling behavior is exclusively driven by match criteria. The sampling logic applies regardless of whether an action was executed (including evaluation of conditional action match criteria, for example, packet length or TTL).

The filter match lists ip-prefix-list, ipv6-prefix-list, protocol-list, and port-list define a list of IP prefixes, IP protocols, and TCP-UDP ports that can be used as match criteria for line card IP and IPv6 filters. Additionally, ip-prefix-list, ipv6-prefix-list, and port-list can also be used in CPM filters.

A match list simplifies the filter policy configuration with multiple prefixes, protocols, or ports that can be matched in a single filter entry instead of creating an entry for each.

The same match list can be used in one or many filter policies. A change in match list content is automatically propagated across all policies that use that list.

The system supports four different filter policies:

• scope template

• scope exclusive

• scope embedded

• scope system

Each scope provides different characteristics and capabilities to deploy a filter policy on a single interface, multiple interfaces or optimize the use of system resources or the management of the filter policies when sharing a common set of filter entries.

*[ex:/configure filter]
A:admin@node-2# info
...
    ip-filter "10" {
        scope embedded
        entry 10 {
        }
        entry 20 {
        }
        entry 30 {
        }
        entry 40 {
        }
    }
    ip-filter "100" {
        scope template
        entry 20010 {
        }
        entry 20020 {
        }
        embed {
            filter "10" offset 0 {
            }
        }
    }
    ip-filter "200" {
        scope template
        entry 100 {
        }
        entry 110 {
        }
        embed {
            filter "10" offset 10000 {
            }
        }
    }

*A:node-2>config>filter# info
----------------------------------------------
        ip-filter 10 name "10" create
            scope embedded
            entry 10 create
            exit
            entry 20 create
            exit
            entry 30 create
            exit
            entry 40 create
            exit
        exit
        ip-filter 100 name "100" create
            scope template
            embed-filter 10
            entry 20010 create
            exit
            entry 20020 create
            exit
        exit
        ip-filter 200 name "200" create
            scope template
            embed-filter 10 offset 10000
            entry 100 create
            exit
            entry 110 create
            exit
        exit
----------------------------------------------

*[ex:/configure filter]
A:admin@node-2# info
    ip-filter "10" {
        scope system
        entry 10 {
            description "Rate Limit NTP to the Infrastructure"
            match {
                protocol udp
                dst-ip {
                    ip-prefix-list "Infrastructure IPs"
                }
                dst-port {
                    eq 123
                }
            }
            action {
                accept
                rate-limit {
                    pir 2000
                }
            }
        }
    }
    ip-filter "100" {
        description "Filter scope template for network interfaces"
        chain-to-system-filter true
    }
    system-filter {
        ip "10" { }
    }

*A:node-2>config>filter# info
----------------------------------------------
        ip-filter 10 name "10" create
            scope system
            entry 10 create
                description "Rate Limit NTP to the Infrastructure"
                match protocol udp
                    dst-ip ip-prefix-list "Infrastructure IPs"
                    dst-port eq 123
                exit
                action
                    rate-limit 2000
                exit
            exit
        exit
        ip-filter 100 name "100" create
            chain-to-system-filter
            description "Filter scope template for network interfaces"
        exit
        system-filter
            ip 10
        exit
----------------------------------------------

The filter policy type defines the list of match criteria available in a filter policy. It provides filtering flexibility by reallocating the CAM in the line card at the filter policy level to filter traffic using additional match criteria not available using filter type normal. The filter type is specific to the filter policy, it is not a system wide or line card command option. You can configure different filter policy types on different interfaces of the same system and line card.

MAC filter supports three different filter types: normal, ISID, or VID.

IPv4 and IPv6 filters support four different filter types: normal, source MAC, packet length, or destination class.

By default, when a user assigns a filter policy to a LAG endpoint, the system allocates the same user-configured rate limit policer value for each FP of the LAG.

The shared policer feature changes this default behavior. When configured to true, the filter policy can only be assigned to endpoints of the same LAG and the configured rate limit policer value is shared between the LAG complexes based on the number of active ports in the LAG on each complex.

The shared policer feature is supported for IPv4 and IPv6 filter policies with the template or exclusive scope, in ingress and egress directions.

Filter policy entries can be statically configured using CLI, SNMP, or NETCONF or dynamically created using BGP FlowSpec, OpenFlow, VSD (XMPP), or RADIUS/Diameter for ESM subscribers.

Dynamic filter entries for FlowSpec, OpenFlow, and VSD can be inserted into an IPv4 or IPv6 filter policy. The filter policy must be either exclusive or a template. Additionally, FlowSpec embedding is supported when using a filter policy that defines system-wide filter rules.

*[ex:/configure router "Base"]
A:admin@node-2# info
    flowspec {
        ip-filter-max-size 50000
    }

[ex:/configure filter ip-filter "100"]
A:admin@node-2# info
...
    ip-filter "100" {
        embed {
            flowspec offset 100000 {
                router-instance "Base"
            }
        }
    }

*A:node-2>config>router# info
----------------------------------------------
        flowspec
            ip-filter-max-size 50000
        exit
----------------------------------------------
A:7750>config>filter# info
----------------------------------------------
        ip-filter 100 name "100" create
            embed-filter flowspec router "Base" offset 100000
        exit
----------------------------------------------

In some deployments, users may want to specify a backup PBR/PBF target if the primary target is down. SR OS allows the configuration of a primary action as part of a single filter policy entry. The secondary action can only be configured if a primary action is configured.

Use the commands in the following contexts to configure a primary action.

configure filter ip-filter entry action
configure filter ipv6-filter entry action
configure filter mac-filter entry action

configure filter ip-filter entry action secondary
configure filter ipv6-filter entry action secondary
configure filter mac-filter entry action secondary

For Layer 2 PBF redundancy, the user can configure the following redundancy command options. Use the forward sap, forward sdp, secondary forward sap, or secondary forward sdp options in the following contexts to configure Layer 2 PBF redundancy.

configure filter ip-filter entry action
configure filter ipv6-filter entry action
configure filter mac-filter entry action

For Layer 3 PBR redundancy, a user can configure any of the following actions as a primary action and any (either same or different than primary) of the following as a secondary action. Furthermore, none of the command options need to be the same between primary and secondary actions. Although the following commands pertain to IPv4 , similar command options also apply to IPv6.

Use the commands in the following contexts to configure forward actions:

• MD-CLI

  configure filter ip-filter entry action forward next-hop nh-ip-vrf
  configure filter ip-filter entry action forward vprn-target

• classic CLI

  configure filter ip-filter entry action forward
  

When primary and secondary actions are configured, PBR/PBF uses the primary action if its target is operationally up, or it uses the secondary action if the primary PBR/PBF target is operationally down. If both targets are down, the default action when the target is down (see Default behavior when a PBR/PBF target is down), according to the primary action, is used, unless the pbr-down-action-override command is configured.

When PBR/PBF redundancy is configured, the user can use sticky destination functionality for a redundant filter entry. When sticky destination is configured, the functionality mimics that of sticky destination configured for redirect policies.

Use the following commands to configure sticky destination.

configure filter ip-filter entry sticky-dest
configure filter ipv6-filter entry sticky-dest
configure filter mac-filter entry sticky-dest

Use the following commands to force a switchover from the secondary to the primary action when sticky destination is enabled and secondary action is selected.

tools perform filter ip-filter entry activate-primary-action
tools perform filter ipv6-filter entry activate-primary-action
tools perform filter mac-filter entry activate-primary-action

Sticky destination can be configured even if no secondary action is configured.

The control plane monitors whether primary and secondary actions can be performed and programs forwarding filter policy to use either the primary or secondary action as required. More generally, the state of PBR/PBF targets is monitored in the following situations:

• when a secondary action is configured

• when sticky destination is configured

• when a pbr-down-action-override is configured

Use the following command to display which redundant action is activated or downloaded, including when both PBR and PBF targets are down.

show filter ip 10 entry 1000

The following example shows the partial output of the command as applicable for PBF redundancy.

…
Primary Action      : Forward (SAP)
  Next Hop           : 1/1/1
  Service Id          : Not configured 
  PBR Target Status : Does not exist 
Secondary Action    : Forward (SAP)
  Next Hop          : 1/1/2 
  Service Id        : Not configured 
  PBR Target Status : Does not exist 
  PBR Down Action     : Forward (pbr-down-action-override)
  Downloaded Action   : None
  Dest. Stickiness    : 1000                         Hold Remain    : 0

In some deployment scenarios, for example, to realize service function chaining, users may want to perform a second action in addition to a traffic steering action. SR OS supports this behavior by configuring an extended action for a main action. This functionality is supported for Layer 3 traffic steering (that is, PBR) and specifically for the following main actions:

• forward ESI (Layer 3 version)

• forward LSP

• forward next-hop indirect router

• forward next-hop interface

• forward redirect-policy

• forward router

• forward VPRN target

The capability to specify an extended action is also supported in the case of PBR redundancy, for the following actions:

• forward next-hop indirect router
• forward VPRN target BGP next hop

The supported extended action is: remark dscp

Use the commands in the following contexts to configure the extended action:

• MD-CLI

  configure filter ip-filter entry action ignore-match
  configure filter ip-filter entry action ignore-match

• classic CLI

  configure filter ip-filter entry action extended-action
  configure filter ipv6-filter entry action extended-action

The VPRN target action is a resilient redirection capability which combines both datapath and control plane lookups to achieve the needed redirection. It allows for the following redirection models:

• redirection toward the default PE while selecting a specific LSP to use

• redirection toward an alternative PE while selecting or not a specific LSP to use. If a specific LSP is not selected, then the system automatically selects one based on the BGP next-hop tunnel resolution mechanism

• all of the preceding within any VPRN

When configuring this action, the user must specify the target BGP next-hop toward the redirection that should occur, as well as the routing context in which the necessary lookups are performed (to derive the service label).

The target BGP next-hop can be configured with any label allocation method (label per VRF, label per next-hop, label per prefix). These methods entail different forwarding behaviors; however, the steering node is not aware of the configuration of the target node. If the user does not specify an advertised route prefix, the steering node assumes that label per VRF is used by the target node and selects the service label accordingly. If the target node is not operating according to the label per VRF method, the user must specify an appropriate route prefix for which a service label is advertised by the target node, keeping in mind the resulting forwarding behavior at the target node of the redirected packet. This specification instructs the steering node to use that specific service label.

Be aware that the system performs an exact match between the specified IPv4 address and mask (or IPv6 address and prefix-length) and the advertised route.

The user can specify an LSP (RSVP-TE, MPLS-TP, or SR-TE LSP) to use toward the BGP next-hop. If no LSP is specified, the system automatically selects one the same way it would have done when normally forwarding a packet toward the BGP next-hop.

This action is resilient in that it tracks events affecting the redirection at the service level and reacts to those events. The system performs the redirection as long as it can reach the target BGP next-hop using the correct service label. If the redirection cannot be performed (for example, if no LSP is available, the peer is down, or there is no more specific labeled route), the system reverts to normal forwarding. This can be overridden and configured to drop. A maximum of 8k of unique (3-tuple {bgp-nh, router, adv-prefix}) redirection targets can be tracked.

For Layer 2 Policy-Based Forwarding (PBF) redirect actions, a far-end router may discard redirected packets when the PBF changes the destination IP interface the packet arrives on. This happens when a far-end IP interface uses a different MAC address than the IP interface reachable via normal forwarding (for example, one of the routers does not support a configurable MAC address per IP interface).

Use the following command to avoid the discards and deploy egress destination MAC rewrite functionality for VPLS SAPs.

configure service vpls sap egress dest-mac-rewrite

Layer 2 policy-based forwarding (PBF) redirect action shows a deployment.

When enabled, all unicast packets have their destination MAC rewritten to the user-configured value on a Layer 2 switch VPLS SAP. Multicast and broadcast packets are unaffected. The feature:

• Is supported for regular and split-horizon group Ethernet SAPs in a regular VPLS Service

• Is expected to be deployed on a SAP that faces far-end IP interface (either a SAP that is the target of PBF action, as shown in Layer 2 policy-based forwarding (PBF) redirect action, or a VPLS SAP of a downstream Layer 2 switch that is connected to a far-end router—not shown).

• Applies to any unicast egress traffic including LI and mirror.

The network port Layer 3 service-aware filter feature allows users to deploy VPRN service aware ingress filtering on network ports. A single ingress filter of scope template can each be defined for IPv4 and for IPv6 against a VPRN service. The filter applies to all unicast traffic arriving on auto-bind and explicit-spoke network interfaces for that service. The network interface can be either Inter-AS, or Intra-AS. The filter does not apply to traffic arriving on access interfaces (SAP, spoke SDP, network-ingress (CsC, rVPLS, eVPN).

The same filter can be used on access interfaces of the specific VPRN, can embed other filters (including OpenFlow), can be chained to a system filter, and can be used by other Layer 2 or Layer 3 services.

The filter is deployed on all line cards (chassis network mode D is required). There are no limitations related to filter match/action criteria or embedding. The filter is programmed online cards against ILM entries for this service. All label-types are supported. If an ILM entry has a filter index programmed, that filter is used when the ILM is used in packet forwarding; otherwise, no filter is used on the service traffic.

ISID filters are a type of MAC filter that allows filtering based on the ISID values instead of Layer 2 criteria used by MAC filters of type normal or VID. ISID filters can be deployed on iVPLS PBB SAPs and Epipe PBB SAPs in the following scenarios.

The MMRP usage of the MRP policy ensures automatically that traffic using Group B-MAC is not flooded between domains. However, there could be small transitory periods when traffic originated from PBB BEB with unicast B-MAC destination may be flooded in the BVPLS context as unknown unicast in the BVPLS context for both IVPLS and PBB Epipe. To restrict distribution of this traffic for local PBB services, ISID filters can be deployed. The MAC filter configured with ISID match criterion can be applied to the same interconnect endpoints (BVPLS SAP or PW) as the MRP policy to restrict the egress transmission of any type of frames that contains a local ISID. The ISID filters are applied as required on a per B-SAP or B-PW basis, only in the egress direction.

The ISID match criteria are exclusive with any other criteria under mac-filter. A new mac-filter type attribute is defined to control the use of ISID match criteria and must be set to ISID to allow the use of ISID match criteria.

VID filters are a type of MAC filters that extend the capability of current Ethernet ports with null or default SAP tag configuration to match and take action on VID tags. Service delimiting tags (for example, QinQ 1/1/1:10.20 or dot1q 1/1/1:10, where outer tag 10 and inner tags 20 are service delimiting) allow fine granularity control of frame operations based on the VID tag. Service delimiting tags are exact match and are stripped from the frame as shown in VID filtering examples. Exact match or service delimiting tags do not require VID filters. VID filters can only be used to match on frame tags that are after the service delimiting tags.

With VID filters, users can choose to match VID tags for up to two tags on ingress, egress, or both.

• The outer tag is the first tag in the packet that is carried transparently through the service.

• The inner tag is the second tag in the packet that is carried transparently through the service.

VID filters add the capability to perform VID value filter policies on default tags (1/1/1:*, or 1/1/1:x.*, or 1/1/1/:*.0) or null tags (1/1/1, 1/1/1:0, or 1/1/1:x.0). The matching is based on the port configuration and the SAP configuration.

At ingress, the system looks for the two outer-most tags in the frame. If present, any service delimiting tags are removed and not visible to VID MAC filtering. For example:

• 1/1/1:x.y SAP has no tag left for VID MAC filter to match on (outer-tag and inner-tag = 0)

• 1/1/1:x.* SAP has potentially one tag in the * position for VID MAC filter to match on

• SAP such as 1/1/1, 1/1/1:*, or 1/1/1:*.* can have as many as two tags for VID MAC filter to match on

• For the remaining tags, the left (outer-most) tag is what is used as the outer tag in the MAC VID filter. The following tag is used as the inner tag in the filter. If any of these positions do not have tags, a value of 0 is used in the filter. At egress, the VID MAC filter is applied to the frame before adding the additional service tags.

In the industry, the QinQ tags are often referred to as the C-VID (customer VID) and S-VID (service VID). The terms outer tag and inner tag allow flexibility without having to see C-TAG and S-TAG explicitly. The position of inner and outer tags is relative to the port configuration and SAP configuration. Matching of tags is allowed for up to the first two tags on a frame because service delimiting tags may be 0, 1, or 2 tags.

The meaning of inner and outer has been designed to be consistent for egress and ingress when the number of non-service delimiting tags is consistent. Service 1 in VID filtering examples shows a conversion from QinQ to a single dot1q example where there is one non-service delimiting tag on ingress and egress. Service 2 shows a symmetric example with two non-service delimiting tags (plus and additional tag for illustration) to two non-service delimiting tags on egress. Service 3 shows a single non-service delimiting tag on ingress and two tags with one non-service delimiting tag on ingress and egress.

SAP-ingress QoS command option allows for MAC-criteria type VID, which uses the VID filter matching capabilities of QoS and VID Filters (see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Quality of Service Guide).

A VID filter entry can also be used as a debug or lawful intercept mirror source entry.

VID filters are available on Ethernet SAPs for Epipe, VPLS, or I-VPLS including eth-tunnel and eth-ring services.

IP exception filters scan all outbound traffic entering an NGE domain and allow packets that match the exception filter criteria to transit the NGE domain unencrypted. For information about IP exception filters supported by NGE nodes, see Router encryption exceptions using ACLs.

The most basic IP exception filter policy must have the following:

• an exception filter policy ID

• scope, either exclusive or template

• at least one filter entry with a specified matching criteria

SR OS-based routers support configuring of IPv4 and IPv6 redirect policies. Redirect policies allow specifying multiple redirect target destinations and defining status check test methods used to validate the ability for a destination to receive redirected traffic. This destination monitoring allows routers to react to target destination failures. To specify an IPv4 redirect policy, define all destinations to be IPv4. To specify an IPv6 redirect policy, define all destinations to be IPv6. IPv4 redirect policies can only be deployed in IPv4 filter policies. IPv6 redirect policy can only be deployed in IPv6 filter policies.

Redirect policies support the following destination tests:

• ping-test – with configurable interval, drop-count, and timeout

• unicast-rt-test – for unicast routing reachability, supported only when router instance is configured for a specific redirect policy. The test yields true if the route to the specified destination exists in RTM for the configured router instance.

Each destination is assigned an initial or base priority describing this destination’s relative importance within the policy. The destination with the highest priority value is selected as most-preferred destination and programmed online cards in filter policies using this redirect policy as an action. Only destinations that are not disabled by the programmed test (if configured) are considered when selecting the most-preferred destination.

In some deployments, it may not be necessary to switch from a currently active, most-preferred redirect-policy destination when a new more-preferred destination becomes available. Use the following command to enable sticky destination functionality to support such deployments.

configure filter redirect-policy sticky-dest

When enabled, the currently active destination remains active unless it goes down or a user forces the switch. Use the following command to force the switch.

tools perform filter redirect-policy activate-best-dest

An optional sticky-dest hold-time-up value or no-hold-time-up command option is available to delay programming the sticky destination in the redirect policy (transition from action forward to PBR action to the most-preferred destination). When the timer is enabled, the first destination that comes up is not programmed and instead the timer is started. After the timer expires, the most-preferred destination at that time is programmed (which may be a different destination from the one that started the timer).

SR OS routers support redirecting HTTP traffic by using the line card ingress IP and IPv6 filter policy action HTTP redirect. This capability is mainly used in the configure subscriber-mgmt context to redirect a subscriber web session to a captive portal landing page:

Examples of use cases include redirecting a subscriber after initial connection to a new network to accept the terms of service, or a subscriber out-of-quota redirection.

Traffic matching the HTTP redirect filter entry is sent to the SF/CPM for HTTP redirection:

• The SF/CPM completes the TCP three-way handshake for new TCP sessions on behalf of the intended server, and responds to the HTTP GET request with a 302 redirect. Therefore, the subscriber web session is redirected to the portal landing page configured in the HTTP redirect filter action.

• Non TCP flows are ignored.

• TCP flows other than HTTP, matching an http-redirect filter action, are TCP reset after the three-way handshake. Therefore, it is recommended to configure the http-redirect filter entry to match only TCP port 80. HTTPs uses TLS as underlying protocol, and cannot be redirected to a landing page.

Additional subscriber information may be required by the captive portal. This information can be appended as variables in the http-redirect URL and automatically substituted with the relevant subscriber session data, as follows:

• $IP: subscriber host IP address

• $MAC: subscriber host MAC address

• $URL: original requested URL

• $SAP: subscriber SAP

• $SUB: subscriber identification string

• $CID: circuit-ID, or interface-ID of the subscriber host (hexadecimal format)

• $RID: remote-ID of the subscriber host (hexadecimal format)

• $SAPDESC: configured SAP description

*[ex:/configure filter]
A:admin@node-2# info
   ip-filter "10" {
        entry 10 {
            description "Allow DNS Traffic to DNS servers"
            match {
                protocol udp
                ip {
                ip-prefix-list "dns-servers"
                }
                dst-port {
                    eq 53
                }
            }
            action {
                accept
            }
        }
        entry 20 {
            description "Allow HTTP traffic to redirect portal"
            match {
                protocol tcp
                ip {
                ip-prefix-list "portal-servers"
                }
                dst-port {
                    eq 80
                }
            }
            action {
                accept
            }
        }
        entry 30 {
            description "HTTP Redirect all other TCP 80 flows"
            match {
                protocol tcp
                dst-port {
                    eq 80
                }
            }
            action {
                http-redirect {
                    url "http://www.mydomain/com/redirect.html?
subscriber=$SUB&ipaddress=$IP&mac=$MAC&location=$SAP."
                }
            }
        }
        entry 40 {
            description "Drop anything else"
            action {
                drop
            }
        }
    }

*A:node-2>config>filter# info
----------------------------------------------
        ip-filter 10 name "10" create
            entry 10 create
                description "Allow DNS Traffic to DNS servers"
                match protocol udp
                    dst-ip ip-prefix-list "dns-servers"
                    dst-port eq 53
                exit
                action
                    forward
                exit
            exit
            entry 20 create
                description "Allow HTTP traffic to redirect portal"
                match protocol tcp
                    dst-ip ip-prefix-list "portal-servers"
                    dst-port eq 80
                exit
                action
                    forward
                exit
            exit
            entry 30 create
                description "HTTP Redirect all other TCP 80 flows"
                match protocol tcp
                    dst-port eq 80
                exit
                action
                    http-redirect "http://www.mydomain/com/redirect.html?
subscriber=$SUB&ipaddress=$IP&mac=$MAC&location=$SAP."
                exit
            exit
            entry 40 create
                description "Drop anything else"
                action
                    drop
                exit
            exit
        exit
----------------------------------------------

*[ex:/configure system cpm-http-redirect]
A:admin@node-2# info detail
 ...
    optimized-mode true

*A:node-2>config>system>cpm-http-redirect# info detail
----------------------------------------------
            optimized-mode
----------------------------------------------

In some deployments, users may select to redirect ESM subscribers to Value Added Services (VAS). Various deployment models can be used but often subscribers are assigned to a specific residential tier-of-service, which also defines the VAS available to subscribers of the specific tier. The subscribers are redirected to VAS based on tier-of-service rules, but such an approach can be hard to manage when many VAS services/tiers of service are needed. Often the only way to identify a subscriber’s traffic with a specific tier-of-service is to preallocate IP/IPv6 address pools to a specific service tier and use those addresses in VAS PBR match criteria. This creates an application-services to network infrastructure dependency that can be hard to overcome, especially if fast and flexible application service delivery is needed.

Filter policy-based ESM service chaining removes ESM VAS steering to network infrastructure inter-dependency. A user can configure per tier of service or per individual VAS service upstream and downstream service chaining rules without a need to define subscriber or tier-of-service match conditions. ACL filter modeling for ESM service chaining shows a possible ACL model (embedded filters are used for VAS service chaining rules).

On the left in ACL filter modeling for ESM service chaining, the per-tier-of-service ACL model is depicted. Each tier of service (Gold or Silver) has a dedicated embedded VAS filter (‟Gold VAS”, ‟Silver VAS”) that contains all steering rules for all service chains applicable to the specific tier. Each VAS filter is then embedded by the ACL filter used by a specific tier. A subscriber is subject to VAS service chain rules based on the per-tier ACL assigned to that subscriber (for example, via RADIUS). If a new VAS rule needs to be added, a user must program that rule in all applicable tiers. Upstream and downstream rules can be configured in a single filter (as shown) or can use dedicated ingress and egress filters.

On the right in ACL filter modeling for ESM service chaining, the per-VAS-service ACL model is depicted. Each VAS has a dedicated embedded filter (‟VAS 1”, ‟VAS 2”, ‟VAS 3”) that contains all steering rules for all service chains applicable to that VAS service. A tier of service is then created by embedding multiple VAS-specific filters: Gold: VAS 1, VAS 2, VAS 3; Silver: VAS 1 and VAS 3. A subscriber is subject to VAS service chain rules based on the per-tier ACL assigned to that subscriber. If a new VAS rule needs to be added, a user needs to program that rule in a single VAS-specific filter only. Again, upstream and downstream rules can be configured in a single filter (as shown) or can use dedicated ingress and egress filters.

Upstream ESM ACL policy-based service chaining shows upstream VAS service chaining steering using filter policies. Upstream subscriber traffic entering Res-GW is subject to the subscriber's ingress ACL filter assigned to that subscriber by a policy server. If the ACL contains VAS steering rules, the VAS-rule-matching subscriber traffic is steered for VAS processing over a dedicated to-from-access VAS interface in the same or a different routing instance. After the VAS processing, the upstream traffic can be returned to Res-GW by a to-from-network interface (shown in Upstream ESM ACL policy-based service chaining) or can be injected to WAN to be routed toward the final destination (not shown).

Downstream ESM ACL-policy based service chaining shows downstream VAS service chaining steering using filter policies. Downstream subscriber traffic entering Res-GW is forwarded to a subscriber-facing line card. On that card, the traffic is subject to the subscriber's egress ACL filter policy processing assigned to that subscriber by a policy server. If the ACL contains VAS steering rules, the VAS rule-matching subscriber's traffic is steered for VAS processing over a dedicated to-from-network VAS interface (in the same or a different routing instance). After the VAS processing, the downstream traffic must be returned to Res-GW via a ‟to-from-network” interface (shown in Downstream ESM ACL-policy based service chaining) to ensure the traffic is not redirected to VAS again when the subscriber-facing line card processes that traffic.

Ensuring the correct configuration for the VAS interface type, for upstream and downstream traffic redirected to a VAS and returned after VAS processing, is critical for achieving loop-free network connectivity for VAS services.

Use the commands in the following contexts to configure the VAS interface type and command options, which are described in the preceding information.

configure service vprn if vas-if-type
configure service ies if vas-if-type
configure router if vas-if-type

• deployments that use two separate interfaces for VAS connectivity (which is recommended, and required if local subscriber-to-subscriber VAS traffic support is required):

  • to-from-access

    • upstream traffic arriving from subscribers over access interfaces must be redirected to a VAS PBR target reachable over this interface for upstream VAS processing

    • downstream traffic destined for subscribers after VAS processing must arrive on this interface, so that the traffic is subject to regular routing but is not subject to Application Assurance diversion, nor to egress subscriber PBR

    • the interface must not be used for downstream pre-VAS traffic; otherwise, routing loops occur

  • to-from-network

    • downstream traffic destined for subscribers arriving from network interfaces must be redirected to a VAS PBR target reachable over this interface for downstream VAS processing

    • upstream traffic after VAS processing, if returned to the router, must arrive on this interface so that regular routing can be applied

• deployments that use a single interface for VAS connectivity (optional, no local subscriber-to-subscriber VAS traffic support):

  • to-from-both

    • both upstream traffic arriving from access interfaces and downstream traffic arriving from the network are redirected to a PBR target reachable over this interface for upstream/downstream VAS processing

    • after VAS processing, traffic must arrive on this interface (optional for upstream), so that the traffic is subject to regular routing but is not subject to AA diversion, nor to egress subscriber PBR

    • the interface must be used for downstream pre-VAS traffic, otherwise, routing loops occur

The ESM filter policy-based service chaining allows users to do the following:

• Steer upstream and downstream traffic per-subscriber with full ACL-flow-defined granularity without the need to specify match conditions that identify subscriber or tier-of-service

• Steer both upstream and downstream traffic on a single Res-GW

• Flexibly assign subscribers to tier-of-service by changing the ACL filter policy a specific subscriber uses

• Flexibly add new services to a subscriber or tier-of-service by adding the subscriber-independent filter rules required to achieve steering

• Achieve isolation of VAS steering from other ACL functions like security through the use of embedded filters

• Deploy integrated Application Assurance (AA) as part of a VAS service chain—both upstream and downstream traffic is processed by AA before a VAS redirect

• Select whether to use IP-Src/IP-Dst address hash or IP-Src/IP-Dst address plus TCP/UDP port hash when LAG/ECMP connectivity to DC is used. Layer 4 inputs are not used in hash with IPv6 packets with extension headers present.

ESM filter policy-based traffic steering supports the following:

• IPv4 and IPv6 steering of unicast traffic using IPv4 and IPv6 ACLs

• use of an action forward redirect-policy filter or an action forward next-hop router filter for IP steering with TCAM-based load-balancing, -to-wire, and sticky destination

• use of an action forward ESI SF-IP VAS interface router filter for an integrated service chaining solution

The purpose policy-based forwarding is to capture traffic from a customer and perform a deep packet inspection (DPI) and forward traffic, if allowed, by the DPI.

In the following example, the split horizon groups are used to prevent flooding of traffic. Traffic from customers enter at SAP 1/1/5:5. Because mac-filter 100 that is applied on ingress, all traffic with dot1p 07 marking is forwarded to SAP 1/1/22:1, which is the DPI.

DPI performs packet inspection/modification and either drops the traffic or forwards the traffic back into the box through SAP 1/1/21:1. Traffic is then sent to spoke-sdp 3:5.

SAP 1/1/23:5 is configured to see if the VPLS service is flooding all the traffic. If flooding is performed by the router then traffic would also be sent to SAP 1/1/23:5 (which it should not).

Policy-based forwarding for deep packet inspection shows an example to configure policy-based forwarding for deep packet inspection on a VPLS service. For information about configuring services, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide.

*[ex:/configure service]
A:admin@node-2# info
...   
    vpls "10" {
        admin-state enable
        customer "1"
        service-mtu 1400
        fdb {
            static-mac {
                mac 00:00:00:31:11:01 {
                    sap 1/1/21:1
                }
                mac 00:00:00:31:12:01 {
                    sap 1/1/22:1
                }
                mac 00:00:00:31:13:05 {
                    sap 1/1/23:5
                }
            }
        }
        split-horizon-group "dpi" {
            residential true
        }
        split-horizon-group "split" {
        }
        sap 1/1/21:1 {
            split-horizon-group "split"
            fdb {
                mac-learning {
                    learning false
                }
            }
        }
        sap 1/1/22:1 {
            split-horizon-group "dpi"
            arp-reply-agent with-subscr-ident
            stp {
                admin-state disable
            }
            fdb {
                mac-pinning true
                mac-learning {
                    learning false
                }
            }
        }
        sap 1/1/23:5 {
        }
    }

*A:node-2>config>service# info
----------------------------------------------
...
        vpls 10 customer 1 create
            service-mtu 1400
            split-horizon-group "dpi" residential-group create
            exit
            split-horizon-group "split" create
            exit
            stp
                shutdown
            exit
            sap 1/1/21:1 split-horizon-group "split" create
                disable-learning
                static-mac 00:00:00:31:11:01 create
            exit
            sap 1/1/22:1 split-horizon-group "dpi" create
                disable-learning
                static-mac 00:00:00:31:12:01 create
            exit
            sap 1/1/23:5 create
                static-mac 00:00:00:31:13:05 create
            exit
            no shutdown
        exit
...
----------------------------------------------

*[ex:/configure filter]
A:admin@node-2# info
    mac-filter "100" {
        default-action accept
        entry 10 {
            log 101
            match {
                dot1p {
                    priority 7
                }
            }
            action {
                forward {
                    sap {
                        vpls "10"
                        sap-id 1/1/22:1
                    }
                }
            }
        }
    }
...

*A:node-2>config>filter# info
----------------------------------------------
...
        mac-filter 100 create
            default-action forward
            entry 10 create
                match
                    dot1p 7 7
                exit
                log 101
                action forward sap 1/1/22:1
            exit
        exit
...
----------------------------------------------

*[ex:/configure service]
A:admin@node-2# info
...
    vpls "10" {
        admin-state enable
        customer "1"
        service-mtu 1400
        fdb {
            static-mac {
                mac 00:00:00:31:11:01 {
                    sap 1/1/21:1
                }
                mac 00:00:00:31:12:01 {
                    sap 1/1/22:1
                }
                mac 00:00:00:31:13:05 {
                    sap 1/1/23:5
                }
                mac 00:00:00:31:15:05 {
                    sap 1/1/5:5
                }
            }
        }
        split-horizon-group "dpi" {
            residential true
        }
        split-horizon-group "split" {
        }
        spoke-sdp 3:5 {
        }
        sap 1/1/21:1 {
            admin-state enable
            split-horizon-group "split"
            fdb {
                mac-learning {
                    learning false
                }
            }
        }
        sap 1/1/22:1 {
            split-horizon-group "dpi"
            arp-reply-agent with-subscr-ident
            stp {
                admin-state disable
            }
            fdb {
                mac-pinning true
                mac-learning {
                    learning false
                }
            }
        }
        sap 1/1/5:5 {
            split-horizon-group "split"
            ingress {
                filter {
                    mac "100"
                }
            }
        }
    }
...

*A:node-2>config>service# info
----------------------------------------------
...
        vpls 10 customer 1 create
            service-mtu 1400
            split-horizon-group "dpi" residential-group create
            exit
            split-horizon-group "split" create
            exit
            stp
                shutdown
            exit
            sap 1/1/5:5 split-horizon-group "split" create
                ingress
                    filter mac 100
                exit
                static-mac 00:00:00:31:15:05 create
            exit
            sap 1/1/21:1 split-horizon-group "split" create
                disable-learning
                static-mac 00:00:00:31:11:01 create
            exit
            sap 1/1/22:1 split-horizon-group "dpi" create
                disable-learning
                static-mac 00:00:00:31:12:01 create
            exit
            sap 1/1/23:5 create
                static-mac 00:00:00:31:13:05 create
            exit
            spoke-sdp 3:5 create
            exit
            no shutdown
        exit
....
----------------------------------------------

FP2-, FP3-, FP4, and FP5-based cards store filter policy entries in dedicated memory banks in hardware, also referred to as CAM tables:

• IP/MAC ingress

• IP/MAC egress

• IPv6 ingress

• IPv6 egress

Additional CAM tables for CPM filters are used on SR-1, SR-1s, SR-2s line cards for MAC, IP and IPv6.

A filter policy has the following attributes:

• policy ID and policy name

• scope: template, exclusive, embedded, system

• type: normal, src-mac, packet-length

• one or more filter entries defining match criteria and action

• default action to define how packets that do not match any of the filter entries are handled

Use the commands in the following context to create a template IPv4 filter policy.

configure filter ip-filter

IPv6 filter policy configuration mimics IP filter policy configuration. See Creating an IPv4 filter policy.

Each filter policy must have the following:

• the filter policy type specified (MAC normal, MAC ISID, MAC VID)

• a filter policy ID

• a default action, either drop or forward

• filter policy scope, either exclusive or template

• at least one filter entry, with a match criterion defined

Configuring and applying IPv4 exception filter policies is optional. Each exception filter policy must have the following:

• an exception filter policy ID

• scope specified, either exclusive or template

• at least one filter entry with matching criteria specified

Configuring and applying IPv6 exception filter policies is optional. Each exception filter policy must have the following:

• an exception filter policy ID

• at least one filter entry with matching criteria specified

To create a match list, you must:

1. Specify a type of a match list (for example, an IPv4 address prefix list).

2. Define a unique match list name (for example, an IPv4-Deny-List).

3. Specify at least one entry in the list (for example, a valid IPv4 prefix).

The following example shows the IPv4 prefix list configuration and its usage in an IPv4 filter policy.

*[ex:/configure filter]
A:admin@node-2# info
...
    match-list {
        ip-prefix-list "IPv4-Deny-List" {
            description "IPv4-Deny-list"
            prefix 10.0.0.0/21 { }
            prefix 10.254.0.0/24 { }
        }
    }
    ip-filter "ip-edge-filter" {
        scope template
        filter-id 10
        entry 10 {
            match {
                src-ip {
                    ip-prefix-list "IPv4-Deny-List"
                }
            }
            action {
                drop
            }
        }
    }

*A:node-2>config>filter# info
----------------------------------------------
      match-list
        ip-prefix-list "IPv4-Deny-List" create
           description "IPv4-Deny-list"
           prefix 10.0.0.0/21
           prefix 10.254.0.0/24
        exit
     exit
     ip-filter 10 name "ip-edge-filter" create
        scope template
        entry 10 create
           match
              src-ip ip-prefix-list "IPv4-Deny-List"
           exit
           action 
               drop
            exit
      exit
exit

---------------------------------------------

Filter policies can be associated with the entities listed in Applying filter policies.

Configuring and applying redirect policies is optional. Each redirect policy must have the following:

• a destination IP address

• a priority (default is 100)

Configuring a ping test is recommended.

The following example shows the configuration for a redirect policy.

*[ex:/configure filter]
A:admin@node-2# info
    redirect-policy "redirect1" {
        admin-state enable
        destination 10.10.10.104 {
            priority 105
        }
        destination 10.10.10.105 {
            admin-state enable
            priority 95
            ping-test {
                timeout 30
                drop-count 5
            }
        }
        destination 10.10.10.106 {
            admin-state enable
            priority 90
        }
    }

*A:node-2>config>filter# info
----------------------------------------------
        redirect-policy "redirect1" create
            destination 10.10.10.104 create
                priority 105
                exit
                no shutdown
            exit
            destination 10.10.10.105 create
                priority 95
                ping-test
                    timeout 30
                    drop-count 5
                exit
                no shutdown
            exit
            destination 10.10.10.106 create
                priority 90
                exit
                no shutdown
            exit
...
----------------------------------------------

Traffic matching an IP filter can be tunneled with GRE using the following mechanisms:

• Configure a GRE tunnel template.

• Associate the GRE tunnel template with the forwarding action of an IPv4 or IPv6 filter using the forward gre-tunnel command.

The GRE tunnel template defines the command options to create the GRE header used to encapsulate matching IP traffic:

• One or more destination IP addresses must be defined in the GRE tunnel template.

  • If more than one destination is configured, traffic is hashed across all available destinations.

  • GRE-Tunnel-templates using IPv6 transport are limited to a single destination address.

  • Traffic is routed to the selected destination address based on the route table in the forwarding context of the IP filter.

• The source address can be configured to any address and is not validated against a local IP address on the local router.

• The optional GRE key command option can be populated with the ifIndex of the ingress interface on which the matching IP packet was received.

• An optional template command, skip-ttl-decrement, allows the TTL of the encapsulated IP packet not to be decremented when encapsulated into the GRE header.

The following example shows the configuration for an IPv4-based GRE tunnel template and an IPv6-based GRE tunnel template.

*[ex:/configure filter]
A:admin@node-2# info
    ip-filter "1" {
        entry 1 {
            pbr-down-action-override forward
            action {
            }
        }
    }
        entry 2 {
            action {
                forward {
                    gre-tunnel "greTunnel_ipv4"
                }
            }
        }
    }
    ip-filter "2" {
        entry 1 {
            action {
                forward {
                    gre-tunnel "greTunnel_ipv6"
                }
            }
        }
    }
    gre-tunnel-template "greTunnel_ipv4" {
        description "10.20.1.5"
        ipv4 {
            source-address 10.20.1.3
            destination-address 9.9.9.9 { }
            destination-address 10.20.1.5 { }
            destination-address 13.13.13.13 { }
        }
    }
    gre-tunnel-template "greTunnel_ipv6" {
        ipv6 {
            source-address 3ffe::a14:100
            gre-key if-index
            destination-address 3ffe::a01:102 { }
        }
    }

*A:node-2>config>filter# info
----------------------------------------------
 ...
        gre-tunnel-template "greTunnel_ipv4" create
            description "10.20.1.5"
            ipv4
                source-address 10.20.1.3
                destination-address 9.9.9.9
                destination-address 10.20.1.5
                destination-address 13.13.13.13
            exit
        exit
        gre-tunnel-template "greTunnel_ipv6" create
            ipv6
                gre-key if-index
                source-address 3ffe::a14:100
                destination-address 3ffe::a01:102
            exit
        exit
        ip-filter 1 name "1" create
            entry 1 create
                action
                exit
                pbr-down-action-override forward
            exit
            entry 2 create
                action
                    forward gre-tunnel "greTunnel_ipv4"
                exit
            exit
        exit
        ip-filter 2 name "2" create
            entry 1 create
                action
                    forward gre-tunnel "greTunnel_ipv6"
                exit
            exit
        exit
----------------------------------------------