- What the Heck Is a Protocol Analyzer?
- Packet Analyzers
- Net Therapy 101: Techniques for Using Your Analyzer
- Appropriate Analysis: Some Analyzer Scenarios
- Packet Analyzer Limitations and Solutions
- Summary
- Q&A
- Workshop
This chapter is from the book
This chapter is from the book
This chapter is from the book
Packet Analyzer Limitations and Solutions
Using an analyzer can be as much of a time sink as you're willing to let it be. If you were the kid in elementary school who had a good time reading the dictionary, you'll have a great time pouring over protocol decodes. If, however, you need to get a lot of work done, you might have to sigh and save the protocol decodes for a less busy time—and employ your black box troubleshooting skills to isolate if and where you need to use your analyzer.
Now it's time for the physical limitations: Remember that an analyzer can only listen in on a "party line." You cannot listen to a station that has a point-to-point connection to a switch because there's no hub to connect to and listen in on. What do you do?
If you are using switches, look in your switch documentation for a feature called port mirroring. (Cisco calls it SPAN, for Switched Port Analysis) This allows you to specify which port of the switch you want to listen in to. Just plug in your analyzer on another switch port, and the switch will do its own wiretap on the port and tell your analyzer all about it. Cool!
If your switch doesn't support port mirroring, you can always "roll your own" wiretap, as illustrated in Figure 21.13. Simply do the following:
){kind=link}
Obtain a mini-hub.
Unplug the network cable from the station you want to "wire tap."
Plug that station's cable into the mini-hub's cascade port.
Connect a network cable from the mini-hub to your analyzer.
Connect a network cable from the mini-hub to the target station.
This has the effect of creating a shared segment on the switch port, and you can now listen in.
Figure 21.13 You can roll your own wiretap for a switch port simply by getting a "mini-hub" and creating a segment between the switch and the end station.
Here's the bad part: If you are doing a lot of analysis, you might be tempted to leave the hub in place where it might be most useful—as in the uplink between your user switches and your server switches. But, if your $50 hub fails, your $50,000 worth of servers are all of a sudden unavailable. For uses like this, you probably want to get something called a "passive tap." (Finisar, at http://www.finisar.com, makes good ones.) Because of its passive nature, even if it fails, the link between devices stays up, as opposed to a hub.
Here's the bottom line: Any type of ongoing probe (such as those required for statistical analysis) should be passive, not hub-based.