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.

IPv4 and IPv6 filter policies support three four filter types, including normal, source MAC, packet length, and destination class, 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

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

IP exception filters allow specific flows to pass through an IPsec-secured interface in the clear, should exceptions be required on the IPsec secured interface.

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.

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

  Rate limit policers are configured with the maximum burst size (MBS) equals the committed burst size (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 and is supported on both ingress and egress filter policies. The MBS value can also be configured using the kilobits-per-second policer.

    The packets-per-second rate limit and kilobits-per-second MBS are not supported when using a MAC filter policy.

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

• • 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). In the indirect case, 0.0.0.0 (for IPv4) or :: (for IPv6) is allowed. Default routes may be different per VRF. 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.

  • 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 sectionRedirect 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 7705 SAR Gen 2 Layer 3 Services Guide: IES and VPRN for more information.

• 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 7705 SAR Gen 2 Classic CLI Command Reference Guide.

    For MD-CLI options, see 7705 SAR Gen 2 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.

• 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 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 router	Drop

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.

The SR OS supports logging of information from the packets that match a specific filter policy. Logging is configurable per filter policy entry by specifying a preconfigured filter log using the following command.

configure filter log

A filter log can be applied to ACL filters. Operators can configure multiple filter logs and specify the following:

• memory allocated to a filter log destination

• Syslog ID for a filter log destination

• filter logging summarization

• wrap-around behavior

The following are 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 a source and destination address and a count is created for each filter type (IPv4, IPv6, and MAC).

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

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

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

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

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

The filter match lists ip-prefix-list, ipv6-prefix-list, protocol-list, port-list, ip-packet-length-list, and ipv6-packet-length-list define a list of IP prefixes, IP protocols, TCP-UDP ports, and packet-length values or ranges 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.

Filter policy entries can be statically configured using CLI, SNMP, or NETCONF or dynamically created using BGP FlowSpec, OpenFlow, VSD (XMPP).

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:node-2>config>filter# info
----------------------------------------------
        ip-filter 100 name "100" create
            embed-filter flowspec router "Base" offset 100000
        exit
----------------------------------------------

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

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 on line 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.

IP exception filters scan all outbound traffic entering an NGE domain or an IPsec secured interface and allow packets that match the exception filter criteria to transit the NGE domain or secured interface 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 time-out

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

Each destination is assigned an initial or base priority describing relative importance of this destination within the policy. The destination with the highest priority value is selected as the most-preferred destination and programmed on line 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). The following restrictions apply:

• When the manual switchover to most-preferred destination is executed, the hold-time-up delay is stopped.

• When the timer value is modified, the new value takes immediate effect and the timer is restarted with the new value (or expired if no-hold-time-up is configured).

The following restrictions apply to the redirect policy feature:

• Redirect policies are supported for ingress IPv4 and IPv6 filter policies only.

• Different platforms support different scales for redirect policies. Contact Nokia technical support to ensure the planned deployment does not exceed the recommended scale.

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

A filter policy has the following attributes:

• policy ID and policy name

• scope: template, exclusive, embedded, system

• type: normal

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

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, the user must do the following:

1. Specify a type of 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 include 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
...
----------------------------------------------