HPE Aruba Switching Expert (Written, HPE7-A06) study materials
HPE Aruba Switching Expert (Written, HPE7-A06) study resources

802.1X and MPSK Coexistence on a Mixed-Fleet Floor

HPE Aruba Switching Expert (Written, HPE7-A06) · Put your knowledge to work in context.

All case studies

802.1X and MPSK Coexistence on a Mixed-Fleet Floor

A hospital wing has Aruba CX 6300 access switches managed by Aruba Central, with ClearPass as RADIUS. Wired ports serve three populations: managed clinical workstations (802.1X, EAP-TLS), biomedical devices that cannot do 802.1X (need MPSK), and guest printers on a shared VLAN. The security team enabled 802.1X with client-limit 1 and MAC authentication as a fallback on all access ports. Within a week, biomedical devices intermittently fail authentication and land in the guest VLAN, and some clinical workstations are bounced when a second device (a daisy-chained monitor) appears on the port. ClearPass shows Access-Challenge loops for the biomedical devices.

1. Diagnose the two failure modes and propose a port-level authentication profile that serves all three populations without weakening security.

Read the worked answer

Failure mode 1 - biomedical devices: With client-limit 1 and MAC-auth fallback, the MPSK-capable devices are being driven into 802.1X first. Because they cannot complete EAP, ClearPass issues repeated Access-Challenge, and the port never cleanly falls through to MAC-auth/MPSK before the client-limit is consumed. Result: device lands in guest VLAN.

Failure mode 2 - clinical workstations: A daisy-chained monitor presents a second MAC on the same port. client-limit 1 rejects the second client, and depending on auth-mode the port can re-authenticate and bounce the primary workstation.

Proposed profile (per port-role):

  • Clinical workstation ports: aaa authentication port-access dot1x authenticator, mac-auth, with client-limit 2 (or multi-domain so voice/data style separation is allowed), and auth-mode client-mode with mac-auth as fallback only after 802.1X fails.
  • Biomedical ports: dedicated port-role that runs MPSK (aaa authentication port-access mac-auth with MPSK) and disables dot1x on those ports, so no Access-Challenge loop.
  • Guest/printer ports: MAC-auth to guest VLAN role, no dot1x.

Security guardrails: keep client-limit explicit per role, enable auth-fail-vlan only for the biomedical role, and ensure MPSK keys are rotated via Central. Do not globally raise client-limit - scope it to the workstation role.

2. How would you verify the fix and what ClearPass-side evidence would confirm correct behavior?

Read the worked answer

On the switch (CX):

  • show port-access clients - confirm each MAC gets the expected role and VLAN.
  • show port-access authenticator interface <port> - confirm 802.1X vs MAC-auth method actually used.
  • show port-access role and show aaa authentication port-access interface <port> - confirm the port-role applied.
  • Check for Access-Challenge storms in show logging -r on the switch.

On ClearPass:

  • Access Tracker should show a single successful service match per device, with the correct enforcement profile (role/VLAN).
  • No repeated Access-Challenge for the biomedical MACs - they should match the MPSK/MAC-auth service directly.
  • For workstations, the second MAC (monitor) should either be ignored or matched to a restricted role, not trigger a re-auth of the primary.

Success criteria: biomedical devices consistently in their device VLAN; workstations not bounced when the monitor appears; guest printers isolated. If any device still loops, capture a RADIUS trace and confirm the service ordering in ClearPass puts MPSK/MAC-auth ahead of dot1x for that device group.