![]() |
![]() |
The entry of ACL rules via the CLI, Web or Avaya Policy Manager does not encourage or enforce any checking beyond correct syntax. The general guideline is that you are configuring a Layer-3 switch, not a firewall. The following are some guidelines for designing safe, efficient ACLs and how they affect performance:
The wildcard feature is convenient but can dramatically increase the number of flows that the switch identifies. Since the standard ACL implies "any" for the destination, use standard ACLs with care. The wildcard should match a specific set of addresses.
Pushing the ACL-to-packet matching up one or two levels of the IP stack refines the granularity of the flows to be very specific in what is matched. A source-port range can cause a large number of "micro" flows to be created. For more information on using protocol and port identifiers in access rules, see Configuring Hash Mode.
You can, however, use ACLs to block protocol or port access to specific interfaces on the switch. For more information, see Configuring Hash Mode.
The number of rules has a direct impact on the CPU effort to match rules to Flows. This is especially true when there is a high frequency of packets that are "walked down" the entire list and don't match any rules.
The goal is to place the most frequently matched rules toward the beginning of the ACL. This requires a good knowledge of traffic patterns. This can be noticeable as ACLs get longer.
This include routing updates (unicast for RIP 1, multicast for RIP 2), SNMP (MSNM, HPOV), LDAP (for Avaya Policy Manager). Not doing this can cause loss of management connectivity.
![]() |
![]() |