TCP/IP and PPP (Running Linux)

So, you've staked out your homestead on the Linux frontier, and installed and configured your system. What next? Eventually you'll want to communicate with other systems--Linux and otherwise--and the Pony Express isn't going to suffice.

Fortunately, Linux supports a number of methods for data communication and networking. This includes serial communications, TCP/IP, and UUCP. In this chapter and the next, we will discuss how to configure your system to communicate with the world.

Linux Network Administrator's Guide, available from the Linux Documentation Project (see the Bibliography) and also published by O'Reilly & Associates, is a complete guide to configuring TCP/IP and UUCP networking under Linux. For a detailed account of the information presented here, we refer you to that book.

15.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 Internet--the 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 TCP/IP support has had its ups and downs. After all, implementing an entire protocol stack from scratch isn't something that one does for fun on a weekend. On the other hand, the Linux TCP/IP code has benefited greatly from the hoard of beta testers and developers to have crossed its path, and as time has progressed many bugs and configuration problems have fallen in their wake.

The current implementation of TCP/IP and related protocols for Linux is called NET-4. This has no relationship to the so-called NET-2 release of BSD Unix; instead, in this context, NET-4 means the fourth implementation of TCP/IP for Linux. Before NET-4 came (no surprise here) NET-3, NET-2, and NET-1, the last having been phased out around kernel Version 0.99.pl10. NET-4 supports nearly all the features you'd expect from a Unix TCP/IP implementation and a wide range of networking hardware.

Linux NET-2 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 any more, because nowadays most people use PPP. If you want to run SLIP on your machine, you can find all the information in the Linux Network Administrator's Guide.

Besides the Linux Network Administrator's Guide, the Linux NET-3 HOWTO contains more or less complete information on configuring TCP/IP and PPP for Linux. The Linux Ethernet HOWTO is a related document that describes configuration of various Ethernet card drivers for Linux.

Also of interest is TCP/IP Network Administration by Craig Hunt. 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 by Cricket Liu and Paul Albitz. This book tells you all there is to know about name servers in a refreshingly funny manner.

