Verifying connectivity
Table of Contents
Ping: Internet Control Message Protocol
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.By the end of this lesson you'll be able to use a number of important troubleshooting tools to help resolve these issues.
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 and 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 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, but I can't really think of anything good so who am I to judge? 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 type ping and a destination IP or a fully qualified domain name. If you don't know how to use a command line in an operating system, don't worry you will soon we'll cover that in another course.
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 percentage of packets transmitted and received, the average round trip time, and a couple 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 4Echo 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. Check out the documentation for your operating system to learn a little bit more.
Traceroute
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 host name 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. Refers. 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.
Testing Port Connectivity
We've covered a bunch of ways to test connectivity between machines at the network layer. But sometimes, you need to know if things are working at the transport layer. For this, there are two super powerful tools at your disposal. Netcat on Linux and Mac OS and Test-NetConnection on Windows.
The Netcat tool can be run through the command nc, and has two mandatory arguments, a host and a port. Running nc google.com 80 would try to establish a connection on port 80 to google.com. If the connection fails, the command will exit. If it succeeds, you'll see a blinking cursor, waiting for more input.
This is a way for you to actually send application layered data to the listening service from your own keyboard. If you're really only curious about the status of a port, you can issue the command, with a -Z flag, which stands for Zero Input/Output Mode. A -V flag, which stands for Verbose, is also useful in this scenario. This makes the commands output useful to human eyes as opposed to non-verbose output, which is best for usage in scripts. Side note, verbose basically means talking too much. So, while I bet you want to throw up a flag on me and my jabbering, we still have lots to get through. Okay, so by issuing the Netcat command with the -Z and -V flags, the command's output will simply tell you if a connection to the port in question is possible or not.
On Windows, Test-NetConnection is a command with some of the similar functionality. If you run Test-NetConnection with only a host specified, it will default to using an ICMP echo request, much like the program ping. But, it will display way more data, including the data link layer protocol being used.
When you issue Test-NetConnection with the -port flag, you can ask it to test connectivity to a specific port. It's important to call out that both Netcat and Test-NetConnection are way more powerful than the brief port connectivity examples we've covered here. In fact, they're such complex tools that covering all of their functionality would be too much for one video. You should read up about all of the other things these super powerful tools can do. We've provided a few in the supplementary readings.
Supplemental Reading for Testing Port Connectivity
Sometimes, you need to know if network connectivity is working at the transport layer. For this, there are two super powerful tools at your disposal: Netcat (nc) on Linux and macOS, and Test-NetConnection on Windows.
The Netcat tool can be run through the command nc, and has two mandatory arguments, a host and a port. Running this command would try to establish a connection on port 80 to google.com:
If the connection fails, the command will exit. If it succeeds, you'll see a blinking cursor, waiting for more input. This is a way for you to actually send application layer data to the listening service from your own keyboard. If you're really only curious about the status of a report, you can issue the command, with a -z flag, which stands for zero input/output mode. A -v flag, which stands for verbose, is also useful in this scenario. So now, the command looks like this:
By issuing the netcat command with the -Z and -V flags, the command's output will simply tell you if a connection to the port in question is possible or not, like this:
On Windows, Test-NetConnection is a command with some similar functionality. If you run Test-NetConnection with only a host specified, it will default to using an ICMP echo request, much like the program ping. But, it will display way more data, including the data link layer protocol being used. When you issue Test-NetConnection with the -Port flag, you can ask it to test connectivity to a specific port. For example, this command tests a TCP connection to google.com:
Test-NetConnection will return output that looks something like this:
It's important to call out that both netcat and Test-NetConnection are way more powerful than the brief port connectivity examples we've covered here. In fact, they're such complex tools that covering all of their functionality would be too much for one video. You should read up about all of the other things these super powerful tools can do in the Wikipedia article for Netcat (nc), and in the documentation for Test-NetConnection.
Reference:
