Simulating Your NT Network

Pinpoint problems with your network's bandwidth or devices, and plan for the future

In the past, most networks housed few shared resources; usersshared access only to file servers, printers, and perhaps a database. Today, many companies distribute information and applications across networks, and many users share access to information. Employees depend on the network to do their job, so when the network goes down, users' loss of access translates into a loss of revenue or customers.

To prevent network outages that cause revenue losses, you need to regularly test your network's capabilities and plan purchases around the network's ability to meet applications' throughput needs. On small networks, you can use network monitoring software and a few simple formulas to diagnose problems or predict the network's reaction to new hardware or software. (For information about testing applications across simple networks, see "Application Testing with Network Monitor," September 1998.) However, as networks grow, their numerous devices and connections make understanding the network impossible. Too many conversations among too many devices via too many network routes occursimultaneously for you to accurately predict how one application's traffic will affect another part of the network. To diagnose problems or test newapplications on a complex network, you need to simulate the network--­ use a simulation program, or simulator, to build a software model of key network elements and test how well the model functions with various traffic loads or network designs.

Because the purpose of modeling network traffic is to reduce the number ofdevices, routes, and transactions on a network to a manageable number,your model must include simplifications and assumptions. The trick tosuccessfully simulating your network is knowing which aspects of the network youcan simplify without compromising the model's effectiveness.

To simulate your production network, you need to construct a reasonablerepresentation of the network's topology, including the physical devices andlogical parameters that comprise the network. You need to determine how muchtraffic is on your network during the period you want to emulate. You mustspecify a question you want the simulation to answer. And finally, you need to run the model through a simulator.

Topology
Your network's topology is the framework for your model. You need to includethe following physical devices in your representation of the network: routers,computers, switches, WAN links, LANs, and point-to-point connections. You alsoneed to include network parameters such as router interface settings, LANspeeds, WAN speeds, router capabilities (e.g., backplane speed), routingprotocols, and naming conventions. How much detail you need to include dependson the question you want the model to answer. For example, if you areinterested in WAN utilization, you don't need to include all your network's PCsin your model; you need to include only the traffic the PCs generate.

You can use software to discover your network's physical devices and logical settings. Some simulators include a discovery tool; others importinformation about network topology from network monitoring tools. Third-partytopology discovery tools include HP's OpenView, Cabletron Systems' SPECTRUM,IBM's NetView for AIX, Digital Equipment's POLYCENTER Manager on NetView forWindows NT, Castle Rock Computing's SNMPc NT, CACI's SIMPROCESS, and NetworkAnalysis Center's WinMIND.

Most discovery programs use the Simple Network Management Protocol (SNMP)to query the devices. Some programs require you to provide a list of thenetwork's routers and those routers' IP addresses. Other programs need only theaddress of a seed router. A discovery program learns what it can from a router'sManagement Information Base (MIB), then asks the router to direct it to aneighboring router. The discovery program queries the next router's MIB andsteps through the network, learning about routers, interfaces, and deviceson each network segment.

This discovery of your network topology provides you the first benefitof simulation: network documentation. The discovery process creates aninventory of the most important devices on the network and their settings. Youcan export this information to a spreadsheet or use the information to updateprevious device inventories you've taken.

Traffic
If your network's traffic stopped, users wouldn't be able to communicatewith network devices, and many users would be unable to perform their job. Your model must emulate traffic in as much detail as is computationally possible.

Before you can emulate network traffic, you need to learn how informationflows on your network. Collecting traffic doesn't require special hardware; youneed only a computer with an NIC that operates in promiscuous mode (manystandard cards do). Collecting traffic requires special software that capturesdata or communicates with SNMP or Remote Network Monitoring (RMON) agents. Somenetwork analysts use a special device for troubleshooting networks. Underneaththe device's case lies a standard PC with one or more standard NICs. For thesake of simplicity, I'll break these devices into two groups: network analyzersand network probes. The functionality of devices within these categoriesoverlaps, but your enterprise probably needs a network analyzer and a networkprobe because products in the two categories serve specific needs common to allnetworks.

Network analyzers. Network, or protocol, analyzers aredevices that take a snapshot of traffic on a network. For example, you can usean analyzer to see instantly whether a large number of frames on the networkhave errors from a problem NIC or computer. You can look inside a frame and viewits contents. (However, you'll be disappointed most of the time because insteadof seeing usernames and passwords, you'll see only unintelligible characters.)Because analyzers are designed to gather and report data about the lowest layersof the Open Systems Interconnect (OSI) model, and because their buffers havelimited sizes, you can't use analyzers to gather data about how protocolsfunction on the network over a long period. Administrators usually don't leaveanalyzers in one place for long, so analyzers often have rugged cases.

Most analyzers can record network traffic and play it back to the networklater. This playback feature is useful when you want to redesign your networkand test how the new system reacts to a specific user request, such as adatabase query. In addition, analyzers can generate traffic to stress test yourproduction network and determine the maximum amount of traffic the network cansupport.

Analyzers let you filter traffic based on host or destination addresses, sothey can capture the traffic that one conversation between two machinesgenerates. This specificity is important when you want to analyze a newapplication before deployment, because you want to include in your analysis onlytraffic that the application you're testing generates. Network analyzers thatrun on NT include 3COM's Transcend LANsentry Manager, Network Associates' ExpertSniffer Network Analyzer and Distributed Sniffer System (DSS), AXON's LANServantManager, NetScout Systems' NetScout Manager Plus, and Compuware'sEcoSCOPE.

Network probes. Network probes use RMON2 to analyze networktraffic at the network and application layers. They provide much of the samedetailed network information that analyzers generate, but they can't providesingle-packet analysis. Probes are best at monitoring a network's healthover time because they don't suffer from the myopia inherent inanalyzers.

Probes can be PCs running probe software, or they can be separate hardwaredevices that are smaller than PCs and have no monitor or keyboard. You attach aprobe to your network, and it gathers the data that you request. You can performadministration tasks remotely, via a serial port connected to the back ofthe probe, or at the probe console if the unit has a console. You need probesthroughout your network to keep an eye on the entire network, so most probesdon't move around much. The optimal simulation environment has a probe on everynetwork segment.

If budget constraints prevent you from placing probes on every segment ofyour network, you must determine where on the network to place probes tomaximize traffic capture for the number of probes you can afford. Lookingat your network's design and traffic data helps you determine where to placeprobes. You want to place them at traffic sources, or sinks. For example, if youhave a Fiber Distributed Data Interface (FDDI) ring with 20 servers attached to it, the FDDI ring is an appropriate place for a probe because a lot oftraffic traverses it. Probes contain information that you don't want anyoneexcept administrators to access. Make sure your probes are password-protected,and keep them behind a locked door.

To ease the management problems that distributed monitoring devicescause, most network monitoring solutions have probes set up to report to amidlevel management station (i.e., a workstation running management software).The probes are smart, so they are capable of gathering data, runningstatistical analyses on the data, and sending only the important numbersto the midlevel management stations. The midlevel management stations consolidate information from all the probes that report to them, and someperform additional analysis. You need a midlevel management station forevery 10 to 15 probes, depending on the volume of traffic the probes process. You also need a higher-order management system that periodically queriesthe midlevel management stations for probe information. This higher-ordermanager assimilates all the network's data and produces data sets and graphs.

Although UNIX probes and UNIX management software have traditionallydominated the network probe market, many vendors are porting their UNIX probesto NT. A UNIX or NT probe can monitor networks running either OS, because probesfunction independently of the local OS. Table 1 lists probes that work with NT.Probes for faster LAN protocols such as FDDI usually cost more than Ethernet or Token-Ring probes.

