The hardest problems in running eduroam at national scale have almost nothing to do with RADIUS. They are problems of architecture.
Alan DeKok, CEO and Founder, InkBridge Networks
Running eduroam RADIUS at national scale is a different job from setting it up for a single campus. Any university IT team can stand up a RADIUS server, point direct their access points at it, and join the federation.
Once you are the operator carrying authentication traffic for dozens or hundreds of institutions, though, the problems you run into have surprisingly little to do with RADIUS itself. They are architecture problems: how you distribute load, how you handle failover between sites, and how you keep the whole system simple enough to support.
What an eduroam RADIUS deployment has to do
eduroam is a worldwide federation of RADIUS servers. When someone from one institution connects at another, the visited network forwards the authentication request back to the user’s home server, which does the actual authentication; the visited site handles authorisation and grants access. As a national operator you sit in the middle of that, proxying requests between your member institutions and out to the rest of the world.
What RADIUS server does eduroam use?
Most of the eduroam federation runs on FreeRADIUS, which we build and maintain. The mechanics for a deployment are well understood. The hard part is doing it at scale without the whole system becoming fragile.
Why multiple sites cause more problems than they solve
The instinct when you want resilience is to run several RADIUS servers on several IP addresses and let clients fail between them.
In practice, client failover is a disaster. All you can really depend on is that an access point, a supplicant, or an NPS box sends packets to a RADIUS server and hopes it is the right one.
If a client does support primary and secondary servers, it might fail over quickly, and it very often does not fail back.
Weeks later you look at your traffic and find 90% of it landing on one server, while the other sits nearly idle. That is the worst position to be in: if the busy server goes down, it takes most of your authentication with it.
RADIUS has no negotiation layer, so you cannot ask a client to rebalance. The system design has to take that control away from the client.
How does eduroam RADIUS work at scale?
One approach that we recommend is a single live IP address at each of two sites, with a load balancer sitting in front of the RADIUS servers at each one. The load balancer does one job, and it should do as little as possible: take incoming packets, do some hashing, and send the packets across the network to a backend server.
The load balancer does not need to decode the packet, run policy, or act as a full RADIUS server itself. That is deliberate. A load balancer that only forwards packets can run at wire rate (tens or hundreds of thousands of packets a second) and it decouples the live IP address from the servers doing the real work.
Several general-purpose load balancers handle this well; for the TLS-based transport we will come to shortly, HAProxy is one option because it can terminate the connection and forward plain TCP to the backends. Once you have that single IP and a simple load balancer at each site, you have most of the scalability you will ever need.
Some very large operators go further and use IP anycast, playing games with routing so that one advertised address is served by many sites and the routing layer handles failover. It is a legitimate technique, but for most eduroam operators it adds an operational burden (that is, managing routing updates) without a matching benefit.
If you do use IP anycast, tie it to the load balancer so that bringing a site down withdraws its routes automatically, and remember that anycast gets packets to a site but does nothing for scaling within it. You still need the load balancer and the backend fleet.
Scale the backend like a RAID array
With a dumb load balancer in front, adding capacity becomes trivial. Your backend RADIUS servers should be identical clones of one another.
To double your throughput, add double the servers. When hardware ages out, pull one server, replace it with a newer one, wait a day to confirm nothing broke, and move to the next.
It is the same process you use to grow a RAID array: swap one disk at a time and let the system rebuild around it.
I always recommend a number of small servers over one large box. A handful of low-end machines gives you higher aggregate throughput and better resilience than a single expensive system, and when one dies you throw it away and slot in a replacement for a couple of thousand dollars.
My favourite counter-example is a well-known commercial product whose recommended “mid-size” deployment calls for 64 CPU cores and 192 GB of RAM for a job that FreeRADIUS handles comfortably with much more modest hardware. In fact, in 25+ years of building systems, we have never built a RADIUS server with 64 cores and 192GB of RAM. It’s not just useful.
Rack hardware is cheap compared to the cost of people answering support calls, so I tell operators to run their RADIUS servers close to idle. When power comes back after an outage and every device tries to reconnect at once, that spare capacity is what keeps you online.
Two more things make the backend easy to grow.
Keep the configuration for every site as templated as possible - the same config, cloned, with as few per-institution special cases as you can manage. Bespoke rules and custom integrations for every member is where operators lose most of their engineering time.
Be sceptical of elastic cloud scaling as a substitute for owning your capacity. Running RADIUS in the cloud is convenient for spinning servers up and down, but you pay for traffic in and out, and if you run a shared instance hot you get throttled hard. Pay for a small instance and push it to 80%, and you may see a fraction of the throughput you expected. Nothing beats hardware you control in a rack.
Worth subscribing to.
Worth reading.
Our weekly newsletter covers network authentication tips, how-tos, security vulnerabilities, free resources, standards updates, and industry news. (All stuff you should stay up to date on!)
Forcing traffic back into balance
Because you cannot ask clients to fail back, you need a small operational tool for the times when your traffic drifts out of balance - a region recovers from an outage, but the clients that moved during it never move back.
The fix is blunt and effective.
Block the misrouted client IP addresses at the firewall for a few minutes. The affected connections fail, the clients reconnect, and because your live IP is the same at the recovered site, they land where they should.
A few minutes later you remove the block. It is not elegant, but with a protocol that gives you no way to talk back to the client, taking the traffic away briefly is the cleanest way to restore a healthy split.
This is the kind of detail worth planning up front, and it is why multi-site RADIUS design deserves its own attention rather than being treated as an afterthought.
Does eduroam support RadSec?
Most eduroam traffic still runs over UDP, and it will for a while. As access points are upgraded, more of them support RadSec - RADIUS over TLS - natively, and much of the newer equipment already does.
The stubborn exception is Microsoft NPS, which a lot of institutions still run and which will almost certainly never support RadSec, so any national operator has to keep carrying UDP for the foreseeable future.
If you want to let your members adopt RadSec, the work on your side is modest: you need a certificate authority to issue and accept client certificates, and FreeRADIUS ships with scripts to help you stand one up.
The operational catch is certificate rollover. Unlike shared secrets, client certificates expire, so you need a plan for renewing them before you turn this on for a large membership.
Treat every support question as a documentation failure
The part of running eduroam that costs the most is support, which is often overlooked in the planning process.
National operators routinely have someone close to full-time answering member questions, and a large share of those questions are about the same handful of onboarding issues.
The mindset that keeps that cost under control is simple: every question is a sign your documentation is inadequate. Do not just answer it and move on. Answer it, then fix the documentation so the next person finds the answer themselves. Over time the volume of questions falls, because search and AI assistants are now good enough that well-written documentation gets found pretty easily.
The corollary is that onboarding a new institution has to be obsessively documented and as close to a standard configuration as you can make it.
It helps to keep a separate onboarding or test server that mirrors production, so members can validate their integration - and you can turn on full debug logging - without anyone touching the live systems. If a member wants something genuinely bespoke, the honest answer is that bespoke work is a separate engagement, not the default path.
The principles travel
None of this is unique to eduroam RADIUS. The same architecture - a simple load balancer, a fleet of identical backends, firewall-level control over where traffic lands, and relentless standardisation - is what we design for ISPs recovering a million subscribers after an outage and for enterprises running authentication across every access point in the building.
The challenges of campus networks just expose the client-behaviour problems more visibly than most, because the clients are the entire travelling population of the world’s universities. Get the architecture right, and the protocol mostly takes care of itself.
Need more help?
InkBridge Networks has been at the forefront of network security for over two decades, tackling complex challenges across various protocols and infrastructures. Our team of seasoned experts has encountered and solved nearly every conceivable network security issue. If you're looking for insights from the architects behind some of the internet's most foundational authentication systems, you can request a quote for network security solutions here.
Related Articles
Network design for multi-site RADIUS systems
Some organizations and network operators such as ISPs can use a central RADIUS service for all of their RADIUS needs. This configuration is possible when there are a small number of users, or system load is low. However, when there are a large number of users spread across a wide geographic region, it may be beneficial to use a multi-site approach. As with all solutions, this approach has benefits and costs.
RADIUS for Universities
University environments present challenges for RADIUS system
design. Every hour, on the hour, thousands of students close their
laptops, move to a different location, and open them again. This
unique environment requires a unique infrastructure to support it.