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.

Basic Layer 3 match criteria:

Fragmentation match criteria:

IPv4 options match criteria:

IPv6 next-header match criteria: (see the Upper-layer protocol match next-header description below):

Upper-layer protocol match criteria:

Operational note for fragmented traffic — IP and IPv6 filters defined to match TCP, UDP, ICMP, or SCTP criteria (such as src-port, dst-port, port, tcp-ack, tcp-syn, icmp-type, and icmp-code) with values of zero or false will also match non-first fragment packets if other match criteria within the same filer entry are also met. Non-initial fragment packets do not contain a UDP, TCP, ICMP or SCTP header.

4.1.1.3. MAC Filter Policy Entry 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 sub-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. For information on IP exception filters, refer to the “Router Encryption Exceptions using ACLs” section in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN.

4.1.1.5. Filter Policy Actions

The 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 will be 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 will perform 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 will be 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” will reflect the behavior a packet will be subject to. However, in transient cases (for example, in the case of a failure) it may not be able to capture what will effectively happen to the packet.

The output also displays relevant information such as the default action when the target is down (see Table 46) 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 will effectively happen to the packet throughout the system. To that end, 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 will, 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.

Starting with SR OS Release 11.0R4, filter policies applied on access interfaces are downloaded only when active and 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 statistics for the filter are reset to 0. Downloading a filter policy to a new line card keeps incrementing existing statistics.

Starting with SR OS Release 13.0R4, filter policies support bulk requests of CPM cache for policy interface-created entries. The cache is periodically refreshed through a background collection of counters from hardware. The counters are also refreshed when the ACL entry corresponding to the cache entry has statistics read from hardware through any direct-read from hardware mechanism. If a cache entry represents an entry for an ACL filter policy not downloaded to any line cards, the cache returns values of 0. If a cache entry represents an ACL filter entry that was removed from a line card since the previous refresh, the current refresh will reload the cache with the most recent values from hardware. The cache has to be rebuilt on a High Availability (HA) switchover, accordingly initial statistics requests after an HA switchover may require reads from hardware.

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

Figure 26 shows an approach to implement logical OR on a list of matching criteria (IPv4 address prefixes in this example) in one or more filter policies prior to introduction of match list.

Figure 26:  IOM/CPM Filter Policy Using Individual Address Prefixes 

An operator has to create one entry for each address prefix to execute a common action. Each entry defines a match on a unique address prefix from the list plus any other additional match criteria and the common action. If the same set of address prefixes needs to be used in another IOM/line card, or CPM filter policy, an operator again needs to create one entry for each address prefix from the list in those filter policies. Same procedure applies (not shown above) if another action needs to be performed on the list of the addresses within the same filter policy (when, for example, specifying different additional match criteria). This process can introduce large operational overhead, especially when a list contains many elements or needs to be reused multiple times across one or more filter policies.

Match lists for CPM and IOM/FP filter policies eliminate the preceding operational complexity by simplifying the IOM/FP and CPM filter policy management on a list of match criteria. Instead of defining multiple filter entries in any specific filter, an operator can now group the same types of matching criteria into a single filter match list and use that list as a match criterion value, thus requiring only a single filter policy entry per each unique action. The same match list can be used in one or more IOM/line card filter policies as well as CPM filter policies.

The match lists further simplify management and deployment of the policy changes. A change in a match-list content is automatically propagated across all policies employing that list in their match criteria, therefore, only a single configuration change is required to trigger policy changes when a list is used by multiple entries in one or more filter policies.

Figure 27 depicts how the IOM/CPM filter policy changes with a filter match list usage (using IPv4 address prefix list in this example).

Figure 27:  IOM/CPM Filter Policy Using an Address Prefix Match List 

The hardware resource usage does not change whether filter match lists are used or whether operator creates multiple entries (each per one element of the list): however, a careful consideration must be given to how the lists are used to ensure only needed match permutations are created in a filter policy entry (especially when other matching criteria that are also lists or ranges are specified in the same entry). The system verifies that a new list element, for example, an IP address prefix, cannot be added to a specific list or a list cannot be used by a new filter policy unless resources exist in hardware to implement the required filter policy (ies) that reference that list. If that is not the case, addition of a new element to the list or use of the list by another policy will fail.

Some use cases, like those driven by dynamic policy changes, may result in acceptance of filter policy configuration changes that cannot be programmed in hardware because of the resource exhaustion. If that is the case, when attempting to program a filter entry that uses match lists, the operation will fail, the entry will not be programmed, and a notification of that failure will be provided to an operator.

Refer to the Software Release Notes for information about objects that can be grouped into a filter match list for FP and CPM filter policies.

4.1.2.2. Embedded Filters

When a large number of standard filter policies are configured in a system, a set of policies will often contain one or more common blocks of entries that define, for example, system-wide and/or service-wide security rules. Before introduction of the embedded filters, such common rules would have to be configured separately in each exclusive/template policy.

To simplify management of such common rules across multiple filter policies, the operator can use embedded filter policies. An embedded filter policy is a special type of a filter policy that cannot be deployed directly but instead is used to define a common filter policy rules that are then included in (embedded into) other filter policies in the system. Thanks to embedding, a common set of rules can now be defined and changed in a single place but deployed across multiple filter policies. The following main rules apply when embedding an embedded filter policy:

