4. Filter policies

This chapter provides information about filter policies and management.

4.1. Filter policy configuration overview

Filter policies, also referred to as Access Control Lists (ACLs), are templates applied to services or network IP interfaces to control network traffic into (ingress) or out of (egress) a service access port (SAP) or network IP interface based on IP and MAC matching criteria. Filters are applied to services to look at packets entering or leaving a SAP. Filters can be used on several interfaces. 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.

Configuring an entity with a filter policy is optional. If an entity such as a service or network IP interface is not configured with filter policies, then all traffic is allowed on the ingress and egress interfaces. By default, there are no filters associated with services or interfaces. They must be explicitly created and associated. When you create a new filter, default values are provided although you must specify a unique filter ID value to each new filter policy as well as each new filter entry and associated actions. The filter entries specify the filter matching criteria and also an action to be taken upon a match.

Available ingress and egress CAM hardware resources can be allocated as per user needs for use with different filter criteria. By default, the system allocates resources to maintain backward compatibility with release 4.0. Users can modify the resource allocation based on their need to scale the number of entries or number of associations (that is, number of SAP/IP interfaces using a filter policy that defines particular match criteria). If no CAM resources are allocated to particular match criteria defined in a filter policy, then the association of that filter policy to a SAP will fail. This is true for both ingress and egress filter policy. Please read the configuration notes section below for more information.

Only one ingress IP or MAC filter policy and one egress IP or MAC filter policy can be applied to a Layer 2 SAP. Both IPv4 and IPv6 ingress and egress filter policy can be used simultaneously with a Layer 2 SAP. Only one ingress IP filter policy and one egress IP filter policy can be applied to a network IP interface. Both IPv4 and IPv6 ingress and egress filter policy can be used simultaneously with an IP interface (For example: network Port IP interface in network mode and IES IP interface in access-uplink mode) for which IPv6 addressing is supported. Network filter policies control the forwarding and dropping of packets based on IP match criteria. Note that non-IP packets are not hitting the IP filter policy, so the default action in the filter policy will not apply to these packets.

Note that non-IP packets are not hitting the IP filter policy, so the default action in the filter policy will not apply to these packets.

4.1.1. Service and network IP 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.

Filter entry matching criteria can be as general or specific as you require, 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 executes the action defined in the entry, either to drop or forward packets that match the criteria.

4.1.2. Filter policy entities

A filter policy compares the match criteria specified within a filter entry to packets coming through 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, then system executes the default action specified in the filter policy. Each filter policy is assigned a unique filter ID. Each filter policy is defined with:

scope
default action
description

Each filter entry contains:

match criteria
an action

4.1.2.1. Applying filter policies

The following tables describe support of filter policies on different 7210 platforms.

Table 35: Applying filter policies for 7210 SAS-T devices configured in network mode

Service	IP filter	IPv6 filter	MAC filter
Network port IP interface	Network port IP interface (ingress and egress)	Network port IP interface (ingress and egress)	Not available
Epipe	Epipe SAP (ingress and egress)	Epipe SAP (ingress and egress)	Epipe SAP (ingress and egress)
VPLS	VPLS SAP (ingress and egress)	VPLS SAP (ingress and egress)	VPLS SAP (ingress and egress)
IES	IES interface SAP (ingress and egress)	IES interface SAP (ingress and egress)	Not available
VPRN	VPRN interface SAP (ingress and egress)	VPRN interface SAP (ingress and egress)	Not available
PBB	Ingress and egress of Epipe I-SAP and I-VPLS I-SAP	Ingress and egress of Epipe I-SAP, and I-VPLS I-SAP	Ingress and egress of Epipe I-SAP, I-VPLS I-SAP and B-VPLS B-SAP
RVPLS (RVPLS SAPs) 1	VPLS access (ingress and egress) and network SAPs (ingress and egress)	Not available	Not available
RVPLS (RVPLS IES IP Interface) 1	Ingress override filters (ingress)	Not available	Not available

Note:

Refer to the “Routed VPLS” section in the 7210 SAS-Mxp, S, Sx, T Services Guide for more information.

Table 36: Applying filter policies for 7210 SAS-T (access-uplink mode)

Service	IP filter	IPv6 filter	MAC filter
Epipe	Epipe access SAP (egress and ingress), Epipe access-uplink SAP (egress and ingress)	Epipe (egress and ingress), Epipe access-uplink SAP (egress and ingress)	Epipe (egress and ingress), Epipe access-uplink SAP (egress and ingress)
VPLS	VPLS access SAP (ingress and egress), VPLS access-uplink SAP (ingress and egress)	VPLS access SAP (ingress and egress), VPLS access-uplink SAP (ingress and egress)	VPLS access SAP (ingress and egress), VPLS access-uplink SAP (ingress and egress)
RVPLS (VPLS SAPs) 1	VPLS access (ingress and egress) and access-uplink SAPs (ingress and egress)	Not available	Not available
RVPLS (RVPLS IES IP Interface) 1	Ingress override filters (ingress)	Not available	Not available
IES	IES access SAP, IES access-uplink SAP	IES access-uplink SAP	Not available

Note:

Refer to the “Routed VPLS” section in the 7210 SAS-Mxp, S, Sx, T Services Guide for more information.

Table 37: Applying filter policies for 7210 SAS-Mxp, 7210 SAS-R6, and 7210 SAS-R12

Service	IP filter	IPv6 filter	MAC filter
Network port IP interface	Network port IP interface (ingress and egress)	Network port IP interface (ingress and egress)	Not available
Epipe	Epipe SAP (ingress and egress)	Epipe SAP (ingress and egress)	Epipe SAP (ingress and egress)
VPLS	VPLS SAP (ingress and egress)	VPLS SAP (ingress and egress)	VPLS SAP (ingress and egress)
IES	IES interface SAP (ingress and egress)	IES interface SAP (ingress and egress)	Not available
VPRN	VPRN interface SAP (ingress and egress)	VPRN interface SAP (ingress and egress)	Not available
PBB	Not supported	Not supported	Not supported
RVPLS (VPLS SAPs) 1	VPLS access (ingress and egress) and access-uplink SAPs (ingress and egress)	Available only for 7210 SAS-Mxp Not available for 7210 SAS-R6 and 7210 SAS-R12	Available only for 7210 SAS-Mxp Not available for 7210 SAS-R6 and 7210 SAS-R12
RVPLS (RVPLS IES and VPRN IP interface) 1	Ingress override filters (ingress)	Available only for 7210 SAS-Mxp Not available for 7210 SAS-R6 and 7210 SAS-R12	Not available

Note:

Refer to the “Routed VPLS” section in the 7210 SAS-Mxp, S, Sx, T Services Guide for more information.

Table 38: Applying filter policies for 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE devices

Service	IP filter	IPv6 filter	MAC filter
Network port IP interface	Network port IP interface (ingress and egress)	Network port IP interface (ingress and egress)	Not available
Epipe	Epipe SAP (ingress and egress)	Epipe SAP (ingress and egress)	Epipe SAP (ingress and egress)
VPLS	VPLS SAP (ingress and egress)	VPLS SAP (ingress and egress)	VPLS SAP (ingress and egress)
IES	IES interface SAP (ingress and egress)	IES interface SAP (ingress and egress)	Not available
VPRN	VPRN interface SAP (ingress and egress)	VPRN interface SAP (ingress and egress)	Not available
PBB	Not available	Not available	Not available
RVPLS (VPLS SAPs) 1	VPLS access (ingress and egress) and access-uplink SAPs (ingress and egress)	Not available	Not available
RVPLS (RVPLS IES and VPRN IP interface) 1	Ingress override filters (ingress)	Not available	Not available

Note:

Refer to the “Routed VPLS” section in the 7210 SAS-Mxp, S, Sx, T Services Guide for more information.

4.1.2.2. ACL on range SAPs

The ACLs on VLAN range SAPs are supported only on ingress (for Epipe and VPLS services). The following tables list the support.

Table 39: ACLs support in Epipe services on 7210 SAS-T network and access-uplink modes variants when using range SAPs

Platforms/types of filters	7210 SAS-T (network mode)	7210 SAS-T (access-uplink mode)
Ingress IP or IPv6	Yes	Yes
Ingress MAC	Yes	Yes
Egress IP	No	No
Egress MAC	No	No

Table 40: ACLs support in Epipe services on 7210 SAS-R6, 7210 SAS-R12, 7210 SAS-Sx/S 1/10GE and 7210 SAS-Sx 10/100GE, 7210 SAS-Sx 10/100GE, and 7210 SAS-Mxp variants when using range SAPs

