Linux networking: Using ip tool instead of ifconfig

To best troubleshoot your Linux network, you'll need to make sure that all IP-related parameters on your network cards are set correctly. If you're using a Dynamic Host Configuration Protocol (DHCP) server, this has most likely been taken care of already. But if you are configuring a server, you have probably left your systems prone to errors by entering the IP information manually. To find out if the IP parameters on your server are set correctly, there are a few questions that you should answer:

• Are you using the right IP address?
• Are you in the right subnet mask?
• Are you sure you're using the right tool to monitor your IP configuration?
• Are you able to communicate with the default gateway?
• Can you reach the Domain Name System (DNS) server?

You many notice that these are all parameters you should set on your own computer. IP-related problems can have their origins outside of your network, as well. I won't deal with these cases, however, as a system administrator typically can't influence them.

Ip versus ifconfig
Many people still like to work with the ifconfig tool to monitor and configure their network. An alternative tool known as ip, however, has been around for a couple of years now. The good news is that there is some compatibility. The bad news is that the compatibility is not complete.

Information that you set using the ip tool won't show up when you monitor your system using ifconfig. While that may seem irrelevant, it isn't, as most of the system tools used on the different Linux distributions rely internally upon the ip tool. That means that you will miss part of the configuration that you've set when using ifconfig for monitoring.

Let's have a look at an example. Use the following command to add a random IP address to your eth0 network card:

ip address add dev eth0 10.100.100.1/24

Now use the ifconfig command to have a look at the configuration of your network card. As you can see in Listing 1 below, the address you've just added doesn't seem to be there.

Listing 1: IP address information set with ip doesn't always show in ifconfig:

uppernavik:/ # ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:15:C5:81:7B:46 inet addr:192.168.1.24 Bcast:0.0.0.0 Mask:255.255.255.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:17

The reason for this isn't hard to understand: ip writes secondary IP address configurations to a different location than ifconfig. Always use ip to find out details about your ip address configuration.

Even if ip is currently the only tool to monitor IP address settings, there are things that ifconfig handles better. An example, for instance, is monitoring the amount of traffic on a network interface, including statistics about packets that have failed. When traveling, I like to monitor the amount of traffic that is sent over my ppp0 interface, which is used to connect to 3G networks. As 3G connections abroad can be expensive, it is worthwhile to monitor the amount of traffic that is being transmitted, and the ifconfig command provides excellent details on this topic.

Once you have used ip to verify that your network connection is using the correct address information, it's time to verify the connection to external networks. To connect to other networks, your computer needs a router. Normally, all computers have a default router setting: an IP address on the same network of the router that allows you to connect to other networks. It is common, but not mandatory, that the last IP address in the range is used for this purpose.

There are two commands to show information about your current routing: the route command and the ip route command. In Listing 2, you can see the output of both of these commands.

Listing 2: You can use route or ip route to show routing information

uppernavik:/ # ip route show 192.168.150.0/24 dev vmnet1 proto kernel scope link src 192.168.150.1 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.24 172.16.186.0/24 dev vmnet8 proto kernel scope link src 172.16.186.1 10.100.100.0/24 dev eth0 proto kernel scope link src 10.100.100.1 uppernavik:/ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 172.16.186.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8 10.100.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

These commands contain information that includes a list of known networks, the IP address of the router that is used to get there and the name of the interface that connects to this computer. The IP address of the router to get to the target network may very well be a local IP address (which is the case in the commands from Listing 2).

As you can see in the example in Listing 2, there is no major difference between the information returned by the route command and the ip route command. You may also notice that some vital information is missing: This computer does not have a default router. That means that this computer is incapable of connecting to external networks.

If a default router hasn't been added automatically, you can use the ip route add command. If, for instance, you want to add a default router with the ip address 10.0.0.254, you can use the following command:

ip route add default via 10.0.0.254

From this moment on, you'll be able to connect to computers on other networks.

The last step in connecting to the rest of the world is name resolving, provided you don't want to connect to other computers by using IP addresses only. If you want to use meaningful names to connect to other computers, such as www.example.com, you'll need DNS.

Typically, you'll use the DNS server that has been installed by your Internet provider for this purpose. You'll have to tell your computer where it can find your favorite DNS server. To do this, find out which is the address of the nameserver you need and add a line like the following to the configuration file /etc/resolv.conf:

nameserver 10.0.0.254

After following these steps, you should be connected. To verify this, you can use ping. The best method is to ping by DNS name, but make sure that you are pinging a server configured to reply to DNS, as not all servers do.

ABOUT THE AUTHOR: Sander van Vugt is an author and independent technical trainer, specializing in Linux since 1994. Vugt is also a technical consultant for high-availability (HA) clustering and performance optimization, as well as an expert on SLED 10 administration.