%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                       Legal Notice                            %
%                                                               %
% This document is copyright (C) Olaf Kirch, okir@monad.swb.de  %
%                                                               %
% For copying conditions, please refer to the file COPYING.	%
%                                                               %
% The author is not liable for any damages, direct or indirect, %
% resulting from the use of information provided in this        %
% document.                                                     %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% When viewing this document with vi on an 80-columns screen,   %
% do a ':se nonumber' first.                                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%               S T A R T   O F   C H A P T E R                 %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Configuring TCP/IP Networking}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface}
In this chapter, we will go through all the steps necessary to setting
up TCP/IP networking on your machine. Starting with the assignment of
IP~addresses, we will slowly work our way through the configuration of
TCP/IP network interfaces, and introduce a few tools that come quite
handy when hunting down problems with your network installation.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{rc scripts@\file{rc} scripts}
\index{bootup sequence}
\index{initializing networking}
\index{network!booting}
\index{rc.inet@\file{rc.inet}}
\index{rc.inet@\file{rc.inet}}

Most of the tasks covered in this chapter you will generally have to
do only once. Afterwards, 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 \file{/etc/rc} scripts.


Commonly, the network-specific part of this procedure is contained
in a script called \file{rc.net} or \file{rc.inet}. Sometimes, you will
also see two scripts named \file{rc.inet1} and \file{rc.inet2}, where the
former initializes the kernel part of networking, while the latter
starts basic networking services and applications. Throughout
the following, I will adhere to the latter concept.


Below, I will discuss the actions performed by \file{rc.inet1}, 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 \file{rc.inet1} with your commands, make
sure \file{rc.inet1} is executed at startup time, and reboot your
machine.  The networking \file{rc} scripts that come along with your
favorite \linux{} distribution should give you a good example.


\section{Setting up the \file{proc} Filesystem}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.procfs}
\index{mounting!the proc filesystem@the \file{proc} filesystem}
\index{proc filesystem@\file{proc} filesystem}

Some of the configuration tools of the Net-2 release rely on
the \file{proc} filesystem for communicating with the kernel. This
is an interface that permits access to kernel run-time 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 \file{loadavg} file that contains the system load
average, or \file{meminfo}, which shows current core memory and swap
usage.


\index{/proc/net@\file{/proc/net}}
To this, the networking code adds the \file{net} 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.


\index{fstab@\file{fstab}}
The \file{proc} filesystem (or \file{procfs} as it is also known)
is usually mounted on \file{/proc} at system boot time. The best 
method is to add the following line to \file{/etc/fstab}:

\begin{tscreen}
\begin{verbatim}
# procfs mont point:
none		/proc		proc	defaults
\end{verbatim}
\end{tscreen}

\noindent
and execute ``\term{mount /proc}'' from your \file{/etc/rc} script.


The \file{procfs} is nowadays configured into most kernels by default.
If the \file{procfs} is not in your kernel, you will get a message like
``\term{mount: fs type procfs not supported by kernel}''. You will then
have to recompile the kernel and answer ``yes'' when asked for
\file{procfs} support.


\section{Installing the Binaries}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.binaries}
\index{installing!network binaries}

If you are using one of the pre-packaged \linux{} distributions, it
will most probably contain the major networking applications and
utilities along with a coherent set of sample files.  The only case
where 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 at least involves recompiling, but sometimes
you may also be required to obtain the latest set of binaries.  These
are usually distributed along with the kernel, packaged in an archive
called \file{net-\var{XXX}.tar.gz}, where \var{XXX}\/ is the version
number. The release matching \linux{}~1.0 is 0.32b, the latest
kernel as of this writing (1.1.12 and later) require 0.32d.


If you want to compile and install the standard TCP/IP network
applications yourself, you can obtain the sources from most \linux{}
FTP servers.  These are more or less heavily patched versions of
programs from Net-BSD or other sources.  Other applications, such as
\prog{Xmosaic}, \prog{xarchie}, or Gopher and IRC clients must be
obtained separately.  Most of them compile out of the box if you
follow the instructions.


\index{obtaining the source code}
\index{FTP, location of \linux{} code}
\index{Net-2e}
\index{Net-3}
\index{Net-BSD}
The official FTP site for Net-3 is \host{sunacm.swan.ac.uk}, mirrored
by \host{sunsite.unc.edu} below \file{system/Network/sunacm}.  The
latest Net-2e patch kit and binaries are available from
\host{ftp.aris.com}.  Matthias Urlichs' BSD-derived networking code
can be gotten from \host{ftp.ira.uka.de} in
\file{/pub/system/linux/netbsd}.


\section{Another Example}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.brewery}
\index{Virtual Brewery}
\index{Brewery, Virtual}

For the remainder of this book, let me introduce a new example
that is less complex than Groucho Marx University, and may be closer
to the tasks you will actually encounter. Consider the Virtual
Brewery, a small company that brews, as the name indicates, virtual
beer. To manage their business more efficiently, the virtual brewers
want to network their computers, which all happen to be PCs running
a bright and shiny \linux{} 1.0.


On the same floor, just across the hall, there's the Virtual Winery,
who work closely with the brewery.  They run an Ethernet of their own.
Quite naturally, the two companies want to link their networks once
they are operational.  As a first step, they want to set up a gateway
host that forwards datagrams between the two subnets. Later, they also
want to have a UUCP link to the outside world, through which they
exchange mail and news.  In the long run, the also want to set up a
SLIP connection to connect to the Internet occasionally.



\section{Setting the Hostname}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.hostname}
\index{hostname!setting}
\index{configuring!hostname}
\index{setting!hostname}

Most, if not all, network applications rely on the local host's
name having been set to some reasonable value. This is usually
done during the boot procedure by executing the \prog{hostname}
command. To set the hostname to \var{name}, it is invoked as 


\begin{tscreen}
 \# hostname \var{name}
\end{tscreen}


It is common practice to use the unqualified hostname without any
domain name for this. For instance, hosts at the Virtual Brewery might
be called \host{vale.vbrew.com}, \host{vlager.vbrew.com}, etc.  These
are their official, fully qualified domain names.  Their local
hostnames would be only the first component of the name, such as
\host{vale}. 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 \file{/etc/hosts} (see below).


\index{domain name!NIS vs. DNS}
\index{domainname@\prog{domainname}}
\index{setting!domain name}
Some people suggest to use the \prog{domainname} command to set the
kernel's idea of a domain name to the remaining part of the FQDN. In
this way you could combine the output from \prog{hostname} and
\prog{domainname} to get the FQDN again.  However, this is at best
only half correct. \prog{domainname} is generally used to set the
host's NIS domain, which may be entirely different from the DNS domain
your host belongs to.  NIS is covered in chapter~\ref{nis}.



\section{Assigning IP~Addresses}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.addresses}
\index{assigning IP addresses}
\index{IP!address!assigning}
\index{address!choosing (IP)}
\index{choosing!IP addresses}

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 you will need an IP~address
just for the loopback interface, which is always \host{127.0.0.1}.


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 the network all by yourself, you have to assign IP~addresses
yourself as described below.


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 either have to assign them
different network numbers, or use subnetting to split your IP~address
range into several subnetworks.


If your network is not connected to the Internet, you are free to choose
any (legal) network address. You only have to make sure to choose one from
classes A, B, or C, else things will most likely not work properly.
However, if you intend to get on the Internet in the near future, you
should obtain an official IP~address \emph{now}. The best way to proceed is
to 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 \email{hostmaster@internic.net}.


\index{creating!subnets}
\index{subnet (DNS)}
\index{interface!netmask}
\index{IP!netmask}
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 \emph{broadcast
network}; 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. The reason for this will be
explained in chapter~\ref{slip}.


% If you do have to use subnetting, assign a number to each network you
% manage. If you have a ``backbone'' whose sole purpose is to connect the
% various subnets, remember to assign it a subnet number, too.  Then
% allocate a fraction of the IP~address' host part sufficient to hold the
% subnet numbers, plus a little room for future expansion.  Make sure the
% remaining host part bits are still sufficient to accomodate the maximum
% number of hosts you will have on any of the subnets.\footnote{
%  Of course, you may also have more complicated schemes that use different
%  netmasks for different subnets.
% }
% 
% 
% Then start assigning numbers to the hosts on each of the subnets.
% A gateway between broadcast networks needs one IP~address
% per network it is on.


As an example, the brewery's network manager applies to the NIC for a
class B network number, and is given \host{191.72.0.0}.  To accomodate
the two Ethernets, she decides to use eight bits of the host part as
additional subnet bits. This leaves another eight 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 \host{191.72.1.0} and
\host{191.72.2.0}. The subnet mask is \host{255.255.255.0}.


\host{vlager}, 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
\host{191.72.1.1} and \host{191.72.2.1}, respectively.
Figure~\ref{interface.fig.subnet} shows the two subnets, and the gateway.


\iftex
 \begin{figure}[tbp]
 \ifps
  \begin{center}
   \mbox{\epsffile{figures/subnet2.epsf}}
  \end{center}
 \else
  \begin{center}
   \input{subnet2.eepic}
  \end{center}
 \fi
 \caption{
  \label{interface.fig.subnet}
  Virtual Brewery and Virtual Winery~-- the two subnets.
 }
 \end{figure}
\else
\fi


Note that in this example I am using a class B network to keep things
simple; 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 2
bits of the host part for the netmask, giving you four possible subnets
with 64 hosts on each.\footnote{
  The last number on each subnet is reserved as the broadcast address,
  so it's in fact 63 hosts per subnet.
}



\section{Writing \file{hosts} and \file{networks} Files}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.simple-resolv}
\index{configuring!hostname resolution}
\index{hosts file@\file{hosts} file}
\index{networks file@\file{networks} file}
\index{hostname!resolution}
\index{network!names}
\index{hosts@\file{hosts}}

After you have subnetted your network, you should prepare for some simple
sort of hostname resolution using the \file{/etc/hosts} file. If you are
not going to use DNS or NIS for address resolution, you have to put all
hosts in the \file{hosts} file.


Even if you want to run DNS or NIS during normal operation, you want to
have some subset of all hostnames in \file{/etc/hosts} nevertheless.
For one, you want to 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 also allows you to use symbolic
hostnames in your \file{rc.inet} scripts. Thus, when changing
IP~addresses, you only have to copy an updated \file{hosts} file to all
machines and reboot, rather than having to edit a large number of
\file{rc} files separately.  Usually, you will put all local hostnames
and addresses in \file{hosts}, adding those of any gateways and NIS
servers if used.\footnote{
 You will need the address of any NIS servers only if you use Peter
 Eriksson's NYS. Other NIS implementations locate their servers at
 run-time only by using \prog{ypbind}.
}


Also, during intial testing, you should make sure your resolver only
uses information from the \file{hosts} file. Your DNS or NIS software may
come with sample files that may produce strange results when being used.
To make all applications use \file{/etc/hosts} exclusively when looking
up the IP~address of a host, you have to edit the \file{/etc/host.conf}
file. Comment out any lines that begin with the keyword \keyword{order}
by preceding them with a hash sign, and insert the line


\begin{tscreen}
 order hosts
\end{tscreen}


The configuration of the resolver library will be covered in detail
in chapter~\ref{resolv}.


The \file{hosts} 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 column one. Anything following a hash sign (\#) is
regarded as a comment and is ignored.


Hostnames can be either fully qualified, or relative to the local
domain.  For \host{vale}, you would usually enter the the fully
qualified name, \host{vale.vbrew.com}, and \host{vale} by itself in the
\file{hosts} file, so that it is known by both its official name and the
shorter local name.


This is an example how a \file{hosts} file at the Virtual Brewery
might look.  Two special names are included, \host{vlager-if1} and
\host{vlager-if2} that give the addresses for both interfaces used
on \host{vlager}.


\begin{tscreen}
\begin{verbatim}
#
# Hosts file for Virtual Brewery/Virtual Winery
#
# IP            local       fully qualified domain name
#
127.0.0.1       localhost
#
191.72.1.1      vlager      vlager.vbrew.com
191.72.1.1      vlager-if1
191.72.1.2      vstout      vstout.vbrew.com
191.72.1.3      vale        vale.vbrew.com
#
191.72.2.1      vlager-if2
191.72.2.2      vbeaujolais  vbeaujolais.vbrew.com
191.72.2.3      vbardolino   vbardolino.vbrew.com
191.72.2.4      vchianti     vchianti.vbrew.com
\end{verbatim}
\end{tscreen}


Just as with a host's IP~address, you sometimes would like to use a
symbolic name for network numbers, too. Therefore, the \file{hosts} file
has a companion called \file{/etc/networks} that maps network names to
network numbers and vice versa. At the Virtual Brewery, we might install
a \file{networks} file like this:\footnote{
 Note that names in \file{networks} must not collide with hostnames
 from the \file{hosts} file, else some programs may produce strange
 results.
}


\begin{tscreen}
\begin{verbatim}
# /etc/networks for the Virtual Brewery
brew-net      191.72.1.0
wine-net      191.72.2.0
\end{verbatim}
\end{tscreen}




\section{Interface Configuration for IP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% How to tell your interface what its IP address is.            %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.interface}
\index{IP!interface configuration} % fuzz factor
\index{interface!configuration}
\index{configuring!network interfaces}
\index{ifconfig@\prog{ifconfig}}
\index{route@\prog{route}}

\index{rc.inet@\file{rc.inet}}
\index{rc.inet@\file{rc.inet}}
After setting up your hardware as explained in the previous chapter, 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
\file{rc.inet1} script each time the system is booted.  The basic tools for
this are called \prog{ifconfig} (where ``if'' stands for interface), and
\prog{route}.


\prog{ifconfig} is used to make an interface accessible to the kernel
networking layer. This involves the assignment of an IP~address and other
parameters, and activating the interface, also known as ``taking up.''
Being active here means that the kernel will send and receive IP~datagrams
through the interface.  The simplest way to invoking it is


\begin{tscreen}
 ifconfig \var{interface ip-address}
\end{tscreen}


\noindent
which assigns \var{ip-address}\/ to \var{interface} and activates it.
All other parameters are set to default values. For instance, the
default subnet mask is derived from the network class of the IP~address,
such as \host{255.255.0.0} for a class~B address.  \prog{ifconfig} is
described in detail at the end of this chapter.


\prog{route} allows you to add or remove routes from the kernel routing
table. It can be invoked as


\begin{tscreen}
 route [add|del] \var{target}
\end{tscreen}


\noindent
where the \option{add} and \option{del} arguments determine whether
to add or delete the route to \var{target}.


\subsection{The Loopback Interface}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.interface.loopback}
\index{configuring!loopback interface}
\index{loopback!interface}
\index{interface!loopback}
\index{lo (loopback interface)@\file{lo} (loopback interface)}

The very first interface to be activated is the loopback interface:


\begin{tscreen}
 \# ifconfig lo 127.0.0.1
\end{tscreen}


\index{localhost@\host{localhost}}
Occasionally, you will also see the dummy hostname \host{localhost}
being used instead of the IP~address. \prog{ifconfig} will look up
the name in the \file{hosts} file where an entry should declare
it as the hostname for \host{127.0.0.1}:


\begin{tscreen}
\begin{verbatim}
# Sample /etc/hosts entry for localhost
localhost     127.0.0.1
\end{verbatim}
\end{tscreen}


\index{checking!network interface}
To view the configuration of an interface, you invoke \prog{ifconfig}
giving it the interface name as argument:


\begin{tscreen}
\begin{verbatim}
$ ifconfig lo
lo        Link encap Local Loopback  
          inet addr 127.0.0.1  Bcast [NONE SET]  Mask 255.0.0.0
          UP BROADCAST LOOPBACK RUNNING  MTU 2000  Metric 1
          RX packets 0 errors 0 dropped 0 overrun 0
          TX packets 0 errors 0 dropped 0 overrun 0
\end{verbatim}
\end{tscreen}


As you can see, the loopback interface has been assigned a netmask
of \host{255.0.0.0}, since \host{127.0.0.1} is a class~A address.
As you can see, the interface doesn't have a broadcast address set,
which isn't normally very useful for the loopback anyway. However, if
you run the \prog{rwhod} daemon on your host, you may have to set the
loopback device's broadcast address in order for \prog{rwho} to function
properly. Setting the broadcast is explained in section ``All about
\prog{ifconfig}'' below.


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 route to destination \host{127.0.0.1}.
This is accomplished by typing


\begin{tscreen}
 \# route add 127.0.0.1
\end{tscreen}


Again, you can use \host{localhost} instead of the IP~address.


\index{testing network configuration}
\index{checking!network configuration}
\index{checking!reachabilty}
\index{reaching a host}
\index{round-trip time (IP)}
\index{ping@\prog{ping}}
Next, you should check that everything works fine, for example by using
\prog{ping}.  \prog{ping} is the networking equivalent of a sonar
device\footnote{
 Anyone remember Pink Floyd's ``Echoes''?
} and 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 is often referred to as the
round-trip time.


\begin{tscreen}
\begin{verbatim}
# ping localhost
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=32 time=1 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=32 time=0 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=32 time=0 ms
^C

--- localhost ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0/0/1 ms
\end{verbatim}
\end{tscreen}


When invoking \prog{ping} as shown here, it will go on emitting packets
forever unless interrupted by the user. The \verb|^C| above marks the
place where we pressed Ctrl-C.


The above example shows that packets for \host{127.0.0.1} are properly
delivered and a reply is returned to \prog{ping} almost instantaneously.
This shows you have succeeded in setting up your first network interface.


\index{Network Unreachable error message@``Network Unreachable'' error message}
\index{network!unreachable}
If the output you get from \prog{ping} does not resemble that shown above,
you are in trouble. Check any error if they indicate some file hasn't
been installed properly. Check that the \prog{ifconfig} and \prog{route}
binaries you use are compatible with the kernel release you run, and,
above all, that the kernel has been compiled with networking enabled
(you see this from the presence of the \file{/proc/net} directory).
If you get an error message saying ``Network unreachable,'' then you
probably have got the \prog{route} command wrong. Make sure you use
the same address as you gave to \prog{ifconfig}.


\index{rc.inet@\file{rc.inet}}
The steps described above are enough to use networking applications on
a standalone host. After adding the above lines to \prog{rc.inet1} and
making sure both \prog{rc.inet} scripts are executed from
\prog{/etc/rc}, you may reboot your machine and try out various
applications. For instance, ``\prog{telnet localhost}'' should
establish a \prog{telnet} connection to your host, giving you a login
prompt.


However, the loopback interface is useful not only as an example in
networking books, or as a testbed during development, but is actually
used by some applications during normal operation.\footnote{
  For instance, all applications based on RPC use the loopback interface
  to register themselves with the \prog{portmapper} daemon at startup.
} Therefore, you always have to configure it, regardless of whether your
machine is attached to a network or not.


\subsection{Ethernet Interfaces}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.interface.ethernet}
\index{configuring!Ethernet}
\index{Ethernet!configuration}
\index{interface!Ethernet}
\index{IP!netmask}
\index{interface!netmask}
\index{eth0 (Ethernet interface)@\file{eth0} (Ethernet interface)}
\index{address!broadcast}
\index{IP!broadcast address}

Configuring an Ethernet interface goes pretty much the same as
with the loopback interface, it just requires a few more parameters
when you are using subnetting. 


At the Virtual Brewery, we have subnetted the IP network, which was
originally a class~B network, into class~C subnetworks. To make the
interface recognize this, the \prog{ifconfig} incantation would look
like this:


\begin{tscreen}
 \# ifconfig eth0 vstout netmask 255.255.255.0
\end{tscreen}


This assigns the \file{eth0} interface the IP~address of \host{vstout}
(\host{191.72.1.2}). If we had omitted the netmask, \prog{ifconfig}
would have deduced the the netmask from the IP~network class, which
would have resulted in a netmask of \host{255.255.0.0}.
Now a quick check shows:


\begin{tscreen}
\begin{verbatim}
# ifconfig eth0
eth0      Link encap 10Mps Ethernet HWaddr  00:00:C0:90:B3:42
          inet addr 191.72.1.2 Bcast 191.72.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
\end{verbatim}
\end{tscreen}


You can see that \prog{ifconfig} automatically set the broadcast
address (the \term{Bcast} field above) to the usual value, which is
the hosts network number with the host bits all set. Also, the message
transfer unit (the maximum size of Ethernet frames the kernel will
generate for this interface) has been set to the maximum value of 1500
bytes. All these values can be overidden with special options that
will be described later.


Quite similar to the loopback case, you now have to install a routing
entry that informs the kernel about the network that can be reached
through \file{eth0}.  For the Virtual Brewery, you would invoke
\prog{route} as


\begin{tscreen}
 \# route add -net 191.72.1.0
\end{tscreen}


At first, this looks a little like magic, because it's not really
clear how \prog{route} detects which interface to route through.
However, the trick is rather simple: the kernel checks all interfaces
that have been configured so far and compares the destination address
(\host{191.72.1.0} in this case) to the network part of the interface
address (that is, the bitwise and of the interface address and the
netmask). The only interface that matches is \file{eth0}.


Now, what's that \option{-net} option for? This is used because
\prog{route} can handle both routes to networks and routes to single
hosts (as you have seen above with \host{localhost}). When being given an
address in dotted quad notation, it attempts to guess whether it is a
network or a hostname by looking at the host part bits. If the address'
host part is zero, \prog{route} assumes it denotes a network, otherwise
it takes it as a host address. Therefore, \prog{route} would think that
\host{191.72.1.0} is a host address rather than a network number,
because it cannot know that we use subnetting. We therefore have to tell
it explicitly that it denotes a network, giving it the \option{-net}
flag.


Of course, the above \prog{route} command is a little tedious to type,
and it's prone to spelling mistakes. A more convenient approach is to
use the network names we have defined in \file{/etc/networks} above.
This makes the command much more readable; even the \option{-net} flag
can now be omitted, because \prog{route} now knows that
\host{191.72.1.0} denotes a network.


\begin{tscreen}
 \# route add brew-net
\end{tscreen}


\index{testing network configuration}
\index{checking!network configuration}
\index{checking!reachabilty}
Now that you've finished the basic configuration steps, we want to
make sure your Ethernet interface is indeed running happily. Choose a
host from your Ethernet, for instance \host{vlager}, and type


\begin{tscreen}
\begin{verbatim}
# ping vlager
PING vlager: 64 byte packets
64 bytes from 191.72.1.1: icmp_seq=0. time=11. ms
64 bytes from 191.72.1.1: icmp_seq=1. time=7. ms
64 bytes from 191.72.1.1: icmp_seq=2. time=12. ms
64 bytes from 191.72.1.1: icmp_seq=3. time=3. ms
^C

----vstout.vbrew.com PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 3/8/12
\end{verbatim}
\end{tscreen}


If you don't see any output similar to this, then something is broken,
obviously.  If you encounter unusual packet loss rates, this hints at
a hardware problem, like bad or missing terminators, etc.  If you
don't receive any packets at all, you should check the interface
configuration with \prog{netstat}. The packet statistics displayed by
\prog{ifconfig} should tell you whether any packets have been sent out
on the interface at all. If you have access to the remote host, too,
you should go over to that machine and check the interface statistics,
too. In this way, you can determine exactly where the packets got
dropped.  In addition, you should display the routing information with
\prog{route} to see if both hosts have the correct routing entry. 
\prog{route} prints out the complete kernel routing table when invoked
without any arguments (the \option{-n} option only makes it print
addresses as dotted quad instead of using the hostname):


\index{IP!routing table}
\index{display!IP routing table}
\index{checking!IP routing table}
\index{route@\prog{route}}

\begin{tscreen}
\begin{verbatim}
# route -n
Kernel routing table
Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
127.0.0.1       *               255.255.255.255 UH    1      0      112 lo
191.72.1.0      *               255.255.255.0   U     1      0       10 eth0
\end{verbatim}
\end{tscreen}


The detailed meaning of these fields is explained below in
section~\ref{iface.netstat}. The \term{Flag} column contains a list of
flags set for each interface. \term{U} is always set for active
interfaces, and \term{H} says the destination address denotes a host.
If the \term{H} flag is set for a route that you meant to be a network
route, then you have to specify the \option{-net} option with the
\prog{route} command. To check whether a route you have entered is used
at all, check if the \term{Use} field in the second to last column
increases between two invocations of \prog{ping}.



\subsection{Routing through a Gateway}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.interface.gateway}
\index{routing!IP gateway}
\index{IP!routing}
\index{IP!gateway}
\index{IP!subnet}
\index{gateway!IP}

In the previous section, I 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 provide a link to the
outside world, the Internet, as well. In order to use the service of a
gateway, you have to provide additional routing information to the
networking layer.


For instance, the Ethernets of the Virtual Brewery and the Virtual
Winery are linked through such a gateway, namely the host \host{vlager}.
Assuming that \host{vlager} has already been configured, we only have to
add another entry to \host{vstout}'s routing table that tells the kernel
it can reach all hosts on the Winery's network through \host{vlager}.
The appropriate incantation of \prog{route} is shown below; the
\option{gw} keyword tells it that the next argument denotes a gateway.


\begin{tscreen}
\# route add wine-net gw vlager
\end{tscreen}


Of course, any host on the Winery network you wish to talk to must have
a corresponding routing entry for the Brewery's network, otherwise you
would only be able to send data from \host{vstout} to \host{vbardolino},
but any response returned by the latter would go into the great bit
bucket.


This example describes only a gateway that switches packets between two
isolated Ethernets. Now assume that \host{vlager} also has a connection
to the Internet (say, through an additional SLIP link). Then we would
want datagrams to \emph{any} destination network other than the Brewery
to be handed to \host{vlager}. This can be accomplished by making it the
default gateway for \host{vstout}:


\begin{tscreen}
\# route add default gw vlager
\end{tscreen}


\index{IP!default route}
\index{route, default}
The network name \host{default} is a shorthand for \host{0.0.0.0},
which denotes the default route. You do not have to add this name to
\file{/etc/networks}, because it is built into \prog{route}.


When you see high packet loss rates when \prog{ping}ing 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 due to temporary
excess loads on forwarding hosts, which makes them delay or even drop
incoming datagrams.


% \index{routing!metric}
% \index{IP!metric}
% \index{metric}
% Beside the \option{gw} argument, you may also specify a metric value
% to \prog{route} using the \option{metric} keyword:
% 
% 
% \begin{tscreen}
% \# route add wine-net gw vlager metric 2
% \end{tscreen}
% 
% 
% This causes the kernel to assume a metric value of 2 for the route to
% the Winery's network. We just mention this for the sake of completeness,
% because on one hand, \linux{} doesn't yet evaluate the metric
% information at all, and on the other hand, you would use this option
% only very rarely, anyway.



\subsection{Configuring a Gateway}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.interface.gateway-conf}
\index{configuring!IP gateway}
\index{gateway!configuring}
\index{IP!gateway}
\index{IP!routing}
\index{IP!subnet}

Configuring a machine to switch packets between two Ethernets is
pretty straightforward. Assume we're back at \host{vlager}, which
is equipped with two Ethernet boards, each being connected to one
of the two networks. All you have to do is configure both interfaces
separately, giving them their respective IP~address, and that's it.


It is quite useful to add information on the two interfaces to
the \file{hosts} file in the way shown below, so we have handy
names for them, too:


\begin{tscreen}
\begin{verbatim}
191.72.1.1      vlager      vlager.vbrew.com
191.72.1.1      vlager-if1
191.72.2.1      vlager-if2
\end{verbatim}
\end{tscreen}


The sequence of commands to set up the two interfaces is then:

\begin{tscreen}
\begin{verbatim}
# ifconfig eth0 vlager-if1
# ifconfig eth1 vlager-if2
# route add brew-net
# route add wine-net
\end{verbatim}
\end{tscreen}



\subsection{The PLIP Interface}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.interface.plip}
\index{configuring!PLIP}
\index{interface!PLIP}
\index{point-to-point link}
\index{Parallel Line IP|see {PLIP}}
\index{PLIP}
\index{plip1 (PLIP interface)@\file{plip1} (PLIP interface)}

When using a PLIP link to connect two machines, things are a
little different from what you have to do when using an Ethernet.
The former are so-called \emph{point-to-point} links, because
they involve ony two hosts (``points''), as opposed
to broadcast networks.


As an example, we consider the laptop computer of some employee at
the Virtual Brewery that is connected to \host{vlager} via PLIP.
The laptop itself is called \host{vlite}, and has only one
parallel port. At boot time, this port will be registered as
\file{plip1}. To activate the link, you have to configure the
\file{plip1} interface using the following commands:\footnote{
 Note that \option{pointopoint} is not a typo. It's really
 spelt like this.
}


\begin{tscreen}
\begin{verbatim}
# ifconfig plip1 vlite pointopoint vlager
# route add default gw vlager
\end{verbatim}
\end{tscreen}


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
\host{vlager}. The second installs the default route, using
\host{vlager} as gateway.  On \host{vlager}, a similar \prog{ifconfig}
command is necessary to activate the link (a \prog{route} invocation is
not needed):


\begin{tscreen}
\begin{verbatim}
# ifconfig plip1 vlager pointopoint vlite
\end{verbatim}
\end{tscreen}


The interesting point is that the \file{plip1} interface on
\host{vlager} does not have to have a separate IP~address, but may also
be given the address \host{191.72.1.1}.\footnote{
 Just as a matter of caution, you should however 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.
}


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 \host{vlite}. One particularly cumbersome way is
to add a specific route to every host's routing table that names 
\host{vlager} as a gateway to \host{vlite}:


\begin{tscreen}
\begin{verbatim}
# route add vlite gw vlager
\end{verbatim}
\end{tscreen}


\index{routing!dynamic}
\index{Routing Information Protocol}
\index{gated@\prog{gated}}
\index{ARP!proxy}
\index{proxy ARP}
A much better option when faced with temporary routes is to use dynamic
routing.  One way to do so is to use \prog{gated}, a routing daemon,
which you would have to install on each host in the network in order
to distribute routing information dynamically.  The easiest way,
however, is to use \emph{proxy} ARP. With proxy ARP, \host{vlager} will
respond to any ARP query for \host{vlite} by sending its own Ethernet
address. The effect of this is that all packets for \host{vlite} will wind
up at \host{vlager}, which then forwards them to the laptop. We will come
back to proxy ARP in section~\ref{iface.verify.arp} below.


Future Net-3 releases will contain a tool called \prog{plipconfig}
which will allow you to set the IRQ of the printer port to use. Later,
this may even be replaced by a more general \prog{ifconfig} command.



\subsection{The SLIP and PPP Interface}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.interface.slip}
\index{sl0 (SLIP interface)@\file{sl0} (SLIP interface)}
\index{sl0 (PPP interface)@\file{sl0} (PPP interface)}
\index{point-to-point link}
\index{configuring!SLIP}
\index{configuring!PPP}
\index{interface!SLIP}
\index{interface!PPP}
\index{SLIP}
\index{PPP}

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. The tools required for setting up a SLIP or
PPP link will be described in chapters~\ref{slip} and~\ref{ppp}.


