As you've seen, computer networking can be an incredibly complicated business. There are so many layers, protocols, and devices at play, and sometimes this means that things just don't work properly. No surprise there. Many of the protocols and devices we've covered have built in functionalities to help protect against some of these issues. These functionalities are known as error detection and error recovery. Error detection is the ability for a protocol or program to determine that something went wrong. Error recovery is the ability for a protocol or program to attempt to fix it. For example, you might remember that cyclical redundancy checks are used by multiple layers to make sure that the correct data was received by the receiving end. If a CRC value doesn't match the data payload, the data is discarded. At that point, the transport layer will decide if the data needs to be reset. But even with all of these safeguards in place, errors still pop up. Misconfigurations occur, hardware breaks down, and system incompatibilities it comes to light.
When network problems come up the most common issue you'll run into is the inability to establish a connection with something. It could be a server you can't reach at all or a website that isn't loading. Maybe you can only reach your resource on your LAN and can't connect to anything on the Internet. Whatever the problem is, being able to diagnose connectivity issues is an important part of network troubleshooting. When a network error occurs the device that detects it needs some way to communicate this to the source of the problematic traffic. It could be that a router doesn't know how to route to a destination, or that a certain port isn't reachable. It could even be that the TTL of an IP datagram expired and no further router hops will be attempted. For all of these situations an more ICMP or Internet control message protocol is used to communicate these issues. ICMP is mainly used by a router or remote host to communicate why a transmission has failed back to the origin of the transmission.
The makeup of an ICMP packet is pretty simple, it has a header with a few fields and a data section that's used by the host to figure out which of their transmissions generated the error.
The first field is the type field 8 bits along which specifies what type of message is being delivered. Some examples are destination unreachable, or time exceeded. Immediately after this is the code field which indicates a more specific reason for the message than just the type, for example of the destination unreachable type there are individual codes for things like destination network unreachable, and destination port unreachable. After this is a 16-bit checksum that works like every other checksum field we've covered so far. Next up is a 32-bit field with an uninspired name, rest of header. You think they could come up with something a bit more interesting. Anyway, this field is optionally used by some of the specific types and codes to send more data. After this is the data payload for an ICMP packet. The payload for an ICMP packet exists entirely so that the recipient of the message knows which of their transmissions cause the error being reported. It contains the entire IP header and the first 8 bytes of the data payload section of the offending packet. ICMP wasn't really developed for humans to interact with. The point is so that these sorts of error messages can be delivered between networked computers automatically. But there's also a specific tool and two message types that are very useful to human operators. This tool is called ping. Some version of it exists on just about every operating system and has for a very long time. Ping is a super simple program and the basics are the same no matter which operating system you're using. Ping let's you send a special type of ICMP message called an echo request. An ICMP echo request essentially just asks a destination - "Hey are you there?". If the destination is up and running and able to communicate on the network, it will send back an ICMP echo reply message type.
You can invoke the Ping Command from the command line of any modern operating system. In its most basic use you just typing and a destination IP or a fully qualified domain name.
Output of the Ping Command is very similar across each of the different operating systems. Every line of output will generally display the adverse sending the ICMP Echo reply, and how long it took for the round trip communications. It will also have the TTL remaining and how large the ICMP message is in bytes. Once the command ends, there will also be some statistics displayed, like the percentage of packets transmitted and received, the average round trip time, and a couple of other things like that. On Linux and Mac OS, the Ping Command will run until it's interrupted by an end-user sending an interrupt event. They do this by pressing the control key and the C key at the same time. On Windows, Ping defaults to only sending 4 echo requests. In all environments PING supports a number of command line flags that let you change its behavior like the number of echo request to send, how large they should be, and how quickly they should be sent.
With ping, you now have a way to determine if you can reach a certain computer from another one. You can also understand the general quality of the connection.
But communications across networks, especially across the Internet usually, cross lots of intermediary nodes. Sometimes, you need a way to determine where in the long chain of router hops the problems actually are. Traceroute to the rescue. Traceroute is an awesome utility that lets you discover the paths between two nodes, and gives you information about each hop along the way. The way traceroute works, is through a clever manipulation technique of the TTL field at the IP level. We learned earlier that the TTL field is decremented by one, by every router that forwards the packet. When the TTL field reaches zero, the packet is discarded and an ICMP Time Exceeded message is sent back to the originating host.
Traceroute uses the TTL field by first setting it to one for the first packet, then two for the second, three for the third and so on. By doing this clever little action, traceroute makes sure that the very first packet sent will be discarded by the first router hop. This results in an ICMP Time Exceeded message, the second packet will make it to the second router, the third will make it to the third, and so on. This continues until the packet finally makes it all the way to its destination. For each hop, traceroute will send three identical packets.
Just like with ping, the output of a traceroute command is pretty simple. On each line, you'll see the number of the hop and the round trip time for all three packets. You will also see the IP of the device at each hop, and a hostname if traceroute can resolve one. On Linux and macOS, traceroute sends UDP packets to very high port numbers. On Windows, the command has a shortened name tracert and defaults to using ICMP echo request. On all platforms, traceroute has more options than can be specified using command line flags. Two more tools that are similar to traceroute are mtr on Linux and macOS and pathping on Windows. These two tools act as long-running traceroutes. So you can better see how things change over a period of time. Mtr works in real-time and will continually update its output with all the current aggregate data about the traceroute. You can compare this with pathping, which runs for 50 seconds and then displays the final aggregate data all at once.