Packet Capture, part 1 - Page 2

 By O'Reilly Press
Page 2 of 3   |  Back to Page 1
Print Article

1.2. Access to Traffic

You can capture traffic only on a link that you have access to. If you can't get traffic to an interface, you can't capture it with that interface. While this might seem obvious, it may be surprisingly difficult to get access to some links on your network. On some networks, this won't be a problem. For example, 10Base2 and 10Base5 networks have shared media, at least between bridges and switches. Computers connected to a hub are effectively on a shared medium, and the traffic is exposed. But on other systems, watch out!

Clearly, if you are trying to capture traffic from a host on one network, it will never see the local traffic on a different network. But the problem doesn't stop there. Some networking devices, such as bridges and switches, are designed to contain traffic so that it is seen only by parts of the local network. On a switched network, only a limited amount of traffic will normally be seen at any interface.[2] Traffic will be limited to traffic to or from the host or to multicast and broadcast traffic. If this includes the traffic you are interested in, so much the better. But if you are looking at general network traffic, you will use other approaches.

[2]This assumes the switches have been running long enough to have a reasonably complete address table. Most switches forward traffic onto all ports if the destination address is unknown. So when they are first turned on, switches look remarkably like hubs.

Not being able to capture data on an interface has both positive and negative ramifications. The primary benefit is that it is possible to control access to traffic with an appropriate network design. By segmenting your network, you can limit access to data, improving security and enhancing privacy.

Lack of access to data can become a serious problem, however, when you must capture that traffic. There are several basic approaches to overcome this problem. First, you can try to physically go to the traffic by using a portable computer to collect the data. This has the obvious disadvantage of requiring that you travel to the site. This may not be desirable or possible. For example, if you are addressing a security problem, it may not be feasible to monitor at the source of the suspected attack without revealing what you are doing. If you need to collect data at multiple points simultaneously, being at different places at the same time is clearly not possible by yourself.

Another approach is to have multiple probe computers located throughout your network. For example, if you have computers on your network that you can reach using telnet, ssh, X Window software, or vnc, you can install the appropriate software on each. Some software has been designed with remote probing in mind. For example, Microsoft's netmon supports the use of a Windows platform as a probe for collecting traffic. Data from the agents on these machines can be collected by a central management station. Some RMON probes will also do this. (vnc and ssh are described in . netmon is briefly described later in this chapter, and RMON is described in .)

When dealing with switches, there are two common approaches you can take. (Several other techniques that I can't recommend are described later in this chapter.) One approach is to augment the switch with a spare hub. Attach the hub to the switch and move from the switch to the hub only the connections that need to be examined. You could try replacing the switch with a hub, but this can be disruptive and, since a hub inherently has a lower capacity, you may have more traffic than the hub can handle. Augmenting the switch with a hub is a better solution.

Buying a small portable hub to use in establishing a probe point into your network is certainly worth the expense. Because you will be connecting a hub to a switch, you will be using both crossover and patch cables. Be sure you work out the details of the cabling well before you have to try this approach on a problematic network. Alternately, there are several commercially available devices designed specifically for patching into networks. These devices include monitoring switches, fiber splitters, and devices designed to patch into 100-Mbps links or links with special protocols. If your hardware dictates such a need, these devices are worth looking into.


Here is a riddle for you -- when is a hub not a hub? In recent years, the distinction between hubs and switches has become blurred. For example, a 10/100 autoswitching hub may be implemented, internally, as a 10-Mbps hub and a 100-Mbps hub connected by a dual-port switch. With such a device, you may not be able to see all the traffic. In the next few years, true hubs may disappear from the market. You may want to keep this in mind when looking for a hub for traffic monitoring.

A second possibility with some switches is to duplicate the traffic from one port onto another port. If your switch supports this, it can be reconfigured dynamically to copy traffic to a monitoring port. Other ports continue functioning normally so the monitoring appears transparent to the rest of the switch's operation. This technique is known by a variety of names. With Bay Network products, this is known as conversation steering. Cisco refers to this as monitoring or using a spanning port. Other names include port aliasing and port mirroring.

Unfortunately, many switches either don't support this behavior or place limitations on what can be done. For instance, some switches will allow traffic to be redirected only to a high-speed port. Implementation details determining exactly what can be examined vary greatly. Another problem is that some types of errors will be filtered by the switch, concealing possible problems. For example, if there are any framing errors, these will typically be discarded rather than forwarded. Normally, discarding these packets is exactly what you want the switch to do, just not in this context. You'll have to consult the documentation with your switch to see what is possible.

This article was originally published on Nov 9, 2001
Get the Latest Scoop with Networking Update Newsletter