AAA with RADIUS Configuration

While TACACS+ is Cisco's preferred protocol for device administration, RADIUS (Remote Authentication Dial-In User Service) is the industry-standard open protocol used across virtually every vendor's equipment for network access control. RADIUS is the protocol behind 802.1X port authentication, wireless network access, VPN user authentication, and — in many organisations — Cisco device management where a RADIUS-only server infrastructure already exists.

RADIUS and TACACS+ share the same AAA framework on Cisco IOS — aaa new-model, method lists, and server groups work identically. The difference is at the protocol level: RADIUS uses UDP ports 1812/1813, encrypts only the password field, and combines authentication and authorisation in a single exchange. Understanding RADIUS configuration is essential for environments using Microsoft NPS, FreeRADIUS, Cisco ISE in RADIUS mode, or any third-party AAA server.

Before starting, complete AAA with TACACS+ Configuration to understand the AAA framework, method lists, fallback logic, and the critical lockout risk. Ensure IP reachability to the RADIUS server — RADIUS uses UDP/1812 for authentication and UDP/1813 for accounting. For the VTY lines being protected, see SSH Configuration.

1. RADIUS Protocol — Core Concepts

RADIUS vs TACACS+ — When to Use Each

Feature	RADIUS	TACACS+
Transport	UDP port 1812 (auth/authz), UDP port 1813 (accounting)	TCP port 49 — reliable, connection-oriented
Encryption	Password only — all other attributes sent in clear text	Entire payload encrypted
AAA separation	Authentication and Authorisation combined in one response	Fully separate — can use different servers per function
Per-command authorisation	❌ Not supported — privilege level only	✅ Supported — each IOS command approved individually
Standard	Open standard (RFC 2865, RFC 2866) — all vendors	Cisco proprietary
Primary use	802.1X, VPN, wireless, dial-up network access control	Network device administration (routers, switches)
Privilege level	Via VSA (Vendor-Specific Attribute) — Cisco-AV-Pair	Server directly returns privilege level in response

RADIUS Authentication Flow

RADIUS uses a challenge-response model. The router (NAS — Network Access Server) acts as the intermediary between the user and the RADIUS server:

  User ──── SSH login attempt ────► Router (NAS)
                                         │
                                         │ Access-Request (UDP/1812)
                                         │ [Username, encrypted password,
                                         │  NAS-IP, NAS-Port, Service-Type]
                                         ▼
                                    RADIUS Server
                                         │
                                         │ Access-Accept OR Access-Reject
                                         │ [If Accept: includes privilege
                                         │  level via Cisco-AV-Pair VSA]
                                         ▼
                                    Router (NAS)
                                         │
                          Login success or denied
                                         ▼
                                       User

  Accounting flow (UDP/1813):
  Router ──► Accounting-Request (Start) ──► RADIUS Server
  Router ──► Accounting-Request (Stop)  ──► RADIUS Server

RADIUS Attribute Types Relevant to Device Access

Attribute	Number	Purpose in IOS AAA
User-Name	1	The username entered at the login prompt — sent in the Access-Request
User-Password	2	The password — encrypted with the shared secret using MD5
NAS-IP-Address	4	The router's source IP for the RADIUS request — must match the client entry on the server
Service-Type	6	The type of service requested — value 7 (NAS-Prompt) for device login; value 6 (Administrative) for privilege 15
Cisco-AV-Pair	VSA 26	Cisco Vendor-Specific Attribute — used to pass privilege level: `shell:priv-lvl=15`

Privilege Level via RADIUS — VSA Configuration

Unlike TACACS+ which has a native privilege-level field in its response, RADIUS delivers privilege level through a Vendor-Specific Attribute (VSA). On the RADIUS server, configure the Cisco-AV-Pair attribute for users requiring elevated access:

RADIUS Server Setting	IOS Result	User Experience
`Cisco-AV-Pair = shell:priv-lvl=15`	User placed directly at privilege 15	Logs in to `Router#` prompt — full access
`Cisco-AV-Pair = shell:priv-lvl=7`	User placed at privilege 7	Limited command access — read-only NOC level
No Cisco-AV-Pair / Service-Type = NAS-Prompt	User placed at privilege 1	Logs in to `Router>` — must manually type `enable`

2. Lab Topology & Scenario

NetsTuts_R1 authenticates all VTY (SSH) management sessions against a Microsoft NPS (Network Policy Server) acting as the RADIUS server at 192.168.10.60. A secondary RADIUS server (FreeRADIUS) provides redundancy at 192.168.10.61. The local account database serves as fallback when both servers are unreachable. All RADIUS requests originate from R1's loopback:

         [Admin PC]               [RADIUS Primary]     [RADIUS Secondary]
         192.168.10.5             192.168.10.60 (NPS)  192.168.10.61 (FreeRADIUS)
               |                         |                     |
               └─────────────────────────┴─────────────────────┘
                                         |
                                  192.168.10.0/24
                                         |
                                   Gi0/1 (INSIDE)
                                   192.168.10.1
                          ┌──────────────────────────────┐
                          │         NetsTuts_R1            │
                          │  aaa new-model                 │
                          │  RADIUS group: RADIUS-SERVERS  │
                          │  Method: RADIUS-AUTH → local   │
                          │  Source: Loopback0 (1.1.1.1)   │
                          │  Local fallback: admin priv 15 │
                          └──────────────────────────────┘
                                   Gi0/0 (WAN)
                                   203.0.113.2

  Auth/Authz:  UDP/1812  R1 ↔ RADIUS servers
  Accounting:  UDP/1813  R1 ↔ RADIUS servers

Device	Role	IP Address	UDP Port
NetsTuts_R1	NAS (Network Access Server) — sends AAA requests	Loopback: 1.1.1.1	Source: ephemeral
NPS (Primary)	RADIUS server — primary authentication	192.168.10.60	1812 (auth), 1813 (acct)
FreeRADIUS (Secondary)	RADIUS server — redundancy failover	192.168.10.61	1812 (auth), 1813 (acct)

3. Step 1 — Create Local Fallback Account First

Identical to TACACS+ deployment — the local privileged account must exist before aaa new-model is enabled. This is non-negotiable: enabling AAA without a fallback risks a complete lockout if both RADIUS servers become unreachable:

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Privileged fallback account — created BEFORE aaa new-model
NetsTuts_R1(config)#username admin privilege 15 secret NetsTuts@2026
NetsTuts_R1(config)#username noc   privilege 7  secret NOCread@2026

! ── Confirm accounts exist ───────────────────────────────
NetsTuts_R1(config)#do show running-config | include username
username admin privilege 15 secret 9 $9$...
username noc privilege 7 secret 9 $9$...

The local accounts serve two purposes. First, they are the authentication fallback when both RADIUS servers are unreachable — ensuring the router is never completely locked out during a server outage. Second, they provide console line access independent of any network server. Always use secret (hashed) over password (weakly encoded) for all user accounts. See Hostname, Banner & Password Configuration for more on securing local credentials.

4. Step 2 — Define RADIUS Servers

As with TACACS+, IOS supports both legacy global commands and the modern server-block model. The modern model is recommended — it supports per-server parameters, redundant servers, and explicit port configuration:

Method A — Legacy Global Command (older IOS)

! ── Legacy syntax — defines server with shared key ───────
NetsTuts_R1(config)#radius-server host 192.168.10.60 auth-port 1812 acct-port 1813 key NetsTutsRAD@2026
NetsTuts_R1(config)#radius-server timeout 5
NetsTuts_R1(config)#radius-server retransmit 3

Method B — Server Block Model (preferred, IOS 15+)

! ── Define primary RADIUS server (NPS) ───────────────────
NetsTuts_R1(config)#radius server NPS-PRIMARY
NetsTuts_R1(config-radius-server)#address ipv4 192.168.10.60 auth-port 1812 acct-port 1813
NetsTuts_R1(config-radius-server)#key NetsTutsRAD@2026
NetsTuts_R1(config-radius-server)#timeout 5
NetsTuts_R1(config-radius-server)#retransmit 3
NetsTuts_R1(config-radius-server)#exit

! ── Define secondary RADIUS server (FreeRADIUS) ──────────
NetsTuts_R1(config)#radius server FREERADIUS-SECONDARY
NetsTuts_R1(config-radius-server)#address ipv4 192.168.10.61 auth-port 1812 acct-port 1813
NetsTuts_R1(config-radius-server)#key NetsTutsRAD@2026
NetsTuts_R1(config-radius-server)#timeout 5
NetsTuts_R1(config-radius-server)#retransmit 3
NetsTuts_R1(config-radius-server)#exit

! ── Create server group containing both servers ───────────
NetsTuts_R1(config)#aaa group server radius RADIUS-SERVERS
NetsTuts_R1(config-sg-radius)#server name NPS-PRIMARY
NetsTuts_R1(config-sg-radius)#server name FREERADIUS-SECONDARY
NetsTuts_R1(config-sg-radius)#exit

Both servers are added to the group RADIUS-SERVERS — IOS queries them in order. If NPS-PRIMARY does not respond within 5 seconds (with up to 3 retransmissions), IOS tries FREERADIUS-SECONDARY. Both servers must have matching keys — the pre-shared key encrypts the password field and is also used to validate the response. A key mismatch causes authentication failure or silent request discard by the server. Unlike TACACS+ which uses TCP, RADIUS uses UDP — the retransmit setting compensates for potential UDP packet loss by specifying how many times IOS resends a request before marking the server as unresponsive.

RADIUS Server Configuration Parameters

Parameter	Command	Default	Notes
Server IP	`address ipv4 [IP] auth-port [n] acct-port [n]`	auth: 1812, acct: 1813	Modern IOS uses 1812/1813. Older servers may use 1645/1646 (legacy ports)
Shared key	`key [string]`	—	Case-sensitive — must match RADIUS server client entry exactly
Timeout	`timeout [seconds]`	5 seconds	How long to wait for UDP response before retransmitting
Retransmit	`retransmit [count]`	3	UDP packet loss compensation — total wait = timeout × retransmit before failover
Source interface	`ip radius source-interface [int]`	Outgoing interface	Set to loopback — RADIUS server NAS entry must match this IP

5. Step 3 — Enable AAA New Model

! ── Enable AAA framework — AFTER local user and server ───
NetsTuts_R1(config)#aaa new-model

Same critical risk as TACACS+. aaa new-model immediately places all lines under AAA control. Configure method lists and apply them to lines in the same configuration session — do not save with wr until the full AAA configuration is complete and tested. Always keep the console session open during initial configuration in case VTY access breaks.

6. Step 4 — Create AAA Method Lists

Authentication Method Lists

! ── VTY authentication: RADIUS primary, local fallback ───
NetsTuts_R1(config)#aaa authentication login RADIUS-AUTH group RADIUS-SERVERS local

! ── Console authentication: local only ───────────────────
NetsTuts_R1(config)#aaa authentication login CON-AUTH local

! ── Default list: safety net for unassigned lines ────────
NetsTuts_R1(config)#aaa authentication login default group RADIUS-SERVERS local

Exec Authorisation — Privilege Level Assignment

! ── Assign privilege level from RADIUS VSA after login ───
NetsTuts_R1(config)#aaa authorization exec RADIUS-AUTHZ group RADIUS-SERVERS local

! ── Enable Cisco VSA attribute parsing ───────────────────
! ── Required for RADIUS to return Cisco-AV-Pair priv-lvl ─
NetsTuts_R1(config)#aaa authorization exec default group RADIUS-SERVERS if-authenticated

The if-authenticated keyword is a RADIUS-specific option — it instructs IOS to authorise exec access for any user who has already successfully authenticated, without querying the server a second time for authorisation. This is useful when the RADIUS server returns the privilege level in the authentication response (via Cisco-AV-Pair) rather than in a separate authorisation exchange.

Accounting

! ── Log session start/stop events ────────────────────────
NetsTuts_R1(config)#aaa accounting exec default start-stop group RADIUS-SERVERS

! ── Log commands run at privilege 15 ─────────────────────
NetsTuts_R1(config)#aaa accounting commands 15 default start-stop group RADIUS-SERVERS

Enable Cisco VSA Support

! ── Required: tell IOS to accept and process Cisco VSAs ──
NetsTuts_R1(config)#radius-server vsa send authentication
NetsTuts_R1(config)#radius-server vsa send accounting

These two commands are critical for RADIUS-based privilege level assignment. Without radius-server vsa send authentication, IOS does not process the Cisco-AV-Pair = shell:priv-lvl=15 attribute returned by the RADIUS server — users would always land at privilege 1 regardless of the server's policy. Both VSA send commands must be present for complete RADIUS functionality with Cisco devices.

Method List Comparison — RADIUS vs TACACS+

Method List Type	RADIUS Configuration	TACACS+ Configuration	Key Difference
Authentication	`group RADIUS-SERVERS local`	`group TACACS-SERVERS local`	Same syntax — protocol difference is in server definition
Exec Authorisation	`group RADIUS-SERVERS if-authenticated`	`group TACACS-SERVERS local`	RADIUS often uses `if-authenticated` since priv-lvl comes with auth response
Command Authorisation	❌ Not supported	`aaa authorization commands 15 [list] group TACACS-SERVERS`	RADIUS cannot do per-command authorisation — TACACS+ exclusive
Accounting	`group RADIUS-SERVERS`	`group TACACS-SERVERS`	Same syntax — both support start-stop accounting

7. Step 5 — Apply Method Lists to Lines and Set Source Interface

! ── VTY lines: RADIUS authentication + exec authorisation
NetsTuts_R1(config)#line vty 0 4
NetsTuts_R1(config-line)#login authentication RADIUS-AUTH
NetsTuts_R1(config-line)#authorization exec RADIUS-AUTHZ
NetsTuts_R1(config-line)#transport input ssh
NetsTuts_R1(config-line)#exit

! ── Console line: local only ─────────────────────────────
NetsTuts_R1(config)#line console 0
NetsTuts_R1(config-line)#login authentication CON-AUTH
NetsTuts_R1(config-line)#exit

! ── RADIUS source interface — loopback for stable source ─
NetsTuts_R1(config)#ip radius source-interface Loopback0

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]
NetsTuts_R1#

ip radius source-interface Loopback0 ensures all RADIUS packets — authentication, authorisation, and accounting — originate from the loopback IP (1.1.1.1). The RADIUS server's NAS (Network Access Server) entry must be configured with this loopback IP. If the source IP changes (because of routing or interface failure), the RADIUS server may reject the request as coming from an unknown NAS. Using the loopback provides a stable, permanent source IP that never changes. See Console & VTY Line Configuration for more on line configuration options.

8. Step 6 — Legacy RADIUS Port Support (1645/1646)

Some older RADIUS servers and equipment use the original non-standard RADIUS ports: UDP/1645 for authentication and UDP/1646 for accounting. These predate the IANA-assigned ports 1812/1813. Modern RADIUS servers support both sets — but some legacy systems only listen on 1645/1646:

! ── Configure if RADIUS server uses legacy ports ─────────
NetsTuts_R1(config)#radius server LEGACY-RADIUS
NetsTuts_R1(config-radius-server)#address ipv4 192.168.10.62 auth-port 1645 acct-port 1646
NetsTuts_R1(config-radius-server)#key OldRADIUSkey@2026
NetsTuts_R1(config-radius-server)#exit

! ── Verify which ports are configured ────────────────────
NetsTuts_R1#show running-config | section radius server
radius server NPS-PRIMARY
 address ipv4 192.168.10.60 auth-port 1812 acct-port 1813
 key 7 ...
radius server LEGACY-RADIUS
 address ipv4 192.168.10.62 auth-port 1645 acct-port 1646
 key 7 ...

Always verify which port pair the RADIUS server is listening on before deployment. If the router sends to 1812 and the server listens on 1645, all authentication requests are silently discarded — the server never receives them. This appears identical to a network connectivity failure in show aaa servers (timeouts with no responses).

9. Verification

show aaa servers

NetsTuts_R1#show aaa servers
RADIUS Server - public:
  Server name: NPS-PRIMARY
  Server address: 192.168.10.60/1812
  Current status: UP
  Number of queries:      28
  Number of responses:    28
  Number of timeouts:      0
  Average response time:   8 ms

RADIUS Server - public:
  Server name: FREERADIUS-SECONDARY
  Server address: 192.168.10.61/1812
  Current status: UP
  Number of queries:       2
  Number of responses:     2
  Number of timeouts:      0
  Average response time:  11 ms

NPS-PRIMARY is handling the load (28 queries) with 0 timeouts — healthy operation. FREERADIUS-SECONDARY has 2 queries — these occurred during a brief window when the primary was being restarted. Both servers showing UP with matching query/response counts and 0 timeouts is the target state. Average response time of 8ms is excellent for a LAN-local server.

debug aaa authentication — Live RADIUS Trace

NetsTuts_R1#debug aaa authentication
AAA Authentication debugging is on

! ── Successful RADIUS login ──────────────────────────────
AAA/BIND(0000000A): Bind i/f
AAA/AUTHEN/LOGIN(0000000A): Pick method list 'RADIUS-AUTH'
RADIUS/ENCODE(0000000A): Acct session id [10]
RADIUS: Send Access-Request to 192.168.10.60:1812 id 21 len 89
RADIUS: Recv Access-Accept from 192.168.10.60:1812 id 21 len 64
RADIUS: Cisco-AVpair [26] shell:priv-lvl=15
AAA/AUTHEN(0000000A): status = PASS

! ── RADIUS server unreachable — fallback to local ────────
AAA/AUTHEN/LOGIN(0000000B): Pick method list 'RADIUS-AUTH'
RADIUS: Send Access-Request to 192.168.10.60:1812 id 22 len 89
RADIUS: Timeout for 192.168.10.60:1812 (retransmit 1)
RADIUS: Timeout for 192.168.10.60:1812 (retransmit 2)
RADIUS: Timeout for 192.168.10.60:1812 (retransmit 3)
RADIUS: No response from 192.168.10.60, trying FREERADIUS-SECONDARY
RADIUS: Timeout for 192.168.10.61:1812 (retransmit 1)
RADIUS: Timeout for 192.168.10.61:1812 (retransmit 2)
RADIUS: Timeout for 192.168.10.61:1812 (retransmit 3)
RADIUS: All servers exhausted, trying next method
AAA/AUTHEN: using method LOCAL
AAA/AUTHEN(0000000B): status = PASS  [local user: admin]

NetsTuts_R1#undebug all

The debug trace reveals the complete authentication flow in both scenarios. For the successful login: the RADIUS-AUTH method list was selected, an Access-Request was sent to NPS-PRIMARY on UDP/1812, and an Access-Accept was returned including the Cisco-AV-Pair with shell:priv-lvl=15 — user gets full privilege 15 access. For the fallback scenario: both RADIUS servers exhaust all retransmits, IOS advances to the local method, and the admin account is authenticated locally. undebug all turns off all debugging.

test aaa group — Live RADIUS Credential Test

! ── Test credentials against RADIUS server group ─────────
NetsTuts_R1#test aaa group RADIUS-SERVERS jsmith SecurePass456
Attempting authentication test to server-group RADIUS-SERVERS using radius
User was successfully authenticated.

! ── Test with wrong password ─────────────────────────────
NetsTuts_R1#test aaa group RADIUS-SERVERS jsmith WrongPass
Attempting authentication test to server-group RADIUS-SERVERS using radius
User was NOT successfully authenticated.

test aaa group for RADIUS does not require the legacy keyword that TACACS+ needs — RADIUS tests work without it. This command directly tests the server group without creating a management session. Comparing a successful test vs a failed test confirms: server reachability is fine, the shared key is correct, and user credentials are validated. If the test hangs then times out, the server is unreachable — not a credential issue.

show aaa method-lists authentication

