Hands-On Lab: Configuring AAA with a RADIUS Server

This hands-on lab configures AAA authentication against an external RADIUS server, defines a method list that tries RADIUS first with local authentication as a fallback, and verifies the fallback activates correctly when the RADIUS server becomes unreachable.

RADIUS Server ConfigurationAAA Fallback MethodCentralized Authentication

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Configure a router to authenticate VTY access against an external RADIUS server, define a method list with local authentication as a fallback, and verify both the primary RADIUS path and the fallback path function correctly.

Lab Purpose

Centralized authentication against a RADIUS server allows an organization to manage credentials for potentially hundreds of network devices from one place, rather than maintaining separate local username databases on every device, discussed in the previous lab, which becomes unmanageable at scale.

Lab Topology

R1 ---- Gi0/0: 192.168.62.1/24

RADIUS server: 192.168.62.100
Shared secret: RadiusKey2026

Local fallback username already configured
from the previous lab: netadmin

Task 1: Configure the RADIUS Server

Configure R1 with the RADIUS server's address and shared secret.

Task 2: Create a Method List Using RADIUS with Local Fallback

Create a method list named MGMT-RADIUS trying RADIUS first, falling back to local if RADIUS is unreachable.

Task 3: Apply the Method List to the VTY Lines

Apply MGMT-RADIUS to the VTY lines.

Task 4: Verify Authentication via RADIUS

Confirm a login attempt with valid RADIUS credentials succeeds and is authenticated by the RADIUS server.

Task 5: Simulate RADIUS Server Failure and Verify Fallback

Make the RADIUS server unreachable, then confirm login still succeeds using the local username as a fallback.

Solution and Verification

R1(config)# radius server MAIN-RADIUS
R1(config-radius-server)# address ipv4 192.168.62.100
R1(config-radius-server)# key RadiusKey2026

R1(config)# aaa authentication login MGMT-RADIUS group radius local

-- This tries the "radius" group first; if
-- and only if the RADIUS server is entirely
-- unreachable (not simply rejecting bad
-- credentials), it falls back to "local"

R1(config)# line vty 0 15
R1(config-line)# login authentication MGMT-RADIUS

ManagementPC> ssh -l raduser 192.168.62.1

Password: [valid RADIUS password]
R1>
-- Login succeeded, authenticated against
-- the RADIUS server

R1# debug aaa authentication

-- (during the successful login above)
AAA/AUTHEN: Method=RADIUS
RADIUS: Received from id 21 ... Access-Accept

-- Simulating RADIUS unreachability by
-- shutting down the interface facing it,
-- or by configuring an incorrect server
-- address temporarily:

R1(config)# radius server MAIN-RADIUS
R1(config-radius-server)# address ipv4 192.168.62.199

ManagementPC> ssh -l netadmin 192.168.62.1

Password: NetAdmin2026
R1>
-- Login still succeeded, this time via the
-- local fallback, since RADIUS at the now-
-- incorrect address never responded at all

Key Takeaway

The fallback to local authentication only activates when the RADIUS server is genuinely unreachable (no response at all), not when it actively rejects invalid credentials — this distinction matters because a user mistyping their RADIUS password should be denied access, not silently authenticated instead through the local fallback, and AAA's method list design correctly preserves this distinction.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه