ArubaOS-CX ACL Configuration: Build, Apply and Verify

ACLs on ArubaOS-CX look Cisco-like but the plumbing differs in three places that catch engineers out: ACLs are created with a numeric range of sequence numbers rather than editing a numbered list line by line, application is a separate second step, and hit counts must be enabled before they show anything. This runbook covers the three ACL families, object groups, applying to an interface, a VLAN and the control plane, resequencing and safe editing, and the verification commands that prove the ACL is actually matching traffic.

ACL families on ArubaOS-CX

• IPv4 ACL - access-list ip <name>; matches source and destination address, protocol, ports and fields.
• IPv6 ACL - access-list ipv6 <name>; same structure with IPv6 source and destination.
• MAC ACL - access-list mac <name>; matches Layer 2 fields such as source and destination MAC, EtherType and VLAN.
• Control-plane ACL - a normal ACL applied with the control-plane keyword, used for CoPP-style management protection.

An ACL is only a definition. Nothing filters until it is applied, and the same definition can be applied to several interfaces, VLANs or the control plane at once. That separation is deliberate - it lets you build and review a policy before it takes effect - but it is also the reason "I created the ACL and it does nothing" is such a common report.

Create the ACL

switch(config)# access-list ip MGMT-ONLY
switch(config-acl-ip)# 10 permit tcp 10.10.10.0/24 any eq 22
switch(config-acl-ip)# 20 permit icmp 10.10.10.0/24 any
switch(config-acl-ip)# 30 deny any any log
switch(config-acl-ip)# exit

Each line is addressed by its sequence number, so inserting rules later means choosing a free number in the gap - resequencing with access-list resequence MGMT-ONLY 10 10 keeps room available. The implicit deny at the end of an ACL is implicit only in the sense that it is not displayed: write the explicit deny yourself whenever you need logging.

Address and Port Object Groups

switch(config)# object-group address SERVERS
switch(config-addrgroup)# 10.10.20.10/32
switch(config-addrgroup)# 10.10.20.11/32
switch(config-addrgroup)# exit
switch(config)# access-list ip APP-POLICY
switch(config-acl-ip)# 10 permit tcp any SERVERS eq 443

Object groups are the CX answer to long, unreadable ACLs: the rule list stays short and the address list is maintained in one place, which also makes audits tractable. Port object groups work the same way for service families, and both can be reused across IPv4 and IPv6 ACLs where the address family matches.

switch(config)# object-group port WEB
switch(config-portgroup)# 80
switch(config-portgroup)# 443
switch(config-portgroup)# exit
switch(config)# access-list ip EDGE-IN
switch(config-acl-ip)# 10 permit tcp any any WEB

Apply to Interface, VLAN or Control Plane

switch(config)# interface 1/1/1
switch(config-if)# apply access-list ip MGMT-ONLY in
switch(config-if)# exit
switch(config)# apply access-list ip GUEST-DENY vlan 30 in
switch(config)# apply access-list ip COPP-EDGE control-plane

Interface and VLAN application are independent of the ACL definition, so an ACL can be created, tested on one port, then rolled to a VLAN. Control-plane application is how you build CoPP-style protection for management protocol traffic - apply it deliberately, because a control-plane ACL that is too aggressive also blocks your SSH session.

Direction, placement and where the ACL is evaluated

The in and out keywords describe the direction relative to the switch, not relative to the traffic's intent. in filters frames arriving on the interface or VLAN; out filters frames leaving it. Getting this backwards is the single most common reason a correct-looking rule never matches. A few consequences worth internalising:

• A port ACL applies to all traffic on the port, whether the port is access, trunk or part of a LAG.
• A VLAN ACL applies to traffic within that VLAN as it is bridged or routed, so it can filter east-west traffic between hosts that never leave the switch.
• A routed ACL needs the traffic to actually be routed - if the source and destination sit in the same VLAN and are just bridged, a routed filter on the SVI will not see it.
• On a LAG, apply the ACL to the LAG interface, not to individual members, so the policy does not diverge across members.
• ACLs applied in both directions on the same interface are evaluated independently; do not assume one trip through the list.

Implicit deny, logging and explicit rules

Every ACL ends with an implicit deny that is not shown in the configuration. That is fine for a security policy but terrible for troubleshooting, because a packet that matches no rule vanishes with no counter. Write the final deny explicitly with log so you can see it, and remember that log has a rate limit - a busy deny rule will log a sample, not every packet. Where you need visibility without a log flood, use hit counts on the specific rules instead.

switch(config-acl-ip)# 30 deny any any log
switch(config-acl-ip)# 40 deny any any count

IPv6 and MAC ACL examples

The IPv6 and MAC families use the same sequence-number and object-group machinery, with family-specific match fields. An IPv6 edge policy that permits management and neighbour discovery while denying the rest looks like this:

switch(config)# access-list ipv6 EDGE-V6
switch(config-acl-ipv6)# 10 permit icmpv6 any any
switch(config-acl-ipv6)# 20 permit tcp 2001:db8:10::/64 any eq 22
switch(config-acl-ipv6)# 30 deny any any count
switch(config-acl-ipv6)# exit

MAC ACLs are the tool when the client address is not yet known - for example blocking a specific device before it has an IP, or enforcing a Layer 2 policy in a VLAN that is bridged and never routed:

switch(config)# access-list mac BLOCK-KNOWN-BAD
switch(config-acl-mac)# 10 deny 00:11:22:33:44:55 any
switch(config-acl-mac)# 20 permit any any
switch(config-acl-mac)# exit
switch(config)# interface 1/1/1
switch(config-if)# apply access-list mac BLOCK-KNOWN-BAD in

Remember that a MAC ACL matches on frames, so it cannot see past a router, and that it also matches the switch's own control traffic on that port unless you exclude it.

Hit Counts and Verification

switch(config)# access-list ip MGMT-ONLY
switch(config-acl-ip)# hitcounts
switch(config-acl-ip)# exit
switch(config)# end
switch# show access-list ip MGMT-ONLY
switch# show access-list hitcounts ip MGMT-ONLY
switch# clear access-list hitcounts ip MGMT-ONLY
switch# show access-list secure-update

Hit counts are off until you turn them on per ACL. When a rule is not matching, check three things in order:

• direction - in versus out on the interface or VLAN;
• whether an ACL applied earlier in the path is already dropping the packet;
• whether the traffic is routable at all, since an SVI has to be up for routed ACL matching. That is where access versus trunk port modes and VSF stack member numbering become relevant: after a stack change, interface names referenced by an applied ACL do not follow a member that renumbers.

CoPP and Control-Plane Protection

Applying an ACL to the control plane is how you protect the switch's own CPU from a flood of ARP, ICMP, DHCP or routing protocol traffic. Treat it as a production change with a rollback plan: a control-plane ACL that denies too much removes your management access, and if you apply it over SSH you may be cutting the branch you are sitting on. Build the policy in a maintenance window, permit your management sources first, and keep an out-of-band console.

switch(config)# access-list ip COPP-EDGE
switch(config-acl-ip)# 10 permit tcp 10.10.10.0/24 any eq 22
switch(config-acl-ip)# 20 permit udp any any eq 67
switch(config-acl-ip)# 30 permit icmp any any
switch(config-acl-ip)# 40 deny any any count
switch(config-acl-ip)# exit
switch(config)# apply access-list ip COPP-EDGE control-plane

A typical building block is a per-protocol policer rather than a blanket deny: allow the protocol at a sane rate, drop the excess, and let hit counts tell you which protocol is misbehaving. Related hardening guidance sits alongside DHCP snooping and trusted ports and VRRP and active gateway design.

Editing, Resequencing and secure-update

CX gives you two ways to edit a live ACL, and they differ in risk. Line-by-line editing with sequence numbers is precise but slow; access-list secure-update controls the safe-edit behaviour that stages changes so the list is never left in a partial state on a failure. When you need to flush a policy back to empty without deleting it - a maintenance-window requirement, because re-applying an empty ACL is faster than deleting and recreating it everywhere - use access-list reset.

switch(config)# access-list resequence MGMT-ONLY 10 10
switch(config)# access-list secure-update
switch(config)# access-list reset ip MGMT-ONLY

Resequencing is worth doing as housekeeping: rules added in a hurry over months leave no gaps, and the next insertion forces a re-read of the whole list. Decide a numbering convention (tens for new policies, fives for insertions) and document it, so the next engineer does not have to renumber under pressure.

ACLs and VSX / VSF

On a VSX pair, ACLs are configured independently on each peer. Nothing synchronises the policies, so a failover can move traffic onto a switch whose ACL is stale or missing. Keep the definitions identical by template or automation, and include the ACL configuration in the check that runs after every change. On a VSF stack, the same caution applies in a different form: ACLs are stack-wide, but the interface names they reference depend on member numbering, so a renumbering after a member replacement can silently point a policy at the wrong port.

Troubleshooting Checklist

1. show access-list ip <name> - is the rule present, and is it in the order you expect?
2. show access-list hitcounts ip <name> - after enabling hit counts, which rules increment?
3. Confirm the direction (in/out) and the attachment point (interface, VLAN, control plane).
4. Check whether the traffic is routed or bridged at the point you are filtering.
5. Look for a second ACL earlier in the path that is already dropping the frame.
6. Check show running-config for the applied statement - an unapplied ACL is a common false alarm.

Finally, access-list secure-update and access-list reset control how the running ACL is edited and cleared, which is useful in maintenance windows when you need to flush a policy back to its empty state without deleting it.

原文链接：https://arubanetworking.hpe.com/techdocs/AOS-CX/10.13/PDF/cli_6000-6100.pdf