1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
<!-- 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 -->
|
