InkBridge Networks - A new name for Network RADIUS

Separating RADIUS Authentication and Accounting functionality

When to do it and why

Many ISP networks have Authentication and Accounting handled by the same databases. This configuration works for many situations, especially small and low-load systems. There are times, however, when it is beneficial to separate the functions of Authentication and Accounting. Doing so can increase performance, and scalability.

Accounting requests can slow down authentication

ISP customers expect to be able to access the network quickly and reliably. To provide a good customer experience, ISPs need the Authentication and Authorization functions to be extremely responsive to user requests. However, Accounting queries to do monthly billing statements can have an enormous impact if they are competing for resources with the Authentication queries.

The solution here is to split the functionality in two. We recommend that ISPs deploy at least two separate RADIUS servers at each site.There should be a clear division of responsibilities between the servers.

  • Dedicated Authentication and Authorization RADIUS server
  • Dedicated Accounting RADIUS server

The diagram below illustrates how this could work for multiple sites.

Separate Authentication and Accounting RADIUS servers

This design has the following characteristics:

  • Each location maintains dedicated RADIUS servers to handle Accounting and Authentication functions separately
  • Authentication servers communicate primarily with the secondary instance of the Directory Service at their location
  • Any traffic related to updating or reporting on accounting is directed to the RADIUS Accounting server
  • Accounting servers communicate primarily with the Session Database at their location

By separating the responsibilities of each server, the design guarantees that the system responding to Authentication requests will be unaffected by any Accounting related traffic.

The reason this system split works well is that the RADIUS protocol provides for retransmissions of Accounting traffic. If the Accounting system is busy, the NAS will simply resend the packets until it gets a response. This retransmission still happens whether or not the user is still online! These retransmissions can happen for many minutes, or, if necessary, hours.

In contrast, Authentication traffic is much more time-sensitive. While the RADIUS protocol does provide for retransmitting Authentication traffic, users are much less forgiving. When users fail to get authenticated quickly, they are unhappy, and likely to complain, or change providers.

Fortunately, this problem can be avoided by a careful design of the AAA network.

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

Why you should separate historical data from live data

ISPs and telecoms are often legally required to keep user accounting data for long periods of time. However, keeping these records can result in enormous databases which then affect the performance of your RADIUS system. There are ways of optimizing the database so that you can keep high performance while maintaining years of accounting data.

How Authentication Protocols Work

Choosing an authentication protocol is one of the most important decisions when designing a RADIUS ecosystem.

There are a variety of authentication protocols to choose from, each with their own set of advantages, disadvantages, and constraints. In general, we recommend using PAP whenever possible. It is compatible with all known back-end databases, and it has no known security issues.