ArubaOS-CX 802.1X Port Access: RADIUS, MAB and Roles - 夜莺博客

ArubaOS-CX 802.1X Port Access: RADIUS, MAB and Roles

ArubaOS-CX treats port-based access control as a single feature called port access, and it is broader than classic 802.1X: the same framework handles supplicant authentication, MAC authentication bypass (MAB), downloadable user roles from ClearPass, device profiles from Aruba Central and the fallback policy used when every RADIUS server is unreachable. This article shows the configuration in the order you actually type it, with the precedence rules and client limits that decide whether a laptop, an IP phone and a headless camera can all live on the same switch port.

Port access building blocks

Five objects make up an ArubaOS-CX port access deployment:

  1. RADIUS server group — the ordered list of authentication servers plus the shared secret.
  2. Global AAA mode — which methods are available (dot1x, MAC auth) and how fail-through is handled.
  3. Interface configuration — per-port authentication methods, precedence, client limit and BPDU allowances.
  4. Local user roles — what a device is allowed to do, either pushed by the server via filter-id or defined locally.
  5. Critical role — the policy applied when all RADIUS servers are down, so an outage does not lock out the building.

Step 1 — RADIUS server group

Switch(config)# aaa group server radius AAA-RADIUS
Switch(config-sg)# server tmeswitching1.aaa
Switch(config-sg)# server tmeswitching2.aaa
Switch(config-sg)# server tmeswitching3.aaa
Switch(config-sg)# exit

Switch(config)# radius-server host tmeswitching1.aaa key plaintext <shared-secret>
Switch(config)# radius-server host tmeswitching2.aaa key plaintext <shared-secret>
Switch(config)# ip source-interface radius 10.10.10.20 vrf mgmt

The server order defines priority. The ip source-interface statement matters more than it looks: the RADIUS server identifies the switch by source IP, so a mismatched source interface produces silent drops rather than authentication failures in the logs.

Step 2 — global authentication settings

Switch(config)# aaa authentication allow-fail-through
Switch(config)# aaa authentication port-access dot1x authenticator radius server-group AAA-RADIUS
Switch(config)# aaa authentication port-access dot1x authenticator enable
Switch(config)# aaa authentication port-access mac-auth radius server-group AAA-RADIUS
Switch(config)# aaa authentication port-access mac-auth enable
Switch(config)# radius dyn-authorization enable
Switch(config)# aaa accounting port-access start-stop interim 15 group AAA-RADIUS

allow-fail-through lets the switch try the next method when a server rejects rather than only when it is unreachable. Change of authorization is what enables dynamic re-profiling without a port bounce. Interim accounting at 15 minutes keeps session tables accurate enough for per-device ACL roles.

Step 3 — per-port configuration

Switch(config)# interface 1/1/1
Switch(config-if)# no shutdown
Switch(config-if)# aaa authentication port-access auth-precedence mac-auth dot1x
Switch(config-if)# aaa authentication port-access client-limit 3
Switch(config-if)# aaa authentication port-access allow-cdp-bpdu
Switch(config-if)# aaa authentication port-access allow-lldp-bpdu
Switch(config-if)# aaa authentication port-access dot1x authenticator
Switch(config-if-dot1x-auth)# max-eapol-requests 3
Switch(config-if-dot1x-auth)# max-retries 2
Switch(config-if-dot1x-auth)# quiet-period 30
Switch(config-if-dot1x-auth)# exit
Switch(config-if)# aaa authentication port-access mac-auth
Switch(config-if-macauth)# enable
Switch(config-if-macauth)# end

Two design points are worth pausing on. First, precedence: listing mac-auth dot1x lets printers and cameras authenticate by MAC instantly while Windows laptops still complete 802.1X. Second, client-limit: a port with a downstream unmanaged switch needs a limit above 1, otherwise the second device causes an authentication bounce that looks like a flapping link.

Step 4 — critical role for server outages

Switch(config)# class ip INTERNAL
Switch(config-class-ip)# 10 match any 10.0.0.0/8
Switch(config-class-ip)# 20 match any 192.168.0.0/16
Switch(config-class-ip)# 30 match any 172.16.0.0/12
Switch(config-class-ip)# exit

Switch(config)# port-access policy AAA-DOWN-ACL-ALLOW
Switch(config-pa-policy)# 10 class ip INTERNAL action drop
Switch(config-pa-policy)# 20 class ip ALL
Switch(config-pa-policy)# exit

Switch(config)# port-access role AAA-DOWN
Switch(config-pa-role)# associate policy AAA-DOWN-ACL-ALLOW
Switch(config-pa-role)# exit

Switch(config)# interface 1/1/1
Switch(config-if)# aaa authentication port-access critical-role AAA-DOWN

This is the pattern that keeps guests on the internet while internal resources stay protected during a RADIUS outage: quarantine RFC1918, permit everything else.

Verification

Switch# show port-access clients
Switch# show port-access clients interface 1/1/1 detailed
Switch# show port-access role
Switch# show aaa authentication port-access interface all
Switch# show radius-server statistics
Switch# show port-access policy

show port-access clients is the workhorse — it names the authenticated MAC, the method (dot1x or mac-auth), the assigned role and the port. During a failed rollout, compare the role the server returned against the local role table: a role-name mismatch leaves the client authenticated but unconstrained.

Failure patterns worth memorising

  • Laptop authenticates but cannot reach anything: the server returned a role the switch does not know; the fallback becomes deny-all.
  • Camera never authenticates: MAC address not registered in the MAB directory, or dot1x precedence placed first and the camera stalled at EAPOL.
  • Port resets every 30 seconds: client-limit 1 with a downstream switch; raise the limit or disable enforcement for that port.
  • Auth works but CoA changes do nothing: radius dyn-authorization missing, or UDP 3799 blocked to the switch source interface.

Choosing between 802.1X, MAB and device profiles

Not every device can run a supplicant, and that is why ArubaOS-CX exposes three authentication paths on the same port. Choosing the right one per device class prevents the two classic outcomes: unauthenticated devices stranded on a quarantine VLAN, or authentication disabled entirely because "the printers do not work".

Device class Recommended method Why
Corporate laptops with a managed OS 802.1X with EAP-TLS Certificate-based, per-user identity, supports CoA and role changes
Printers, cameras, badge readers MAB in parallel, lower precedence No supplicant, but a registered MAC is a workable identity
IP phones with a PC passthrough 802.1X plus LLDP-based device profile Voice device is authenticated while the attached PC authenticates separately (client limit > 1)
Guest / BYOD MAB to a captive portal role Known MAC gets network access, internet only, until portal completion
IoT with no identity Port-based role with a strict ACL Accept that the port is the identity, restrict it accordingly

The precedence statement is what encodes this: auth-precedence mac-auth dot1x means MAB is attempted first, and this is usually the right order on mixed ports because it produces the fastest successful authentication for headless devices, with 802.1X still available for supplicants.

Rollout sequence that avoids a support ticket storm

  1. Inventory first. Collect MAC addresses of every device on ports you plan to convert, and register them in the RADIUS/NAC side before enabling enforcement.
  2. Monitor mode on a pilot switch. Configure port access but keep the fail policy permissive (no critical role restrictions), and watch show port-access clients to see who authenticates and who does not.
  3. Fix exceptions. Devices that fail MAB are usually unregistered MACs, or they use randomised MAC addresses that change per reboot — identify that early rather than during the rollout.
  4. Enable enforcement per floor. Convert one access switch at a time, with a documented rollback command set.
  5. Turn on critical roles last. The AAA-DOWN policy should be tested by deliberately unreachable RADIUS servers in a lab, because discovering a bad ACL during a real outage multiplies the impact.

Each step needs an out-of-band path. A port-access mistake on an uplink or on the switch's own management port locks out the person fixing it, which is why changes to management ports are worth doing over a console session.

Radius, CoA and accounting: what to watch

Switch# show radius-server statistics
Switch# show port-access clients interface 1/1/1 detailed
Switch# show port-access policy
Switch# show aaa authentication port-access interface 1/1/1
Switch# show accounting session
  • Attribute mismatches are the leading cause of "authenticated but wrong access". Check which attributes the server returns (filter-id, Aruba-User-Role, tunnel attributes) and how the switch maps them to a role.
  • CoA needs UDP 3799 open from the RADIUS server to the switch's configured source IP, and radius dyn-authorization enable. Without it, policy changes require re-authentication.
  • Accounting session tables are what make per-device role auditing possible; verify interim updates arrive rather than only start/stop records, or stale sessions accumulate after abrupt disconnects.
  • Auth-fail VLAN behaviour should be explicit. Decide in advance whether a failed authentication drops the port into a restricted VLAN, applies a limited role, or blocks traffic entirely.

Related configuration guides

Port access usually sits next to strict port security controls; see ArubaOS-CX port security, MAC lockout and client limits. If you are still deciding what the port's L2 mode should be before adding authentication, start with ArubaOS-CX access versus trunk port comparison. On the layer-2 filtering side, ArubaOS-CX DHCP snooping configuration complements port access nicely.

原文链接:https://arubanetworking.hpe.com/techdocs/AOS-CX/10.16/HTML/security_5420-6200-6300-6400/Content/Chp_Port_acc/PortAcc8021x+MAC_CfgEg.htm