network performance toolkit using open source testing tools phần 7 docx

By modeling the network, you canobserve how network applications behave within the model environment, andextrapolate from the results an idea of how the application would behave inthe pr

PA R T

Three Application Performance Tools

Part III of this book approaches network performance from a different spective Not only is it crucial to have the network configured for maximumperformance, it also helps to have network applications that are configured tooperate efficiently across the network This part of the book describes somemethods and tools that can be used to help determine how an application willbehave within your network environment By modeling the network, you canobserve how network applications behave within the model environment, andextrapolate from the results an idea of how the application would behave inthe production network environment This chapter provides an overview ofthe methods used for modeling production networks and using those models

per-to test network applications

Trying to determine how an application will perform on a network is often

a task that falls to the network administrator While programmers work tomake network applications functional for their customers, they sometimes for-get to consider how the application will affect the existing production net-work, or conversely, how the existing production network will affect theapplication’s performance Often, customers, programmers, and networkadministrators do not find out that a new network application is the cause ofnetwork performance issues (or again, that the network is responsible for net-work application performance issues) until it is too late

Measuring Application

Performance

C H A P T E R

13

This chapter begins by introducing the concept of network modeling, byshowing the different methods used for testing network applications All ofthe network models described are ways that programmers and networkadministrators have used to determine how a network application might per-form within the production network environment.

Methods of Testing Network Applications

The point of testing network applications is to observe how an application willperform when run on a network In today’s world of “do everything on thenetwork,” each network application is competing for network resources withlots of other applications, from bulk file transfers to Web browsing The key togood network application performance is to determine how an individualapplication will behave in your particular network environment

There are four basic methods that can be used for testing network applications:

■■ Using a test network

■■ Using the production network

■■ Using a network emulator

■■ Using a network simulatorEach of these testing environments has a unique set of benefits and challengesfor programmers and network administrators This section walks through each

of the test environments, and describes the pros and cons of each

The Test Network

Creating a test network is the most common method used in programmingshops It is usually the quickest and easiest solution for testing network appli-cations Unfortunately, it can also produce the least useful results It is notuncommon for a network application to perform flawlessly within the test net-work, but fail miserably when placed in the production network environment.Most test networks fail to take into consideration the problems associated withthe actual production network

Usually, the test network is nothing more than a group of workstations nected together on a standalone network where no other applications are run-ning This can create a false sense of security for the application developers, asreal network problems are not addressed in the application To create a usefultest network, the testers should attempt to mimic the network problems of the

con-production network (discussed later in the Modeling Network Problems section).

Production Network

The most accurate method to use for testing network applications is to run theapplication in the production network environment This ensures that all ofthe network factors present in the production network will affect the applica-tion, as in real life, which makes it the best method of determining if the net-work will affect application performance, or if the application will affectnetwork performance Of course, there are downsides to testing on the pro-duction network

Often it is not feasible for the application to be developed on the productionnetwork Often, application developers are not located in the same area wherethe application will be run, making it impossible for them to use the produc-tion network for testing This is the case for almost all commercial networkapplications used However, even with in-house programming, the program-mers often do not have access to the application area where the program will

be run

Even when the application developers do have access to the production work, it is not always a good idea to test the application on the network Therehave been incidents of runaway applications that consumed the entire band-width of a production network, effectively crashing the network for other pro-duction data In environments where high availability is a necessity, this couldcause catastrophic results

The key to network emulation is to have devices that can introduce networkproblems into the test network environment There are two common methodsthat are used for this purpose:

■■ Have network devices that produce network traffic, emulating production traffic on the test network

■■ Have network devices that can accept packets, and delay, drop,

or misorder them, as in the production environment

The following sections describe how these two methods are used

Network Traffic Generator

The first method consists of network devices that can produce network trafficthat mimics the traffic found in the production network Just as the netperf net-work performance tool was capable of sending test data streams similar toapplication traffic, a network traffic generator can send traffic emulating any-thing from FTP data transfers and interactive Telnet sessions to database accessand Web browsing Many advanced network emulation devices also includeoptions to combine different types and amounts of traffic generated, such asemulating 10 FTP users and 100 Web browser users simultaneously

By adding one or more network traffic generators to a simple test network,you can more accurately observe how the network application will performgiven other network traffic While this is still not a complete emulation of theproduction environment, it gets the tester closer to the desired results

Not only can network traffic generators be used to test network tions, they are also used to test the performance of network devices Many network administrators use network traffic generators to simulate normal net-work traffic for switches, routers, and WAN links By simulating the actualtraffic that could be present during normal production times, you can observethe behavior of the network devices before customers complain

applica-Network Emulation Device

Instead of generating network traffic for the test network, the second type ofnetwork emulation device provides a way to model an entire production net-work within one or more devices As packets enter the network emulator, theyare processed to simulate network problems that could be present on the pro-duction network The network emulation device plugs in between the clientand server devices testing the network application

For packets to pass from the client to the server, they must pass through thenetwork emulator The emulator is configured to process each packet in somemanner, depending on the type of network emulated, before it is passed to theserver The idea is to inflict the same network problems on each packet sent aswould be seen on the production network

To accomplish this, most network emulators create one or more pipelinesbetween the device input and output As packets are received on the input,they are fed through the pipelines on their way to the output Within eachpipeline, the packets are subjected to different delays, errors, and even dropsbefore they are sent to the device output This is demonstrated in Figure 13.1

Figure 13.1 Network emulation within the pipeline.

The network emulator sends packets between the different pipelines domly, so each of the network effects is distributed among the incoming pack-ets The pipeline can perform the network emulation using either hardware orsoftware solutions Often the pipelines are implemented internal networkfunctions within the emulation device, such as interprocess communication(IPC) on Unix systems

ran-Network Simulation

Network simulators perform network-modeling functions completely within

a software environment Mathematical algorithms are used to model thebehavior of each network link and device, and also represent the data pro-duced and consumed by the network application The way the mathematicalalgorithms work on the input data is similar to the way the actual productionnetwork would affect the data, using delays, drops, and out-of-order packets.Each device within the network path is modeled, with the individual modelsconnected together within the simulation

The network model connects the hubs, links, and router models together toproduce a single network model The output from one device model is fed intothe input of another device model, representing the various aspects of the net-work connections Using this technique, any type of network can be modeled

in the network simulation environment

Modeling application data can be tricky Just like the network traffic ators, network simulators must simulate different types of network traffic Theonly difference is that the simulators do it mathematically, without using realpackets By sending data streams that represent real traffic, the network simu-lation can produce results showing how the output of each network devicewould look

gener-client server

delay

drop packet Error injector

Network 1 Network 2

Network Emulator

A network simulator does not have to process information at the same speed

as the modeled network (real-time processing) The purpose of the networksimulator is not to simulate real-time data, but to produce results that indicatewhat the overall performance of the network application would be, given themodeled network There are basically two types of network simulators:

Unfortunately, this simulation method is computationally intensive, ing lots of calculations for each packet within the data stream and each net-work device handling the packet along the network path To simulate largequantities of network traffic within large networks, discrete event simulatorsoften have to perform calculations for hours, and even days, before producingresults

requir-Analytical

Analytical simulators attempt to decrease the calculation times by using ematical equations to estimate the behavior of different network devices andthe way they would handle particular types of traffic Each network device issimulated using a simple mathematical equation, and each data stream is rep-resented as information passes through the equations

math-Instead of having to process each packet through each device, the analyticalsimulator just needs to process a group of calculations on input data Thisresults in extremely fast simulation results, although they are not as accurate

as the discrete event results

Modeling Network Problems

No matter which network-testing method you use, to fully test a networkapplication, you must be able to simulate the way the application behaveswithin the normal network environment This means that the method must berobust enough to simulate all of the problems associated with busy networks

Each of these problems must be duplicated within the network model used topredict the performance of the network There are several problems that must

be taken into consideration:

■■ Network bandwidth constraints

■■ Packet errors

■■ Lost packets

■■ Out-of-order packets

■■ Delayed packetsThis section explains each of these problems, how they can affect a networkapplication running on a production network, and how the network modelmust take them into consideration when producing test results

Bandwidth Constraints

A network application should never assume unrestrained communicationbetween network devices One of the primary factors in determining networkapplication performance is how often the application sends data across the net-work The network can make or break the network application’s performance.Network applications that send lots of packets between devices are depen-dent on the efficiency of the network Any delays between packets introduced

by busy networks can be catastrophic for the application It should be a damental design goal of all network application programmers to minimize thedata traffic that must traverse the network

fun-There are many applications that violate this principle Database tions are usually the biggest culprits There are two basic ways to performclient/server database functions across the network

applica-In the first method, the database engine is located on the client device, whilethe database data is located on the server For a simple data query, the databaseengine must select each record within the database index to look for the queryresult This requires each index record to be passed across the network to theclient, causing lots of network traffic

In the second method, the database engine is located on the server device,along with the database data The client contains simple code that sends thequery to the database engine, which then does all of the database indexlookups internally, and sends a single response with the result This methodproduces minimal network traffic, and is more network-friendly, especially forslower networks

In both scenarios it is crucial to model how much network bandwidth is beingconsumed by the network application The key is knowing the characteristics ofthe network application, and being able to quantify those characteristics Net-work traffic generator applications can be used to simulate the network traffic

generated by each type of database application—either in real life, by sendingdummy database packets across the network, or in simulation, by performingthe calculations necessary to simulate the traffic.

Packet Errors

The network application should also be prepared to deal with faulty datareceived in packets Most network applications that use the TCP or UDP pro-tocols do not have to worry about this, as it is taken care of at the networklevel However, applications that use their own protocols must be prepared tohandle errors

The most common method used in network applications to handle packeterrors is the checksum method Most standard protocols provide a system forcalculating a checksum of the data contained in the packet, and including thevalue within the packet (the checksum part of the packet is set to zero for thecalculation) The receiving device must extract the checksum value, performits own checksum calculation, and compare the two values If the valuesmatch, the packet is assumed to be error-free

N OT E There are lots of methods for calculating checksums The most common method used for network packets uses 16-bit arithmetic to break the packet into 16-bit chunks, add them, and take the complement of the result.

Network models simulate network errors by injecting errors within a tain percentage of packets received in the model Network emulation devices

cer-do this by purposely altering the packet before it is forwarded to the output.Network simulators perform this task mathematically

Lost Packets

Besides error packets, the network application should also be prepared to dealwith missing packets While applications that use TCP don’t have to worryabout this, it is a big concern for applications that use UDP for communications.For applications in which lost packets are devastating, a trustworthy proto-col, such as TCP, is recommended Barring a total network failure, this willcause the underlying network devices to ensure that the remote host receiveseach packet sent This often requires retransmission of packets that are notacknowledged as being received While it is perfectly normal to have someretransmitted packets on the network, too many may be an indication of a net-work problem, such as an overloaded switch or router that is dropping packets.For some applications, however, lost packets are not a problem Applica-tions that transmit information at regular intervals can just send another data

sample with either updated information or duplicated information, and goabout their business UDP does not provide a method for tracking packets Thereceiving device does not recognize any packets lost in the network Networkgame applications often use UDP for its quick turnaround times (no connec-tion establishment phase is required) Most multiplayer network games sendout user information (such as location, health status, and so on) at preset inter-vals to each of the players If a status packet is lost, the next one updates theplayer information on the clients.

Simulating lost packets is not too difficult for network models Networkemulators can be set to drop packets as either a percentage of the overall datastream or as a random event occurring over a set amount of time Networksimulators represent dropped packets as retransmissions (as the sender mustretransmit the dropped packets) Retransmitted packets appear as additionalpackets within the data stream, increasing the bandwidth required for the datastream

Similarly, many network emulators and simulators also model decimated

packets Decimated packets occur when a network device drops a fixed amount

of traffic—for example, when a router or switch runs out of buffer space and

drops entire data streams (as described in the Modeling Network Devices section,

presented later in this chapter) Instead of dropping a percentage of packets,the model drops a set number of packets within the same data stream, forexample, losing 10 packets in a row within the stream The results of this can

be significantly different from the results of dropping just a single packetwithin the data stream Sometimes, network applications that can recoverfrom dropped packets will crash and burn as a result of decimated packets

Out-of-Order Packets

Another UDP problem is out-of-order packets This problem is most often seen

in WAN environments, where multiple network paths can be taken betweentwo endpoints If any network routers are performing dynamic routing, there

is no guarantee that all of the transmitted packets will take the same path toreach the same destination With all of the different WAN connectivity optionsavailable (56 kbps, T1, ISDN, DSL, ATM), it is possible that some packets willtake a slower path than others will

This can result in packets arriving at intervals different from those at whichthey were sent If the delays between paths are long enough, the packets caneven arrive out of order Figure 13.2 demonstrates this problem

It is up to the network application to ensure that the out-of-order packets are reassembled back in the proper order This of course will slow down application-processing time, and cause performance problems

Figure 13.2 Packets arriving out of order at the client.

Network emulation devices simulate out-of-order packets by creating tiple pipelines to process incoming packets, and delaying one pipeline morethan another As a result, some packets are processed more quickly thanothers, causing them to be sent out ahead of time, which creates out-of-orderpackets Of course, you don’t want all of the packets within a data stream to beout-of-order, just a percentage of them This requires the pipeline to use ran-dom amounts of delays within the pipeline, changing delay values over theperiod of the data stream

mul-Delayed Packets

With the increase of voice and video applications on the network, networkdelay has become a hot topic of discussion Any delays introduced by the net-work between the two endpoints can be devastating to the quality (or evenavailability) of the voice or video stream

There are plenty of opportunities for delays to be introduced in the packetflows Any device that must handle the packet and retransmit it is suspected ofinjecting a delay in the process Overloaded switches and routers are the primesuspects, as well as overambitious firewalls

Many network device vendors implement an IP quality of service (QoS) ture, allowing voice and video packets to be marked as having high priority Even with QoS features on routers, however, there is no guarantee that pack-ets will arrive at the same intervals at which they were sent from the server Asrouters become congested and reach their buffer limits, processing times canbecome longer, and even high-priority packets will be delayed

fea-Creating network delays is not difficult within the network emulator or ulator; the hard part is knowing how much and how often packets should bedelayed to replicate the production network environment There are severaldifferent methods used to simulate network delays:

sim-client server

5 4 5

4 3

3 2

2

1

1

4 5 2 3 1 Packet-Switching Network

Fixed delay. This method produces a fixed amount of delay between datapackets.

Uniform increase delay. Produces a variable amount of delay betweendata packets The delay time increases by a fixed amount for eachpacket

Exponentially increasing delay. Produces a variable amount of delaybetween data packets The delay time increases exponentially for eachpacket

Gaussian distribution delay. This is the most common method used

It provides a fixed distribution for the amounts of delay used on the network data

Modeling Network Devices

Not only do network emulators and simulators have to model network lems, they also need to model the specific behaviors of different types of network devices Different types of network devices require different types

prob-of models to emulate the way they handle and/or process packets This tion describes the characteristics of different types of network devices, andexplains how those characteristics are modeled within network emulators andsimulators

sec-Hubs

A network hub is used to connect multiple devices together on a shared work medium All packets sent to the hub by any device are forwarded toevery port on the hub (except the port that received the packet)

net-Since the network hub operates as a shared medium, its performance isdirectly related to how much traffic is present on all of the hub ports at anygiven time The hub software sequentially handles each packet received by

each port This behavior is modeled as a single packet queue, operating in first

in, first out (FIFO) mode.

The network speed of the hub is represented by the capacity of the FIFOqueue The faster the network hub, the larger the queue (more packets can beprocessed in the same amount of time) Figure 13.3 demonstrates this principle.Each port on the hub places packets into the single packet queue The hubremoves each packet individually from the queue, and sends it to all of theports on the hub When the queue fills up (which represents network over-load), packets are dropped, representing network problems such as collisionsand error packets on an overloaded network hub

Figure 13.3 Modeling a network hub.

The idea for modeling network hubs is to determine how much trafficcauses the network hub to fill This can be the result of either a short burst ofnetwork traffic from a single device, or a sustained network load caused bylots of network traffic In either situation, the model must account for whichpackets will cause errors, and how many errors

Switches

Like the hub, the network switch also connects multiple devices together onthe network However, instead of blindly forwarding each packet out everyport, the switch examines the destination of each packet, and forwards thepacket only to the port where the destination is supposed to reside

To perform this task, the switch must maintain large tables of MACaddresses, so it can tell which devices are located on which switch port by theirMAC address This greatly complicates the packet-forwarding process, andcreates a much more complicated model

Instead of a single queue, switches are usually modeled as multiple queues,two queues for each port on the switch As a new packet is received on a port,

