Port security on AOS-CX — MAC lockdown, and four limits to know up front

Notes from reading documentation, not results from testing on a live system. Main source: HPE’s ArubaOS-CX 10.04 Security Guide. Each point carries a page citation at the end; anything that could not be verified is marked.

⚠️ port security and port access are two entirely different features with nearly the same name.

• Port access (its own page) is 802.1X and MAC-Auth: it asks a RADIUS server, there is an identity, there is a role.
• Port security is the switch remembering on its own which MAC addresses are allowed on each port and blocking unknown MACs. It asks no one, and there is no user identity.

Because it asks no one, port security is only a low-level layer of port protection. This note covers what it concretely does and — more importantly — four places where it does not protect¹.

Details

Three knobs, and what each one implies

Configured per port¹:

Knob	What you choose	Worth remembering
Action	when an intruder is detected, send an SNMP trap to the management station, and/or shut the port down	⚠️ The default is to NOT shut the port down — see below; this is a deliberate choice, not an oversight
Address limit	number of MACs allowed on the port	The ceiling for secure MACs is 64; a manually configured MAC list holds at most 8 devices
Address learn mode	how the port gets its MAC list	three modes, see right below

The three learning modes¹:

• Static — set a MAC ceiling, configure part of the list by hand, and the port learns the rest from incoming traffic.
• Configured — every MAC must be configured; the port is not allowed to learn from traffic.
• Port access — only accepts MACs of devices authenticated via 802.1X, i.e. it hands the decision to port access.

Author’s note (unverified): The practical point: static is convenient to set up, but it means “whichever device plugs in first gets recorded as legitimate”. An attacker who plugs into a port that has not reached its MAC count gets learned into the list — entirely by the book. Configured takes effort, but it is the only real allowlist.

⚠️ Four limits — read before relying on this feature

1. Blocking traffic without shutting the port is the default behavior. Unless you explicitly configure a shutdown, the switch only blocks unauthorized traffic and keeps the port running¹. This is a sensible design — it is what lets you apply port security to a port with a hub or small switch hanging off it, so legitimate users can keep working.

Author’s note (unverified): the consequence is that the incident does not surface on its own. Nobody drops off the network, nobody calls support; without SNMP traps enabled and someone reading the logs, an unknown device can be blocked for months and nobody will know someone plugged it in.

2. ⚠️ Broadcast and multicast are ALWAYS let through. The documentation says it plainly: an intruder plugged into a port with port security enabled can still read broadcast and multicast traffic¹.

Author’s note (unverified): that means it can still collect a fair amount of information about the network — who is talking, device discovery protocols, host names — while the dashboard shows “port protected”.

3. ⚠️ Port security does NOT run on trunk groups, and is silently wiped when the port is added to a trunk. The documentation states two things clearly¹:

Port security does not work on static or dynamic trunk groups. A port configured with port security that is later added to a trunk group has its port security parameters reset to factory defaults by the switch.

A port configured for LACP Active or Passive that is not yet a member of any trunk can still use port security — the line is whether it has joined a trunk, not whether LACP is configured¹.

Author’s note (unverified): this is the most dangerous of the four limits, because it breaks the security configuration as a side effect of something else. Whoever bundles two ports into a LAG for bandwidth does not think they just removed security; the old configuration is no longer there for anyone to see.

4. No identity. Port security only remembers MACs; it asks no one. See anti-spoofing MAC-Auth with profiling.

Author’s note (unverified): MACs are easy to spoof; even MAC-Auth (which does ask RADIUS) needs profiling to resist spoofing, so port security (which asks no one) resists it even less.

Dynamic ARP protection — the companion feature, and the trusted-port rule

In the same chapter as port security, the documentation covers dynamic ARP protection. Two design rules worth remembering¹:

• Ports that connect to other switches in the network are configured as trusted ports, so switches can exchange ARP and update their ARP tables with valid information.
• ⚠️ Switches that do NOT support dynamic ARP protection must be moved into a separate L2 domain, separated by a router. The mechanical reason: ARP packets do not cross an L3 boundary, so an unprotected switch will not accidentally take in an attacker’s ARP and forward it to a protected switch through the trusted port itself. Configuring a port toward an unsupported switch as trusted opens the door to ARP poisoning from the machines behind it.

Background on this kind of attack: man-in-the-middle attacks and L2/L3 protocol protection on AOS-CX.

Related

• Tuning port access on AOS-CX — the mechanism with RADIUS and identity; and MAC-Auth excludes port security on the same port

Sources

Unverified. The source documents release 10.04. Later AOS-CX releases may have changed the MAC ceiling, default behavior or the trunk rules — check against the running release before relying on specific numbers. The reset-on-trunk rule in particular is worth re-checking first.

Footnotes

1. ArubaOS-CX 10.04 Security Guide (6300, 6400 Switch Series) — official HPE product documentation, chapter 17, PDF pp. 248–251 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