15.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. Transmission Control Protocol/Internet Protocol 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 and the first volume of W. Richard Stevens' TCP/IP Illustrated.

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 then, 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 of 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 128.17.75.20.

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 upon 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 (see Figure 15-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 128.17.75.20 is host number 75.20 on the network 128.17.

Figure 15-1. IP address

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 two bytes of host information, up to 65,534 hosts on the network. The organization may then wish to dole 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 (see Figure 15-2). In this case, the IP address 128.17.75.20 identifies host number 20 on subnetwork 75 of network 128.17.[57]

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

Figure 15-2. IP address with subnet

Processes (either on the same machine or on 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 telnet program allows a user on one machine to start a login session on another. On the remote machine, there is the telnet "daemon," telnetd, which is listening to a specific port for incoming connections (in this case, the port number is 23).[58]

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

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

Note that the telnet 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 telnetd doesn't need to know the port number of the incoming telnet client beforehand. When the client initiates the connection, part of the information it sends to telnetd is its port number. telnetd can be thought of as a business with a well-known mailing address. Any customers that wish to correspond with the telnetd running on a particular machine need to know not only the IP address of the machine to talk to (the address of the telnetd office building), but also the port number where telnetd can be found (the particular office within the building). The address and port number of the telnet 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.

In order 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 Service (DNS) takes care of translating hostnames to IP addresses, and vice versa, as well as handles 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. If those aren't enough, you can really get the full scoop from the book DNS and BIND.

For the purposes of most administration, all you need to know is that a daemon called named (pronounced "name-dee") has to run on your system. This daemon 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 together through some physical network medium--such 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 15-3 depicts the configuration of these machines on the network. Note that papaya is connected to another network as well, which includes the machines pineapple and pear. These machines have the respective IP addresses:

Hostname	IP address
eggplant	128.17.75.20
apricot	128.17.75.12
zucchini	128.17.75.37
papaya	128.17.75.98, 128.17.112.3
pear	128.17.112.21
pineapple	128.17.112.40, 128.17.30.1

Figure 15-3. Network with two gateways

As you can see, papaya has two IP addresses--one on the 128.17.75 subnetwork and another on the 128.17.112 subnetwork. pineapple has two IP addresses as well--one on 128.17.112 and another on 128.17.30.

IP uses the network portion of the IP address to determine how to route packets between machines. In order 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
128.17.75.0   128.17.75.20  255.255.255.0  UN     1500 0         0 eth0
default       128.17.75.98  0.0.0.0        UGN    1500 0         0 eth0

127.0.0.1     127.0.0.1     255.0.0.0      UH     3584 0         0 lo
128.17.75.20  127.0.0.1     255.255.255.0  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 128.17.75.20, 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 127.0.0.1, 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 128.17.75.20, which is the eggplant host's own address. As we can see, it uses 127.0.0.1 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 128.17.75.20 and a destination address of 128.17.75.37. IP determines that the network portion of the destination address is 128.17.75 and uses the routing table entry for 128.17.75.0 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? In this case, the destination address is 128.17.112.21. 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
128.17.75.0   128.17.75.98  255.255.255.0  UN     1500 0         0 eth0
128.17.112.0  128.17.112.3  255.255.255.0  UN     1500 0         0 eth1
default       128.17.112.40 0.0.0.0        UGN    1500 0         0 eth1
127.0.0.1     127.0.0.1     255.0.0.0      UH     3584 0         0 lo
128.17.75.98  127.0.0.1     255.255.255.0  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 wants 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.

15.1.2. Hardware Requirements

You can use Linux TCP/IP without any networking hardware at all; 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, obviously you'll need an Ethernet adapter card. Many Ethernet adapters are supported by Linux for the ISA, EISA, and PCI buses, as well as pocket and PCMCIA adapters. In Chapter 1, "Introduction to Linux", we provided a partial list of supported Ethernet cards; see the Linux Ethernet HOWTO for a complete discussion of Linux Ethernet hardware compatibility.

Linux also supports SLIP and PPP, which allow you to use a modem to access the Internet over the phone line. In this case, you'll need a modem compatible with your SLIP or PPP server; for example, many servers require a 56kbps 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. If you want to use the older SLIP, please see the Linux Network Administrator's Guide.

15.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 which case your gateway, name server, 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 the section "Section 15.2, "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 name server 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 LAN--but 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 Telnet 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.

We also assume that your kernel has been configured and compiled with TCP/IP support enabled. See the section "Section 7.4, "Building a New Kernel"" in Chapter 7, "Upgrading Software and the Kernel", 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 used by NET-4. 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, but in other cases 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 NET-2 configuration files and software in the same location; they may be spread across several directories.

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.

15.1.3.1. 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 network-access provider can provide you with this information:

Your IP address

15.1.3.2. The networking rc files

rc files are systemwide resource configuration scripts executed at boottime 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/rc.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 rc 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, on the other hand, distributes the configuration over several files, such as /sbin/init.d/network and /sbin/init.d/route, among others, and lets you configure most networking aspects via the tool yast.)

Here, we're going to describe the rc files used to configure TCP/IP:

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.
SuSE: All the startup files for all system services, including networking, are grouped together in the /sbin/init.d directory. They are actually quite generic and get their actual values from the system-wide configuration file /etc/rc.config. The most important files here are /sbin/init.d/network, which starts and halts network interfaces, /sbin/init.d/route, which configures routing, and /sbin/init.d/ serial, which configures serial ports. If you have ISDN hardware, the files /sbin/init.d/i4l and /sbin/init.d/i4l_hardware are applicable, too. Note that in general, you do not need to (and should not) edit those files; edit /etc/rc.config instead.
Debian: The network configuration (Ethernet cards, IP addresses, and routing) is set up in the file /etc/init.d/network. The base networking daemons (portmap and inetd themselves are initialized by the start-stop script /etc/init.d/netbase).
Slackware: Networking is started by files named rc.inet1 and rc.inet2. rc.inet1 is used to configure the basic network parameters (such as IP addresses and routing information), and rc.inet2 fires up the TCP/IP daemons (telnetd, ftpd, and so forth).

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

n1:34:wait:/etc/rc.d/rc.inet1 
n2:34:wait:/etc/rc.d/rc.inet2

The inittab file is described in the section "Section 5.3.2, "init, inittab, and rc files"" in Chapter 5, "Essential System Management". The first field gives a unique two-character identifier for each entry. The second field lists the runlevels in which the scripts are run; on this system, we initialize networking in runlevels 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:

#!/bin/sh
# This is /etc/rc.d/rc.inet1 - Configure the TCP/IP interfaces

# First, configure the loopback device

HOSTNAME=`hostname`

/sbin/ifconfig lo 127.0.0.1   # uses default netmask 255.0.0.0
/sbin/route add 127.0.0.1     # 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="128.17.75.20"       # REPLACE with your IP address
NETMASK="255.255.255.0"     # REPLACE with your subnet mask
NETWORK="128.17.75.0"       # REPLACE with your network address
BROADCAST="128.17.75.255"   # REPLACE with your broadcast address
GATEWAY="128.17.75.98"      # 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 127.0.0.1

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

ifconfig eth0 127.17.75.20

assigns the eth0 (first Ethernet) device the address 127.17.75.20.

In addition to specifying the address, Ethernet devices usually require that the subnetwork mask be set with the netmask option and 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 the IP address of the gateway for this route, and metric 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 128.17.75.98, we would use the command:

route add default gw 128.17.75.98

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 destination--if 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 further below). 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 off a copy of the appropriate daemon for that port. For example, when an incoming Telnet connection is made, inetd forks in.telnetd, which handles the Telnet 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 log files 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/rc.d/rc.inet2

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

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

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