\subsection{The Dummy Interface}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\namedlabel{iface.interface.dummy}{The Dummy Interface}
\index{dummy interface}
\index{interface!dummy}
\index{standalone host}
\index{host!standalone}
\index{configuring!SLIP}
\index{configuring!PPP}

The dummy interface is really a little exotic, but rather useful
nevertheless. Its main benefit is with standalone hosts, and machines
whose only IP network connection is a dial-up link. In fact, the
latter are standalone hosts most of the time, too.

The dilemma with standalone hosts is that they only have a single network
device active, the loopback device, which is usually assigned
the address \host{127.0.0.1}.  On some occasions, however, you need
to send data to the `official' IP address of the local host. For
instance, consider the laptop \host{vlite}, that has been disconnected
from any network for the duration of this example.  An application
on \host{vlite} may now want to send some data to another application on
the same host. Looking up \host{vlite} in \file{/etc/hosts} yields
an IP~address of \host{191.72.1.65}, so the application tries to send
to this address. As the loopback interface is currently the only active
interface on the machine, the kernel has no idea that this address
actually refers to itself! As a consequence, the kernel discards the
datagram, and returns an error to the application.

This is where the dummy device steps in. It solves the dilemma by
simply serving as the alter ego of the loopback interface.  In the
case of \host{vlite}, you would simply give it the address
\host{191.72.1.65} and add a host route pointing to it. Every datagram
for \host{191.72.1.65} would then be delivered locally. The proper
invocation is:


\begin{tscreen}
\begin{verbatim}
# ifconfig dummy vlite
# route add vlite
\end{verbatim}
\end{tscreen}



\section{All About \prog{ifconfig}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.ifconfig}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{ifconfig@\prog{ifconfig}}

There are a lot more parameters to \prog{ifconfig} than we have
described above. Its normal invocation is this:

\begin{tscreen}
 ifconfig \var{interface} [[-net|-host] \var{address} [\var{parameters}]]
\end{tscreen}


\var{interface} is the interface name, and \var{address} is the
IP~address to be assigned to the interface.  This may either be an
IP~address in dotted quad notation, or a name \prog{ifconfig} will look
up in \file{/etc/hosts} and \file{/etc/networks}.  The \option{-net} and
\option{-host} options force \prog{ifconfig} to treat the address as
network number or host address, respectively.


\index{display!interface configuration}
If \prog{ifconfig} is invoked with only the interface name, it displays
that interface's configuration. When invoked without any parameters, it
displays all interfaces you configured so far; an option of \option{-a}
forces it to show the inactive ones as well.  A sample invocation for the
Ethernet interface \file{eth0} may look like this:


\begin{tscreen}
\begin{verbatim}
# ifconfig eth0
eth0      Link encap 10Mbps Ethernet  HWaddr 00:00:C0:90:B3:42
          inet addr 191.72.1.2 Bcast 191.72.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

\end{verbatim}
\end{tscreen}


\index{Maximum Transfer Unit}
\index{routing!metric}
The \term{MTU} and \term{Metric} 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.


The RX and TX 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 happen when packets
come in faster than the kernel can service the last interrupt.  The
flag values printed by \prog{ifconfig} correspond more or less to the
names of its command line options; they will be explained below.


The following is a list of parameters recognized by \prog{ifconfig} with
the corresponding flag names are given in brackets. Options that simply
turn on a feature also allow it to be turned off again by preceding the
option name by a dash (-).


\begin{dispitems}
\ditem[\option{up}]
        This marks an interface ``up'', i.e. accessible to the IP layer.
        This option is implied when an \var{address} is given on the
        command line. It may also be used to re-eenable an interface
        that has been taken down temporarily using the \option{down}
        option.

        \noindent
        (This option corresponds to the flags \term{UP RUNNING}.)

\ditem[\option{down}]
        This marks an interface ``down'', i.e. inaccessible to the IP
        layer. This effectively disables any IP~traffic through the
        interface.  Note that this does not delete all routing entries
        that use this interface automatically.  If you take the
        interface down permanently, you should to delete these routing
        entries and supply alternative routes if possible.

\ditem[\option{netmask} \var{mask}]
        \index{IP!netmask}
        \index{interface!netmask}
        This 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.
        %, or as a netmask name listed in \file{/etc/netmasks}.

\ditem[\option{pointopoint} \var{address}]
        \index{point-to-point link}
        This option is used for point-to-point IP links that involve
        only two hosts. This option is needed to configure, for example,
        SLIP or PLIP interfaces.

        \noindent
        (If a point-to-point address has been set, \prog{ifconfig}
        displays the \term{POINTOPOINT} flag.)

\ditem[\option{broadcast} \var{address}]
        \index{IP!broadcast address}
        \index{broadcast address}
        \index{address!broadcast}
        The broadcast address is usually made up from the network number
        by setting all bits of the host part. Some IP implementations
        use a different scheme; this option is there to adapt to these
        strange environments.

        \noindent
        (If a broadcast address has been set, \prog{ifconfig} displays
        the \term{BROADCAST} flag.)

\ditem[\option{metric} \var{number}]
        \index{Routing Information Protocol}
        \index{routing!metric}
        \index{IP!metric}
        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{
          \label{iface.interface.ifconfig.metric}
          RIP chooses the optimal route to a given host based on the
          ``length'' 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} parameter sets this hop cost, which is then
          broadcast by the routing daemon.
        } The default metric used by \prog{ifconfig} is a value of
        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.

\ditem[\option{mtu} \var{bytes}]
        \index{Maximum Transfer Unit}
        \index{MTU|see {Maximum Transfer Unit}}
        \index{IP!MTU|see {Maximum Transfer Unit}}
        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 1500; for SLIP
        interfaces, this is 296.

%\ditem[\option{trailers}]
%        \index{Ethernet!trailers}
%        This is an option specific to Ethernet interfaces. It enables
%        so-called \emph{trailer encapsulation}, a technique to minimize
%        the number of memory-to-memory copies the receiving system needs
%        to perform. The option is on by default.
%
%        \noindent
%        (If trailer encapsulation is disabled, \prog{ifconfig} displays
%        the flag \term{NOTRAILERS}.)

\ditem[\option{arp}]
        \index{disabling ARP}
        \index{enabling ARP}
        \index{ARP!enabling}
        This is an option specific to broadcast networks such as
        Ethernets or packet radio. It enables the use of ARP, the
        Address Resolution Protocol, to detect the physical addresses
        of hosts attached to the network. For broadcast networks, is
        on by default.

        \noindent
        (If ARP is disabled, \prog{ifconfig} displays the flag \term{NOARP}.)

\ditem[\option{-arp}]
	Disables the use of ARP on this interface.

\ditem[\option{promisc}]
	\index{Ethernet!promiscuous mode}
	\index{security!Ethernet}
	Puts the interface in promiscuous mode. On a broadcast network,
	this makes the interface receive all packets, regardless of whether
	they were destined for another host or not. This allows an analysis
	of network traffic using packet filters and such, also called
	\emph{Ethernet snooping}.  Usually, this is a good technique
	of hunting down network problems that are otherwise hard to
	come by.

	On the other hand, this allows attackers to skim the traffic of
	your network for passwords and do other nasty things. One
	protection against this type of attack is not to let anyone
	just plug in their computers in your Ethernet. Another
	option is to use secure authentication protocols, such as
	Kerberos, or the SRA login suite.\footnote{
	 SRA can be obtained from \host{ftp.tamu.edu} in
	 \file{/pub/sec/TAMU}.
	}

        \noindent
        (This option corresponds to the flag \term{PROMISC}.)

\ditem[\option{-promisc}]
	Turns off promiscuous mode.

\ditem[\option{allmulti}]
	\index{IP!multicast addresses}
	Multicast addresses are some sort of broadcast to a group of
	hosts who don't necessarily have to be on the same subnet.
	Multicast addresses are not yet supported by the kernel.

        \noindent
        (This option corresponds to the flag \term{ALLMULTI}.)

\ditem[\option{-allmulti}]
	Turns off multicast addresses.

\end{dispitems}



\section{Checking with \prog{netstat}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\namedlabel{iface.netstat}{Checking with \prog{netstat}}
\index{netstat@\prog{netstat}|(}

Next, I will turn to a useful tool for checking your network
configuration and activity. It is called \prog{netstat} and is, in
fact, rather a collection of several tools lumped together. We will
discuss each of its functions in the following sections.


\subsection{Displaying the Routing Table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.netstat.-r}
\index{IP!routing table}
\index{checking!the routing table}
\index{display!IP routing table}
\index{routing!table}

When invoking \prog{netstat} with the \option{-r} flag, it displays the
kernel routing table in the way we've been doing this with \prog{route}
above.  On \host{vstout}, it produces:


\begin{tscreen}
\begin{verbatim}
# netstat -nr
Kernel routing table
Destination     Gateway         Genmask         Flags Metric Ref Use    Iface
127.0.0.1       *               255.255.255.255 UH    1      0       50 lo
191.72.1.0      *               255.255.255.0   U     1      0      478 eth0
191.72.2.0      191.72.1.1      255.255.255.0   UGN   1      0      250 eth0
\end{verbatim}
\end{tscreen}


The \option{-n} option makes \prog{netstat} print addresses as dotted
quad IP~numbers rather than the symbolic host and network names. This is
especially useful when you want to avoid address lookups over the network
(e.g. to a DNS or NIS server).


The second column of \prog{netstat}'s output shows the gateway the
routing entry points to. If no gateway is used, an asterisk is printed
instead. Column three shows the ``generality'' of the route. When given
an IP~address to find a suitable route for, the kernel goes through all
routing table entries, taking the bitwise AND of the address and the
genmask before comparing it to the target of the route.


The fourth column displays various flags that describe the route:


\begin{dispitems}
\ditem[G]
        The route uses a gateway.

\ditem[U]
        The interface to be used is up.

\ditem[H]
        Only a single host can be reached through the route. For
        example, this is the case for the loopback entry
        \host{127.0.0.1}.

\ditem[D]
        This is set if the table entry has been generated
        by an ICMP redirect message (see section~\ref{tcpip.icmp}).

\ditem[M]
        This is set if the table entry was modified by an ICMP
        redirect message.
\end{dispitems}


The \term{Ref} column of \prog{netstat}'s output shows the number of
references to this route, that is, how many other routes (e.g. through
gateways) rely on the presence of this route. The last two columns show
the number of times the routing entry has been used, and the interface
that datagrams are passed to for delivery.



\subsection{Displaying Interface Statistics}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.netstat.-i}
\index{display!interface statistics}
\index{interface!statistics}
\index{checking!network interface}

When invoked with the \option{-i} flag, \prog{netstat} will display
statistics for the network interfaces currently configured. If, in
addition, the \option{-a} option is given, it will print \emph{all}
interfaces present in the kernel, not only those that have been
configured currently. On \host{vstaout}, the output from \prog{netstat}
will look like this:


\begin{tscreen}
\begin{verbatim}
$ netstat -i
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
\end{verbatim}
\end{tscreen}


The MTU and Met fields show the current MTU and metric value for that
interface. The RX and TX columns show how many packets have been
received or transmitted error free (RX-OK/TX-OK), damaged
(RX-ERR/TX-ERR), how many were dropped (RX-DRP/TX-DRP), and how many
were lost because of an overrun (RX-OVR/TX-OVR).


The last column shows the flags that have been set for this interface.
These are one-character versions of the long flag names the are printed
when you display the interface configuration with \prog{ifconfig}.


\begin{dispitems}
 \ditem[B]	A broadcast address has been set.
 \ditem[L]	This interface is a loopback device
 \ditem[M]	All packets are received (promiscuous mode).
 \ditem[N]	Trailers are avoided.
 \ditem[O]	ARP is turned off for this interface.
 \ditem[P]	This is a point-to-point connection.
 \ditem[R]	Interface is running.
 \ditem[U]	Interface is up.
\end{dispitems}



\subsection{Displaying Connections}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{iface.netstat.-t-u-x}
\index{display!active connections}
\index{network!display connections}
\index{connections, display}
\index{checking!network connections}
\index{checking!TCP server activity}

\prog{netstat} supports a set of options to display active or passive
sockets. The options \option{-t}, \option{-u}, \option{-w}, and
\option{-x} show active TCP, UDP, RAW, or UNIX socket connections.
If you provide the \option{-a} flag in addition, sockets that are
waiting for a connection (i.e. listening) are displayed as well.
This will give you a list of all servers that are currently running
on your system.


Invoking \prog{netstat -ta} on \host{vlager} produces

\begin{tscreen}
\begin{verbatim}
$ netstat -ta
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  
\end{verbatim}
\end{tscreen}


This shows most servers simply waiting for an incoming connection. However,
the fourth line shows an incoming SMTP connection from \host{vstout}, and
the sixth line tells you there is an outgoing \prog{telnet} connection
to \host{vbardolino}.\footnote{
 You can tell whether a connection is outgoing or not from the port
 numbers involved. The port number shown for the \emph{calling} host
 will always be a simple integer, while on the host being called, a
 well-known service port will be in use, for which \prog{netstat} uses
 the symbolic name found in \file{/etc/services}.
}

Using the \option{-a} flag all by itself will display all sockets
from all families.


\index{netstat@\prog{netstat}|)}


\section{Checking the ARP Tables}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\namedlabel{iface.verify.arp}{Checking the ARP Tables}
\index{checking!Ethernet interface}
\index{checking!ARP tables}
\index{ARP!display table}
\index{display!ARP table}

On some occasions, it is useful to view or even 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 \prog{arp} tool was made for things like these.  Its command line
options are


\begin{tscreen}
 arp [-v] [-t \var{hwtype}] -a [\var{hostname}]           \\
 arp [-v] [-t \var{hwtype}] -s \var{hostname} \var{hwaddr}\\
 arp [-v] -d \var{hostname} [\var{hostname}\ldots]    
\end{tscreen}


All \var{hostname} arguments may be either symbolic host names or
IP~addresses in dotted quad notation.


The first invocation displays the ARP entry for the IP~address or host
specified, or all hosts known if no \var{hostname} is given.  For example,
invoking \prog{arp} on \host{vlager} may yield


\begin{tscreen}
\begin{verbatim}
# arp -a
IP address      HW type                 HW address
191.72.1.3      10Mbps Ethernet         00:00:C0:5A:42:C1
191.72.1.2      10Mbps Ethernet         00:00:C0:90:B3:42
191.72.2.4      10Mbps Ethernet         00:00:C0:04:69:AA
\end{verbatim}
\end{tscreen}


\noindent
which shows the Ethernet addresses of \host{vlager}, \host{vstout} and
\host{vale}.


Using the \option{-t} option you can limit the display to the hardware
type specified.  This may be \keyword{ether}, \keyword{ax25}, or
\keyword{pronet}, standing for 10Mbps Ethernet, AMPR~AX.25, and IEEE~802.5
token ring equipment, respectively.


The \option{-s} option is used to permanently add \var{hostname}'s
Ethernet address to the ARP tables. The \var{hwaddr} 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, too,
using the \option{-t} option.


One problem which may require you to manually add an IP~address to the
ARP table is when for some reasons ARP queries for the remote host 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.  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.


Invoking \prog{arp} using the \option{-d} switch deletes all ARP entries
relating to the given host.  This may be used to force the interface to
re-attempt to obtain the Ethernet address for the IP~address in question.
This is useful when a misconfigured system has broadcast wrong ARP
information (of course, you have to reconfigure the broken host before).


\index{point-to-point link}
\index{routing!proxy ARP}
\index{routing!dynamic}
\index{proxy ARP}
\index{ARP!proxy}
\index{SLIP!routing}
\index{PLIP!routing}
\index{PPP!routing}
The \option{-s} option may also be used to implement \emph{proxy} ARP.
This is a special technique where a host, say \host{gate}, acts as a
gateway to another host named \host{fnord}, by pretending that both
addresses refer to the same host, namely \host{gate}. It does so by
publishing an ARP entry for \host{fnord} that points to its own Ethernet
interface. Now when a host sends out an ARP query for \host{fnord},
\host{gate} will return a reply containing its own Ethernet address. The
querying host will then send all datagrams to \host{gate}, which
dutyfully forwards them to \host{fnord}.


These contortions may be necessary, for instance, when you want to
access \host{fnord} 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 \host{fnord} was on the local subnet,
so it doesn't have to know about how to route through a gateway.


Another very 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 already encountered
the laptop \host{vlite} which was connected to \host{vlager} through a
PLIP link only from time to time.  Of course, this 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. For instance, \host{vstout} could proxy ARP
for any host on the Brewery subnet (\host{191.72.1.0}), but never for a
host on the Winery subnet (\host{191.72.2.0}).


The proper invocation to provide proxy ARP for \host{fnord} is given
below; of course, the Ethernet address given must be that of \host{gate}.


\begin{tscreen}
\begin{verbatim}
# arp -s fnord 00:00:c0:a1:42:e0 pub
\end{verbatim}
\end{tscreen}


The proxy ARP entry may be removed again by invoking:


\begin{tscreen}
\begin{verbatim}
# arp -d fnord
\end{verbatim}
\end{tscreen}


\section{The Future}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\linux{} networking is still evolving.  Major changes at the kernel
layer will bring a very flexible configuration scheme that will allow
you to configure the network devices at run time.  For instance, the
\prog{ifconfig} command will take arguments that set the IRQ line and
DMA channel.

\index{Maximum Transfer Unit}
\index{route@\prog{route}}
Another change to come soon is the additional \option{mtu} flag to the
\prog{route} command which will set the Maximum Transmission Unit for a 
particular route.  This route-specific MTU overrides the MTU specified
for the interface.  You will typically use this option for routes
through a gateway, where the link between the gateway and the
destination host requires a very low MTU. For instance, assume 
host \host{wanderer} is connected to \host{vlager} through a SLIP link.
When sending data from \host{vstout} to \host{wanderer}, the
networking layer on \host{wanderer} would would use packets of up to
1500 bytes, because packets are sent across the Ethernet. The SLIP
link, on the other hand, is operated with an MTU of 296, so the network
layer on \host{vlager} would have to break up the IP packets into
smaller fragments that fit into 296 bytes. If instead, you would have
configured the route on \host{vstout} to use a MTU of 296 right from
the start, this relatively expensive fragmentation could be avoided:


\begin{tscreen}
\begin{verbatim}
# route add wanderer gw vlager mtu 296
\end{verbatim}
\end{tscreen}


\index{Subnets Are Local@`Subnets Are Local' Policy}
Note that the \option{mtu} option also allows you to selectively undo
the effects of the `Subnets Are Local' Policy (SNARL). This policy is
a kernel configuration option and is described in chapter~\ref{hardware}.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                E N D   O F   C H A P T E R                    %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
