This chapter is from the book
This chapter is from the book
This chapter is from the book
Some Network-Monitoring Tools
Many times system performance can be relative to external factors such as the network. Unix has a vast array of tools to examine network performance, from single host-monitoring software to applications than can monitor and manage vast WANs. This section looks at four relatively low-key applications for monitoring network activity:
ping
traceroute
tcpdump
ntop
ping
The ping utility is a very simple program that is most often used to simply see if a host is alive on the network. However, the return information from ping can often tell you how well a particular host-to-host connection is performing. The following is a sample of a ping session:
$ ping tesla PING tesla.dp.asi (192.187.226.6): 56 data bytes 64 bytes from 192.187.226.6: icmp_seq=0 ttl=255 time=6.119 ms 64 bytes from 192.187.226.6: icmp_seq=1 ttl=255 time=0.620 ms 64 bytes from 192.187.226.6: icmp_seq=2 ttl=255 time=3.483 ms 64 bytes from 192.187.226.6: icmp_seq=3 ttl=255 time=1.340 ms 64 bytes from 192.187.226.6: icmp_seq=4 ttl=255 time=0.633 ms 64 bytes from 192.187.226.6: icmp_seq=5 ttl=255 time=7.803 ms 64 bytes from 192.187.226.6: icmp_seq=6 ttl=255 time=5.475 ms --- tesla.dp.asi ping statistics --- 7 packets transmitted, 7 packets received, 0% packet loss round-trip min/avg/max/std-dev = 0.620/3.639/7.803/2.681 ms
Not too bad at all. Now I have purposely saturated the interface on host tesla (with several other pings running with the -f option to flood it at once, of course). Look at the results:
$ ping tesla PING tesla.dp.asi (192.187.226.6): 56 data bytes 64 bytes from 192.187.226.6: icmp_seq=0 ttl=255 time=3.805 ms 64 bytes from 192.187.226.6: icmp_seq=1 ttl=255 time=1.804 ms 64 bytes from 192.187.226.6: icmp_seq=2 ttl=255 time=8.672 ms 64 bytes from 192.187.226.6: icmp_seq=3 ttl=255 time=1.616 ms 64 bytes from 192.187.226.6: icmp_seq=4 ttl=255 time=6.793 ms 64 bytes from 192.187.226.6: icmp_seq=5 ttl=255 time=1.607 ms 64 bytes from 192.187.226.6: icmp_seq=6 ttl=255 time=2.393 ms 64 bytes from 192.187.226.6: icmp_seq=7 ttl=255 time=1.601 ms 64 bytes from 192.187.226.6: icmp_seq=8 ttl=255 time=6.073 ms 64 bytes from 192.187.226.6: icmp_seq=9 ttl=255 time=1.615 ms 64 bytes from 192.187.226.6: icmp_seq=10 ttl=255 time=9.402 ms 64 bytes from 192.187.226.6: icmp_seq=11 ttl=255 time=1.875 ms 64 bytes from 192.187.226.6: icmp_seq=12 ttl=255 time=1.815 ms --- tesla.dp.asi ping statistics --- 13 packets transmitted, 13 packets received, 0% packet loss round-trip min/avg/max/std-dev = 0.601/2.774/8.402/2.802 ms
As you can see, there is a slightly higher time lapse, on average.
ping has a number of useful options. Table 3.10 lists some of them with example usage ideas:
Table 3.10 ping Options
|
-c |
This option means that ping will ping a node only c times. This is especially useful for noninteractive scripts or if you are not interested in watching ping for more than a quick test to determine whether it is alive. |
-f |
The flood option sends requests as fast as the host you are pinging from can. This is a good way to measure just how well a host can send them. As mentioned in a previous example, it's also an easy way to load down a system for testing. |
-r |
This option bypasses routing tables and helps if a new node is on the network but the system you are pinging from either is not aware of it or is not in the same subnet. |
-s |
This option can modify the packet size and is useful for seeing whether the node that is being pinged is having issues with the size of packets being sent to it from other nodes. |
traceroute
The traceroute utility is invaluable for discovering where a problem on a network might be located. It also is of great use in ensuring that your host is talking to the network just fine and that any problems might lie elsewhere. On this particular network, I show two traceroutes, one to a host that is local to the network and one to a remote host on a network in another city. The difference between these is astounding.
Here's the local traceroute:
$ traceroute andy traceroute to strider.diverge.org (192.168.1.1), 64 hops max, 40 byte packets 1 strider.diverge.org (192.168.1.1) 0.547 ms 0.469 ms 3.383 ms $
And here's the remote traceroute:
$ traceroute www.diverge.org traceroute to www.diverge.org (192.168.2.2), 64 hops max, 40 byte packets 1 strider.diverge.org (192.168.1.1) 7.791 ms 7.182 ms 6.457 ms 2 gandalf.diverge.org (192.168.2.1) 43.978 ms 41.325 ms 43.904 ms 3 www.diverge.org (192.168.2.2) 41.293 ms 41.366 ms 41.683 ms $
In this output, you easily can see the routers between my localhost and the remote host www.diverge.org—they are strider.diverge.org and gandalf.diverge.org. The fields are hop-number hostname IPaddress times.
Using the Sniffer tcpdump
A sniffer is a network-monitoring system that captures a great deal of information about the real content of a given network. Sniffers are particularly powerful because they allow for the storage of several layers of TCP information, which, of course, can be used for performing malicious attacks as well as monitoring.
On the upside, a sniffer can provide detailed information for troubleshooting efforts. Figure 3.4 is a snapshot of tcpdump.
){kind=link}
Figure 3.4 tcpdump output.
The output when tcpdump is started with no options is dizzying. The tcpdump sniffer has an immense amount of command-line switches and options.
Some Practical Applications for tcpdump
Obviously, the output of tcpdump is rather intense. After reviewing some of the options, you have probably surmised that there are ways to focus the tcpdump utility to look for particular information. Table 3.11 describes some options and shows what particular problem they can be used to address.
Table 3.11
|
Command String |
Application |
|---|---|
|
tcpdump tcp host <ip_address> |
SYN floods |
|
tcpdump dst host <ip_address> |
Network stack overflows (a.k.a. Ping of Death) |
|
tcpdump icmp dst host <broadcast_address> |
Smurf attacks |
|
tcpdump -e host <ip_address> |
Duplicate IP addresses |
|
tcpdump arp |
ARP misconfiguration |
|
tcpdump icmp |
Routing issues |
As an example, let's say that you want to look at ICMP traffic on the local network:
# [root@kerry /root]# tcpdump icmp Kernel filter, protocol ALL, datagram packet socket tcpdump: listening on all devices 11:48:30.214757 eth1 M 172.16.141.99 > 192.187.225.50: icmp: echo request 11:48:30.215135 eth1 M 172.16.141.99 > arouter.local.net: icmp: echo request 11:48:32.277764 eth1 M 172.16.141.99 > frame.local.net: icmp: echo request . . .
This output tells you that there are a lot of echo requests from the node at 172.16.141.99. In fact, this is a new router being installed, and the administrator is probing the network from the router.