RADIUS সার্ভার হাই অ্যাভেইলেবিলিটি: Active-Active বনাম Active-Passive

# RADIUS Server High Availability: Active-Active vs Active-Passive ## Purple Technical Briefing — Podcast Script (~10 minutes) --- **PART 1 — INTRODUCTION & CONTEXT (approx. 1 minute)** Welcome to the Purple Technical Briefing. I'm your host, and today we're tackling one of the most consequential infrastructure decisions for any organisation running enterprise WiFi: RADIUS server high availability. If you're a network architect or IT director responsible for authentication infrastructure at a hotel group, a retail chain, a stadium, or a public-sector facility, this briefing will give you the frameworks and the specific technical detail you need to make the right call — and avoid the mistakes that cause authentication outages at the worst possible moment. Let me set the scene. RADIUS — Remote Authentication Dial-In User Service — is the gatekeeper to your network. Every time an employee connects via 802.1X, or a guest authenticates through your captive portal, RADIUS is the engine checking credentials and authorising access. It's the backbone of IEEE 802.1X and WPA3 enterprise deployments. And unlike most IT services that degrade gracefully when they fail, RADIUS is binary: it either works, or nobody gets on the network. That asymmetry is what makes high availability so critical. --- **PART 2 — TECHNICAL DEEP-DIVE (approx. 5 minutes)** Let's start with the fundamentals. RADIUS operates over UDP — typically port 1812 for authentication and 1813 for accounting. The stateless nature of UDP is actually an advantage for HA design: because each authentication request is self-contained, any server in a cluster can handle any request without needing to know what happened before. This is the architectural property that makes active-active deployments so elegant. Now, there are two primary high-availability models you need to understand. **Active-Passive** is the traditional approach. You have a primary RADIUS server handling all authentication traffic, and a secondary server sitting in standby, receiving replicated data but not processing requests. When the primary fails, the Network Access Device — your access point, your switch, your VPN gateway — detects the failure and redirects traffic to the secondary. How long does that failover take? This is where the specifics matter. The NAS sends a RADIUS request and waits. The default packet timeout is typically two seconds. After that, it retries — usually three attempts per server. With two servers configured, you're looking at a maximum failover detection time of around six to twelve seconds in a well-tuned deployment. In a worst-case scenario with three servers and default timers, that can stretch to eighteen seconds. For a hotel guest trying to connect at check-in, or a retail associate trying to process a transaction, that's a painful window. **Active-Active** is the more sophisticated approach, and for most enterprise deployments it's the right one. Both — or all — RADIUS servers are processing authentication requests simultaneously. Traffic is distributed across the cluster either by round-robin rotation or by a dedicated load balancer. When one node fails, the remaining nodes absorb its traffic immediately. There is no failover detection delay because there is no failover in the traditional sense: the load balancer simply stops sending requests to the unhealthy node, typically within one to two seconds based on health-check intervals. The performance benefits compound. In a large venue — think a 60,000-seat stadium or a conference centre hosting a major exhibition — you can see thousands of simultaneous authentication requests when doors open or a session break occurs. A single RADIUS server, even a well-specified one, can become a bottleneck. An active-active cluster scales horizontally: add another node and you add proportional capacity. Now, let's talk about the database layer, because this is where many deployments get into trouble. RADIUS authentication itself is largely stateless — the server checks credentials against a directory and returns an Accept or Reject. But RADIUS accounting is stateful: it tracks session start, interim updates, and session stop events. If you're using accounting for billing, compliance logging, or session management, you need that data to be consistent across all nodes. The standard approach is to back your RADIUS cluster with a replicated database. FreeRADIUS, the world's most widely deployed open-source RADIUS server, integrates with MySQL and MariaDB. For active-active deployments, you have two main options: MySQL NDB Cluster, which provides synchronous multi-master replication with sub-second failover, or Galera Cluster, which offers similar synchronous replication with slightly simpler operational management. Both eliminate the risk of data loss on node failure. Asynchronous replication — standard MySQL primary-replica — is cheaper but introduces a replication lag that can result in lost accounting records if the primary fails before changes are replicated. Let me address the question of geographic distribution, because this is increasingly relevant for multi-site operators. If you're running a retail chain with 200 stores, or a hotel group with properties across multiple countries, the question isn't just "how do I make my RADIUS server redundant?" — it's "where should my RADIUS servers be located relative to my access points?" Backhauling authentication traffic from a remote site to a central data centre introduces WAN latency and a single point of failure at the WAN link. If that link goes down, the remote site cannot authenticate anyone, regardless of how redundant your central RADIUS cluster is. The solution is either to deploy local RADIUS instances at each site — which creates significant operational overhead — or to use a cloud RADIUS service with geographically distributed edge nodes. Cloud RADIUS platforms solve the HA problem at the architectural level. Rather than you building and managing redundant infrastructure, the provider operates RADIUS across multiple availability zones and regions. Failover between nodes happens automatically, typically in under one second, because it's handled by the platform's internal load balancing rather than by NAS retry timers. The SLA commitments from enterprise cloud RADIUS providers are typically 99.99% uptime — that's less than 53 minutes of downtime per year. There's an important compliance dimension here as well. PCI DSS requires strong authentication controls for cardholder data environments. GDPR treats authentication logs as personal data, requiring appropriate handling and data residency controls. Cloud RADIUS providers typically hold SOC 2 Type II certifications and offer GDPR data processing agreements with regional data residency options. On-premise deployments give you full control over data location, which matters in healthcare environments under NHS data governance frameworks, or in government facilities with data sovereignty requirements. --- **PART 3 — IMPLEMENTATION RECOMMENDATIONS & PITFALLS (approx. 2 minutes)** Let me walk you through two real-world scenarios that illustrate these principles in practice. First: a European hotel group with 45 properties across six countries. Their IT team of three engineers was running FreeRADIUS on virtual machines at each property — 45 separate instances to patch, monitor, and maintain. When a TLS certificate expired at one property, it caused a complete guest WiFi outage during a major conference. The fix required an engineer to remote in and manually renew the certificate — a process that took 40 minutes while guests were unable to connect. After migrating to a cloud RADIUS service with centralised policy management, the team eliminated per-site maintenance entirely. Certificate rotation became automatic. The three engineers reclaimed roughly 40 percent of their time previously spent on RADIUS operations. More importantly, the platform's active-active architecture across multiple cloud regions meant that a single node failure — which previously would have caused a site outage — became a non-event. Second scenario: a national sports stadium hosting 60,000 fans for a major event. The network team had deployed an active-passive RADIUS configuration with a primary server and a hot standby. During a pre-event load test, they discovered that the primary server was becoming saturated during the authentication surge when gates opened — processing 8,000 authentication requests per minute. The passive secondary was sitting idle while the primary struggled. The solution was to reconfigure the NAS devices to use round-robin load balancing across both servers, effectively converting the deployment to active-active. Authentication throughput doubled immediately. They also added a third server to provide headroom for the peak load, and configured Galera Cluster replication for the accounting database. The result was a deployment that could absorb the loss of any single node without any user-visible impact. Now, the pitfalls. The most common mistake is treating the secondary RADIUS server as a "set and forget" backup. Configurations drift. Certificates expire on the secondary while the primary is running fine. When the primary eventually fails and the secondary takes over, it fails too — for a completely different reason. The fix is simple: test your failover regularly, at least quarterly, and treat both nodes as production systems. The second pitfall is neglecting the database replication lag. If you're using asynchronous replication and your primary database node fails, you may lose accounting records for sessions that were active at the moment of failure. For PCI DSS compliance, this is a serious gap. Use synchronous replication — Galera or NDB — for any deployment where accounting data integrity is a compliance requirement. --- **PART 4 — RAPID-FIRE Q&A (approx. 1 minute)** Let me address the questions I hear most often from network architects. "What's the minimum viable HA configuration?" Two RADIUS servers with active-passive failover, shared secret synchronisation, and a replicated database backend. That's your floor. For anything above 500 concurrent users, move to active-active. "Can I use a hardware load balancer for RADIUS?" Yes, but RADIUS uses UDP, and many load balancers are optimised for TCP. Ensure your load balancer supports UDP load balancing with health checks. HAProxy Enterprise has a dedicated RADIUS UDP module. F5 BIG-IP handles it natively. "How do I handle EAP certificate trust in an HA cluster?" All nodes must present the same server certificate, or at minimum certificates from the same CA chain. Clients validate the server certificate during EAP-TLS and PEAP handshakes — if nodes present different certificates, you'll see authentication failures after failover. "Does cloud RADIUS work with on-premise Active Directory?" Yes, via a lightweight connector or LDAP proxy that queries your local AD without exposing it directly to the internet. This is the standard integration pattern for hybrid environments. --- **PART 5 — SUMMARY & NEXT STEPS (approx. 1 minute)** Let me close with the key decisions you need to make. If you're running fewer than 500 concurrent users at a single site with a stable team to manage infrastructure, active-passive with a well-tested failover procedure is a defensible choice. Keep it simple, test it regularly, and use synchronous database replication. If you're running a multi-site estate, a high-density venue, or if your team's bandwidth is constrained, active-active is the right architecture — and cloud RADIUS is the fastest path to getting there without building the infrastructure yourself. Whatever model you choose, the principles are the same: distribute rather than duplicate, automate failover decisions, and test your failure scenarios before they test you. For more on how Purple's platform handles RADIUS authentication at scale — including integration with 802.1X, WPA3 enterprise, and guest WiFi portals — visit purple.ai. Until next time. --- *End of script. Approximate reading time at 150 words per minute: 10 minutes.*