Platforms/types of filters	7210 SAS-R6 and 7210 SAS-R12	7210 SAS-Mxp	7210 SAS-Sx/S 1/10GE	7210 SAS-Sx 10/100GE
Ingress IP or IPv6	Yes	Yes	Yes	Yes
Ingress MAC	Yes	Yes	Yes	Yes
Egress IP	No	No	No	No
Egress MAC	No	No	No	No

Table 41: ACLs support in VPLS services on 7210 SAS-T network and access-uplink mode variants when using range SAPs

Platforms/types of filters	7210 SAS-T (access-uplink mode)	7210 SAS-T (network mode)
Ingress IP or IPv6	Yes	No
Ingress MAC	Yes	No
Egress IP	No	No
Egress MAC	No	No

Filter policies are applied to the following service entities:

SAP ingress
IP and MAC filter policies applied on the SAP ingress define the Service Level Agreement (SLA) enforcement of service packets as they ingress a SAP according to the filter policy match criteria.
SAP egress
Filter policies applied on the SAP egress define the Service Level Agreement (SLA) enforcement for service packets as they egress on the SAP according to the filter policy match criteria.
network ingress
IP filter policies are applied to network ingress IP interfaces.
network egress
IP filter policies are applied to network egress IP interfaces.

4.1.2.2.1. Configuration guidelines for Routed VPLS and ACLs

The following information describes Routed VPLS and ACLs configuration guidelines:

MAC filters are supported on R-VPLS SAPs only on the 7210 SAS-Mxp. Refer to the “Routed VPLS” section in the 7210 SAS-Mxp, S, Sx, T Services Guide for more information.
IPv6 filters on RVPLS SAP are supported only on 7210 SAS-Mxp.
IP filters using resources from the pool allocated to IPv4 criteria are supported as override filters on all platforms as described in this document.
IP filters using resources from the pool allocated to IPv4 criteria, and IPv6 filters using resources allocated to IPv6 criteria (both 64-bit and 128-bit resource pools), are supported as override filters only on 7210 SAS-Mxp.
IP filters using IPv6 resources are not supported on RVPLS SAP.
Egress override filters are not supported (under the IES and VPRN interface associated with RVPLS).

4.2. Creating and applying policies

The following figure shows the process to create filter policies and apply them to a service network IP interface.

Figure 9: Creating and applying filter policies

4.2.1. Packet matching criteria

As few or as many match parameters can be specified as required, but all conditions must be met for the packet to be considered a match and the specified action performed. The process stops when the first complete match is found and then executes the action defined in the entry, either to drop or forward packets that match the criteria.

IP filter policies match criteria that associate traffic with an ingress or egress SAP. Matching criteria to drop or forward IP traffic include:

source IP address and mask
Source IP address and mask values can be entered as search criteria. The IP Version 4 addressing scheme consists of 32 bits expressed in dotted decimal notation (X.X.X.X).
Address ranges are configured by specifying mask values, the 32-bit combination used to describe the address portion which refers to the subnet and which portion refers to the host. The mask length is expressed as an integer (range 1 to 32).
destination IP address and mask
Destination IP address and mask values can be entered as search criteria. Similar choice as available for source IPv6 addresses is available for destination IPv6 addresses (see above).
protocol
Entering a protocol ID (such as TCP, UDP, etc.) allows the filter to search for the protocol specified in this field.
protocol
For IPv6: entering a next header allows the filter to match the first next header following the IPv6 header.
source port
Entering the source port number allows the filter to search for matching TCP or UDP port values.
destination port
Entering the destination port number allows the filter to search for matching TCP or UDP port.
DSCP marking
Entering a DSCP marking enables the filter to search for the DSCP marking specified in this field. See Table 42.
ICMP code
Entering an ICMP code allows the filter to search for matching ICMP code in the ICMP header.
ICMP type
Entering an ICMP type allows the filter to search for matching ICMP types in the ICMP header.
IPv4 filter created in the mode to use IPv6 resource cannot be applied at egress SAP. Similarly IPv4 filter created in the mode to use IPv6 resource fails to match fragment option.
fragmentation
IPv4 only: Enable fragmentation matching. A match occurs if packets have either the MF (more fragment) bit set or have the Fragment Offset field of the IP header set to a non-zero value.
option present
Enabling the option presence allows the filter to search for presence or absence of IP options in the packet. Padding and EOOL are also considered as IP options.
TCP-ACK/SYN flags
Entering a TCP-SYN/TCP-ACK flag allows the filter to search for the TCP flags specified in these fields.

