5.1.1. Overview of Filter Policies

Filter policies (or filters), also referred to as Access Control Lists (ACLs), are sets of rules that can be applied to network interfaces and services (VLL (Ethernet and IP), VPLS, VPRN and IES, and IES in-band management). Filter policies constrain network or user traffic based on match criteria and determine the action that will be invoked against the subject packet (that is, the default action can be either “drop” or “forward”).

The 7705 SAR supports five types of filter policies:

The 7705 SAR also supports policy-based routing (PBR), which is based on IP filters, and multi-field classification (MFC).

IP, MAC, and VLAN filters scan all traffic and take the appropriate (configured) action against matching packets. Packets that are not filtered by one of these filters and are destined for the 7705 SAR are then scanned by the CSM filter, if configured.

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.

IP and MAC filter support for SAP and SDP is described in the following sections and is summarized in Table 67 and Table 68. Ingress filter override support for routed VPLS on IES and VPRN services is summarized in Table 69. IPv4 and IPv6 filter support (ingress and egress) for network interfaces is described in the lists following Table 69. MAC filters do not support network interfaces.

Configuring an entity for a filter policy is optional. If a network or service interface is not configured with filter policies, all traffic is allowed on the interface. By default, there are no filters associated with interfaces or services. The filters must be explicitly created and associated. When you create a new filter, you must specify a unique filter ID value for each new filter policy, as well as each new filter entry and associated actions. The filter entries specify the filter matching criteria. See Filter Policy Entries. After creating a filter policy you can also, optionally, assign filters a unique name. Filter IDs or filter names can be used throughout the system to manage filter policies and assign them to interfaces.

IP Filters

IPv4 filters can be applied to the following entities:

Ingress filters affect only incoming packets regardless of whether the packets need to be forwarded to a downstream router or are destined for the 7705 SAR.

IPv6 filters can be applied to the following entities:

MAC Filters

MAC filters can be applied to the following entities:

VLAN Filters

VLAN filters can be applied to ring ports at the ingress point on the 2-port 10GigE (Ethernet) Adapter card and 2-port 10GigE (Ethernet) module. VLAN filters are blocked on all other adapter cards and modules.

CSM Filters

The 7705 SAR supports IPv4 and IPv6 CSM filters. For information on CSM filters, refer to the 7705 SAR System Management Guide, “CSM Filters and CSM Security”.

IP Exception Filters

The 7705 SAR supports IPv4 exception filters. For information on IP exception filters, refer to the 7705 SAR Services Guide, “Router Encryption Exceptions using ACLs”.

5.1.2. Network and Service (Access) Interface-based Filtering

IP and MAC filter policies specify either a forward or a drop action for packets, based on information specified in the match criteria. Within each filter policy, you can create entries that define matching criteria.

The same IP filter policy can be assigned to any entity (network interfaces, IP pseudowires, Ethernet pseudowires, VPLS services, VPRN services, and IES services), all of which can be configured on the same adapter card. For example, a filter policy with filter-id defined as filter-5 can be assigned to multiple Ipipe SAPs and, simultaneously, to network interfaces on the same adapter card.

A filter policy assigned to an entity on one adapter card can also be assigned to any entity on another adapter card. For example, a filter policy with filter-id defined as filter-2 can be assigned to an Epipe on an Ethernet Adapter card and to a network interface on another Ethernet Adapter card.

Only one type of filter (IP or MAC) can be assigned to an interface at a time, and only one filter of that type can be assigned to an interface at a time. The exception is a dual-stack interface (one that supports both IPv4 and IPv6); the interface can have both an IPv4 and an IPv6 filter assigned to it.

Both IP and MAC filter policies are supported per adapter card, and assigning the same filter policy to different entities on a card counts as using one filter policy.

Filter entry matching criteria can be as general or specific as required, but all conditions in the entry must be met in order for the packet to be considered a match and the specified entry action performed. The process stops when the first complete match is found and the action defined in the entry is executed (that is, packets that match the criteria are either dropped or forwarded).

Configuration and assignment of IP and MAC filter policies is similar for network interfaces, IES management SAPs, Ethernet and IP pseudowire SAPs, VPRN and IES interface SAPs and spoke SDPs, and VPLS SAPs and SDPs (spoke and mesh). This guide describes the assignment of filter policies to network interfaces. For detailed information on assigning filters to a service, refer to the 7705 SAR Services Guide; see “IP Filters” (under “Ethernet VLL (Epipe) Services” and “IP Interworking VLL (Ipipe) Services”) for information on assigning IP filter policies to SAPs and spoke SDPs, and see “MAC Filters” (under VPLS Features), for information on assigning MAC filter policies to VPLS SAPs and SDPs.

