Thank you for your post. Listed below are some work arounds that might help with your Radius agent configuration.
Load Balancing and High Availability
Concern: Many RADIUS client devices only support active/passive RADIUS high-availability.
Active/Passive means that only one RADIUS agent is used for all traffic until that agent fails, then all traffic fails over to the second agent.
From a capacity planning perspective all traffic goes to one agent. Any failover agent API token could expire if it is not used for 30 days!
Potential workaround: Leverage a load balancer like F5 or Netscaler A load balancer should help with all of the concerns above. Traffic will be distributed across multiple agents which increases potential throughput.
None of the agents are sitting idle which means the API tokens are less likely to expire.
Alternate method for keeping a passive RADIUS agent alive would be to run a script on Linux that makes a call to the RADIUS agent every 3 days using Radtest.
Radtest is part of the FreeRADIUS project and can be run from the CLI radtest -t pap username password 192.168.0.65:1812 0 <PreSharedKey> Even invalid credentials will keep the agent token alive.