it is placed in an input queue for the port After the switch has examined thepacket and determined which port it must be forwarded to, the packet isplaced in an output queue for the appropriate port Figure 13.4 demonstratesthis process

The network switch model must account for situations in which one or moreport queues fill up with packets, and drop packets This situation results inmissing packets for the network application The trouble with the switchmodel is that, although a single port queue may be full, other ports can handlenetwork traffic just fine Of course, when a switch’s processing capabilities areoverloaded due to excessive network traffic, packets are delayed (and possiblydropped) across all of the switch ports

packets coming in from ports

packets going out to ports

Figure 13.4 Modeling a network switch

Routers

Routers present a wide array of modeling problems Routers perform manyfunctions, and each function must be accurately modeled Obviously, the basicfunction of routers is to forward packets between networks To perform thisprocess requires three functions:

■■ Receive a packet on a network interface

■■ Examine the packet and determine the destination

■■ Send the packet out the appropriate network interfaceThe receiving and sending functions are usually modeled similarly to theswitch and hub interfaces, as a simple queue—two queues for each routerinterface (one for input and one for output) The size of the interface queues isrelated to the speed of the network interface Since routers are often used toconnect dissimilar networks, this can be somewhat tricky

Since the port queues can be different sizes, it is very possible that one face can overrun another interface, for instance if a 100-MB LAN sends lots ofpackets out a T1 Internet connection Because of this probability, most routersalso incorporate some type of buffering system for the interfaces, to helpreduce packet loss To complicate things even more, many routers supply dif-ferent sizes of buffers for different sizes of packets Since smaller-sized packetsare more common than larger-sized packets, more buffers are allocated forthem Of course this complicates the router model

inter-The interesting part to model is the lookup function inter-The router must usetables to store information about which networks are connected to whichinterfaces, and which remote networks can be accessed through which inter-faces These tables must then be referenced for each packet received by therouter This is often the bottleneck function within the router

The lookup table can be modeled using a simple packet delay function, ilar to that of the switch model Of course, the packet delay injected by the

sim-processing delay

port queues switch ports

switch model

lookup table is not consistent, so the packet delay model should include a way

to randomize the delays caused by the router

Besides the basic router functions, there are some advanced functions thatalso require modeling:

■■ Quality of service (QoS)

■■ Weighted fair queuing (WFQ)

■■ Stochastic fair queuing (SFQ)

■■ Random early detection (RED)The following sections describe these router features, and how they areoften modeled

Quality of Service

The quality of service function on routers allows applications to use the IPType-of-Service (ToS) field to indicate priority packets When the router deter-mines that a packet is marked at a higher priority, it moves the packet ahead inthe queue of packets waiting to be processed

The job of the network model is to be able to model situations in which alltraffic is at the same priority, and those in which there is a mix of high- andlow-priority traffic Obviously, in a mixed situation, when the router becomesoverloaded, the first packets to be dropped should be the lower-priority pack-ets This results in the high-priority packets having a lower packet drop rate(close to zero) than the lower-priority packets

Weighted Fair Queuing

Routers apply the weighted fair queuing (WFQ) method to help balancepacket streams received from different sources Instead of allowing a singlenetwork source to monopolize the network resources, the router attempts toforward packets from multiple sources in a fair and equal manner

This may result in packets being dropped from busy sources more quently than from sources sending fewer packets It is assumed that the busysources will recover from the loss of packets more quickly than the sourcessending fewer packets

fre-Stochastic Fair Queuing

Routers also can apply the stochastic fair queuing (SFQ) method to help ance packet streams received from different sources Instead of tracking whichnetwork devices are sending the most traffic, SFQ uses multiple queues, and

bal-distributes the received packets equally among the queues Each queue is thenprocessed in a round-robin fashion, assigning equal priority to each queue.

The SFQ method does not solve the problem of a single network devicemonopolizing the network bandwidth, but it does provide a method forattempting to equally distribute the chance of dropped packets among differ-ent network data streams

Random Early Detection

Random early detection (RED) is a technique used by routers to drop packetsfairly, when buffers are becoming overloaded In a normal situation, a routerwill accept incoming packets on interfaces until the specific packet bufferassigned to the interface, or packet size, is full When the buffer becomes full,all incoming packets are dropped until more room becomes available in thebuffer