5.1.3. Policy-Based Routing

Traditionally, IP routing is done by making routing decisions based on the destination IP address of the incoming packet. PBR expands the routing decision from one based solely on the destination IP address to include any other IP criteria, such as source IP address, DSCP, or source/destination UDP/TCP port.

Using PBR at the iLER node provides filtering needed to route IP traffic over multiple uplink interfaces or tunnels using IP criteria. For example, a service provider can use PBR to separate high-value traffic (signaling) from user data by examining the source IP address and/or DSCP bits of the incoming IP packets, and assign a separate transport tunnel to each traffic flow. The transport tunnels could be engineered by using RSVP-TE throughout the entire mobile backhaul network with specific reservation values. The LSP is signaled throughout the network and reserves the needed resources at each node, ensuring the QoS for the high-value traffic.

PBR can also be used to extract packets from the data path and send them to the CSM for debugging or slow path forwarding.

Figure 12 illustrates a PBR implementation for VPRN services in an LTE network, and includes CLI command syntax. The 7705 SAR-8 at the cell site makes routing decisions based on the incoming packet DSCP only, as follows:

Figure 12:  PBR Filtering Based on the DSCP of Incoming Packets 

PBR is supported at ingress for the following services and interfaces:

Note: A PBR filter action can be assigned to an Epipe or Ipipe, or to VPLS (SAP, spoke SDP, or mesh SDP); however, the PBR action is ignored (not performed).

PBR is supported on the private IPSec service (VPRN). For more information on IPSec and PBR, refer to the “PBR” section in the 7705 SAR Services Guide.

5.1.4. Multi-field Classification (MFC)

Multi-field classification (MFC) allows untrusted traffic arriving on the access ports of the 7705 SAR to be reclassified and queued according to a forwarding class assigned to the traffic.

Traffic is classified based on IP criteria. Arriving traffic has an ACL (also known as filter policies) applied to it. If the ACL action is forward fc, a match results in the assignment of the corresponding configured Forwarding Class (FC). This FC is used for queuing of the packet through the 7705 SAR. The match can be based on any IP criteria currently supported by the 7705 SAR IP filter policies.

When MFC is configured and a match is made on an arriving packet, the FC is based only on the MFC configuration. The access ingress policy is no longer active for this packet.

Both PBR and MFC are configured under the IP filter configuration and the action of the filter policy can include both PBR (next-hop ip-address) and MFC (fc fc-name).

If MFC is assigned to a Layer 3 spoke-SDP termination interface, MFC classification is based on the traffic’s customer-assigned inner IP packet. The filter policy rules are applied to the IP criteria of the inner packet after the VC label and transport tunnel label have been removed from the packet. Based on the matching criteria, the appropriate FC is assigned to the packet. This functionality allows the customer packet to be marked with the correct DSCP before it egresses the 7705 SAR. This applies only to an untrusted SAP configuration that has a SAP egress QoS policy assigned to it.

MFC is supported at ingress for the following services and interfaces:

Multi-field classification (MFC) is also supported on the private IPSec service (VPRN). MFC functions in the same manner as the VPRN configuration of traditional services.

5.1.5. VLAN-based Filtering

VLAN filter policies specify either a forward or a drop action for packets, based on VLAN ID information specified in the policy match criteria.

Only one VLAN filter is allowed per ring port on the 2-port 10GigE (Ethernet) Adapter card or 2-port 10GigE (Ethernet) module. The same VLAN filter can be applied to both ring ports. Each VLAN filter supports up to 64 matching criteria entries. The filter acts on ingress traffic and the forwarding action sends packets to the other ring port or to the v-port, depending on the packet’s destination.

The number of VLAN filters that can be created depends on the memory available on the 2-port 10GigE (Ethernet) Adapter card or 2-port 10GigE (Ethernet) module.

The 7705 SAR does not support filter logging or statistics collection for VLAN filters.

5.1.6. Filter Policy Entries

Topics in this section include:

A filter policy compares the match criteria specified within a filter entry to packets coming into the system, in the order the entries are numbered in the policy. When a packet matches all the parameters specified in the entry, the system takes the specified action to either drop or forward the packet. If a packet does not match the entry parameters, the packet continues through the filter process and is compared to the next filter entry, and so on.