MAC filter policies match criteria that associate traffic with an ingress or egress SAP. Matching criteria to drop or forward MAC traffic include:

source MAC address and mask
Entering the source MAC address range allows the filter to search for matching a source MAC address and/or range. Enter the source MAC address and mask in the form of xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx; for example, 00:dc:98:1d:00:00.
destination MAC address and mask
Entering the destination MAC address range allows the filter to search for matching a destination MAC address and/or range. Enter the destination MAC address and mask in the form of xx:xx:xx:xx:xx:xx or xx-xx-xx-xx-xx-xx; for example, 02:dc:98:1d:00:01.
dot1p and mask
Entering an IEEE 802.1p value or range allows the filter to search for matching 802.1p frame. The Dot1p and mask accepts decimal, hex, or binary in the range of 0 to 7.
Ethertype
Entering an Ethernet type II Ethertype value to be used as a filter match criterion. The Ethernet type field is a two-byte field used to identify the protocol carried by the Ethernet frame. The Ethertype accepts decimal, hex, or binary in the range of 1536 to 65535.

4.2.1.1. DSCP values

The following table lists DSCP values.

Table 42: DSCP name to DSCP value table

DSCP name	Decimal DSCP value	Hexadecimal DSCP value	Binary DSCP value
default	0	*
cp1	1
cp2	2
cp3	3
cp4	4
cp5	5
cp6	6
cp7	7	*
cs1	8
cp9	9
af11	11	*
af12	12	*
cp13	13
cp15	15
cs2	16	*
cp17	17
af21	18	*
cp19	19
af22	20	*
cp21	21
af23	22	*
cp23	23
cs3	24	*
cp25	25
af31	26	*
cp27	27
af32	28	*
cp29	29
af33	30	*
cp21	31
cs4	32	*
cp33	33
af41	34	*
cp35	35
af42	36	*
cp37	37
af43	38	*
cp39	39
cs5	40	*
cp41	41
cp42	42
cp43	43
cp44	44
cp45	45
ef	46	*
cp47	47
nc1	48	*	(cs6)
cp49	49
cp50	50
cp51	51
cp52	52
cp53	53
cp54	54
cp55	55
cp56	56
cp57	57
nc2	58	*	(cs7)
cp60	60
cp61	61
cp62	62

4.2.2. 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. 7210 SAS supports either drop or forward action.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 an ascending entry ID order. To reorder entries in a filter policy, edit the entry ID value; for example, to reposition entry ID 6 to a more explicit location, change the entry ID 6 value to entry ID 2.

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

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

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

Packets are compared with the criteria in the first entry ID.
If a packet matches all the properties defined in the entry, the entry specified action is executed.
If a packet does not completely match, the packet continues to the next entry, and then subsequent entries.
If a packet does not completely match any subsequent entries, then the default action is performed.

The following figure shows an example of several packets forwarded upon matching the filter criteria and several packets traversing through the filter entries and then dropped.

Figure 10: Filtering process example

4.2.3. Applying filters

This section provides information about applying filters to entities.

4.2.3.1. Applying a filter to a SAP

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 an entry action is performed. If permitted, the traffic is forwarded according to the specification of the action. If the packets do not match, the default filter action is applied. If permitted, the traffic is forwarded.

When egress filters are applied to a SAP, packets received at the egress SAP are checked against the matching criteria in the filter entries. If the packet completely matches all criteria in an entry, the checking stops. If permitted, the traffic is transmitted. If denied, the traffic is dropped. If the packets do not match, the default filter action is applied.

Filters can be added or changed to an existing SAP configuration by modifying the SAP parameters. Filter policies are not operational until they are applied to a SAP and the service enabled.

4.2.3.2. Applying a filter to a network IP interface

An IP 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. If permitted, the traffic is forwarded. If the packets do not match, they are discarded or forwarded based on the default action specified in the policy.

4.3. Configuration notes

Note:

Refer to the 7210 SAS-Mxp, S, Sx, T Services Guide and the 7210 SAS-R6, R12 Services Guide for service-specific ACL support and restrictions.

