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:
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 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 126.96.36.199 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:
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:
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:
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.
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.