Part-1
When a host is unreachable, you can perform the troubleshooting steps discussed earlier until the host is reachable again.
But what if the network is slow? Let’s list out the issues.
DNS Issues
When DNS does has an issue, it can often result in poor network performance. For example, if there are two DNS servers configured for a domain and the first one goes down then the DNS requests will wait for 30 seconds before they time out and go to the secondary DNS server.
Although this will definitely be noticeable when we run tools like dig or nslookup, DNS issues can cause apparent network slowdowns in some unexpected ways. This is because so many services rely on DNS to resolve hostnames to IP addresses.
Tracking down the Network Slowdowns with Traceroute
When your network connection seems slow between your server and a host on a different network, sometimes it can be difficult to track down where the real slowdown is. Especially in situations where the slowdown is in latency (the time it takes to get a response) and not overall bandwidth, it’s a situation where the traceroute was made of.
traceroute as a way to test overall connectivity between us and the server on a remote network, but traceroute is also useful when we need to diagnose where a network slowdown might be. Since traceroute outputs the reply times for every hop between us and another machine, we can trace down servers that might be on a different continent or gateways that might be overloaded and causing network slowdowns.
What’s up with the bandwidth?
Using iftop command!
Sometimes network is slow but not because of the problems on the remote server or router, but just because something on the system is using up all the available bandwidth.
This problem can be identified about what the process is using up all the bandwidth, but there are some tools you can use to help identify the flaws on it.
top is such a great troubleshooting tool that it has inspired number of similar tools like iotop to identify what processes are consuming the most disk I/O. It turns out there is a tool called iftop that does something similar with network connections.
Unlike top, iftop doesn’t concern itself with processes but instead lists the connections between server and the remote IP that are consuming the most bandwidth. For instance, with iftop command we can quickly see if our backup job is using up all our bandwidth by seeing the backup server IP address at the top of the output.
Normally iftop displays overall bandwidth used between hosts, but to help you narrow things down, you might want to see what ports each host is using to communicate. After all, if we knew the host was consuming most of our bandwidth over our web port, we would be performing different troubleshooting than if it was connecting to an FTP port.
Packet captures
As we know the troubleshooting wide range of networking problems, some problems are so subtle or low-level that the only way to track them down is to dig down into the protocol itself and examine individual packets as they go back and forth.
Because of the low-level and tedious nature of analysing the packet dumps, we should try to use it as a last resort. This means the type of troubleshooting can be quite effective, particularly to identify hosts on the local network that are misbehaving, hosts with misconfigured network settings, or debugging communications between own client and server software.
Packet dumps are less effective for troubleshooting if the the protocols examined creates errors, or if we allow ourself to get buried in volumes of packets and can’t see the problem for all of the normal traffic.
Using TCP Dump
The main packet capture tool we will discuss here is tcpdump. This is an important and proven command-line packet capture tool, and although there are more modern tools out there, tcpdump is a program that we should be able to find on any Linux system.
Because of how tcpdump works, we will need to run it with root privileges on our machine. By default, it will scan through your network interfaces and choose the first suitable one, then it will capture, parse, and output information about the packets it sees.
