Tools for configuring and troubleshooting network connectivity

Names to Numbers and Back

The Address Resolution Protocol (ARP) converts a host's IP address to the hardware address or MAC address permanently assigned to your network adapter at the factory. Historically, the ARP tables were read and managed by the arp command. You might not often need to touch arp, but it's handy to have the option of monitoring and managing the way your system handles address resolution. Note that you only have ARP information about "neighbor" hosts on your network. If you have a private network, you can use arp and get something like Figure 4.

Figure 4: The arp command maps IP addresses to hardware addresses.

If you haven't pinged or interacted with the host previously, you won't have anything in the cache, so you can have two machines sitting next to one another on the network that have no ARP cache entries for their neighbors. If you ping the machine, you'll be able to get the ARP entry, which will include the MAC address under the HWaddress column. Not surprisingly, the ip command provides a replacement. The object, in this case, is neigh for "neighbor." (See the "Shorthand" box for more information.)


One interesting and useful aspect of the ip command is that, when specifying an object, you do not need to type the entire object name. Several of the objects described in this article are abbreviations for the actual objects; for example, address is the object and addr is just an abbreviation, neigh is an abbreviation for neighbor, and so forth.

The command ip l will show you the configured links just as ip link would. Note, however, that in a couple of cases multiple objects start with the same letter – for example, address and addrlabel. If you input just ip a, you are shown the addresses rather than the address labels. In general, the more common objects are recognized first. Also, you can use abbreviations for commands as well as objects.

The arp output for a specific host might look something like ether 00:80:77:b8:1f:f6 C eth0

where the output from ip neigh would look like: dev eth0 lladdr 00:80:77:b8:1f:f6 REACHABLE

Both commands output the IP address (, the Link Layer address (lladdr 00:80:77:b8:1f:f6), and the physical device (eth0) that connects to this address.


Once you have finished configuring the network, you might need to check to ensure that packets can reach remote hosts. The ping command verifies that the networking system can successfully support communication with another computer on the network. You can specify either the hostname or the IP address:


The output shows a report for each packet in an unending list that includes information on whether the attempt was successful, along with response times. Although this continuous output can be useful for testing purposes, it is easily ended with Ctrl+C. To limit the number of packets, use the -c (count) option.

You might want to ping using a specific interface to try to troubleshoot networking problems. For example, if you have a server with two or more interfaces, you can specify the eth1 interface to use with ping -I eth1 (replace eth1 with the name of the interface you'd like to use).

The ping command also allows you to set the interval between packets. The default is 1 second for each packet, or to send as fast as the system can with the -f (flood) option.

Note that only root can use the flood option. To specify the interval, use ping -i NN where NN is the interval. This can be a fraction of a second, so if you want to send a ping every half second, use:

ping -i 0.5

Another option, short of using flood, is to preload the number of packets to be sent. This option will send a predetermined number of packets without waiting for a response. To send more than three, you'll need to use sudo or be root. The preload option is specified with -l, like so:

ping -l <NN>

Replace NN with the number of packets that you'd like to send.

Finally, you might want to change the Time To Live (TTL) option using the -t option. TTL is the maximum number of routers that a packet can travel before being thrown away.

Admins sometimes need to check the route a packet takes to its destination. Just because you can't reach a site doesn't mean the problem is on your network or the destination network – sometimes the problem is somewhere in between.

For example, say you can't reach for some reason. It could be that is down, or that you have a networking issue on your side. Or, the problem might lie between your network and's network, and one way to figure this out is by using utilities to trace the path that packets are taking.

The traceroute command and the newer tracepath utility provide this information. tracepath is part of the iputils package that also includes ping. Although traceroute is the older utility, it has many more options than tracepath. Essentially, the only thing you can pass to tracepath is a destination port number. On the other hand, traceroute allows you to specify time-to-live values, maximum hops, a specific interface to use, and many other options.

The basic syntax is simple enough: Use traceroute host and you'll see a listing of the hosts between your computer (or the system you are running traceroute on) and the final destination. Because you're using traceroute to check for overall latency and problems, if a host returns * * * but the packets are reaching their destination, this is OK.

The maximum TTL (number of hops) is usually set to 30. You might have more than 30 hops between yourself and the final host. To change this, use the -m option, like so:

traceroute -m 35

This line would increase the number of hops to 35. Adjust as necessary.

Again, you might need to use traceroute to debug specific interfaces on a machine. To do this, you can use -i (interface), -s (source address), or both options.

A machine could have two or more IP addresses without actually having more than one interface, or each interface might have its own address. Therefore, if you want to specify an IP address on a system's second Ethernet interface, use:

traceroute -i eth1 -s

Naturally, you'll want to replace the IP address with the appropriate address. If the path of the packets is inefficient or unexpected, route or ip route will show you what routes are configured. Note that you only see the route configured from the local machine; it is very possible the problem might lie elsewhere.

For example, a given router might be explicitly configured not to provide any details. In that case, tracepath might report "no reply." This situation does not mean you cannot connect to the target (which you can verify with ping); it simply means the intermediate router is not responding to the request from tracepath (or traceroute).

The tracepath documentation specifies that it is not a "privileged program" and can be executed by anyone. Although this is true, I have never had any trouble running traceroute as a normal user, except that it is usually not in a normal user search path.

Other troubleshooting utilities include the netstat command (which outputs information on connections, routing tables, and interface statistics) or the newer ss utilities. Although ss is part of the iproute package, its syntax is different from ip. See the ss man page for more information.

Buy this article as PDF

Express-Checkout as PDF

Pages: 6

Price $2.95
(incl. VAT)

Buy Raspberry Pi Geek

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content