If the packet does not match any of the entries, the system executes the default action specified in the filter policy, which is to either drop or forward the packet. Each filter policy is assigned a unique filter ID. Each filter policy is defined with:

Each filter entry contains:

5.1.6.1. Applying Filter Policies

IPv4 filter policies can be applied at:

1. network interfaces
   1. ingress and egress of network IP interfaces
2. SAPs
   1. ingress of Ethernet and IP pseudowire SAPs (Epipe and Ipipe), VPLS SAPs, VPRN SAPs, and IES SAPs
   2. ingress of IES in-band management SAPs
   3. egress of VPRN and IES SAPs
   4. egress of VPLS SAPs (Ethernet only)
3. SDPs
   1. ingress of VPLS SDPs (spoke and mesh)
   2. ingress of VPRN and IES spoke SDPs

IPv6 filters can be applied at:

1. network interfaces
   1. ingress and egress of Ethernet network interfaces (with null or dot1q encapsulation)
   2. ingress and egress of network interfaces on the 4-port OC3/STM1 Clear Channel Adapter card (with POS encapsulation)
2. SAPs
   1. ingress and egress of IES SAPs
   2. ingress and egress of VPRN SAPs
   3. ingress and egress of VPLS SAPs
3. SDPs
   1. ingress of VPRN spoke SDPs
   2. ingress of VPLS SDPs

MAC filter policies can be applied at the ingress of VPLS SAPs (Ethernet, and ATM on clear channel OC3 adapter cards) and SDPs (spoke and mesh).

VLAN filters can only be applied to ring ports on the 2-port 10GigE (Ethernet) Adapter card and 2-port 10GigE (Ethernet) module.

Note: By default, all created filters have a default action of drop (implicit drop). That is, if none of the entries in the filter match the packet, and a default action is not explicitly configured by the user, the packet is dropped.

Figure 13 shows the process to create filter policies and apply them to a network interface.

Figure 13:  Creating and Applying Filter Policies 

5.1.6.3. Ordering Filter Entries

When entries are created, they should be arranged sequentially from the most explicit entry to the least explicit. Filter matching ceases when a packet matches an entry. The entry action is performed on the packet, either drop or forward. To be considered a match, the packet must meet all the conditions defined in the entry.

Packets are compared to entries in a filter policy in ascending entry ID order. To reorder entries in a filter policy, for example, to reposition entry ID 6 as entry ID 2, use the renum command (renum 6 2).

When a filter policy consists of a single entry, the filter executes actions as follows.

1. If a packet matches all the entry criteria, the entry’s specified action is performed (drop or forward).
2. If a packet does not match all of the entry criteria, the policy’s default action is performed (drop or forward).

If a filter policy contains two or more entries, packets are compared in ascending entry ID order (for example, 1, 2, 3 or 10, 20, 30).

1. Packets are compared with the criteria in the first entry ID.
2. If a packet matches all the properties defined in the entry, the entry’s specified action is executed.
3. If a packet does not completely match, the packet continues to the next entry, and then subsequent entries.
4. If a packet does not completely match any subsequent entries, the default action is performed (drop or forward).

   Note: By default, all created filters have a default action of drop (implicit drop). That is, if none of the entries in the filter match the packet, and a default action is not explicitly configured by the user, the packet is dropped.

Figure 14 displays an example of several packets forwarded upon matching the filter criteria and several packets traversing through the filter entries and then dropped.

Figure 14:  Filtering Process Example 

5.1.7. Filter Log Files

Filter entries can be configured to be written to a filter log file. The log file must exist before any entries can be logged. To create a log file, use the config>filter>log log-id create command. Filter logs can be sent to either memory or to an existing syslog server. See Filter Logs for more information.

The 7705 SAR supports filter logging for the following filters:

The 7705 SAR does not support filter logging for VLAN filters.

Refer to the 7705 SAR System Management Guide, “Syslog”, for information on syslogs.

5.2.1. IP Filters

5.2.2. IPv6 Filters

IPv6 packets with extension headers can be filtered with an IPv6 filter, but are subject to some restrictions:

No alarms, logs, or statistics will be reported in the above cases.

5.2.3. MAC Filters

5.2.4. VLAN Filters

5.2.5. Filter Logs

5.2.6. Reference Sources

For information on supported IETF drafts and standards, as well as standard and proprietary MIBs, refer to Standards and Protocol Support.