A company runs three policy service nodes serving 250 access switches for 802.1X. Administrators report that user sessions occasionally restart mid-morning even though no node has failed, and RADIUS load counters show nearly all traffic landing on one node. Which load balancing design for the policy service nodes would restore both distribution and session continuity?
Select an answer to reveal the explanation.
Short Explanation
You can use a RADIUS-aware load balancer with Calling-Station-ID persistence to spread sessions across your policy service nodes while keeping each user's exchange on the same node. Think of it as keeping your place in line, so your session stays with the node that holds its state.
Full Explanation
An 802.1X authentication can involve multiple Access-Request and Access-Challenge rounds, so a RADIUS-aware load balancer can distribute sessions across healthy policy service nodes (PSNs) while using Calling-Station-ID persistence to keep a client’s requests on the same PSN during an exchange. This supports both balanced traffic and session continuity. Listing all three PSN addresses in a switch’s RADIUS server group provides redundancy if a node stops, but does not itself ensure balanced distribution or session affinity. Resolving a shared FQDN with round-robin DNS may spread some requests, but it does not guarantee that follow-up RADIUS packets reach the PSN holding the exchange state. Configuring one PSN as primary and another as standby provides redundancy, but does not distribute normal traffic across both nodes. One caveat is that persistence should use a suitable RADIUS attribute, such as Calling-Station-ID, rather than relying only on source IP, which may be shared by many clients. To check the design in practice, compare per-node RADIUS counters across multiple sessions and confirm that traffic is distributed while each exchange remains on one PSN.