LDP/LDP/guide/docbook/linux-ip/trouble.xml

65 lines
1.9 KiB
XML

<!-- $Id$ -->
<chapter id="ch-trouble">
<title>Troubleshooting</title>
<para>
Invariably, troubles and misconfigurations creep into networks. New
devices get connected and added to a network. Old devices are removed,
and something seemingly unrelated breaks. Troubleshooting is really a
test in discerning patterns.
</para>
<para>
My favored method for solving problems is to start with the simplest
elements, verifying correct operation and proceeding to the next layer or
element until I have isolated the problem element. If you are lucky,
you'll know from a symptom where the problem is likely to be, but more
often, you'll have to start at the bottom of the networking hierarchy, and
verify each other layer.
</para>
<section id="trouble-intro">
<title>Introduction to Troubleshooting</title>
<para>
The first thing to consider whenever somebody reports a strange
networking problem is any recent change. What has changed recently in
the network? Have any new machines been added? Is the user using a
service which was recently decommissioned? Did a machine (firewall,
mail server, DNS resolver) recently reboot? Did all of the services
restart?
</para>
<para>
</para>
<para>
</para>
<para>
</para>
<para>
</para>
</section>
<section id="trouble-ethernet">
<title>Troubleshooting at the Ethernet Layer</title>
<para>
</para>
</section>
<section id="trouble-ip">
<title>Troubleshooting at the IP Layer</title>
<para>
</para>
</section>
<section id="trouble-routing">
<title>Handling and Diagnosing Routing Problems</title>
<para>
</para>
</section>
<section id="trouble-tcp">
<title>Identifying Problems with TCP Sessions</title>
<para>
</para>
</section>
<section id="trouble-dns">
<title>DNS Troubleshooting</title>
<para>
</para>
</section>
</chapter>