NetsTuts_R1#show aaa method-lists authentication
authen queue=AAA_ML_AUTHEN_LOGIN
  name=default      :  state=ALIVE :
      Method list:   1. RADIUS-SERVERS group
                     2. LOCAL
  name=RADIUS-AUTH  :  state=ALIVE :
      Method list:   1. RADIUS-SERVERS group
                     2. LOCAL
  name=CON-AUTH     :  state=ALIVE :
      Method list:   1. LOCAL

show aaa local user lockout

NetsTuts_R1#show aaa local user lockout
No Locked Users

After repeated failed login attempts, IOS can lock out local accounts. show aaa local user lockout shows any locked accounts. Unlock with clear aaa local user lockout username [name] or clear aaa local user lockout all. This is important when testing fallback — if the local account gets locked due to multiple failed test attempts, the fallback itself will stop working.

show running-config | section radius

NetsTuts_R1#show running-config | section radius
radius server NPS-PRIMARY
 address ipv4 192.168.10.60 auth-port 1812 acct-port 1813
 key 7 045802150C2E1D1C5A
 timeout 5
 retransmit 3
radius server FREERADIUS-SECONDARY
 address ipv4 192.168.10.61 auth-port 1812 acct-port 1813
 key 7 045802150C2E1D1C5A
 timeout 5
 retransmit 3
aaa group server radius RADIUS-SERVERS
 server name NPS-PRIMARY
 server name FREERADIUS-SECONDARY
ip radius source-interface Loopback0
radius-server vsa send authentication
radius-server vsa send accounting

Verification Command Summary

Command	What It Shows	Primary Use
`show aaa servers`	RADIUS server status (UP/DOWN), query/response/timeout counters, response time	Primary health check — UP + 0 timeouts = healthy. Timeouts = unreachable
`debug aaa authentication`	Real-time AAA authentication events — method list selected, server queried, response received	Deep troubleshooting — trace exact path and server response for each login attempt
`test aaa group [group] [user] [pass]`	Live credential test against a server group — pass/fail without creating a session	End-to-end RADIUS verification — confirms reachability + key + credentials
`show aaa method-lists authentication`	All authentication method lists with ordered methods and state	Verify method lists exist with correct server group and fallback order
`show aaa local user lockout`	Lists any locally locked accounts	Check for and clear locked accounts after test failures
`show aaa sessions`	Active AAA-managed sessions with username and source IP	Confirm active sessions are attributed to named users

10. Troubleshooting RADIUS AAA Issues

Problem	Symptom	Cause	Fix
All RADIUS requests timing out	`show aaa servers` shows the server DOWN with mounting timeouts — logins fall back to local after long delay	RADIUS server unreachable — routing failure, wrong IP, ACL blocking UDP/1812, or server service not running. Also check: router is sending from a source IP not whitelisted as a NAS on the RADIUS server	Ping the RADIUS server from the router's loopback: `ping 192.168.10.60 source Loopback0`. Verify `ip radius source-interface` matches the NAS entry on the server. Check ACLs for UDP/1812 blocking. Verify RADIUS service is running on the server.
Server reachable but authentication fails	`show aaa servers` shows queries and responses but all logins return "Access denied" — no timeouts	Pre-shared key mismatch — the key on the router does not match the NAS client entry on the RADIUS server. The server discards requests it cannot decrypt, or returns Access-Reject	Verify key: `show running-config \| section radius server`. Compare with the NAS entry on the RADIUS server (NPS, ISE). Keys are case-sensitive — reconfigure both sides with identical keys. Use `debug aaa authentication` to see if Access-Accept or Access-Reject is returned.
Login succeeds but user gets privilege 1	RADIUS authentication passes but user lands at `Router>` prompt (privilege 1) instead of privilege 15	RADIUS VSA not configured — either `radius-server vsa send authentication` is missing, exec authorisation not configured, or the RADIUS server is not returning `Cisco-AV-Pair = shell:priv-lvl=15`	Add `radius-server vsa send authentication`. Configure `aaa authorization exec` method list and apply under VTY lines. Verify the RADIUS server user profile includes `Cisco-AV-Pair = shell:priv-lvl=15`.
RADIUS works with 1812 but not 1645	Migration to new RADIUS server fails — server responds but IOS gets no authentication on new server	Port mismatch — the router is configured with 1812/1813 but the new server listens on 1645/1646 (or vice versa)	Verify server listening ports in the RADIUS server configuration. Update IOS: `address ipv4 [IP] auth-port 1645 acct-port 1646`. Run `debug radius` to confirm which port requests are sent to.
Fallback to local not working	RADIUS times out but local account login also fails	Local account is locked out from repeated failed attempts, or the local account does not exist, or method list does not include `local`	Check `show aaa local user lockout` and clear if locked. Verify local user: `show running-config \| include username`. Confirm `local` is the last method in the authentication list.
Accounting records not reaching RADIUS	RADIUS server shows successful authentication events but no accounting records	UDP/1813 is blocked while UDP/1812 is permitted, or accounting is configured on a different port than the server expects	Verify UDP/1813 is not blocked by an ACL between the router and RADIUS server. Confirm accounting port in `show running-config \| section radius server`. Some RADIUS servers use 1646 for legacy accounting.

Key Points & Exam Tips

RADIUS uses UDP port 1812 for authentication/authorisation and UDP port 1813 for accounting. Legacy systems may use 1645/1646. Always confirm which ports the RADIUS server listens on before configuring.
RADIUS is an open standard (RFC 2865) — supported by all vendors. It is preferred for network access control (802.1X, VPN, wireless). TACACS+ is Cisco-proprietary and preferred for device administration.
RADIUS encrypts only the password field — all other attributes are sent in clear text. TACACS+ encrypts the entire payload. This is a key difference tested on the CCNA exam.
Privilege level assignment via RADIUS requires Cisco VSA (Vendor-Specific Attribute) — the server must return Cisco-AV-Pair = shell:priv-lvl=15. Requires radius-server vsa send authentication on the router.
The if-authenticated keyword in exec authorisation is RADIUS-specific — it grants exec access to any already-authenticated user without a separate authorisation query, when the privilege level is delivered in the authentication response.
RADIUS uses UDP — the retransmit command compensates for potential packet loss by specifying how many times to resend before marking the server unreachable. Total failover time = timeout × retransmit.
RADIUS does not support per-command authorisation — this is the exclusive capability of TACACS+. Choose TACACS+ when granular command-level control is required.
ip radius source-interface [loopback] ensures consistent source IP for all RADIUS packets — the RADIUS server's NAS entry must match this IP. Without it, the source IP may vary with routing changes.
test aaa group [group] [user] [pass] (without legacy keyword for RADIUS) is the fastest end-to-end verification — tests server reachability, shared key, and credential validation in one command.
On the CCNA exam: know RADIUS ports (1812/1813), what is encrypted (password only), the difference from TACACS+ (per-command auth, encryption level, transport), VSA requirement for privilege levels, and the retransmit vs timeout parameters.

Next Steps: RADIUS authentication is now centralised. For device administration requiring per-command authorisation, compare this configuration with AAA with TACACS+ Configuration. For reviewing authentication events and denied access attempts, check show logging. For securing the VTY lines that RADIUS now protects at the network level, add Standard ACL source-IP restrictions as a defence-in-depth layer — requiring both a whitelisted source IP and valid RADIUS credentials for management access.

TEST WHAT YOU LEARNED

1. What is the primary reason RADIUS is preferred over TACACS+ for 802.1X wireless and VPN authentication, while TACACS+ is preferred for network device administration?

A. RADIUS supports more simultaneous users — TACACS+ is limited to 100 concurrent sessions B. RADIUS is an open standard supported by all vendors — making it compatible with Windows NPS, FreeRADIUS, and wireless controllers from any vendor. TACACS+ is Cisco-proprietary and not universally supported. For device administration, TACACS+ is preferred because it supports per-command authorisation and full payload encryption C. RADIUS uses TCP for wireless reliability — TACACS+ uses UDP which is unsuitable for slow WAN links D. TACACS+ requires a Cisco ISE license — RADIUS works with any free server

Correct answer is B. RADIUS's status as an open IETF standard (RFC 2865) means it is implemented by every authentication server vendor — Microsoft NPS, FreeRADIUS, Juniper Steel-Belted Radius, Aruba ClearPass, and non-Cisco wireless infrastructure. For network access scenarios (802.1X, VPN, guest wireless) spanning multi-vendor environments, RADIUS is the only practical choice. TACACS+ is Cisco-proprietary and only available on Cisco ISE, Cisco ACS, and a few third-party implementations. For Cisco device administration specifically, TACACS+'s per-command authorisation, full payload encryption, and separated AAA transactions make it the superior choice. Most large enterprises run both: TACACS+ for device admin, RADIUS for network access.

2. Why must `radius-server vsa send authentication` be configured for RADIUS-based privilege level assignment to work?

A. It activates the RADIUS server to send authentication responses — without it, the server does not respond B. It enables UDP/1812 on the router's interface for RADIUS traffic C. It configures the RADIUS server with the Cisco-AV-Pair attribute automatically D. Without this command, IOS ignores Vendor-Specific Attributes (VSAs) in RADIUS responses — including the Cisco-AV-Pair = shell:priv-lvl=15 that carries the privilege level. Since RADIUS has no native privilege-level field (unlike TACACS+), the privilege level is delivered via VSA. If IOS discards VSAs, users always land at privilege 1 regardless of server policy

Correct answer is D. RADIUS is a generic protocol with standard attributes — privilege level assignment for Cisco devices is not a standard RADIUS attribute. Cisco delivers it through a Vendor-Specific Attribute (VSA), specifically attribute 26 containing Cisco-AV-Pair = shell:priv-lvl=15. IOS will not process VSAs unless explicitly told to with radius-server vsa send authentication. Without this command, the RADIUS server returns the Access-Accept with the privilege-level VSA, but IOS silently ignores the VSA and defaults to privilege 1. This is one of the most common RADIUS configuration mistakes — authentication works but all users get privilege 1.

3. A RADIUS server is configured with timeout 5 and retransmit 3. How long does IOS wait before declaring the primary RADIUS server unreachable and trying the secondary?

A. 15 seconds — IOS sends the initial request, waits 5 seconds, then retransmits up to 3 times. Total wait = 5 × (1 initial + 3 retransmits) = 20 seconds. Some implementations calculate it as timeout × retransmit = 5 × 3 = 15 seconds. IOS then moves to the secondary server B. 3 seconds — the retransmit value overrides the timeout for failover decisions C. 5 seconds — the timeout value is the total wait regardless of retransmit count D. 8 seconds — timeout + retransmit count = 5 + 3

Correct answer is A. Because RADIUS uses UDP (connectionless), packet loss is possible — the retransmit parameter compensates by resending requests that receive no response. With timeout=5 and retransmit=3, IOS sends the request and waits 5 seconds, then resends (retransmit 1) and waits 5 more seconds, resends (retransmit 2) waits 5 more, resends (retransmit 3) and waits 5 more. Total time before declaring the primary unreachable is approximately 15-20 seconds depending on IOS implementation. This is significantly longer than TACACS+ (TCP/5 seconds total — TCP's connection failure is near-immediate). The high failover time is one of RADIUS's practical drawbacks for interactive device management access.

4. What is the functional difference between `aaa authorization exec default group RADIUS-SERVERS local` and `aaa authorization exec default group RADIUS-SERVERS if-authenticated`?

A. local uses the local username database for authorisation; if-authenticated skips authorisation entirely B. They are identical — if-authenticated is just a newer alias for local C. With local as fallback, if the RADIUS server is unreachable for exec authorisation, IOS checks the local username's configured privilege level. With if-authenticated, any user who has already passed authentication is automatically granted exec access — no second query to RADIUS or local database is needed. if-authenticated is used when the privilege level comes bundled in the auth response via VSA D. if-authenticated only applies to console lines — VTY lines must use local

Correct answer is C. RADIUS combines authentication and authorisation in a single Access-Accept response — the privilege level VSA comes with the authentication reply. When if-authenticated is specified for exec authorisation, IOS grants exec access to any user who has already successfully authenticated, using whatever privilege level was delivered in the authentication response (via VSA). This avoids a redundant second RADIUS query for authorisation. With local as fallback, if RADIUS fails to authorise exec access (server unreachable for that second query), IOS checks the local user's configured privilege level. if-authenticated is appropriate when the RADIUS server reliably delivers the privilege level via VSA in the authentication response.

5. An engineer runs `test aaa group RADIUS-SERVERS admin SecurePass` and gets "User was NOT successfully authenticated." However, logging in to the router via SSH with the same credentials works. What is the most likely explanation?

A. The test command uses UDP while SSH uses TCP — RADIUS responds differently to each B. The test command bypasses the shared key — it only tests connectivity, not credentials C. RADIUS blocks credentials containing uppercase letters when tested from CLI D. The SSH login is succeeding via the local fallback — the RADIUS server is rejecting the credentials (or returning Access-Reject), but the method list falls back to local where the admin account exists. The test command tests RADIUS directly — its failure confirms the RADIUS server itself is not accepting these credentials for this user

Correct answer is D. This is an important diagnostic scenario. The test aaa group command directly queries the RADIUS server group — its result reflects only the RADIUS server's response. If it returns "NOT successfully authenticated," the RADIUS server is responding with Access-Reject (wrong password, account doesn't exist, or NAS restriction). However, SSH is still succeeding because the method list has local as the fallback — when RADIUS returns Access-Reject (or the admin isn't on the RADIUS server), IOS tries the local database where the admin account with matching credentials exists. This scenario reveals a misconfiguration: the RADIUS server doesn't have the admin account or the password doesn't match on the server side.

6. What is the purpose of `ip radius source-interface Loopback0` and what happens on the RADIUS server if it is not configured?

A. Forces all RADIUS packets to use the loopback IP as source — the RADIUS server must have this IP in its NAS (Network Access Server) client list. Without it, RADIUS requests may come from different physical interface IPs depending on routing. If the RADIUS server only whitelists the loopback IP, requests from unexpected source IPs are silently rejected as coming from an unknown NAS B. Encrypts the RADIUS packets using the loopback interface's IP as an encryption seed C. Restricts RADIUS authentication to loopback network — only loopback-connected devices can authenticate D. Routes RADIUS traffic through the loopback to reduce latency on LAN-connected servers

Correct answer is A. RADIUS servers typically maintain a NAS (Network Access Server) client table — only requests from IP addresses in this table are processed. Each NAS entry includes the client IP and shared key. If a router's RADIUS requests come from different source IPs (depending on which interface the packet exits), the RADIUS server may reject requests from IPs not in its NAS table as "unknown client" — the request is silently discarded. By configuring ip radius source-interface Loopback0, all RADIUS traffic always uses the loopback IP (e.g., 1.1.1.1). The RADIUS server NAS entry is configured with 1.1.1.1, and the shared key. This single consistent IP works regardless of physical interface state or routing changes.

7. A router is configured with `radius server NPS-PRIMARY` using `auth-port 1812`. The NPS server is configured to listen on UDP/1645. Logins time out and fall back to local. `show aaa servers` shows 0 responses. What is the fix?

A. Change NPS to listen on 1812 — 1645 is not supported on modern servers B. Add a second radius server entry pointing to the same IP on port 1812 C. Update the router's server entry to use the port that NPS actually listens on: address ipv4 192.168.10.60 auth-port 1645 acct-port 1646. The router is sending to 1812 but NPS only listens on 1645 — requests are silently dropped at the network stack level, appearing as timeouts D. Configure a PAT rule to redirect UDP/1812 to UDP/1645 on the router

Correct answer is C. Port mismatch is one of the most common RADIUS deployment errors. The router sends Access-Request packets to UDP/1812, but NPS is only listening on UDP/1645 — the OS on the NPS server discards the packets because nothing is bound to port 1812. From the router's perspective, this looks identical to a network connectivity failure: requests sent, no responses received, timeouts accumulate. The diagnostic approach: confirm NPS configuration to check which port it listens on (Server Manager → NPS → RADIUS Clients and Servers), then update the IOS configuration: radius server NPS-PRIMARY → address ipv4 192.168.10.60 auth-port 1645 acct-port 1646.

8. After testing RADIUS fallback by deliberately misconfiguring the server IP, an engineer notices the local admin account is now locked out. What command unlocks it?

A. aaa local authentication clear username admin B. clear aaa local user lockout username admin — or clear aaa local user lockout all to unlock all locked accounts simultaneously. Verify the result with show aaa local user lockout C. no aaa local user lockout D. The account must be deleted and recreated — lockouts cannot be cleared administratively

Correct answer is B. IOS tracks consecutive failed login attempts for local accounts and can lock them out after exceeding a configured threshold (configurable with aaa local authentication attempts max-fail). During RADIUS fallback testing with deliberate failures, the local admin account can get locked if multiple wrong-password attempts are made. The unlock command is clear aaa local user lockout username admin for a specific account or clear aaa local user lockout all for all locked accounts. After unlocking, verify with show aaa local user lockout which should show "No Locked Users". This is particularly important because a locked fallback account means no emergency access path exists if RADIUS also fails.

9. In `debug aaa authentication` output, what is the significance of seeing "RADIUS: Recv Access-Accept" vs "RADIUS: Recv Access-Reject"?

A. Access-Accept means the server acknowledged the request; Access-Reject means the request was malformed B. Access-Accept means the router's shared key matched; Access-Reject indicates a key mismatch C. Access-Accept means the server is online; Access-Reject means it needs a restart D. Access-Accept means the RADIUS server validated the credentials and grants access — it may include VSA attributes like shell:priv-lvl=15. Access-Reject means the server received and processed the request but denied authentication — wrong credentials, account disabled, or access policy violation. Critically, Access-Reject is a definitive server response — IOS does NOT fall back to the next method (local), unlike a timeout

Correct answer is D. The distinction between Access-Reject and a timeout is critical for understanding AAA fallback behaviour. Access-Accept = authentication granted (server is reachable and credentials are valid). Access-Reject = authentication denied by the server (server is reachable and processed the request, but the user failed policy). With Access-Reject, IOS treats this as a definitive failure and does not try the next method in the list — if the RADIUS server rejects credentials, IOS does not then try the local database as a "second chance." Method list fallback (to local) only occurs when the server is unreachable — no response, timeout. A timeout appears in debug as "RADIUS: Timeout" with retransmit attempts. Understanding this distinction is essential for diagnosing whether AAA failures are connectivity issues or credential/policy issues.

10. A network engineer needs to implement AAA for a new deployment. The requirements are: (1) per-command authorisation to control which IOS commands each engineer can run, (2) full audit log of every command on every device, (3) multi-vendor environment including Cisco, Juniper, and HP switches. Which AAA protocol and why?

A. RADIUS — it is the open standard and the only protocol supported on non-Cisco devices B. TACACS+ — it supports per-command authorisation and full encryption, and is available on all modern network equipment including Juniper and HP C. This requires a hybrid approach — TACACS+ for Cisco devices (per-command authorisation, full encryption, command accounting) and RADIUS for Juniper and HP devices (which typically do not support TACACS+). A server like Cisco ISE supports both protocols simultaneously from the same policy engine D. Local authentication on each device — no single protocol meets all requirements in a multi-vendor environment

Correct answer is C. This is a real-world enterprise architecture decision. Requirements 1 and 2 (per-command authorisation and command audit logging) are exclusively TACACS+ capabilities — RADIUS cannot do per-command authorisation. However, Juniper and HP network devices typically do not support TACACS+ — their device administration AAA uses RADIUS. The practical solution is running both protocols simultaneously on a server like Cisco ISE or Cisco ACS: TACACS+ for all Cisco devices (full per-command control and audit), RADIUS for non-Cisco devices (privilege-level based access with session accounting). ISE can apply unified policies across both protocols, delivering as much control as each protocol supports on each vendor platform. This hybrid approach is standard in large enterprise environments.

Back to Home