130 lines
4.9 KiB
XML
130 lines
4.9 KiB
XML
<!-- WSUG Chapter Four -->
|
|
<!-- $Id$ -->
|
|
|
|
<chapter id="Chap04">
|
|
<title>Troubleshooting with <application>Wireshark</application></title>
|
|
<section>
|
|
<title>An approach to troubleshooting with Wireshark</title>
|
|
<para>
|
|
Wireshark is a very useful tool for network troubleshooting, since it
|
|
contains a number of features that allow you to quickly focus on
|
|
problems in your network for several reasons:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
It allows you to focus in on specific packets and protocols,
|
|
as you can see a large amount of detail associated with
|
|
various protocols.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
It supports a large number of protocols, and the list of
|
|
protocols supported is growing as more people contribute
|
|
dissectors
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
By giving you a visual view of traffic in parts of your
|
|
network, and providing tools to filter and colorize that
|
|
information, you can get a better feel for your network
|
|
traffic, and can understand your network better.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
<para>
|
|
The following general approach is suggested:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Determine that the problem looks like a networking problem.
|
|
There is no point in capturing packets if the problem is not
|
|
networking related.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Figure out where to capture packets. You will have to
|
|
capture packets from a part of the network where you can
|
|
actually get network traffic related to the problem. This is
|
|
especially important in the presence of switches and routers.
|
|
See <xref linkend="Ch04ROUSWI"/> for more details.
|
|
</para>
|
|
<para>
|
|
Because Wireshark can read many capture file formats, you can
|
|
capture using any convenient tool. One useful approach is
|
|
to use <command>tcpdump</command> to capture on remote
|
|
systems and then copy the capture file to your system for
|
|
later analysis. For more details on capturing with
|
|
<command>tcpdump</command>, see <xref linkend="Ch05tcpdump"/>.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Once you have captured packets that you think relate to
|
|
the problem, load them into Wireshark and look for your
|
|
problem. Using Wireshark's filtering and colorization
|
|
capabilities, you can quickly narrow down the capture to the
|
|
area of interest.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Examine the appropriate fields within the packets where
|
|
the problem appears to be. These can often help to reveal
|
|
the problem.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</section>
|
|
<section id="Ch04ROUSWI">
|
|
<title>Capturing in the presence of switches and routers</title>
|
|
<para>
|
|
In the old days of Ethernet, all network traffic was spread over one
|
|
"yellow" cable through the whole network. Capturing data was easy,
|
|
as all packets from the network could be captured using the
|
|
"promiscuous mode" at any place in the network. The only devices blocking
|
|
network traffic, were routers. But as routers were extremely expensive,
|
|
they were not widely used.
|
|
</para>
|
|
<para>
|
|
Then Ethernet wiring using hubs become the state of the art. As the hubs
|
|
still spaded the packets all over the network, things regarding
|
|
capturing didn't changed.
|
|
</para>
|
|
<para>
|
|
At the next stage, Ethernet switches became widely available. This
|
|
complicated things a lot. When capturing traffic on a computer connected
|
|
to a switch, usually the switch will only forward packets to the computer,
|
|
which are directed to it, or to all computers (broadcasts). It's much the
|
|
same like deactivating the promiscuous mode of the capturing network card.
|
|
</para>
|
|
<para>
|
|
There are some ways to circumvent this.
|
|
</para>
|
|
<para>
|
|
Many vendor's switches support a feature known as "port spanning"
|
|
or "port mirroring" in which all of the traffic to and from port A
|
|
are also sent out port B. An excellent reference on the
|
|
"port spanning" feature of Cisco switches can be found at
|
|
<ulink url="http://www.cisco.com/warp/public/473/41.html">
|
|
Configuring the Catalyst Switched Port Analyzer (SPAN) Feature
|
|
</ulink>
|
|
</para>
|
|
</section>
|
|
<section>
|
|
<title>Examples of troubleshooting</title>
|
|
<para>
|
|
Troubleshooting often requires a reasonable knowledge of the
|
|
protocols in question. However, as Wireshark will often give you some
|
|
good hints, you might get an idea of what is going wrong simply by
|
|
looking in the packets being exchanged.
|
|
</para>
|
|
</section>
|
|
</chapter>
|
|
<!-- End of WSUG Chapter 4 -->
|
|
|