When an ISP is running a large number of systems at 99% idle capacity "just in case," you know there's room for optimization.
We worked with a multi-service provider that had built four separate RADIUS servers for four different network offerings. This overbuild resultedin four times the necessary network hardware and operational overhead. We helped them consolidate their RADIUS proxy architecture without sacrificing the reliability that their customers depend on.
The problem: Duplicate effort and wasted money
Our client, a multi-service ISP, had taken a well-intentioned but cautious approach to network authentication. For each service they offered (WiFi, DSL, and others) they had implemented completely separate RADIUS infrastructures, each with separate maintenance schedules and procedures.
That meant multiple policy configurations covering identical scenarios and significantly higher operational costs than necessary.
They had optimized for improbable worst-case scenarios while creating real daily operational burdens that were affecting their operational budget and team efficiency.
Why ISPs over-provision network infrastructure (and when it makes sense)
Before diving into our solution, it's worth understanding why this ISP had built such redundant network systems. ISP customer authentication is a different beast than most other network operations.
ISPs must run RADIUS systems at about 1% busy capacity. Servers sit 99% idle most of the time, but when lightning hits a transformer, 200,000 people may go offline. Ten minutes later, those 200,000 people will try to reconnect at the same time. The RADIUS server needs to ramp from near-zero traffic to the maximum load essentially instantly.
Unlike cloud services that can take 10 seconds or more to spin up, network authentication can't wait. The cost of angry customer calls exceeds the cost of idle network hardware by orders of magnitude.
But our client had missed a critical insight: What are the odds that WiFi, DSL, and all other services would experience simultaneous outages? In most cases, practically zero—unless power goes out for an entire city. And if that happens, people have bigger concerns than internet connectivity taking an extra five minutes to restore.
The solution: A strategy for RADIUS proxy consolidation
Our client had two paths forward when upgrading to our RADIUS proxy solution:
- Option 1: Maintain multiple servers—Keep the existing server architecture while implementing shared configuration management.
- Option 2: Consolidate to a single server—Replace multiple RADIUS systems with one robust multi-server system featuring isolated "walled gardens".
The client chose Option 2, which would maintain service separation without hardware duplication.
Implementation: A walled garden architecture for network systems
Our consolidated approach created isolated environments within a single RADIUS proxy system. Each service type operates in its own “virtual server” protected space where policies cannot interfere with each other. This “virtual server” technology is not a VM solution, but is instead a set of virtualized policies within the RADIUS server. FreeRADIUS is the only RADIUS server which has this functionality!
This solution then uses a shared infrastructure without shared risks. The different virtual severs can have independent policies, while sharing connections to databases. The result is further decreased costs and system loads.
Results: Better customer authentication, lower operational costs
The consolidated RADIUS proxy architecture delivered something that every ISP dreams of: better performance with lower costs. They were also pleased to discover how much better things got once everything was working together instead of operating in isolation. Fewer systems meant less work, and lower chance of outages.
The reliability boost
Before consolidation, each server was making failover decisions based only on what it could see locally.
Imagine four security guards at different entrances to a building, each deciding independently whether to sound an alarm, with no way to communicate with each other. Sometimes they'd all panic at once, sometimes none of them would react to a real problem.
After consolidation, suddenly all the "guards" could talk to each other. When one service area detected an issue, the entire system could coordinate its response. Failover happened faster, fail-back was smoother, and the whole authentication process became more intelligent.
Instead of four separate systems occasionally stepping on each other, we had one smart system that could see the big picture.
A noticeable difference to customers
Login problems across all services dropped significantly, which translated directly into happier customers and fewer frustrated calls to support.
The network operations team found they could troubleshoot issues faster because they only had one system to understand instead of juggling multiple separate architectures. When something did go wrong, they could fix it in one place instead of hunting through four different configurations.
Better for the business
Yes, hardware costs dropped—that was the initial win. The ongoing benefit was in operational efficiency. Maintenance became simpler, troubleshooting became faster, and most importantly, the technical team could stop playing whack-a-mole with multiple systems and start focusing on actually growing the business. When you're not constantly firefighting duplicate infrastructure, amazing things happen to productivity.
Expert insights on network infrastructure optimization for ISPs
Q: How do you balance network infrastructure optimization with reliability requirements?
Alan DeKok, CEO InkBridge Networks: "The key is understanding the difference between smart redundancy and wasteful redundancy. This client was protecting against scenarios that would never happen while creating real operational problems that happened every day. True network infrastructure optimization means identifying where redundancy adds value and where it just adds cost."
Q: What's the biggest mistake ISPs make with RADIUS systems and network infrastructure planning?
"They optimize for the wrong metrics. Everyone focuses on 'what if we get overwhelmed with traffic?' The real question is: 'what if we have to maintain four separate systems instead of one?'
The operational overhead of multiple network systems causes more downtime than traffic spikes ever will. Smart network infrastructure optimization considers the total cost of ownership, not just the theoretical maximum capacity."
Q: How does consolidation affect network security best practices?
"Consolidation actually improves security when done correctly. Instead of managing security measures across multiple separate systems—each with their own potential vulnerabilities—you have one hardened system with consistent security policies. It's much easier to implement network security best practices across a single, well-designed architecture than across multiple disparate systems."
Key lesson: smart beats complicated
Here's what this client case study really proves: more redundancy doesn't always mean more reliability. Sometimes the best path to bulletproof infrastructure runs straight through simplification.
The lesson for ISPs? Stop optimizing for disasters that will never happen. Start optimizing for the problems that hit you every single day: operational overhead, maintenance complexity, and resource allocation. When your engineers aren't babysitting four separate systems, they can focus on growing your business.
Need more help?
InkBridge Networks has been at the forefront of network authentication for over two decades, helping ISPs and enterprises improve network performance while maintaining the security measures their customers depend on. Our team has solved nearly every conceivable challenge that comes with managing large-scale customer authentication systems.
Are you dealing with infrastructure that feels more complicated than it should be? Request a quote for network solutions here.
Related Articles
Email addresses are primary user identifiers?
There is a lot of advice out there that email addresses are not identifiers. Even Internet2 has a document explaining why email is not an appropriate user identifier. What does this mean for RADIUS, especially since RFC 7542 allows using email addresses as identifiers? Speaking as the author of RFC 7542, I think I can help you.
IETF Bangkok 122 recap: What we're doing to advance RADIUS standards
I've recently returned from IETF Bangkok, the Internet Engineering Task Force (IETF) 122 meeting, where I spent a week working with implementers, operators, and standards authors who are defining the future of RADIUS and other network protocols.