Network Troubleshooting with Oracle Linux

Introduction

When applications that use network connectivity for communication are not working, the cause is often a mystery. Despite advances in modern operating systems, many users believe there is no way to directly "see" what's going over the wire, and that often leads to confusion and difficulties when something goes wrong.

The reality is that you can actually see what's going over the wire, and there are a number of tools built into Oracle Linux for troubleshooting network issues. This article will help solve some of the mystery and make network connectivity a bit more user friendly.

Tools for Network Troubleshooting

The most basic test you can perform to determine network connectivity is the ping test. The ping application is a simple utility that sends an Internet Control Message Protocol (ICMP) packet to a remote host on your network to see whether you get a reply. ICMP is part of the TCP/IP stack.

In the example shown in Listing 1, we are going to ping the test2 system from the test1 system to see whether test2 responds on the network. The ping application will continue to run until you terminate it by pressing Ctrl-C.

In the output shown in Listing 1, you can see that test2 is responding. It was sent six ICMP packets and responded to all of them and had an average response time of 0.218ms.

The ping command can also be used to identify network latency issues. If one of the packets had an abnormally long reply time, that might be an indicator of some type of network congestion or issue.

Many networks are quite complicated, and packets move through many different layers of routing and switching equipment to reach the intended destination. The traceroute application can show us the path that packets are taking to reach their destination.

The example shown in Listing 2 uses traceroute to trace the path to a popular search engine from the demo cloud instance. The IP address of the cloud instance has been replaced with x.x.x.x in this example.

Both ping and traceroute are quite useful on their own, but in a lot of cases, they can provide only limited information based on a short duration of time. A very useful application for looking at network latency is mtr. (mtr stands for My Traceroute, although it originally stood for Matt's Traceroute because the application was written by Matt Kimball in 1997.)

The mtr application can provide real-time data about latency and routing changes for end users. Figure 1 shows an example of the output from the cloud instance to the same popular search engine used in the Listing 2.

Figure 1. Example of output from the mtr application

Have you ever had a situation in which you could contact a host but were not sure you were communicating with the correct host or using the correct IP address? The nmap utility is a very powerful tool for network scanning and diagnostics, and it can provide exactly that information.

In example shown in Listing 3, we are verifying that the ocfs2-2 node is actually the node we are looking for. You can verify you have the correct node by looking at its running services and its OS fingerprint. The nmap utility can identify a number of operating systems based on their fingerprints if the fingerprints are contained in the nmap database of known operating systems.

The example in Listing 3 is quite useful, but what if you did not have the correct host? That's no problem for nmap. You can scan the entire subnet and nmap will report back which hosts are responding on the network.

In the example shown in Listing 4, we are using nmap with the "scan and ping" option (-sP) to scan 256 IP addresses using a /24 subnet with the mask of 255.255.255.0. The output shows that we get a response back from three hosts that are up: 10.0.0.1, 10.0.0.2, and 10.0.0.3.

Once you know what hosts are available on your subnet, you can do an additional scan on the host that you want to explore further.

Firewalls are indispensable tools for securing systems, but they often pose a problem when you inadvertently block traffic you are not intending to block. To further complicate matters, sometimes you don't have full administrative rights to the systems that you are connecting to, so you can't verify the firewall settings and make any needed changes. Even with these challenges, there are ways of determining connectivity through a firewall by using simple tools.

One of the first tools that you can use is telnet. Let's say for example that you want to check whether port 7777 is open on another host. You can use telnet to do this, as shown in Listing 5, which indicates you were able to connect to remote host 10.0.0.3 on port 7777.

Listing 8. Example of netcat output when connection to a remote host fails

Conclusion

These are just some of the techniques you can use to troubleshoot issues you are experiencing on the network. There are many other tools available and many other techniques that work just as well, depending on the specific needs of the environment that you are working in.

See Also

About the Author

Robert Chase is a member of the Oracle Linux product management team. He has been involved with Linux and open source software since 1996. He has worked with systems as small as embedded devices and with large supercomputer-class hardware.