Study guide
10.1 The AAA Framework and Architecture
HPE Aruba Networking Certified Associate - Campus Access HPE6-A85
Track your progress as you read
Finished sections get a check mark.
1 Introduction: HPE6-A85 Exam Overview
HPE6-A85 Exam Facts and Current Blueprint
2 Chapter 1: Network Stack Fundamentals
1.1 OSI Reference Model and Encapsulation 1.2 TCP/IP Protocol Suite and IP Headers 1.3 Layer 2 Operation, ARP, and 802.1Q Tagging
3 Chapter 2: Physical Connectivity and Host Addressing
2.1 Ethernet Media and Transceiver Standards 2.2 Power over Ethernet (PoE, PoE+, PoE++) Standards and Budgeting 2.3 LLDP, LLDP-MED, and Voice VLAN Configuration 2.4 Host IP Addressing and DHCP Relay Operations
4 Chapter 3: Network Resiliency and Virtualization
3.1 Virtual Switching Framework (VSF) Architecture and Topologies 3.2 VSF Split Detection, Failover, and Auto-Stacking 3.3 Virtual Switching Extension (VSX) Architecture and Operations 3.4 High-Availability Gateways: VRRP and VSX Active-Gateway
5 Chapter 4: AOS-CX Architecture and Switch Operation
4.1 AOS-CX Hardware Portfolio and State Database Architecture 4.2 Network Analytics Engine (NAE) and Automated Telemetry 4.3 AOS-CX Interface Configuration and Port Control 4.4 Link Aggregation (LAG) and LACP Configuration
6 Chapter 5: Layer 2 Protocols and Spanning Tree
5.1 AOS-CX VLAN Configuration and Native VLAN Handling 5.2 Spanning Tree Protocols: STP, RSTP, and MSTP 5.3 Spanning Tree Protections and Loop Prevention 5.4 MAC Address Table Learning, Aging, and Forwarding
7 Chapter 6: Wireless Fundamentals, Standards, and RF
6.1 IEEE 802.11 Standards and Wi-Fi Generations 6.2 RF Fundamentals, Signal Propagation, and Channel Design 6.3 Aruba Access Point Hardware Portfolio and Suffix Conventions 6.4 WLAN Topologies, BSSID/ESSID, and Roaming Standards
8 Chapter 7: Aruba Wireless Architecture and Management
7.1 AOS 10 Architecture and Aruba Central Integration 7.2 Wireless Forwarding Modes: Bridge vs Tunnel Mode 7.3 Automated RF and Client Optimization: AirMatch and ClientMatch 7.4 Secure Wireless Access: WPA3, SAE, and MPSK Implementation
9 Chapter 8: IP Routing Fundamentals and OSPF
8.1 IP Routing Principles and Packet Forwarding 8.2 OSPFv2 Protocol Mechanics and Adjacency Formation 8.3 OSPF Designated Routers and Multi-Area Deployments 8.4 ECMP, Static Routing, and VRF Isolation
10 Chapter 9: Campus Network Security and Segmentation
9.1 DHCP Snooping and Dynamic ARP Inspection 9.2 Port Security and MAC Address Limiting 9.3 ClearPass Policy Management and RADIUS Change of Authorization 9.4 Dynamic Segmentation, User-Based Tunneling, and Policy Enforcement
11 Chapter 10: Authentication, Authorization, and Accounting
10.1 The AAA Framework and Architecture 10.2 802.1X Authentication and EAP Methods 10.3 MAC Authentication and Captive Portal Onboarding 10.4 Administrative Access Control: RADIUS vs TACACS+
12 Chapter 11: Network Management and Telemetry
11.1 Aruba Central Cloud Architecture and Group Configuration 11.2 Zero-Touch Provisioning (ZTP) and Aruba Activate 11.3 AI Insights and Aruba User Experience Insight (UXI) 11.4 Network Telemetry, Streaming APIs, and SNMP/Syslog
13 Chapter 12: Troubleshooting the Solution
12.1 Structured Troubleshooting Methodologies and Scope Isolation 12.2 AOS-CX Layer 2 and Interface Diagnostic Commands 12.3 Layer 3, IP Services, and End-to-End Diagnostics 12.4 Physical-Layer Troubleshooting 12.5 Troubleshooting Wireless Clients and Network Access
14 Chapter 13: Optimizing Performance: QoS, Baselines, and Comparisons
13.1 Quality of Service (QoS) Classification and Marking 13.2 Queuing Algorithms and Congestion Management 13.3 Traffic Policing, Shaping, and Broadcast Rate Limiting 13.4 Establishing a Performance Baseline 13.5 Comparing Results to the Baseline
15 Chapter 14: Plan the Solution
14.1 Analyzing the Current Environment 14.2 Interpreting an Architect's High-Level Design 14.3 Creating a Low-Level Design 14.4 Preparing for Implementation
16 Chapter 15: Validate and Operate the Solution
15.1 Validating the Solution 15.2 Performing Firmware Updates 15.3 Making Basic Ongoing Configuration Changes 15.4 Maintaining Network Documentation
10.1 The AAA Framework and Architecture
Key Takeaways Explain This Topic AI
The AAA security framework decouples network access control into three distinct operational pillars: Authentication (verifying identity), Authorization (enforcing policy and resource privileges), and Accounting (logging session activity and resource utilization).
IEEE 802.1X establishes a tripartite access control architecture comprising the Supplicant (client endpoint), Authenticator (AOS-CX access switch or Aruba AP), and Authentication Server (Aruba ClearPass Policy Manager or RADIUS server).
EAP encapsulation shifts at the Authenticator: Extensible Authentication Protocol packets travel over Layer 2 Ethernet as EAPOL (IEEE 802.1X) on the access link and are translated into RADIUS UDP datagrams traversing the routed IP core to the authentication server.
The Authenticator enforces port security using a dual-port model with an uncontrolled port (which permits only EAPOL traffic prior to authentication) and a controlled port (which blocks all data traffic until authorization succeeds).
Aruba AOS-CX switches apply dynamic authorization by assigning User Roles returned in RADIUS Access-Accept messages via the Aruba-User-Role VSA, mapping authenticated clients to specific VLANs, ACLs, and QoS profiles.
Last updated: October 2026
The AAA Framework and Architecture
Quick Summary: The AAA security framework underpins enterprise access control by dividing network security into three discrete functions: Authentication (validating identity), Authorization (granting resource permissions), and Accounting (recording user activity). In campus LANs, this framework is operationalized through IEEE 802.1X port-based network access control , which deploys a three-party architecture consisting of the Supplicant (endpoint), the Authenticator (AOS-CX switch), and the Authentication Server (ClearPass). By bridging Layer 2 EAPOL frames at the switch edge with IP-based RADIUS datagrams upstream, enterprise switches dynamically enforce granular User Roles , micro-segmenting authenticated devices without requiring static port reconfigurations.
The Tripartite AAA Security Model
In modern enterprise networks, granting physical switch port connectivity must not equate to granting unrestricted network access. The AAA framework decouples identity management and policy enforcement into three structured operational pillars: +---------------------------------------------------------------------------------------------------------+
- | THE AAA SECURITY FRAMEWORK PILLARS |
- | |
- | [ 1. AUTHENTICATION ] ---------> "Who are you?" |
- | Validates identity using credentials, PKI digital certificates, |
- | or hardware tokens before permitting Layer 2 admission. |
- | |
- | [ 2. AUTHORIZATION ] ----------> "What are you allowed to do?" |
- | Assigns dynamic network privileges: VLAN membership, ingress ACLs, |
- | bandwidth contracts, and User Roles based on user context. |
- | |
- | [ 3. ACCOUNTING ] -------------> "What did you do, and for how long?" |
- | Records session metrics: start/stop timestamps, framing IP, |
- | packet/byte counters, and termination reasons for audit compliance. |
- +---------------------------------------------------------------------------------------------------------+
- 1. Authentication (AuthN)
Authentication answers the fundamental question: "Who is attempting to access the network?" The system verifies claimed identity assertions before granting admission to enterprise transport infrastructure. Authentication methods include:
Cryptographic Credentials: Passwords, passphrases, or challenge-response hashes (MS-CHAPv2).
Digital Certificates: X.509 certificates validating public-key cryptographic assertions (EAP-TLS).
Layer 2 Hardware Identifiers: Media Access Control (MAC) addresses (MAC-Auth for headless IoT).
Interactive Captive Portals: Web-based forms capturing guest sponsor details or temporary vouchers.
2. Authorization (AuthZ)
Authorization answers the conditional policy question: "What network services and assets is this authenticated identity permitted to consume?" Once identity is validated, the authentication server evaluates contextual attributes (device health, time of day, connection medium, physical location) and issues an enforcement profile to the switch. In Aruba architectures, authorization attributes dynamically program:
Dynamic VLAN Assignment: Placing an unmanaged contractor device into a quarantine or guest VLAN.
User Roles: Assigning an AOS-CX local or dynamic user role containing tailored access control lists (ACLs).
Quality of Service (QoS): Enforcing rate-limiting policies or marking DSCP/802.1p priorities.
User-Based Tunneling (UBT): Directing client traffic across a GRE tunnel to an Aruba Mobility Gateway for deep stateful packet inspection.
3. Accounting (Acct)
Accounting answers the operational audit question: "What did the user do, when did they connect, and what resources did they consume?" Accounting tracks user sessions by generating audit records transmitted via RADIUS accounting packets (RFC 2866):
Accounting-Start: Generated the moment the client port is authorized, recording the client MAC, assigned IP address, switch port, and session identifier.
Interim-Update: Periodically transmitted (e.g., every 600 seconds) to report elapsed connection duration, active IP configuration, and cumulative byte/packet counters.
Accounting-Stop: Generated when the client disconnects, link flaps, or times out. This record documents total bytes sent, total bytes received, session duration, and the specific termination cause (e.g., User-Request , Lost-Carrier , Admin-Reset ).
The IEEE 802.1X Architectural Triad
The IEEE 802.1X standard defines port-based network access control (PNAC) for local area networks. It establishes a secure perimeter at the network edge by requiring client authentication prior to forwarding standard unicast or broadcast traffic. The standard mandates three distinct architectural entities: +---------------------------------------------------------------------------------------------------------+
- | IEEE 802.1X ARCHITECTURAL TRIAD |
- | |
- | [ Supplicant ] [ Authenticator ] [ Authentication Server ] |
- | (Workstation / NIC) (AOS-CX Access Switch) (ClearPass Policy Manager) |
- | | | | |
- | | <==== EAPOL over Ethernet ===> | <======== EAP inside RADIUS ======> | |
- | | (Layer 2 PAE Frame: 0x888E) | (UDP Port 1812 over IP) | |
- | | | | |
- | +---- Uncontrolled Port (Open) --+ | |
- | +---- Controlled Port (Closed) --+ | |
- +---------------------------------------------------------------------------------------------------------+
- 1. The Supplicant
The Supplicant is the client software entity running on the endpoint seeking network admission (such as a laptop, workstation, smartphone, or corporate tablet). The supplicant responds to requests from the authenticator to verify identity.
Native Supplicants: Built directly into modern operating systems (Microsoft Windows 802.1X supplicant, macOS Network framework, Apple iOS, Android, and Linux wpa_supplicant ).
Supplicant Responsibilities: Negotiates EAP types, validates server certificates against local trusted root stores, retrieves user/machine credentials, and manages cryptographic key material.
2. The Authenticator
The Authenticator is the network access device (an AOS-CX switch or Aruba wireless access point) situated at the physical or RF perimeter. The authenticator controls physical access to the network based on the authentication status of the client.
Dual-Port Conceptual Model (PAE): Under IEEE 802.1X, each physical switch port is logically split into two Port Access Entity (PAE) communication paths:
Uncontrolled Port: Always open to receive and transmit Layer 2 802.1X control frames (EAPOL). It discards all standard user data (IP packets, ARP, DHCP).
Controlled Port: Remains in an unauthorized, blocked state until the authentication server verifies the supplicant's identity. Once authorized, the controlled port transitions to the forwarding state, allowing bidirectional data traffic.
Crucial Architectural Principle: The Authenticator never validates credentials . It acts as a transparent protocol translator, bridging Layer 2 EAPOL frames from the client into Layer 4 RADIUS packets destined for the authentication server.
3. The Authentication Server
The Authentication Server is the centralized policy and identity verification engine—typically Aruba ClearPass Policy Manager (CPPM) or an enterprise RADIUS server (such as FreeRADIUS or Microsoft NPS). The server performs the actual cryptographic validation of identity assertions against enterprise directory stores (such as Microsoft Active Directory via Kerberos/LDAP, Azure AD/Entra ID, or internal certificate authorities). Following validation, the authentication server instructs the switch whether to open the controlled port and transmits authorization parameters.
EAP Encapsulation: EAPOL vs. RADIUS over IP
The Extensible Authentication Protocol (EAP, RFC 3748) is an authentication envelope rather than a specific authentication mechanism. To allow EAP packets to travel between the Supplicant and the Authentication Server across intermediate network switches, two distinct transport encapsulation standards are used:
Protocol Segment Transport Standard Layer Destination Addressing Payload Format
Supplicant to Authenticator EAPOL (EAP over LAN, IEEE 802.1X) Layer 2 Data Link Multicast 01:80:C2:00:00:03 (EtherType 0x888E ) Raw EAP frame encapsulated directly in Ethernet
Authenticator to Auth Server RADIUS (RFC 2865, 3579) Layer 4 Transport / IP Unicast IP of ClearPass server (UDP Port 1812) EAP packet embedded in RADIUS Attribute 79 ( EAP-Message )
Protocol Translation at the Authenticator
The Supplicant connects and sends an EAPOL-Start or responds to an EAP-Request/Identity with an EAP-Response/Identity over Ethernet.
The AOS-CX switch intercepts the Layer 2 EAPOL frame on the uncontrolled port.
The switch extracts the inner EAP message and encapsulates it into a standard RADIUS Access-Request UDP datagram. It appends RADIUS attributes:
User-Name (Attribute 1): The client's claimed identity string.
NAS-IP-Address (Attribute 4): The switch's management or loopback IP address.
NAS-Port / NAS-Port-Id (Attribute 5/87): Physical switch port identifier (e.g., 1/1/10 ).
Calling-Station-Id (Attribute 31): Endpoint MAC address.
Called-Station-Id (Attribute 30): Switch MAC address or port identifier.
EAP-Message (Attribute 79): The raw EAP packet.
Message-Authenticator (Attribute 80): An HMAC-MD5 cryptographic signature verifying packet integrity between the switch and ClearPass using the shared secret.
When ClearPass returns a RADIUS Access-Challenge , the switch strips the RADIUS headers, places the EAP payload into an EAPOL-Packet frame, and delivers it to the client.
Upon final validation, ClearPass sends a RADIUS Access-Accept containing authorization VSAs. The switch unlocks the controlled port and sends an EAP-Success frame to the endpoint.
AOS-CX Port-Access Client Modes and State Machine
In enterprise environments, multiple devices frequently connect through a single physical switch port (for example, a VoIP desktop telephone with an integrated PC pass-through switch port). AOS-CX switches provide configurable port-access client modes to manage these topologies: +---------------------------------------------------------------------------------------------------------+
- | AOS-CX PORT-ACCESS CLIENT MODES |
- | |
- | [ CLIENT-MODE ] -------------> Multi-Client Authentication (Standard Enterprise Default) |
- | Each connected MAC address authenticates independently. |
- | Phone (VoIP role/VLAN) + PC (Corporate role/VLAN) on same port. |
- | |
- | [ DEVICE-MODE ] -------------> Single-Client Authentication (Legacy/High-Security Port) |
- | The first authenticated MAC unlocks the physical port. |
- | Additional devices piggyback without separate authentication. |
- +---------------------------------------------------------------------------------------------------------+
AOS-CX sets the mode per port with aaa authentication port-access auth-mode {client-mode | device-mode | multi-domain} ; client-mode is the default . Multi-domain mode allows one voice device plus a configured number of data devices.
Detailed Analysis of Client Modes
Client-Mode ( client-mode ): Each connected device must authenticate independently via its own MAC address. The switch maintains separate authorization states, User Roles, and accounting sessions for every MAC address learned on the interface. A VoIP phone authenticates via 802.1X/MAC-Auth and receives the Voice VLAN role, while the tethered PC authenticates and receives an Employee role on the Data VLAN.
Device-Mode ( device-mode ): Only the initial connecting client authenticates. Once that device is authorized, the controlled port opens for all traffic arriving on that physical interface. This mode creates severe security risks in modern multi-device environments and is reserved for specialized single-device containment.
The AOS-CX Port-Access Client State Machine
An endpoint navigating port authentication on AOS-CX transitions through formal lifecycle states:
Connecting: The switch detects physical link-up and transmits an EAP-Request/Identity frame. If no response arrives, the switch retransmits according to configured retry counters.
Authenticating: The client responds with identity credentials. The switch exchanges EAPOL/RADIUS challenge messages with the authentication server.
Authenticated: The authentication server transmits an Access-Accept . The switch applies the assigned User Role, opens the controlled port, and initiates RADIUS accounting.
Held / Quiet Period: If authentication fails (bad credentials or server reject) after the allowed retries ( max-retries , default 2), the switch holds the client for the quiet-period (default 60 seconds). During this interval, authentication attempts from that MAC are not processed, which slows brute-force attempts and avoids locking out directory accounts.
Role-Based Enforcement on AOS-CX
Traditional network architectures relied solely on dynamic VLAN assignment (RADIUS RFC 2868/3580 attributes: Tunnel-Type , Tunnel-Medium-Type , and Tunnel-Private-Group-ID ) to segment users. Aruba AOS-CX elevates this through User Roles .
An AOS-CX User Role is a comprehensive policy container that encapsulates:
Assigned VLAN ID: The Layer 2 broadcast domain.
Ingress/Egress Access Control Lists (ACLs): Layer 2 through Layer 4 packet filtering applied directly in the switch ASIC.
Quality of Service (QoS) Policy: Bandwidth rate-limits, priority queues, and DSCP remarking.
Captive Portal Profile: Redirection URLs for web authentication onboarding.
User-Based Tunneling (UBT): Redirecting traffic to an Aruba gateway cluster for stateful firewall inspection.
Dynamic User Roles (DUR) vs. Local User Roles (LUR)
Local User Role (LUR): The administrator manually configures the role and its associated ACLs directly in the AOS-CX CLI ( port-access role <role-name> ). When ClearPass returns the Aruba-User-Role VSA (Vendor ID 14823 , VSA 1 ), the switch matches the string to its locally pre-configured role definition.
Dynamic User Role (DUR): The role definition (including ACLs and VLAN parameters) is maintained exclusively in ClearPass. When a client authenticates, ClearPass pushes the role name via RADIUS, and the AOS-CX switch downloads the full policy definition dynamically via REST APIs. This centralizes policy administration across hundreds of campus switches.
AOS-CX Configuration and Verification
The following configuration session illustrates configuring a RADIUS server, establishing an AAA server group, enabling 802.1X globally, and securing access port 1/1/1 on an AOS-CX switch: switch# configure terminal
- ! Step 1: Define the ClearPass RADIUS Server and Shared Secret
- switch(config)# radius-server host 10.10.100.50 key plaintext SecretRadiusKey123
- switch(config)# radius dyn-authorization enable
- switch(config)# radius dyn-authorization client 10.10.100.50 secret-key plaintext SecretRadiusKey123
- ! Step 2: Create a RADIUS Server Group
- switch(config)# aaa group server radius CPPM-RADIUS-GROUP
- switch(config-sg)# server 10.10.100.50
- switch(config-sg)# exit
- ! Step 3: Enable 802.1X Port-Access Globally and point it at the server group
- switch(config)# aaa authentication port-access dot1x authenticator radius server-group CPPM-RADIUS-GROUP
- switch(config)# aaa authentication port-access dot1x authenticator enable
- ! Step 4: Configure Local User Roles for Role-Based Enforcement
- switch(config)# port-access role EMPLOYEE_ROLE
- switch(config-pa-role)# vlan access 20
- switch(config-pa-role)# exit
- switch(config)# port-access role REJECT_ROLE
- switch(config-pa-role)# vlan access 99
- switch(config-pa-role)# exit
- ! Step 5: Configure 802.1X on Access Port 1/1/1
- switch(config)# interface 1/1/1
- switch(config-if)# no routing
- switch(config-if)# vlan access 1
- switch(config-if)# aaa authentication port-access auth-mode client-mode
- switch(config-if)# aaa authentication port-access client-limit 4
- switch(config-if)# aaa authentication port-access dot1x authenticator enable
- switch(config-if)# aaa authentication port-access reject-role REJECT_ROLE
- switch(config-if)# exit
- Essential Verification Commands
Verification Command Diagnostic Purpose
show port-access clients Lists all active authenticated clients across the switch, displaying MAC address, assigned port, authentication method (dot1x/mac-auth), status, and active User Role.
show port-access clients detail Provides granular telemetry for each client: authentication method, session time, VLAN, applied role, and status.
show radius-server Displays the configured RADIUS servers and their reachability.
show port-access role Summarizes all configured Local User Roles, assigned VLAN IDs, and bound security ACLs.
Common Exam Traps
Authenticator Credential Validation Myth: The exam frequently asks whether the authenticator switch evaluates client password hashes or digital certificates. The switch never evaluates credentials; it operates strictly as an EAPOL-to-RADIUS protocol relay. Only the authentication server (ClearPass) validates credentials.
Controlled vs. Uncontrolled Ports: Confusing which port entity permits EAPOL. Unauthenticated clients can always transmit EAPOL frames because the uncontrolled port is open; standard data traffic is blocked until the controlled port is opened upon authorization.
Client-Mode vs. Device-Mode: Changing a port that connects both an IP phone and a PC to device-mode . In device mode only the first client authenticates and the rest ride along; keep the default client-mode (and a client limit of at least 2) so each device authenticates independently.