NT Remote-Access Servers: Ready For The Big League?

	How We Tested RAS-Based Servers We created two separate tests designed to stress the servers: a throughput test and a modem dial test. The latter was developed in conjunction with Midnight Networks, a test equipment manufacturer, to test the servers' call-handling abilities. In both tests, the infrastructure remained the same, while the client portion changed. Providing WAN connectivity, we used a Madge Teleos Model 60 switch for T1/PRI signaling. The PC for the card-based remote-access devi ces was a Micron Electronics' PPRO 200 with 128 MB of RAM and a 3Com Corp. EtherLink 10/100 NIC. We used a Dell Computer Corp. P90 running Windows NT 4.0 and IIS (Internet Information Server) for the FTP server. The RAS and the FTP server were connected via a 3Com SuperStack 10-Mbps switch. We used Klos Technologies' SerialView for PPP tracing and debugging. Compaq Computer Corp.'s 4000 provided the client-side modem. The throughput testing was performed with a Micron PPRO 200 with a Digi EPC/X multiport board connected to three EPC/CON RS-232 break-out boxes. For background load, we made the maximum number of connections to the remote-access server, less one port, and ran FTP traffic down each pipe. We also connected a second Micron PPRO 200 running Windows 95(B) with dial-up networking and ran several FTP transfers across the link. We averaged the time reported by FTP on the Windows95 client for performance measurements. Our modem dial test used Midnight Networks' Avalanche system to load the RAS with calls. All of the RAS servers used Microsoft's Service Pack 3 and the RRAS (Routing & RAS) update. Once the RAS was loaded with calls, Avalanche ran a loop 1,000 times that dropped calls 10 at a time, waited 15 seconds and reconnected the calls up to the IPCP (IP Control Protocol) layer. Each loop ran through all of the ports once. Because we couldn't determine with certainty why modems occasionally failed to train up, we only included the modems that successfully trained in the measurements. We then counted the number of successful LCP (Link Control Protocol) negotiations. Once the LCP connections were up, we counted the number of IPCP negotiations out of the successful LCP connections. Notably, both the RAServer and the RASCAL posted the longest LCP negotiation time (18 seconds), while the Hawk maxed out at five seconds. This didn't seem to pose a problem with our rather light calling load. The LCP negotiation times averaged three seconds across all devices, indicating the longer times were rare.

For the Side Bar on NT RAS: Ready For Enterprise Remote Access? Management Additions Other Reviews This Issue Old and New Novell Services Combine for a Clutch Hit in the Internet Rally By Ron Anderson