Data Reduction
If you have multiple probes capturing conversations on your network, theprobes might capture thousands of conversations per minute. This amount oftraffic bogs down simulations on the most powerful machines. You need to removeor consolidate conversations to prevent unnecessary conversations from slowingyour simulation.

Remove duplicate conversations. One method for reducing thenumber of conversations you capture is eliminating duplicate conversations. Twoprobes might capture and record the same conversation; for an accurate measureof network traffic, you need to make sure you record conversations only once.Most network probe software packages eliminate duplicate conversations. If yourprobe software doesn't remove duplicate conversations, you must create a utilitythat compares conversations and deletes one of every pair of conversations thathave identical attributes.

Reduce the number of remaining conversations. You can usetwo methods to reduce the number of valid (i.e., not duplicate) conversations.Few probes or simulators provide these methods of data reduction, so you mightneed to create a standalone application to use them. The first method eliminatesconversations that are too small to significantly affect network traffic. Forexample, 40 percent of conversations across your network might make up less than1 percent of the network's total traffic because these conversations consist of very few packets and very few bytes. These small conversations(such as pings) register in the simulation and use up precious resources on themachine running the simulation.

The second method consolidates conversations with the same source,destination, and application. This method combines all the consolidatedconversations' packets and bytes, so it doesn't lose any traffic data. You canset a time criterion (e.g., 5 seconds), so the software consolidates onlyconversations that took place within a specific period of time. Eliminatingsmall conversations and consolidating remaining conversations can reduce yournumber of conversations by up to 70 percent.

Application Profiles
You can use simulation to estimate the effect that deploying a newapplication will have on your production network. Until you deploy theapplication, probes on your network won't capture the application's traffic. To measure a new application's effect on a simulation, you first must add the application to one machine on the production network or (preferably) to a lab network.

Then, you can gather basic information about the application's individualconversations. Use probes that detect packets' header information, includingtheir network protocol and application. Most probes automatically determinewhich network protocol a packet uses (e.g., IP, IPX, DECnet), but you mustmanually configure them to identify many applications (e.g., Word, Telnet, CAD).After you configure your probes, you can identify the following information forevery conversation on the network: the network protocol, the application thatgenerates the conversation, the conversation's source and destination computers,the number of packets and bytes that travel in each direction, total round-triplatency for the application, and the duration of the conversation.

Looking at your traffic at the application level is useful. You can checklatency for applications to see whether they are meeting a minimum quality ofservice. You can see how much throughput each application uses. Because you knowthe source and destination of all traffic flow, you can determine where yourintranet traffic is going and which users are using which resources. To simulatedeployment of an application, you need to gather data about the application'sconversations and manually add this data to your network model. Then, you must instruct the simulator to expand the information you've gathered about the application to simulate the activities of many users at many locations within your model.

Developing a Question
Before you run a simulation, you must devise a specific question that youwant the simulation to answer. You might want to ask a change-analysis question. For example, you might want to analyze what would happen if you changed your network's WAN links, LANs, or routers or added a new application to your network. You might want the simulation to answer a question about the network's fault tolerance. For example, you might want to determine how the failure of a specific device or group of devices­­ such as LANs, WAN links, or an entire facility of your organization--­would affect application demands. Answering these questions can help you in capacity planning, rollout validation,disaster recovery, and life cycle management.

After you decide which question you want your simulation to answer,you might need to tweak the network model's topology and traffic to make surethe simulation addresses your question. Simulators automatically alter anetwork model to test its fault tolerance; they have built-in utilities that emulate the failure of network devices. You can select devices from amenu, and your simulation will predict what effects that device's failurewould have on your production network. However, you must manually alter yourmodel for your simulation to answer a change-analysis question. To add ormove servers or users, you must change the volume of bytes an applicationproduces in the model or add network devices or demands to the model beforerunning your simulation.

Simulators
After you develop a model of your network and define the question you wantto answer, you're ready to run simulations. Simulators have traditionally run onpowerful UNIX workstations, but some simulators are now available for NT. Mostcost between $40,000 and $100,000, and running them requires training. Becauseof simulators' cost and complexity, many companies contract with firms thatspecialize in simulations to provide the necessary tools and run thesimulations.

Simulators usually use a discrete event or an analytical approach to modelnetwork traffic. Discrete-event simulation analyzes the network traffic thateach packet generates to determine the network's behavior. The analyticalapproach makes assumptions about network traffic before a simulation. The analytical method can be as accurate as the discrete-event method, because discrete-event simulators can't store detailed information about each packet in simulations that include the many thousands of conversations (each of which can contain many packets) that most networks generate. Because the discrete-event method is much slower than the analytical method on large networks, I recommend that you use an analytical simulator for simulations of networks with more than 50 routers.

My COMNET Predictor Tests
COMNET Predictor is an analytical modeling tool from CACI. (For moreinformation about CACI, see http://www.caciasl.com). COMNET Predictor runson NT and is intuitive to install. I recently used COMNET Predictor to build asimple simulation from scratch on a lab network. I defined my network topologyfor the simulation, and I manually added all the network's traffic demandsbecause my network was so simple.

Screen 1 illustrates my test network. The network consisted of two LANsegments separated by a WAN link. An NT server and workstation resided on eachLAN. You can see COMNET Predictor's selection of network-building tools on theleft side of the screen. To create a network, you select a device icon (such as the LAN or server icon) and drag the icon into the main window. You connect devices with links and define the links' characteristics by choosing characteristics from a predefined list (such as T1 or ISDN) or customizing the specifications. My test network contained two models of Cisco routers. COMNET Predictor was familiar with the routers' capabilities and automatically included the routers' characteristics in the simulation.

Screen 2 shows five conversations that I manually entered into my simulation. For each conversation, I entered the origin computer, destination computer, application, protocol, and rate of transfer. You can select applications from a predefined list or add your applications manually (as I did in my simulation for Lotus cc:Mail).

After I entered my network topology and network traffic, I ran asimulation. I clicked the Run Simulation icon (the stoplight in Screen 1'stoolbar), and the simulation began. Because my model network was simpleand had little traffic, the simulation was complete in a fraction of asecond. I generated reports that examine current and forecasted networkutilization and potential failures. Screen 3 shows a report that provides theaverage percent utilization for each device and LAN on the network during thetime that my simulation's traffic demands were active. Most network devices havea limit on the number of packets they can process per second; for networkdevices, percent utilization measures how much of this limit network traffic isconsuming. For WAN and LAN segments, percent utilization measures how much ofthe available bandwidth network traffic is using.

I told COMNET Predictor I expect a 10 percent growth in traffic each year.The software calculated the demand for each device and LAN and projected thenetwork components' percent utilization for the next 2 years. If my test were asimulation of an actual production network, this report would tell me to keep aneye on my WAN link. If I decided to increase the throughput of my WAN link, Icould easily change the throughput of the model's WAN link and run anothersimulation to determine the effect that change would have on the network.

Life Cycle Management
Conducting simulations is a very important part of life cycle management foryour network. You need to carry out simulations often, because most networks'topology and traffic are constantly evolving. Figure 1 illustrates how thedifferent stages of simulations fit into the life cycle management of yournetwork.

To maintain a healthy network, use simulations to predict your needs for the future and develop cost-effective solutions to problems before adisaster strikes. Keep an up-to-date inventory of the devices and settings onyour network. Conduct traffic analyses to keep abreast of LAN, WAN, and networkdevice utilization. Determine how long users must wait for applications torespond, which might be part of a quality-of-service contract. Useperiodic simulations to help plan your capacity for future growth and determineemergency plans to deal with network failures. In addition to your periodictests, run simulations before you roll out new applications or hardware.

A simulation is neither the starting point nor the end point for answering your network design questions. Run-ning simulations will incite your curiosity and generate more questions than the process answers. As you run simulations, you will learn to appreciate your network's complexity and gain a better sense of how all the components work together.