Figure 28 shows implementation of embedded filter policy using IPv4 ACL filter policy example with an embedded filter 10 being used to define common filter rules that are then embedded into filter 1 and 20 (with filter 20 overwriting rule at offset 50).

Figure 28:  Embedded Filter Policy 

Note: Embedded filter policies are supported for line card IP(v4) and IPv6 filter policies only.

4.1.2.3. System-level IPv4/IPv6 Line Card Filter Policy

A system filter policy allows the definition of a common set of policy rules that can then be activated within other exclusive/template filters. IPv4/IPv6 system filter policies supports all IPv4/IPv6 filter policy match rules and actions respectively but system policy entries cannot be the sources of mirroring.

System filter policy cannot be used directly; the active system policy is deployed by activating it within any IPv4 or IPv6 exclusive/template filter policy (chaining the system policy and a specific interface policy). When an IPv4/IPv6 filter policy is chained to the active IPv4/IPv6 system filter, system filter rules are evaluated first before any rules of the chaining filter are evaluated (i.e. chaining filter's rules are only matched against if no system filter match took place).

A system filter policy is intended mainly for system-level blacklisting rules, therefore it is recommended to use system policies with drop/forward actions. 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 policies can be populated using CLI/SNMP/Netconf management interfaces and Openflow policy interface. System filter policy entries cannot be populated using flowspec, RADIUS, or Gx.

System filter policy scale is identical to a corresponding IPv4 or IPv6 filter policy scale. System filter policy consumes single set of H/W resources on each line card as soon as it is activated, regardless of how many IPv4/IPv6 filters chain to that system policy. This optimizes resource allocation when multiple filter policies activate a specific system policy.

An example (IPv4) configuration is shown below:

4.1.2.4. 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 46), 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.5. 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, amongst others, for PBR/PBF redundancy, the extended action listed above will not be performed when the PBR target is down. Moreover, a filter policy containing an entry with the extended action remark dscp will be blocked in the following cases: if applied on ingress with the egress-pbr flag set, if applied on egress without the egress-pbr flag set. The latter case includes actions that are not supported on egress (and for which egress-pbr cannot be set).

4.1.2.6. 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 will be 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 will assume that label per VRF is used by the target node and will select 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 will instruct the steering node to use that specific service label.

Be aware that the system will perform 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 will automatically select 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 will 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. As such, the system will perform 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 will revert 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.7. 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 29 shows a sample deployment.

Figure 29:  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.8. 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.9. 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 BMAC is not flooded between domains. However, there could be small transitory periods when traffic originated from PBB BEB with unicast BMAC 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 will be applied as required on a per B-SAP or B-PW basis, just 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.10. 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 30. 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 30 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 30:  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.10.2. Port Group Configuration Example

Figure 31:  Port Groups 

Figure 31 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.11. IP Exception Filters

IP exception filters scan all outbound traffic entering a Network Group Encryption (NGE) domain and allow packets that match the exception filter criteria to transit the NGE domain unencrypted.

The VSR supports IPv4 exception filters. For information on IP exception filters, refer to the “Router Encryption Exceptions using ACLs” section in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN.

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

4.1.2.12. 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 will not be programmed and instead the timer is started. Once the timer expires, the most-preferred destination at that time will be programmed (which may be a different destination from the one that started the timer). Note the following:

Note: The unicast-rt-test command will fail 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 such cases.

Feature restrictions:

4.1.2.13. HTTP-redirect (Captive Portal)

Web redirection policies can be configured on SR OSs/switches. The http redirection action can block a customer’s request from an intended recipient and force the customer to connect to the service’s portal server. 255 unique entries with http-redirect are allowed.

4.1.2.14. Filter Policies and Dynamic Policy-Driven Interfaces

In addition to configuration interfaces like CLI/SNMP, filter policies can be created and modified by dynamic policy-driven interfaces, such as BGP flowspec, OpenFlow, RADIUS, or XMPP-Python.

For BGP flowspec, routes are learned by a routing instance, and the system auto-creates an embedded filter to contain the rules derived from these routes. The maximum number of rules in the embedded filter of each routing instance can be controlled through configuration. The embedded filter containing the flowspec rules of a routing instance can be inserted into any configured exclusive or template-scope IPv4/IPv6 filter, and the embedding is activated if:

The insertion point of the flowspec rules in each embedding filter policy is controlled through offset configuration. For more information, see the BGP flowspec section of the 7450 ESS, 7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide.

For RADIUS, operator can assign filter policies to a subscriber, and populate filter policies used by the subscriber within a preconfigured block reserved for RADIUS filter entries. See the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide and filter RADIUS-related commands for more details.

VSD filters are created dynamically via XMPP and managed via 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. More information about VSD filter provisioning, automation, and Python scripting details are in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide: VLL, VPLS, PBB, and EVPN.

For OpenFlow, embedded filter infrastructure is used to inject 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 reprogrammed.

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 33 shows a possible ACL model (embedded filters are used for VAS service chaining rules).

On the left in Figure 33, 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 33, 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 33:  ACL filter modeling for ESM Service Chaining 

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

Figure 34:  Upstream ESM ACL-policy based service chaining 

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

Figure 35:  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 will be 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 will then be 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 36 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 36:  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: