Testing Dial-Up Networking with Chariot Application Note April 30, 2001

Transcription

1 Testing Dial-Up Networking with Chariot Application Note April 30, 2001 Contents Introduction...1 Methodology...1 Conclusion...4 Notes...4 For the foreseeable future, a large percentage of Internet users will continue to connect through dial-up networking (DUN). But repeatable, accurate testing is the only way to find out how dial-up will perform under certain conditions. This paper explains how you can use Chariot, by NetIQ, to run realistic, end-to-end tests of DUN equipment, no matter how the intervening network is configured. With Chariot, only a few computers are needed to simulate hundreds and even thousands of simultaneous users dialing in to a server. We used a single multiple-client station generating V.90 dial-up Point-to-Point Protocol (PPP) connections to a Windows NT Remote Access Server (RAS); however, with a few alterations, the methods we illustrate here could be applied to other testing environments and scaled extensively.

2

3 Introduction Despite all the hype about broadband Internet access technologies, dial-up networking (DUN) is far from obsolete. By some estimates, faster connection options, such as cable and DSL, are still available to only 27% of home Internet users in the United States, and GartnerGroup projects that 55% of U.S. users will still use dial-up to connect to the Internet in 2004 (1). And with today s increasingly mobile work force, more and more businesses are expanding their dial-up infrastructure. Internet users demand reliability and performance without regard for network conditions, which may include heavy traffic. As a result, DUN needs to be repeatedly, accurately tested to see how it will perform under normal and stressful conditions. NetIQ Chariot can test dial-up connections with minimal setup and equipment. Over an open connection, Chariot can realistically emulate the network traffic of dozens, hundreds, and even thousands of users accessing a dial-up server and using any intervening equipment on the network. For the present example, we used a single multiple-client station generating dial-up Point-to-Point Protocol (PPP) connections through a V.90 modem to a Windows NT Remote Access Server (RAS); however, with a few alterations, the methods we illustrate here could be applied to other testing environments and scaled extensively. Methodology To set up a realistic test emulating multiple dial-up networking users, but actually using only a few computers, a Windows NT computer configured with multiple modem ports can be used. A variety of cards are available that have 4 to 6 modems per card, or you could use T1/PRI interface modem cards with 23 or 24 modems per card. The client station we used was configured to support 24 simultaneous DUN phonebook entries over four 6-port Rocket Modem PCI cards that supported V.90 dial-up connections. Each entry was bound to a unique modem COM port and represented a Chariot endpoint emulating a DUN client. In addition, each phonebook entry was configured to request an IP address from an NT RAS Server before completing the dial-up connection. When Chariot traffic was sent between the endpoints on the DUN Client computer and the RAS Server, the combinations of IP addresses and modem COM ports behaved, for all intents and purposes, like 24 unique dial-up users. We used a batch file with the Windows application rasdial to establish simultaneous dial-up connections for all phonebook entries. Once the connections were open, the Chariot Console initialized the test, sending a test script to each Endpoint 1 address in the DUN client computer and then driving application traffic from those addresses through the Device/Network Under Test to the Endpoint 2 computer configured as the RAS Server. We discovered early in our testing that Windows NT was routing all the Chariot traffic over a single RAS port during the test. Obviously, this meant that the test was not realistically emulating the effects of multiple dial-up connections to the RAS: data was only traveling through the port whose connection was opened last. To solve this problem, we configured static routes at the DUN client computer to ensure that the Chariot application traffic would be routed to the correct modem port and destination address (Endpoint 2). Testing Dial-Up Networking with Chariot 1

4 Test Bed Configuration Our test bed consisted of three computers connected by a 10 Mbps Ethernet LAN. The Chariot Console was installed on a Windows NT 4.0 workstation, and Performance Endpoints were installed on a Windows NT 24-port DUN client station and a Windows NT Remote Access Server. All three computers had a NIC with a static IP address. We also assigned 24 Virtual IP addresses to the NIC on Endpoint 2, the RAS server. These would be the destination addresses for the DUN clients to the RAS server. Figure 1: Chariot Dial-Up Networking Test Configuration Using Rasdial to Establish the Dial-Up Connections Before you run the Chariot test, you must do the following: Define the dial-up connections. Open the dial-up connections. First, define the connections as phonebook entries. You can create them in the Windows GUI or at a command prompt. To create phonebook entries in Windows NT, invoke the New Phonebook wizard by double-clicking the My Computer icon on the Desktop, selecting Dial-Up Networking, and clicking New. Once you ve created a connection to the RAS server, you can dial it by double-clicking the Dial-Up Networking icon and clicking Dial. To create phonebook entries in Windows 2000, access the Network Connection wizard from Settings ->Network and Dial-Up Connections->Make New Connection. A new icon for the connection is created in the Network and Dial-Up Connections folder; just select it to begin dialing. We used a batch file to do the dialing simultaneously for all phonebook entries. Our file invoked rasdial, which dials in with the username and password needed for authentication by the RAS. Here s the syntax for rasdial.exe: 2 Copyright NetIQ Corporation, 2001

5 rasdial entryname [username [password *]] [/DOMAIN:domain] [/PHONE:phonenumber] [/CALLBACK:callbacknumber] [/PHONEBOOK:phonebookfile] [/PREFIXSUFFIX] rasdial [entryname] /DISCONNECT rasdial The RAS was set to assign IP addresses from a pre-selected range to the phonebook entries serving as Endpoint 1 ( , , , etc.). For Endpoint 2 in each pair, we used the virtual IP addresses assigned to the RAS Network Interface Card ( , , , etc.). Rasdial provides plenty of progress messages, so it s obvious when the connections are up. Once all the connections were made and authenticated, and once they had received IP addresses from the RAS, we needed to set up the static routes on the DUN client computer. This was to ensure that Windows NT didn t send all Chariot data out the last modem port that connected. First, we cleared the routing table at the DUN client station using the command route f. Next, we entered the new routes, designating the Endpoint 1 addresses assigned by the RAS as Gateways and the Endpoint 2 Virtual IP addresses as Destinations. This can be done manually or automated with a batch file. Here s an example: (Destination) (Gateway) route add route add route add Creating the Chariot Test Once we had static routes set up, we created a new Chariot test. We added 24 pairs, using the Benchmark application script Throughput.scr to get some standard performance measurements. As we created each pair, we modified its Console-to-Endpoint 1 settings so that test flows were sent to the static IP address at the Endpoint 1 (client) computer. To change the Console-to-E1 setting, select a pair in the Test window and choose Edit Console to Endpoint 1 from the Edit menu. Then clear the box labeled Use Endpoint 1 to Endpoint 2 values and enter the address: Figure 2: Chariot s Edit Console-to-Endpoint 1 dialog box. The default settings in Chariot application scripts are intended for higher-speed links than the typical 56kbps dial-up link. We edited the script to send smaller files so that the test would complete more quickly. Testing Dial-Up Networking with Chariot 3

6 Conclusion Testing dial-up networking with Chariot requires some extra configuration ahead of time, but once you ve created the phonebook entries and established static routes that clearly define each endpoint pair, Chariot tests will measure all activity between the endpoints, excluding the actual dialing. As mentioned earlier, any equipment may be set up between the endpoints and its performance tested using the methods highlighted here. Although the test we ve described here emulates only 24 dial-up users, this test scenario can be scaled to test hundreds or even thousands of users. A Windows NT multiple-client station like ours supports up to 24 phonebook entries, and Chariot can create multiple pairs with the same entries serving as Endpoint 1 many times. Add another multiple-client station or a modem card that supports multiple modems to the test bed if you want to test with additional unique dial-up connections. Notes 1. Spring, Tom. Dial-up Ain t Dead. PC World June 9, Accessed 2/21/01. 4 Copyright NetIQ Corporation, 2001

7 Copyright Information NetIQ Corporation provides this document as is without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability or fitness for a particular purpose. Some states do not allow disclaimers of express or implied warranties in certain transactions; therefore, this statement may not apply to you. This document and the software described in this document are furnished under a license agreement or a non-disclosure agreement and may be used only in accordance with the terms of the agreement. This document may not be lent, sold, or given away without the written permission of NetIQ Corporation. No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or otherwise, without the prior written consent of NetIQ Corporation. Companies, names, and data used in this document are fictitious unless otherwise noted. This document could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein. These changes may be incorporated in new editions of the document. NetIQ Corporation may make improvements in and/or changes to the products described in this document at any time NetIQ Corporation, all rights reserved. U.S. Government Restricted Rights: Use, duplication, or disclosure by the Government is subject to the restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause of the DFARs and FAR (c) and any successor rules or regulations. AppManager, the AppManager logo, Knowledge Scripts, Work Smarter, NetIQ Partner Network, the NetIQ Partner Network logo, Chariot, Pegasus, End2End, Qcheck, ADcheck, NetIQ Security Manager, NetIQ File and Storage Administrator, OnePoint, the OnePoint logo, OnePoint Directory Administrator, OnePoint Resource Administrator, OnePoint Exchange Administrator, OnePoint Domain Migration Administrator, OnePoint Operations Manager, OnePoint File Administrator, OnePoint Event Manager, Enterprise Administrator, Knowledge Pack, ActiveKnowledge, ActiveAgent, ActiveEngine, Mission Critical Software, the Mission Critical Software logo, Ganymede, Ganymede Software, the Ganymede logo, NetIQ, and the NetIQ logo are trademarks or registered trademarks of NetIQ Corporation or its subsidiaries in the United States and other jurisdictions. All other company and product names mentioned are used only for identification purposes and may be trademarks or registered trademarks of their respective companies. Testing Dial-Up Networking with Chariot 5