Home > Articles

  • Print
  • + Share This
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


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 ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=6.119 ms
64 bytes from icmp_seq=1 ttl=255 time=0.620 ms
64 bytes from icmp_seq=2 ttl=255 time=3.483 ms
64 bytes from icmp_seq=3 ttl=255 time=1.340 ms
64 bytes from icmp_seq=4 ttl=255 time=0.633 ms
64 bytes from icmp_seq=5 ttl=255 time=7.803 ms
64 bytes from 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 ( 56 data bytes
64 bytes from icmp_seq=0 ttl=255 time=3.805 ms
64 bytes from icmp_seq=1 ttl=255 time=1.804 ms
64 bytes from icmp_seq=2 ttl=255 time=8.672 ms
64 bytes from icmp_seq=3 ttl=255 time=1.616 ms
64 bytes from icmp_seq=4 ttl=255 time=6.793 ms
64 bytes from icmp_seq=5 ttl=255 time=1.607 ms
64 bytes from icmp_seq=6 ttl=255 time=2.393 ms
64 bytes from icmp_seq=7 ttl=255 time=1.601 ms
64 bytes from icmp_seq=8 ttl=255 time=6.073 ms
64 bytes from icmp_seq=9 ttl=255 time=1.615 ms
64 bytes from icmp_seq=10 ttl=255 time=9.402 ms
64 bytes from icmp_seq=11 ttl=255 time=1.875 ms
64 bytes from 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


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.


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.


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.


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.


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 (, 64 hops max, 40 byte packets
 1  strider.diverge.org (  0.547 ms  0.469 ms  3.383 ms

And here's the remote traceroute:

$ traceroute www.diverge.org
traceroute to www.diverge.org (, 64 hops max, 40 byte packets
 1  strider.diverge.org (  7.791 ms  7.182 ms  6.457 ms
 2  gandalf.diverge.org (  43.978 ms  41.325 ms  43.904 ms
 3  www.diverge.org (  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.

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


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 > icmp: echo request
11:48:30.215135 eth1 M > arouter.local.net: icmp: echo request
11:48:32.277764 eth1 M > frame.local.net: icmp: echo request
. . .

This output tells you that there are a lot of echo requests from the node at In fact, this is a new router being installed, and the administrator is probing the network from the router.

  • + Share This
  • 🔖 Save To Your Account