You can watch the queue status of the router devices as packets are passedfrom the remote client to the server device.Interpreting the Results After the ns simulation is run, you can ana
Trang 1Running the Model
After creating and saving the simulation model, you can run it using the nscommand-line program:
$ ns test.tcl
Depending on the speed of your Unix host, the simulation may run for a fewseconds, then finish After it finishes, you should see two files: out.nam andout.tr The out.nam file contains the network simulation data for the nam ani-mator program The out.tr file contains the network simulation regarding theraw data transfers
You can observe the network in action by using the nam program with theout.nam file:
$nam out.nam
This starts the nam application, and loads the data from the out.nam file.You may want to click the Relayout button a few times, until the network lay-out suits your taste Figure 19.5 shows the basic layout of the network simula-tion, along with packets as they are being processed
Figure 19.5 The nam network simulation display.
Trang 2You can watch the queue status of the router devices as packets are passedfrom the remote client to the server device.
Interpreting the Results
After the ns simulation is run, you can analyze the out.tr file to observe thedata transfers A sample of the out.tr contents looks like:
+ 1 0 1 tcp 40 - 1 0.0 6.0 0 0
- 1 0 1 tcp 40 - 1 0.0 6.0 0 0 + 1 5 4 tcp 40 - 2 5.0 6.1 0 1
- 1 5 4 tcp 40 - 2 5.0 6.1 0 1
r 1.010003 0 1 tcp 40 - 1 0.0 6.0 0 0 + 1.010003 1 2 tcp 40 - 1 0.0 6.0 0 0
- 1.010003 1 2 tcp 40 - 1 0.0 6.0 0 0
r 1.010003 5 4 tcp 40 - 2 5.0 6.1 0 1 + 1.010003 4 6 tcp 40 - 2 5.0 6.1 0 1
- 1.010003 4 6 tcp 40 - 2 5.0 6.1 0 1
r 1.010006 4 6 tcp 40 - 2 5.0 6.1 0 1
The trace file shows the status of each simulated packet at any given time inthe simulation The format of the trace file is:
event time src dst pkttype pktsize flags fid srcaddr dstaddr seqnum pktid
The event field defines the status of the packet record A plus sign indicatesthat the packet has been placed in the queue for the associated source and des-tination node link A minus sign indicates that the packet has been removed
from the link queue, while a letter r indicates that the destination node has
received the packet You can use this information to monitor the amount ofdata that is received by each node in the simulation
The goal of this simulation was to watch how long it would take each client
to send 10 Mb of data to the server You can use the trace file to watch the datapackets as they are received within the network, and count the data To ensurethat you are tracking data from the right client, you need to choose two points
in the network that are unique to the individual client data paths Monitoringdata received by node 4 from node 3 ensures that it is data received from client
0, while monitoring data received by host 4 from node 5 ensures it is fromclient 5
You can write a simple shell script to create an output file containing thetime field and the sum of the packet size field for specific source and destina-tion nodes A sample would look like this:
cat out.tr | grep ^r | grep “3 4 tcp 1040” | awk ‘{old = old + $6; printf(“%f\t%d\n”, $2, old)}’ > out.34
Trang 3This script scans the trace file, looking for received packets (the ^r part)from host 3 to host 4 (the 3 4 part) that contain data (the 1040 part) That infor-mation is fed into an awk script, which sums the packet sizes, and prints thetime and the packet size sum value The result is redirected to an output file.The result of the output file looks like:
$ head out.34 1.096288 1040 1.101835 2080 1.162349 3120 1.167940 4160 1.173487 5200 1.179034 6240 1.228499 7280 1.234046 8320 1.239593 9360 1.245139 10400
$
By changing the host numbers in the shell script, you can produce a similarfile for the data between hosts 5 and 4, showing the local client data path Now,you can use the xgraph program to chart both data lines and observe the datastreams, as shown in Figure 19.6
Figure 19.6 xgraph display of the data traffic.
Trang 4As seen in the xgraph display, both of the data streams start at 1 second intothe simulation The data stream from client 5 to the server reached 10 Mb atabout 11 seconds into the simulation, while the data stream from client 0 to theserver reached the 10-Mb data mark at about 55 seconds This indicates thatthe remote client transfer took about 54 seconds, while the local client transfertook about 10 seconds.
Performing additional analysis of the trace output, you can compare theindividual times for each data stream It took on average 6 ms for one datapacket to traverse the network from the remote client to the server, while ittook less than 1 ms for the same data to traverse the local network from thelocal client A 5-ms difference does not seem like a long time, but, as seen inthis example, when large amounts of data are traversing the network, it adds
up to a large overall performance delay
Using SSFNet
Next up is the SSFNet model To simulate the model network, you must create
a DML program defining the network devices and links, along with the cols used This section describes the steps necessary to build an SSFNet modeland observe the results
proto-Building the Model
The SSFNet DML model must define the pertinent devices and links to late from the production network Figure 19.7 shows the SSFNet model used tosimulate the sample network
simu-Figure 19.7 SSFNet network model
host 4 router 1 router 2
Trang 5The SSFNet network model uses the Ethernet LAN modeling feature to ulate the speed and delay present in the internal switch network within thebuildings This greatly simplifies the model Each device must also have theproper interfaces configured (shown by the small numbers on the nodes) torepresent the link speeds in the model Figure 19.8 shows the resulting DMLmodel code.
sim-Net [ frequency 1000000000
randomstream [ generator “MersenneTwister”
stream “stream1”
reproducibility_level “timeline”
]
traffic [ pattern [ client 0 servers [nhi 4(0) port 1600]
] pattern [ client 3 servers [nhi 4(0) port 1600]
] ]
host [
id 0 interface [id 0 bitrate 10000000]
route [dest default interface 0]
graph [ ProtocolSession [ name TCPclient use SSF.OS.TCP.test.tcpClient start_time 1.0
start_window 1.0 file_size 10000000 request_size 40 show_report true ]
ProtocolSession [name socket use SSF.OS.Socket.socketMaster] ProtocolSession [name tcp use SSF.OS.TCP.tcpSessionMaster tcpinit[
show_report true ]
] ProtocolSession [name ip use SSF.OS.IP]
Figure 19.8 SSFNet DML model (continued)
Trang 6] ]
host [
id 3 interface [id 0 bitrate 100000000]
nhi_route [dest default interface 0 next_hop 2(0)]
graph [ ProtocolSession [ name tcpClient use SSF.OS.TCP.test.tcpClient start_time 1.0
start_window 1.0 file_size 10000000 request_size 40 show_report true ]
ProtocolSession [name socket use SSF.OS.Socket.socketMaster] ProtocolSession [name tcp use SSF.OS.TCP.tcpSessionMaster tcpinit [
show_report true ]
] ProtocolSession [name ip use SSF.OS.IP]
] ]
host [
id 4 interface [id 0 bitrate 100000000 tcpdump test7.dmp]
nhi_route [dest default interface 0 next_hop 2(0)]
graph [ ProtocolSession [ name TCPServer use SSF.OS.TCP.test.tcpServer port 1600
request_size 10 show_report true ]
ProtocolSession [name socket use SSF.OS.Socket.socketMaster] ProtocolSession [name tcp use SSF.OS.TCP.tcpSessionMaster tcpinit[
show_report true
Figure 19.8 (continued)
Trang 7] ] ProtocolSession [name ip use SSF.OS.IP]
] ]
router [
id 1 interface [id 0 bitrate 100000000]
interface [id 1 bitrate 1500000]
graph [ProtocolSession [name ip use SSF.OS.IP]]
route [dest default interface 1]
] router [
id 2 interface [id 0 bitrate 100000000]
interface [id 1 bitrate 1500000]
graph [ProtocolSession [name ip use SSF.OS.IP]]
route [dest default interface 1]
]
link [attach 0(0) attach 1(0) delay 0.010]
link [attach 1(1) attach 2(1)]
link [attach 2(0) attach 3(0) attach 4(0) delay 0.010]
]
Figure 19.8 (continued)
Hosts 0 and 3 are configured as TCP client devices, capable of sending a
10-Mb file using standard TCP Host 4 is configured as a TCP server device,accepting the 10-Mb file stream from the clients, and returning an acknowl-edgment packet Two router devices are configured to simulate the T1 linkwithin the production network Since no IP addresses are assigned to the sim-ulation, default routes are specified for each device on the network Both of thelocal networks are modeled using a single LAN connecting the devices, and a10-ms delay period
Running the Model
The SSFNet model is run using the java command-line interpreter, along with the SSF.Net.Net base class used in the Raceway SSFNet system Sinceeach of the client devices and the server device use the show_report feature,you can observe the start and end of the data streams The output looks like:
$ java SSF.Net.Net 100 test.dml -
| Raceway SSF 1.1b01 (15 March 2002)
Trang 8| (c)2000,2001,2002 Renesys Corporation
|
| ??
| -
CIDR IP Block b16 NHI 0.0.0.0/27 0x00000000
** Using specified 1.0ns clock resolution
- Phase I: construct table of routers and hosts
- Phase II: connect Point-To-Point links
- Phase III: add static routes
## Net config: 5 routers and hosts
## Elapsed time: 0.667 seconds
** Running for 100000000000 clock ticks (== 100.0 seconds sim time) 1.919942997 TCP host 3 src={0.0.0.2:10001} dest={0.0.0.3:1600} Active Open
1.920456578 TCP host 0 src={0.0.0.13:10001}dest={0.0.0.3:1600} Active Open
1.930046197 TCP host 4 src={0.0.0.3:1600} dest={0.0.0.2:10001} SYN recvd 1.941005111 TCP host 4 src={0.0.0.3:1600} dest={0.0.0.13:10001} SYN recvd
14.39844274 [ sid 1 start 1.919942997 ] tcpClient 3 srv 4(0) rcvd 10000000B at 6411.027kbps - read() SUCCESS
14.39844274 TCP host 3 src={0.0.0.2:10001} dest={0.0.0.3:1600} Active Close
14.40854594 TCP host 4 src={0.0.0.3:1600} dest={0.0.0.2:10001} Active Close
14.40854594 TCP host 4 src={0.0.0.3:1600} dest={0.0.0.2:10001} Passive Close
57.521336685 [ sid 1 start 1.920456578 ] TCPclient 0 srv 4(0) rcvd 10000000B at 1438.826kbps - read() SUCCESS
57.521336685 TCP host 0 src={0.0.0.13:10001} dest={0.0.0.3:1600} Active Close
57.541885218 TCP host 4 src={0.0.0.3:1600} dest={0.0.0.13:10001} Active Close
57.541885218 TCP host 4 src={0.0.0.3:1600} dest={0.0.0.13:10001} Passive Close
-| 1 timelines, 5 barriers, 117752 events, 7450 ms, 17 Kevt/s -
Trang 9By analyzing the output from the simulation, you can see the start and stoptimes for each data stream The next step is to analyze this information to seehow the data transfers performed.
Interpreting the Results
From the output data produced by SSFNet, you can determine the time it tookfor each individual data transfer For the slow link from host 0 to host 4, thetransfer started at about 1.92 seconds in the simulation, and finished at about57.52 seconds, for a total transfer time of about 55.6 seconds, very close to whatthe ns test predicted
For the local file transfer, the transfer again started at about 1.92 seconds inthe simulation, and finished at about 14.4 seconds, for a total transfer time ofabout 12.5 seconds The ns prediction for this value was a little less close, butstill in the same ballpark Remember, the point of the simulation is to comparethe two transfer times, which in both cases, so far, indicate that remote clientswill observe a significant decrease in performance when running the networkapplication
Using dummynet
The first network emulator package to test is the dummynet application This
is used to create a test network environment on a FreeBSD system that canemulate the actual production network This section explains how to create thedummyet network emulation, and how to observe network application behav-ior within the test network
Building the Emulation Environment
Since the dummynet application intercepts packets at the kernel level of theFreeBSD system, you can configure dummynet to affect data traffic eitherbetween two installed network cards, or from the local system to the networkcard or to itself For this test, I will configure dummynet to intercept packetsbetween itself and a remote device on the test network The test network appli-cation will be an FTP session from the local machine to the remote test host
Dummynet builds rules that affect network traffic as it traverses the systemkernel A single rule will define the total network behavior between the twoendpoints You must incorporate all network delays and bandwidth limita-tions within the single rule
WA R N I N G Remember that dummynet affects the network traffic both when
it enters the kernel and as it leaves the kernel, so any delays configured must
be cut in half.
Trang 10Since dummynet uses the ipfw program, you must clear out any existingrules that may affect the test, and then enter the rules necessary to create theemulation rule:
# ipfw flush Are you sure [yn] y
# ipfw add pipe 1 tcp from 192.168.1.1 to 192.168.1.6
# ipfw add pipe 2 tcp from 192.168.1.6 to 192.168.1.6
# ipfw pipe 1 config bw 1.5Mb/s delay 10ms
# ipfw pipe 2 config bw 1.5Mb/s delay 10ms
The first command clears any existing rules in the ipfw table The secondcommand creates a pipe used for all TCP traffic originating from the local host
IP address to the specific IP address of the remote test host The next commandcreates a second pipe handling traffic in the opposite direction
After the two pipes are created, they can be configured for the appropriatenetwork bandwidth limitation and delay time These create an emulationenvironment for the T1 router and incorporate a network delay representingthe delay found on the local network switches After the first emulation iscomplete, you must remove these rules, using the flush option, and create twonew rules using the 100-Mbps link speed to emulate the local client test
Running the Emulation
After creating the first set of emulation rules, you can begin a simple networkapplication test by starting an FTP session between the test hosts and sending
a 10-Mb file to represent the data stream between the hosts First, you mustcreate a sample 10-Mb file to use
I like to echo a string of a known size to a file, then ping-pong copy the file
to another file until the size is appropriate:
$ echo 0123456789012345678901234 > test
$ cat test > test1
$ cat test1 >> test
$ cat test >> test1
.
$ ls -al test -rw-r r 1 rich rich 10000000 Jan 28 15:39 test
$
This example creates a 25-byte file, and continually concatenates it onto awork file until the file size is 10 Mb When the test file is complete, you areready to start the FTP session:
Trang 11$ ftp 192.168.1.6 Connected to 192.168.1.6.
220 ProFTPD 1.2.2rc1 Server (ProFTPD Default Installation) Name (192.168.1.6:rich): rich
331 Password required for rich.
Password:
230 User rich logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> put test local: test remote: test
200 PORT command successful.
150 Opening BINARY mode data connection for test.
# ipfw pipe 1 config bw 100Mb/s delay 10ms
Again, send the sample file via FTP, and watch the results This time the FTPoutput shows the total transfer time for the 10-Mb file as 11 seconds Both ofthese values are right in line with the results seen in the network simulations
Using NIST Net
The next network emulation package to test is the NIST Net application Thisapplication allows you to emulate the production network on a Linux system.This section explains how to create the NIST Net model, and how to observenetwork application behavior within the test network
Building the Emulation Environment
Like dummynet, NIST Net can be used as either a bridge device between arate network segments, a router device between different subnetworks, or astandalone emulator, affecting only traffic within the local loopback address
sep-In both the bridging and routing scenarios, you must have two network cards
in your Linux system, and configure the system for either bridging or routing.You can configure the NIST Net module to affect only specific packets for spe-cific IP addresses, port numbers, and protocols
Trang 12For this example, I configured NIST Net to affect all IP network between thelocal host device and a specific remote IP address connected via a 100-Mb hub
on a test network No external traffic will be present to taint the test samples.For the network application, I will FTP a 10-Mb file to emulate the client/server transactions for 10 Mb of data
With NIST Net, you must emulate all the production network characteristicswithin a single model command line This forces you to determine the end-to-end bandwidth limitations, as well as any delays, packet drops, and retrans-missions As with the dummynet model, the NIST Net model defines thebottleneck speed along the network path, and incorporates any networkdelays that are present For this emulation, I will use a 1.5-Mbps bottleneckspeed to represent the T1 line limitation for the remote client, and a 100-Mbpsbottleneck speed for the local client The remote click will use a 20-ms delayrepresenting both sets of local switches in the network path, while the localclient will use a single 10-ms delay
WA R N I N G Remember that NIST Net specifies the network bandwidth value
as bytes per second, not bits per second You must divide the network speed by
8 to use the correct speed emulation.
The commands used to start and configure NIST Net for the first test are:
The third line creates a second rule that duplicates the settings of the firstrule, but for the return direction of the connection path Finally, the NIST Netemulation is started, using the -u command-line option
WA R N I N G Don’t forget to use the -u option to start the emulator Without
it, the configured rules will not be active and affect network traffic.
Trang 13Running the Emulation
After NIST Net has been started, you can create a test file to FTP between thetwo test hosts Any standard method of creating a 10-Mb file can be used
Now that you have a test file, you can begin the emulated network transfer:ftp> put test
local: test remote: test
200 PORT command successful.
150 Opening BINARY mode data connection for test.
226 Transfer complete.
10000000 bytes sent in 54.8 secs (1.8e+02 Kbytes/sec)
As you can see from the FTP output, the NIST Net emulator did its job, iting the bandwidth of the file transfer so it took 54.8 seconds Next you mustchange the rules to reflect a 100-Mbps bandwidth, emulating the local clientconnection to the server:
lim-# cnistnet -a 192.168.1.1 192.168.1.6 add new —bandwidth 12500000 —delay 10
The results from this test indicated that the transfer took 11.5 seconds.Again, this is similar to the other emulation and simulation results
Final Results
After running the network emulators and simulators, you now have a goodidea of how the network application will perform on the actual productionnetwork Table 19.1 recaps the results from each of the tests
As you can see from the test results, all of the tools produce somewhat ilar results for the production network Now, it is time to watch the real net-work application perform on the production network, to see if the tools areaccurate
sim-Table 19.1 Test Recap
Trang 14Again, a simple FTP session is used to transfer a 10-Mb file between hosts onthe network The first test uses hosts separated by a T1 link, connecting tworemote networks:
ftp> put test local: test remote: test
200 PORT command successful.
150 Opening BINARY mode data connection for test.
226 Transfer complete.
10000000 bytes sent in 58.6 secs (1.5e+02 Kbytes/sec)
The actual data transfer across the T1 link took 58.6 seconds, which is sistent with the simulation and emulation results All of the network applica-tion performance tools were close enough to the correct answer that they could
con-be relied on to determine other network application con-behavior You can alsofine-tune each of the network models to more accurately represent the actualproduction network environment
Summary
This section of the book presented five different scenarios for testing networkapplication performance for a production network environment This chapterconcluded the section by comparing the tools in a common scenario
The first step to working with network application performance tools is toproperly model the production network and application data Most produc-tion networks are complicated, and trying to model every network devicewould be impractical Instead, you must determine which network devicesand links are the bottlenecks, and which ones contribute to network problemssuch as delays, dropped packets, and packet retransmissions After creating asimplified version of the production network, you are ready to simulate andemulate
Both of the network simulation tools presented, ns and SSFNet, model work devices, links, and data, using configuration files By defining only thesimplified network elements in the simulation, you can easily create an accu-rate simulation environment that will produce data consistent with the realproduction network This enables you to perform lots of “what if”, easily mod-ifying the simulation configuration by moving network devices into differentlocations, increasing or decreasing network link speeds, and modifying net-work application data that traverses the network
net-The network emulation tools presented, dummynet and NIST Net, bothmodify data traffic as it traverses the system kernel By placing the emulationtool between two endpoints (or between a remote endpoint and the tool host,
Trang 15using the tool host as the local endpoint), you can force actual network traffic
to be modified by the emulation Configuring the emulation tools is similar toconfiguring the network simulator models Each emulator must have rulesdefined for how the data traffic flow will be affected By limiting the band-width of the data flow to the network bottleneck speed, and adding delays,dropped packets, and retransmissions as necessary, you can easily emulate theproduction network environment within a test network
As seen from the results, each of the network application performance toolsproduced results that were consistent with the actual results observed on theproduction network This proves that you can indeed easily duplicate produc-tion network performance with a simplified test network environment
This chapter concludes our walk through network performance tools I hopeyou have enjoyed your experience with each of the tools, and will continue tolearn and experiment in your network environment With the advent of newnetwork devices (and network applications), there is always something new tolearn in the field of network performance Hopefully this book has presented
a good place to start, and you will continue your education in the field Thefollowing appendix contains lots of Web resources for network performance It
is a good idea to stay in touch with the latest trends and ideas, to keep yournetwork running smoothly Happy networking
Trang 17One of the advantages of using open source tools is their availability on theInternet There are scores of Web sites devoted to network performance issuesand the tools used to monitor and analyze network performance This appen-dix lists some of the resources that are available for each of the tools presented
in this book As with any Internet resource, the URLs provided are subject tochange
Network Monitoring Tools
■■ The tcpdump Web site: www.tcpdump.org
■■ The libpcap library: www.tcpdump.org/release/libpcap-0.7.1.tar.gz
■■ The winpcap library: http://winpcap.polito.it/install/default.htm
■■ The windump application:
http://windump.polito.it/install.bin/alpha.WinDump.exe
■■ The Analyzer application: http://analyzer.polito.it/
■■ The Ethereal application: www.ethereal.com/distribution/
Resources
A P P E N D I X