The following information describes filter implementation guidelines and caveats:

Creating a filter policy is optional.
Associating a service with a filter policy is optional.
When a filter policy is configured, it should be defined as having either an exclusive scope for one-time use, or a template scope meaning that the filter can be applied to multiple SAPs.
A specific filter must be explicitly associated with a specific service in order for packets to be matched.
A filter policy can consist of zero or more filter entry. Each entry represents a collection of filter match criteria. When packets enter the ingress or egress ports, packets are compared to the criteria specified within the entry or entries.
When a large (complex) filter is configured, it may take a few seconds to load the filter policy configuration and be instantiated.
The action keyword must be entered for the entry to be active. Any filter entry without the action keyword will be considered incomplete and be inactive.
When a filter policy is created with the option ipv6-64bit-address, the entries can only use only the IPv6 src-ip and IPv6 dst-ip fields in the match criteria.
When a filter policy is created with the option ipv6-128bit-address, the entries can use the IPv6 src-ip, IPv6 dst-ip, IPv6 DSCP, TCP/UDP port numbers (source and destination port), ICMP code and type, and TCP flags fields in the match criteria.
The resources must be allocated for use by ingress IPv6 filters, before associating an IPv6 filter policy to a SAP. By default, the software does not enable the use of IPv6 resources. Until resources are allocated for use by IPv6 filters, software fails all attempts to associate a IPv6 filter policy with a SAP.
The available ingress CAM hardware resources can be allocated as per user needs for use with different filter criteria using the commands under config> system>resource-profile>ingress-internal-tcam>acl-sap-ingress. By default, the system allocates resources to maintain backward compatibility with release 4.0. Users can modify the resource allocation based on their need to scale the number of entries or number of associations (that is, number of SAP/IP interfaces using a filter policy that defines a particular match criterion).
The available egress CAM hardware resources can be allocated as per user needs for use with different filter criteria using the commands under config> system>resource-profile>egress-internal-tcam>acl-sap-egress. By default, the system allocates resources to maintain backward compatibility with release 4.0. Users can modify the resource allocation based on their needs to scale the number of entries or the number of associations (that is, number of SAP/IP interfaces using a filter policy that defines a particular match criterion).
IPv6 ACLs and MAC QoS policies cannot co-exist on the SAP.
If no CAM resources are allocated to a particular match criterion defined in a filter policy, then the association of that filter policy to a SAP will fail. This is true for both ingress and egress filter policy.
IPv6 ACLs and MAC QoS policies cannot co-exist on the SAP.
For traffic ingressing a B-VPLS SAP and destined to a B-VPLS SAP, the MAC filter matches the B-domain, MAC header fields (that is, B-DA, B-SA, and others). The MAC filter can be used to match customer payload MAC header fields for traffic ingressing a B-VPLS SAP and destined to an I-VPLS SAP.

4.3.1. MAC filters

The following information describes MAC filters:

If a MAC filter policy is created with an entry and entry action specified but the packet matching criteria is not defined, then all packets processed through this filter policy entry will pass and take the action specified. There are no default parameters defined for matching criteria.
MAC filters cannot be applied to network interfaces. On the 7210 SAS-Mxp, they can be applied on an R-VPLS service with IES or VPRN. See Applying filter policies and refer to the 7210 SAS-Mxp, S, Sx, T Services Guide for more information.
Some of the MAC match criteria fields are exclusive to each other, based on the type of Ethernet frame. Use the following table to determine the exclusivity of fields. On the 7210 SAS, the default frame-format is “EthernetII”.

Table 43: MAC match criteria exclusivity rules

Frame format	Etype
Ethernet – II	Yes
802.3	No
802.3 – snap	No

4.3.2. IP filters

The following information describes IP filterSs:

define filter entry packet matching criteria
If a filter policy is created with an entry and entry action specified but the packet matching criteria is not defined, then all packets processed through this filter policy entry will pass and take the action specified. There are no default parameters defined for matching criteria.
action
An action parameter must be specified for the entry to be active. Any filter entry without an action parameter specified will be considered incomplete and be inactive.

4.3.3. IPv6 filters

The following information describes IPv6 filters:

