4.2.1.1. Filter Policy Packet Match Criteria

This section defines packet match criteria supported on SR OS for IPv4, IPv6 and MAC filters. Types of criteria supported depends on the hardware platform and filter direction, please see your Nokia representative for further details.

General notes:

4.2.1.2. IPv4/IPv6 Filter Policy Entry Match Criteria

The IPv4 and IPv6 match criteria supported by the SR OS are listed below. The criteria are evaluated against outer IPv4/IPv6 header and a L4 header that follows (if applicable). Support for a given match criteria may depend on H/W and/or filter direction as per below description. It is recommended not to configure a filter in a direction or on a H/W where a given match condition is not supported as this may lead to undesired 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 details.

Basic Layer 3 match criteria:

Conditional action match criteria:

Fragmentation match criteria:

IPv4 options match criteria:

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

Upper-layer protocol match:

Operational Note – For fragmented traffic, when non-initial fragments do not contain the L4 header, the L4 match criteria in the filter policy look-up key are set to zero (0). If a filter policy contains an entry that specifies L4 zero match criterion (for example, TCP/UDP/SCTP port/src-port/dst-port eq 0), the non-initial fragment will match the entry if other match criteria are also met. IPv6 L4 match criteria are supported with up to 6 extension headers present in the packet.

4.2.1.3. MAC Filter Policy Entry Match Criteria

The following list describes the MAC match criteria supported by the 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 given 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. It is recommended not to configure a filter in a direction or on a H/W where a given match condition is not supported as this may lead to undesired behavior.

4.2.1.4. Filter Policy Actions

The following lists actions supported by ACL filter policies

In addition to the above actions:

4.2.1.5. 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, summed up and made available to an operator.

Starting with SR OS Release 11.0 R4, 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 (zero). 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 (zero). 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 CPM cache for policy interfaces 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 (zero). 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, thus initial statistics requests after an HA switchover may require reads from hardware.

Operational notes:

4.2.1.6. Filter Policy Logging

SR OS supports logging of the information from the packets that match a given 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.2.1.7. 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 or not (including evaluation of conditional action match criteria, for example, packet-length or ttl).

4.2.1.8. Filter Policy Management

4.2.2.1. Match-list for Filter Policies

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

Figure 17:  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/linecard, or CPM filter policy, an operator again needs to create one entry for each address prefix of 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/and needs to be reused multiple times across one or more filter policies.

Match list for CPM and IOM/FP filter policies are introduced to eliminate above operational complexity by simplifying the IOM/FP and CPM filter policy management on a list of a match criterion. Instead of defining multiple filter entries in any given filter, an operator can now group same type of the matching criteria into a single filter match list, and then use that list as a match criterion value, thus requiring only single filter policy entry per each unique action. The same match list can be used in one or more IOM/linecard 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, thus 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 18 depicts how the IOM/CPM filter policy illustrated at the top of this section changes with a filter match list usage (using IPv4 address prefix list in this example).

Figure 18:  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 desired 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 given 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 a match list(s), the operation will fail, the entry will be not programmed, and a notification of that failure will be provided to an operator.

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

4.2.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. Prior to 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 by) 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 19 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 19:  Embedded Filter Policy 

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

4.2.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 given 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, thus 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 undesired 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 given system policy.

System filter policy requires chassis mode D.

An example (IPv4) configuration is shown below:

4.2.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. The 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 (thus 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 45), 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 given 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 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 display of the command as applicable for PBF redundancy.

4.2.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. The SR OS allows this behavior by configuring an extended action for a given 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, thus 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.2.2.6. 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 20 illustrates a sample deployment.

Figure 20:  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:

Caveats:

4.2.2.7. 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 given 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.

Caveats:

4.2.2.8. 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 a 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 endpoint(s), BVPLS SAP or PW, as the mrp-policy to restrict the egress transmission any type of frames that contain 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.2.2.9. 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 grain control of frame operations based on the VID tag. Service delimiting tags are exact match and are stripped from the frame as illustrated in Figure 21. 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 or 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 an 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. Since 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 21 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 illustrates single non-service delimiting tags on ingress and to 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 QoS and VID Filters (moved to QoS guide) on page 313.

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

Figure 21:  VID Filtering Examples 

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

4.2.2.9.2. Port Group Configuration Example

Figure 22:  Port Groups 

Figure 22 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.2.2.10. Redirect Policies

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

Redirect policy supports 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 desirable 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 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:

Operational note: unicast-rt-test 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 caveats:

4.2.2.11. 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.2.2.12. 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 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 TPSDA 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 proper 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 on VSD filter provisioning, automation, and Python scripting details can be found in the Layer 2 Services and EVPN Guide.

For OpenFlow, embedded filter infrastructure is used to inject OpenFlow rules into an existing filter policy. Please see “Hybrid OpenFlow Switch” section for more details.

Policy-controlled auto-created filters are recreated on system reboot. Policy-controlled filter-entries are lost on system reboot and need to be reprogrammed.

4.2.2.13. 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 particular residential tier-of-service, which also defines the VAS available to subscribers of the given 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 particular tier-of-service is to preallocate IP/IPv6 address pools to a given 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 24 shows a possible ACL model (embedded filters are used for VAS service chaining rules).

On the left in Figure 24, 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 given tier. Each VAS filter is then embedded by the ACL filter used by a given 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 24, 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 24:  ACL filter modeling for ESM Service Chaining 

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

Figure 25:  Upstream ESM ACL-policy based service chaining 

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

Figure 26:  Downstream ESM ACL-policy based service chaining 

Ensuring the proper 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>interface>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:

Caveats:

4.2.2.14. 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 27 shows an example to configure policy-based forwarding for deep packet inspection on a VPLS service. For information about configuring services, refer to the Layer 2 Services and EVPN Guide: VLL, VPLS, PBB, and EVPN.

Figure 27:  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: