Traceroute ain’t tracert

After ping, trace route is probably one of the most common network tools. Be it for fault finding, verification, discovery or testing. Between ping and trace route you can do a lot. Trace route, at it’s most basic sends a series of packets with an ever increasing Time to Live (TTL), starting at TTL=1. Every layer 3 device in the path will decrement this TTL and send a TTL Expired back towards the source if the TTL hits 0, until eventually the packet has a TTL that is long enough that it will reach the end device. The series of returned TTL Expired packets will tell you the path that the packet took.

Continue reading

All of the Pings!

Ping is one of the most recognised network troubleshooting tools. It is used without thought and is considered so basic that to post about it seems pointless, however, pings aren’t pings!

Ping started as a small utility written by Mike Muuss who was working at the Ballistic Research Laboratory and needed a quick and easy way to troubleshoot the state of the network. Given the tools usefulness it has since been ported to many platforms.

Ping uses the Internet Control Message Protocol (ICMP) to send ICMP Echo Requests to the target host and listen for ICMP Echo Replies. If you want to learn more about ICMP, check out RFC 792

Ping is useful for the following reasons:

  • It can assist in detecting network reachability of a host (However it can be confusing if there are return path issues .. )
  • It is useful as a “yard stick” for network performance by looking at the Round Trip Time (RTT) (Latency), the degree that the RTT changes (i.e. Jitter) and the rate of packet drops (if any)
  • To discover devices on a network (nmap –sP –PN!)
  • To discover any MTU limitations and network performance issues that can result

Continue reading

Bruce’s thoughts on Fault Finding

Fault finding is an incredibly subjective topic, I can’t think of the perfect fault finding process but there are a number of hints and best practices that a network engineer will pick up over time. From my recent TSHOOT studies, Cisco defines the fault finding process as:

  • Define the Problem
  • Gather Information
  • Analyse Information
  • Eliminate Possible Problem Causes
  • Formulate a Hypothesis
  • Test Hypothesis
  • Solve the Problem

This is a good position to start discussing my thoughts about fault finding issues in a network.

Continue reading