LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/guide/docbook/nag2/ch05.sgm

1931 lines
83 KiB
Plaintext
Raw Permalink Blame History

<chapter id="X-087-2-iface"><title>Configuring <?lb>TCP/IP Networking</title>
<para>
<indexterm><primary>bootup sequence</primary></indexterm>
<indexterm><primary>initializing networking</primary></indexterm>
<indexterm><primary>networks</primary><secondary>booting</secondary></indexterm>
<indexterm id="chtc.tcpip.config.netwks" class="startofrange"><primary>TCP/IP (Transmission Control Protocol/Internet Protocol)</primary><secondary>configuring networks</secondary></indexterm>
In this chapter, we walk you through all the necessary steps to set up
TCP/IP networking on your machine. Starting with the assignment of IP
addresses, we slowly work our way through the configuration of TCP/IP
network interfaces and introduce a few tools that come in handy when
hunting down network installation problems.
</para>
<para>
Most of the tasks covered in this chapter will generally have to be
done only once. Afterward, you have to touch most configuration files
only when adding a new system to your network or when you reconfigure
your system entirely. Some of the commands used to configure TCP/IP,
however, have to be executed each time the system is booted. This is
usually done by invoking them from the system
<filename>/etc/rc*</filename> scripts.
</para>
<para>
<indexterm><primary>rc script</primary></indexterm>
Commonly, the network-specific part of this procedure is contained in
a script. The name of this script varies in different Linux
distributions. In many older Linux distributions, it is known as
<filename>rc.net</filename> or <filename>rc.inet</filename>. Sometimes
you will also see two scripts named <filename>rc.inet1</filename> and
<filename>rc.inet2</filename>&thinsp;; the former initializes the
kernel part of networking and the latter starts basic networking
services and applications. In modern distributions, the
<filename>rc</filename> files are structured in a more sophisticated
arrangement; here you may find scripts in the
<filename>/etc/init.d/</filename> (or
<filename>/etc/rc.d/init.d/</filename>&thinsp;) directory that create
the network devices and other <filename>rc</filename> files that run
the network application programs. This book's examples are based on
the latter arrangement.
</para>
<para>
This chapter discusses parts of the script that configure your network
interfaces, while applications will be covered in later chapters.
After finishing this chapter, you should have established a sequence
of commands that properly configure TCP/IP networking on your
computer. You should then replace any sample commands in your
configuration scripts with your commands, make sure the script is
executed from the basic <filename>rc</filename> script at startup
time, and reboot your machine. The networking <filename>rc</filename>
scripts that come along with your favorite Linux distribution should
provide a solid example from which to work.
</para>
<sect1 id="X-087-2-iface.procfs"><title>Mounting the /proc Filesystem</title>
<indexterm><primary>mounting</primary><secondary>the proc filesystem</secondary></indexterm>
<indexterm><primary>proc filesystem, mounting</primary></indexterm>
<para>
Some of the configuration tools of the Linux NET-2 and NET-3 release
rely on the <filename>/proc</filename> filesystem for communicating
with the kernel. This interface permits access to kernel runtime
information through a filesystem-like mechanism. When mounted, you can
list its files like any other filesystem, or display their contents.
Typical items include the <filename>loadavg</filename> file, which
contains the system load average, and <filename>meminfo</filename>,
which shows current core memory and swap usage.
</para>
<para>
<indexterm><primary sortas="proc/net file">/proc/net file</primary></indexterm>
To this, the networking code adds the <filename>net</filename> directory.
It contains a number of files that show things like the kernel ARP tables,
the state of TCP connections, and the routing tables. Most network
administration tools get their information from these files.
</para>
<para>
<indexterm><primary sortas="etc/fstab file">/etc/fstab file</primary></indexterm>
The <filename>proc</filename> filesystem (or <filename>procfs</filename>, as
it is also known) is usually mounted on <filename>/proc</filename> at system
boot time. The best method is to add the following line to
<filename>/etc/fstab</filename>&thinsp;:
<screen>
# procfs mount point:
none /proc proc defaults
</screen>
Then execute <command>mount /proc</command> from your
<filename>/etc/rc</filename> script.
</para>
<para>
The <filename>procfs</filename> is now configured into most kernels by
default. If the <filename>procfs</filename> is not in your kernel, you
will get a message such as: <literal>mount: fs type procfs not
supported by kernel</literal>. You will then have to recompile the
kernel and answer &ldquo;yes&rdquo; when asked for
<filename>procfs</filename> support.
</para>
</sect1>
<sect1 id="X-087-2-iface.binaries"><title>Installing the Binaries</title>
<indexterm><primary>installing</primary><secondary>network binaries</secondary></indexterm>
<indexterm><primary>binaries, installing</primary></indexterm>
<para>
If you are using one of the prepackaged Linux distributions, it will
contain the major networking applications and utilities along with a
coherent set of sample files. The only case in which you might have to
obtain and install new utilities is when you install a new kernel
release. As they occasionally involve changes in the kernel networking
layer, you will need to update the basic configuration tools. This
update at least involves recompiling, but sometimes you may also be
required to obtain the latest set of binaries. These binaries are
available at their official home site at <emphasis>ftp.inka.de/pub/comp/Linux/networking/NetTools/</emphasis>,
packaged in an archive called
<filename>net-tools-XXX.tar.gz</filename>, where
<filename>XXX</filename> is the version number. The release matching
Linux 2.0 is <filename>net-tools-1.45</filename>.
</para>
<para>
If you want to compile and install the standard TCP/IP network applications
yourself, you can obtain the sources from most Linux FTP servers. All modern
Linux distributions include a fairly comprehensive range of TCP/IP network
applications, such as World Wide Web browsers, <command>telnet</command> and
<command>ftp</command> programs, and other network applications, such as
<command>talk</command>. If you do find something that you do need to compile
yourself, the chances are good that it will compile under Linux from
source quite simply if you follow the instructions included in the source
package.
</para>
</sect1>
<sect1 id="X-087-2-iface.hostname"><title>Setting the Hostname</title>
<indexterm><primary>hostname</primary><secondary>setting</secondary></indexterm>
<indexterm><primary>configuring</primary><secondary>hostname</secondary></indexterm>
<indexterm><primary>setting</primary><secondary>hostname</secondary></indexterm>
<para>
Most, if not all, network applications rely on you to set the local
host's name to some reasonable value. This setting is usually made
during the boot procedure by executing the <command>hostname</command>
command. To set the hostname to <replaceable>name</replaceable>, enter:
<screen>
# <userinput>hostname</userinput> <replaceable>name</replaceable>
</screen>
</para>
<para>
It is common practice to use the unqualified hostname without
specifying the domain name. For instance, hosts at the Virtual Brewery
(described in <xref linkend="X-087-2-appendix.brewery">) might be
called <systemitem role="sitename">vale.vbrew.com</systemitem> or
<systemitem role="sitename">vlager.vbrew.com</systemitem>. These are
their official <emphasis>fully qualified domain names</emphasis>
(FQDNs). Their local hostnames would be the first component of the
name, such as <systemitem role="sitename">vale</systemitem>. However,
as the local hostname is frequently used to look up the host's IP
address, you have to make sure that the resolver library is able to
look up the host's IP address. This usually means that you have to
enter the name in <filename>/etc/hosts</filename>.
</para>
<para>
<indexterm><primary>domains</primary><secondary>names</secondary><tertiary>NIS versus DNS</tertiary></indexterm>
<indexterm><primary>domainname command</primary></indexterm>
<indexterm><primary>setting</primary><secondary>domain name</secondary></indexterm>
Some people suggest using the <command>domainname</command> command to
set the kernel's idea of a domain name to the remaining part of the
FQDN. This way you could combine the output from
<command>hostname</command> and <command>domainname</command> to get
the FQDN again. However, this is at best only half
correct. <command>domainname</command> is generally used to set the
host's NIS domain, which may be entirely different from the DNS domain
to which your host belongs. Instead, to ensure that the short form of
your hostname is resolvable with all recent versions of the
<command>hostname</command> command, either add it as an entry in your
local Domain Name Server or place the fully qualified domain name in
the <filename>/etc/hosts</filename> file. You may then use the
<parameter>--fqdn</parameter> argument to the
<command>hostname</command> command, and it will print the fully
qualifed domain name.
</para>
</sect1>
<sect1 id="X-087-2-iface.addresses"><title>Assigning IP Addresses</title>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>addresses</secondary><tertiary>assigning</tertiary></indexterm>
<indexterm><primary>addresses</primary><secondary>choosing (IP)</secondary></indexterm>
<indexterm><primary>choosing</primary><secondary>IP addresses</secondary></indexterm>
<indexterm><primary>private IP addresses</primary></indexterm>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>addresses</secondary><tertiary>private</tertiary></indexterm>
<indexterm><primary>networks</primary><secondary>IP address</secondary></indexterm>
<para>
If you configure the networking software on your host for standalone
operation (for instance, to be able to run the INN Netnews software),
you can safely skip this section, because the only IP address
you will need is for the loopback interface, which is always
<systemitem role="sitename">127.0.0.1</systemitem>.
</para>
<para>
Things are a little more complicated with real networks like Ethernets.
If you want to connect your host to an existing network, you have to ask
its administrators to give you an IP address on this network. When
setting up a network all by yourself, you have to assign IP addresses
yourself.
</para>
<para>
Hosts within a local network should usually share addresses from the
same logical IP network. Hence, you have to assign an IP network address.
If you have several physical networks, you have to either assign them
different network numbers, or use subnetting to split your IP address
range into several subnetworks. Subnetting will be revisited in the
next section, <xref linkend="X-087-2-create.subnets">.&rdquo;
</para>
<para>
When picking an IP network number, much depends on whether you intend
to get on the Internet in the near future. If so, you should obtain an
official IP address <emphasis>now</emphasis>. Ask your network service
provider to help you. If you want to obtain a network number, just in
case you might get on the Internet someday, request a Network Address
Application Form from <systemitem
role="emailaddr">hostmaster@internic.net</systemitem>, or your
country's own Network Information Center, if there is one.
</para>
<para>
If your network is not connected to the Internet and won't be in the
near future, you are free to choose any legal network address. Just
make sure no packets from your internal network escape to the real
Internet. To make sure no harm can be done even if packets
<emphasis>did</emphasis> escape, you should use one of the network
numbers reserved for private use. The Internet Assigned Numbers
Authority (IANA) has set aside several network numbers from classes A,
B, and C that you can use without registering. These addresses are
valid only within your private network and are not routed between real
Internet sites. The numbers are defined by RFC 1597 and are listed in
<xref linkend="X-087-2-issues.reserved.addresses"> in <xref
linkend="X-087-2-issues">. Note that the second and third blocks
contain 16 and 256 networks, respectively.
</para>
<para>
Picking your addresses from one of these network numbers is not
only useful for networks completely unconnected to the Internet; you can
still implement a slightly more restricted access using a single
host as a gateway. To your local network, the gateway is accessible by its
internal IP address, while the outside world knows it by an officially
registered address (assigned to you by your provider). We come back to
this concept in connection with the IP masquerade facility in
<xref linkend="X-087-2-ipmasq">.
</para>
<para>
Throughout the remainder of the book, we will assume that the brewery's
network manager uses a class B network number, say
<systemitem role="sitename">172.16.0.0</systemitem>. Of course, a class C
network number would definitely suffice to accommodate both the Brewery's and
the Winery's networks. We'll use a class B network here for the sake of
simplicity; it will make the subnetting examples in the next section
of this chapter a little more intuitive.
</para>
</sect1>
<sect1 id="X-087-2-create.subnets"><title>Creating Subnets</title>
<indexterm><primary>creating</primary><secondary>subnets</secondary></indexterm>
<indexterm><primary>subnets</primary><secondary>DNS, creating</secondary></indexterm>
<indexterm><primary>interfaces</primary><secondary>netmask</secondary></indexterm>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>netmask</secondary></indexterm>
<para>
To operate several Ethernets (or other networks, once a driver is
available), you have to split your network into subnets. Note that
subnetting is required only if you have more than one
<emphasis>broadcast network</emphasis>&mdash;point-to-point links
don't count. For instance, if you have one Ethernet, and one or more
SLIP links to the outside world, you don't need to subnet your
network. This is explained in more detail in <xref
linkend="X-087-2-slip">.
</para>
<para>
To accommodate the two Ethernets, the Brewery's network manager decides
to use 8 bits of the host part as additional subnet bits. This
leaves another 8 bits for the host part, allowing for 254 hosts on
each of the subnets. She then assigns subnet number 1 to the brewery,
and gives the winery number 2. Their respective network addresses are
thus <systemitem role="sitename">172.16.1.0</systemitem> and
<systemitem role="sitename">172.16.2.0</systemitem>. The subnet mask is
<systemitem role="sitename">255.255.255.0</systemitem>.
</para>
<para>
<systemitem role="sitename">vlager</systemitem>, which is the gateway between
the two networks, is assigned a host number of 1 on both of them, which gives
it the IP addresses <systemitem role="sitename">172.16.1.1</systemitem> and
<systemitem role="sitename">172.16.2.1</systemitem>, respectively.
</para>
<para>
Note that in this example we are using a class B network to keep things
simple, but a class C network would be more realistic. With the new networking
code, subnetting is not limited to byte boundaries, so even a class C
network may be split into several subnets. For instance, you could use two
bits of the host part for the netmask, giving you 4 possible subnets
with 64 hosts on each.<footnote id="X-087-2-FNTC02"><para>
The first number on each subnet is the subnetwork address, and the last number
on each subnet is reserved as the broadcast address, so it's actually 62 hosts
per subnet.
</para>
</footnote>
</para>
</sect1>
<sect1 id="X-087-2-iface.simple-resolv"><title>Writing hosts and networks Files</title>
<indexterm><primary>configuring</primary><secondary>hostname</secondary><tertiary>resolution</tertiary></indexterm>
<indexterm><primary>hosts file</primary></indexterm>
<indexterm><primary sortas="etc/hosts file">/etc/hosts file</primary></indexterm>
<indexterm><primary>hostname</primary><secondary>resolution</secondary></indexterm>
<indexterm><primary>networks</primary><secondary>names of</secondary></indexterm>
<indexterm><primary>hosts file</primary></indexterm>
<para>
After you have subnetted your network, you should prepare for some simple
sort of hostname resolution using the <filename>/etc/hosts</filename> file.
If you are not going to use DNS or NIS for address resolution, you have to put
all hosts in the <filename>hosts</filename> file.
</para>
<para>
Even if you want to run DNS or NIS during normal operation, you should
have some subset of all hostnames in
<filename>/etc/hosts</filename>. You should have some sort of name
resolution, even when no network interfaces are running, for example,
during boot time. This is not only a matter of convenience, but it
allows you to use symbolic hostnames in your network
<filename>rc</filename> scripts. Thus, when changing IP addresses, you
only have to copy an updated <filename>hosts</filename> file to all
machines and reboot, rather than edit a large number of
<filename>rc</filename> files separately. Usually you put all local
hostnames and addresses in <filename>hosts</filename>, adding those of
any gateways and NIS servers used.<footnote id="X-087-2-FNTC03"><para>
You need the address of an NIS server only if you use Peter Eriksson's
NYS. Other NIS implementations locate their servers only at runtime by
using <command>ypbind</command>.
</para>
</footnote>
</para>
<para>
You should make sure your resolver only uses information from the
<filename>hosts</filename> file during initial testing. Sample files
that come with your DNS or NIS software may produce strange
results. To make all applications use <filename>/etc/hosts</filename>
exclusively when looking up the IP address of a host, you have to edit
the <filename>/etc/host.conf</filename> file. Comment out any lines
that begin with the keyword <systemitem
role="keyword">order</systemitem> by preceding them with a hash sign,
and insert the line:
<screen>
order hosts
</screen>
</para>
<para>
The configuration of the resolver library is covered in detail in
<xref linkend="X-087-2-resolv">.
</para>
<para>
The <filename>hosts</filename> file contains one entry per line, consisting
of an IP address, a hostname, and an optional list of aliases for the
hostname. The fields are separated by spaces or tabs, and the address
field must begin in the first column. Anything following a hash sign (#) is
regarded as a comment and is ignored.
</para>
<para>
Hostnames can be either fully qualified or relative to the local domain.
For <systemitem role="sitename">vale</systemitem>, you would usually enter the
fully qualified name, <systemitem role="sitename">vale.vbrew.com</systemitem>,
and <systemitem role="sitename">vale</systemitem> by itself in the
<filename>hosts</filename> file, so that it is known by both its official name
and the shorter local name.
</para>
<para>
This is an example how a <filename>hosts</filename> file at the Virtual
Brewery might look. Two special names are included,
<systemitem role="sitename">vlager-if1</systemitem> and
<systemitem role="sitename">vlager-if2</systemitem>, which give the addresses
for both interfaces used on <systemitem role="sitename">vlager</systemitem>:
</para>
<para>
<screen>
#
# Hosts file for Virtual Brewery/Virtual Winery
#
# IP FQDN aliases
#
127.0.0.1 localhost
#
172.16.1.1 vlager.vbrew.com vlager vlager-if1
172.16.1.2 vstout.vbrew.com vstout
172.16.1.3 vale.vbrew.com vale
#
172.16.2.1 vlager-if2
172.16.2.2 vbeaujolais.vbrew.com vbeaujolais
172.16.2.3 vbardolino.vbrew.com vbardolino
172.16.2.4 vchianti.vbrew.com vchianti
</screen>
</para>
<para>
<indexterm><primary>networks file</primary></indexterm>
<indexterm><primary sortas="etc/networks file">/etc/networks file</primary></indexterm>
Just as with a host's IP address, you should sometimes use a symbolic
name for network numbers, too. Therefore, the
<filename>hosts</filename> file has a companion called
<filename>/etc/networks</filename> that maps network names to network
numbers, and vice versa. At the Virtual Brewery, we might install a
<filename>networks</filename> file like this:<footnote
id="X-087-2-FNTC04"><para> Note that names in
<filename>networks</filename> must not collide with hostnames from the
<filename>hosts</filename> file, or else some programs may produce
strange results.
</para>
</footnote>
<screen>
# /etc/networks for the Virtual Brewery
brew-net 172.16.1.0
wine-net 172.16.2.0
</screen>
</para>
</sect1>
<sect1 id="X-087-2-iface.interface"><title>Interface Configuration for IP</title>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>interface</secondary><tertiary>configuration</tertiary></indexterm>
<indexterm><primary>interfaces</primary><secondary>configuration of</secondary></indexterm>
<indexterm><primary>configuring</primary><secondary>networks</secondary><tertiary>interfaces</tertiary></indexterm>
<indexterm><primary>ifconfig command</primary></indexterm>
<para>
After setting up your hardware as explained in <xref
linkend="X-087-2-serial">, you have to make these devices known to the
kernel networking software. A couple of commands are used to configure
the network interfaces and initialize the routing table. These tasks
are usually performed from the network initialization script each time
you boot the system. The basic tools for this process are called
<command>ifconfig</command> (where &ldquo;if&thinsp;&rdquo; stands for
interface) and <command>route</command>.
</para>
<para>
<command>ifconfig</command> is used to make an interface accessible to
the kernel networking layer. This involves the assignment of an IP
address and other parameters, and activation of the interface, also
known as &ldquo;bringing up&rdquo; the interface. Being active here
means that the kernel will send and receive IP datagrams through the
interface. The simplest way to invoke it is with:
<screen>
ifconfig <replaceable>interface</replaceable> <replaceable>ip-address</replaceable>
</screen>
</para>
<para>
This command assigns <replaceable>ip-address</replaceable> to
<replaceable>interface</replaceable> and activates it. All other
parameters are set to default values. For instance, the default
network mask is derived from the network class of the IP address, such
as <systemitem role="sitename">255.255.0.0</systemitem> for a class B
address. <command>ifconfig</command> is described in detail in the
section <xref linkend="X-087-2-iface.ifconfig">.&rdquo;
</para>
<indexterm><primary>route command</primary></indexterm>
<para>
<command>route</command> allows you to add or remove routes from the kernel
routing table. It can be invoked as:
<screen>
route [add|del] [-net|-host] <replaceable>target</replaceable> [<replaceable>if</replaceable>]
</screen>
</para>
<para>
The <option>add</option> and <option>del</option> arguments determine
whether to add or delete the route to
<replaceable>target</replaceable>. The <option>-net</option> and
<option>-host</option> arguments tell the route command whether the
target is a network or a host (a host is assumed if you don't
specify). The <option>if</option> argument is again optional, and
allows you to specify to which network interface the route should be
directed&mdash;the Linux kernel makes a sensible guess if you don't
supply this information. This topic will be explained in more detail
in succeeding sections.
</para>
<sect2 id="X-087-2-iface.interface.loopback"><title>The Loopback Interface</title>
<indexterm><primary>configuring</primary><secondary>loopback interface device</secondary></indexterm>
<indexterm><primary>loopback</primary><secondary>interface device</secondary><tertiary>configuring</tertiary></indexterm>
<indexterm><primary>interfaces</primary><secondary>loopback</secondary></indexterm>
<indexterm><primary>lo (loopback interface)</primary></indexterm>
<para>
The very first interface to be activated is the loopback interface:
<screen>
# <userinput>ifconfig lo 127.0.0.1</userinput>
</screen>
</para>
<para>
<indexterm><primary>localhost (dummy hostname)</primary></indexterm>
Occasionally, you will see the dummy hostname
<systemitem role="sitename">localhost</systemitem> being used instead of the
IP address. <command>ifconfig</command> will look up the name in the
<filename>hosts</filename> file, where an entry should declare
it as the hostname for <systemitem role="sitename">127.0.0.1</systemitem>:
<screen>
# Sample /etc/hosts entry for localhost
localhost 127.0.0.1
</screen>
</para>
<para>
<indexterm><primary>checking</primary><secondary>network</secondary><tertiary>interface</tertiary></indexterm>
To view the configuration of an interface, you invoke
<command>ifconfig</command>, giving it only the interface name as argument:
<screen>
$ <userinput>ifconfig lo</userinput>
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
Collisions:0
</screen>
</para>
<para>
As you can see, the loopback interface has been assigned a netmask
of <systemitem role="sitename">255.0.0.0</systemitem>, since
<systemitem role="sitename">127.0.0.1</systemitem> is a class A address.
</para>
<para>
Now you can almost start playing with your mini-network. What is still
missing is an entry in the routing table that tells IP that it may use
this interface as a route to destination <systemitem
role="sitename">127.0.0.1</systemitem>. This is accomplished by using:
<screen>
# route add 127.0.0.1
</screen>
</para>
<para>
Again, you can use <systemitem role="sitename">localhost</systemitem> instead
of the IP address, provided you've entered it into your
<filename>/etc/hosts</filename>.
</para>
<para>
<indexterm><primary>testing</primary><secondary>network configuration</secondary></indexterm>
<indexterm><primary>checking</primary><secondary>network</secondary><tertiary>configuration</tertiary></indexterm>
<indexterm><primary>checking</primary><secondary>reachabilty</secondary></indexterm>
<indexterm><primary>reaching a host</primary></indexterm>
<indexterm><primary>round-trip time (IP)</primary></indexterm>
<indexterm><primary>ping command</primary></indexterm>
Next, you should check that everything works fine, for example by using
<command>ping</command>. <command>ping</command> is the networking equivalent
of a sonar device.<footnote id="X-087-2-FNTC05"><para>
Anyone remember Pink Floyd's &ldquo;Echoes&rdquo;?
</para>
</footnote> The command is used to verify that a given address is
actually reachable, and to measure the delay that occurs when sending
a datagram to it and back again. The time required for this process is
often referred to as the &ldquo;round-trip time&rdquo;:
</para>
<para>
<screen>
# <userinput>ping localhost</userinput>
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.4 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.4 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.4 ms
^C
--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.4/0.4 ms
#
</screen>
</para>
<para>
When you invoke <command>ping</command> as shown here, it will
continue emitting packets forever, unless interrupted by the user. The
<literal>^C</literal> marks the place where we pressed Ctrl-C.
</para>
<para>
The previous example shows that packets for <systemitem
role="sitename">127.0.0.1</systemitem> are properly delivered and a
reply is returned to <command>ping</command> almost instantaneously.
This shows that you have successfully set up your first network
interface.
</para>
<para>
<indexterm><primary>Network Unreachable error message</primary></indexterm>
<indexterm><primary>networks</primary><secondary>unreachable</secondary></indexterm>
If the output you get from <command>ping</command> does not resemble
that shown in the previous example, you are in trouble. Check any
errors if they indicate that some file hasn't been installed
properly. Check that the <command>ifconfig</command> and
<command>route</command> binaries you use are compatible with the
kernel release you run, and above all, that the kernel has been
compiled with networking enabled (you see this from the presence of
the <filename>/proc/net</filename> directory). If you get an error
message saying &ldquo;Network unreachable,&rdquo; you probably got the
<command>route</command> command wrong. Make sure you use the same
address you gave to <command>ifconfig</command>.
</para>
<para>
<indexterm><primary>networks</primary><secondary>initialization scripts</secondary></indexterm>
The steps previously described are enough to use networking
applications on a standalone host. After adding the lines mentioned
earlier to your network initialization script and making sure it will
be executed at boot time, you may reboot your machine and try out
various applications. For instance, <command>telnet
localhost</command> should establish a <command>telnet</command>
connection to your host, giving you a <literal>login:</literal>
prompt.
</para>
<para>
However, the loopback interface is useful not only as an example in
networking books, or as a test bed during development, but is actually
used by some applications during normal operation.<footnote
id="X-087-2-FNTC06"><para> For example, all applications based on RPC
use the loopback interface to register themselves with the
<command>portmapper</command> daemon at startup. These applications
include NIS and NFS.
</para>
</footnote>
Therefore, you always have to configure it, regardless of whether your machine
is attached to a network or not.
</para>
</sect2>
<sect2 id="X-087-2-iface.interface.ethernet"><title>Ethernet Interfaces</title>
<indexterm><primary>configuring</primary><secondary>Ethernet</secondary></indexterm>
<indexterm><primary>Ethernet</primary><secondary>configurating interface</secondary></indexterm>
<indexterm><primary>interfaces</primary><secondary>Ethernet</secondary></indexterm>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>netmask</secondary></indexterm>
<indexterm><primary>interfaces</primary><secondary>netmask</secondary></indexterm>
<indexterm><primary>eth0 (Ethernet interface)</primary></indexterm>
<indexterm><primary>addresses</primary><secondary>broadcast</secondary></indexterm>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>broadcast address</secondary></indexterm>
<para>
Configuring an Ethernet interface is pretty much the same as the
loopback interface; it just requires a few more parameters when you are
using subnetting.
</para>
<indexterm><primary>ifconfig command</primary></indexterm>
<para>
At the Virtual Brewery, we have subnetted the IP network, which was
originally a class B network, into class C subnetworks. To make the
interface recognize this, the <command>ifconfig</command> incantation
would look like this:
<screen>
# <userinput>ifconfig eth0 vstout netmask 255.255.255.0</userinput>
</screen>
</para>
<para>
This command assigns the <filename>eth0</filename> interface the IP
address of <systemitem role="sitename">vstout</systemitem>
(<systemitem role="sitename">172.16.1.2</systemitem>). If we omitted
the netmask, <command>ifconfig</command> would deduce the netmask from
the IP network class, which would result in an incorrect netmask of
<systemitem role="sitename">255.255.0.0</systemitem>. Now a quick
check shows:
<screen>
# <userinput>ifconfig eth0</userinput>
eth0 Link encap 10Mps Ethernet HWaddr 00:00:C0:90:B3:42
inet addr 172.16.1.2 Bcast 172.16.1.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 1
RX packets 0 errors 0 dropped 0 overrun 0
TX packets 0 errors 0 dropped 0 overrun 0
</screen>
</para>
<para>
You can see that <command>ifconfig</command> automatically sets the broadcast
address (the <systemitem role="keyword">Bcast</systemitem> field) to the
usual value, which is the host's network number with all the host bits set.
Also, the maximum transmission unit (the maximum size of IP datagrams the
kernel will generate for this interface) has been set to the maximum size of
Ethernet packets: 1,500 bytes. The defaults are usually what you will use, but
all these values can be overidden if required, with special options that will
be described under <xref linkend="X-087-2-iface.ifconfig">&rdquo;.
</para>
<para>
<indexterm><primary>route command</primary></indexterm>
Just as for the loopback interface, you now have to install a routing
entry that informs the kernel about the network that can be reached
through <filename>eth0</filename>. For the Virtual Brewery, you might invoke
<command>route</command> as:
<screen>
# <userinput>route add -net 172.16.1.0</userinput>
</screen>
</para>
<para>
At first this looks a little like magic, because it's not really
clear how <command>route</command> detects which interface to route through.
However, the trick is rather simple: the kernel checks all interfaces
that have been configured so far and compares the destination address
(<systemitem role="sitename">172.16.1.0</systemitem> in this case) to the
network part of the interface address (that is, the bitwise AND of the
interface address and the netmask). The only interface that matches is
<filename>eth0</filename>.
</para>
<para>
Now, what's that <option>&ndash;net</option> option for? This is used
because <command>route</command> can handle both routes to networks
and routes to single hosts (as you saw before with <systemitem
role="sitename">localhost</systemitem>). When given an address in
dotted quad notation, <command>route</command> attempts to guess
whether it is a network or a hostname by looking at the host part
bits. If the address's host part is zero, <command>route</command>
assumes it denotes a network; otherwise, <command>route</command>
takes it as a host address. Therefore, <command>route</command> would
think that <systemitem role="sitename">172.16.1.0</systemitem> is a
host address rather than a network number, because it cannot know that
we use subnetting. We have to tell <command>route</command> explicitly
that it denotes a network, so we give it the
<option>&ndash;net</option> flag.
</para>
<para>
Of course, the <command>route</command> command is a little tedious to
type, and it's prone to spelling mistakes. A more convenient approach
is to use the network names we defined in
<filename>/etc/networks</filename>. This approach makes the command
much more readable; even the <option>&ndash;net</option> flag can be
omitted because <command>route</command> knows that <systemitem
role="sitename">172.16.1.0</systemitem> denotes a network:
<screen>
# <userinput>route add brew-net</userinput>
</screen>
</para>
<para>
<indexterm><primary>testing</primary><secondary>network configuration</secondary></indexterm>
<indexterm><primary>checking</primary><secondary>network</secondary><tertiary>configuration</tertiary></indexterm>
<indexterm><primary>checking</primary><secondary>reachabilty</secondary></indexterm>
Now that you've finished the basic configuration steps, we want to
make sure that your Ethernet interface is indeed running
happily. Choose a host from your Ethernet, for instance <systemitem
role="sitename">vlager</systemitem>, and type:
<screen>
# <userinput>ping vlager</userinput>
PING vlager: 64 byte packets
64 bytes from 172.16.1.1: icmp_seq=0. time=11. ms
64 bytes from 172.16.1.1: icmp_seq=1. time=7. ms
64 bytes from 172.16.1.1: icmp_seq=2. time=12. ms
64 bytes from 172.16.1.1: icmp_seq=3. time=3. ms
^C
----vstout.vbrew.com PING Statistics----
4 packets transmitted, 4 packets received, 0
round-trip (ms) min/avg/max = 3/8/12
</screen>
</para>
<para>
<indexterm><primary>netstat command</primary></indexterm>
If you don't see similar output, something is broken. If you encounter
unusual packet loss rates, this hints at a hardware problem, like bad
or missing terminators. If you don't receive any replies at all, you
should check the interface configuration with
<command>netstat</command> described later in <xref
linkend="X-087-2-iface.netstat">&rdquo;. The packet statistics displayed by
<command>ifconfig</command> should tell you whether any packets have
been sent out on the interface at all. If you have access to the
remote host too, you should go over to that machine and check the
interface statistics. This way you can determine exactly where the
packets got dropped. In addition, you should display the routing
information with <command>route</command> to see if both hosts have
the correct routing entry. <command>route</command> prints out the
complete kernel routing table when invoked without any arguments
(<option>&ndash;n</option> just makes it print addresses as dotted
quad instead of using the hostname):
<indexterm><primary>IP (Internet Protocol)</primary><secondary>routing</secondary><tertiary>table</tertiary></indexterm>
<indexterm><primary>displaying</primary><secondary>IP routing table</secondary></indexterm>
<indexterm><primary>checking</primary><secondary>IP routing table</secondary></indexterm>
<indexterm><primary>route command</primary></indexterm>
<INDEXTERM><PRIMARY>IP (Internet Protocol)</PRIMARY><SECONDARY>routing</SECONDARY><TERTIARY>table</TERTIARY></INDEXTERM>
<screen>
# <userinput>route -n</userinput>
Kernel routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
127.0.0.1 * 255.255.255.255 UH 1 0 112 lo
172.16.1.0 * 255.255.255.0 U 1 0 10 eth0
</screen>
</para>
<para>
The detailed meaning of these fields is explained later in <xref
linkend="X-087-2-iface.netstat">." The <systemitem
role="keyword">Flags</systemitem> column contains a list of flags set
for each interface. <systemitem role="keyword">U</systemitem> is
always set for active interfaces, and <systemitem
role="keyword">H</systemitem> says the destination address denotes a
host. If the <systemitem role="keyword">H</systemitem> flag is set for
a route that you meant to be a network route, you have to reissue the
<command>route</command> command with the <option>&ndash;net</option>
option. To check whether a route you have entered is used at all,
check to see if the <systemitem role="keyword">Use</systemitem> field
in the second to last column increases between two invocations of
<command>ping</command>.
</para>
</sect2>
<sect2 id="X-087-2-iface.interface.gateway"><title>Routing Through a Gateway</title>
<indexterm><primary>routing</primary><secondary>IP</secondary><tertiary>gateways</tertiary></indexterm>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>routing</secondary></indexterm>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>gateways</secondary></indexterm>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>subnets</secondary></indexterm>
<indexterm><primary>gateways</primary><secondary>routing networks through</secondary></indexterm>
<para>
In the previous section, we covered only the case of setting up a host
on a single Ethernet. Quite frequently, however, one encounters
networks connected to one another by gateways. These gateways may
simply link two or more Ethernets, but may also provide a link to the
outside world, such as the Internet. In order to use a gateway, you
have to provide additional routing information to the networking
layer.
</para>
<para>
The Ethernets of the Virtual Brewery and the Virtual Winery are linked
through such a gateway, namely the host <systemitem
role="sitename">vlager</systemitem>. Assuming that <systemitem
role="sitename">vlager</systemitem> has already been configured, we
just have to add another entry to <systemitem
role="sitename">vstout</systemitem>'s routing table that tells the
kernel it can reach all hosts on the Winery's network through
<systemitem role="sitename">vlager</systemitem>. The appropriate
incantation of <command>route</command> is shown below; the
<systemitem role="keyword">gw</systemitem> keyword tells it that the
next argument denotes a gateway:
</para>
<para>
<screen>
# <userinput>route add wine-net gw vlager</userinput>
</screen>
</para>
<para>
Of course, any host on the Winery network you wish to talk to must have
a routing entry for the Brewery's network. Otherwise you would only be able
to send data to the Winery network from the Brewery network, but the hosts on
the Winery would be unable to reply.
</para>
<para>
This example describes only a gateway that switches packets between
two isolated Ethernets. Now assume that <systemitem
role="sitename">vlager</systemitem> also has a connection to the
Internet (say, through an additional SLIP link). Then we would want
datagrams to <emphasis>any</emphasis> destination network other than
the Brewery to be handed to <systemitem
role="sitename">vlager</systemitem>. This action can be accomplished
by making it the default gateway for <systemitem
role="sitename">vstout</systemitem>:
<screen>
# <userinput>route add default gw vlager</userinput>
</screen>
</para>
<para>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>default route</secondary></indexterm>
<indexterm><primary>route, default</primary></indexterm>
The network name <systemitem role="sitename">default</systemitem> is a shorthand
for <systemitem role="sitename">0.0.0.0</systemitem>, which denotes the default
route. The default route matches every destination and will be used if there
is no more specific route that matches. You do not have to add this name to
<filename>/etc/networks</filename> because it is built into
<command>route</command>.
</para>
<para>
If you see high packet loss rates when pinging a host behind one or more
gateways, this may hint at a very congested network. Packet loss is not so
much due to technical deficiencies as to temporary excess loads on
forwarding hosts, which makes them delay or even drop incoming datagrams.
</para>
</sect2>
<sect2 id="X-087-2-iface.interface.gateway-conf"><title>Configuring a Gateway</title>
<indexterm><primary>configuring</primary><secondary>IP gateways</secondary></indexterm>
<indexterm><primary>gateways</primary><secondary>configuring</secondary></indexterm>
<para>
Configuring a machine to switch packets between two Ethernets is
pretty straightforward. Assume we're back at <systemitem
role="sitename">vlager</systemitem>, which is equipped with two
Ethernet cards, each connected to one of the two networks. All you
have to do is configure both interfaces separately, giving them their
respective IP addresses and matching routes, and that's it.
</para>
<para>
It is quite useful to add information on the two interfaces to the
<filename>hosts</filename> file as shown in the following example, so
we have handy names for them, too:
<screen>
172.16.1.1 vlager.vbrew.com vlager vlager-if1
172.16.2.1 vlager-if2
</screen>
</para>
<para>
The sequence of commands to set up the two interfaces is then:
<screen>
# <userinput>ifconfig eth0 vlager-if1</userinput>
# <userinput>route add brew-net</userinput>
# <userinput>ifconfig eth1 vlager-if2</userinput>
# <userinput>route add wine-net</userinput>
</screen>
</para>
<para>
If this sequence doesn't work, make sure your kernel has been compiled
with support for IP forwarding enabled. One good way to do this is to
ensure that the first number on the second line of
<filename>/proc/net/snmp</filename> is set to <literal>1</literal>.
</para>
</sect2>
<sect2 id="X-087-2-iface.interface.plip"><title>The PLIP Interface</title>
<indexterm><primary>configuring</primary><secondary>PLIP</secondary></indexterm>
<indexterm><primary>interfaces</primary><secondary>PLIP</secondary></indexterm>
<indexterm><primary>point-to-point link</primary></indexterm>
<indexterm><primary>PLIP (Parallel Line IP) protocol</primary><secondary>interface</secondary></indexterm>
<para>
A PLIP link used to connect two machines is a little different from an
Ethernet. PLIP links are an example of what are called
<emphasis>point-to-point</emphasis> links, meaning that there is a single
host at each end of the link. Networks like Ethernet are called
<emphasis>broadcast</emphasis> networks. Configuration of point-to-point links
is different because unlike broadcast networks, point-to-point links don't
support a network of their own.
</para>
<para>
PLIP provides very cheap and portable links between computers. As
an example, we'll consider the laptop computer of an employee at the Virtual
Brewery that is connected to <systemitem role="sitename">vlager</systemitem>
via PLIP. The laptop itself is called
<systemitem role="sitename">vlite</systemitem> and has only one parallel port.
At boot time, this port will be registered as <filename>plip1</filename>. To
activate the link, you have to configure the <filename>plip1</filename>
interface using the following commands:<footnote id="X-087-2-FNTC07"><para>
Note that <userinput>pointopoint</userinput> is not a typo. It's really spelled like
this.
</para>
</footnote>
<screen>
# <userinput>ifconfig plip1 vlite pointopoint vlager</userinput>
# <userinput>route add default gw vlager</userinput>
</screen>
</para>
<para>
The first command configures the interface, telling the kernel that this
is a point-to-point link, with the remote side having the address of
<systemitem role="sitename">vlager</systemitem>. The second installs the default
route, using <systemitem role="sitename">vlager</systemitem> as gateway. On
<systemitem role="sitename">vlager</systemitem>, a similar
<command>ifconfig</command> command is necessary to activate the link
(a <command>route</command> invocation is not needed):
<screen>
# <userinput>ifconfig plip1 vlager pointopoint vlite</userinput>
</screen>
</para>
<para>
Note that the <filename>plip1</filename> interface on <systemitem
role="sitename">vlager</systemitem> does not need a separate IP
address, but may also be given the address <systemitem
role="sitename">172.16.1.1</systemitem>. Point-to-point networks don't
support a network directly, so the interfaces don't require an address
on any supported network. The kernel uses the interface information in
the routing table to avoid any possible confusion.<footnote
id="X-087-2-FNTC08"><para> As a matter of caution, you should
configure a PLIP or SLIP link only after you have completely set up
the routing table entries for your Ethernets. With some older kernels,
your network route might otherwise end up pointing at the
point-to-point link.
</para>
</footnote>
</para>
<para>
<indexterm><primary>route command</primary></indexterm>
Now we have configured routing from the laptop to the Brewery's
network; what's still missing is a way to route from any of the
Brewery's hosts to <systemitem role="sitename">vlite</systemitem>. One
particularly cumbersome way is to add a specific route to every host's routing
table that names <systemitem role="sitename">vlager</systemitem> as a gateway
to <systemitem role="sitename">vlite</systemitem>:
<screen>
# <userinput>route add vlite gw vlager</userinput>
</screen>
</para>
<para>
<indexterm><primary>routing</primary><secondary>dynamic</secondary></indexterm>
<indexterm><primary>Routing Information Protocol (RIP)</primary></indexterm>
<INDEXTERM><PRIMARY>RIP (Routing Information Protocol)</PRIMARY></INDEXTERM>
<indexterm><primary>gated command</primary></indexterm>
<indexterm><primary>ARP (Address Resolution Protocol)</primary><secondary>proxy</secondary></indexterm>
<indexterm><primary>proxy ARP</primary></indexterm>
Dynamic routing offers a much better option for temporary routes. You
could use <command>gated</command>, a routing daemon, which you would
have to install on each host in the network in order to distribute
routing information dynamically. The easiest option, however, is to
use <emphasis>proxy ARP</emphasis> (Address Resolution Protocol).
With proxy ARP, <systemitem role="sitename">vlager</systemitem> will
respond to any ARP query for <systemitem
role="sitename">vlite</systemitem> by sending its own Ethernet
address. All packets for <systemitem
role="sitename">vlite</systemitem> will wind up at <systemitem
role="sitename">vlager</systemitem>, which then forwards them to the
laptop. We will come back to proxy ARP in the section <xref
linkend="X-087-2-iface.verify.arp">.&rdquo;
</para>
<para>
<indexterm><primary>plipconfig command</primary></indexterm>
Current <filename>net-tools</filename> releases contain a tool called
<command>plipconfig</command>, which allows you to set certain PLIP
timing parameters. The IRQ to be used for the printer port can be set using
the <command>ifconfig</command> command.
</para>
</sect2>
<sect2 id="X-087-2-iface.interface.slip"><title>The SLIP and PPP Interfaces</title>
<indexterm><primary>sl0 (SLIP interface)</primary></indexterm>
<indexterm><primary>ppp0 (PPP interface)</primary></indexterm>
<indexterm><primary>point-to-point link</primary></indexterm>
<indexterm><primary>configuring</primary><secondary>SLIP</secondary></indexterm>
<indexterm><primary>configuring</primary><secondary>PPP</secondary></indexterm>
<indexterm><primary>interfaces</primary><secondary>SLIP</secondary></indexterm>
<indexterm><primary>interfaces</primary><secondary>PPP</secondary></indexterm>
<indexterm><primary>SLIP (Serial Line IP) protocol</primary><secondary>interface</secondary></indexterm>
<indexterm><primary>PPP (Point-to-Point Protocol)</primary></indexterm>
<para>
Although SLIP and PPP links are only simple point-to-point links like
PLIP connections, there is much more to be said about them. Usually,
establishing a SLIP connection involves dialing up a remote site
through your modem and setting the serial line to SLIP mode. PPP is
used in a similar fashion. We discuss SLIP and PPP in detail in
<xref linkend="X-087-2-slip"> and <xref linkend="X-087-2-ppp">.
</para>
</sect2>
<sect2 id="X-087-2-iface.interface.dummy"><title>The Dummy Interface</title>
<indexterm><primary>dummy interface configuration</primary></indexterm>
<indexterm><primary>interfaces</primary><secondary>dummy</secondary></indexterm>
<indexterm><primary>standalone host</primary></indexterm>
<indexterm><primary>hosts</primary><secondary>standalone</secondary></indexterm>
<para>
The dummy interface is a little exotic, but rather useful
nevertheless. Its main benefit is with standalone hosts and machines
whose only IP network connection is a dialup link. In fact, the
latter are standalone hosts most of the time, too.
</para>
<para>
The dilemma with standalone hosts is that they only have a single
network device active, the loopback device, which is usually assigned
the address <systemitem role="sitename">127.0.0.1</systemitem>. On
some occasions, however, you must send data to the
&ldquo;official&rdquo; IP address of the local host. For instance,
consider the laptop <systemitem role="sitename">vlite</systemitem>,
which was disconnected from a network for the duration of this
example. An application on <systemitem
role="sitename">vlite</systemitem> may now want to send data to
another application on the same host. Looking up <systemitem
role="sitename">vlite</systemitem> in <filename>/etc/hosts</filename>
yields an IP address of <systemitem
role="sitename">172.16.1.65</systemitem>, so the application tries to
send to this address. As the loopback interface is currently the only
active interface on the machine, the kernel has no idea that
<systemitem role="sitename">172.16.1.65</systemitem> actually refers
to itself&thinsp;! Consequently, the kernel discards the datagram and returns
an error to the application.
</para>
<para>
This is where the dummy device steps in. It solves the dilemma by
simply serving as the alter ego of the loopback interface. In the
case of <systemitem role="sitename">vlite</systemitem>, you simply
give it the address <systemitem
role="sitename">172.16.1.65</systemitem> and add a host route pointing
to it. Every datagram for <systemitem
role="sitename">172.16.1.65</systemitem> is then delivered
locally. The proper invocation is:<footnote id="X-087-2-FNTC09"><para>
The dummy device is called <filename>dummy0</filename> if you have
loaded it as a module rather than choosing it as an inbuilt kernel
option. This is because you are able to load multiple modules and have
more than one dummy device.
</para>
</footnote>
<screen>
# <userinput>ifconfig dummy vlite</userinput>
# <userinput>route add vlite</userinput>
</screen>
</para>
</sect2>
<sect2 id="X-087-2-iface.interface.alias"><title>IP Alias</title>
<INDEXTERM><PRIMARY>IP (Internet Protocol)</PRIMARY><SECONDARY>alias configuration</SECONDARY></INDEXTERM>
<indexterm><primary>interfaces</primary><secondary>alias</secondary></indexterm>
<indexterm><primary>standalone host</primary></indexterm>
<indexterm><primary>hosts</primary><secondary>standalone</secondary></indexterm>
<indexterm><primary>hosts</primary><secondary>virtual</secondary></indexterm>
<para>
New kernels support a feature that can completely replace the dummy
interface and serve other useful functions. <emphasis>IP
Alias</emphasis> allows you to configure multiple IP addresses onto a
physical device. In the simplest case, you could replicate the function
of the dummy interface by configuring the host address as an alias
onto the loopback interface and completely avoid using the dummy
interface. In more complex uses, you could configure your host to look
like many different hosts, each with its own IP address. This
configuration is sometimes called &ldquo;Virtual Hosting,&rdquo;
although technically it is also used for a variety of other
techniques.<footnote id="X-087-2-FNTC10"><para> More correctly, using
IP aliasing is known as network layer virtual hosting. It is more
common in the WWW and STMP worlds to use application layer virtual
hosting, in which the same IP address is used for each virtual host,
but a different hostname is passed with each application layer
request. Services like FTP are not capable of operating in this way,
and they demand network layer virtual hosting.
</para>
</footnote>
</para>
<para>
To configure an alias for an interface, you must first ensure that
your kernel has been compiled with support for IP Alias (check that
you have a <filename>/proc/net/ip_alias</filename> file; if not, you
will have to recompile your kernel). Configuration of an IP alias is
virtually identical to configuring a real network device; you use a
special name to indicate it's an alias that you want. For example:
<screen>
# <userinput>ifconfig lo:0 172.16.1.1</userinput>
</screen>
This command would produce an alias for the loopback interface with
the address <literal>172.16.1.1</literal>. IP aliases are referred to
by appending :<replaceable>n</replaceable> to the actual
network device, in which &ldquo;n&rdquo; is an integer. In our example,
the network device we are creating the alias on is
<literal>lo</literal>, and we are creating an alias numbered zero for
it. This way, a single physical device may support a number of
aliases.
</para>
<para>
Each alias may be treated as though it is a separate device, and as
far as the kernel IP software is concerned, it will be; however, it
will be sharing its hardware with another interface.
</para>
</sect2>
</sect1>
<sect1 id="X-087-2-iface.ifconfig"><title>All About ifconfig</title>
<indexterm id="chtc.ifconfig.cmd" class="startofrange"><primary>ifconfig command</primary></indexterm>
<para>
There are many more parameters to <command>ifconfig</command> than we
have described so far. Its normal invocation is this:
<screen>
ifconfig <replaceable>interface</replaceable> [<replaceable>address</replaceable> [<replaceable>parameters</replaceable>]]
</screen>
</para>
<para>
<replaceable>interface</replaceable> is the interface name, and
<replaceable>address</replaceable> is the IP address to be assigned to the
interface. This may be either an IP address in dotted quad notation or a
name that <command>ifconfig</command> will look up in
<filename>/etc/hosts</filename>.
</para>
<para>
<indexterm><primary>displaying</primary><secondary>interface</secondary><tertiary>configuration</tertiary></indexterm>
If <command>ifconfig</command> is invoked with only the interface
name, it displays that interface's configuration. When invoked without
any parameters, it displays all interfaces you have configured so far;
a <option>&ndash;a</option> option forces it to show the inactive ones
as well. A sample invocation for the Ethernet interface
<filename>eth0</filename> may look like this:
<screen>
# <userinput>ifconfig eth0</userinput>
eth0 Link encap 10Mbps Ethernet HWaddr 00:00:C0:90:B3:42
inet addr 172.16.1.2 Bcast 172.16.1.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 0
RX packets 3136 errors 217 dropped 7 overrun 26
TX packets 1752 errors 25 dropped 0 overrun 0
</screen>
</para>
<para>
<indexterm><primary>Maximum Transmission Unit (MTU)</primary></indexterm>
<indexterm><primary>routing</primary><secondary>metric</secondary></indexterm>
The <literal>MTU</literal> and <literal>Metric</literal> fields show the
current MTU and metric value for that interface. The metric value is
traditionally used by some operating systems to compute the cost of a route.
Linux doesn't use this value yet, but defines it for compatibility,
nevertheless.
</para>
<para>
The <literal>RX</literal> and <literal>TX</literal> lines show how
many packets have been received or transmitted error free, how many
errors occurred, how many packets were dropped (probably because of
low memory), and how many were lost because of an overrun. Receiver
overruns usually occur when packets come in faster than the kernel can
service the last interrupt. The flag values printed by
<command>ifconfig</command> roughly correspond to the names of its
command-line options; they will be explained later.
</para>
<para>
The following is a list of parameters recognized by <command>ifconfig</command>
with the corresponding flag names. Options that simply turn on a feature also
allow it to be turned off again by preceding the option name by a
dash (&ndash;).
</para>
<variablelist>
<varlistentry><term><literal>up</literal></term>
<listitem><para>
This option makes an interface accessible to the IP layer. This option
is implied when an <replaceable>address</replaceable> is given on the
command line. It may also be used to reenable an interface that has
been taken down temporarily using the <literal>down</literal> option.
</para>
<para>
This option corresponds to the flags <option>UP</option> and
<option>RUNNING</option>.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>down</literal></term> <listitem><para>
This option marks an interface inaccessible to the IP layer. This
effectively disables any IP traffic through the interface. Note that
this option will also automatically delete all routing entries that
use this interface.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>netmask</literal> <replaceable>mask</replaceable></term>
<listitem><para>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>netmask</secondary></indexterm>
<indexterm><primary>interfaces</primary><secondary>netmask</secondary></indexterm>
This option assigns a subnet mask to be used by the interface. It may
be given as either a 32-bit hexadecimal number preceded by 0x, or as a
dotted quad of decimal numbers. While the dotted quad format is more
common, the hexadecimal representation is often easier to work
with. Netmasks are essentially binary, and it is easier to do
binary-to-hexadecimal than binary-to-decimal conversion.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>pointopoint</literal> <replaceable>address</replaceable></term>
<listitem><para>
<indexterm><primary>point-to-point link</primary></indexterm> This option is
used for point-to-point IP links that involve only two hosts. This option is
needed to configure SLIP or PLIP interfaces, for example. If a point-to-point address has been set, <command>ifconfig</command> displays
the <option>POINTOPOINT</option> flag.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>broadcast</literal>
<replaceable>address</replaceable></term>
<listitem><para>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>broadcast address</secondary></indexterm>
<indexterm><primary>broadcast address</primary></indexterm>
<indexterm><primary>addresses</primary><secondary>broadcast</secondary></indexterm>
The broadcast address is usually made up from the network number by
setting all bits of the host part. Some IP implementations (systems
derived from BSD 4.2, for instance) use a different scheme in which
all host part bits are cleared instead. The
<option>broadcast</option> option adapts to these strange
environments. If a broadcast address has been set, <command>ifconfig</command> displays the <option>BROADCAST</option> flag.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>irq</literal></term>
<listitem><para>
<indexterm><primary>setting</primary><secondary>IRQ</secondary></indexterm>
<indexterm><primary>IRQ (Interrupt Request)</primary><secondary>setting</secondary></indexterm>
This option allows you to set the IRQ line used by certain devices. This is
especially useful for PLIP, but may also be useful for certain Ethernet cards.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>metric</literal> <replaceable>number</replaceable></term>
<listitem><para>
<indexterm><primary>Routing Information Protocol (RIP)</primary></indexterm>
<INDEXTERM><PRIMARY>RIP (Routing Information Protocol)</PRIMARY></INDEXTERM>
<indexterm><primary>routing</primary><secondary>metric</secondary></indexterm>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>metric</secondary></indexterm>
This option may be used to assign a metric value to the routing table entry
created for the interface. This metric is used by the Routing Information
Protocol (RIP) to build routing tables for the
network.<footnote id="X-087-2-FNTC11"><para>
RIP chooses the optimal route to a given host based on the &ldquo;length&rdquo;
of the path. It is computed by summing up the individual metric values of each
host-to-host link. By default, a hop has length 1, but this may be any
positive integer less than 16. (A route length of 16 is equal to infinity.
Such routes are considered unusable.) The <option>metric</option> parameter
sets this hop cost, which is then broadcast by the routing daemon.
</para>
</footnote>
The default metric used by <command>ifconfig</command> is zero. If
you don't run a RIP daemon, you don't need this option at all; if you do, you
will rarely need to change the metric value.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>mtu</literal> <replaceable>bytes</replaceable></term>
<listitem><para>
<indexterm><primary>Maximum Transmission Unit (MTU)</primary></indexterm>
This sets the Maximum Transmission Unit, which is the maximum number of octets
the interface is able to handle in one transaction. For Ethernets, the MTU
defaults to 1,500 (the largest allowable size of an Ethernet packet); for SLIP
interfaces, it is 296. (There is no constraint on the MTU of SLIP links; this
value is a good compromise.)
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>arp</literal></term>
<listitem><para>
<indexterm><primary>ARP (Address Resolution Protocol)</primary><secondary>enabling/disabling</secondary></indexterm>
This is an option specific to broadcast networks such as Ethernets or packet
radio. It enables the use of the Address Resolution Protocol (ARP) to detect
the physical addresses of hosts attached to the network. For broadcast
networks, it is on by default. If ARP is disabled, <command>ifconfig</command> displays the <option>NOARP</option> flag.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>&ndash;arp</literal></term>
<listitem><para>
This option disables the use of ARP on this interface.
</para></listitem>
</varlistentry>
<varlistentry><term><literal>promisc</literal></term>
<listitem><para>
<indexterm><primary>Ethernet</primary><secondary>promiscuous mode</secondary></indexterm>
<indexterm><primary>security</primary><secondary>Ethernet</secondary></indexterm>
This option puts the interface in promiscuous mode. On a broadcast
network, this makes the interface receive all packets, regardless of
whether they were destined for this host or not. This allows network
traffic analysis using packet filters and such, also called
<emphasis>Ethernet snooping</emphasis>. Usually, this is a good
technique for hunting down network problems that are otherwise hard to
detect. Tools such as <command>tcpdump</command> rely on this.
</para>
<para>
On the other hand, this option allows attackers to do nasty things,
such as skim the traffic of your network for passwords. You can
protect against this type of attack by prohibiting just anyone from
plugging their computers into your Ethernet. You could also use
secure authentication protocols, such as Kerberos or the secure shell
login suite.<footnote id="X-087-2-FNTC12"><para> ssh can be obtained
from <systemitem role="sitename">ftp.cs.hut.fi</systemitem> in
<filename>/pub/ssh</filename>.
</para>
</footnote> This option corresponds to the <option>PROMISC</option> flag.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>&ndash;promisc</literal></term>
<listitem><para>
This option turns promiscuous mode off.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>allmulti</literal></term>
<listitem><para>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>multicast addresses</secondary></indexterm>
Multicast addresses are like Ethernet broadcast addresses, except that
instead of automatically including everybody, the only people who
receive packets sent to a multicast address are those programmed to
listen to it. This is useful for applications like Ethernet-based
videoconferencing or network audio, to which only those interested can
listen. Multicast addressing is supported by most, but not all,
Ethernet drivers. When this option is enabled, the interface receives
and passes multicast packets for processing. This option corresponds to the <option>ALLMULTI</option> flag.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>&ndash;allmulti</literal></term>
<listitem><para>
This option turns multicast addresses off.
</para>
</listitem>
</varlistentry>
</variablelist>
<indexterm class="endofrange" startref="chtc.ifconfig.cmd">
</sect1>
<sect1 id="X-087-2-iface.netstat"><title>The netstat Command</title>
<indexterm id="idx-commandnetstatcommand-1" class="startofrange"><primary>netstat command</primary></indexterm>
<para>
<command>netstat</command> is a useful tool for checking your network
configuration and activity. It is in fact a collection of several
tools lumped together. We discuss each of its functions in the
following sections.
</para>
<sect2 id="X-087-2-iface.netstat.-r"><title>Displaying the Routing Table</title>
<indexterm><primary>IP (Internet Protocol)</primary><secondary>routing</secondary><tertiary>table</tertiary></indexterm>
<indexterm><primary>checking</primary><secondary>routing table</secondary></indexterm>
<indexterm><primary>displaying</primary><secondary>IP routing table</secondary></indexterm>
<indexterm><primary>routing table</primary><secondary>displaying via netstat</secondary></indexterm>
<para>
When you invoke <command>netstat</command> with the
<option>&ndash;r</option> flag, it displays the kernel routing table
in the way we've been doing with <command>route</command>. On
<systemitem role="sitename">vstout</systemitem>, it produces:
<screen>
# <userinput>netstat -nr</userinput>
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
127.0.0.1 * 255.255.255.255 UH 0 0 0 lo
172.16.1.0 * 255.255.255.0 U 0 0 0 eth0
172.16.2.0 172.16.1.1 255.255.255.0 UG 0 0 0 eth0
</screen>
</para>
<para>
The <option>&ndash;n</option> option makes <command>netstat</command>
print addresses as dotted quad IP numbers rather than the symbolic
host and network names. This option is especially useful when you want
to avoid address lookups over the network (e.g., to a DNS or NIS
server).
</para>
<para>
The second column of <command>netstat</command>&thinsp;'s output shows
the gateway to which the routing entry points. If no gateway is used,
an asterisk is printed instead. The third column shows the
&ldquo;generality&rdquo; of the route, i.e., the network mask for this
route. When given an IP address to find a suitable route for, the
kernel steps through each of the routing table entries, taking the
bitwise AND of the address and the genmask before comparing it to the
target of the route.
</para>
<para>
The fourth column displays the following flags that describe the route:
<variablelist>
<varlistentry><term><literal>G</literal></term>
<listitem><para>
The route uses a gateway.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>U</literal></term>
<listitem><para>
The interface to be used is up.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>H</literal></term>
<listitem><para>
Only a single host can be reached through the route. For example, this is the
case for the loopback entry <systemitem role="sitename">127.0.0.1</systemitem>.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>D</literal></term> <listitem><para> This
route is dynamically created. It is set if the table entry has been
generated by a routing daemon like <command>gated</command> or by an
ICMP redirect message (see the section <xref
linkend="X-087-2-issues.icmp">&rdquo; in Chapter 2).
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>M</literal></term> <listitem><para> This
route is set if the table entry was modified by an ICMP redirect
message.
</para>
</listitem>
</varlistentry>
<varlistentry><term><literal>!</literal></term>
<listitem><para>
The route is a reject route and datagrams will be dropped.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
<indexterm><primary>irtt parameter</primary></indexterm>
<indexterm><primary>displaying</primary><secondary>irtt</secondary></indexterm>
The next three columns show the MSS, Window and irtt that will be
applied to TCP connections established via this route. The MSS is the
Maximum Segment Size and is the size of the largest datagram the
kernel will construct for transmission via this route. The Window is
the maximum amount of data the system will accept in a single burst
from a remote host. The acronym <literal>irtt</literal> stands for
&ldquo;initial round trip time.&rdquo; The TCP protocol ensures that
data is reliably delivered between hosts by retransmitting a datagram
if it has been lost. The TCP protocol keeps a running count of how
long it takes for a datagram to be delivered to the remote end, and an
acknowledgement to be received so that it knows how long to wait
before assuming a datagram needs to retransmitted; this process is
called the round-trip time. The initial round-trip time is the value
that the TCP protocol will use when a connection is first
established. For most network types, the default value is okay, but
for some slow networks, notably certain types of amateur packet radio
networks, the time is too short and causes unnecessary
retransmission. The <literal>irtt</literal> value can be set using the
<command>route</command> command. Values of zero in these fields mean
that the default is being used.
</para>
<para>
Finally, the last field displays the network interface that this route
will use.
</para>
</sect2>
<sect2 id="X-087-2-iface.netstat.-i"><title>Displaying Interface Statistics</title>
<indexterm><primary>displaying</primary><secondary>interface</secondary><tertiary>statistics</tertiary></indexterm>
<indexterm><primary>interfaces</primary><secondary>statistics, displaying</secondary></indexterm>
<indexterm><primary>checking</primary><secondary>network</secondary>
<tertiary>interface</tertiary></indexterm>
<para>
When invoked with the <option>&ndash;i</option> flag,
<command>netstat</command> displays statistics for the network
interfaces currently configured. If the <option>&ndash;a</option>
option is also given, it prints <emphasis>all</emphasis> interfaces
present in the kernel, not only those that have been configured
currently. On <systemitem role="sitename">vstout</systemitem>, the
output from <command>netstat</command> will look like this:
<screen>
# <userinput>netstat -i</userinput>
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags
lo 0 0 3185 0 0 0 3185 0 0 0 BLRU
eth0 1500 0 972633 17 20 120 628711 217 0 0 BRU
</screen>
</para>
<para>
The <literal>MTU</literal> and <literal>Met</literal> fields show the
current MTU and metric values for that interface. The
<literal>RX</literal> and <literal>TX</literal> columns show how many
packets have been received or transmitted error-free
(<literal>RX-OK</literal>/<literal>TX-OK</literal>) or damaged
(<literal>RX-ERR</literal>/<literal>TX-ERR</literal>); how many were
dropped (<literal>RX-DRP</literal>/<literal>TX-DRP</literal>); and how
many were lost because of an overrun
(<literal>RX-OVR</literal>/<literal>TX-OVR</literal>).
</para>
<para>
The last column shows the flags that have been set for this interface.
These characters are one-character versions of the long flag names
that are printed when you display the interface configuration with
<command>ifconfig</command>:
<variablelist>
<varlistentry><term><literal>B</literal></term>
<listitem><para>
A broadcast address has been set.
</para></listitem>
</varlistentry>
<varlistentry><term><literal>L</literal></term>
<listitem><para>
This interface is a loopback device.
</para></listitem>
</varlistentry>
<varlistentry><term><literal>M</literal></term>
<listitem><para>
All packets are received (promiscuous mode).
</para></listitem>
</varlistentry>
<varlistentry><term><literal>O</literal></term>
<listitem><para>
ARP is turned off for this interface.
</para></listitem>
</varlistentry>
<varlistentry><term><literal>P</literal></term>
<listitem><para>
This is a point-to-point connection.
</para></listitem>
</varlistentry>
<varlistentry><term><literal>R</literal></term>
<listitem><para>
Interface is running.
</para></listitem>
</varlistentry>
<varlistentry><term><literal>U</literal></term>
<listitem><para>
Interface is up.
</para></listitem>
</varlistentry>
</variablelist>
</para>
</sect2>
<sect2 id="X-087-2-iface.netstat.-t-u-x"><title>Displaying Connections</title>
<indexterm><primary>displaying</primary><secondary>active connections</secondary></indexterm>
<indexterm><primary>networks</primary><secondary>display connections</secondary></indexterm>
<indexterm><primary>checking</primary><secondary>network</secondary>
<tertiary>connections</tertiary></indexterm>
<indexterm><primary>checking</primary><secondary>TCP server activity</secondary></indexterm>
<INDEXTERM><PRIMARY>netstat command</PRIMARY><SECONDARY>displaying connections</SECONDARY></INDEXTERM>
<para>
<command>netstat</command> supports a set of options to display active
or passive sockets. The options <option>&ndash;t</option>,
<option>&ndash;u</option>, <option>&ndash;w</option>, and
<option>&ndash;x</option> show active TCP, UDP, RAW, or Unix socket
connections. If you provide the <option>&ndash;a</option> flag in
addition, sockets that are waiting for a connection (i.e., listening)
are displayed as well. This display will give you a list of all
servers that are currently running on your system.
</para>
<para>
Invoking <command>netstat -ta</command> on
<systemitem role="sitename">vlager</systemitem> produces this output:
<screen>
$ <userinput>netstat -ta</userinput>
Active Internet Connections
Proto Recv-Q Send-Q Local Address Foreign Address (State)
tcp 0 0 *:domain *:* LISTEN
tcp 0 0 *:time *:* LISTEN
tcp 0 0 *:smtp *:* LISTEN
tcp 0 0 vlager:smtp vstout:1040 ESTABLISHED
tcp 0 0 *:telnet *:* LISTEN
tcp 0 0 localhost:1046 vbardolino:telnet ESTABLISHED
tcp 0 0 *:chargen *:* LISTEN
tcp 0 0 *:daytime *:* LISTEN
tcp 0 0 *:discard *:* LISTEN
tcp 0 0 *:echo *:* LISTEN
tcp 0 0 *:shell *:* LISTEN
tcp 0 0 *:login *:* LISTEN
</screen>
</para>
<para>
This output shows most servers simply waiting for an incoming
connection. However, the fourth line shows an incoming SMTP connection
from <systemitem role="sitename">vstout</systemitem>, and the sixth
line tells you there is an outgoing <command>telnet</command>
connection to <systemitem
role="sitename">vbardolino</systemitem>.<footnote
id="X-087-2-FNTC13"><para> You can tell whether a connection is
outgoing from the port numbers. The port number shown for the
<emphasis>calling</emphasis> host will always be a simple integer. On
the host being called, a well-known service port will be in use for
which <command>netstat</command> uses the symbolic name such as
<literal>smtp</literal>, found in <filename>/etc/services</filename>.
</para>
</footnote>
</para>
<para>
Using the <option>&ndash;a</option> flag by itself will display all
sockets from all families.
</para>
<para>
<indexterm class="endofrange" startref="idx-commandnetstatcommand-1">
</para>
</sect2>
</sect1>
<sect1 id="X-087-2-iface.verify.arp"><title>Checking the ARP Tables</title>
<indexterm><primary>checking</primary><secondary>Ethernet interface</secondary></indexterm>
<indexterm><primary>checking</primary><secondary>ARP tables</secondary></indexterm>
<indexterm><primary>ARP (Address Resolution Protocol)</primary><secondary>display table</secondary></indexterm>
<indexterm><primary>displaying</primary><secondary>ARP table</secondary></indexterm>
<para>
On some occasions, it is useful to view or alter the contents of the
kernel's ARP tables, for example when you suspect a duplicate Internet
address is the cause for some intermittent network problem. The
<command>arp</command> tool was made for situations like this. Its
command-line options are:
<screen>
arp [-v] [-t <replaceable>hwtype</replaceable>] -a [<replaceable>hostname</replaceable>]
arp [-v] [-t <replaceable>hwtype</replaceable>] -s <replaceable>hostname</replaceable> <replaceable>hwaddr</replaceable>
arp [-v] -d <replaceable>hostname</replaceable> [<replaceable>hostname</replaceable>&hellip;]
</screen>
</para>
<para>
All <replaceable>hostname</replaceable> arguments may be either symbolic
hostnames or IP addresses in dotted quad notation.
</para>
<para>
The first invocation displays the ARP entry for the IP address or host
specified, or all hosts known if no <replaceable>hostname</replaceable> is
given. For example, invoking <command>arp</command> on
<systemitem role="sitename">vlager</systemitem> may yield:
<screen>
# <userinput>arp -a</userinput>
IP address HW type HW address
172.16.1.3 10Mbps Ethernet 00:00:C0:5A:42:C1
172.16.1.2 10Mbps Ethernet 00:00:C0:90:B3:42
172.16.2.4 10Mbps Ethernet 00:00:C0:04:69:AA
</screen>
</para>
<para>
which shows the Ethernet addresses of
<systemitem role="sitename">vlager</systemitem>,
<systemitem role="sitename">vstout</systemitem> and
<systemitem role="sitename">vale</systemitem>.
</para>
<para>
You can limit the display to the hardware type specified using the
<option>&ndash;t</option> option. This may be <systemitem
role="keyword">ether</systemitem>, <systemitem
role="keyword">ax25</systemitem>, or <systemitem
role="keyword">pronet</systemitem>, standing for 10 Mbps Ethernet;
AMPR AX.25, and IEEE 802.5 token ring equipment, respectively.
</para>
<para>
The <option>&ndash;s</option> option is used to permanently add
<replaceable>hostname</replaceable>'s Ethernet address to the ARP
tables. The <replaceable>hwaddr</replaceable> argument specifies the
hardware address, which is by default expected to be an Ethernet
address specified as six hexadecimal bytes separated by colons. You
may also set the hardware address for other types of hardware, using
the <option>&ndash;t</option> option.
</para>
<para>
For some reason, ARP queries for the remote host sometimes fail, for
instance when its ARP driver is buggy or there is another host in the
network that erroneously identifies itself with that host's IP
address; this problem requires you to manually add an IP address to
the ARP table. Hard-wiring IP addresses in the ARP table is also a
(very drastic) measure to protect yourself from hosts on your Ethernet
that pose as someone else.
</para>
<para>
Invoking <command>arp</command> using the <option>&ndash;d</option>
switch deletes all ARP entries relating to the given host. This switch
may be used to force the interface to re-attempt obtaining the
Ethernet address for the IP address in question. This is useful when a
misconfigured system has broadcasted wrong ARP information (of course,
you have to reconfigure the broken host first).
</para>
<para>
<indexterm><primary>point-to-point link</primary></indexterm>
<indexterm><primary>routing</primary><secondary>proxy ARP</secondary></indexterm>
<indexterm><primary>routing</primary><secondary>dynamic</secondary></indexterm>
<indexterm><primary>proxy ARP</primary></indexterm>
<indexterm><primary>ARP (Address Resolution Protocol)</primary><secondary>proxy</secondary></indexterm>
<indexterm><primary>SLIP (Serial Line IP) protocol</primary><secondary>routing</secondary></indexterm>
<indexterm><primary>PLIP (Parallel Line IP) protocol</primary><secondary>routing</secondary></indexterm>
<indexterm><primary>PPP (Point-to-Point Protocol)</primary><secondary>routing</secondary></indexterm>
The <option>&ndash;s</option> option may also be used to implement
<emphasis>proxy</emphasis> ARP. This is a special technique through
which a host, say <systemitem role="sitename">gate</systemitem>, acts
as a gateway to another host named <systemitem
role="sitename">fnord</systemitem> by pretending that both addresses
refer to the same host, namely <systemitem
role="sitename">gate</systemitem>. It does so by publishing an ARP
entry for <systemitem role="sitename">fnord</systemitem> that points
to its own Ethernet interface. Now when a host sends out an ARP query
for <systemitem role="sitename">fnord</systemitem>, <systemitem
role="sitename">gate</systemitem> will return a reply containing its
own Ethernet address. The querying host will then send all datagrams
to <systemitem role="sitename">gate</systemitem>, which dutifully
forwards them to <systemitem role="sitename">fnord</systemitem>.
</para>
<para>
These contortions may be necessary when you want to access <systemitem
role="sitename">fnord</systemitem> from a DOS machine with a broken
TCP implementation that doesn't understand routing too well. When you
use proxy ARP, it will appear to the DOS machine as if <systemitem
role="sitename">fnord</systemitem> was on the local subnet, so it
doesn't have to know about how to route through a gateway.
</para>
<para>
Another useful application of proxy ARP is when one of your hosts acts
as a gateway to some other host only temporarily, for instance,
through a dial-up link. In a previous example, we encountered the
laptop <systemitem role="sitename">vlite</systemitem>, which was
connected to <systemitem role="sitename">vlager</systemitem> through a
PLIP link from time to time. Of course, this application will work
only if the address of the host you want to provide proxy ARP for is
on the same IP subnet as your gateway. <systemitem
role="sitename">vstout</systemitem> could proxy ARP for any host on
the Brewery subnet (<systemitem
role="sitename">172.16.1.0</systemitem>), but never for a host on the
Winery subnet (<systemitem role="sitename">172.16.2.0</systemitem>).
</para>
<para>
The proper invocation to provide proxy ARP for <systemitem
role="sitename">fnord</systemitem> is given below; of course, the
given Ethernet address must be that of <systemitem
role="sitename">gate</systemitem>:
</para>
<para>
<screen>
# arp -s fnord 00:00:c0:a1:42:e0 pub
</screen>
</para>
<para>
The proxy ARP entry may be removed again by invoking:
<screen>
# arp -d fnord
</screen>
</para>
</sect1>
<indexterm class="endofrange" startref="chtc.tcpip.config.netwks">
</chapter>
View Git Blame Copy Permalink