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).
ACL Filter policies, also referred to as Access Control Lists (ACLs) or filter for short, are sets of ordered rules specifying packet match criteria and actions to be performed upon a match. Filters are applied to services or network ports to control network traffic into (ingress) or out of (egress) a service access port (SAP) or network. There are three main types of filter policies: IPv4, IPv6, and MAC filter policies. The same filter can be applied to ingress traffic, egress traffic, or both. Ingress filters affect only inbound traffic destined for the routing complex, and egress filters affect only outbound traffic sent from the routing complex.
On a Layer 2 SAP, either a single IP (v4 or v6) or a single MAC filter policy can be applied in a given direction. On a Layer 3 SAP and network interfaces, a single IP (v4 or v6) can be applied in a given direction. The ingress and egress direction policies can be same or different. For dual stack IPv4/IPv6 SAPs/interfaces, if both IPv4 and IPv6 filter policies are defined, 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.
Figure 16 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 17 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.
Figure 18 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):
Web redirection policies can be configured on 7750 SR devices. Redirection policies were designed for testing purposes. The new redirection policy can now 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.
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 20 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 21 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.:
Figure 22 displays the process to create a redirect policy and to apply that policy to a service SAP or router interface.
Figure 23 displays the process to create a filter policy and apply that policy to a service or network port.
During the SAP creation process, ingress and egress filters are selected from a list of qualifying IP and MAC filters. When ingress filters are applied to a SAP, packets received at the SAP are checked against the matching criteria in the filter entries. If the packet completely matches all criteria in an entry, the checking stops and the entry’s action is preformed. If the packet does not match any filter entries, the default filter action is applied.
An IP (v4 and/or IPv6) filter can be applied to a network port IP interface. Packets received on the interface are checked against the matching criteria in the filter entries. If the packet completely matches all criteria in an entry, the checking stops and the entry’s action is performed. If the packets do not match any filter entries, they are discarded or forwarded based on the default action specified in the policy.
Figure 24 displays an example of several packets forwarded upon matching the filter criteria and several packets traversing through the filter entries and then dropped.
Note: When snap header is present, this is always set to AA-AA.
