Section 13.1. Networking with TCP/IP

Linux supports a full implementation of the Transmission Control Protocol/Internet Protocol (TCP/IP) networking protocols. TCP/IP has become the most successful mechanism for networking computers worldwide. With Linux and an Ethernet card, you can network your machine to a local area network (LAN) or (with the proper network connections) to the Internetthe worldwide TCP/IP network.

Hooking up a small LAN of Unix machines is easy. It simply requires an Ethernet controller in each machine and the appropriate Ethernet cables and other hardware. Or if your business or university provides access to the Internet, you can easily add your Linux machine to this network.

Linux also supports Serial Line Internet Protocol (SLIP ) and Point-to-Point Protocol (PPP ). SLIP and PPP allow you to have dial-up Internet access using a modem. If your business or university provides SLIP or PPP access, you can dial in to the SLIP or PPP server and put your machine on the Internet over the phone line. Alternatively, if your Linux machine also has Ethernet access to the Internet, you can configure it as a SLIP or PPP server.

In the following sections, we won't mention SLIP anymore because nowadays most people use PPP.

Besides the Linux Network Administrator's Guide, the various HOWTOs at contain lots of information about how to set up particular aspects of networking, including how to deal with unruly hardware like some modems. For example, Linux Ethernet HOWTO at is a document that describes configuration of various Ethernet card drivers for Linux.

Also of interest is TCP/IP Network Administration (O'Reilly). It contains complete information on using and configuring TCP/IP on Unix systems. If you plan to set up a network of Linux machines or do any serious TCP/IP hacking, you should have the background in network administration presented by that book.

If you really want to get serious about setting up and operating networks, you will probably also want to read DNS and BIND (O'Reilly). This book tells you all there is to know about nameservers in a refreshingly funny manner.

13.1.1. TCP/IP Concepts

In order to fully appreciate (and utilize) the power of TCP/IP, you should be familiar with its underlying principles. TCP/IP is a suite of protocols (the magic buzzword for this chapter) that define how machines should communicate with each other via a network, as well as internally to other layers of the protocol suite. For the theoretical background of the Internet protocols, the best sources of information are the first volume of Douglas Comer's Internetworking with TCP/IP (Prentice Hall) and the first volume of W. Richard Stevens' TCP/IP Illustrated (Addison Wesley).

TCP/IP was originally developed for use on the Advanced Research Projects Agency network, ARPAnet, which was funded to support military and computer-science research. Therefore, you may hear TCP/IP being referred to as the "DARPA Internet Protocols." Since that first Internet, many other TCP/IP networks have come into use, such as the National Science Foundation's NSFNET, as well as thousands of other local and regional networks around the world. All these networks are interconnected into a single conglomerate known as the Internet.

On a TCP/IP network, each machine is assigned an IP address, which is a 32-bit number uniquely identifying the machine. You need to know a little about IP addresses to structure your network and assign addresses to hosts. The IP address is usually represented as a dotted quad: four numbers in decimal notation, separated by dots. As an example, the IP address 0x80114b14 (in hexadecimal format) can be written as

Two special cases should be mentioned here: dynamic IP addresses and masqueraded IP addresses. Both were invented to overcome the current shortage of IP addresses (which will not be of concern any longer once everybody has adopted the new IPv6 standard that prescribes 6 bytes for the IP addressesenough for every amoeba in the universe to have an IP address).[*]

[*] Linux supports IPv6, but since most local networks and ISPs do not use it yet, it is not very relevant at this time, unfortunately.

Dynamic IP addresses are what most Internet service providers (ISPs) use. When you connect to your ISP's service, whether by dial-up, DSL, or otherwise, you are assigned an IP number out of a pool that the ISP has allocated for this service. The next time you log in, you might get a different IP number. The idea behind this is that only a small number of the customers of an ISP are logged in at the same time, so a smaller number of IP addresses are needed. Still, as long as your computer is connected to the Internet, it has a unique IP address that no other computer is using at that time.

Masquerading (also known as Network Address Translation, NAT ) allows several computers to share an IP address. All machines in a masqueraded network use so-called private IP numbers, numbers out of a range that is allocated for internal purposes and that can never serve as real addresses out there on the Internet. Any number of networks can use the same private IP numbers, as they are never visible outside of the LAN. One machine, the "masquerading server," will map these private IP numbers to one public IP number (either dynamic or static) and ensure through an ingenious mapping mechanism that incoming packets are routed to the right machine.

The IP address is divided into two parts: the network address and the host address. The network address consists of the higher-order bits of the address and the host address of the remaining bits. (In general, each host is a separate machine on the network.) The size of these two fields depends on the type of network in question. For example, on a Class B network (for which the first byte of the IP address is between 128 and 191), the first two bytes of the address identify the network, and the remaining two bytes identify the host (Figure 13-1). For the example address just given, the network address is 128.17, and the host address is 75.20. To put this another way, the machine with IP address is host number 75.20 on the network 128.17.

In addition, the host portion of the IP address may be subdivided to allow for a subnetwork address. Subnetworking allows large networks to be divided into smaller subnets, each of which may be maintained independently. For example, an organization may allocate a single Class B network, which provides 2 bytes of host information, up to 65,534 hosts on the network.[] The organization may then wish to dole

[] Why not 65,536 instead? For reasons to be discussed later, a host address of 0 or 255 is invalid.

Figure 13-1. IP address

out the responsibility of maintaining portions of the network so that each subnetwork is handled by a different department. Using subnetworking, the organization can specify, for example, that the first byte of the host address (that is, the third byte of the overall IP address) is the subnet address, and the second byte is the host address for that subnetwork (Figure 13-2). In this case, the IP address identifies host number 20 on subnetwork 75 of network 128.17.

Figure 13-2. IP address with subnet

Processes (on either the same or different machines) that wish to communicate via TCP/IP generally specify the destination machine's IP address as well as a port address. The destination IP address is used, of course, to route data from one machine to the destination machine. The port address is a 16-bit number that specifies a particular service or application on the destination machine that should receive the data. Port numbers can be thought of as office numbers at a large office building: the entire building has a single IP address, but each business has a separate office there.

Here's a real-life example of how IP addresses and port numbers are used. The ssh program allows a user on one machine to start a login session on another, while encrypting all the data traffic between the two so that nobody can intercept the communication. On the remote machine, the ssh daemon, sshd, is listening to a specific port for incoming connections (in this case, the port number is 22).[*]

[*] On many systems, sshd is not always listening to port 22; the Internet services daemon inetd is listening on its behalf. For now, let's sweep that detail under the carpet.

The user executing ssh specifies the address of the machine to log in to, and the ssh program attempts to open a connection to port 22 on the remote machine. If it is successful, ssh and sshd are able to communicate with each other to provide the remote login for the user in question.

Note that the ssh client on the local machine has a port address of its own. This port address is allocated to the client dynamically when it begins execution. This is because the remote sshd doesn't need to know the port number of the incoming ssh client beforehand. When the client initiates the connection, part of the information it sends to sshd is its port number. sshd can be thought of as a business with a well-known mailing address. Any customers who wish to correspond with the sshd running on a particular machine need to know not only the IP address of the machine to talk to (the address of the sshd office building), but also the port number where sshd can be found (the particular office within the building). The address and port number of the ssh client are included as part of the "return address" on the envelope containing the letter.

The TCP /IP family contains a number of protocols. Transmission Control Protocol (TCP) is responsible for providing reliable, connection-oriented communications between two processes, which may be running on different machines on the network. User Datagram Protocol (UDP ) is similar to TCP except that it provides connectionless, unreliable service. Processes that use UDP must implement their own acknowledgment and synchronization routines if necessary.

TCP and UDP transmit and receive data in units known as packets . Each packet contains a chunk of information to send to another machine, as well as a header specifying the destination and source port addresses.

Internet Protocol (IP) sits beneath TCP and UDP in the protocol hierarchy. It is responsible for transmitting and routing TCP or UDP packets via the network. In order to do so, IP wraps each TCP or UDP packet within another packet (known as an IP datagram), which includes a header with routing and destination information. The IP datagram header includes the IP address of the source and destination machines.

Note that IP doesn't know anything about port addresses; those are the responsibility of TCP and UDP. Similarly, TCP and UDP don't deal with IP addresses, which (as the name implies) are only IP's concern. As you can see, the mail metaphor with return addresses and envelopes is quite accurate: each packet can be thought of as a letter contained within an envelope. TCP and UDP wrap the letter in an envelope with the source and destination port numbers (office numbers) written on it.

IP acts as the mail room for the office building sending the letter. IP receives the envelope and wraps it in yet another envelope, with the IP address (office building address) of both the destination and the source affixed. The post office (which we haven't discussed quite yet) delivers the letter to the appropriate office building. There, the mail room unwraps the outer envelope and hands it to TCP/UDP, which delivers the letter to the appropriate office based on the port number (written on the inner envelope). Each envelope has a return address that IP and TCP/UDP use to reply to the letter.

To make the specification of machines on the Internet more humane, network hosts are often given a name as well as an IP address. The Domain Name System (DNS ) takes care of translating hostnames to IP addresses, and vice versa, as well as handling the distribution of the name-to-IP-address database across the entire Internet. Using hostnames also allows the IP address associated with a machine to change (e.g., if the machine is moved to a different network), without having to worry that others won't be able to "find" the machine once the address changes. The DNS record for the machine is simply updated with the new IP address, and all references to the machine, by name, will continue to work.

DNS is an enormous, worldwide distributed database. Each organization maintains a piece of the database, listing the machines in the organization. If you find yourself in the position of maintaining the list for your organization, you can get help from the Linux Network Administrator's Guide or TCP/IP Network Administration, both from O'Reilly. If those aren't enough, you can really get the full scoop from the book DNS and BIND (O'Reilly).

For the purposes of most administration, all you need to know is that either a daemon called named (pronounced "name-dee") has to run on your system, or you need to configure your system to use somebody else's name servicetypically your ISP's or one running in your local network. This daemon or name service is your window onto DNS.

Now, we might ask ourselves how a packet gets from one machine (office building) to another. This is the actual job of IP, as well as a number of other protocols that aid IP in its task. Besides managing IP datagrams on each host (as the mail room), IP is also responsible for routing packets between hosts.

Before we can discuss how routing works, we must explain the model upon which TCP/IP networks are built. A network is just a set of machines that are connected through some physical network mediumsuch as Ethernet or serial lines. In TCP/IP terms, each network has its own methods for handling routing and packet transfer internally.

Networks are connected to each other via gateways (also known as routers ). A gateway is a host that has direct connections to two or more networks; the gateway can then exchange information between the networks and route packets from one network to another. For instance, a gateway might be a workstation with more than one Ethernet interface. Each interface is connected to a different network, and the operating system uses this connectivity to allow the machine to act as a gateway.

In order to make our discussion more concrete, let's introduce an imaginary network, made up of the machines eggplant, papaya, apricot, and zucchini. Figure 13-3 depicts the configuration of these machines on the network.

Figure 13-3. Network with two gateways

As you can see, papaya has two IP addressesone on the 128.17.75 subnetwork and another on the 128.17.112 subnetwork. pear and pineapple are both on network 128.17.112, and pineapple is also on 128.17.30.

IP uses the network portion of the IP address to determine how to route packets between machines. To do this, each machine on the network has a routing table, which contains a list of networks and the gateway machine for that network. To route a packet to a particular machine, IP looks at the network portion of the destination address. If there is an entry for that network in the routing table, IP routes the packet through the appropriate gateway. Otherwise, IP routes the packet through the "default" gateway given in the routing table.

Routing tables can contain entries for specific machines as well as for networks. In addition, each machine has a routing table entry for itself.

Let's examine the routing table for eggplant. Using the command netstat -rn, we see the following:

    eggplant:$ netstat -rn
            Kernel IP routing table
            Destination   Gateway       Genmask        Flags  MSS  Window irtt Iface
    UN     1500 0         0 eth0
            default        UGN    1500 0         0 eth0
        UH     3584 0         0 lo
    UH     3584 0         0 lo

The first column displays the destination networks (and hosts) that the routing table includes. The first entry is for the network 128.17.75 (note that the host address is 0 for network entries), which is the network that eggplant lives on. Any packets sent to this network should be routed through, which is the IP address of eggplant. In general, a machine's route to its own network is through itself.

The Flags column of the routing table gives information on the destination address for this entry; U specifies that the route is "up," N that the destination is a network, and so on. The MSS field shows how many bytes are transferred at a time over the respective connection, Window indicates how many frames may be sent ahead before a confirmation must be made, irtt gives statistics on the use of this route, and Iface lists the network device used for the route. On Linux systems, Ethernet interfaces are named eth0, eth1, and so on. lo is the loopback device, which we'll discuss shortly.

The second entry in the routing table is the default route, which applies to all packets destined for networks or hosts for which there is no entry in the table. In this case, the default route is through papaya, which can be considered the door to the outside world. Every machine on the 128.17.75 subnet must go through papaya to talk to machines on any other network.

The third entry in the table is for the address, which is the loopback address. This address is used when a machine wants to make a TCP/IP connection to itself. It uses the lo device as its interface, which prevents loopback connections from using the Ethernet (via the eth0 interface). In this way, network bandwidth is not wasted when a machine wishes to talk to itself.

The last entry in the routing table is for the IP address, which is the eggplant host's own address. As we can see, it uses as its gateway. This way, any time eggplant makes a TCP/IP connection to itself, the loopback address is used as the gateway, and the lo network device is used.

Let's say that eggplant wants to send a packet to zucchini. The IP datagram contains a source address of and a destination address of IP determines that the network portion of the destination address is 128.17.75 and uses the routing table entry for accordingly. The packet is sent directly to the network, which zucchini receives and is able to process.

What happens if eggplant wants to send packets to a machine not on the local network, such as pear? The destination address is IP attempts to find a route for the 128.17.112 network in the routing tables, but none exists, so it selects the default route through papaya. papaya receives the packet and looks up the destination address in its own routing tables. The routing table for papaya might look like this:

    Destination   Gateway       Genmask        Flags  MSS  Window irtt Iface
    UN     1500 0         0 eth0
    UN     1500 0         0 eth1
            default        UGN    1500 0         0 eth1
        UH     3584 0         0 lo
    UH     3584 0         0 lo

As you can see, papaya is connected to the 128.17.75 network through its eth0 device and to 128.17.112 through eth1. The default route is through pineapple, which is a gateway to the Wild Blue Yonder (as far as papaya is concerned).

Once papaya receives a packet destined for pear, it sees that the destination address is on the network 128.17.112 and routes that packet to the network using the second entry in the routing table.

Similarly, if eggplant wanted to send packets to machines outside the local organization, it would route packets through papaya (its gateway). papaya would, in turn, route outgoing packets through pineapple, and so forth. Packets are handed from one gateway to the next until they reach the intended destination network. This is the basic structure upon which the Internet is based: a seemingly infinite chain of networks, interconnected via gateways.

13.1.2. Hardware Requirements

You can use Linux TCP/IP without any networking hardware ; configuring "loopback" mode allows you to talk to yourself. This is necessary for some applications and games that use the loopback network device.

However, if you want to use Linux with an Ethernet TCP/IP network, you'll need an Ethernet adapter card. Many Ethernet adapters are supported by Linux for the ISA, EISA, and PCI buses, as well as USB and PCMCIA adapters. See the Linux Ethernet HOWTO for a complete discussion of Linux Ethernet hardware compatibility. For any reasonably new computer (that was sold in the last, say, two to three years), it is also quite likely that the computer has Ethernet built in, so you do not have install an Ethernet adapter card. You'll recognize this because there is an Ethernet connector socket (type RJ45) somewhere.

Over the last few years, support has been added for non-Ethernet high-speed networking, such as HIPPI. This topic is beyond the scope of this book, but if you are interested, you can get some information from the directory Documentation/networking in your kernel sources.

If you have an ADSL connection and use an ADSL router, this looks to Linux just like a normal Ethernet connection. As such, you need neither specific hardware (except an Ethernet card, of course) nor special drivers besides the Ethernet card driver itself. If you want to connect your Linux box directly to your ADSL modem, you still don't need to have any particular hardware or driver, but you do need to run a protocol called PPPoE (PPP over Ethernet); more about this later.

Linux also supports SLIP and PPP, which allow you to use a modem to access the Internet over a phone line. In this case, you'll need a modem compatible with your SLIP or PPP server; for example, many servers require a 56-kbps V.90 modem (most also support K56flex). In this book, we describe the configuration of PPP because it is what most Internet service providers offer.

Finally, there is PLIP, which lets you connect two computers directly via parallel ports, requiring a special cable between the two.

13.1.3. Configuring TCP/IP with Ethernet

In this section, we discuss how to configure an Ethernet TCP/IP connection on a Linux system. Presumably this system will be part of a local network of machines that are already running TCP/IP; in this case, your gateway, nameserver, and so forth are already configured and available.

The following information applies primarily to Ethernet connections. If you're planning to use PPP, read this section to understand the concepts, and follow the PPP-specific instructions in "Dial-Up PPP," later in this chapter.

On the other hand, you may wish to set up an entire LAN of Linux machines (or a mix of Linux machines and other systems). In this case, you'll have to take care of a number of other issues not discussed here. This includes setting up a nameserver for yourself, as well as a gateway machine if your network is to be connected to other networks. If your network is to be connected to the Internet, you'll also have to obtain IP addresses and related information from your access provider.

In short, the method described here should work for many Linux systems configured for an existing LANbut certainly not all. For further details, we direct you to a book on TCP/IP network administration, such as those mentioned at the beginning of this chapter.

First of all, we assume that your Linux system has the necessary TCP/IP software installed. This includes basic clients such as ssh and FTP, system-administration commands such as ifconfig and route (usually found in /etc or /sbin), and networking configuration files (such as /etc/hosts). The other Linux-related networking documents described earlier explain how to go about installing the Linux networking software if you do not have it already.

A new system administration interface has been developed that unifies the various networking tasks (configurating, routing, etc.) into a single command named ip, provided by the IPROUTE2 package. We won't cover it here, because its value lies mainly in advanced features that most administrators don't use, but once you understand the concepts in this chapter you can figure out how to use those commands if you want to use that package.

We also assume that your kernel has been configured and compiled with TCP/IP support enabled. See "Building a New Kernel" in Chapter 18 for information on compiling your kernel. To enable networking, you must answer yes to the appropriate questions during the make config or make menuconfig step, rebuild the kernel, and boot from it.

Once this has been done, you must modify a number of configuration files. For the most part this is a simple procedure. Unfortunately, however, there is wide disagreement between Linux distributions as to where the various TCP/IP configuration files and support programs should go. Much of the time, they can be found in /etc or /etc/sysconfig, but in other cases they may be found in /usr/etc, /usr/etc/inet, or other bizarre locations. In the worst case, you'll have to use the find command to locate the files on your system. Also note that not all distributions keep the network configuration files and software in the same location; they may be spread across several directories.

Here we cover how to set up and configure networking on a Linux box manually. This should help you get some insight into what goes on behind the scenes and enable you to help yourself if something goes wrong with automatic setup tools provided by your distribution. It can be a good idea, though, to first try setting up your network with the configuration programs that your distribution provides; many of these are quite advanced these days and detect many of the necessary settings automatically. They are usually available from the menus on your desktop. If you understand the concepts in this chapter, it is not hard to figure out how to use them, but we do not cover them here because they tend to change, and what you mainly need to know is the effects you're aiming to achieve.

This section also assumes use of one Ethernet device on the system. These instructions should be fairly easy to extrapolate if your system has more than one network connection (and hence acts as a gateway).

Here, we also discuss configuration for loopback-only systems (systems with no Ethernet or PPP connection). If you have no network access, you may wish to configure your system for loopback-only TCP/IP so that you can use applications that require it. Your network configuration

Before you can configure TCP/IP , you need to determine the following information about your network setup. In most cases, your local network administrator or ISP can provide you with this information. If your network is using DHCP, things are going to be a bit differentfor example, you do not need to know your IP address, since it will be assigned to you automatically. But it's often easier to test things one step at a time and start with a static IP address. Just make sure with your network administrator or Internet service provider that you are not using one that another computer on the network is already usingthat could be very annoying both for you and the other user, because communication will be disturbed, to say the least.

Your IP address

This is the unique machine address in dotted-decimal format. An example is Your network administrators will provide you with this number.

If you're configuring loopback mode (i.e., no PPP and no Ethernet card, just TCP/IP connections to your own machine), your IP address is

Your subnetwork mask

This is a dotted quad, similar to the IP address, which determines which portion of the IP address specifies the subnetwork number and which portion specifies the host on that subnet.

The subnetwork mask is a pattern of bits, which, when bitwise-ANDed with an IP address on your network, will tell you which subnet that address belongs to. For example, your subnet mask might be If your IP address is, the subnetwork portion of your address is 128.17.75.

We distinguish here between "network address" and "subnetwork address." Remember that for Class B addresses , the first two bytes (here, 128.17) specify the network, while the second two bytes specify the host. With a subnet mask of, however, 128.17.75 is considered the entire subnet address (e.g., subnetwork 75 of network 128.17), and 20 the host address.

Your network administrators choose the subnet mask and therefore can provide you with this information.

This applies as well to the loopback device. Since the loopback address is always, the netmask for this device is always

Your subnetwork address

This is the subnet portion of your IP address as determined by the subnet mask. For example, if your subnet mask is and your IP address, your subnet address is

Loopback-only systems don't have a subnet address.

Your broadcast address

This address is used to broadcast packets to every machine on your subnet. In general, this is equal to your subnet address (see previous item) with 255 replaced as the host address. For subnet address, the broadcast address is Similarly, for subnet address, the broadcast address is

Note that some systems use the subnetwork address as the broadcast address. If you have any doubt, check with your network administrators.

Loopback-only systems do not have a broadcast address.

The IP address of your gateway

This is the address of the machine that acts as the default route to the outside world. In fact, you may have more than one gateway addressfor example, if your network is connected directly to several other networks. However, only one of these will act as the default route. (Recall the example in the previous section, where the network is connected to both through papaya and the outside world through pineapple.)

Your network administrators will provide you with the IP addresses of any gateways on your network, as well as the networks they connect to. Later, you will use this information with the route command to include entries in the routing table for each gateway.

Loopback-only systems do not have a gateway address. The same is true for isolated networks.

The IP address of your nameserver

This is the address of the machine that handles hostname-to-address translations for your machine. Your network administrators will provide you with this information.

You may wish to run your own nameserver (by configuring and running named). However, unless you absolutely must run your own nameserver (for example, if no other nameserver is available on your local network), we suggest using the nameserver address provided by your network administrators (or your ISP). At any rate, most books on TCP/IP configuration include information on running named.

Naturally, loopback-only systems have no nameserver address. The network configuration files

Network configuration files are system-wide resource configuration scripts executed at boot time by init. They run basic system daemons (such as sendmail, crond, and so on) and are used to configure network parameters. rc files are usually found in the directory /etc/init.d.

Note that there are many ways to carry out the network configuration described here. Every Linux distribution uses a slightly different mechanism to help automate the process. What we describe here is a generic method that allows you to create two network configuration files that will run the appropriate commands to get your machine talking to the network. Most distributions have their own scripts that accomplish more or less the same thing. If in doubt, first attempt to configure networking as suggested by the documentation for your distribution and, as a last resort, use the methods described here. (As an example, the Red Hat distribution uses the script /etc/rc.d/init.d/network, which obtains network information from files in /etc/sysconfig. The control-panel system administration program provided with Red Hat configures networking automatically without editing any of these files. The SUSE distribution uses /etc/init.d/network, and lets you configure most networking aspects via the tool YaST2. And of course, any new version of either distribution could change this again.)

Here, we're going to describe the network configuration files used to configure TCP/IP in some of the better-known distributions:

Red Hat

Networking is scattered among files for each init level that includes networking. For instance, the /etc/rc.d/rc1.d directory controls a level 1 (single-user) boot, so it doesn't have any networking commands, but the /etc/rc.d/rc3.d controlling a level 3 boot has files specifically to start networking.


All the startup files for all system services, including networking, are grouped together in the /etc/init.d directory. They are quite generic and get their actual values from the system-wide configuration file /etc/sysconfig. The most important files here are /etc/init.d/network, which starts and halts network interfaces and configures routing, and /etc/init.d/setserial, which configures serial ports. If you have ISDN hardware, the file /etc/init.d/isdn is applicable, too. Note that in general, you do not need to (and should not) edit those files; edit the files /etc/sysconfig instead (that's what YaST does).


The network configuration (Ethernet cards, IP addresses, and routing) and the base networking daemons (portman and inetd) are set up in the file /etc/init.d/networking.

We'll use two files here for illustrative purposes: /etc/init.d/rc.inet1 and /etc/init.d/rc.inet2. The former will set up the hardware and the basic networking, and the latter will configure the networking services. A number of distributions follow such a separation, even though the files might have other names.

init uses the file /etc/inittab to determine what processes to run at boot time. To run the files /etc/init.d/rc.inet1 and /etc/init.d/rc.inet2 from init, /etc/inittab might include entries such as:


The inittab file is described in "init, inittab, and rc Files" in Chapter 17. The first field gives a unique two-character identifier for each entry. The second field lists the run levels in which the scripts are run; on this system, we initialize networking in run levels 3 and 4. The word wait in the third field tells init to wait until the script has finished execution before continuing. The last field gives the name of the script to run.

While you are first setting up your network configuration, you may wish to run rc.inet1 and rc.inet2 by hand (as root) in order to debug any problems. Later you can include entries for them in another rc file or in /etc/inittab.

As mentioned earlier, rc.inet1 configures the basic network interface. This includes your IP and network address and the routing table information for your system. Two programs are used to configure these parameters: ifconfig and route. Both of these are usually found in /sbin.

ifconfig is used for configuring the network device interface with certain parameters, such as the IP address, subnetwork mask, broadcast address, and the like. route is used to create and modify entries in the routing table.

For most configurations, an rc.inet1 file similar to the following should work. You will, of course, have to edit this for your own system. Do not use the sample IP and network addresses listed here; they may correspond to an actual machine on the Internet:

    # This is /etc/init.d/rc.inet1 - Configure the TCP/IP interfaces

    # First, configure the loopback device


    /sbin/ifconfig lo   # uses default netmask
    /sbin/route add     # a route to point to the loopback device

    # Next, configure the Ethernet device. If you're only using loopback or
    # SLIP, comment out the rest of these lines.

    # Edit for your setup.
    IPADDR=""       # REPLACE with your IP address
    NETMASK=""     # REPLACE with your subnet mask
    NETWORK=""       # REPLACE with your network address
    BROADCAST=""   # REPLACE with your broadcast address
    GATEWAY=""      # REPLACE with your default gateway address

    # Configure the eth0 device to use information above.
    /sbin/ifconfig eth0 ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST}

    # Add a route for our own network.
    /sbin/route add ${NETWORK}

    # Add a route to the default gateway.
    /sbin/route add default gw ${GATEWAY} metric 1

    # End of Ethernet Configuration

As you can see, the format of the ifconfig command is

    ifconfig interface device options...

For example:

    ifconfig lo

assigns the lo (loopback) device the IP address, and

    ifconfig eth0

assigns the eth0 (first Ethernet) device the address

In addition to specifying the address, Ethernet devices usually require that the subnetwork mask be set with the netmask option and that the broadcast address be set with broadcast.

The format of the route command, as used here, is:

    route add [ -net | -host ] destination [ gw gateway ]
              [ metric metric ] options

where destination is the destination address for this route (or the keyword default), gateway is the IP address of the gateway for this route, and metric is the metric number for the route (discussed later).

We use route to add entries to the routing table. You should add a route for the loopback device (as seen earlier), for your local network, and for your default gateway. For example, if our default gateway is, we would use the command:

    route add default gw

route takes several options. Using -net or -host before destination will tell route that the destination is a network or specific host, respectively. (In most cases, routes point to networks, but in some situations you may have an independent machine that requires its own route. You would use -host for such a routing table entry.)

The metric option specifies a metric value for this route. Metric values are used when there is more than one route to a specific location, and the system must make a decision about which to use. Routes with lower metric values are preferred. In this case, we set the metric value for our default route to 1, which forces that route to be preferred over all others.

How could there possibly be more than one route to a particular location? First of all, you may use multiple route commands in rc.inet1 for a particular destinationif you have more than one gateway to a particular network, for example. However, your routing tables may dynamically acquire additional entries in them if you run routed (discussed later). If you run routed, other systems may broadcast routing information to machines on the network, causing extra routing table entries to be created on your machine. By setting the metric value for your default route to 1, you ensure that any new routing table entries will not supersede the preference of your default gateway.

You should read the manual pages for ifconfig and route, which describe the syntax of these commands in detail. There may be other options to ifconfig and route that are pertinent to your configuration.

Let's move on. rc.inet2 is used to run various daemons used by the TCP/IP suite. These are not necessary in order for your system to talk to the network, and are therefore relegated to a separate rc file. In most cases you should attempt to configure rc.inet1, and ensure that your system is able to send and receive packets from the network, before bothering to configure rc.inet2.

Among the daemons executed by rc.inet2 are inetd , syslogd, and routed. The version of rc.inet2 on your system may currently start a number of other servers, but we suggest commenting these out while you are debugging your network configuration.

The most important of these servers is inetd, which acts as the "operator" for other system daemons. It sits in the background and listens to certain network ports for incoming connections. When a connection is made, inetd spawns a copy of the appropriate daemon for that port. For example, when an incoming FTP connection is made, inetd forks in.ftpd, which handles the FTP connection from there. This is simpler and more efficient than running individual copies of each daemon. This way, network daemons are executed on demand.

syslogd is the system logging daemon; it accumulates log messages from various applications and stores them into logfiles based on the configuration information in /etc/syslogd.conf.

routed is a server used to maintain dynamic routing information. When your system attempts to send packets to another network, it may require additional routing table entries in order to do so. routed takes care of manipulating the routing table without the need for user intervention.

Here is a sample rc.inet2 that starts up syslogd, inetd, and routed:

    #! /bin/sh
    # Sample /etc/init.d/rc.inet2

    # Start syslogd
    if [ -f /usr/sbin/syslogd ]

    # Start inetd
    if [ -f /usr/sbin/inetd ]

    # Start routed
    if [ -f /usr/sbin/routed ]
    /usr/sbin/routed -q

Among the various additional servers you may want to start in rc.inet2 is named. named is a nameserver: it is responsible for translating (local) IP addresses to names, and vice versa. If you don't have a nameserver elsewhere on the network, or if you want to provide local machine names to other machines in your domain, it may be necessary to run named. named configuration is somewhat complex and requires planning; we refer interested readers to DNS and BIND (O'Reilly). /etc/hosts

/etc/hosts contains a list of IP addresses and the hostnames they correspond to. In general, /etc/hosts contains entries for your local machine and perhaps other "important" machines (such as your nameserver or gateway). Your local nameserver provides address-to-name mappings for other machines on the network transparently. It is in fact possible to only get your address-to-name mappings from the /etc/hosts file , without running a local nameserver at all. If you only have a few machines on your network, that may well be possible. But if you have more, then you would have to change the /etc/hosts file on each machine for each change, a task that grows quadratic in size with the number of machines and quickly becomes infeasible.

For example, if your machine is with the IP address, your /etc/hosts would look like this:               localhost   eggplant

If you're just using loopback, the only line in the /etc/hosts file should be for the address /etc/networks

The /etc/networks file lists the names and addresses of your own and other networks. It is used by the route command and allows you to specify a network by name instead of by address.

Every network you wish to add a route to using the route command (generally called from rc.inet1) should have an entry in /etc/networks for convenience; otherwise, you will have to specify the network's IP address instead of the name.

As an example:

    default         # default route    - mandatory
    loopnet       # loopback network - mandatory
    veggie-net     # Modify for your own network address

Now, instead of using the command:

    route add

we can use:

    route add veggie-net /etc/host.conf

The /etc/host.conf file specifies how your system resolves hostnames. It should contain the following two lines:

    order hosts,bind
    multi on

These lines tell the resolver libraries to first check the /etc/hosts file and then ask the nameserver (if one is present) for any names it must look up. The multi entry allows you to have multiple IP addresses for a given machine name in /etc/hosts.

On systems that use glibc2 (which applies to most of the newer distributions), /etc/nsswitch.conf is used instead of /etc/host.conf. In this case, this file should contain the lines hosts: files dns and networks: files dns. /etc/resolv.conf

The /etcresolv.conf file configures the name resolver, specifying the address of your nameserver (if any) and domains that you want to search by default if a specified hostname is not a fully specified hostname. For example, if this file contains the line:


using the hostname blurb will cause the name resolver to try to resolve the names and (in this order). This is convenient because it saves you typing in the full names of often-used domains. On the other hand, the more domains you specify here, the longer the DNS lookup will take.

For example, the machine with a nameserver at address would have the following lines in /etc/resolv.conf:


You can specify more than one nameserver; each must have a nameserver line of its own in resolv.conf. Setting your hostname

You should set your system hostname with the hostname command. This is usually executed from a file called /etc/init.d/boot.localnet or similar; simply search your system rc files to determine where it is invoked. For example, if your (full) hostname is, edit the appropriate rc file to execute the command /bin/hostname Note that the hostname executable may be found in a directory other than /bin on your system. Trying out your network

Once you have the various networking configuration files modified for your system, you should be able to reboot (using a TCP/IP-enabled kernel) and attempt to use the network.

When first booting the system, you may wish to disable execution of rc.inet1 and rc.inet2 and run them by hand once the system is up. This allows you to catch any error messages, modify the scripts, and retry. Once you have things working, you can enable the scripts from /etc/inittab.

One good way of testing network connectivity is to simply ssh to another host. You should first try to connect to another host on your local network, and if this works, attempt to connect to hosts on other networks . The former will test your connection to the local subnet; the latter, your connection to the rest of the world through your gateway.

You may be able to connect to remote machines via the gateway if connecting to machines on the subnet fails. This is a sign that there is a problem with your subnetwork mask or the routing table entry for the local network.

When attempting to connect to other machines, you should first try to connect using only the IP address of the remote host. If this seems to work, but connecting via the hostname does not, there may be a problem with your nameserver configuration (e.g., /etc/resolv.conf and /etc/host.conf) or with your route to the nameserver.

The most common source of network trouble is an ill-configured routing table. You can use the command

    netstat -rn

to display the routing table; in the previous section, we described the format of the routing tables as displayed by this command. The netstat(8) manual page provides additional insight as well. Using netstat without the -n option forces it to display host and network entries by name instead of by address.

To debug your routing tables, you can either edit rc.inet1 and reboot, or use the route command by hand to add or delete entries. The manual page for route(8) describes the full syntax of this command. Note that simply editing rc.inet1 and re-executing it will not clear out old entries in the routing table; you must either reboot or use route del to delete the entries.

If absolutely nothing seems to work, there may be a problem with your Ethernet device configuration. First, be sure that your Ethernet card was detected at the appropriate address and/or IRQ at boot time. The kernel boot messages will give you this information; if you are using syslogd, kernel boot-time messages are also saved in a file, such as /var/log/messages.

A good way to determine whether it was really the Ethernet card that created the trouble is to use the command ifconfig interface_name, as in the following example:

    ifconfig eth0

This will output statistics about the interface. If it has received or sent any packets, it must have been recognized by the kernel, and there cannot be a general hardware problem. If your card is not listed when issuing:


it wasn't even recognized by the kernel.

If detection of your Ethernet card is faulty, you may have to modify kernel parameters to fix it. The Linux Ethernet HOWTO includes much information on debugging Ethernet card configurations. In many cases, the fix is as simple as specifying the appropriate IRQ and port address at the LILO (or Grub, or whichever bootloader you are using) boot prompt. For example, booting via LILO with the command:

    lilo: linux ether=9,0x300,0,1,eth0

will select IRQ 9, base address 0x300, and the external transceiver (the fourth value of 1) for the eth0 device. To use the internal transceiver (if your card supports both types), change the fourth value of the ether option to 0.

Also, don't overlook the possibility that your Ethernet card is damaged or incorrectly connected to your machine or the network. A bad Ethernet card or cable can cause no end of trouble, including intermittent network failures, system crashes, and so forth. When you're at the end of your rope, consider replacing the Ethernet card or cable, or both, to determine if this is the source of the problem.[*]

[*] One of the authors once spent three hours trying to determine why the kernel wouldn't recognize an Ethernet card at boot time. As it turned out, the 16-bit card was plugged into an 8-bit slotmea culpa.

If your Ethernet card is detected but the system is still having problems talking to the network, the device configuration with ifconfig may be to blame. Be sure you have specified the appropriate IP address, broadcast address, and subnet mask for your machine. Invoking ifconfig with no arguments displays information on your Ethernet device configuration.

Part I: Enjoying and Being Productive on Linux
Part II: System Administration