Troubleshooting ACL Resource Insufficiency

Many services use ACL resources. However, ACL resources on CloudEngine series switches are limited. If ACL resources are insufficient, services that require ACL resources will fail to be delivered.

ACL resource insufficiency is a common problem on the live network, which is difficult to resolve since the ACL working mechanism is complex. To help address this problem, this document describes the causes of ACL resource insufficiency, services that use ACL resources, and how to predict whether services will be successfully delivered.

This document helps you gain a basic understanding of ACL resources. For more information, see ACL Technical Topics.

On the live network, a device generally reports an alarm indicating ACL resource insufficiency even when only a few ACL rules are configured and the number does not reach the upper limit. Why does this happen? This is because the rule resource is only a type of ACL resources, and the bottleneck of ACL resources lies in the key buffer (KB) resource.

A service using ACL resources can run properly only after it is successfully delivered to a group. Many groups have been predefined on the device. However, the groups are not created at the beginning, which can be considered as empty groups and cannot be used to house services. The system starts creating a group while configuring a service that uses ACL resources. Successful creation of a group depends on sufficient KB resources. The groups fall into the three types: single-width group, double-width group, and quadruple-width group. A single-width group and a double-width group respectively occupy one KB, and a quadruple-width group occupies two KBs.

In addition, multiple services can be delivered to the same group. When a new service is configured and if the created group meets the requirements, the service can be delivered to this group without occupying extra KB resources. If the created group does not meet the requirements, a KB resource needs to be obtained to create a new group.

Therefore, in the actual configuration, although rules are the most familiar and direct resource for users, sufficient KB resources for creating a group are the key to successful delivery of a service. The following table uses the CE12800 as an example to illustrate the ACL working mechanism for your better understanding.

Figure 1-1 ACL resource working mechanism

The table row specifies the bucket depth, which indicates the rule specification. The table column specifies the bucket width, which indicates the KB specification. The bucket width is the bottleneck in successful service delivery.

If the total length of the matching fields in a rule does not exceed 80 bits (for example, the total length of the matching source and destination IP addresses is 64 bits because an IP address has 32 bits. For the lengths of other fields, that is, the number of bits occupied in the packet, see the related product documentation), a single-width group is selected and one KB is occupied. If the total length of matching fields in a rule falls within the range of 80 bits to 160 bits, a double-width group is selected and one KB is occupied. If the total length of matching fields in a rule exceeds 160 bits, a quadruple-width group is selected and two consecutive KBs are occupied.

For example, assume that the following rules have been configured:

Rule 1: rule permit tcp source 1.1.1.1 24 destination 1.1.2.2 24

Rule 2: rule permit tcp source 1.1.1.1 24 destination 1.1.2.2 24 source-port eq 1 destination-port eq 10

Rule 3: rule permit tcp source 1.1.1.1 24 destination 1.1.2.2 24 source-port eq 1 destination-port eq 10 tcp-flag ack ttl-expired tos 2 precedence 5 logging

As shown in Figure 1-1, sending protocol packets to the CPU occupies two KBs by default. Rule 1 is delivered to a single-width group, occupying one KB; Rule 2 is delivered to a double-width group, occupying one KB; and Rule 3 is delivered to a quadruple-width group, occupying two consecutive KBs. In addition, multiple rules can occupy the same KB, for example, Rule 4 and Rule 1.

If Rule 5 and Rule 6 are configured later, all the eight KB resources are occupied. If new services are configured and the created groups cannot meet the requirements, new groups need to be created but no KB resources are available. In this case, even if the number of rules does not reach the specification, the device still reports an alarm indicating that ACL resources are insufficient and services fail to be delivered.

A key question raising here is what is in a group and how to determine whether the created group meets the requirements of new services. We will continue finding the answers in the following sections.

The preceding section briefly describes the basic principles of ACL and the causes of ACL resource insufficiency. However, on the live network, ACL resources may be insufficient even if users have not configured any ACL rule. Why does this problem still occur? This section will explore this problem by explaining the services that use ACL resources.

The ACL function is powerful. You can configure the modular QoS command line interface (MQC) based on ACL rules to provide differentiated services. Besides, the implementation of many services depends on internal ACL delivery. For example, to collect statistics on VLANIF interfaces, a corresponding ACL needs to be delivered. Services related to IPv4, IPv6, MPLS, TRILL, and VXLAN are closely related to ACLs.

Depending on the user sensitivity, services using ACL resources are classified into explicit services and implicit services. For example, when users configure MQC, they also configure ACL rules. Therefore, the MQC service is an explicit service. When users enable VLAN traffic statistics collection, an ACL for processing VLAN traffic statistics will be delivered, but users are unaware of this. Therefore, VLAN traffic statistics collection is an implicit service.

As mentioned in the preceding section, ACL resources must first be delivered to groups so that services that use ACL resources can run properly. A device has many predefined groups, but not all groups can meet service requirements. Groups that meet service requirements may occupy different ACL resources. So, how can we select a proper group?

The following uses a simple example to describe the two group selection modes.

Static group selection for implicit services:

Traffic statistics collection is the commonly used maintenance function, which is implemented using ACL. For example, to collect statistics on the traffic received from a VLAN, run the following commands:

# 
vlan 10    
 statistics enable 
#

After VLAN traffic statistics collection is enabled, an ACL rule for matching traffic of VLAN 10 is delivered, and the action is traffic statistics collection.

You can run the display system tcam service brief [ slot slot-id ] command to check whether the VLAN statistics collection service is successfully delivered to group 11.

[~HUAWEI] display system tcam service brief slot 1
Slot: 1                                                       
------------------------------------------------------------------------------ 
 Chip  GroupID    Width      Stage          ServiceName                 Count 
       (FEI/FE)                                                                
------------------------------------------------------------------------------ 
    0     2/2     Quadruple  Ingress        BPDU Deny                      21  
          2/2     Quadruple  Ingress        CPCAR                           5  
          2/2     Quadruple  Ingress        L2 Protocol Tunnel              1  
          3/3     Quadruple  Ingress        App-Session                     3  
          3/3     Quadruple  Ingress        CPCAR                          23 
         11/1     Single     Ingress        VLAN Statistics                 1   
------------------------------------------------------------------------------

Dynamic group selection for the MQC service:

Assume that we need to configure MQC to allow specific TCP packets from VLANIF 10 to pass through.

Configure ACL 3000.

#  
acl number 3000 
 rule 5 permit tcp source 1.1.1.1 0 source-port eq 2048 destination 1.1.1.2 0 destination-port eq 1024 
 rule 10 deny tcp 
#

Configure a traffic classifier that contains ACL 3000.

# 
traffic classifier c_example type or     
 if-match acl 3000 
#

Configure a traffic behavior and set the action to statistics collection.

# 
traffic behavior b_example  
 statistics enable 
#

Configure a traffic policy.

# 
traffic policy p_example 
 classifier c_example behavior b_example precedence 5   
#

Apply the traffic policy to VLANIF 10.

# 
interface vlanif10  
 traffic-policy p_example inbound 
#

In traffic policy p_example, the traffic classifier c_example matches traffic against the IP 5-tuple in ACL 3000, and the action defined in the traffic behavior b_example is statistics collection. The traffic policy is applied to a VLANIF interface. When selecting a group, the device traverses all predefined MQC group templates based on the configured fields, actions, and application view information, and selects a group template that includes all the above conditions and occupies the minimum resources. For example, the device traverses the following MQC group templates and selects group 216.

Run the display traffic-policy applied-record command. The command output shows that the traffic policy p_example is applied successfully.

[~HUAWEI] display traffic-policy applied-record 
Total records : 1 
------------------------------------------------------------------------------- 
Policy Type/Name                 Apply Parameter             Slot   State 
p_example                        Vlanif10 inbound               1   success      
                                                                2   success      
                                                                3   success      
                                                                4   success      
-------------------------------------------------------------------------------

Run the display system tcam service brief [ slot slot-id ] command. The command output shows that the MQC service Traffic Policy VLANIF is delivered to group 216.

[~HUAWEI] display system tcam service brief slot 1 
Slot: 1                                                       
------------------------------------------------------------------------------ 
 Chip  GroupID    Width      Stage          ServiceName                 Count 
       (FEI/FE)                                                                
------------------------------------------------------------------------------ 
    0     2/2     Quadruple  Ingress        BPDU Deny                      21  
          2/2     Quadruple  Ingress        CPCAR                           5  
          2/2     Quadruple  Ingress        L2 Protocol Tunnel              1  
          3/3     Quadruple  Ingress        App-Session                     1  
          3/3     Quadruple  Ingress        CPCAR                          23 
        216/1     Double     Ingress        Traffic Policy VLANIF           2 
------------------------------------------------------------------------------

The preceding information shows that the 5-tuple-based MQC service with the action of statistics collection and the application view of VLANIF interface is delivered to group 216.

According to Table 1-1, if you configure other MQC services, such as the MQC1 service (5-tuple-based, "redirect" action, applied to a VLANIF interface), the MQC1 service is delivered to group 216 without occupying extra KB resources because group 216 also supports the "redirect" action. If the MQC2 service (5-tuple-based, "rate limit" action, applied to a VLANIF interface) is configured, the MQC2 service cannot be delivered to group 216 because group 216 does not support the "rate limit" action. In this case, you need to create a new group and use more KB resources. If the KB resources are exhausted, the MQC2 service will fail to be delivered due to insufficient resources.

If the service prediction result shows that a service can be successfully delivered, you can then configure the service. If the service prediction result shows a service delivery failure, adjust the service deployment mode and use the ACL Service Addition Query Tool for a query until the service delivery result is successful.

If the service prediction result always shows a service delivery failure, further study ACL resources by referring to ACL Technical Topics or contact Huawei technical support for assistance.

CloudEngine 12800, 12800E, 8800, 7800, 6800, and 5800 Series Switches ACL Technical Topics

CloudEngine 12800 and 12800E V200R005C10 ACL Configuration Guide