Network Computingwww.networkcomputing.com

While SBR's included reporting tool is somewhat sparse (literally rehashing statistics and configuration info already available through the management console), you can get a free "Steel-Belted Reporter" from Funk's Web site.

Dan Backman can be reached at dbackman@nwc.com.

Performance: It's All A Numbers Game

So where are the pretty graphs showing RADIUS (Remote Authentication Dial-In User Service) server performance? Instead of pushing each RADIUS server to failure through hundreds of simulated access servers and unreasonable numbers of user connections per second, we tested each server's ability to service a reasonable rate of authentication and accounting requests.

Most dial-in sessions generate three RADIUS requests: the initial authentication request (followed by an accept or reject response, accompanied by various attributes), a "Start" accounting record, and finally a "Stop" accounting record (accompanied by total resource usage figures such as time online, octets and packets transferred in and out, and miscellaneous port information specified by the access server). Our tests reflected this pattern of activity, generating first authentication and accounting "Start" requests, and later a pattern of accounting "Stop" requests. This also tested each product's ability to track large numbers of concurrent, open sessions (each under a different logical session and port ID).

What's a reasonable rate of authentication re-quests? In a dial-up pool of 1,000 lines and an average session time of 20 minutes, a simple calculation shows three calls per hour per line, or 3,000 calls per hour. Assuming an even distribution of calls, this accounts for less than one authentication per second (3,000 calls/3,600 seconds). In our tests, a Pentium 90-MHz Windows NT 4.0 Server

running either Funk Software Steel-Belted Radius 2.1 or Shiva Corp. Access Manager 3.0 can authenticate between seven and 10 users per second (against a back-end NT domain, which slows performance compared with a native RADIUS server user database).

This authentication rate should serve most corporate environments. In our high-end performance tests, we used a Sun Ultra 10 workstation (300-MHz UltraSPARC IIi with 256 MB of RAM) to generate continuous authentication loads averaging approximately 20 simulated dial-up authentications per second using our own RADIUS client simulator.

The Solaris-based RADIUS servers (authenticating against their local user database) had no problem weathering this storm of activity. However, once we added a second client load generator (an additional Ultra 10 workstation), we did find that Funk's Steel-Belted Radius client allowed 0.08 percent client requests to time out (under a load of approximately 30 authentication requests per second). However, we don't feel that this reflects negatively on the product, since such a load would require 36,000 dial-in lines at full capacity (assuming an average 20-minute session time and an even call distribution).

On the other hand, authenticating to a back-end source does add some processing time. In environments where authentication performance is of the utmost importance, authenticating against the RADIUS server's native user database will yield the best performance.