eG Help

Network Policy Server (NPS) supports Remote Authentication Dial-In User Service (RADIUS) accounting, which you can use to track network usage for auditing and billing purposes. Accounting data can also be queried to assist with network access troubleshooting.

When a RADIUS client is configured to use RADIUS accounting, at the start of service delivery it generates an Accounting-Start message describing the type of service being delivered and the user it is being delivered to. The message is then sent to the RADIUS Accounting server, which sends back an acknowledgment to the RADIUS client. At the end of service delivery, the client generates an Accounting-Stop message describing the type of service that was delivered and optional statistics, such as elapsed time, input and output octets, or input and output packets. It then sends that data to the RADIUS accounting server, which sends back an acknowledgment to the RADIUS client.

The Accounting-Request message (whether for the Start or Stop message) is submitted to the RADIUS accounting server through the network. If the quality of this network connection is poor, then many request packets may be malformed, forcing the server to drop them. This in turn can delay or deny responses to accounting servers and acknowledgements to clients.

Also, if the accounting server is overloaded with requests, the server can choke slowing down accounting in the bargain.

To avoid such delays, administrators must track accounting requests and responses, proactively detect potential slowdowns, accurately isolate what is causing it, and promptly fix it. This is where the NPSRAcctServerTest test helps.

This test tracks the requests to and responses from each accounting server and reveals whether/not the servers are responding as quickly as the requests come in. You can also use this test to monitor the time each server takes to process requests, and thus identify the server that is experiencing a processing bottleneck. In addition, the test also captures the rate at which packets are dropped by the server and malformed/erroneous packets are received by the server, thus pointing to issues with the client or in the network connection between the server and the client. The load on each server is also revealed by monitoring the packets received by and the pending requests on the server from time to time. This way, the test pinpoints irregularities in load-balancing between servers, which in time can bottleneck request processing by the servers, resulting in slowdowns.

Measurement	Description	Measurement Unit	Interpretation
Accounting_requests	Indicates the rate at which this server receives accounting requests.	Reqs/Sec	This is a good indicator of the workload on the server. Compare the value of this measure across servers to know which server is overloaded. If a single server appears to be handling a vast majority of the requests, you may want to consider sprucing up your load-balancing algorithm, so that the request load is uniformly balanced across servers. If required, you can even consider adding more servers.
Accounting_responses	Indicates the rate at which this server is responding to requests.	Reqs/Sec	If the value of this measure is much lower than the value of the Accounting_requests measure, it could indicate that the server is not responding to requests quickly. You may want to investigate the reasons for the same.
Bad_authenticators	Indicates the rate at which this server received requests containing an invalid Message Authenticator attribute.	Reqs/Sec	Ideally, the value of this measure should be 0.
Packets_dropped	Indicates the rate at which this server were silently discarded the request packets it received for a reason other than “malformed”, “invalid Message Authenticator”, or “unknown type”.	Packets/Sec	Ideally, the value of this measure should be 0.
Malformed_packets	Indicates the rate at which this server received malformed packets.	Packets/Sec	Ideally, the value of this measure should be 0.
Packets_received	Indicates the rate at which requests packets were received by his server.	Packets/Sec
Request_timeouts	Indicates the rate at which requests to this server timed out.	Reqs/Sec	A high value indicates frequent timeouts. Under such circumstances, you may want to consider changing the timeout setting for requests, so that timeouts are kept at a minimum.
Retransmissions	Indicates the rate at which requests were retransmitted to this server.	Reqs/Sec	Retransmits can increase the number of requests to the server, thus overloading it. It is hence good practice to keep the rate of retransmissions minimal. One of the reasons for a high rate of retransmissions is a low Timeout setting on the server. If the value of this measure is very high, you may want to change the timeout setting to reduce retransmits.
Unknown_type	Indicates the average number of unknown type (non-RADIUS) packets received by this server per second.	Packets/Sec
Last_round_trip_time	Indicates the interval (in hundredths of a second) between the most recent request to this server and its response.	Secs	Ideally, the value of this measure should be very low. A high value indicates that that the accounting server is taking too long to perform accounting.
Pending_requests	Indicates the rate of requests destined for this server that have not yet timed out or received a response.	Reqs/Sec	A high value could either indicate a processing bottleneck on the server or a high timeout setting (which could be causing many requests to be retransmitted to the server). In the case of the latter, you may want to consider modifying the timeout setting to minimize the number of pending requests.