mirror of https://github.com/tLDP/LDP
965 lines
42 KiB
Plaintext
965 lines
42 KiB
Plaintext
<chapter id="X-087-2-issues"><title>Issues of TCP/IP <?lb>Networking</title>
|
|
<indexterm id="chis.tcp.ip.networks" class="startofrange"><primary>TCP/IP (Transmission Control Protocol/Internet Protocol)</primary><secondary>networks</secondary></indexterm>
|
|
<indexterm id="chis.networks.tcp.ip" class="startofrange"><primary>networks</primary><secondary>TCP/IP</secondary></indexterm>
|
|
|
|
<para>
|
|
In this chapter we turn to the configuration decisions you'll need to make
|
|
when connecting your Linux machine to a TCP/IP network, including dealing
|
|
with IP addresses, hostnames, and routing issues. This chapter gives you the
|
|
background you need in order to understand what your setup requires, while
|
|
the next chapters cover the tools you will use.
|
|
</para>
|
|
|
|
<para>
|
|
To learn more about TCP/IP and the reasons behind it, refer to the
|
|
three-volume set <emphasis>Internetworking with TCP/IP</emphasis>, by
|
|
Douglas R. Comer (Prentice Hall). For a more detailed guide to managing
|
|
a TCP/IP network, see <emphasis>TCP/IP Network Administration</emphasis>
|
|
by Craig Hunt (O'Reilly).
|
|
</para>
|
|
|
|
<sect1 id="X-087-2-issues.interfaces"><title>Networking Interfaces</title>
|
|
<indexterm><primary>interfaces</primary></indexterm>
|
|
<para>
|
|
To hide the diversity of equipment that may be used in a networking
|
|
environment, TCP/IP defines an abstract <emphasis>interface</emphasis>
|
|
through which the hardware is accessed. This interface offers a set of
|
|
operations that is the same for all types of hardware and basically deals
|
|
with sending and receiving packets.
|
|
</para>
|
|
|
|
<para>
|
|
For each peripheral networking device, a corresponding interface has
|
|
to be present in the kernel. For example, Ethernet interfaces in Linux
|
|
are called by such names as <filename>eth0</filename> and
|
|
<filename>eth1</filename>; PPP (discussed in <xref
|
|
linkend="X-087-2-ppp"> ) interfaces are named <filename>ppp0</filename>
|
|
and <filename>ppp1</filename>; and FDDI interfaces are given names
|
|
like <filename>fddi0</filename> and <filename>fddi1</filename>. These
|
|
interface names are used for configuration purposes when you want to
|
|
specify a particular physical device in a configuration command, and
|
|
they have no meaning beyond this use.
|
|
</para>
|
|
|
|
<para>
|
|
Before being used by TCP/IP networking, an interface must be assigned
|
|
an IP address that serves as its identification when communicating
|
|
with the rest of the world. This address is different from the
|
|
interface name mentioned previously; if you compare an interface to a
|
|
door, the address is like the nameplate pinned on it.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Maximum Transfer Unit (MTU)</primary></indexterm>
|
|
Other device parameters may be set, like the maximum size of datagrams
|
|
that can be processed by a particular piece of hardware, which is referred
|
|
to as <emphasis>Maximum Transfer Unit</emphasis> (MTU). Other attributes
|
|
will be introduced later. Fortunately, most attributes have sensible defaults.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-issues.ip-addresses"><title>IP Addresses</title>
|
|
<indexterm><primary>addresses</primary><secondary>IP</secondary></indexterm>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>addresses</secondary></indexterm>
|
|
<para>
|
|
As mentioned in <xref linkend="X-087-2-intro">, the IP networking protocol
|
|
understands addresses as 32-bit numbers. Each machine must be assigned a
|
|
number unique to the networking environment.<footnote id="X-087-2-FNIS01">
|
|
<para>
|
|
The version of the Internet Protocol most frequently used on the
|
|
Internet is Version 4. A lot of effort has been expended in designing
|
|
a replacement called IP Version 6. IPv6 uses a different addressing
|
|
scheme and larger addresses. Linux has an implementation of IPv6, but
|
|
it isn't ready to document it in this book yet. The Linux kernel
|
|
support for IPv6 is good, but a large number of network applications
|
|
need to be modified to support it as well. Stay tuned.
|
|
</para>
|
|
</footnote>
|
|
If you are running a local network that does not have TCP/IP traffic
|
|
with other networks, you may assign these numbers according to your
|
|
personal preferences. There are some IP address ranges that have been
|
|
reserved for such private networks. These ranges are listed in <xref
|
|
linkend="X-087-2-issues.reserved.addresses">. However, for sites on
|
|
the Internet, numbers are assigned by a central authority, the
|
|
<emphasis>Network Information Center</emphasis> (NIC).<footnote
|
|
id="X-087-2-FNIS02">
|
|
<para>
|
|
Frequently, IP addresses will be assigned to you by the provider from
|
|
whom you buy your IP connectivity. However, you may also apply to the
|
|
NIC directly for an IP address for your network by sending email to
|
|
<systemitem role="emailaddr">hostmaster@internic.net</systemitem>, or
|
|
by using the form at <systemitem
|
|
role="url">http://www.internic.net/</systemitem>.
|
|
</para>
|
|
</footnote>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>dotted quad notation</primary></indexterm>
|
|
<indexterm><primary>octets</primary></indexterm>
|
|
IP addresses are split up into four eight-bit numbers called
|
|
<emphasis>octets</emphasis> for readability. For example,
|
|
<systemitem role="sitename">quark.physics.groucho.edu</systemitem> has an
|
|
IP address of <systemitem role="sitename">0x954C0C04</systemitem>, which is
|
|
written as <systemitem role="sitename">149.76.12.4</systemitem>. This format
|
|
is often referred to as <emphasis>dotted quad notation</emphasis>.
|
|
</para>
|
|
|
|
<para>
|
|
Another reason for this notation is that IP addresses are split into a
|
|
<emphasis>network</emphasis> number, which is contained in the leading
|
|
octets, and a <emphasis>host</emphasis> number, which is the remainder.
|
|
When applying to the NIC for IP addresses, you are not assigned an address
|
|
for each single host you plan to use. Instead, you are given a network
|
|
number and allowed to assign all valid IP addresses within this range to
|
|
hosts on your network according to your preferences.
|
|
</para>
|
|
|
|
<para>
|
|
The size of the host part depends on the size of the network. To accommodate
|
|
different needs, several classes of networks, defining different places to
|
|
split IP addresses, have been defined. The class networks are described here:
|
|
</para>
|
|
|
|
<para>
|
|
<variablelist>
|
|
<varlistentry><term>Class A</term>
|
|
<listitem><para>
|
|
Class A comprises networks <systemitem role="sitename">1.0.0.0</systemitem>
|
|
through <systemitem role="sitename">127.0.0.0</systemitem>. The network number
|
|
is contained in the first octet. This class provides for a 24-bit host part,
|
|
allowing roughly 1.6 million hosts per network.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Class B</term>
|
|
<listitem><para>
|
|
Class B contains networks <systemitem role="sitename">128.0.0.0</systemitem>
|
|
through <systemitem role="sitename">191.255.0.0</systemitem>; the network
|
|
number is in the first two octets. This class allows for 16,320 nets with 65,024
|
|
hosts each.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Class C</term> <listitem><para> Class C networks
|
|
range from <systemitem role="sitename">192.0.0.0</systemitem> through
|
|
<systemitem role="sitename">223.255.255.0</systemitem>, with the
|
|
network number contained in the first three octets. This class allows
|
|
for nearly 2 million networks with up to 254 hosts.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>Classes D, E, and F</term>
|
|
<listitem><para>
|
|
Addresses falling into the range of
|
|
<systemitem role="sitename">224.0.0.0</systemitem> through
|
|
<systemitem role="sitename">254.0.0.0</systemitem> are either experimental or
|
|
are reserved for special purpose use and don't specify any network. IP
|
|
Multicast, which is a service that allows material to be transmitted to many
|
|
points on an internet at one time, has been assigned addresses from within
|
|
this range.
|
|
</para></listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
</para>
|
|
|
|
<para>
|
|
If we go back to the example in Chapter 1, we find that
|
|
<systemitem role="sitename">149.76.12.4</systemitem>, the address of
|
|
<systemitem role="sitename">quark</systemitem>, refers to host
|
|
<systemitem role="sitename">12.4</systemitem> on the class B network
|
|
<systemitem role="sitename">149.76.0.0</systemitem>.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>addresses</primary><secondary>broadcast</secondary></indexterm>
|
|
You may have noticed that not all possible values in the previous list
|
|
were allowed for each octet in the host part. This is because octets
|
|
<systemitem role="sitename">0</systemitem> and <systemitem
|
|
role="sitename">255</systemitem> are reserved for special purposes.
|
|
An address where all host part bits are 0 refers to the network, and
|
|
an address where all bits of the host part are 1 is called a
|
|
<emphasis>broadcast address</emphasis>. This refers to all hosts on
|
|
the specified network simultaneously. Thus, <systemitem
|
|
role="sitename">149.76.255.255</systemitem> is not a valid host
|
|
address, but refers to all hosts on network <systemitem
|
|
role="sitename">149.76.0.0</systemitem>.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>default
|
|
route</secondary></indexterm>
|
|
<indexterm><primary>route, default</primary></indexterm>
|
|
<indexterm><primary>loopback</primary><secondary>address</secondary></indexterm>
|
|
<indexterm><primary>addresses</primary><secondary>loopback</secondary></indexterm>
|
|
A number of network addresses are reserved for special purposes.
|
|
<systemitem role="sitename">0.0.0.0</systemitem> and <systemitem
|
|
role="sitename">127.0.0.0</systemitem> are two such addresses. The
|
|
first is called the <emphasis>default route</emphasis>, and the latter
|
|
is the <emphasis>loopback address</emphasis>. The default route has to
|
|
do with the way the IP routes datagrams.
|
|
</para>
|
|
|
|
<para>
|
|
Network <systemitem role="sitename">127.0.0.0</systemitem> is reserved for
|
|
IP traffic local to your host. Usually, address
|
|
<systemitem role="sitename">127.0.0.1</systemitem> will be assigned to a special
|
|
interface on your host, the <emphasis>loopback interface</emphasis>, which
|
|
acts like a closed circuit. Any IP packet handed to this interface from
|
|
TCP or UDP will be returned to them as if it had just arrived from some
|
|
network. This allows you to develop and test networking software without
|
|
ever using a “real” network. The loopback network also allows
|
|
you to use networking software on a standalone host. This may not be as
|
|
uncommon as it sounds; for instance, many UUCP sites don't have IP
|
|
connectivity at all, but still want to run the INN news system. For
|
|
proper operation on Linux, INN requires the loopback interface.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>private addresses</secondary></indexterm>
|
|
Some address ranges from each of the network classes have been set
|
|
aside and designated “reserved” or “private”
|
|
address ranges. These addresses are reserved for use by private
|
|
networks and are not routed on the Internet. They are commonly used by
|
|
organizations building their own intranet, but even small networks
|
|
often find them useful. The reserved network addresses appear in <xref
|
|
linkend="X-087-2-issues.reserved.addresses">.
|
|
</para>
|
|
|
|
<table id="X-087-2-issues.reserved.addresses">
|
|
<title>IP Address Ranges Reserved for Private Use</title>
|
|
<tgroup cols=2>
|
|
<thead>
|
|
<row>
|
|
<entry>Class</entry>
|
|
<entry>Networks</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>A</entry>
|
|
<entry>10.0.0.0 through 10.255.255.255</entry>
|
|
</row>
|
|
<row>
|
|
<entry>B</entry>
|
|
<entry>172.16.0.0 through 172.31.0.0</entry>
|
|
</row>
|
|
<row>
|
|
<entry>C</entry>
|
|
<entry>192.168.0.0 through 192.168.255.0</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
|
|
<para>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>addresses</secondary></indexterm>
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-issues.arp"><title>Address Resolution</title>
|
|
<indexterm id="chis.arp1" class=startofrange><primary>ARP (Address Resolution Protocol)</primary></indexterm>
|
|
<indexterm><primary>Ethernet</primary><secondary>addresses</secondary></indexterm>
|
|
<para>
|
|
Now that you've seen how IP addresses are composed, you may be wondering
|
|
how they are used on an Ethernet or Token Ring network to address different
|
|
hosts. After all, these protocols have their own addresses to identify hosts
|
|
that have absolutely nothing in common with an IP address, don't they? Right.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>ham radio</primary></indexterm>
|
|
<indexterm><primary>Token Ring</primary><secondary>ARP and</secondary></indexterm>
|
|
A mechanism is needed to map IP addresses onto the addresses of the
|
|
underlying network. The mechanism used is the <emphasis>Address
|
|
Resolution Protocol</emphasis> (ARP). In fact, ARP is not confined to
|
|
Ethernet or Token Ring, but is used on other types of networks, such
|
|
as the amateur radio AX.25 protocol. The idea underlying ARP is
|
|
exactly what most people do when they have to find Mr. X in a throng
|
|
of 150 people: the person who wants him calls out loudly enough that
|
|
everyone in the room can hear them, expecting him to respond if he is
|
|
there. When he responds, we know which person he is.
|
|
</para>
|
|
|
|
<para>
|
|
When ARP wants to find the Ethernet address corresponding to a given
|
|
IP address, it uses an Ethernet feature called <emphasis>broadcasting</emphasis>, in which a datagram is addressed to
|
|
all stations on the network simultaneously. The broadcast datagram
|
|
sent by ARP contains a query for the IP address. Each receiving host
|
|
compares this query to its own IP address and if it matches, returns
|
|
an ARP reply to the inquiring host. The inquiring host can now
|
|
extract the sender's Ethernet address from the reply.
|
|
</para>
|
|
|
|
<para>
|
|
You may wonder how a host can reach an Internet address that may be on
|
|
a different network halfway around the world. The answer to this
|
|
question involves <emphasis>routing</emphasis>, namely finding the
|
|
physical location of a host in a network. We will discuss this issue
|
|
further in the next section.
|
|
</para>
|
|
<?troff .Nd 15>
|
|
<para>
|
|
Let's talk a little more about ARP. Once a host has discovered an
|
|
Ethernet address, it stores it in its ARP cache so that it doesn't
|
|
have to query for it again the next time it wants to send a datagram
|
|
to the host in question. However, it is unwise to keep this
|
|
information forever; the remote host's Ethernet card may be replaced
|
|
because of technical problems, so the ARP entry becomes
|
|
invalid. Therefore, entries in the ARP cache are discarded after some
|
|
time to force another query for the IP address.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>diskless clients</primary></indexterm>
|
|
<indexterm><primary>BOOTP</primary></indexterm>
|
|
<indexterm><primary>RARP (Reverse Address Resolution Protocol)</primary></indexterm>
|
|
<indexterm><primary>RARP (Reverse Address Resolution Protocol)</primary></indexterm>
|
|
Sometimes it is also necessary to find the IP address associated with
|
|
a given Ethernet address. This happens when a diskless machine wants
|
|
to boot from a server on the network, which is a common situation on
|
|
Local Area Networks. A diskless client, however, has virtually no
|
|
information about itself—except for its Ethernet address! So it
|
|
broadcasts a message containing a request asking a boot server to
|
|
provide it with an IP address. There's another protocol for this
|
|
situation named <emphasis>Reverse Address Resolution
|
|
Protocol</emphasis> (RARP). Along with the BOOTP protocol, it serves
|
|
to define a procedure for bootstrapping diskless clients over the
|
|
network.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm startref="chis.arp1" class=endofrange>
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-issues.routing"><title>IP Routing</title>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>routing</secondary></indexterm>
|
|
<indexterm><primary>routing</primary><secondary>IP</secondary></indexterm>
|
|
<para>
|
|
We now take up the question of finding the host that datagrams go to
|
|
based on the IP address. Different parts of the address are handled in
|
|
different ways; it is your job to set up the files that indicate how to treat
|
|
each part.
|
|
</para>
|
|
|
|
<sect2 id="X-087-2-issues.routing.networks"><title>IP Networks</title>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>networks</secondary></indexterm>
|
|
<para>
|
|
When you write a letter to someone, you usually put a complete address
|
|
on the envelope specifying the country, state, and Zip Code. After you
|
|
put it in the mailbox, the post office will deliver it to its
|
|
destination: it will be sent to the country indicated, where the
|
|
national service will dispatch it to the proper state and region. The
|
|
advantage of this hierarchical scheme is obvious: wherever you
|
|
post the letter, the local postmaster knows roughly which direction to
|
|
forward the letter, but the postmaster doesn't care which way the
|
|
letter will travel once it reaches its country of destination.
|
|
</para>
|
|
|
|
<para>
|
|
IP networks are structured similarly. The whole Internet consists of a
|
|
number of proper networks, called <emphasis>autonomous
|
|
systems</emphasis>. Each system performs routing between its member
|
|
hosts internally so that the task of delivering a datagram is reduced
|
|
to finding a path to the destination host's network. As soon as the
|
|
datagram is handed to <emphasis>any</emphasis> host on that particular
|
|
network, further processing is done exclusively by the network itself.
|
|
</para>
|
|
|
|
<?troff .Nd 10>
|
|
</sect2>
|
|
|
|
<sect2 id="X-087-2-issues.routing.subnets"><title>Subnetworks</title>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>subnets</secondary></indexterm>
|
|
<indexterm><primary>subnets</primary><secondary>IP</secondary></indexterm>
|
|
<para>
|
|
This structure is reflected by splitting IP addresses into a host and
|
|
network part, as explained previously. By default, the destination network is
|
|
derived from the network part of the IP address. Thus, hosts with identical
|
|
IP <emphasis>network</emphasis> numbers should be found within the same
|
|
network.<footnote id="X-087-2-FNIS03"><para>
|
|
Autonomous systems are slightly more general. They may comprise more than
|
|
one IP network.
|
|
</para>
|
|
</footnote>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
It makes sense to offer a similar scheme <emphasis>inside</emphasis> the
|
|
network, too, since it may consist of a collection of hundreds of smaller
|
|
networks, with the smallest units being physical networks like Ethernets.
|
|
Therefore, IP allows you to subdivide an IP network into several
|
|
<emphasis>subnets</emphasis>.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>interfaces</primary><secondary>netmask</secondary></indexterm>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>netmask</secondary></indexterm>
|
|
A subnet takes responsibility for delivering datagrams to a certain range
|
|
of IP addresses. It is an extension of the concept of splitting bit fields,
|
|
as in the A, B, and C classes. However, the network part is now extended
|
|
to include some bits from the host part. The number of bits that are
|
|
interpreted as the subnet number is given by the so-called
|
|
<emphasis>subnet mask</emphasis>, or <emphasis>netmask</emphasis>. This is a
|
|
32-bit number too, which specifies the bit mask for the network part of the
|
|
IP address.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Groucho Marx University (GMU)</primary></indexterm>
|
|
The campus network of Groucho Marx University is an example of such a
|
|
network. It has a class B network number of
|
|
<systemitem role="sitename">149.76.0.0</systemitem>, and its
|
|
netmask is therefore <systemitem role="sitename">255.255.0.0</systemitem>.
|
|
</para>
|
|
|
|
<para>
|
|
Internally, GMU's campus network consists of several smaller networks,
|
|
such various departments' LANs. So the range of IP addresses is broken
|
|
up into 254 subnets, <systemitem
|
|
role="sitename">149.76.1.0</systemitem> through <systemitem
|
|
role="sitename">149.76.254.0</systemitem>. For example, the department
|
|
of Theoretical Physics has been assigned <systemitem
|
|
role="sitename">149.76.12.0</systemitem>. The campus backbone is a
|
|
network in its own right, and is given <systemitem
|
|
role="sitename">149.76.1.0</systemitem>. These subnets share the same
|
|
IP network number, while the third octet is used to distinguish
|
|
between them. They will thus use a subnet mask of <systemitem
|
|
role="sitename">255.255.255.0</systemitem>.
|
|
</para>
|
|
|
|
<para>
|
|
<xref linkend="X-087-2-issues.fig.subnet"> shows how <systemitem
|
|
role="sitename">149.76.12.4</systemitem>, the address of <systemitem
|
|
role="sitename">quark</systemitem>, is interpreted differently when
|
|
the address is taken as an ordinary class B network and when used with
|
|
subnetting.
|
|
</para>
|
|
|
|
<figure id="X-087-2-issues.fig.subnet">
|
|
<title>Subnetting a class B network</title>
|
|
<!-- <graphic fileref="lag2_0201.jpg"></graphic> -->
|
|
<!-- 2016-01-28; MAB, TLDP -->
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/lag2_0201.jpg" format="jpg">
|
|
</imageobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/lag2_0201.eps" format="eps">
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<para>
|
|
<indexterm><primary>delegating</primary><secondary>IP subnets</secondary></indexterm>
|
|
<indexterm><primary>subnets</primary><secondary>IP</secondary></indexterm>
|
|
It is worth noting that <emphasis>subnetting</emphasis> (the technique
|
|
of generating subnets) is only an <emphasis>internal
|
|
division</emphasis> of the network. Subnets are generated by the
|
|
network owner (or the administrators). Frequently, subnets are created
|
|
to reflect existing boundaries, be they physical (between two
|
|
Ethernets), administrative (between two departments), or geographical
|
|
(between two locations), and authority over each subnet is delegated
|
|
to some contact person. However, this structure affects only the
|
|
network's internal behavior, and is completely invisible to the
|
|
outside world.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="X-087-2-issues.routing.gateway"><title>Gateways</title>
|
|
<indexterm><primary>internetworking</primary></indexterm>
|
|
<indexterm><primary>gateways</primary></indexterm>
|
|
|
|
<para>
|
|
Subnetting is not only a benefit to the organization; it is frequently
|
|
a natural consequence of hardware boundaries. The viewpoint of a host
|
|
on a given physical network, such as an Ethernet, is a very limited
|
|
one: it can only talk to the host of the network it is on. All other
|
|
hosts can be accessed only through special-purpose machines called
|
|
<emphasis>gateways</emphasis>. A gateway is a host that is connected
|
|
to two or more physical networks simultaneously and is configured to
|
|
switch packets between them.
|
|
</para>
|
|
|
|
<para>
|
|
<xref linkend="X-087-2-issues.fig.ip"> shows part of the network topology at
|
|
Groucho Marx University (GMU). Hosts that are on two subnets at the same
|
|
time are shown with both addresses.
|
|
</para>
|
|
|
|
<figure id="X-087-2-issues.fig.ip">
|
|
<title>A part of the net topology at Groucho Marx University</title>
|
|
<!-- <graphic fileref="lag2_0202.jpg"></graphic> -->
|
|
<!-- 2016-01-28; MAB, TLDP -->
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/lag2_0202.jpg" format="jpg">
|
|
</imageobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/lag2_0202.eps" format="eps">
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<para>
|
|
Different physical networks have to belong to different IP networks for IP to
|
|
be able to recognize if a host is on a local network. For example, the
|
|
network number
|
|
<systemitem role="sitename">149.76.4.0</systemitem> is reserved for hosts on
|
|
the mathematics LAN. When sending a datagram to
|
|
<systemitem role="sitename">quark</systemitem>, the network software on
|
|
<systemitem role="sitename">erdos</systemitem> immediately sees from the IP
|
|
address <systemitem role="sitename">149.76.12.4</systemitem> that the
|
|
destination host is on a different physical network, and therefore can be
|
|
reached only through a gateway (<systemitem role="sitename">sophus</systemitem>
|
|
by default).
|
|
</para>
|
|
|
|
<para>
|
|
<systemitem role="sitename">sophus</systemitem> itself is connected to two
|
|
distinct subnets: the Mathematics department and the campus backbone. It
|
|
accesses each through a different interface, <filename>eth0</filename> and
|
|
<filename>fddi0</filename>, respectively. Now, what IP address do we assign
|
|
it? Should we give it one on subnet
|
|
<systemitem role="sitename">149.76.1.0</systemitem>, or on
|
|
<systemitem role="sitename">149.76.4.0</systemitem>?
|
|
</para>
|
|
|
|
<para>
|
|
The answer is: “both.”
|
|
<systemitem role="sitename">sophus</systemitem> has been assigned the address
|
|
<systemitem role="sitename">149.76.1.1</systemitem> for use on the
|
|
<systemitem role="sitename">149.76.1.0</systemitem> network and address
|
|
<systemitem role="sitename">149.76.4.1</systemitem> for use on the
|
|
<systemitem role="sitename">149.76.4.0</systemitem> network. A gateway must be
|
|
assigned one IP address for each network it belongs to. These<?troff .nD 10> addresses—along with the corresponding netmask—are tied to
|
|
the interface through which the subnet is accessed. Thus, the interface and
|
|
address mapping for <systemitem role="sitename">sophus</systemitem>
|
|
would look like this:
|
|
</para>
|
|
|
|
<informaltable>
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>Interface</entry>
|
|
<entry>Address</entry>
|
|
<entry>Netmask</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry><filename>eth0</filename></entry>
|
|
<entry>149.76.4.1</entry>
|
|
<entry>255.255.255.0</entry>
|
|
</row>
|
|
<row>
|
|
<entry><filename>fddi0</filename></entry>
|
|
<entry>149.76.1.1</entry>
|
|
<entry>255.255.255.0</entry>
|
|
</row>
|
|
<row>
|
|
<entry><filename>lo</filename></entry>
|
|
<entry>127.0.0.1</entry>
|
|
<entry>255.0.0.0</entry>
|
|
</row>
|
|
</tbody></tgroup>
|
|
</informaltable>
|
|
|
|
<?troff .Nd 7>
|
|
<para>
|
|
The last entry describes the loopback interface <filename>lo</filename>, which
|
|
we talked about earlier.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>gateways</primary></indexterm>
|
|
Generally, you can ignore the subtle difference between attaching an
|
|
address to a host or its interface. For hosts that are on one network
|
|
only, like <systemitem role="sitename">erdos</systemitem>, you would generally
|
|
refer to the host as having this-and-that IP address, although strictly
|
|
speaking, it's the Ethernet interface that has this IP address. The
|
|
distinction is really important only when you refer to a gateway.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="X-087-2-issues.routing.table"><title>The Routing Table</title>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>routing</secondary><tertiary>table</tertiary></indexterm>
|
|
<indexterm><primary>routing table</primary></indexterm>
|
|
|
|
<para>
|
|
We now focus our attention on how IP chooses a gateway to use to deliver
|
|
a datagram to a remote network.
|
|
</para>
|
|
|
|
<para>
|
|
We have seen that <systemitem role="sitename">erdos</systemitem>, when
|
|
given a datagram for <systemitem role="sitename">quark</systemitem>,
|
|
checks the destination address and finds that it is not on the local
|
|
network. <systemitem role="sitename">erdos</systemitem> therefore
|
|
sends the datagram to the default gateway <systemitem
|
|
role="sitename">sophus</systemitem>, which is now faced with the same
|
|
task. <systemitem role="sitename">sophus</systemitem> recognizes that
|
|
<systemitem role="sitename">quark</systemitem> is not on any of the
|
|
networks it is connected to directly, so it has to find yet another
|
|
gateway to forward it through. The correct choice would be <systemitem
|
|
role="sitename">niels</systemitem>, the gateway to the Physics
|
|
department. <systemitem role="sitename">sophus</systemitem> thus
|
|
needs information to associate a destination network with a
|
|
suitable gateway.
|
|
</para>
|
|
|
|
<para>
|
|
IP uses a table for this task that associates networks with the
|
|
gateways by which they may be reached. A catch-all entry (the
|
|
<emphasis>default route</emphasis>) must generally be supplied too;
|
|
this is the gateway associated with network <systemitem
|
|
role="sitename">0.0.0.0</systemitem>. All destination addresses match
|
|
this route, since none of the 32 bits are required to match, and
|
|
therefore packets to an unknown network are sent through the default
|
|
route. On <systemitem role="sitename">sophus</systemitem>, the table
|
|
might look like this:
|
|
</para>
|
|
|
|
<informaltable>
|
|
<tgroup cols="4">
|
|
<thead>
|
|
<row>
|
|
<entry>Network</entry>
|
|
<entry>Netmask</entry>
|
|
<entry>Gateway</entry>
|
|
<entry>Interface</entry>
|
|
</row>
|
|
</thead>
|
|
<tbody>
|
|
<row>
|
|
<entry>149.76.1.0</entry>
|
|
<entry>255.255.255.0</entry>
|
|
<entry>-</entry>
|
|
<entry><filename>fddi0</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry>149.76.2.0</entry>
|
|
<entry>255.255.255.0</entry>
|
|
<entry>149.76.1.2</entry>
|
|
<entry><filename>fddi0</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry>149.76.3.0</entry>
|
|
<entry>255.255.255.0</entry>
|
|
<entry>149.76.1.3</entry>
|
|
<entry><filename>fddi0</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry>149.76.4.0</entry>
|
|
<entry>255.255.255.0</entry>
|
|
<entry>-</entry>
|
|
<entry><filename>eth0</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry>149.76.5.0</entry>
|
|
<entry>255.255.255.0</entry>
|
|
<entry>149.76.1.5</entry>
|
|
<entry><filename>fddi0</filename></entry>
|
|
</row>
|
|
<row>
|
|
<entry>…</entry>
|
|
<entry>…</entry>
|
|
<entry>…</entry>
|
|
<entry>…</entry>
|
|
</row>
|
|
<row>
|
|
<entry>0.0.0.0</entry>
|
|
<entry>0.0.0.0</entry>
|
|
<entry>149.76.1.2</entry>
|
|
<entry><filename>fddi0</filename></entry>
|
|
</row>
|
|
</tbody></tgroup>
|
|
</informaltable>
|
|
|
|
<para>
|
|
If you need to use a route to a network that <systemitem
|
|
role="sitename">sophus</systemitem> is directly connected to, you
|
|
don't need a gateway; the gateway column here contains a hyphen.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>routing</secondary><tertiary>effect of netmask</tertiary></indexterm>
|
|
The process for identifying whether a particular destination address
|
|
matches a route is a mathematical operation. The process is quite
|
|
simple, but it requires an understanding of binary arithmetic and
|
|
logic: A route matches a destination if the network
|
|
address logically ANDed with the netmask precisely equals the
|
|
destination address logically ANDed with the
|
|
netmask. </para>
|
|
<para>
|
|
Translation: a route matches if the
|
|
number of bits of the network address specified by the netmask
|
|
(starting from the left-most bit, the high order bit of byte one of
|
|
the address) match that same number of bits in the destination
|
|
address.
|
|
</para>
|
|
|
|
<para>
|
|
When the IP implementation is searching for the best route to a
|
|
destination, it may find a number of routing entries that match the
|
|
target address. For example, we know that the default route matches
|
|
every destination, but datagrams destined for locally attached
|
|
networks will match their local route, too. How does IP know which
|
|
route to use? It is here that the netmask plays an important
|
|
role. While both routes match the destination, one of the routes has a
|
|
larger netmask than the other. We previously mentioned that the
|
|
netmask was used to break up our address space into smaller
|
|
networks. The larger a netmask is, the more specifically a target
|
|
address is matched; when routing datagrams, we should always choose
|
|
the route that has the largest netmask. The default route has a
|
|
netmask of zero bits, and in the configuration presented above, the
|
|
locally attached networks have a 24-bit netmask. If a datagram matches
|
|
a locally attached network, it will be routed to the appropriate device
|
|
in preference to following the default route because the local network
|
|
route matches with a greater number of bits. The only datagrams that
|
|
will be routed via the default route are those that don't match any
|
|
other route.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>dynamic
|
|
routing</secondary></indexterm>
|
|
<indexterm><primary>dynamic routing</primary></indexterm>
|
|
<indexterm><primary>routing</primary><secondary>daemon</secondary></indexterm>
|
|
<indexterm><primary>routing</primary><secondary>dynamic</secondary></indexterm>
|
|
You can build routing tables by a variety of means. For small LANs, it
|
|
is usually most efficient to construct them by hand and feed them to
|
|
IP using the <command>route</command> command at boot time (see <xref
|
|
linkend="X-087-2-iface">). For larger networks, they are built and
|
|
adjusted at runtime by <emphasis>routing daemons</emphasis>; these
|
|
daemons run on central hosts of the network and exchange routing
|
|
information to compute “optimal” routes between the member
|
|
networks.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>routing</secondary><tertiary>protocols</tertiary></indexterm>
|
|
<indexterm><primary>routing</primary><secondary>protocols</secondary></indexterm>
|
|
<indexterm><primary>Routing Information Protocol (RIP)</primary></indexterm>
|
|
<INDEXTERM><PRIMARY>RIP (Routing Information Protocol)</PRIMARY></INDEXTERM>
|
|
<indexterm><primary>routed command</primary></indexterm>
|
|
<indexterm><primary>gated command</primary></indexterm>
|
|
Depending on the size of the network, you'll need to use different
|
|
routing protocols. For routing inside autonomous systems (such as the
|
|
Groucho Marx campus), the <emphasis>internal routing
|
|
protocols</emphasis> are used. The most prominent one of these is the
|
|
<emphasis>Routing Information Protocol</emphasis> (RIP), which is
|
|
implemented by the BSD <command>routed</command> daemon. For routing
|
|
between autonomous systems, <emphasis>external routing
|
|
protocols</emphasis> like <emphasis>External Gateway
|
|
Protocol</emphasis> (EGP) or <emphasis>Border Gateway
|
|
Protocol</emphasis> (BGP) have to be used; these protocols, including
|
|
RIP, have been implemented in the University of Cornell's
|
|
<command>gated</command> daemon.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="X-087-2-issues.routing.metric"><title>Metric Values</title>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>metric</secondary><tertiary>values</tertiary></indexterm>
|
|
<indexterm><primary>routing</primary><secondary>metric</secondary></indexterm>
|
|
<indexterm><primary>metric values (for routing table entries)</primary></indexterm>
|
|
|
|
<para>
|
|
<?troff .hw discarded>
|
|
We depend on dynamic routing to choose the best route to a destination
|
|
host or network based on the number of <emphasis>hops</emphasis>. Hops
|
|
are the gateways a datagram has to pass before reaching a host or
|
|
network. The shorter a route is, the better RIP rates it. Very long
|
|
routes with 16 or more hops are regarded as unusable and are
|
|
discarded.
|
|
</para>
|
|
|
|
<para>
|
|
RIP manages routing information internal to your local network, but
|
|
you have to run <command>gated</command> on all hosts. At boot time,
|
|
<command>gated</command> checks for all active network interfaces. If
|
|
there is more than one active interface (not counting the loopback
|
|
interface), it assumes the host is switching packets between several
|
|
networks and will actively exchange and broadcast routing
|
|
information. Otherwise, it will only passively receive RIP updates and
|
|
update the local routing table.
|
|
</para>
|
|
|
|
<para>
|
|
When broadcasting information from the local routing table,
|
|
<command>gated</command> computes the length of the route from the
|
|
so-called <emphasis>metric value</emphasis> associated with the
|
|
routing table entry. This metric value is set by the system
|
|
administrator when configuring the route, and should reflect the
|
|
actual route cost.<footnote id="X-087-2-FNIS05"><para> The cost of a
|
|
route can be thought of, in a simple case, as the number of hops
|
|
required to reach the destination. Proper calculation of route costs
|
|
can be a fine art in complex network designs.
|
|
</para>
|
|
</footnote> Therefore, the metric of a route to a subnet that the host
|
|
is directly connected to should always be zero, while a route going
|
|
through two gateways should have a metric of two. You don't have to bother
|
|
with metrics if you don't use <command>RIP</command> or
|
|
<command>gated</command>.
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-issues.icmp"><title>The Internet Control Message Protocol</title>
|
|
|
|
<para>
|
|
<indexterm><primary>protocols</primary><secondary>ICMP</secondary></indexterm>
|
|
<indexterm><primary>ICMP (Internet Control Message Protocol)</primary><secondary>Port Unreachable message</secondary></indexterm>
|
|
IP has a companion protocol that we haven't talked about yet. This is
|
|
the <emphasis>Internet Control Message Protocol</emphasis> (ICMP),
|
|
used by the kernel networking code to communicate error messages to
|
|
other hosts. For instance, assume that you are on <systemitem
|
|
role="sitename">erdos</systemitem> again and want to
|
|
<command>telnet</command> to port 12345 on <systemitem
|
|
role="sitename">quark</systemitem>, but there's no process listening
|
|
on that port. When the first TCP packet for this port arrives on
|
|
<systemitem role="sitename">quark</systemitem>, the networking layer
|
|
will recognize this arrival and immediately return an ICMP message to
|
|
<systemitem role="sitename">erdos</systemitem> stating “Port
|
|
Unreachable.”
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>ICMP (Internet Control Message Protocol)</primary><secondary>Redirect message</secondary></indexterm>
|
|
<indexterm><primary>routing</primary><secondary>ICMP Redirect</secondary></indexterm>
|
|
<indexterm><primary>routing</primary><secondary>dynamic</secondary></indexterm>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>routing</secondary><tertiary>Redirect message (ICMP)</tertiary></indexterm>
|
|
The ICMP protocol provides several different messages, many of which
|
|
deal with error conditions. However, there is one very interesting
|
|
message called the Redirect message. It is generated by the routing
|
|
module when it detects that another host is using it as a gateway,
|
|
even though a much shorter route exists. For example, after booting, the
|
|
routing table of <systemitem role="sitename">sophus</systemitem> may be
|
|
incomplete. It might contain the routes to the Mathematics network, to the
|
|
FDDI backbone, and the default route pointing at the Groucho Computing
|
|
Center's gateway ( gcc1). Thus, packets for <systemitem role="sitename">quark</systemitem> would be sent
|
|
to <systemitem role="sitename">gcc1</systemitem> rather than to
|
|
<systemitem role="sitename">niels</systemitem>, the gateway to the Physics
|
|
department. When receiving such a datagram,
|
|
<systemitem role="sitename">gcc1</systemitem> will notice that this is a poor
|
|
choice of route and will forward the packet to
|
|
<systemitem role="sitename">niels</systemitem>, meanwhile returning an
|
|
ICMP Redirect message to <systemitem role="sitename">sophus</systemitem> telling it of the superior route.
|
|
</para>
|
|
|
|
<para>
|
|
This seems to be a very clever way to avoid manually setting up any
|
|
but the most basic routes. However, be warned that relying on dynamic
|
|
routing schemes, be it RIP or ICMP Redirect messages, is not always a
|
|
good idea. ICMP Redirect and RIP offer you little or no choice in
|
|
verifying that some routing <?troff .ne 10>information is indeed authentic. This
|
|
situation allows malicious good-for-nothings to disrupt your entire
|
|
network traffic, or even worse. Consequently, the Linux networking
|
|
code treats Network Redirect messages as if they were Host Redirects.
|
|
This minimizes the damage of an attack by restricting it to just one
|
|
host, rather than the whole network. On the flip side, it means that a
|
|
little more traffic is generated in the event of a legitimate
|
|
condition, as each host causes the generation of an ICMP Redirect
|
|
message. It is generally considered bad practice to rely on ICMP
|
|
redirects for anything these days.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-issues.resolving"><title>Resolving Host Names</title>
|
|
<indexterm id="chis.dns.1" class=startofrange><primary>DNS (Domain Name System)</primary></indexterm>
|
|
<indexterm><primary>hostname</primary><secondary>resolution</secondary></indexterm>
|
|
<indexterm><primary>hostname</primary><secondary>mapping to addresses</secondary></indexterm>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>addresses</secondary><tertiary>hostname and</tertiary></indexterm>
|
|
|
|
<para>
|
|
As described previously, addressing in TCP/IP networking, at least for
|
|
IP Version 4, revolves around 32-bit numbers. However, you will have a
|
|
hard time remembering more than a few of these numbers. Therefore,
|
|
hosts are generally known by “ordinary” names such as
|
|
<systemitem role="sitename">gauss</systemitem> or <systemitem
|
|
role="sitename">strange</systemitem>. It becomes the application's
|
|
duty to find the IP address corresponding to this name. This process
|
|
is called <emphasis>hostname resolution</emphasis>.
|
|
</para>
|
|
|
|
<indexterm><primary>gethostbyname( )</primary></indexterm>
|
|
<indexterm><primary>gethostbyaddr( )</primary></indexterm>
|
|
<para>
|
|
When an application needs to find the IP address of a given host, it
|
|
relies on the library functions <function>gethostbyname(3)</function>
|
|
and <function>gethostbyaddr(3)</function>. Traditionally, these and a
|
|
number of related procedures were grouped in a separate library called
|
|
the <emphasis>resolverlibrary</emphasis> ; on Linux, these functions
|
|
are part of the standard <filename>libc</filename>. Colloquially, this
|
|
collection of functions is therefore referred to as “the
|
|
resolver.” Resolver name configuration is detailed in <xref
|
|
linkend="X-087-2-resolv">.
|
|
</para>
|
|
|
|
<para>
|
|
On a small network like an Ethernet or even a cluster of Ethernets, it
|
|
is not very difficult to maintain tables mapping hostnames to
|
|
addresses. This information is usually kept in a file named
|
|
<filename>/etc/hosts</filename>. When adding or removing hosts, or
|
|
reassigning addresses, all you have to do is update the
|
|
<filename>hosts</filename> file on all hosts. Obviously, this will
|
|
become burdensome with networks that comprise more than a handful of
|
|
machines.
|
|
</para>
|
|
|
|
<indexterm><primary>NIS (Network Information System)</primary></indexterm>
|
|
<indexterm><primary>Yellow Pages (YP)</primary></indexterm>
|
|
<para>
|
|
One solution to this problem is the <emphasis>Network Information
|
|
System</emphasis> (NIS), developed by Sun Microsystems, colloquially
|
|
called YP or Yellow Pages. NIS stores the <filename>hosts</filename>
|
|
file (and other information) in a database on a master host from which clients
|
|
may retrieve it as needed. Still, this approach is suitable only for
|
|
medium-sized networks such as LANs, because it involves maintaining
|
|
the entire <filename>hosts</filename> database centrally and distributing
|
|
it to all servers. NIS installation and configuration is discussed in
|
|
detail in <xref linkend="X-087-2-nis">.
|
|
</para>
|
|
|
|
<para>
|
|
On the Internet, address information was initially stored in a single
|
|
<filename>HOSTS.TXT</filename> database, too. This file was maintained at
|
|
the <emphasis>Network Information Center</emphasis> (NIC), and had to
|
|
be downloaded and installed by all participating sites. When the network
|
|
grew, several problems with this scheme arose. Besides the administrative
|
|
overhead involved in installing <filename>HOSTS.TXT</filename> regularly,
|
|
the load on the servers that distributed it became too high. Even more
|
|
severe, all names had to be registered with the NIC, which made sure that
|
|
no name was issued twice.
|
|
</para>
|
|
|
|
<para>
|
|
This is why a new name resolution scheme was adopted in 1994: the
|
|
<emphasis>Domain Name System</emphasis>. DNS was designed by Paul
|
|
Mockapetris and addresses both problems simultaneously. We discuss the
|
|
Domain Name System in detail in <xref linkend="X-087-2-resolv">.
|
|
</para>
|
|
|
|
<INDEXTERM startref="chis.dns.1" class=endofrange>
|
|
|
|
</sect1>
|
|
<INDEXTERM startref="chis.tcp.ip.networks" class=endofrange>
|
|
<INDEXTERM startref="chis.networks.tcp.ip" class=endofrange>
|
|
</chapter>
|
|
|
|
|