Network Tools in Linux

Motivation

We have learned the basics of how a network works. Now lets look at more tools that help you debug and troubleshoot network issues.

DNS Lookup

When you go to a website you do not need to remember the IP address. You use a name for that. e.g. you go to www.google.com. In order to find the associated IP address you need to lookup that name. The tools for that are: host nslookup or dig. For simple lookups I prefer host, while the other tools will give you more detailed information of how the lookup worked.

 host www.google.com
www.google.com has address 172.217.16.196
www.google.com has IPv6 address 2a00:1450:4001:817::2004

Sometimes you want to define aliases for certain hosts. Especially in your private network at home you will not want to run your own DNS system. A simple file that relates IP addresses to names will be sufficient to make your life easiser. This is the /etc/hosts file where you can add names to your IP addresses. E.g. your hosts file could look like this:

$ cat /etc/hosts
127.0.0.1	localhost
::1     localhost ip6-localhost ip6-loopback

192.168.19.27 laptop1 acer
192.168.19.101 handy lg200
192.168.19.1 netgear

In this example we have defined 3 names in the 192.168.19.0/24 network. You can add alias names after the first name. It is also good to have the name of your own computer defined. Also the loopback interface should be named localhost. In the above example we also name the IPv6 address (::1) to be localhost.

ping

Ping is a tool that sends out a special packet (ICMP Echo) to another station and receives the answer from the other side. This is useful to see if the other station is alive or if the network connection to the other side is working. Of course the other side could choose to not answer the packet or there could be a firewall in between us and the remote side that filter either request packet or the response.

Ping comes from sonar, where a short sound is sent out (a Ping) and the echo is used to find out if there is an object ahead and how far it is away. The network ping also measures the time that it takes for the response.

You can tell the ping tool how many packets it sends, in which interval and what the size of the packets should be. On Linux the default number of packets is infinity. So you need to interrupt the tool by pressing Ctrl-C.

$ ping www.google.com
PING www.google.com (172.217.16.196) 56(84) bytes of data.
64 bytes from fra16s08-in-f196.1e100.net (172.217.16.196): icmp_seq=1 ttl=53 time=16.7 ms
64 bytes from fra16s08-in-f196.1e100.net (172.217.16.196): icmp_seq=2 ttl=53 time=14.3 ms
64 bytes from fra16s08-in-f196.1e100.net (172.217.16.196): icmp_seq=3 ttl=53 time=14.4 ms
^C
--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 14.304/15.130/16.672/1.091 ms

What we see above: We sent 3 packets to a google server and got 3 responses. The packets are numberd with a sequence id, so we would know if there are packets missing in between or if the packets arrived in different order. We also see the time in milliseconds for the round trip. Here about 14ms.

Here the ping also does a reverse lookup on the IP address. This can be avoided with the -n switch of ping. This should be used of you are cutoff from the network, since then the reverse lookup will not work but you want to use the ping tool to troubleshoot anyways.

Then there is the ttl value: Each time a package is forwarded from one network segment to the next the ttl counter of a package is decreased by one. The packages is sent with an initial value and if it ever gets to zero, then the package is thrown away (and the sender is notified that its packet is thrown away). Most of the time either 64 or 255 is used as a start value. In our case it was most likely 64 that was used by google in its return package. From this we can infer that the distance, measured in the number of networks in between, is abut 12 hops.

If there is package loss then the quality of the transmission is bad. On a TCP/IP Connection a station is supposed to lower its transmission rate when it encounters packet loss on a transmission the speed of a connection will rapidly drop. For details see: https://en.wikipedia.org/wiki/TCP_congestion_control

The reason for the drop of packages could be some transmission errors, e.g. on a wireless connection, or, most often, if the bandwidth of a link in between is saturated, the router has to drop packages.