Log InMany 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.
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?
These design principles are based on best practices developed over the last twenty years at NetworkRADIUS. We have seen pretty much every variation of FreeRADIUS deployments out there. If you have a complex network environment and need expertise from the people who wrote FreeRADIUS, contact us for a consultation.
More about ISP RADIUS design best practices
ISP RADIUS design: a practical guide
