74
line to reach the rest of the Internet, you dont really have T1 access. Finally, ISPs should have multiple peering arrangements connections to the global Internet
so that if one connection goes down, there is an alternative path available. Of course, your ISP may feel differently. And, if the price is really good, your arrangement
may make sense. Clearly, not all service arrangements are the same. Youll want to come to a clear understanding with your ISP if you can. Unfortunately, with many ISPs, the
information you will need is a closely guarded secret. As always, caveat emptor.
4.2.4 Traffic Measurements with netstat
In the ideal network, throughput numbers, once you account for overhead, will be fairly close to your bandwidth numbers. But few of us have our networks all to ourselves. When throughput numbers are
lower than expected, which is usually the case, youll want to account for the difference. As mentioned before, this could be hardware or software related. But usually it is just the result of the other traffic on
your network. If you are uncertain of the cause, the next step is to look at the traffic on your network.
There are three basic approaches you can take. First, the quickest way to get a summary of the activity on a link is to use a tool such as netstat. This approach is described here. Or you can use packet
capture to look at traffic. This approach is described in Chapter 5
. Finally, you could use SNMP-based tools like ntop. SNMP tools are described in
Chapter 7 . Performance analysis tools using SNMP are
described in Chapter 8
. The program netstat was introduced in
Chapter 2 . Given that netstats role is to report network data
structures, it should come as no surprise that it might be useful in this context. To get a quick picture of the traffic on a network, use the -i option. For example:
bsd2 netstat -i Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lp0 1500 Link 0 0 0 0 0 ep0 1500 Link 00.60.97.06.22.22 13971293 0 1223799 1 0
ep0 1500 205.153.63 bsd2 13971293 0 1223799 1 0 tun0 1500 Link 0 0 0 0 0
sl0 552 Link 0 0 0 0 0 ppp0 1500 Link 0 0 0 0 0
lo0 16384 Link 234 0 234 0 0 lo0 16384 127 localhost 234 0 234 0 0
The output shows the number of packets processed for each interface since the last reboot. In this example, interface ep0 has received 13,971,293 packets
Ipkts
with no errors
Ierrs
, has sent 1,223,799 packets
Opkts
with 1 error
Oerrs
, and has experienced no collisions
Coll
. A few errors are generally not a cause for alarm, but the percentage of either error should be quite low,
certainly much lower than 0.1 of the total packets. Collisions can be higher but should be less than 10 of the traffic. The collision count includes only those involving the interface. A high number of
collisions is an indication that your network is too heavily loaded, and you should consider segmentation. This particular computer is on a switch, which explains the absence of collision.
Collisions are seen only on shared media.
If you want output for a single interface, you can specify this with the -I option. For example:
bsd2 netstat -Iep0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
75
ep0 1500 Link 00.60.97.06.22.22 13971838 0 1223818 1 0 ep0 1500 205.153.63 bsd2 13971838 0 1223818 1 0
This was run a couple of minutes later so the numbers are slightly larger. Implementations vary, so your output may look different but should contain the same basic
information. For example, here is output under Linux:
lnx1 netstat -i Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg eth0 1500 0 7366003 0 0 0 93092 0 0 0
BMRU eth1 1500 0 289211 0 0 0 18581 0 0 0 BRU
lo 3924 0 123 0 0 0 123 0 0 0 LRU
As you can see, Linux breaks down lost packets into three categories—errors, drops, and overruns. Unfortunately, the numbers netstat returns are cumulative from the last reboot of the system. What is
really of interest is how these numbers have changed recently, since a problem could develop and it would take a considerable amount of time before the actual numbers would grow enough to reveal the
problem.
[6] [6]
System Performance Tuning by Mike Loukides contains a script that can be run at regular intervals so that differences are more apparent.
One thing you may want to try is stressing the system in question to see if this increases the number of errors you see. You can use either ping with the -l option or the spray command. spray is discussed in
greater detail in Chapter 9
. First, run netstat to get a current set of values:
bsd2 netstat -Iep0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
ep0 1500 Link 00.60.97.06.22.22 13978296 0 1228137 1 0 ep0 1500 205.153.63 bsd2 13978296 0 1228137 1 0
Next, send a large number of packets to the destination. In this example, 1000 UDP packets were sent:
bsd1 spray -c1000 205.153.63.239 sending 1000 packets of lnth 86 to 205.153.63.239 ...
in 0.09 seconds elapsed time 464 packets 46.40 dropped
Sent: 11267 packetssec, 946.3K bytessec Rcvd: 6039 packetssec, 507.2K bytessec
Notice that this exceeded the capacity of the network as 464 packets were dropped. This may indicate a congested network. More likely, the host is trying to communicate with a slower machine. When
spray is run in the reverse direction, no packets are dropped. This indicates the latter explanation. Remember, spray is sending packets as fast as it can, so dont make too much out of dropped packets.
Finally, rerun nestat to see if any problems exist:
bsd2 netstat -Iep0
76
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ep0 1500 Link 00.60.97.06.22.22 13978964 0 1228156 1 0
ep0 1500 205.153.63 bsd2 13978964 0 1228156 1 0
No problems are apparent in this example. If problems are indicated, you can get a much more detailed report with the -s option. Youll probably
want to pipe the output to more so it doesnt disappear off the top of the screen. The amount of output data can be intimidating but can give a wealth of information. The information is broken down by
protocol and by error types such as bad checksums or incomplete headers.
On some systems, such as FreeBSD, a summary of the nonzero values can be obtained by using the -s option twice, as shown in this example:
bsd2 netstat -s -s ip:
255 total packets received 255 packets for this host
114 packets sent from this host icmp:
ICMP address mask responses are disabled igmp:
tcp: 107 packets sent
81 data packets 8272 bytes 26 ack-only packets 25 delayed
140 packets received 77 acks for 8271 bytes
86 packets 153 bytes received in-sequence 1 connection accept
1 connection established including accepts 77 segments updated rtt of 78 attempts
2 correct ACK header predictions 62 correct data packet header predictions
udp: 115 datagrams received
108 broadcastmulticast datagrams dropped due to no socket 7 delivered
7 datagrams output
A summary for a single protocol can be obtained with the -p option to specify the protocol. The next example shows the nonzero statistics for TCP:
bsd2 netstat -p tcp -s -s tcp:
147 packets sent 121 data packets 10513 bytes
26 ack-only packets 25 delayed 205 packets received
116 acks for 10512 bytes 122 packets 191 bytes received in-sequence
1 connection accept 1 connection established including accepts
116 segments updated rtt of 117 attempts 2 correct ACK header predictions
88 correct data packet header predictions
77
This can take a bit of experience to interpret. Begin by looking for statistics showing a large number of errors. Next, identify the type of errors. Typically, input errors are caused by faulty hardware.
Output errors are a problem on or at the local host. Data corruption, such as faulty checksums, frequently occurs at routers. And, as noted before, congestion is indicated by collisions. Of course,
these are generalizations, so dont read too much into them.
4.3 Microsoft Windows
Most of the tools we have been discussing are available in one form or another for Windows platforms. Microsofts implementation of traceroute, known as tracert, has both superficial and fundamental
differences from the original implementation. Like ping, tracert requires a DOS window to run. We have already seen an example of its output. tracert has fewer options, and there are some superficial
differences in their flags. But most of traceroutes options are rarely used anyway, so this isnt much of a problem.
A more fundamental difference between Microsofts tracert and its Unix relative is that tracert uses ICMP packets rather than UDP packets. This isnt necessarily bad, just different. In fact, if you have
access to both traceroute and tracert, you may be able to use this to your advantage in some unusual circumstances. Its behavior may be surprising in some cases. One obvious implication is that routers
that block ICMP messages will block tracert, while traceroutes UDP packets will be passed.
As noted earlier in this chapter, Mentors Java implementation of ttcp runs under Windows if you can find it. Both netperf and iperf have also been ported to Windows. Another freely available program
worth considering is Qcheck from Ganymede Software, Inc. This program requires that Ganymedes Performance Endpoints software be installed on systems at each end of the link. This software is also
provided at no cost and is available for a wide variety of systems ranging from Windows to MVS. In addition to supporting IP, the software supports SPX and IPX protocols. The software provides ping-
like connectivity checks, as well as response time and throughput measurements.
As noted in Chapter 2
, Microsoft also provides its own version of netstat. The options of interest here are -e and -s. The -e option gives a brief summary of activity on any Ethernet interface:
C:\netstat -e Interface Statistics
Received Sent Bytes 9840233 2475741
Unicast packets 15327 16414 Non-unicast packets 9268 174
Discards 0 0 Errors 0 0
Unknown protocols 969
The -s option gives the per-protocol statistics:
C:\netstat -s IP Statistics
Packets Received = 22070 Received Header Errors = 0
