C9800 RADIUS and AAA Configuration Guide

Opening Context: AAA as the Foundation of Enterprise Wireless Security

Authentication, Authorization, and Accounting (AAA) represents the cornerstone of enterprise wireless security in Catalyst 9800 controller deployments. Unlike local authentication methods that store credentials on the controller itself, AAA delegates these functions to centralized, purpose-built infrastructure. This architecture provides you with several critical advantages: scalability across thousands of wireless access points, consistent security policy enforcement, detailed audit trails for compliance, and the ability to revoke access without modifying device configurations.

The Catalyst 9800 controller acts as a network access server (NAS), communicating with external AAA servers using industry-standard protocols like RADIUS (Remote Authentication Dial-In User Service). When a user attempts to connect to a wireless network, the C9800 intercepts the authentication request and forwards it to designated RADIUS servers. These servers validate credentials, determine what resources the user can access, and log detailed session information for accounting purposes. This separation of concerns means you can update security policies, add or remove users, and modify access rules without touching wireless controller configurations.

This guide walks you through RADIUS server configuration, AAA method lists, RADIUS vendor-specific attributes (VSAs) for policy enforcement, server load balancing, and survivability mechanisms for WAN failures. You'll learn how to configure the fundamental building blocks of enterprise wireless authentication, implement real-world scenarios like MAC filtering and VLAN assignment, and verify your configurations with practical testing commands.

Understanding RADIUS Protocol and Server Communication

RADIUS operates over UDP on port 1812 for authentication and accounting (port 1645 on older implementations), using a shared secret between the NAS and RADIUS server for packet authentication. The protocol employs a stateless request-response model: your C9800 sends an Access-Request packet to the RADIUS server, which responds with either an Access-Accept, Access-Reject, or Access-Challenge packet.

Each RADIUS packet contains a set of attribute-value pairs (AVPs) that carry information about the authentication attempt. Common attributes include User-Name, User-Password, Service-Type, Calling-Station-Id (the device's MAC address), and Called-Station-Id (the SSID or access point identifier). The RADIUS server evaluates these attributes against its local user database or external directory service (such as Active Directory via LDAP) and includes authorization attributes in the Access-Accept response.

Here's an example of a typical RADIUS Access-Request packet structure you'll see in packet captures:

Code: Access-Request (1)
ID: 245
Length: 156
Request Authenticator: 4f e2 41 2a 3c 8b 92 e4 1d 47 58 e1 a9 2d fc 3b

Attributes:
  User-Name: alice@example.com
  User-Password: [encrypted with shared secret]
  Service-Type: Framed-User (2)
  Calling-Station-Id: 00:1a:2b:3c:4d:5e
  Called-Station-Id: AP1-Guest-SSID
  NAS-IP-Address: 10.1.1.100
  NAS-Identifier: C9800-Controller
  Message-Authenticator: [HMAC-MD5 of entire packet]

The Message-Authenticator attribute is particularly important—it provides integrity checking for the entire RADIUS packet using HMAC-MD5, protecting against packet modification. Many modern RADIUS servers require this attribute for security reasons. The Response Authenticator in the server's reply is calculated as MD5(Code + ID + Length + Request Authenticator + Attributes + Shared Secret), which prevents unauthorized servers from crafting valid responses.

Configuring RADIUS Servers and Server Groups

You configure RADIUS server credentials at the global level on your C9800, then organize servers into logical groups for method lists. This approach provides flexibility: you might have one server group for wired authentication and another for wireless guest access, each with different characteristics (timeout values, retry counts, deadtime settings).

Here's the fundamental configuration for adding a RADIUS server to your C9800:

C9800# configure terminal
C9800(config)# radius server RADIUS-PRIMARY
C9800(config-radius-server)# address ipv4 10.1.1.50 auth-port 1812 acct-port 1813
C9800(config-radius-server)# key MySharedSecret123
C9800(config-radius-server)# timeout 5
C9800(config-radius-server)# retransmit 3
C9800(config-radius-server)# exit

C9800(config)# radius server RADIUS-SECONDARY
C9800(config-radius-server)# address ipv4 10.1.1.51 auth-port 1812 acct-port 1813
C9800(config-radius-server)# key MySharedSecret123
C9800(config-radius-server)# timeout 5
C9800(config-radius-server)# retransmit 3
C9800(config-radius-server)# exit

Notice that you define timeout (seconds to wait for a response) and retransmit (number of retry attempts) at the individual server level. These values affect how long the controller waits before considering a server unresponsive. A timeout of 5 seconds with 3 retransmits means the controller will wait up to 15 seconds total before moving to the next server.

Now organize these servers into a named group:

C9800(config)# aaa group server radius ENTERPRISE-AUTH
C9800(config-sg-radius)# server name RADIUS-PRIMARY
C9800(config-sg-radius)# server name RADIUS-SECONDARY
C9800(config-sg-radius)# ip radius source-interface GigabitEthernet0/0/0
C9800(config-sg-radius)# exit

The source-interface command ensures that all RADIUS traffic originates from the specified interface—critical for firewalls and RADIUS servers that validate source IP addresses against permitted NAS addresses. If you don't specify this, RADIUS packets may originate from unexpected interfaces in multi-homed controller deployments.

RADIUS Server Groups, Dead-Server Detection, and Load Balancing

The C9800 implements intelligent server group management to handle scenarios where RADIUS servers become unavailable. When the controller detects that a server is not responding to authentication requests, it marks that server as "dead" and stops sending traffic to it until a configurable deadtime expires.

The key parameters for server group behavior are:

• Deadtime (in minutes): How long the controller waits before attempting to use a dead server again. Default is 0 (disabled).
• Load-Balance method: Whether to distribute requests sequentially or based on response time.
• Batch size: How many requests to send to a server before rotating to the next server (used with load-balance method).

Configure deadtime and load balancing like this:

C9800(config)# aaa group server radius ENTERPRISE-AUTH
C9800(config-sg-radius)# dead-criteria tries 3 time 10
C9800(config-sg-radius)# deadtime 15
C9800(config-sg-radius)# load-balance method least-outstanding-requests
C9800(config-sg-radius)# load-balance method batch 50
C9800(config-sg-radius)# exit

The dead-criteria command tells the controller to mark a server as dead after 3 failed requests within 10 seconds. The deadtime of 15 minutes means the controller will wait 15 minutes before attempting the dead server again. Once deadtime expires, the controller will send a test request to determine if the server is back online (a process called server recovery).

The load-balance method directs the controller to distribute requests to servers with the fewest outstanding requests, optimizing for responsiveness. Alternatively, you can use load-balance method batch 50 to send 50 consecutive requests to the first server, then switch to the next server.

AAA Method Lists and Authentication Flow

Method lists define the sequence and type of authentication and authorization services the controller uses for specific purposes. You might have one method list for 802.1X authentication (which checks a RADIUS server, then falls back to local authentication), another for web authentication (which might skip RADIUS entirely), and another for administrative CLI access.

Here's a method list for 802.1X that uses RADIUS as the primary mechanism with local authentication as fallback:

C9800(config)# aaa authentication dot1x default group ENTERPRISE-AUTH local
C9800(config)# aaa authorization network default group ENTERPRISE-AUTH local
C9800(config)# aaa accounting update newinfo
C9800(config)# aaa accounting dot1x default start-stop group ENTERPRISE-AUTH

Let's break this down. The first line creates an authentication method list named "default" (which is used as the fallback if no other method list is specified). This method list tries the ENTERPRISE-AUTH server group first; if that group is unavailable or doesn't respond, the controller falls back to local authentication (the "local" keyword). The second line sets up authorization using the same group.

For a guest wireless network with web-based authentication, you might use a different approach:

C9800(config)# aaa authentication login GUEST-AUTH group ENTERPRISE-AUTH
C9800(config)# aaa authorization exec GUEST-AUTH group ENTERPRISE-AUTH local
C9800(config)# aaa accounting exec default start-stop group ENTERPRISE-AUTH

This method list applies to login sessions (users entering credentials via a web portal) rather than 802.1X port-based authentication. After the RADIUS server authenticates the user, it returns an Access-Accept message that may include authorization attributes instructing the controller to assign the user to a specific VLAN or apply an ACL.

RADIUS Vendor-Specific Attributes and Policy Enforcement

Standard RADIUS attributes handle basic authentication and authorization, but Cisco extends the protocol with Vendor-Specific Attributes (VSAs) to enforce wireless-specific policies. VSAs are encoded as a single AVP of type "Vendor-Specific" that wraps vendor-specific sub-attributes. Cisco uses vendor ID 9 (0x00000009) in RADIUS packets.

The most powerful VSA for wireless is Cisco-AV-Pair, which allows the RADIUS server to instruct the controller to assign VLANs, apply ACLs, set QoS policies, and more. Here's an example of how a RADIUS server response might include these VSAs:

Access-Accept packet from RADIUS server:
Code: Access-Accept (2)
ID: 245
Length: 248

Attributes:
  User-Name: alice@example.com
  Service-Type: Framed-User (2)
  Framed-Protocol: PPP (1)
  Framed-IP-Address: 10.2.1.100
  Framed-MTU: 1500

Vendor-Specific Attributes (Cisco):
  Cisco-AV-Pair: shell:roles="student"
  Cisco-AV-Pair: vlan:vlanname=VoIP-VLAN
  Cisco-AV-Pair: ip:inacl#1=permit ip any host 10.1.1.1
  Cisco-AV-Pair: cisco-av-pair=session-timeout=3600
  Cisco-AV-Pair: Audit-session-id=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
  Cisco-AV-Pair: Airespace-WLAN-ID=5

Each Cisco-AV-Pair entry is a string with a specific format. The vlan:vlanname=VoIP-VLAN pair instructs the controller to assign the user's session to a VLAN named "VoIP-VLAN". The ip:inacl#1 pair provides an inbound ACL that the controller applies to the session. The session-timeout pair sets how long the session remains active before reauthentication. The Audit-session-id is a unique identifier for the session used in logging and troubleshooting. Airespace-WLAN-ID is the numeric ID of the wireless network (SSID) that sent the request.

To use these VSAs, your RADIUS server must be configured with rules that populate them in authorization responses. If you're using Cisco Identity Services Engine (ISE), you'd create an authorization profile with policy sets that generate these AV-pairs based on user groups or device profiles.

Implementing RADIUS Realm-Based Authentication and Username Transformations

In large enterprises with multiple authentication domains, you may need to strip realm information from usernames before sending them to the RADIUS server. For example, a user might present the username alice@engineering.example.com, but your RADIUS server expects just alice with the domain handled separately.

Configure realm-based authentication like this:

C9800(config)# aaa authentication login default local
C9800(config)# radius-server vsa send authentication
C9800(config)# aaa group server radius ISE-SERVERS
C9800(config-sg-radius)# server name ISE-PRIMARY
C9800(config-sg-radius)# server name ISE-SECONDARY
C9800(config-sg-radius)# load-balance method batch 25
C9800(config-sg-radius)# exit

C9800(config)# ip radius source-interface GigabitEthernet0/0/0

C9800(config)# aaa authentication login REALM-AUTH group ISE-SERVERS local
C9800(config)# aaa authorization network default group ISE-SERVERS local

The radius-server vsa send authentication command tells the controller to include VSAs in authentication requests and accept VSAs in authorization responses. This is essential for advanced features like VLAN assignment and policy enforcement.

When a user supplies a realm in their username (format: username@realm), some RADIUS servers expect the controller to extract just the username part. You can configure stripping on a per-SSID or per-authentication-method basis, though the exact mechanism depends on your authentication flow (802.1X, web-based, etc.).

Advanced Server Load Balancing and Batch Configuration

In deployments with multiple RADIUS servers handling hundreds of concurrent authentications, load balancing parameters directly impact performance and failover behavior. The batch-size parameter determines how many authentication requests the controller sends to a single server before moving to the next server in the group.

For a server group with three RADIUS servers, configuring batch-size 100 means the controller will send 100 requests to Server 1, then 100 requests to Server 2, then 100 to Server 3, and cycle back to Server 1. This ensures load distribution but also means that if Server 1 becomes overloaded, the controller won't detect it until the batch completes.

A more responsive approach uses least-outstanding-requests load balancing:

C9800(config)# aaa group server radius ENTERPRISE-AUTH
C9800(config-sg-radius)# load-balance method least-outstanding-requests
C9800(config-sg-radius)# deadtime 10
C9800(config-sg-radius)# dead-criteria tries 5 time 30
C9800(config-sg-radius)# exit

With this configuration, the controller tracks how many requests are currently awaiting responses from each server. A new authentication request is always sent to the server with the fewest outstanding requests. This method provides better responsiveness to server overload conditions but requires more computational overhead on the controller.

The dead-criteria tries 5 time 30 means the controller marks a server as dead only after 5 consecutive failed requests within a 30-second window. This threshold is more stringent than the default, reducing false positives from transient network delays.

AAA Survivability Cache and WAN Failure Scenarios

When your primary WAN link to a RADIUS server fails, AAA Survivability Cache allows the controller to continue authenticating users based on cached credentials from previous successful authentications. This feature is critical for maintaining wireless connectivity during WAN outages—without it, users would be unable to authenticate until the RADIUS server becomes reachable again.

Configure AAA Survivability Cache with these commands:

C9800(config)# aaa new-model
C9800(config)# aaa cache server dead-criteria tries 3 time 10
C9800(config)# aaa cache server deadtime 120

C9800(config)# aaa authentication login default group ENTERPRISE-AUTH cache
C9800(config)# aaa authorization network default group ENTERPRISE-AUTH cache
C9800(config)# aaa accounting update newinfo
C9800(config)# aaa accounting network default start-stop group ENTERPRISE-AUTH

The aaa cache server commands configure how the controller detects that RADIUS servers are unavailable. The tries 3 time 10 setting marks a server as dead after 3 failed attempts within 10 seconds. The deadtime 120 (in minutes) specifies that the controller will attempt the dead server again after 120 minutes have passed. During this deadtime, authentication requests use cached entries instead of contacting the RADIUS server.

When you add the cache keyword to authentication and authorization method lists, the controller caches successful authentication and authorization results. The next time the same user authenticates with the same password, if the RADIUS server is unavailable, the controller retrieves the cached result and allows the authentication to succeed. This is different from failover to local authentication—it's a replay of the exact previous authorization response, including VSA policies.

Important limitations: AAA cache only stores successful authentications. If a user's credentials change on the RADIUS server, the controller will not be aware until the server becomes reachable again. Additionally, cached entries have a time-to-live (TTL) that you should configure based on your security policies—you don't want cached entries persisting indefinitely.

Wireless-Specific RADIUS Attributes and Session Identification

Beyond standard RADIUS attributes, wireless authentication involves device-specific attributes that identify which access point, SSID, and interface handled the connection. The controller includes these attributes in Access-Request packets and the RADIUS server uses them for policy decisions.

Key wireless-specific attributes include:

The controller includes these attributes in every Access-Request. A well-configured RADIUS server uses them to make context-aware authorization decisions. For example, a policy rule might specify: "If the user belongs to the Engineering group AND they're connecting to the Corporate-5G SSID (Airespace-WLAN-ID 3), assign them to the Engineering-Data VLAN. If they're connecting to the Guest SSID, assign them to the Guest VLAN instead."

The Audit-session-id is particularly valuable for troubleshooting. This globally unique identifier allows you to correlate authentication logs on the controller with logs on the RADIUS server, ISE, or a SIEM system. When investigating authentication failures or unexpected access denials, searching for the session ID across all systems provides a complete picture of what occurred.

Configuration Examples: MAC Filtering and VLAN Assignment via RADIUS

A common wireless scenario is MAC-based authentication for IoT devices or printers that can't perform 802.1X or web authentication. The controller uses the Calling-Station-Id attribute (the device's MAC address) to authenticate the device, and RADIUS returns authorization attributes that assign the device to an IoT VLAN.

Here's a complete configuration for MAC-based authentication:

C9800(config)# aaa authentication login MAC-AUTH group ENTERPRISE-AUTH local
C9800(config)# aaa authorization exec MAC-AUTH group ENTERPRISE-AUTH local
C9800(config)# aaa accounting exec default start-stop group ENTERPRISE-AUTH

C9800(config)# wireless tag policy test-tag
C9800(config-wireless-tag)# description "Test policy for MAC authentication"
C9800(config-wireless-tag)# exit

C9800(config)# wlan PRINTERS 2
C9800(config-wlan)# description "Printer Network"
C9800(config-wlan)# ssid PRINTERS
C9800(config-wlan)# security wpa3 personal
C9800(config-wlan)# exit

On the RADIUS server, you'd configure user entries using MAC addresses as usernames (with a shared password) and return VSAs that assign them to a specific VLAN:

User Database Entry (example ISE format):
Username: 00-1a-2b-3c-4d-5e
Password: shared-mac-secret
Attribute: Cisco-AV-Pair=vlan:vlanname=Printer-VLAN
Attribute: Cisco-AV-Pair=Audit-session-id=device-printer-001

For centralized VLAN assignment that applies to all users, configure VLAN policy at the controller level. When the RADIUS server returns a vlan:vlanname VSA, the controller dynamically assigns the session to that VLAN. This is far more flexible than static VLAN assignments because policies can be changed on the RADIUS server without controller reconfiguration.

To verify that VLAN assignment is working, use these commands:

C9800# show wireless session clients

Client MAC Address : 00:1a:2b:3c:4d:5e
State : Run
WLAN : 2 (PRINTERS)
VLAN : 202 (Printer-VLAN)
IP Address : 10.2.202.150
Protocol : 802.11ax
Band : 5GHz
Channel : 44
Signal Strength : -42 dBm
Data Rate : 433 Mbps

The VLAN field shows the current assignment. If it displays the correct Printer-VLAN, your RADIUS VSA configuration is working.

Verification and Testing Commands

After configuring RADIUS servers, method lists, and VSAs, verify the configuration with controller commands that test server connectivity and review active sessions.

First, verify that your RADIUS server configuration is correct:

C9800# show radius server-group ENTERPRISE-AUTH

Server group : ENTERPRISE-AUTH
Group state : Alive

Server : 10.1.1.50
  Priority : 50 (default)
  State : Alive
  Total requests : 1247
  Total retransmissions : 3
  Total timeouts : 0
  Total responses : 1244
  Total pending requests : 0
  Last response received : 00:00:35

Server : 10.1.1.51
  Priority : 50 (default)
  State : Alive
  Total requests : 1156
  Total retransmissions : 2
  Total timeouts : 0
  Total responses : 1155
  Total pending requests : 0
  Last response received : 00:00:42

This output shows you that both servers are in Alive state with very few retransmissions, indicating good connectivity and responsiveness. The low retransmission count (3 and 2 out of ~1200 requests) suggests reliable network paths and server performance.

To test authentication against a specific server group, use the test command:

C9800# test aaa group ENTERPRISE-AUTH alice password123 new-code

Testing group : ENTERPRISE-AUTH
Attempting authentication test to server group...

Server IP: 10.1.1.50
Result: Authentication succeeded
Response time: 125 ms
Response code: Access-Accept

This test sends an actual Access-Request to the RADIUS server and displays the response. If you receive "Access-Accept", the server validated the credentials. If you receive "Access-Reject", the server denies access—check your RADIUS server's user database to verify the credentials exist.

To display active AAA method lists and their configuration:

C9800# show aaa authentication

aaa authentication login default group ENTERPRISE-AUTH local
aaa authentication login GUEST-AUTH group ENTERPRISE-AUTH
aaa authentication dot1x default group ENTERPRISE-AUTH local
aaa authentication login MAC-AUTH group ENTERPRISE-AUTH local

This summarizes all method lists on the controller. Cross-reference these against your wireless SSID configurations to ensure each WLAN is using the correct method list for its authentication type.

To view active wireless sessions and their authentication status:

C9800# show wireless session clients summary

Number of Clients : 47

MAC Address          WLAN Name           IP Address       VLAN  Auth Status
00:11:22:33:44:01   CORPORATE-SSID      10.1.1.50        101   Authenticated
00:11:22:33:44:02   CORPORATE-SSID      10.1.1.51        101   Authenticated
00:1a:2b:3c:4d:5e   PRINTERS            10.2.202.150     202   Authenticated
aa:bb:cc:dd:ee:ff   Guest-SSID          10.3.100.75      300   Web-Authenticated

The "Auth Status" column shows the authentication method used. "Authenticated" indicates 802.1X or MAC authentication succeeded through RADIUS. "Web-Authenticated" indicates the user completed a web portal authentication flow.

Key Takeaways and Best Practices

AAA and RADIUS configuration on the Catalyst 9800 provides enterprise-grade authentication, authorization, and accounting for wireless networks. Here are the critical points to remember as you implement these features:


  Always use a shared secret longer than 20 characters to protect RADIUS communication. Consider using different secrets for different server groups to limit the blast radius of a compromised secret.
  Configure deadtime and dead-server detection to handle RADIUS server failures gracefully. Without these settings, authentication delays increase significantly when a server becomes unavailable.
  Use VSAs (Vendor-Specific Attributes) for policy enforcement rather than static VLAN or ACL assignments. This allows you to modify policies on the RADIUS server without touching the controller.
  Implement AAA Survivability Cache in deployments where WAN outages are possible. Cache extends wireless connectivity during network failures while maintaining security policies.
  Include Audit-session-id in all RADIUS requests to enable correlation between controller logs, RADIUS server logs, and SIEM systems. This dramatically improves troubleshooting efficiency.
  Test method lists with test aaa commands before deploying to production. This catches configuration errors early and verifies that servers are reachable.
  Monitor server statistics with show radius server-group regularly. High retransmission counts or timeout rates indicate network issues, server overload, or misconfigured shared secrets.
  Document which method lists apply to which WLANs. In large deployments with many SSIDs and authentication types, clear documentation prevents configuration errors and makes troubleshooting faster.


By mastering RADIUS configuration and AAA method lists on the C9800, you gain complete control over wireless access policies. Users authenticate against centralized servers, authorization policies are enforced consistently across all access points, and detailed accounting logs provide the audit trail required for compliance and security investigations.