renamed dirs dg-src and ug-src to match output dirnames
[obnox/wireshark/wip.git] / docbook / eug_src / EUG_chapter_troubleshoot.xml
diff --git a/docbook/eug_src/EUG_chapter_troubleshoot.xml b/docbook/eug_src/EUG_chapter_troubleshoot.xml
new file mode 100644 (file)
index 0000000..b0afb9b
--- /dev/null
@@ -0,0 +1,129 @@
+<!-- EUG Chapter Four -->
+<!-- $Id$ -->
+
+<chapter id="Chap04">
+  <title>Troubleshooting with <application>Ethereal</application></title>
+  <section>
+    <title>An approach to troubleshooting with Ethereal</title>
+    <para>
+      Ethereal 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 networkfor 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 Ethereal can read many capture file formats, you can 
+           capture using any conventient 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 Ethereal and look for your 
+           problem. Using Ethereal'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 spreaded 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 spreaded 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 (broadcast's). 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 Ethereal 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 EUG Chapter 4 -->
+