4.1.1.1. Filter Policy Packet Match Criteria

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:

4.1.1.2. IPv4/IPv6 Filter Policy Entry Match Criteria

The IPv4 and IPv6 match criteria supported by SR OS are listed below. The criteria are evaluated against the outer IPv4/IPv6 header and a Layer 4 header that follows (if applicable). Support for match criteria may depend on hardware or filter direction, as described below. Nokia recommends not configuring a filter in a direction or on hardware where a match criterion is not supported as this may lead to unwanted behavior. Some match criteria may be grouped in match lists and may be auto-generated based on router configuration, see Filter Policy Advanced Topics for more information.

IPv4 and IPv6 filter policies support three different filter type with normal, src-mac and packet-length each supporting different set of match criteria.

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

Fragmentation match criteria:

IPv4 options match criteria:

IPv6 Extension Header match criteria:

Up to six extension headers are matched against when config>system>ip>ipv6-eh max is configured. When config>system>ip>ipv6-eh limited is configured, the next header value of the IPv6 header is used instead.

Upper-layer protocol match criteria:

Filter type match criteria:

Additional match criteria for src-mac, packet-length and destination-class are available using different filter types. See Filter Policy Type for more information.

4.1.1.3. MAC Filter Policy Entry Match Criteria

MAC filter policies support 3 different filter type with normal, isid and vid each supporting 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 a match criteria may depend on H/W and/or filter direction as per below description. Match criterion 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.

4.1.1.4. IP Exception Filters

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

4.1.1.5. Filter Policy Actions

The following actions are supported by ACL filter policies:

In addition to the above actions:

4.1.1.6. Viewing Filter Policy Actions

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

Because of this, SR OS provides the following commands that enable the user to capture this context globally and identify how a packet is handled by the system:

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

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 to 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 Table 9) as well as the overridden default action when pbr-down-action-override has been configured.

There are situations where, collectively, this information does not capture what effectively happens to the packet throughout the system. The effective-action keyword of the show>filter>[{ip | ipv6 | mac}] commands enables advanced checks to be performed and accurate packet fates to be displayed.

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 keyword is not used. This is, for example, be the case for redundant actions.

4.1.1.7. Filter Policy Statistics

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:

4.1.1.8. Filter Policy Logging

SR OS supports logging of the information from the packets that match a specific filter policy. Logging is configurable per filter policy entry by specifying preconfigured filter log (config>filter>log). A filter log can be applied to ACL filters and CPM hardware filters. Operators can configure multiple filter logs and specify: memory allocated to a filter log destination, syslog ID for filter log destination, filter logging summarization, and wrap-around behavior.

Notes related to filter log summarization:

Operational note:

4.1.1.9. Filter Policy cflowd Sampling

Filter policies can be used to control how cflowd sampling is performed on an IP interface. If an IP interface has cflowd sampling enabled, an operator 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 (interface-disable-sample). If an IP interface has cflowd sampling disabled, an operator 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 (filter-sample).

The above 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).

4.1.1.10. Filter Policy Management

4.1.2.1. Match List for Filter Policies

The filter match list 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.

4.1.2.2. Filter Policy Scope and Embedded Filters

The system supports four different filter policies:

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.

Template and Exclusive

A filter policy of scope template can be re-used across multiple interfaces. This filter policy uses a single set of resources per line card regardless of how many interfaces use it. Template filter policies used on access interfaces consume resources on line cards where the access interfaces are configured only. A filter policy of scope template is the most common type of filter policies configured in a router.

A filter policy of scope exclusive defines a filter dedicated to a single interface. An exclusive filter allows the highest level of customization but uses the most resources on the system line cards as it cannot be shared with other interfaces.

Embedded

To simplify the management of filters sharing a common set of filter entries, the operator can create a filter policy of scope embedded. This filter can then be included in (embedded into) a filter of scope template, exclusive or system.

Using filter scope embedded, a common set of filter entries can be updated in a single place and deployed across multiple filter policies. The scope embedded is supported for IPv4 and IPv6 filter policies.

A filter policy of scope embedded is not directly downloaded to a line card and cannot be directly referenced in an interface. However, this policy helps the network operator provision a common set of rules across different filter policies.

The following rules apply when using filter policy of scope embedded:

Figure 22 shows a configuration with two filter policies of scope template, filter 100 and 200 each embed filter policy 10 at a different offset:

Figure 22:  Embedded Filter Policy 

System

The filter policy of scope system provides the most optimized use of hardware resources by programming filter entries once in the line cards regardless of how many IPv4 or IPv6 filter policies of scope template or exclusive use this filter. The system filter policy entries are not duplicated inside each policy that uses it, instead, template or exclusive filter policies can be chained to the system filter using the chain-to-system-filter command.

When a template of exclusive filter policy is chained to the system filter, system filter rules are evaluated first before any rules of the chaining filter are evaluated (that is chaining filter's rules are only matched against if no system filter match took place).

The system filter policy is intended primarily to deploy a common set of system-level deny rules and infrastructure-level filtering rules to allow, block, or rate limit traffic. Other actions like, for example, PBR actions, or redirect to ISAs should not be used unless the system filter policy is activated only in filters used by services that support such action. The “nat” action is not supported and should not be configured. Failure to observe these restrictions can lead to unwanted behavior as system filter actions are not verified against the services the chaining filters are deployed for. System filter policy entries also cannot be the sources of mirroring.

System filter policies can be populated using CLI, SNMP, Netconf, Openflow and Flowspec. System filter policy entries cannot be populated using RADIUS or Gx.

An example for IPv4 system filter configuration is shown as follows:

4.1.2.3. Filter Policy Type

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 setting. The operator 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, src-mac, packet-length or destination-class.

4.1.2.4. Filter Policies and Dynamic Policy-Driven Interfaces

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 in a filter policy of scope template or exclusive using the embed-filter command in IPv4 and IPv6 filter policies. Additionally, flowspec embedding is supported using a filter policy of scope system.

BGP flowspec

BGP FlowSpec routes are learned in a particular routing instance and can be used to dynamically create filter entries in a given filter policy using the embed-filter flowspec command.

The following rules apply to FlowSpec embedding:

The following is a FlowSpec configuration example:

OpenFlow

The embedded filter infrastructure is used to insert OpenFlow rules into an existing filter policy. See Hybrid OpenFlow Switch for more details. Policy-controlled auto-created filters are re-created on system reboot. Policy controlled filter entries are lost on system reboot and need to be re-programmed.

VSD

VSD filters are created dynamically using XMPP and managed using a Python script so rules can be inserted into or removed from the correct VSD template or embedded filters. XMPP messages received by the 7750 SR are passed transparently to the Python module to generate the appropriate CLI. For more information about VSD filter provisioning, automation, and Python scripting details refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide: VLL, VPLS, PBB, and EVPN.

RADIUS/Diameter for Subscriber Management

The operator can assign filter policies or filter entries used by a subscriber within a preconfigured filter entry range defined for RADIUS or Diameter. Refer to the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide and filter RADIUS-related commands for more details.

4.1.2.5. Primary and Secondary Filter Policy Action for PBR/PBF Redundancy

In some deployments, operators may want to specify a backup PBR/PBF target if the primary target is down. SR OS allows the configuration of a primary action (config>filter>{ip-filter | ipv6-filter | mac-filter}>entry>action) and a secondary action (config>filter>{ip-filter | ipv6-filter | mac-filter}>entry>action secondary) as part of a single filter policy entry. The secondary action can only be configured if the primary action is configured.

For Layer 2 PBF redundancy, the operator can configure the following redundancy options:

For Layer 3 PBR redundancy, an operator 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 parameters need to be the same between primary and secondary actions. Although the following commands refer to IPv4 in the ip-address parameter, they also apply to IPv6.

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 Table 9), as per the primary action, is used, unless pbr-down-action-override is configured.

When PBR/PBF redundancy is configured, the operator can use sticky destination functionality for a redundant filter entry. When sticky destination is configured (config>filter>{ip-filter | ipv6-filter | mac-filter}>entry>sticky-dest), the functionality mimics that of sticky destination configured for redirect policies. To force a switchover from the secondary to the primary action when sticky destination is enabled and secondary action is selected, the operator can use the tools>perform>filter>{ip-filter | ipv6-filter | mac-filter}>entry>activate-primary-action command. 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:

The show>filter>{ip-filter | ipv6-filter | mac-filter} [entry] command displays which redundant action is activated or downloaded, including when both PBR/PBF targets are down. The following example shows partial output of the command as applicable for PBF redundancy.

4.1.2.6. Extended Action for Performing Two Actions at a Time

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

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

The supported extended action is:

The extended action is available in the following contexts: config>filter>ip-filter>entry>action>extended-action and config>filter>ipv6-filter>entry>action>extended-action.

If the status of the target of the main action is tracked, which is the case for PBR/PBF redundancy, the extended action listed above is not performed when the PBR target is down. Moreover, a filter policy containing an entry with the extended action remark dscp is blocked in the following cases:

The latter case includes actions that are not supported on egress (and for which egress-pbr cannot be set).

4.1.2.7. Advanced VPRN Redirection

The vprn-target action is a resilient redirection capability which combines both data-path and control plane lookups to achieve the desired redirection. It allows for the following redirection models:

When configuring this action, the user must specify the target BGP next-hop (bgp-nh) towards which the redirection should occur, as well as the routing context (router) 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 (adv-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 and exact match between the specified ip-address/mask (or ipv6-address/prefix-length) and the advertised route.

The user can specify an LSP (RSVP-TE, MPLS-TP, or SR-TE LSP) to use towards 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 towards the BGP next-hop.

Note: While the system only performs the redirection when the traffic is effectively able to reach the target BGP next-hop, it does not verify whether the redirected packets effectively reach their destination after that.

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

4.1.2.8. Destination MAC Rewrite When Deploying Policy-Based Forwarding

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). To avoid the discards, operators can deploy egress destination MAC rewrite functionality for VPLS SAPs (config>service>vpls>sap>egress>dest-mac-rewrite). Figure 23 shows a sample deployment.

Figure 23:  Layer 2 Policy-Based Forwarding (PBF) redirect action 

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

Restrictions:

4.1.2.9. Network-port VPRN Filter Policy

Network-port Layer 3 service-aware filter feature allows operators 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.

Restrictions:

4.1.2.10. ISID MAC Filters

ISID filters are a type of MAC filters that allows filtering based on the ISID values rather than 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.

4.1.2.11. VID MAC Filters

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 Figure 24. 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, operators can choose to match VID tags for up to two tags on ingress, egress, or both.

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:

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 refer to 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 Figure 24 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 setting 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.

Figure 24:  VID Filtering Examples 

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

4.1.2.11.2. Port Group Configuration Example

Figure 25:  Port Groups 

Figure 25 shows a customer use example where some VLANs are prevented from ingressing or egressing certain ports. In the example, port A sap 1/1/1:1.* would have a filter as shown below while port A sap 1/1/1:2.* would not.:

mac-filter 4 create

     default-action forward

            type vid

            entry 1 create

                match frame-type ethernet_II

                    outer-tag 30 4095

                exit

                action drop

            exit

        exit

4.1.2.12. IP Exception Filters

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 on IP exception filters supported by NGE nodes, see Router Encryption Exceptions using ACLs.

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

4.1.2.13. Redirect Policies

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:

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 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. To support such deployments, operators can enable the sticky destination functionality (config>filter>redirect-policy>sticky-dest). When enabled, the currently active destination remains active unless it goes down or an operator forces the switch using the tools>perform>filter>redirect-policy>activate-best-dest command. An optional sticky destination hold-time-up 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. Once 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). Note the following:

Note: The unicast-rt-test command fails when performed in the context of a VPRN routing instance when the destination is routable only through grt-leak functionality. ping-test is recommended in these cases.

Feature restrictions:

4.1.2.14. HTTP-Redirect (Captive Portal)

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 a subscriber-management 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:

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:

The recommended filter configuration to redirect HTTP traffic page is described below using ingress ip-filter policy "10":

Also, the router supports two redirect scale modes that are configurable at the system level. The optimized-mode improves the number of HTTP redirect sessions supported by system as compared to the no optimized-mode, as follows:

4.1.2.14.1. Traffic Flow

The following example provides a brief scenario of a subscriber connecting to a new network, where it is required to authenticate or accept the network terms of use, before getting access to Internet:

1. The subscriber typically receives an IP address upon connecting to the network using DHCP, and is assigned a filter policy to redirect HTTP traffic to a web portal.
2. The subscriber HTTP session TCP traffic is intercepted by the router. The CPM completes the TCP three-way handshake on behalf of the destination HTTP server, and responds to the HTTP request with an HTTP 302 “Moved Temporarily” response. This response contains the URL of the web portal configured in the filter policy.
3. Upon receiving this redirect message, the subscriber web browser closes the original TCP session, and opens a new TCP session to the redirection portal.
4. The subscriber can now authenticate or accept the terms of use. Once done, the subscriber filter policy is dynamically modified.
5. The subscriber can now connect to the original Internet site.

Figure 26:  Web Redirect Traffic Flow 

4.1.2.15. Filter Policy-based ESM Service Chaining

In some deployments, operators 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 desired. 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 desired.

Filter policy-based ESM service chaining removes ESM VAS steering to network infrastructure inter-dependency. An operator 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. Figure 27 shows a possible ACL model (embedded filters are used for VAS service chaining rules).

On the left in Figure 27, 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, an operator 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 Figure 27, 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, an operator 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.

Figure 27:  ACL filter modeling for ESM Service Chaining 

Figure 28 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 Figure 28) or can be injected to WAN to be routed toward the final destination (not shown).

Figure 28:  Upstream ESM ACL-policy based service chaining 

Figure 29 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 Figure 29) to ensure the traffic is not redirected to VAS again when the subscriber-facing line card processes that traffic.

Figure 29:  Downstream ESM ACL-policy based service chaining 

Ensuring the correct settings 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. The available configuration options (config>service>vprn>if>vas-if-type, config>service>ies>if>vas-if-type and config>router>if>vas-if-type) are described below:

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

ESM filter policy-based traffic steering supports the following:

Operational notes:

Restrictions:

4.1.2.16. Policy-Based Forwarding for Deep Packet Inspection in VPLS

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. Due to the 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).

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

Figure 30:  Policy-Based Forwarding for Deep Packet Inspection  

The following displays a VPLS service configuration with DPI example:

The following displays a MAC filter configuration example:

The following displays the MAC filter added to the VPLS service configuration:

4.1.2.17. Storing Filter Entries

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

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

4.1.2.17.1. FP4-based Cards

To optimize both scale and performance, policy entries configured by the operator are compressed by each FP4 line card prior to being installed in hardware.

This compression can result, in an unexpected scenario typically only achieved in a lab environment, in an overload condition for a specified FP CAM line card. This overload condition can occur when applying a filter policy for the first time on a line card FP or when adding entries to a filter policy.

For a line card ACL filter, the system raises a trap if a specified FP CAM utilization goes beyond 85% utilization.

Applying a Filter Policy

A policy is installed for the first time on a line card FP if no router interface, service interface, SAP, spoke SDP, mesh SDP, or ESM subscriber host was using the policy on this FP.

A policy installed for the first time on a line card FP can lead to a compression failure resulting in an overload condition for this policy on this FP CAM. In this case, none of the entries for the affected filter policy are programmed and traffic is forwarded as if no filter was installed.

Adding Filter Entries

Adding an additional entry to a filter policy can lead to a compression failure resulting in an overload condition.

In this case, the newly added entry is not programmed on the affected FP CAM. Additional entries added to the same policy after the first overload condition are also not programmed on the affected FP CAM as the system attempts to install all outstanding additions in order.

A trap is raised when an overload condition occurs. After the first overload event is detected for a specified ACL FP CAM, the CPM interactively rejects the addition of filter policies or filter entries applied to the same FP CAM, thus providing an interactive error message to the operator or the dynamic provisioning interfaces such as RADIUS.

Note: The filter resource management task on the CPM controls the maximum number of filter entries per FP. If the operator attempts to go over the scaling limit, the system returns an interactive error message. This mechanism is independent from the overload state of the FP CAM.

Removing Filter Entries

Removing filter entries from a filter policy is always accepted and is used to resolve the overload events.

Resolving Overload

The overload condition should be resolved by the network operator before adding new entries or policies in the affected FP CAM.

To identify the affected policy, the system logs the overload event providing slot number, FP number, and impacted CAM. Based on this information, the tools>dump>filter>overload command allows the operator to identify the affected policy and policy entries in the system that cannot be programmed on a given FP CAM.

To resolve the overload condition, the network operator can remove the newly added entries from the affected policy or assign a different policy.