Among the various additional servers you may want to start in rc.inet2 is named. named is a name server; it is responsible for translating (local) IP addresses to names, and vice versa. If you don't have a name server 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.

15.1.3.3. /etc/hosts

/etc/hosts contains a list of IP addresses and the hostnames they correspond to. In general, /etc/hosts contains entries only for your local machine and perhaps other "important" machines (such as your name server or gateway). Your local name server provides address-to-name mappings for other machines on the network transparently.

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

127.0.0.1               localhost
128.17.75.20            eggplant.veggie.com eggplant

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

15.1.3.4. /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         0.0.0.0         # default route    - mandatory
loopnet         127.0.0.0       # loopback network - mandatory
veggie-net      128.17.75.0     # Modify for your own network address

Now, instead of using the command:

route add 128.17.75.20

we can use:

route add veggie-net

15.1.3.5. /etc/host.conf

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

order hosts,bind
multi on

These lines tell the resolver libraries to first check the /etc/hosts file and then ask the name server (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 the new glibc2 (like Red Hat from Version 5.0, SuSE from Version 6.0 and Debian from Version 2.0), /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.

15.1.3.6. /etc/resolv.conf

This file configures the name resolver, specifying the address of your name server (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:

search vpizza.com vpasta.com

then using the hostname blurb will try to resolve the names blurb.vpizza.com and blurb.vpasta.com (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 eggplant.veggie.com with a name server at address 128.17.75.55 would have the following lines in /etc/resolv.conf:

domain      veggie.com
nameserver  128.17.75.55

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

15.1.3.7. Setting your hostname

You should set your system hostname with the hostname command. This is usually executed from /etc/rc.d/rc.sysinit (/sbin/init.d/boot on SuSE systems); simply search your system rc files to determine where it is invoked. For example, if your (full) hostname is eggplant.veggie.com, edit the appropriate rc file to execute the command /bin/hostname eggplant.veggie.com. Note that the hostname executable may be found in a directory other than /bin on your system.

15.1.3.8. 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 telnet 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, whereas 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 hostname does not, there may be a problem with your name server configuration (e.g., /etc/resolv.conf and /etc/host.conf ) or with your route to the name server.

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 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 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 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.

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 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 and/or cable to determine if this is the source of the problem.[59]

[59]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 slot--mea culpa.