The problem with this method of dropping packets is that a single tion with a large amount of data can fill the buffer, and other smaller applica-tions will suffer, as their packets are dropped along with the packets from thenetwork-hogging application This method is referred to as the tail-drop FIFOmethod

applica-RED helps make this system fair by attempting to intelligently drop packetsbefore the buffer actually fills The router must identify which source device issending more packets than others, and attempt to drop more packets from thatsource than from others Due to the nature of TCP, as more packets are droppedfrom the busy source, the source should throttle the packet transmissions,thereby reducing the bandwidth it consumes

Modeling RED is often difficult, and not many network emulators or lators tackle that situation Usually RED doesn’t play into router behavioruntil network overload conditions are present

simu-Firewalls

With the increase of hacking on networks connected to the Internet, firewallshave become commonplace in most corporate networks (and even many homenetworks) Unfortunately, firewalls add another element to the network thatcan affect the performance of network applications

While firewalls protect our networks from intruders, the downside is thatprotection comes at a price—performance Each packet that traverses the fire-wall must be checked against a database, or access control list (ACL) The ACLcontains rules that define the level of protection the firewall offers There areseveral different types of traffic that the firewall can be configured to block:

■■ Packets going to a specific IP address

■■ Packets coming from a specific IP address

■■ Packets containing a specific protocol (such as ICMP or UDP)

■■ Packets containing a specific application (such as FTP, Telnet, or Web)The trick with firewalls is to configure them to be secure enough to preventunauthorized users from accessing network resources, but not so strict thateach packet must be compared against dozens of rules The more rules con-tained in the ACL, the more delay introduced by the firewall

As you would expect, the firewall’s main network problem is packet delay,although it is not unheard of to see packet loss associated with a firewall Mod-eling a firewall in a network requires adding additional delays to the networkpath, along with possible packet loss

Wide Area Networks

While modeling LANs requires building networks of hubs and switches, eling WANs presents another problem There are many different methods thatare used to create a WAN, each with different characteristics The two mostcommon techniques used to create WANS are:

mod-■■ Point-to-point networks

■■ Packet-switching networksThe following sections describe these two methods, and explain how theyare modeled in emulation and simulation software

Modeling Point-to-Point Networks

A point-to-point network directly connects two endpoints with a single mission link, such as a T1 or OC-3 line Point-to-point networks incorporatethree components in the model:

trans-■■ The sending overhead

■■ The receiving overhead

■■ The transmission overheadThe sending and receiving overhead models are similar to the standard hubmethod of creating input and output queues for the incoming and outgoingpackets The transmission overhead is somewhat different

Each network link will contain its own delay function, along with a lar amount of packet error Both of these problems must be modeled in theemulation or simulation, to accurately duplicate the WAN environment

particu-Modeling Packet-Switching Networks

While point-to-point networks have dedicated links between the endpoints inthe network, packet-switching networks introduce multiple paths to end-points Packet-switching networks consist of a series of routers interconnected

to produce a grid, providing multiple paths between any two points on thenetwork

Each packet transmitted from one endpoint to another is handled dently from the rest of the data stream As a router in the packet-switching net-work receives each packet, it determines the best path to its destination Asnetwork links become congested, alternate routes are taken

indepen-As packets going between the same two network endpoints can traverse ferent routers, there is no way to determine exactly how much delay will beinjected into any packet’s path Since each packet within the same data streamcan take a different route, there is also no guarantee that the packets will arrive

dif-at the destindif-ation endpoint in the same order in which they were sent

This out-of-order problem was discussed earlier in the Modeling Network Problems section The WAN model must incorporate a method to randomly

mix up packets, so it is possible for them to arrive out of order at the endpointmodel

Wireless Networks

With the increased use of wireless networks, network models must providemethods to model wireless behavior While wireless networks provide func-tions similar to those of LANs, they also present some unique problems to net-work traffic that must be accounted for in the network models

Due to the behavior of the wireless radio transmissions, simulating errorswithin the wireless network can be a major task Often, a full simulation of awireless environment is impossible, as the vast amount of data required to sim-ulate the radio propagation and energy consumption can be overwhelming

To compensate for the varying quality of wireless network behavior, mostwireless network models focus on the effect of the slower network speed intro-duced by the wireless network In most LAN situations, the wireless network

is the bottleneck within the network path, and should be considered the ing factor within the network model

limit-Due to the significantly slower wireless network speed (usually less than

3 Mbps), packet overhead (such as TCP/IP headers) has a greater affect on thedata stream Packet size becomes a driving issue in wireless networks, assmaller packets result in larger overhead, and lower data throughput

Network emulators and simulators must be capable of varying the packetsizes within the model to account for the lower bandwidth associated withwireless networks

There are many different ways to test network applications The easiestmethod is usually to create a small standalone test network of a few worksta-tions and servers The downside to using a test network is that it does notaccurately duplicate the production network environment Alternately, somenetwork testing can be done on the actual production network This providesthe best method for determining how a network application will perform forcustomers Unfortunately, it is often not possible to use the production net-work, and sometimes it is dangerous to test new applications on the produc-tion network.

To solve the testing dilemma, many network administrators are turning tonetwork emulation and simulation Network emulators provide a way to feedactual network application data through a device that emulates the actual pro-duction network, and watch the results The benefit to network emulation isthat the actual network application can be used without having to use theactual production network

Network simulators allow networks and applications to be mathematicallymodeled, producing a generic test environment to help determine how theapplication will perform The downside to network simulators is that they donot use the actual network application, but rather an estimation of the type ofdata it will produce on the network Network simulators can also require lots

of processing time, for performing calculations to simulate each networkdevice and link in the network path

Both network emulators and simulators must be able to accurately modelthe devices found on the network and also the problems associated with net-works Each network device has unique characteristics that must be accuratelymodeled, using either mathematical equations or a combination of hardwareand software Each of the different problems found on the network, such aspacket loss, delays, and errors, must also be factored into the emulation or sim-ulation

The next chapter begins the network application testing toolkit by ing the dummynet application, which can be used to emulate a productionnetwork environment on a single network device When application data isfed into dummynet, the output data will look as if it has passed through theemulated network

This chapter introduces the first network emulation tool, dummynet Thedummynet application provides a method for network administrators to emulate network problems such as delayed packets, dropped packets, andnetwork errors First the chapter discusses dummynet, and how it works.Next, a discussion of the ipfw program, the main building block of dummynet,

is presented Finally, the chapter describes in detail how dummynet isinstalled and configured, and offers some examples of ways to configure dum-mynet to emulate different types of networks

FreeBSD, another open source Unix distribution, includes the ipfw tion, which is used for providing firewall functions within FreeBSD to processincoming and outgoing packets By using the firewall features, ipfw can drop,delay, and limit the bandwidth of packets traversing the FreeBSD system Thedummynet application, created by Luigi Rizzo, exploits the features of ipfw byusing them to create a network emulation system The next section describesdummynet, and how it can be used in different network environments to emu-late serious network problems

applica-dummynet

C H A P T E R

14

What Is dummynet?

The dummynet application is an internal FreeBSD system facility that ulates IP packets as the kernel handles them The dummynet system can pro-vide the following network emulation features:

manip-■■ Bandwidth restrictions

■■ Multipath packet routes

■■ Packet delays

■■ Packet loss

■■ Finite packet queues

■■ Weighted fair queuingYou can combine different dummynet features within a single dummynetimplementation to create a system that closely emulates the behavior of yourproduction network

WA R N I N G Since dummynet uses the IP firewall features of FreeBSD, it can only be used to emulate IP network behavior Only applications that use IP can

be tested with dummynet.

dummynet Features

The dummynet system works by creating communication pipes between theinput and output network facilities of the FreeBSD device Each communica-tion pipe can be configured separately with individual dummynet features.Figure 14.1 shows a simple dummynet configuration that includes three com-munication pipes

Two pipes are used for handling packets received on the standard systemnetwork interface card, while the third pipe handles packets sent from the sys-tem out to the network interface card Each pipe acts independently from theother, processing packets according to its own rule set

The first two pipes are configured in a weighted fair queuing (WFQ) system,dividing incoming packets between the two pipes, based on a WFQ algorithm.Each pipe is configured with a set bandwidth limitation, allowing only a setnumber of packets to traverse the pipe for a given time This can be used toemulate specifically sized network links, from slow WAN links to high-speedEthernet links

Also associated with the first pipe is a packet loss directive The packet loss

is defined as a percentage of the overall network traffic in the pipe This featureemulates a consistent packet drop situation, such as a faulty network device orbad cabling