The SROS supports filter policies for services and network interfaces (described in this chapter), subscriber management (integrated with service filter policies with the subscriber management specifics defined in the SROS Triple Play Guide), and CPM security and Management Interface (described in SROS Router Configuration Guide).
There are three main types of filter policies: IPv4, IPv6, and MAC filter policies. Additionally MAC filter policies support three sub-types: (
configure filter mac-filter type {
normal |
isid |
vid}). These sub-types allow operators to configure different L2 match criteria for a L2 MAC filter.
•
|
An exclusive filter allows defining policy rules explicitly for a single interface. An exclusive filter allows highest-level of customization but uses most resources, since each exclusive filter consumes H/W resources on line cards the interface exists.
|
•
|
A template filter allows usage of identical set of policy rules across multiple interfaces. Template filters use a single set of resources per line card, regardless of how many interfaces use a given template filter policy on that line card. Template filter policies used on access interfaces, consume resources on line cards only if at least one access interface for a given template filter policy is configured on a given line card.
|
•
|
An embedded filter allows defining common set of policy rules that can then be used (embedded) by other exclusive or template filters in the system. This allows optimized management of filter policies.
|
•
|
A system filter policy allows defining common set of policy rules that can then be activated within other exclusive/template filters. A system filter policy is intended mainly for system-level blacklisting rules but can be used for other applications as well. This allows optimized management of common rules (similarly to embedded filters); however, active system filter policy entries are not duplicated inside each policy that actives the system policy (as is the case when embedding is used). The active system policy is downloaded once to line cards, and activating filter policies are chained to it.
|
For Layer 2, either an IPv4/IPv6, and MAC filter policy can be applied. For Layer 3 and network interfaces, an IPv4/IPv6 policy can be applied. For r-VPLS service, a L2 filter policy can be applied to L2 forwarded traffic and L3 filter policy can be applied to L3 routed traffic. For dual stack interfaces, if both IPv4 and IPv6 filter policies are configured, the policy applied will be based on the outer IP header of the packet. Note that non-IP packets are not hitting an IP filter policy, so the default action in the IP filter policy will not apply to these packets.
The command action (with all types and related parameters defining) used to define an action to be performed on a packet matching IPv4/IPv6/MAC ACL policy entry has been deprecated and replaced by a new
action command that allow operator to enter a new CLI context under which individual actions can be selected using
drop,
forward,
gtp-local-breakout,
http-redirect,
nat, reassemble action type commands and their parameters as applicable to a given action type and a given filter type.
would result in “action drop” configuration (implicit
action drop configuration). After an upgrade to release 13.0 R4, this functionality is no longer supported and
action drop must be explicitly specified. An operator must add drop keyword to any existing manually edited CLI configuration files that do not explicitly specify
action drop. Note that the system would always save a configuration with implicit action drop defined as explicit
action drop.
This section defines packet match criteria supported on SROS-based routers/switches for IPv4, IPv6 and MAC filters. Types of criteria supported depends on the hardware platform and filter direction, please see your Alcatel-Lucent representative for further details.
IPv4/IPv6 Filter Policy Entry Match Criteria
The below lists IPv4 and IPv6 match criteria supported by SROS routers/switches. 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 Advanced Filter Policy topics for more details.
•
|
dscp — Match for the specified DSCP value against the Differentiated Services Code Point/Traffic Class field in the IPv4/v6 packet header.
|
•
|
src-ip/dst-ip — Match for the specified source/destination IPv4/IPv6 address-prefix against the source/destination IPv4/IPv6 address field in the IPv4/IPv6 packet header. Operator can optionally configure a mask to be used in a match.
|
•
|
flow-label — Match for the specified flow label against the Flow label field in IPv6 packet . Operator can optionally configure a mask to be used in a match. Supported for ingress filters only. Requires minimum chassis mode C.
|
•
|
packet-length — Match for the specified packet-length value/range against the Total Length field in IPv4 packet header or Payload Length field in IPv6 packet header. This match condition is supported for drop action only and is part of action evaluation – i.e. after packet is determined to match the entry based on other match criteria configured. Packets that match all match criteria for a given filter policy entry are dropped if the packet-length match criterion is met and forwarded if the packet match criterion is not met. When a filter entry with a packet-length condition is used as a mirror source, only forwarded packets are mirrored. Supported for ingress filters only. Requires minimum FP-2 based line cards. The packet-length match condition is always true if a filter is configured on egress or on an older H/W.
|
•
|
TTL — Match for the specified TTL value/range against the Total Length field in IPv4 packet header . This match condition is supported for drop action only and is part of action evaluation – i.e. after packet is determined to match the entry based on other match criteria configured. Packets that match all match criteria for a given filter policy entry are dropped if the TTL match criterion is met and forwarded if the TTLmatch criterion is not met. When a filter entry with a TTL condition is used as a mirror source, only forwarded packets are mirrored. When a filter entry with a TTL condition is used in cflowd processing, the TTL condition is ignored for cflowd processing. Supported for ingress filters only and requires minimum FP-2 based line cards. The TTL match condition is always true if a filter is configured on egress or on an older H/W.
|
•
|
fragment — Enable fragmentation support in filter policy match. For IPv4, match against MF bit or Fragment Offset field to determine whether the packet is a fragment or not. For IPv6, match against Next Header Field for Fragment Extension Header value to determine whether the packet is a fragment or not. Up to 6 extension headers are matched against to find Fragmentation Extension Header.
|
•
|
ip-option — Match for the specified option value in the first option of the IPv4 packet. Operator can optionally configure a mask to be used in a match.
|
•
|
option-present — Match for the presence or absence of the IP options in the IPv4 packet. Padding and EOOL are also considered as IP options. Up to 6 IP options are matched against.
|
•
|
multiple-options — Match for the presence of multiple IP options in the IPv4 packet.
|
•
|
src-route-option — Match for the presence of IP Option 3 or 9 (Loose or Strict Source Route) in the first 3 IP Options of the IPv4 packet. A packet will also match this rule if the packet has more than 3 IP Options.
|
IPv6 next-header match criteria (see also Upper-layer protocol match next-header description below):
•
|
ah-ext-header — Match for presence/absence of the Authentication Header extension header in the IPv6 packet. This match criterion is supported on ingress only and requires minimum FP-2 based line cards. Up to 6 extension headers are matched against.
|
•
|
esp-ext-header — Match for presence/absence of the Encapsulating Security Payload extension header in the IPv6 packet. This match criterion is supported on ingress only and requires minimum FP-2 based line cards. Up to 6 extension headers are matched against.
|
•
|
hop-by-hop-opt — Match for the presence/absence of Hop-by-hop options extension header in the IPv6 packet. This match criterion is supported on ingress only and requires minimum FP-2 based line cards. Up to 6 extension headers are matched against.
|
•
|
routing-type0 — Match for the presence/absence of Routing extension header type 0 in the IPv6 packet. This match criterion is supported on ingress only and requires minimum FP-2 based line cards. Up to 6 extension headers are matched against.
|
•
|
next-header — Match for the specified upper layer protocol (for example, TCP, UDP, IGMPv6) against the Next Header field of the IPv6 packet header. “*” can be used to specify TCP or UDP upper-layer protocol match (Logical OR). Note: next-header matching allows also matching on presence of a subset of IPv6 extension headers. See CLI section for details on which extension header match is supported.
|
•
|
protocol — Match for the specified protocol against the Protocol field in the IPv4 packet header (for example, TCP, UDP, IGMP) of the outer IPv4. “*” can be used to specify TCP or UDP upper-layer protocol match (Logical OR).
|
•
|
icmp-code — Match for the specified value against the Code field of the ICMP/ICMPv6 header of the packet. This match is supported only for entries that also define protocol/next-header match for “ICMP”/”ICMPv6” protocol.
|
•
|
icmp-type — Match for the specified value against the Type field of the ICMP/ICMPv6 header of the packet. This match is supported only for entries that also define protocol/next-header match for “ICMP”/”ICMPv6” protocol.
|
•
|
src-port/dst-port/port – Match for the specified port value or port range against the Source Port Number/Destination Port Number of the UDP/TCP/SCTP packet header. An option to match either source or destination (Logical OR) using a single filter policy entry is supported by using a directionless “port” command. Source/destination match is supported only for entries that also define protocol/next-header match for “TCP”, “UDP”, “SCTP”, or “TCP or UDP” protocols. Note that a non-initial fragment will never match an entry with non-zero port criteria specified.
|
•
|
tcp-ack/tcp-syn — Match for the TCP ACK/TCP SYNC flag presence/absence in the TCP header of the packet. This match is supported only for entries that also define protocol/next-header match for “TCP” protocol.
|
•
|
frame-type — Entering the frame type allows the filter to match for a specific type of frame format. For example, configuring frame-type ethernet_II will match only Ethernet-II frames.
|
•
|
src-mac— Entering the source MAC address allows the filter to search for matching a source MAC address frames. Operator can optionally configure a mask to be used in a match.
|
•
|
dst-mac— Entering the destination MAC address allows the filter to search for matching destination MAC address frames. Operator can optionally configure a mask to be used in a match.
|
•
|
dot1p — Entering an IEEE 802.1p value allows the filter to search for matching 802.1p frames. Operator can optionally configure a mask to be used in a match.
|
•
|
etype— Entering an Ethertype value allows the filter to search for matching Ethernet II frames. The Ethernet type field is a two-byte field used to identify the protocol carried by the Ethernet frame.
|
•
|
ssap— Entering an Ethernet 802.2 LLC SSAP value allows the filter to search for matching frames with a source access point on the network node designated in the source field of the packet. Operator can optionally configure a mask to be used in a match.
|
•
|
dsap— Entering an Ethernet 802.2 LLC DSAP value allows the filter to search for matching frames with a destination access point on the network node designated in the destination field of the packet.. Operator can optionally configure a mask to be used in a match.
|
•
|
snap-oui— Entering an Ethernet IEEE 802.3 LLC SNAP OUI allows the filter to search for matching frames with the specified the three-byte OUI field.
|
•
|
snap-pid— Entering an Ethernet IEEE 802.3 LLC SNAP PID allows the filter to search for the matching frames with the specified two-byte protocol ID that follows the three-byte OUI field.
|
•
|
isid — Entering an Ethernet IEEE 802.1ag ISID from the I-TAG value allows the filter to search for the matching Ethernet frames with the 24 bits ISID value from the PBB I-TAG. This match criterion is mutually exclusive with all the other match criteria under a particular mac-filter policy and is applicable to MAC filters of type isid only. The resulting mac-filter can only be applied on a BVPLS SAP or PW in the egress direction.
|
•
|
inner-tag/outer-tag — Entering inner-tag/outer-tag VLAN ID values allows the filter to search for the matching Ethernet frames with the non-service delimiting tags as described In “VID MAC filters” subsection later-on this. This match criterion is mutually exclusive with all other match criteria under a particular mac-filter policy and is applicable to MAC filters of type vid only.
|
•
|
drop — This action allows operator to deny traffic to ingress/egress the system
|
•
|
forward — This action allows operator to permit traffic to ingress/egress the system and be subject to regular processing
|
•
|
forward “Policy-based Routing/Forwarding (PBR/PBF) action”— PBR/PBF actions allows operator to permit ingress traffic but change the regular routing/forwarding packet would be a subject to. The PBR/PBF is applicable to unicast traffic only. The following PBR/PBF actions are supported (See CLI section for command details):
|
→
|
egress-pbr — enabling egress-pbr activates a PBR action on egress, while disabling egress-pbr activates a PBR action on ingress (default). The following subset of the below-defined PBR actions can be activated on egress: redirect-policy, next-hop-router, and esi. Egress PBR is supported in IPv4 and IPv6 filter policies for ESM only. Unicast traffic that is subject to slow-path processing on ingress (for example IPv4 packets with options or IPv6 packets with hop-by-hop extension header) will not match egress pbr entries. Filter logging, cflowd, and mirror source are mutually exclusive to configuring a filter entry with an egress PBR action. Configuring pbr-down-action-override, if supported with a given PBR ingress action type, is also supported when the action is an egress PBR action. Processing defined by pbr-down-action-override does not apply if the action is deployed in the wrong direction. If a packet matches a filter PBR entry and the entry is not activated for the direction in which the filter is deployed, action forward is executed. Egress PBR cannot be enabled in system filters. Egress PBR functionality requires chassis mode D.
|
→
|
esi — forwards the incoming traffic using VXLAN tunnel resolved using EVPN MP BGP control plane to the first service chain function identified by ESI (L2) or ESI/SF-IP (L3). Supported with VPLS (L2) and IES/VPRN (L3) services. If the service function forwarding cannot be resolved, traffic matches an entry and action forward is executed. For VPLS, no cross service PBF is supported – i.e. the filter specifying ESI PBF entry must be deployed in the VPLS service where BGP EVPN control plane resolution takes place as configured for a given ESI PBF action. The functionality is supported in filter policies deployed on ingress VPLS interfaces. BUM traffic that matches a filter entry with ESI PBF will be unicast forwarded to the VTEP:VNI resolved through PBF forwarding. For IES/VPRN, the outgoing R-VPLS interface can be in any VPRN service. The outgoing interface and VPRN service for BGP EVPN control plane resolution must again be configured as part of ESI PBR entry configuration. The functionality is supported in filter policies deployed on ingress IES/VPRN interfaces and in filter policies deployed on ingress and egress for ESM subscribers. Only uncast traffic is subject to ESI PBR, any other traffic matching a filter entry with L3 ESI action will be subject to action forward. The functionality requires chassis mode D. When deployed in unsupported direction, traffic matching a filter policy ESI PBR/PBF entry will be subject to action forward.
|
→
|
interface — forwards the incoming traffic onto the specified IPv4 interface. Supported for ingress IPv4 filter policies in global routing table instance. If the configured interface is down or not of the supported type, traffic is dropped.
|
→
|
lsp — forwards the incoming traffic onto the specified LSP. Supports RSVP-TE LSPs (type static or dynamic only) or MPLS-TP LSPs. Supported for ingress IPv4/IPv6 filter policies only deployed on IES SAPs or network interfaces. If the configured LSP is down, traffic matches the entry and action forward is executed.
|
→
|
next-hop — changes the IP destination address used in routing from the address in the packet to the address configure in this PBR action. The operator can configure whether the next-hop IP address must be direct (local subnet only) or indirect (any IP). Supported for ingress IPv4/IPv6 filter policies only, deployed on L3 interfaces. If configured next-hop is not reachable, traffic is dropped and “ICMP destination unreachable” message is sent. For IPv6, requires minimum Chassis mode C.
|
→
|
redirect-policy — implements PBR next-hop or PBR next-hop router action with ability to select and prioritize multiple redirect targets and monitor the specified redirect targets so PBR action can be changed if the selected destination goes down. Supported for ingress IPv4 and IPv6 filter policies deployed on L3 interfaces only. See Redirect Policies in this chapter for more details.
|
→
|
router — changes the routing instance a packet is routed in from the upcoming interface’s instance to the routing instance specified in the PBR action (supports both GRT and VPRN redirect). This action requires incoming interfaces to be on FP2 line cards or newer. It is supported for ingress IPv4/IPv6 filter policies deployed on L3 interfaces. The action can be combined with the next-hop action specifying direct/indirect IP/IPv6 next hop. Packets are dropped if they cannot be routed in the configured routing instance.
|
→
|
sap — forwards the incoming traffic onto the specified VPLS SAP. Supported for ingress IPv4/IPv6 and MAC filter policies deployed in VPLS service. The SAP traffic is to egress on must be in the same VPLS service as the incoming interface. If the configured SAP is down, traffic is dropped.
|
→
|
sdp — forwards the incoming traffic onto the specified VPLS SDP. Supported for ingress IPv4/IPv6 and MAC filter policies deployed in VPLS service. The SDP traffic is to egress on must be in the same VPLS service as the incoming interface. If the configured SDP is down, traffic is dropped.
|
•
|
forward “isa action” — ISA processing actions allow operator to permit ingress traffic and send it for ISA processing as per specified isa action. The following isa actions are supported (see CLI section for command details):
|
→
|
gtp-local-breakout — forwards matching traffic to NAT instead of being GTP tunneled to the mobile operator’s PGW or GGSN. The action applies to GTP-subscriber-hosts. If filter is deployed on other entities, action forward is applied. Supported for IPv4 ingress filter policies only. If ISAs performing NAT are down, traffic is dropped.
|
→
|
nat — forwards matching traffic for NAT. Supported for IPv4/IPv6 filter policies for L3 services in GRT or VPRN. If ISAs performing NAT are down, traffic is dropped. (see CLI for options)
|
→
|
reassemble — forwards matching packets to the reassembly function. Supported for IPv4 ingress filter policies only. If ISAs performing reassemble are down, traffic is dropped.
|
•
|
http-redirect — implements HTTP redirect captive portal. HTTP GET is forwarded to CPM card for captive portal processing by router. See HTTP-redirect (Captive Portal) section for further details.
|
•
|
An operator can select a default-action for a filter policy. The default action is executed on packets subjected to an active filter when none of the filter’s active entries matches the packet. By default, filter policies have default action set to drop but operator can select a default action to be forward instead.
|
SROS supports logging of the information from the packets that match given filter policy. Logging is configurable per filter policy entry by specifying pre-configured filter log (config filter log). A filter log can be applied to ACL filters and CPM hardware filters. Operator 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.
Filter copy allows operators to perform bulk operations on filter policies by copying one filter’s entries to another filter. Either all entries or a specified entry of the source filter can be selected for copy. When entries are copied, entry order is preserved unless destination filter’s entry ID is selected (applicable to single entry copy). The filter copy allows overwrite of the existing entries in the destination filter by specifying “overwrite” option during the copy command. Filter copy can be used, for example, when creating new policies from existing policies or when modifying an existing filter policy (an existing source policy is copied to a new destination policy, the new destination policy is modified, then the new destinations policy is copied back the source policy with overwrite specified).
Figure 15 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.
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 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 filter policies are introduced to eliminate above operational complexity by simplifying the IOM 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 filter policies as well as CPM filter policies.
Figure 16 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).
Note: 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.
It is often desired to automatically update a filter policy when the configuration on a router changes. To allow such a touch-less filter policy management, SROS allows auto-generation of address prefixes for IPv4 or IPv6 address prefix match lists based on operator-configured criteria. When the configuration on a router changes, the match lists address prefixes are automatically updated and, in-turn, all filter policies (CPM or IOM) that use these match lists are automatically updated.
Figure 17 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):
*A:vm1>config>filter#
# Configure system-policy
ip-filter 1 create
scope system
entry 5 create
match protocol *
fragment true
exit
action drop
exit
exit
# Activate it
system-filter
ip 1
exit
# Use it in another filter:
ip-filter 10 create
chain-to-system-filter
filter-name "test-name"
embed-filter open-flow "test" offset 100
exit
exit
Network-port L3 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 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 18 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.
Note that configure>system>ethernet>new-qinq-untagged-sap is a special QinQ function for single tagged QinQ frames with a null second tag. Using this in combination with VID filters is not recommended. Note that the outer-tag is the only tag available for filtering on egress for frames arriving from MPLS SDPs or from PBB services even though additional tags may be carried transparently.
Figure 19 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
SROS-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 IP filter policies. IPv6 redirect policy can only be deployed in IPv6 filter policies.
•
|
ping test – with configurable interval, drop-count, and time-out for the test
|
•
|
url-test – with configurable URL to test, interval, drop-count, timeout, and configurable action (disable destination, lower or raise priority) based upon return error code
|
•
|
snmp-test – with configurable OID and Community strings, interval, drop-count, timeout for the test, and configurable action (disable destination, lower or raise priority) based upon SNMP return value.
|
•
|
unicast-rt-test – unicast routing reachability, supported only when router instance is configured for a given redirect policy. The test yields true if the route to the specified destination exists in RTM for the configured router instance.
|
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.
On the left in Figure 21, 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 21, 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.
![](images/filters.14.1.7.jpg)
Figure 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 ) or can be injected to WAN to be routed towards the final destination (not shown).
Upstream ESM ACL-policy based service chainingFigure 22 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 22) to ensure the traffic is not redirected to VAS again when the subscriber-facing line card processes that traffic.
•
|
action forward redirect-policy or action forward next-hop router for IP-steering with TCAM-based load-balancing, fail-to-wire, and sticky destination
|
•
|
action forward esi sf-ip vas-interface router for integrated service chaining solution
|