A municipal hospital campus WAN places RADIUS in a management VRF, but routers never reach the AAA host. Which troubleshooting focus is most appropriate first?
Select an answer to reveal the explanation.
Short Explanation
If RADIUS lives in the management VRF, the router has to send AAA packets out that door—wrong source interface or VRF and the hospital AAA host never hears you.
Full Explanation
When a municipal hospital campus WAN places RADIUS in a management VRF but routers never reach the AAA host, troubleshoot VRF-aware AAA and source-interface first. Requests must egress the management VRF with a source the RADIUS host and routing table expect; wrong VRF, missing aaa or server VRF binding, or a source-interface in the data table sends packets into a black hole away from the hospital AAA cluster.
Increasing OSPF reference bandwidth on unrelated data VRFs does not fix RADIUS UDP delivery to a management-VRF host. Disabling aaa new-model so RADIUS supposedly bypasses VRF routing is not a valid fix and removes AAA control. Replacing RADIUS with NHRP authentication does not solve IP reachability to an AAA host and confuses VPN mapping authentication with device administration AAA on the hospital edge.
Exam caveat: management-VRF AAA failures are usually routing, source-interface, or VRF binding—not IGP reference bandwidth. Operational check: ping or traceroute the RADIUS host from the router in the management VRF context, confirm aaa group/server VRF and radius source-interface, verify UDP reaches the host on the configured ports, then retest hospital admin login. In practice, capture before-and-after outputs in the municipal ticket so the chosen fix is proven against the distractors, and re-check overlay or AAA health after the change window closes.