Security, Segmentation, and Policy Enforcement
Identity-based segmentation
Aruba's story is dynamic segmentation: authenticate the user or device once (802.1X, MAC authentication, or device profiling via ClearPass), assign a role, and enforce that role everywhere. On AOS-CX the enforcement points are port access roles, downloadable user roles from ClearPass, and role-based ACLs that follow the user rather than the port. In the data center the same idea becomes microsegmentation between workloads: role-tagged traffic identified at the VTEP and enforced in hardware, so east–west traffic between two workloads can still be filtered.
Classic controls you still need
ACLs (extended, MAC and role ACLs) applied in the correct direction and place; DHCP snooping and dynamic ARP inspection in Layer 2 segments; storm control; control-plane policing; TACACS+/RADIUS with least-privilege RBAC for administrators; certificates and HTTPS-only REST access; MACsec on links that leave the rack where the platform supports it.
Traps
- Implicit deny at the end of an ACL - return traffic needs its own permit if the ACL is applied in both directions.
- Direction confusion: an ACL applied inbound filters traffic entering that interface from the attached host.
- Assuming port ACLs and role ACLs merge the way you expect; know the precedence for your release.
- A VSX LAG needs identical policy on both peers, or the pair filters asymmetrically.
- Treating segmentation as an overlay-only problem and leaving the underlay unprotected.
Rule of thumb
Ask three questions of any segmentation question: Who is the identity (user, device, workload)? Where is it classified (ClearPass, port, or VTEP)? Where is it enforced (role ACL, port ACL, or fabric policy)? If any answer is 'nowhere', the design is not segmented.