Cisco Knowledge Suite Cisco SystemsCisco Press
   

   
Home
MyCKS
Cutting Edge
Certification
Core Reference
Guided Learning
   
Networking Architecture
LAN
WAN
Switching
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services
 

Troubleshooting Common TCP/IP Problems

   

< Back Contents Next >

Troubleshooting Common TCP/IP Problems

  

14.1. -

Analyzers and Sniffers

  

14.2. -

Software Tools to Help You Solve Problems

  

14.3. -

Windows NT Network Monitor

  

14.4. -

Common Problems

  

14.5. -

Analyzing Packet Dumps and Examples of Common Sequences

  

14.6. -

Summary

Save to MyCKS

 
TCP/IP Blueprints

From: TCP/IP Blueprints
Author: Martin Bligh
Publisher: Sams
More Information

14. Troubleshooting Common TCP/IP Problems

by Mark Vevers

We have spent so much time in this book describing how all the different protocols work. Some people may be curious to know what's going on “under the hood,” but do you really need to know? Not until something goes wrong. It's all very well to follow the instructions to “point and click,” but what if it doesn't work?

This chapter tells you how to find out what is really happening on your network. Refer to the earlier chapters on IP protocols to find out what's supposed to behappening. Compare the two, and (theoretically) you have your problem. In practice, it can be a bit more difficult than that.

Debugging networks is both an art and a science. Some things only can be picked up through experience, but a logical approach will solve most problems. First, here are a few general principles:

  • The error you're seeing is the symptom of the problem. You need to find the cause. They can be a long way apart, and it's often not obvious. Multiple problems that initially appear unrelated often turn out to be caused by the same problem.

  • Don't make assumptions or go too far down one path without stepping back to consider the whole picture. Often the problem will turn out to be the most obvious thing.

  • When did it break? If it worked fine Monday but not Wednesday, what did you change between then? This is not infallible. Things sometimes break for no discernible reason.

  • Try to find a way to reliably re-create the problem. If it's intermittent, it will be much more difficult to diagnose.

  • If the problem is intermittent, is there a pattern to when it occurs? When did it start? Does it happen at one particular time of the day, when a certain job is running, or when the network or host is busy?

  • Are there error messages in the logs? Seemingly unrelated messages can solve the problem—for example, DNS errors causing backups to fail.

  • Is there a pattern of which machine it occurs on? Network diagrams are useful here.

  • Does the problem happen only when going to/from a particular machine? Is there another working machine with which you can compare configurations?

  • By all means, take a few guesses about what's going wrong. If they're not right, it comes to a point when you'll just have to work through it methodically—what's meant to be happening step by step. Check it off against what is actually happening.

  • Keep breaking the problem down. Try to replicate the error in a simpler way. If a complex mailing program is producing errors, try sending a mail message to the remote site invoking sendmail by hand. If that doesn't work, try to telnet to the remote machine's SMTP port. If that doesn't work, try pinging the remote machine. If that doesn't work, try pinging your default gateway and every router along the path to the remote host (or use traceroute).

  • If there's a chain of commands being executed, look at the output of each command. For example, try changing “foo | bar” to “foo | tee log | bar”. This will take a copy of the pipe's contents into a file called log.

14.1. Analyzers and Sniffers

At the most basic level, analyzers and sniffers are tools for looking at the packets flying around your network (often referred to as “taking a trace”). Some will monitor any traffic going past on the network, while some are just for watching what's going in and out of the machine on which you are sitting.

In order to monitor the network, you can either use a dedicated device such as network sniffer, or you can use a PC with some suitable software to analyze the traffic. You can see an example of the use of such software in the section tcpdump.

Hardware solutions can cope with higher levels of traffic, but tend to be expensive. Software solutions tend to be fairly basic and unable to give full packet analysis, but are cheap and flexible (you can write scripts to interpret the output).

Looking at the packets going across the network is a brute force approach to solving a problem, but often it's the only way. It's not as bad as it sounds; the main problem is too much information, so you need to filter out exactly what you need.

Most good network analysis tools can filter by criteria, such as:

  • Source IP address

  • Destination IP address

  • Source Port

  • Destination Port

More sophisticated tools can interpret protocols for you, such as:

  • IP

  • TCP and UDP

  • Telnet, FTP, LPD, and so on

The data captured is usually available in a textual or ASCII format. This enables you to run your own processing scripts on it and then print or store the results. Some new WWW-based tools are emerging, which present the output as hypertext so you can more readily navigate and interpret the information.

   

< Back Contents Next >

Save to MyCKS

 

Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential Broadband, Second Edition
by George Abe

Introduces the topics surrounding high-speed networks to the home. It is written for anyone seeking a broad-based familiarity with the issues of residential broadband (RBB) including product developers, engineers, network designers, business people, professionals in legal and regulatory positions, and industry analysts.

             
     

From the Brains at InformIT

|

Contact Us

|

Copyright, Terms & Conditions

|

Privacy Policy

 

© Copyright 2000 InformIT. All rights reserved.