define filter entry packet matching criteria
If a filter policy is created with an entry and entry action specified, but the packet matching criteria is not defined, then all packets processed through this filter policy entry passes and takes the action specified. There are no default parameters defined for matching criteria.
action
An action parameter must be specified for the entry to be active. Any filter entry without an action parameter specified is considered incomplete and inactive.

4.3.3.1. Resource usage for ingress filter policies

Note:

The number of entries per slice/chunk is different for both ingress-internal-tcam resource pool and egress-internal-tcam resource pool for different platforms.
The example below assumes number of entries to be 256 per slice/chunk for ingress-internal-tcam resource pool (for example: 7210 SAS-T). It is valid for other platforms with suitable modification of number of entries per slice.

When the user allocates resources from the ingress CAM resource pool for use by filter policies using the configure> system> resource-profile CLI commands, the system allocates resources in chunks of fixed-size entries (example - 256 entries per chunk on 7210 SAS-T). The usage of these entries by different type of match criteria is described below:

mac-criteria - User needs to allocate resources for mac-criteria from the filter resource pool by using the command config>system>resource-profile>ingress-internal-tcam>acl-sap-ingress>mac-match-enable before using ingress ACLs with mac-criteria. Every entry configured in the filter policy using the mac-criteria uses one (1) entry from the chunks allocated for use by mac-criteria in the hardware. For example, assume a filter policy is configured with 50 entries and uses config>system>resource-profile>ingress-internal-tcam>acl-sap-ingress>mac-match-enable 1, the user configures one chunk for use by mac-criteria (allowing a total of 256 entries. one reserved for internal use entries for use by SAPs using filter policies that use mac-criteria). In this case, the user can have 5 SAPs using mac-criteria filter policy and consumes 250 entries.
ipv4-criteria - User needs to allocate resources for ip(v4)-criteria from the filter resource pool by using the command config>system>resource-profile>ingress-internal-tcam>acl-sap-ingress>ipv4-match-enable before using ingress ACLs with ipv4-criteria. The resource usage per IPv4 match entry is same as the mac-criteria. Please check the preceding example. When created with use-ipv6-resource, the resource usage is the same as IPv6 filters using ipv6-128-bit-addresses.
ipv6-criteria using ipv6-64-bit addresses - User needs to allocate resources for ipv6-criteria with 64-bit address match from the filter resource pool by using the command config>system>resource-profile>ingress-internal-tcam>acl-sap-ingress>ipv6-64only-match-enable before using ingress ACLs with ipv6-criteria that use only IPv6 64-bit address for source and destination IPv6 addresses. The IPv6 headers fields available for match is limited. Please see the CLI description for filter below for more information. The usage is same as the ipv4 and mac-criteria.
ipv6-criteria using ipv6-128-bit addresses - User needs to allocate resources for ipv6-criteria with 128-bit address match from the filter resource pool by using the command config>system>resource-profile>ingress-internal-tcam>acl-sap-ingress>ipv4-ipv6-128-match-enable before using ingress ACLs with ipv6-criteria that use only IPv6 128-bit address for source and destination IPv6 addresses. These resources can be shared by a policy that uses only IPv4 criteria entries. Every entry configured in the filter policy using the ipv6-criteria with 128-bit addresses uses two (2) entries from the chunks allocated for use by ipv6-criteria (128-bit) in the hardware. For example: Assume a filter policy is configured with 50 entries and using config>system>resource-profile>ingress-internal-tcam>acl-sap-ingress>ipv4-ipv6-128-match-enable 1, the user configures one chunk for use by ipv6-criteria with 128-bit addresses (allowing for a total of 128 entries for use by SAPs using filter policies that use this criteria). In this case, user can have five (5) SAPs using this filter policy and consumes 125 entries. Note when a chunk is allocated to IPv6 criteria, software automatically adjusts the number of available entries in that chunk to 128, instead of 256, since 2 entries are needed to match IPv6 fields.

The users can use the tools>dump>system-resources command to know the current usage and availability. For example: Though chunks are allocated in 256 entries, only 128 entries show up against filters using those of IPv6 128-bit addresses. One or more entries are reserved for system use and is not available for user.

4.3.3.2. Resource usage for egress filter policies

When the user allocates resources for use by filter policies using the config>system>resource-profile>egress-internal-tcam CLI commands, the system allocates resources in chunks of fixed-size entries (example - 256 entries per slice on 7210 SAS-Mxp) from the egress internal tcam pool in hardware. The usage of these entries by different type of match criteria is described below:

mac-criteria - The user needs to allocate resources for using mac-criteria using the command config>system>resource-profile>egress-internal-tcam>acl-sap-egress>mac-match-enable 2 or config>system>resource-profile>egress-internal-tcam>acl-sap-egress>mac-ipv4-match-enable 2 or config>system> resource-profile>egress-internal-tcam>acl-sap-egress>mac-ipv6-64bit-match-enable 2. In the last two cases, the resources can be shared with SAPs that use IPv4 or IPv6 64-bit filter policies. The first case allocates resources for exclusive use by MAC filter policies. The resource usage varies based how resources have been allocated:
1. If resources are allocated for use by mac-criteria only (using mac-match-enable), then every entry configured in the filter policy uses one (1) entry from the chunks allocated for use by mac-criteria in the hardware. For example: Assume a filter policy is configured with 25 mac-criteria entries and uses config>system>resource-profile>egress-internal-tcam>acl-sap-egress>mac-match-enable 2, the user configures two chunks (each chunk having 256 entries each) for use by mac-criteria, allowing a total of 512 entries for use by SAPs using filter policies that use mac-criteria. Therefore, the user can have about 10 SAPs using mac-criteria filter policy and consumes 500 entries. With this, SAPs using ipv4 criteria or ipv6 criteria cannot share the resources along with SAPs using mac-criteria.
2. If the resources are allocated for sharing between mac-criteria and ipv4-criteria, then every entry configured in the filter policy uses 2 (two) entries from the chunks allocated in hardware. For example, assume a filter policy is configured with 25 mac-criteria entries and another filter policy configured with 25 IPv4 criteria entries and, with mac-ipv4-match-enable set to 2, that is, user configures two chunks (each chunk having 256 entries each) for sharing between MAC and IPv4, allowing for a total of 128 entries for use by SAPs that use filter policies using ipv4-criteria or mac-criteria. Therefore, the user can have about 5 SAPs using filter policies, such that 3 SAPs uses mac-criteria and the other 2 SAPs use ipv4-criteria or any combination thereof.
3. If the resources are allocated for sharing between mac-criteria and ipv6-64bit-criteria, then every entry configured in the filter policy uses 2 (two) entries from the chunks allocated in hardware.
  For example, assume a filter policy is configured with 50 mac-criteria entries and another filter policy configured with 50 IPv6 64-bit criteria entries and, with mac-ipv6-64bit-match-enable set to 2, that is, user configures two chunks (with 256 entries each) for sharing between MAC and IPv6-64bit, allowing for a total of 128 entries for use by SAPs that use filter policies using ipv6-64bit-criteria or mac-criteria. Therefore, the user can have about 2 SAPs using filter policies, such that one SAP uses mac-criteria and the other one SAP uses ipv6-64bit-criteria or any combination thereof.
ipv4-criteria - The user need to allocate resources using the command config> system>resource-profile>egress-internal-tcam>acl-sap-egress>mac-ipv4-match-enable. The resource usage is as described previously.
ipv6-criteria using ipv6-64-bit addresses - The user need to allocate resources using the command config>system>resource-profile>egress-internal-tcam>acl-sap-egress> mac-ipv6-64bit-match-enable. The resource usage is as described previously.
ipv6-criteria using ipv6-128-bit addresses - The user need to allocate resources using the command config>system>resource-profile>egress-internal-tcam>acl-sap-egress>ipv6-128bit-match-enable. This command allocates resources for exclusive by IPv6-128bit criteria filter policies and cannot be shared by SAPs using any another criteria. If resources are allocated for use by ipv6-128bit-criteria only, then every entry configured in the filter policy uses two (2) entries from the chunks allocated for use in hardware. For example: Assume a filter policy is configured with 50 ipv6-128bit-criteria entries and user uses config>system>resource-profile>egress-internal-tcam>acl-sap-egress>ipv6-128bit-match-enable 2, to configure two chunks (each chunk having 256 entries each) for use by ipv6-128bit-criteria. This allows for a total of 128 entries for use by SAPs using filter policies that use ipv6-128bit-criteria. Therefore the user can have about 2 SAPs using ipv6-128bit-criteria filter policy and consumes 100 entries.

The user can use the tools>dump>system-resources command to know the current usage and availability.