A Practical Guide

More than almost any other business, Internet Service Providers (ISPs) need to provide their customers with fast, reliable access to their network. Any downtime can be catastrophic to their business. Slow connection speeds will drive customers away to other providers. This means that ISPs need to ensure that their network has several levels of redundancy in order to provide stable service at all times.

This article outlines our ISP RADIUS deployment design best practices. At Network RADIUS, we have been successfully using these principles for over ten years, with customers who are distributed across the world. These practices have been tested, and proven in production. These practices apply to all ISPs, from small to large, though the individual methods can vary depending on the ISPs size and needs.

Small, single site ISPs

In general, small ISPs should usually prioritize a system design which minimizes IT management overhead. In practice, this design usually means:

  • All the RADIUS functionality is on a single system. Unlike larger networks, there is usually no need to separate the authentication and accounting tasks onto different machines.
  • A separate machine to run the database which holds user information. Maintaining separate hardware for the RADIUS server and the database helps to ensure that the system is less likely to be overloaded when surges of authentication requests happen.
  • Leveraging virtualization as much as possible. We usually recommend putting the RADIUS server and database onto VMs and taking regular snapshots. The archive of snapshots makes it easier to recover from unexpected events or upgrades gone wrong. The cost to “restore from snapshot” is significantly less than the cost to rebuild a machine from scratch!

Larger ISPs will likely find this simple network design insufficient for their needs. As the size of the ISP grows, we see several common scenarios, each of which require a specific design approach. These design blueprints are not mutually exclusive and can be mixed and matched to suit your specific needs and constraints.

Multi-site design

ISPs and other enterprises that have geographically dispersed locations, usually also need a distributed RADIUS server design. Our design for a multi-site RADIUS deployment recommends deploying more than one primary database instance for the directory service. This provides much stronger network resilience, more responsive service, and dramatically reduces the risk of service outages. Different sites can fail over to each other, ensuring that there is no single point of failure in the network. This multi-site design also allows for easy maintenance, as there is little impact to taking part of the network offline for upgrades.

Read more: How to design RADIUS for multi-site networks

Heavy accounting query requirements

Some large ISPs regularly run large and complex accounting billing queries. When Authentication and Accounting functions are being performed by the same database, the increased load from billing can prevent users from authenticating into the network. The solution is to separate these databases, so that a high load on one does not impact the other.

Read more: Separating RADIUS Authentication and Accounting functionality

Tracking fraudulent authentication in multiple locations

Some of our larger clients have issues with people fraudulently sharing credentials with friends and family in other locations. A naive “multi-site” design as above will not be able to catch this behavior, which leads to loss of revenue and increased costs. The system design needs to take additional steps in order to prevent this abuse. To support this requirement, without sacrificing performance, the network design should create secondary copies of session databases at each site.

Read more: Preventing fraudulent logins across multiple sites

Need more help?

If you have a large network with complex requirements, contact us for help. We are the team that wrote FreeRADIUS and have seen pretty much every variation out there. We’ll build and deploy your network, and then hand it over to your team to run and manage.