VRF-aware RADIUS with DNAC
DNAC is currently not designed to be VRF-aware with its Network Settings. The AAA server settings are configured with global context regardless of the device management IP being in a VRF.
Here is what DNAC provisions for RADIUS:
aaa new-model
aaa authentication login default local
aaa authentication login dnac-cts-list group dnac-client-radius-group local
aaa authentication dot1x default group dnac-client-radius-group
aaa authorization exec default local
aaa authorization network default group dnac-client-radius-group
aaa authorization network dnac-cts-list group dnac-client-radius-group
aaa accounting Identity default start-stop group dnac-client-radius-group
aaa accounting update newinfo periodic 2880
!
aaa server radius dynamic-author
client 10.0.0.111 server-key <secret>
client 10.0.0.112 server-key <secret>
!
radius server dnac-radius_10.0.0.111
address ipv4 10.0.0.111 auth-port 1812 acct-port 1813
timeout 4
retransmit 3
automate-tester username dummy ignore-acct-port probe-on
pac key <secret>
!
radius server dnac-radius_10.0.0.112
address ipv4 10.0.0.112 auth-port 1812 acct-port 1813
timeout 4
retransmit 3
automate-tester username dummy ignore-acct-port probe-on
pac key <secret>
!
radius-server attribute 6 on-for-login-auth
radius-server attribute 6 support-multiple
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server attribute 31 mac format ietf upper-case
radius-server attribute 31 send nas-port-detail mac-only
radius-server dead-criteria time 5 tries 3
radius-server deadtime 3
!
aaa group server radius dnac-client-radius-group
server name dnac-radius_10.0.0.111
server name dnac-radius_10.0.0.112
ip radius source-interface Loopback0
!
ip radius source-interface Loopback0
Here my ISE PSNs are 10.0.0.111 and .112
DNAC correctly configures Loopback0 as the source interface as this is the interface with the IP DNAC manages the device on. Notice the redundant configuration of the source interface for RADIUS. We have the source interface defined both under the RADIUS server group and in global. I’ll show the options for this in a bit.
The issues is that the configuration is for the global context of the device. If Loopback0 is in a VRF, the configuration will not work.
If you configure the dnac-client-radius-group RADIUS group to be in your management VRF, let’s call it vn001 for this example, the RADIUS servers will never come up. Let’s have a look at this. The config would be:
aaa group server radius dnac-client-radius-group
server name dnac-radius_10.0.0.111
server name dnac-radius_10.0.0.112
ip vrf forwarding vn001
ip radius source-interface Loopback0 vrf vn001
!
ip radius source-interface Loopback0 vrf vn001
If we return to the redundant source interface configuration, here is the explanation from the config guide:
With both options configured, the priority is given to the group-specific source interface configuration. I have chosen to keep both options as this is what DNAC configures and I do not want to deviate too much from this.
You will find documentation of the above configuration in the Security section of the configuration guide:
Configuring RADIUS Source-Interface Under a RADIUS Server-Group
And in the command line reference:
Despite the correct VRF-aware configuration, you’ll find that both RADIUS servers are DEAD:
Switch#show aaa servers | in State:|SMD:|10.0.0.11[12]
RADIUS: id 3, priority 1, host 10.0.0.111, auth-port 1812, acct-port 1813, hostname dnac-radius 10.0.0.111
State: current DEAD, duration 949808s, previous duration Os
Platform State from SMD: current DEAD, duration 949808s, previous duration 0s
RADIUS: id 4, priority 2, host 10.0.0.112, auth-port 1812, acct-port 1813, hostname dnac-radius 110.0.0.112
State: current DEAD, duration 949805s, previous duration 0s
Platform State from SMD: current DEAD, duration 949805s, previous duration Os
Switch#
This is despite reachability to the RADIUS servers is OK:
Switch#ping vrf vn001 10.0.0.111 source lo0
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 10.0.0.111, timeout is 2 seconds:
Packet sent with a source address of 100.127.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/12 ms
Switch#ping vrf vn001 10.0.0.112 source lo0
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 10.0.0.112, timeout is 2 seconds:
Packet sent with a source address of 100.127.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 m
Switch#
If you debug radius you’ll see that the automate-tester uses an incorrect source IP (from an interface in global). There is a known bug for the automate-tester not being VRF-aware:
CSCvs80192 - Cat9K Radius Automated Tester is not VRF-Aware
To fix this issue with dead RADIUS servers, we must make the automate-tester VRF-aware. NOTE! You must run 17.4.1 or later IOS XE release.
Here is a link to the 17.4.x release notes:
Software Features in Cisco IOS XE Bengaluru 17.4.1
radius server dnac-radius_10.0.0.111
automate-tester username dummy ignore-acct-port probe-on vrf vn001
!
radius server dnac-radius_10.0.0.112
automate-tester username dummy ignore-acct-port probe-on vrf vn001
NOTE! The “VRF Aware RADIUS Automated Testing” feature requires global RADIUS source interface definitions! You’ll find the specific documentation here:
VRF Aware RADIUS Automated Testing
Wait for ~5 minutes and both RADIUS servers should be up. Terminal monitor should reveal this or just keep looking at your log. You’ll see something like this:
000191: *Nov 9 2022 14:34:33.219 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server 10.0.0.111:1812,1813 is not responding.
000192: *Nov 9 14:34:33.286: Request successfully sent to PAC Provisioning driver.
000193: *Nov 9 2022 14:34:33.373 UTC: %RADIUS-4-RADIUS_DEAD: RADIUS server 10.0.0.112:1812,1813 is not responding.
000194: *Nov 9 14:34:42.367: Request successfully sent to PAC Provisioning driver.
000200: *Nov 9 2022 14:37:33.231 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server 10.0.0.111:1812,1813 is being marked alive.
000201: *Nov 9 2022 14:37:33.382 UTC: %RADIUS-4-RADIUS_ALIVE: RADIUS server 10.0.0.112:1812,1813 is being marked alive.
Oh, and don’t forget to fix the VRF-awareness for for CoA as well:
aaa server radius dynamic-author
client 10.0.0.111 vrf vn001
client 10.0.0.112 vrf vn001
The official configuration guide for CoA:
My suggestion is to create a DayN template in DNAC and provision it to add VRF-awareness to the RADIUS configuration DNAC pushes if you have your management in a VRF. Don’t forget to do the same with TACACS+ if you use that.
Conclusion
Configuring VRF-aware RADIUS with DNAC is a matter of finding the correct documentation and creating a DayN template for DNAC to push after it has added the global context RADIUS configuration.
We configure redundant source interfaces for RADIUS. One is in the server group and one is in global. The VRF Aware RADIUS Automated Testing” feature required the RADIUS source interface be defined in global! Good thing I choose to keep both configs even though they look redundant. This is just how Cisco has chosen to implement VRF-aware RADIUS capabilities in IOS XE.
You might want to look into TACACS+ if you use that feature for device administration. This is less complex to configure.
I hope you found this short documentation useful.
