After setting up your hardware as explained in Chapter 4, you have to make these devices known to the kernel networking software. A couple of commands are used to configure the network interfaces and initialize the routing table. These tasks are usually performed from the network initialization script each time you boot the system. The basic tools for this process are called ifconfig (where “if ” stands for interface) and route.
ifconfig is used to make an interface accessible to the kernel networking layer. This involves the assignment of an IP address and other parameters, and activation of the interface, also known as “bringing up” the interface. Being active here means that the kernel will send and receive IP datagrams through the interface. The simplest way to invoke it is with:
ifconfig interface ip-address |
This command assigns ip-address to interface and activates it. All other parameters are set to default values. For instance, the default network mask is derived from the network class of the IP address, such as 255.255.0.0 for a class B address. ifconfig is described in detail in the section Section 5.8.”
route allows you to add or remove routes from the kernel routing table. It can be invoked as:
route [add|del] [-net|-host] target [if] |
The add and del arguments determine
whether to add or delete the route to
target. The -net and
-host arguments tell the route command whether the
target is a network or a host (a host is assumed if you don't
specify). The if argument is again optional, and
allows you to specify to which network interface the route should be
directed—the Linux kernel makes a sensible guess if you don't
supply this information. This topic will be explained in more detail
in succeeding sections.
The very first interface to be activated is the loopback interface:
# ifconfig lo 127.0.0.1 |
Occasionally, you will see the dummy hostname localhost being used instead of the IP address. ifconfig will look up the name in the hosts file, where an entry should declare it as the hostname for 127.0.0.1:
# Sample /etc/hosts entry for localhost localhost 127.0.0.1 |
To view the configuration of an interface, you invoke ifconfig, giving it only the interface name as argument:
$ ifconfig lo
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 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 |
As you can see, the loopback interface has been assigned a netmask of 255.0.0.0, since 127.0.0.1 is a class A address.
Now you can almost start playing with your mini-network. What is still missing is an entry in the routing table that tells IP that it may use this interface as a route to destination 127.0.0.1. This is accomplished by using:
# route add 127.0.0.1 |
Again, you can use localhost instead of the IP address, provided you've entered it into your /etc/hosts.
Next, you should check that everything works fine, for example by using ping. ping is the networking equivalent of a sonar device.[1] The command is used to verify that a given address is actually reachable, and to measure the delay that occurs when sending a datagram to it and back again. The time required for this process is often referred to as the “round-trip time”:
# ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.4 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.4 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.4 ms ^C --- localhost ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.4/0.4/0.4 ms # |
When you invoke ping as shown here, it will continue emitting packets forever, unless interrupted by the user. The ^C marks the place where we pressed Ctrl-C.
The previous example shows that packets for 127.0.0.1 are properly delivered and a reply is returned to ping almost instantaneously. This shows that you have successfully set up your first network interface.
If the output you get from ping does not resemble that shown in the previous example, you are in trouble. Check any errors if they indicate that some file hasn't been installed properly. Check that the ifconfig and route binaries you use are compatible with the kernel release you run, and above all, that the kernel has been compiled with networking enabled (you see this from the presence of the /proc/net directory). If you get an error message saying “Network unreachable,” you probably got the route command wrong. Make sure you use the same address you gave to ifconfig.
The steps previously described are enough to use networking applications on a standalone host. After adding the lines mentioned earlier to your network initialization script and making sure it will be executed at boot time, you may reboot your machine and try out various applications. For instance, telnet localhost should establish a telnet connection to your host, giving you a login: prompt.
However, the loopback interface is useful not only as an example in networking books, or as a test bed during development, but is actually used by some applications during normal operation.[2] Therefore, you always have to configure it, regardless of whether your machine is attached to a network or not.
Configuring an Ethernet interface is pretty much the same as the loopback interface; it just requires a few more parameters when you are using subnetting.
At the Virtual Brewery, we have subnetted the IP network, which was originally a class B network, into class C subnetworks. To make the interface recognize this, the ifconfig incantation would look like this:
# ifconfig eth0 vstout netmask 255.255.255.0 |
This command assigns the eth0 interface the IP address of vstout (172.16.1.2). If we omitted the netmask, ifconfig would deduce the netmask from the IP network class, which would result in an incorrect netmask of 255.255.0.0. Now a quick check shows:
# ifconfig eth0
eth0 Link encap 10Mps Ethernet HWaddr 00:00:C0:90:B3:42
inet addr 172.16.1.2 Bcast 172.16.1.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 1
RX packets 0 errors 0 dropped 0 overrun 0
TX packets 0 errors 0 dropped 0 overrun 0 |
You can see that ifconfig automatically sets the broadcast address (the Bcast field) to the usual value, which is the host's network number with all the host bits set. Also, the maximum transmission unit (the maximum size of IP datagrams the kernel will generate for this interface) has been set to the maximum size of Ethernet packets: 1,500 bytes. The defaults are usually what you will use, but all these values can be overidden if required, with special options that will be described under Section 5.8”.
Just as for the loopback interface, you now have to install a routing entry that informs the kernel about the network that can be reached through eth0. For the Virtual Brewery, you might invoke route as:
# route add -net 172.16.1.0 |
At first this looks a little like magic, because it's not really clear how route detects which interface to route through. However, the trick is rather simple: the kernel checks all interfaces that have been configured so far and compares the destination address (172.16.1.0 in this case) to the network part of the interface address (that is, the bitwise AND of the interface address and the netmask). The only interface that matches is eth0.
Now, what's that –net option for? This is used
because route can handle both routes to networks
and routes to single hosts (as you saw before with localhost). When given an address in
dotted quad notation, route attempts to guess
whether it is a network or a hostname by looking at the host part
bits. If the address's host part is zero, route
assumes it denotes a network; otherwise, route
takes it as a host address. Therefore, route would
think that 172.16.1.0 is a
host address rather than a network number, because it cannot know that
we use subnetting. We have to tell route explicitly
that it denotes a network, so we give it the
–net flag.
Of course, the route command is a little tedious to
type, and it's prone to spelling mistakes. A more convenient approach
is to use the network names we defined in
/etc/networks. This approach makes the command
much more readable; even the –net flag can be
omitted because route knows that 172.16.1.0 denotes a network:
# route add brew-net |
Now that you've finished the basic configuration steps, we want to make sure that your Ethernet interface is indeed running happily. Choose a host from your Ethernet, for instance vlager, and type:
# ping vlager PING vlager: 64 byte packets 64 bytes from 172.16.1.1: icmp_seq=0. time=11. ms 64 bytes from 172.16.1.1: icmp_seq=1. time=7. ms 64 bytes from 172.16.1.1: icmp_seq=2. time=12. ms 64 bytes from 172.16.1.1: icmp_seq=3. time=3. ms ^C ----vstout.vbrew.com PING Statistics---- 4 packets transmitted, 4 packets received, 0 round-trip (ms) min/avg/max = 3/8/12 |
If you don't see similar output, something is broken. If you encounter
unusual packet loss rates, this hints at a hardware problem, like bad
or missing terminators. If you don't receive any replies at all, you
should check the interface configuration with
netstat described later in Section 5.9”. The packet statistics displayed by
ifconfig should tell you whether any packets have
been sent out on the interface at all. If you have access to the
remote host too, you should go over to that machine and check the
interface statistics. This way you can determine exactly where the
packets got dropped. In addition, you should display the routing
information with route to see if both hosts have
the correct routing entry. route prints out the
complete kernel routing table when invoked without any arguments
(–n just makes it print addresses as dotted
quad instead of using the hostname):
# route -n Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.1 * 255.255.255.255 UH 1 0 112 lo 172.16.1.0 * 255.255.255.0 U 1 0 10 eth0 |
The detailed meaning of these fields is explained later in Section 5.9." The Flags column contains a list of flags set
for each interface. U is
always set for active interfaces, and H says the destination address denotes a
host. If the H flag is set for
a route that you meant to be a network route, you have to reissue the
route command with the –net
option. To check whether a route you have entered is used at all,
check to see if the Use field
in the second to last column increases between two invocations of
ping.
In the previous section, we covered only the case of setting up a host on a single Ethernet. Quite frequently, however, one encounters networks connected to one another by gateways. These gateways may simply link two or more Ethernets, but may also provide a link to the outside world, such as the Internet. In order to use a gateway, you have to provide additional routing information to the networking layer.
The Ethernets of the Virtual Brewery and the Virtual Winery are linked through such a gateway, namely the host vlager. Assuming that vlager has already been configured, we just have to add another entry to vstout's routing table that tells the kernel it can reach all hosts on the Winery's network through vlager. The appropriate incantation of route is shown below; the gw keyword tells it that the next argument denotes a gateway:
# route add wine-net gw vlager |
Of course, any host on the Winery network you wish to talk to must have a routing entry for the Brewery's network. Otherwise you would only be able to send data to the Winery network from the Brewery network, but the hosts on the Winery would be unable to reply.
This example describes only a gateway that switches packets between two isolated Ethernets. Now assume that vlager also has a connection to the Internet (say, through an additional SLIP link). Then we would want datagrams to any destination network other than the Brewery to be handed to vlager. This action can be accomplished by making it the default gateway for vstout:
# route add default gw vlager |
The network name default is a shorthand for 0.0.0.0, which denotes the default route. The default route matches every destination and will be used if there is no more specific route that matches. You do not have to add this name to /etc/networks because it is built into route.
If you see high packet loss rates when pinging a host behind one or more gateways, this may hint at a very congested network. Packet loss is not so much due to technical deficiencies as to temporary excess loads on forwarding hosts, which makes them delay or even drop incoming datagrams.
Configuring a machine to switch packets between two Ethernets is pretty straightforward. Assume we're back at vlager, which is equipped with two Ethernet cards, each connected to one of the two networks. All you have to do is configure both interfaces separately, giving them their respective IP addresses and matching routes, and that's it.
It is quite useful to add information on the two interfaces to the hosts file as shown in the following example, so we have handy names for them, too:
172.16.1.1 vlager.vbrew.com vlager vlager-if1 172.16.2.1 vlager-if2 |
The sequence of commands to set up the two interfaces is then:
# ifconfig eth0 vlager-if1 # route add brew-net # ifconfig eth1 vlager-if2 # route add wine-net |
If this sequence doesn't work, make sure your kernel has been compiled with support for IP forwarding enabled. One good way to do this is to ensure that the first number on the second line of /proc/net/snmp is set to 1.
A PLIP link used to connect two machines is a little different from an Ethernet. PLIP links are an example of what are called point-to-point links, meaning that there is a single host at each end of the link. Networks like Ethernet are called broadcast networks. Configuration of point-to-point links is different because unlike broadcast networks, point-to-point links don't support a network of their own.
PLIP provides very cheap and portable links between computers. As an example, we'll consider the laptop computer of an employee at the Virtual Brewery that is connected to vlager via PLIP. The laptop itself is called vlite and has only one parallel port. At boot time, this port will be registered as plip1. To activate the link, you have to configure the plip1 interface using the following commands:[3]
# ifconfig plip1 vlite pointopoint vlager # route add default gw vlager |
The first command configures the interface, telling the kernel that this is a point-to-point link, with the remote side having the address of vlager. The second installs the default route, using vlager as gateway. On vlager, a similar ifconfig command is necessary to activate the link (a route invocation is not needed):
# ifconfig plip1 vlager pointopoint vlite |
Note that the plip1 interface on vlager does not need a separate IP address, but may also be given the address 172.16.1.1. Point-to-point networks don't support a network directly, so the interfaces don't require an address on any supported network. The kernel uses the interface information in the routing table to avoid any possible confusion.[4]
Now we have configured routing from the laptop to the Brewery's network; what's still missing is a way to route from any of the Brewery's hosts to vlite. One particularly cumbersome way is to add a specific route to every host's routing table that names vlager as a gateway to vlite:
# route add vlite gw vlager |
Dynamic routing offers a much better option for temporary routes. You could use gated, a routing daemon, which you would have to install on each host in the network in order to distribute routing information dynamically. The easiest option, however, is to use proxy ARP (Address Resolution Protocol). With proxy ARP, vlager will respond to any ARP query for vlite by sending its own Ethernet address. All packets for vlite will wind up at vlager, which then forwards them to the laptop. We will come back to proxy ARP in the section Section 5.10.”
Current net-tools releases contain a tool called plipconfig, which allows you to set certain PLIP timing parameters. The IRQ to be used for the printer port can be set using the ifconfig command.
Although SLIP and PPP links are only simple point-to-point links like PLIP connections, there is much more to be said about them. Usually, establishing a SLIP connection involves dialing up a remote site through your modem and setting the serial line to SLIP mode. PPP is used in a similar fashion. We discuss SLIP and PPP in detail in Chapter 7 and Chapter 8.
The dummy interface is a little exotic, but rather useful nevertheless. Its main benefit is with standalone hosts and machines whose only IP network connection is a dialup link. In fact, the latter are standalone hosts most of the time, too.
The dilemma with standalone hosts is that they only have a single network device active, the loopback device, which is usually assigned the address 127.0.0.1. On some occasions, however, you must send data to the “official” IP address of the local host. For instance, consider the laptop vlite, which was disconnected from a network for the duration of this example. An application on vlite may now want to send data to another application on the same host. Looking up vlite in /etc/hosts yields an IP address of 172.16.1.65, so the application tries to send to this address. As the loopback interface is currently the only active interface on the machine, the kernel has no idea that 172.16.1.65 actually refers to itself ! Consequently, the kernel discards the datagram and returns an error to the application.
This is where the dummy device steps in. It solves the dilemma by simply serving as the alter ego of the loopback interface. In the case of vlite, you simply give it the address 172.16.1.65 and add a host route pointing to it. Every datagram for 172.16.1.65 is then delivered locally. The proper invocation is:[5]
# ifconfig dummy vlite # route add vlite |
New kernels support a feature that can completely replace the dummy interface and serve other useful functions. IP Alias allows you to configure multiple IP addresses onto a physical device. In the simplest case, you could replicate the function of the dummy interface by configuring the host address as an alias onto the loopback interface and completely avoid using the dummy interface. In more complex uses, you could configure your host to look like many different hosts, each with its own IP address. This configuration is sometimes called “Virtual Hosting,” although technically it is also used for a variety of other techniques.[6]
To configure an alias for an interface, you must first ensure that your kernel has been compiled with support for IP Alias (check that you have a /proc/net/ip_alias file; if not, you will have to recompile your kernel). Configuration of an IP alias is virtually identical to configuring a real network device; you use a special name to indicate it's an alias that you want. For example:
# ifconfig lo:0 172.16.1.1 |
Each alias may be treated as though it is a separate device, and as far as the kernel IP software is concerned, it will be; however, it will be sharing its hardware with another interface.
| [1] | Anyone remember Pink Floyd's “Echoes”? |
| [2] | For example, all applications based on RPC use the loopback interface to register themselves with the portmapper daemon at startup. These applications include NIS and NFS. |
| [3] | Note that pointopoint is not a typo. It's really spelled like this. |
| [4] | As a matter of caution, you should configure a PLIP or SLIP link only after you have completely set up the routing table entries for your Ethernets. With some older kernels, your network route might otherwise end up pointing at the point-to-point link. |
| [5] | The dummy device is called dummy0 if you have loaded it as a module rather than choosing it as an inbuilt kernel option. This is because you are able to load multiple modules and have more than one dummy device. |
| [6] | More correctly, using IP aliasing is known as network layer virtual hosting. It is more common in the WWW and STMP worlds to use application layer virtual hosting, in which the same IP address is used for each virtual host, but a different hostname is passed with each application layer request. Services like FTP are not capable of operating in this way, and they demand network layer virtual hosting. |