mirror of https://github.com/tLDP/LDP
1298 lines
65 KiB
Plaintext
1298 lines
65 KiB
Plaintext
<chapter id="X-087-2-intro"><title>Introduction <?lb>to Networking</title>
|
|
<sect1 id="X-087-2-intro.history"><title>History</title>
|
|
|
|
<para>
|
|
<indexterm id="chit.netwks.intro"
|
|
class="startofrange"><primary>networks</primary><secondary>introduction
|
|
to</secondary></indexterm> The idea of networking is probably as old
|
|
as telecommunications itself. Consider people living in the Stone
|
|
Age, when drums may have been used to transmit messages between
|
|
individuals. Suppose caveman A wants to invite caveman B over for a
|
|
game of hurling rocks at each other, but they live too far apart for B
|
|
to hear A banging his drum. What are A's options? He could 1) walk
|
|
over to B's place, 2) get a bigger drum, or 3) ask C, who lives
|
|
halfway between them, to forward the message. The last option is
|
|
called <emphasis>networking</emphasis>.
|
|
</para>
|
|
|
|
<para>
|
|
Of course, we have come a long way from the primitive pursuits and devices of
|
|
our forebears. Nowadays, we have computers talk to each other over vast
|
|
assemblages of wires, fiber optics, microwaves, and the like, to make an
|
|
appointment for Saturday's soccer match.<footnote id="X-087-2-FNIT01"><para>
|
|
The original spirit of which (see above) still shows on some occasions in
|
|
Europe.
|
|
</para>
|
|
</footnote>
|
|
In the following description, we will deal with the means and ways by which
|
|
this is accomplished, but leave out the wires, as well as the soccer part.
|
|
</para>
|
|
|
|
<para>
|
|
We will describe three types of networks in this guide. We will focus on
|
|
TCP/IP most heavily because it is the most popular protocol suite in use on
|
|
both Local Area Networks (LANs) and Wide Area Networks (WANs), such as the
|
|
Internet. We will also take a look at UUCP and IPX. UUCP was once commonly
|
|
used to transport news and mail messages over dialup telephone connections.
|
|
It is less common today, but is still useful in a variety of situations. The
|
|
IPX protocol is used most commonly in the Novell NetWare environment and we'll
|
|
describe how to use it<?troff .ne 7> to connect your Linux machine into a Novell network.
|
|
Each of these protocols are networking protocols and are used to carry data
|
|
between host computers. We'll discuss how they are used and introduce you to
|
|
their underlying principles.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>sites</primary></indexterm>
|
|
<indexterm><primary>hosts</primary></indexterm> We define a network as
|
|
a collection of <emphasis>hosts</emphasis> that are able to
|
|
communicate with each other, often by relying on the services of a
|
|
number of dedicated hosts that relay data between the
|
|
participants. Hosts are often computers, but need not be; one can also
|
|
think of X terminals or intelligent printers as hosts. Small
|
|
agglomerations of hosts are also called <emphasis>sites</emphasis>.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>networks</primary><secondary>protocols</secondary></indexterm>
|
|
<indexterm><primary>protocols</primary></indexterm> Communication is
|
|
impossible without some sort of language or code. In computer
|
|
networks, these languages are collectively referred to as
|
|
<emphasis>protocols</emphasis>. However, you shouldn't think of
|
|
written protocols here, but rather of the highly formalized code of
|
|
behavior observed when heads of state meet, for instance. In a very
|
|
similar fashion, the protocols used in computer networks are nothing
|
|
but very strict rules for the exchange of messages between two or more
|
|
hosts.
|
|
</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-intro.tcpip"><title>TCP/IP Networks</title>
|
|
|
|
<para>
|
|
<indexterm><primary>networks</primary><secondary>TCP/IP</secondary></indexterm>
|
|
<INDEXTERM id="chit.networks.tcp-ip"
|
|
class=startofrange><PRIMARY>TCP/IP (Transmission Control
|
|
Protocol/Internet
|
|
Protocol)</PRIMARY><SECONDARY>networks</SECONDARY></INDEXTERM>
|
|
<indexterm><primary>Local Area Networks (LANs)</primary></indexterm>
|
|
<indexterm><primary>networks</primary><secondary>Local
|
|
Area</secondary></indexterm>
|
|
<indexterm><primary>networks</primary><secondary>packet-switched</secondary></indexterm>
|
|
<indexterm><primary>packet-switched networks</primary></indexterm>
|
|
Modern networking applications require a sophisticated approach to
|
|
carrying data from one machine to another. If you are managing a Linux
|
|
machine that has many users, each of whom may wish to simultaneously
|
|
connect to remote hosts on a network, you need a way of allowing them
|
|
to share your network connection without interfering with each
|
|
other. The approach that a large number of modern networking protocols
|
|
uses is called <emphasis>packet-switching</emphasis>. A
|
|
<emphasis>packet</emphasis> is a small chunk of data that is
|
|
transferred from one machine to another across the network. The
|
|
switching occurs as the datagram is carried across each link in the
|
|
network. A packet-switched network shares a single network link among
|
|
many users by alternately sending packets from one user to another
|
|
across that link.
|
|
</para>
|
|
|
|
<para>
|
|
<INDEXTERM><PRIMARY>datagrams</PRIMARY></INDEXTERM> The solution that
|
|
Unix systems, and subsequently many non-Unix systems, have adopted is
|
|
known as TCP/IP. When talking about TCP/IP networks you will hear the
|
|
term <emphasis>datagram</emphasis>, which technically has a special
|
|
meaning but is often used interchangeably with
|
|
<emphasis>packet</emphasis>. In this section, we will have a look at
|
|
underlying concepts of the TCP/IP protocols.
|
|
</para>
|
|
|
|
<sect2 id="X-087-2-intro.tcpip.intro"><title>Introduction to TCP/IP Networks</title>
|
|
|
|
<para>
|
|
<indexterm><primary>ARPANET</primary></indexterm>
|
|
<indexterm><primary>networks</primary><secondary>ARPANET</secondary></indexterm>
|
|
TCP/IP traces its origins to a research project funded by the United States
|
|
Defense Advanced Research Projects Agency (DARPA) in 1969. The ARPANET was an
|
|
experimental network that was converted into an operational one in 1975 after
|
|
it had proven to be a success.
|
|
</para>
|
|
<?troff .Nd 7>
|
|
<para>
|
|
<indexterm><primary>networks</primary><secondary>Internet</secondary></indexterm>
|
|
<indexterm><primary>Internet</primary></indexterm>
|
|
<indexterm><primary>networks</primary><secondary>corporate</secondary></indexterm>
|
|
In 1983, the new protocol suite TCP/IP was adopted as a standard, and
|
|
all hosts on the network were required to use it. When ARPANET
|
|
finally grew into the Internet (with ARPANET itself passing out of
|
|
existence in 1990), the use of TCP/IP had spread to networks beyond
|
|
the Internet itself. Many companies have now built corporate TCP/IP
|
|
networks, and the Internet has grown to a point at which it could
|
|
almost be considered a mainstream consumer technology. It is difficult
|
|
to read a newspaper or magazine now without seeing reference to the
|
|
Internet; almost everyone can now use it.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Marx, Groucho</primary></indexterm>
|
|
<indexterm><primary>Groucho Marx University
|
|
(GMU)</primary></indexterm> For something concrete to look at as we
|
|
discuss TCP/IP throughout the following sections, we will consider
|
|
Groucho Marx University (GMU), situated somewhere in Fredland, as an
|
|
example. Most departments run their own Local Area Networks, while
|
|
some share one and others run several of them. They are all
|
|
interconnected and hooked to the Internet through a single high-speed
|
|
link.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>remote</primary><secondary>login</secondary></indexterm>
|
|
Suppose your Linux box is connected to a LAN of Unix hosts at the Mathematics
|
|
department, and its name is <systemitem role="sitename">erdos</systemitem>. To
|
|
access a host at the Physics department, say
|
|
<systemitem role="sitename">quark</systemitem>,
|
|
you enter the following command:
|
|
|
|
<screen>
|
|
$ <userinput>rlogin quark.physics</userinput>
|
|
Welcome to the Physics Department at GMU
|
|
(ttyq2) login:
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>remote</primary><secondary>login</secondary><tertiary>via TCP/IP</tertiary></indexterm>
|
|
At the prompt, you enter your login name, say
|
|
<systemitem role="userid">andres</systemitem>, and your password. You are then
|
|
given a shell<footnote id="X-087-2-FNIT02"><para>
|
|
The shell is a command-line interface to the Unix operating system. It's
|
|
similar to the DOS prompt in a Microsoft Windows environment, albeit much
|
|
more powerful.
|
|
</para>
|
|
</footnote> on <systemitem role="sitename">quark</systemitem>, to which you
|
|
can type as if you were sitting at the system's console. After you exit the
|
|
shell, you are returned to your own machine's prompt. You have just used one
|
|
of the instantaneous, interactive applications that TCP/IP provides: remote
|
|
login.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>remote</primary><secondary>login</secondary><tertiary>X Windows session</tertiary></indexterm>
|
|
<indexterm><primary>X Windows</primary></indexterm>
|
|
<indexterm><primary>DISPLAY (environment variable)</primary></indexterm>
|
|
<indexterm><primary>environment variables</primary><secondary>DISPLAY</secondary></indexterm>
|
|
While being logged into <systemitem role="sitename">quark</systemitem>,
|
|
you might also want to run a graphical user interface application,
|
|
like a word processing program, a graphics drawing program, or even a
|
|
World Wide Web browser. The X windows system is a fully network-aware
|
|
graphical user environment, and it is available for many different
|
|
computing systems. To tell this application that you want to have its
|
|
windows displayed on your host's screen, you have to set the
|
|
<systemitem role="keyword">DISPLAY</systemitem> environment variable:
|
|
<screen>
|
|
$ <userinput>DISPLAY=erdos.maths:0.0</userinput>
|
|
$ <userinput>export DISPLAY</userinput>
|
|
</screen>
|
|
</para>
|
|
|
|
<para>
|
|
If you now start your application, it will contact your X server instead of
|
|
<systemitem role="sitename">quark</systemitem>'s, and display all its windows
|
|
on your screen. Of course, this requires that you have X11 runnning on
|
|
<systemitem role="sitename">erdos</systemitem>. The point here is that TCP/IP
|
|
allows <systemitem role="sitename">quark</systemitem> and
|
|
<systemitem role="sitename">erdos</systemitem> to send X11 packets back and
|
|
forth to give you the illusion that you're on a single system. The network
|
|
is almost transparent here.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>NFS (Network File System)</primary><secondary>via TCP/IP</secondary></indexterm>
|
|
Another very important application in TCP/IP networks is NFS, which
|
|
stands for <emphasis>Network File System</emphasis>. It is another
|
|
form of making the network transparent, because it basically allows
|
|
you to treat directory hierarchies from other hosts as if they
|
|
were local file systems and look like any other directories on your
|
|
host. For example, all users' home directories can be kept on a
|
|
central server machine from which all other hosts on the LAN mount
|
|
them. The effect is that users can log in to any machine and find
|
|
themselves in the same home directory. Similarly, it is possible to
|
|
share large amounts of data (such as a database, documentation or
|
|
application programs) among many hosts by maintaining one copy of
|
|
the data on a server and allowing other hosts to access it. We will
|
|
come back to NFS in <xref linkend="X-087-2-nfs">.
|
|
</para>
|
|
|
|
<para>
|
|
Of course, these are only examples of what you can do with TCP/IP networks.
|
|
The possibilities are almost limitless, and we'll introduce you to more as you
|
|
read on through the book.
|
|
</para>
|
|
|
|
<para>
|
|
We will now have a closer look at the way TCP/IP works. This information will
|
|
help you understand how and why you have to configure your machine. We will
|
|
start by examining the hardware, and slowly work our way up.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="X-087-2-intro.tcpip.history"><title>Ethernets</title>
|
|
|
|
<para>
|
|
<indexterm><primary>protocols</primary><secondary>Ethernet</secondary></indexterm>
|
|
<indexterm><primary>networks</primary><secondary>Ethernet</secondary></indexterm>
|
|
<indexterm><primary>Local Area Networks (LANs)</primary><secondary>hardware for</secondary></indexterm>
|
|
The most common type of LAN hardware is known as <emphasis>Ethernet</emphasis>.
|
|
In its simplest form, it consists of a single cable with hosts attached to it
|
|
through connectors, taps, or transceivers. Simple Ethernets are relatively
|
|
inexpensive to install, which together with a net transfer rate of 10, 100,
|
|
or even 1,000 Megabits per second, accounts for much of its popularity.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Ethernet</primary><secondary>thick/thin</secondary></indexterm>
|
|
<indexterm><primary>Ethernet</primary><secondary>twisted pair</secondary></indexterm>
|
|
<indexterm><primary>thinnet</primary></indexterm>
|
|
<indexterm><primary>BNC connector</primary></indexterm>
|
|
<indexterm><primary>active hubs</primary></indexterm>
|
|
<indexterm><primary>networks</primary><secondary>thinnet</secondary></indexterm>
|
|
Ethernets come in three flavors: <emphasis>thick</emphasis>,
|
|
<emphasis>thin</emphasis>, and <emphasis>twisted pair</emphasis>.
|
|
Thin and thick Ethernet each use a coaxial cable, differing in
|
|
diameter and the way you may attach a host to this cable. Thin
|
|
Ethernet uses a T-shaped “BNC” connector, which you insert
|
|
into the cable and twist onto a plug on the back of your computer.
|
|
Thick Ethernet requires that you drill a small hole into the cable,
|
|
and attach a transceiver using a “vampire tap.” One or
|
|
more hosts can then be connected to the transceiver. Thin and thick
|
|
Ethernet cable can run for a maximum of 200 and 500 meters
|
|
respectively, and are also called 10base-2 and 10base-5. The
|
|
“base” refers to “baseband modulation” and
|
|
simply means that the data is directly fed onto the cable without any
|
|
modem. The number at the start refers to the speed in Megabits per
|
|
second, and the number at the end is the maximum length of the cable
|
|
in hundreds of metres. Twisted pair uses a cable made of two pairs of
|
|
copper wires and usually requires additional hardware known as
|
|
<emphasis>active hubs</emphasis>. Twisted pair is also known as
|
|
10base-T, the “T” meaning twisted pair. The 100 Megabits
|
|
per second version is known as 100base-T.
|
|
</para>
|
|
|
|
<para>
|
|
To add a host to a thin Ethernet installation, you have to disrupt
|
|
network service for at least a few minutes because you have to cut the
|
|
cable to insert the connector. Although adding a host to a thick
|
|
Ethernet system is a little complicated, it does not typically bring
|
|
down the network. Twisted pair Ethernet is even simpler. It uses a
|
|
device called a “hub,” which serves as an interconnection
|
|
point. You can insert and remove hosts from a hub without interrupting
|
|
any other users at all.
|
|
</para>
|
|
|
|
<para>
|
|
Many people prefer thin Ethernet for small networks because it is very
|
|
inexpensive; PC cards come for as little as US $30 (many
|
|
companies are literally throwing them out now), and cable is in the
|
|
range of a few cents per meter. However, for large-scale
|
|
installations, either thick Ethernet or twisted pair is more
|
|
appropriate. For example, the Ethernet at GMU's Mathematics Department
|
|
originally chose thick Ethernet because it is a long route that the
|
|
cable must take so traffic will not be disrupted each time a host
|
|
is added to the network. Twisted pair installations are now very
|
|
common in a variety of installations. The Hub hardware is dropping in
|
|
price and small units are now available at a price that is attractive
|
|
to even small domestic networks. Twisted pair cabling can be
|
|
significantly cheaper for large installations, and the cable itself is
|
|
much more flexible than the coaxial cables used for the other Ethernet
|
|
systems. The network administrators in GMU's mathematics department
|
|
are planning to replace the existing network with a twisted pair
|
|
network in the coming finanical year because it will bring them up to
|
|
date with current technology and will save them significant time when
|
|
installing new host computers and moving existing computers around.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Ethernet</primary><secondary>drawbacks</secondary></indexterm>
|
|
<indexterm><primary>repeaters</primary></indexterm>
|
|
<indexterm><primary>bridges</primary></indexterm>
|
|
<indexterm><primary>routers</primary></indexterm>
|
|
One of the drawbacks of Ethernet technology is its limited cable length, which
|
|
precludes any use of it other than for LANs. However, several Ethernet
|
|
segments can be linked to one another using repeaters, bridges, or routers.
|
|
Repeaters simply copy the signals between two or more segments so that all
|
|
segments together will act as if they are one Ethernet. Due to timing
|
|
requirements, there may not be more than four repeaters between any two hosts
|
|
on the network. Bridges and routers are more sophisticated. They analyze
|
|
incoming data and forward it only when the recipient host is not on the local
|
|
Ethernet.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Ethernet</primary><secondary>addresses</secondary></indexterm>
|
|
<indexterm><primary>addresses</primary><secondary>Ethernet</secondary></indexterm>
|
|
Ethernet works like a bus system, where a host may send packets (or
|
|
<emphasis>frames</emphasis>) of up to 1,500 bytes to another host on the same
|
|
Ethernet. A host is addressed by a six-byte address hardcoded into the
|
|
firmware of its Ethernet network interface card (NIC). These addresses are
|
|
usually written as a sequence of two-digit hex numbers separated by colons,
|
|
as in <systemitem role="sitename">aa:bb:cc:dd:ee:ff</systemitem>.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Ethernet</primary><secondary>collisions</secondary></indexterm>
|
|
<indexterm><primary>collisions (Ethernet)</primary></indexterm> A
|
|
frame sent by one station is seen by all attached stations, but only
|
|
the destination host actually picks it up and processes it. If two
|
|
stations try to send at the same time, a
|
|
<emphasis>collision</emphasis> occurs. Collisions on an Ethernet are
|
|
detected very quickly by the electronics of the interface cards and
|
|
are resolved by the two stations aborting the send, each waiting a
|
|
random interval and re-attempting the transmission. You'll hear lots
|
|
of stories about collisions on Ethernet being a problem and that
|
|
utilization of Ethernets is only about 30 percent of the available
|
|
bandwidth because of them. Collisions on Ethernet are a
|
|
<emphasis>normal</emphasis> phenomenon, and on a very busy Ethernet
|
|
network you shouldn't be surprised to see collision rates of up to
|
|
about 30 percent. Utilization of Ethernet networks is more
|
|
realistically limited to about 60 percent before you need to start
|
|
worrying about it.<footnote id="X-087-2-FNIT03"><para> The Ethernet
|
|
FAQ at <systemitem
|
|
role="url">http://www.faqs.org/faqs/LANs/ethernet-faq/</systemitem>
|
|
talks about this issue, and a wealth of detailed historical and
|
|
technical information is available at Charles Spurgeon's Ethernet web
|
|
site at <systemitem
|
|
role="url">http://wwwhost.ots.utexas.edu/ethernet/</systemitem>.
|
|
</para>
|
|
</footnote>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="X-087-2-intro.tcpip.other-hardware"><title>Other Types of Hardware</title>
|
|
<para>
|
|
In larger installations, such as Groucho Marx University, Ethernet is usually
|
|
not the only type of equipment used. There are many other data communications
|
|
protocols available and in use. All of the protocols listed are supported by
|
|
Linux, but due to space constraints we'll describe them briefly. Many of the
|
|
protocols have HOWTO documents that describe them in detail, so you should
|
|
refer to those if you're interested in exploring those that we don't describe
|
|
in this book.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>FDDI (Fiber Distributed Data Interface)</primary></indexterm>
|
|
<INDEXTERM><PRIMARY>Fiber Distributed Data Interface (FDDI)</PRIMARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>protocols</PRIMARY><SECONDARY>token-passing</SECONDARY></INDEXTERM>
|
|
At Groucho Marx University, each department's LAN is linked to the
|
|
campus high-speed “backbone” network, which is a fiber
|
|
optic cable running a network technology called <emphasis>Fiber
|
|
Distributed Data Interface</emphasis> (FDDI). FDDI uses an entirely
|
|
different approach to transmitting data, which basically involves
|
|
sending around a number of <emphasis>tokens</emphasis>, with a station
|
|
being allowed to send a frame only if it captures a token. The main
|
|
advantage of a token-passing protocol is a reduction in collisions.
|
|
Therefore, the protocol can more easily attain the full speed of the
|
|
transmission medium, up to 100 Mbps in the case of FDDI. FDDI, being
|
|
based on optical fiber, offers a significant advantage because its
|
|
maximum cable length is much greater than wire-based technologies. It
|
|
has limits of up to around 200 km, which makes it ideal for linking
|
|
many buildings in a city, or as in GMU's case, many buildings on a
|
|
campus.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Token Ring</primary><secondary>networks</secondary></indexterm>
|
|
<INDEXTERM><PRIMARY>networks</PRIMARY><SECONDARY>Token
|
|
Ring</SECONDARY></INDEXTERM> <INDEXTERM><PRIMARY>IBM Token Ring
|
|
networks</PRIMARY></INDEXTERM> Similarly, if there is any IBM
|
|
computing equipment around, an IBM Token Ring network is quite likely
|
|
to be installed. Token Ring is used as an alternative to Ethernet in
|
|
some LAN environments, and offers the same sorts of advantages as FDDI
|
|
in terms of achieving full wire speed, but at lower speeds (4 Mbps or
|
|
16 Mbps), and lower cost because it is based on wire rather than
|
|
fiber. In Linux, Token Ring networking is configured in almost
|
|
precisely the same way as Ethernet, so we don't cover it specifically.
|
|
</para>
|
|
|
|
<para>
|
|
Although it is much less likely today than in the past, other LAN
|
|
technologies, such as ArcNet and DECNet, might be installed. Linux
|
|
supports these too, but we don't cover them here.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>protocols</primary><secondary>X.25</secondary></indexterm>
|
|
<indexterm><primary>X.25 protocol</primary></indexterm>
|
|
<indexterm><primary>PAD (Packet Assembler
|
|
Disassembler)</primary></indexterm> Many national networks operated by
|
|
Telecommunications companies support packet switching
|
|
protocols. Probably the most popular of these is a standard named
|
|
X.25. Many Public Data Networks, like Tymnet in the U.S., Austpac in
|
|
Australia, and Datex-P in Germany offer this service. X.25 defines a
|
|
set of networking protocols that describes how data terminal
|
|
equipment, such as a host, communicates with data communications
|
|
equipment (an X.25 switch). X.25 requires a synchronous data link, and
|
|
therefore special synchronous serial port hardware. It is possible to
|
|
use X.25 with normal serial ports if you use a special device called a
|
|
PAD (Packet Assembler Disassembler). The PAD is a standalone device
|
|
that provides asynchronous serial ports and a synchronous serial
|
|
port. It manages the X.25 protocol so that simple terminal devices can
|
|
make and accept X.25 connections. X.25 is often used to carry other
|
|
network protocols, such as TCP/IP. Since IP datagrams cannot simply be
|
|
mapped onto X.25 (or vice versa), they are encapsulated in X.25
|
|
packets and sent over the network. There is an experimental
|
|
implementation of the X.25 protocol available for Linux.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>protocols</primary><secondary>Frame Relay</secondary></indexterm>
|
|
<indexterm><primary>FRAD (Frame Relay Access Device)</primary></indexterm>
|
|
A more recent protocol commonly offered by telecommunications
|
|
companies is called <emphasis>Frame Relay</emphasis>. The Frame Relay
|
|
protocol shares a number of technical features with the X.25 protocol,
|
|
but is much more like the IP protocol in behavior. Like X.25, Frame
|
|
Relay requires special synchronous serial hardware. Because of their
|
|
similarities, many cards support both of these protocols. An
|
|
alternative is available that requires no special internal hardware,
|
|
again relying on an external device called a Frame Relay Access Device
|
|
(FRAD) to manage the encapsulation of Ethernet packets into Frame
|
|
Relay packets for transmission across a network. Frame Relay is ideal
|
|
for carrying TCP/IP between sites. Linux provides drivers that support
|
|
some types of internal Frame Relay devices.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>protocols</primary><secondary>ATM (Asynchronous Transfer Mode)</secondary></indexterm>
|
|
<indexterm><primary>ATM (Asynchronous Transfer Mode)</primary></indexterm>
|
|
If you need higher speed networking that can carry many different
|
|
types of data, such as digitized voice and video, alongside your usual
|
|
data, ATM (Asynchronous Transfer Mode) is probably what you'll be
|
|
interested in. ATM is a new network technology that has been
|
|
specifically designed to provide a manageable, high-speed, low-latency
|
|
means of carrying data, and provide control over the Quality of
|
|
Service (Q.S.). Many telecommunications companies are deploying ATM
|
|
network infrastructure because it allows the convergence of a number
|
|
of different network services into one platform, in the hope of
|
|
achieving savings in management and support costs. ATM is often used
|
|
to carry TCP/IP. The Networking-HOWTO offers information on the Linux
|
|
support available for ATM.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>protocols</primary><secondary>AX.25</secondary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>NetRom</secondary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>Rose</secondary></indexterm>
|
|
<indexterm><primary>amateur radio protocols</primary></indexterm>
|
|
<indexterm><primary>ham radio</primary></indexterm>
|
|
<indexterm><primary>packet radio</primary></indexterm>
|
|
<indexterm><primary>AX.25 protocol</primary></indexterm>
|
|
<indexterm><primary>NetRom protocol</primary></indexterm>
|
|
<indexterm><primary>Rose protocol</primary></indexterm>
|
|
<indexterm><primary>TNC (Terminal Node Controller)</primary></indexterm>
|
|
<INDEXTERM><PRIMARY>AX25 HOWTO</PRIMARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>HOWTOs</PRIMARY><SECONDARY>AX25</SECONDARY></INDEXTERM>
|
|
Frequently, radio amateurs use their radio equipment to network their
|
|
computers; this is commonly called <emphasis>packet
|
|
radio</emphasis>. One of the protocols used by amateur radio operators
|
|
is called AX.25 and is loosely derived from X.25. Amateur radio
|
|
operators use the AX.25 protocol to carry TCP/IP and other protocols,
|
|
too. AX.25, like X.25, requires serial hardware capable of synchronous
|
|
operation, or an external device called a “Terminal Node
|
|
Controller” to convert packets transmitted via an asynchronous
|
|
serial link into packets transmitted synchronously. There are a
|
|
variety of different sorts of interface cards available to support
|
|
packet radio operation; these cards are generally referred to as being
|
|
“Z8530 SCC based,” and are named after the most popular
|
|
type of communications controller used in the designs. Two of the
|
|
other protocols that are commonly carried by AX.25 are the NetRom and
|
|
Rose protocols, which are network layer protocols. Since these
|
|
protocols run over AX.25, they have the same hardware
|
|
requirements. Linux supports a fully featured implementation of the
|
|
AX.25, NetRom, and Rose protocols. The AX25-HOWTO is a good source of
|
|
information on the Linux implementation of these protocols.
|
|
</para>
|
|
|
|
<para>
|
|
Other types of Internet access involve dialing up a central system
|
|
over slow but cheap serial lines (telephone, ISDN, and so on). These
|
|
require yet another protocol for transmission of packets, such as SLIP
|
|
or PPP, which will be described later.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="X-087-2-intro.tcpip.ip"><title>The Internet Protocol</title>
|
|
|
|
<para>
|
|
<indexterm><primary>protocols</primary><secondary>Internet (IP)</secondary></indexterm>
|
|
<indexterm><primary>IP (Internet Protocol)</primary></indexterm>
|
|
Of course, you wouldn't want your networking to be limited to one
|
|
Ethernet or one point-to-point data link. Ideally, you would want to
|
|
be able to communicate with a host computer regardless of what type of
|
|
physical network it is connected to. For example, in larger
|
|
installations such as Groucho Marx University, you usually have a
|
|
number of separate networks that have to be connected in some way. At
|
|
GMU, the Math department runs two Ethernets: one with fast machines
|
|
for professors and graduates, and another with slow machines for
|
|
students. Both are linked to the FDDI campus backbone network.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>forwarding</primary><secondary>IP</secondary></indexterm>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>forwarding</secondary></indexterm>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>gateways</secondary></indexterm>
|
|
<indexterm><primary>gateways</primary></indexterm>
|
|
This connection is handled by a dedicated host called a
|
|
<emphasis>gateway</emphasis> that handles incoming and outgoing
|
|
packets by copying them between the two Ethernets and the FDDI fiber
|
|
optic cable. For example, if you are at the Math department and want
|
|
to access <systemitem role="sitename">quark</systemitem> on the
|
|
Physics department's LAN from your Linux box, the networking software
|
|
will not send packets to <systemitem role="sitename">quark</systemitem>
|
|
directly because it is not on the same Ethernet. Therefore, it has to
|
|
rely on the gateway to act as a forwarder. The gateway (named
|
|
<systemitem role="sitename">sophus</systemitem>) then forwards these
|
|
packets to its peer gateway <systemitem
|
|
role="sitename">niels</systemitem> at the Physics department, using
|
|
the backbone network, with <systemitem
|
|
role="sitename">niels</systemitem> delivering it to the destination
|
|
machine. Data flow between <systemitem
|
|
role="sitename">erdos</systemitem> and <systemitem
|
|
role="sitename">quark</systemitem> is shown in <xref
|
|
linkend="X-087-2-intro.fig.ip-flow">.
|
|
</para>
|
|
|
|
<figure id="X-087-2-intro.fig.ip-flow">
|
|
<title>The three steps of sending a datagram from erdos to quark</title>
|
|
<!-- <graphic fileref="lag2_0101.jpg"></graphic> -->
|
|
<!-- 2016-01-28; MAB, TLDP -->
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/lag2_0101.jpg" format="jpg">
|
|
</imageobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/lag2_0101.eps" format="eps">
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<para>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>routing</secondary></indexterm>
|
|
<INDEXTERM><PRIMARY>datagrams</PRIMARY></INDEXTERM>
|
|
This scheme of directing data to a remote host is called
|
|
<emphasis>routing</emphasis>, and packets are often referred to as
|
|
<emphasis>datagrams</emphasis> in this context. To facilitate things,
|
|
datagram exchange is governed by a single protocol that is independent
|
|
of the hardware used: IP, or <emphasis>Internet Protocol</emphasis>.
|
|
In <xref linkend="X-087-2-issues">, we will cover IP and the issues of
|
|
routing in greater detail.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>internetworking</primary></indexterm>
|
|
<indexterm><primary>networks</primary><secondary>interconnecting</secondary></indexterm>
|
|
<indexterm><primary>Internet</primary><secondary>versus internetworking</secondary></indexterm>
|
|
The main benefit of IP is that it turns physically dissimilar networks into
|
|
one apparently homogeneous network. This is called internetworking, and the
|
|
resulting “meta-network” is called an
|
|
<emphasis>internet</emphasis>. Note the subtle difference here between
|
|
<emphasis>an</emphasis> internet and <emphasis>the</emphasis> Internet.
|
|
The latter is the official name of one particular global internet.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>addresses</primary><secondary>IP</secondary></indexterm>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>addresses</secondary></indexterm>
|
|
<indexterm><primary>dotted quad notation</primary></indexterm>
|
|
<indexterm><primary>dotted decimal notation</primary></indexterm>
|
|
<INDEXTERM><PRIMARY>IPv4 (Internet Protocol)</PRIMARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>IP (Internet Protocol)</PRIMARY><SECONDARY>IPv4</SECONDARY></INDEXTERM>
|
|
Of course, IP also requires a hardware-independent addressing
|
|
scheme. This is achieved by assigning each host a unique 32-bit number
|
|
called the <emphasis>IP address</emphasis>. An IP address is usually
|
|
written as four decimal numbers, one for each 8-bit portion, separated
|
|
by dots. For example, <systemitem role="sitename">quark</systemitem>
|
|
might have an IP address of <systemitem
|
|
role="sitename">0x954C0C04</systemitem>, which would be written as
|
|
<systemitem role="sitename">149.76.12.4</systemitem>. This format is
|
|
also called <emphasis>dotted decimal notation</emphasis> and sometimes
|
|
<emphasis>dotted quad notation</emphasis>. It is increasingly going
|
|
under the name IPv4 (for Internet Protocol, Version 4) because a new
|
|
standard called IPv6 offers much more flexible addressing, as well as
|
|
other modern features. It will be at least a year after the release of
|
|
this edition before IPv6 is in use.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>IP (Internet Protocol)</primary><secondary>addresses</secondary><tertiary>versus hostname</tertiary></indexterm>
|
|
<indexterm><primary>Ethernet</primary><secondary>addresses</secondary><tertiary>versus IP address</tertiary></indexterm>
|
|
You will notice that we now have three different types of addresses:
|
|
first there is the host's name, like <systemitem
|
|
role="sitename">quark</systemitem>, then there are IP addresses, and
|
|
finally, there are hardware addresses, like the 6-byte Ethernet
|
|
address. All these addresses somehow have to match so that when you
|
|
type <command>rlogin quark</command>, the networking software can be
|
|
given <systemitem role="sitename">quark</systemitem>'s IP address; and
|
|
when IP delivers any data to the Physics department's Ethernet, it
|
|
somehow has to find out what Ethernet address corresponds to the IP
|
|
address.
|
|
</para>
|
|
|
|
<para>
|
|
We will deal with these situations in <xref linkend="X-087-2-issues">.
|
|
For now, it's enough to remember that these steps of finding addresses are
|
|
called <emphasis>hostname resolution</emphasis>, for mapping hostnames onto IP
|
|
addresses, and <emphasis>address resolution</emphasis>, for mapping the latter
|
|
to hardware addresses.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="X-087-2-intro.tcpip.slip"><title>IP Over Serial Lines</title>
|
|
|
|
<para>
|
|
<indexterm><primary>protocols</primary><secondary>CSLIP</secondary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>SLIP</secondary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>PPP</secondary></indexterm>
|
|
<INDEXTERM><PRIMARY>telephones</PRIMARY><SECONDARY>sending data over</SECONDARY></INDEXTERM>
|
|
<indexterm><primary>SLIP (Serial Line IP) protocol</primary></indexterm>
|
|
<indexterm><primary>CSLIP (Compressed Serial Line IP) protocol</primary></indexterm>
|
|
<indexterm><primary>PPP (Point-to-Point Protocol)</primary></indexterm>
|
|
On serial lines, a “de facto” standard exists known as SLIP, or
|
|
<emphasis>Serial Line IP</emphasis>. A modification of SLIP known as CSLIP,
|
|
or <emphasis>Compressed SLIP</emphasis>, performs compression of IP headers
|
|
to make better use of the relatively low bandwidth provided by most serial
|
|
links. Another serial protocol is PPP, or the
|
|
<emphasis>Point-to-Point Protocol</emphasis>. PPP is more modern than
|
|
SLIP and includes a number of features that make it more attractive. Its
|
|
main advantage over SLIP is that it isn't limited to transporting IP
|
|
datagrams, but is designed to allow just about any protocol to be carried
|
|
across it.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="X-087-2-intro.tcpip.tcp"><title>The Transmission Control Protocol</title>
|
|
|
|
<para>
|
|
<indexterm><primary>protocols</primary><secondary>TCP</secondary></indexterm>
|
|
<indexterm><primary>TCP (Transmission Control Protocol)</primary></indexterm>
|
|
Sending datagrams from one host to another is not the whole story. If you
|
|
log in to <systemitem role="sitename">quark</systemitem>, you want to have a
|
|
reliable connection between your <command>rlogin</command> process on
|
|
<systemitem role="sitename">erdos</systemitem> and the shell process on
|
|
<systemitem role="sitename">quark</systemitem>. Thus, the information sent
|
|
to and fro must be split up into packets by the sender and reassembled into
|
|
a character stream by the receiver. Trivial as it seems, this involves a
|
|
number of complicated tasks.
|
|
</para>
|
|
|
|
<para>
|
|
A very important thing to know about IP is that, by intent, it is not
|
|
reliable. Assume that ten people on your Ethernet started downloading
|
|
the latest release of Netscape's web browser source code from GMU's
|
|
FTP server. The amount of traffic generated might be too much for the
|
|
gateway to handle, because it's too slow and it's tight on memory. Now
|
|
if you happen to send a packet to <systemitem
|
|
role="sitename">quark</systemitem>, <systemitem
|
|
role="sitename">sophus</systemitem> might be out of buffer space for a
|
|
moment and therefore unable to forward it. IP solves this problem by
|
|
simply discarding it. The packet is irrevocably lost. It is therefore
|
|
the responsibility of the communicating hosts to check the integrity
|
|
and completeness of the data and retransmit it in case of error.
|
|
</para>
|
|
|
|
<para>
|
|
This process is performed by yet another protocol, <emphasis>Transmission
|
|
Control Protocol</emphasis> (TCP), which builds a reliable service on top of IP. The
|
|
essential property of TCP is that it uses IP to give you the illusion of a
|
|
simple connection between the two processes on your host and the remote
|
|
machine, so you don't have to care about how and along which route your data
|
|
actually travels. A TCP connection works essentially like a two-way pipe that
|
|
both processes may write to and read from. Think of it as a telephone
|
|
conversation.
|
|
</para>
|
|
|
|
<para>
|
|
<INDEXTERM id="chit.networks.tcp.ports" class=startofrange><PRIMARY>networks</PRIMARY><SECONDARY>ports</SECONDARY></INDEXTERM>
|
|
<INDEXTERM id="chit.networks.ports" class=startofrange><PRIMARY>ports</PRIMARY></INDEXTERM>
|
|
TCP identifies the end points of such a connection by the IP addresses
|
|
of the two hosts involved and the number of a
|
|
<emphasis>port</emphasis> on each host. Ports may be viewed as
|
|
attachment points for network connections. If we are to strain the
|
|
telephone example a little more, and you imagine that cities are like
|
|
hosts, one might compare IP addresses to area codes (where numbers map
|
|
to cities), and port numbers to local codes (where numbers map to
|
|
individual people's telephones). An individual host may support many
|
|
different services, each distinguished by its own port number.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>remote</primary><secondary>login</secondary></indexterm>
|
|
In the <command>rlogin</command> example, the client application
|
|
(<command>rlogin</command>) opens a port on <systemitem
|
|
role="sitename">erdos</systemitem> and connects to port 513 on
|
|
<systemitem role="sitename">quark</systemitem>, to which the
|
|
<command>rlogind</command> server is known to listen. This action
|
|
establishes a TCP connection. Using this connection,
|
|
<command>rlogind</command> performs the authorization procedure and
|
|
then spawns the shell. The shell's standard input and output are
|
|
redirected to the TCP connection, so that anything you type to
|
|
<command>rlogin</command> on your machine will be passed through the
|
|
TCP stream and be given to the shell as standard input.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="X-087-2-intro.tcpip.udp"><title>The User Datagram Protocol</title>
|
|
|
|
<para>
|
|
<indexterm><primary>protocols</primary><secondary>UDP</secondary></indexterm>
|
|
<indexterm><primary>UDP (User Datagram Protocol)</primary></indexterm>
|
|
<indexterm><primary>User Datagram Protocol (UDP)</primary></indexterm>
|
|
Of course, TCP isn't the only user protocol in TCP/IP networking. Although
|
|
suitable for applications like <command>rlogin</command>, the overhead
|
|
involved is prohibitive for applications like NFS, which instead uses a
|
|
sibling protocol of TCP called UDP, or
|
|
<emphasis>User Datagram Protocol</emphasis>. Just like TCP, UDP allows an
|
|
application to contact a service on a certain port of the remote machine, but
|
|
it doesn't establish a connection for this. Instead, you use it to send single
|
|
packets to the destination service—hence its name.
|
|
</para>
|
|
|
|
<para>
|
|
Assume you want to request a small amount of data from a database
|
|
server. It takes at least three datagrams to establish a TCP
|
|
connection, another three to send and confirm a small amount of data
|
|
each way, and another three to close the connection. UDP provides us
|
|
with a means of using only two datagrams to achieve almost the same
|
|
result. UDP is said to be connectionless, and it doesn't require us to
|
|
establish and close a session. We simply put our data into a datagram
|
|
and send it to the server; the server formulates its reply, puts the
|
|
data into a datagram addressed back to us, and transmits it
|
|
back. While this is both faster and more efficient than TCP for simple
|
|
transactions, UDP was not designed to deal with datagram loss. It is
|
|
up to the application, a name server for example, to take care of
|
|
this.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="X-087-2-intro.tcpip.ports"><title>More on Ports</title>
|
|
|
|
<para>
|
|
<indexterm><primary>networks</primary><secondary>services</secondary></indexterm>
|
|
<indexterm><primary>services</primary></indexterm> Ports may be viewed
|
|
as attachment points for network connections. If an application wants
|
|
to offer a certain service, it attaches itself to a port and waits for
|
|
clients (this is also called <emphasis>listening</emphasis> on the
|
|
port). A client who wants to use this service allocates a port on its
|
|
local host and connects to the server's port on the remote host. The
|
|
same port may be open on many different machines, but on each machine
|
|
only one process can open a port at any one time.
|
|
</para>
|
|
|
|
<para>
|
|
An important property of ports is that once a connection has been
|
|
established between the client and the server, another copy of the
|
|
server may attach to the server port and listen for more clients.
|
|
This property permits, for instance, several concurrent remote logins
|
|
to the same host, all using the same port 513. TCP is able to tell
|
|
these connections from one another because they all come from
|
|
different ports or hosts. For example, if you log in twice to
|
|
<systemitem role="sitename">quark</systemitem> from <systemitem
|
|
role="sitename">erdos</systemitem>, the first
|
|
<command>rlogin</command> client will use the local port 1023, and the
|
|
second one will use port 1022. Both, however, will connect to the same
|
|
port 513 on <systemitem role="sitename">quark</systemitem>. The two
|
|
connections will be distinguished by use of the port numbers used at
|
|
<systemitem role="sitename">erdos</systemitem>.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>services</primary><secondary>well-known</secondary></indexterm>
|
|
<indexterm><primary>services</primary><secondary>port numbers and</secondary></indexterm>
|
|
<indexterm><primary>IETF (Internet Engineering Task Force)</primary></indexterm>
|
|
This example shows the use of ports as rendezvous points, where a client
|
|
contacts a specific port to obtain a specific service. In order for a client
|
|
to know the proper port number, an agreement has to be reached between the
|
|
administrators of both systems on the assignment of these numbers. For
|
|
services that are widely used, such as <command>rlogin</command>, these
|
|
numbers have to be administered centrally. This is done by the IETF
|
|
(Internet Engineering Task Force), which regularly releases an RFC titled
|
|
<emphasis>Assigned Numbers</emphasis> (RFC-1700). It describes, among other
|
|
things, the port numbers assigned to well-known services. Linux uses a file
|
|
called <filename>/etc/services</filename> that maps service names to
|
|
numbers.
|
|
</para>
|
|
|
|
<para>
|
|
It is worth noting that although both TCP and UDP connections rely on ports,
|
|
these numbers do not conflict. This means that TCP port 513, for example, is
|
|
different from UDP port 513. In fact, these ports serve as access points for
|
|
two different services, namely <command>rlogin</command> (TCP) and
|
|
<command>rwho</command> (UDP).
|
|
<INDEXTERM startref="chit.networks.tcp.ports" class=endofrange>
|
|
<INDEXTERM startref="chit.networks.ports" class=endofrange>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="X-087-2-intro.tcpip.sockets"><title>The Socket Library</title>
|
|
<para>
|
|
<indexterm><primary>networks</primary><secondary>programming interfaces</secondary></indexterm> <indexterm><primary>Berkeley Socket Library</primary></indexterm>
|
|
<indexterm><primary>sockets</primary></indexterm>
|
|
<indexterm><primary>bind( )</primary></indexterm>
|
|
<indexterm><primary>connect( )</primary></indexterm>
|
|
<indexterm><primary>listen( )</primary></indexterm>
|
|
<indexterm><primary>accept( )</primary></indexterm>
|
|
<indexterm><primary>XNS (Xerox Networking System)</primary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>XNS</secondary></indexterm>
|
|
In Unix operating systems, the software performing all the tasks and
|
|
protocols described above is usually part of the kernel, and so it is
|
|
in Linux. The programming interface most common in the Unix world is
|
|
the <emphasis>Berkeley Socket Library</emphasis>. Its name derives
|
|
from a popular analogy that views ports as sockets and connecting to
|
|
a port as plugging in. It provides the <function>bind</function> call
|
|
to specify a remote host, a transport protocol, and a service that a
|
|
program can connect or listen to (using <function>connect</function>,
|
|
<function>listen</function>, and <function>accept</function>). The
|
|
socket library is somewhat more general in that it provides not only a
|
|
class of TCP/IP-based sockets (the <function>AF_INET</function>
|
|
sockets), but also a class that handles connections local to the
|
|
machine (the <function>AF_UNIX</function> class). Some implementations
|
|
can also handle other classes, like the XNS (<emphasis>Xerox
|
|
Networking System</emphasis>) protocol or X.25.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>IPX (Internet Packet eXchange)</primary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>Internet Packet eXchange (IPX)</secondary></indexterm>
|
|
<indexterm><primary>X.25 protocol</primary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>X.25</secondary></indexterm>
|
|
<indexterm><primary>ATM (Asynchronous Transfer Mode)</primary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>ATM (Asynchronous Transfer Mode)</secondary></indexterm>
|
|
<indexterm><primary>AX.25 protocol</primary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>AX.25</secondary></indexterm>
|
|
<indexterm><primary>NetRom protocol</primary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>NetRom</secondary></indexterm>
|
|
<indexterm><primary>Rose protocol</primary></indexterm>
|
|
<indexterm><primary>protocols</primary><secondary>Rose</secondary></indexterm>
|
|
In Linux, the socket library is part of the standard
|
|
<filename>libc</filename> C library. It supports the
|
|
<function>AF_INET</function> and <function>AF_INET6</function> sockets
|
|
for TCP/IP and <function>AF_UNIX</function> for Unix domain
|
|
sockets. It also supports <function>AF_IPX</function> for Novell's
|
|
network protocols, <function>AF_X25</function> for the X.25 network
|
|
protocol, <function>AF_ATMPVC</function> and
|
|
<function>AF_ATMSVC</function> for the ATM network protocol and
|
|
<function>AF_AX25</function>, <function>AF_NETROM</function>, and
|
|
<function>AF_ROSE</function> sockets for Amateur Radio protocol
|
|
support. Other protocol families are being developed and will be
|
|
added in time.
|
|
</para>
|
|
<INDEXTERM startref="chit.networks.tcp-ip" class=endofrange>
|
|
</sect2>
|
|
<?troff .Nd 7>
|
|
</sect1>
|
|
|
|
<sect1 id="X-087-2-intro.uucp"><title>UUCP Networks</title>
|
|
<para>
|
|
<indexterm><primary>networks</primary><secondary>UUCP</secondary></indexterm>
|
|
<INDEXTERM><PRIMARY>UUCP</PRIMARY><SECONDARY>networks</SECONDARY></INDEXTERM>
|
|
Unix-to-Unix Copy (UUCP) started out as a package of programs that
|
|
transferred files over serial lines, scheduled those transfers, and
|
|
initiated execution of programs on remote sites. It has undergone major
|
|
changes since its first implementation in the late seventies, but it
|
|
is still rather spartan in the services it offers. Its main
|
|
application is still in Wide Area Networks, based on periodic dialup
|
|
telephone links.
|
|
</para>
|
|
|
|
<para>
|
|
UUCP was first developed by Bell Laboratories in 1977 for
|
|
communication between their Unix development sites. In mid-1978, this
|
|
network already connected over 80 sites. It was running email as an
|
|
application, as well as remote printing. However, the system's
|
|
central use was in distributing new software and bug fixes. Today, UUCP
|
|
is not confined solely to the Unix environment. There are free and
|
|
commercial ports available for a variety of platforms, including
|
|
AmigaOS, DOS, and Atari's TOS.
|
|
</para>
|
|
|
|
<para>
|
|
One of the main disadvantages of UUCP networks is that they operate in
|
|
batches. Rather than having a permanent connection established between
|
|
hosts, it uses temporary connections. A UUCP host machine might dial in to
|
|
another UUCP host only once a day, and then only for a short period of time.
|
|
While it is connected, it will transfer all of the news, email, and files that
|
|
have been queued, and then disconnect. It is this queuing that limits the
|
|
sorts of applications that UUCP can be applied to. In the case of email, a
|
|
user may prepare an email message and post it. The message will stay queued
|
|
on the UUCP host machine until it dials in to another UUCP host to transfer
|
|
the message. This is fine for network services such as email, but is no
|
|
use at all for services such as <command>rlogin</command>.
|
|
</para>
|
|
|
|
<para>
|
|
Despite these limitations, there are still many UUCP networks
|
|
operating all over the world, run mainly by hobbyists, which offer
|
|
private users network access at reasonable prices. The main reason for
|
|
the longtime popularity of UUCP was that it was very cheap compared to
|
|
having your computer directly connected to the Internet. To make your
|
|
computer a UUCP node, all you needed was a modem, a working UUCP
|
|
implementation, and another UUCP node that was willing to feed you
|
|
mail and news. Many people were prepared to provide UUCP feeds to
|
|
individuals because such connections didn't place much demand on their
|
|
existing network.
|
|
</para>
|
|
|
|
<para>
|
|
We cover the configuration of UUCP in a chapter of its own later in
|
|
the book, but we won't focus on it too heavily, as it's being replaced
|
|
rapidly with TCP/IP, now that cheap Internet access has become commonly
|
|
available in most parts of the world.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1><title>Linux Networking</title>
|
|
|
|
<para>
|
|
<indexterm><primary>Linux</primary><secondary>networks</secondary></indexterm>
|
|
<indexterm><primary>networks</primary><secondary>Linux</secondary></indexterm>
|
|
<indexterm><primary>Net-1 network version</primary></indexterm>
|
|
<indexterm><primary>Net-2d network version</primary></indexterm>
|
|
<indexterm><primary>Net-2Debugged network version</primary></indexterm>
|
|
<indexterm><primary>Net-3 network version</primary></indexterm>
|
|
<indexterm><primary>Biro, Ross</primary></indexterm>
|
|
<indexterm><primary>Cox, Alan</primary></indexterm>
|
|
<indexterm><primary>Kempen, Fred van</primary></indexterm>
|
|
As it is the result of a concerted effort of programmers around
|
|
the world, Linux wouldn't have been possible without the global
|
|
network. So it's not surprising that in the early stages of
|
|
development, several people started to work on providing it with
|
|
network capabilities. A UUCP implementation was running on Linux
|
|
almost from the very beginning, and work on TCP/IP-based networking
|
|
started around autumn 1992, when Ross Biro and others created what has
|
|
now become known as Net-1.
|
|
</para>
|
|
|
|
<para>
|
|
After Ross quit active development in May 1993, Fred van Kempen began
|
|
to work on a new implementation, rewriting major parts of the
|
|
code. This project was known as Net-2. The first public release, Net-2d, was
|
|
made in the summer of 1993 (as part of the 0.99.10 kernel), and has
|
|
since been maintained and expanded by several people, most
|
|
notably Alan Cox.<footnote id="X-087-2-FNIT04"><para>Alan can be reached at
|
|
<systemitem role="emailaddr">alan@lxorguk.ukuu.org.uk</systemitem>
|
|
</para></footnote> Alan's original work was known as
|
|
Net-2Debugged. After heavy debugging and numerous improvements to the
|
|
code, he changed its name to Net-3 after Linux 1.0 was released. The
|
|
Net-3 code was further developed for Linux 1.2 and Linux 2.0. The 2.2
|
|
and later kernels use the Net-4 version network support, which remains
|
|
the standard official offering today.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Net-4 network version</primary></indexterm> The
|
|
Net-4 Linux Network code offers a wide variety of device drivers and
|
|
advanced features. Standard Net-4 protocols include SLIP and PPP (for
|
|
sending network traffic over serial lines), PLIP (for parallel lines),
|
|
IPX (for Novell compatible networks, which we'll discuss in <xref
|
|
linkend="X-087-2-ipx">), Appletalk (for Apple networks) and AX.25,
|
|
NetRom, and Rose (for amateur radio networks). Other standard Net-4
|
|
features include IP firewalling, IP accounting (discussed later in
|
|
<xref linkend="X-087-2-firewall"> and <xref
|
|
linkend="X-087-2-accounting">), and IP Masquerade (discussed later in
|
|
<xref linkend="X-087-2-ipmasq">. IP tunnelling in a couple of
|
|
different flavors and advanced policy routing are supported. A very
|
|
large variety of Ethernet devices is supported, in addition to support
|
|
for some FDDI, Token Ring, Frame Relay, and ISDN, and ATM cards.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Tridgell, Andrew</primary></indexterm>
|
|
Additionally, there are a number of other features that greatly
|
|
enhance the flexibility of Linux. These features include an
|
|
implementation of the SMB filesystem, which interoperates with
|
|
applications like <emphasis>lanmanager</emphasis> and Microsoft
|
|
Windows, called Samba, written by Andrew Tridgell, and an
|
|
implementation of the Novell NCP (NetWare Core Protocol).<footnote
|
|
id="X-087-2-FNIT05"><para> NCP is the protocol on which Novell file
|
|
and print services are based.
|
|
</para>
|
|
</footnote>
|
|
|
|
</para>
|
|
|
|
<sect2><title>Different Streaks of Development</title>
|
|
<para>
|
|
There have been, at various times, varying network development efforts active
|
|
for Linux.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Net-2e network version</primary></indexterm>
|
|
<indexterm><primary>DDI (Device Driver
|
|
Interface)</primary></indexterm> <indexterm><primary>Device Driver
|
|
Interface (DDI)</primary></indexterm> Fred continued development after
|
|
Net-2Debugged was made the official network implementation. This
|
|
development led to the Net-2e, which featured a much revised design of
|
|
the networking layer. Fred was working toward a standardized Device
|
|
Driver Interface (DDI), but the Net-2e work has ended now.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>Urlichs, Matthias</primary></indexterm> Yet another
|
|
implementation of TCP/IP networking came from Matthias
|
|
Urlichs, who wrote an ISDN driver for Linux and FreeBSD. For this
|
|
driver, he integrated some of the BSD networking code in the Linux
|
|
kernel. That project, too is no longer being worked on.
|
|
</para>
|
|
|
|
<para>
|
|
There has been a lot of rapid change in the Linux kernel networking
|
|
implementation, and change is still the watchword as development
|
|
continues. Sometimes this means that changes also have to occur in
|
|
other software, such as the network configuration tools. While this is
|
|
no longer as large a problem as it once was, you may still find that
|
|
upgrading your kernel to a later version means that you must upgrade
|
|
your network configuration tools, too. Fortunately, with the large
|
|
number of Linux distributions available today, this is a quite simple
|
|
task.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>IPv6 (Internet Protocol)</primary></indexterm>
|
|
<INDEXTERM><PRIMARY>IP (Internet Protocol)</PRIMARY><SECONDARY>IPv6</SECONDARY></INDEXTERM>
|
|
The Net-4 network implementation is now quite mature and is in use at a
|
|
very large number of sites around the world. Much work has been done on
|
|
improving the performance of the Net-4 implementation, and it now competes
|
|
with the best implementations available for the same hardware platforms.
|
|
Linux is proliferating in the Internet Service Provider environment, and is
|
|
often used to build cheap and reliable World Wide Web servers, mail servers,
|
|
and news servers for these sorts of organizations. There is now sufficient
|
|
development interest in Linux that it is managing to keep abreast of
|
|
networking technology as it changes, and current releases of the Linux kernel
|
|
offer the next generation of the IP protocol, IPv6, as a standard offering.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2><title>Where to Get the Code</title>
|
|
|
|
<para>
|
|
<indexterm><primary>code, obtaining for</primary><secondary>Linux network</secondary></indexterm>
|
|
<indexterm><primary>Linux</primary><secondary>networks</secondary><tertiary>obtaining code for</tertiary></indexterm>
|
|
<indexterm><primary>FTP (File Transfer Protocol), location of Linux code</primary></indexterm>
|
|
<indexterm><primary>Net-3 network version</primary></indexterm>
|
|
It seems odd now to remember that in the early days of the Linux
|
|
network code development, the standard kernel required a huge patch
|
|
kit to add the networking support to it. Today, network development
|
|
occurs as part of the mainstream Linux kernel development process. The
|
|
latest stable Linux kernels can be found on <emphasis
|
|
role=bold>ftp.kernel.org</emphasis> in
|
|
<filename>/pub/linux/kernel/v2.x/</filename>, where
|
|
<emphasis>x</emphasis> is an even number. The latest experimental Linux
|
|
kernels can be found on <emphasis role=bold>ftp.kernel.org</emphasis>
|
|
in <filename>/pub/linux/kernel/v2.y/</filename>, where
|
|
<emphasis>y</emphasis> is an odd number. There are Linux kernel source
|
|
mirrors all over the world. It is now hard to imagine Linux without
|
|
standard network support.
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1><title>Maintaining Your System</title>
|
|
|
|
<para>
|
|
<indexterm><primary>maintenance, system</primary></indexterm>
|
|
<indexterm><primary>system maintenance</primary></indexterm>
|
|
Throughout this book, we will mainly deal with installation and
|
|
configuration issues. Administration is, however, much more than
|
|
that—after setting up a service, you have to keep it running, too.
|
|
For most services, only a little attendance will be necessary, while some,
|
|
like mail and news, require that you perform routine tasks to keep your system
|
|
up to date. We will discuss these tasks in later chapters.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>cron</primary></indexterm>
|
|
<INDEXTERM><PRIMARY>errors, checking for</PRIMARY></INDEXTERM>
|
|
The absolute minimum in maintenance is to check system and per-application
|
|
log files regularly for error conditions and unusual events. Often, you
|
|
will want to do this by writing a couple of administrative shell scripts
|
|
and periodically running them from <command>cron</command>. The source
|
|
distributions of some major applications, like <command>inn</command> or
|
|
C News, contain such scripts. You only have to tailor them to suit your
|
|
needs and preferences.
|
|
</para>
|
|
|
|
<para>
|
|
The output from any of your <command>cron</command> jobs should be mailed to an
|
|
administrative account. By default, many applications will send error
|
|
reports, usage statistics, or log file summaries to the
|
|
<systemitem role="userid">root</systemitem> account. This makes sense only
|
|
if you log in as <systemitem role="userid">root</systemitem> frequently; a much
|
|
better idea is to forward <systemitem role="userid">root</systemitem>'s mail to
|
|
your personal account by setting up a mail alias as described in
|
|
<xref linkend="X-087-2-exim"> or <xref linkend="X-087-2-sendmail">.
|
|
</para>
|
|
|
|
<para>
|
|
However carefully you have configured your site, Murphy's law guarantees
|
|
that some problem <emphasis>will</emphasis> surface eventually. Therefore,
|
|
maintaining a system also means being available for complaints. Usually,
|
|
people expect that the system administrator can at least be reached via email
|
|
as <systemitem role="emailaddr">root</systemitem>, but there are also other
|
|
addresses that are commonly used to reach the person responsible for a
|
|
specific aspect of maintenence. For instance, complaints about a
|
|
malfunctioning mail configuration will usually be addressed to
|
|
<systemitem role="emailaddr">postmaster</systemitem>, and problems with the
|
|
news system may be reported to
|
|
<systemitem role="emailaddr">newsmaster</systemitem> or
|
|
<systemitem role="emailaddr">usenet</systemitem>. Mail to
|
|
<systemitem role="emailaddr">hostmaster</systemitem> should be redirected to
|
|
the person in charge of the host's basic network services, and the DNS name
|
|
service if you run a name server.
|
|
</para>
|
|
|
|
<sect2 id="X-087-2-intro.security"><title>System Security</title>
|
|
|
|
<para>
|
|
<indexterm><primary>system security</primary></indexterm>
|
|
<indexterm><primary>security</primary><secondary>system</secondary></indexterm>
|
|
Another very important aspect of system administration in a network
|
|
environment is protecting your system and users from intruders.
|
|
Carelessly managed systems offer malicious people many targets. Attacks
|
|
range from password guessing to Ethernet snooping, and the damage caused
|
|
may range from faked mail messages to data loss or violation of your
|
|
users' privacy. We will mention some particular problems when discussing
|
|
the context in which they may occur and some common defenses against them.
|
|
</para>
|
|
|
|
<para>
|
|
This section will discuss a few examples and basic techniques for
|
|
dealing with system security. Of course, the topics covered cannot
|
|
treat all security issues you may be faced with in detail; they merely
|
|
serve to illustrate the problems that may arise. Therefore, reading a
|
|
good book on security is an absolute must, especially in a networked
|
|
system.
|
|
</para>
|
|
|
|
<para>
|
|
System security starts with good system administration. This includes
|
|
checking the ownership and permissions of all vital files and
|
|
directories and monitoring use of privileged accounts. The COPS
|
|
program, for instance, will check your file system and common
|
|
configuration files for unusual permissions or other anomalies. It is
|
|
also wise to use a password suite that enforces certain rules on the
|
|
users' passwords that make them hard to guess. The shadow password
|
|
suite, for instance, requires a password to have at least five letters
|
|
and to contain both upper- and lowercase numbers, as well as
|
|
non-alphabetic characters.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>services</primary><secondary>restricting access
|
|
to</secondary></indexterm> <indexterm><primary>TFTP (Trivial File
|
|
Transfer Protocol)</primary></indexterm> When making a service
|
|
accessible to the network, make sure to give it “least
|
|
privilege”; don't permit it to do things that aren't required
|
|
for it to work as designed. For example, you should make programs
|
|
setuid to <systemitem role="userid">root</systemitem> or some other
|
|
privileged account only when necessary. Also, if you want to use a
|
|
service for only a very limited application, don't hesitate to
|
|
configure it as restrictively as your special application allows. For
|
|
instance, if you want to allow diskless hosts to boot from your
|
|
machine, you must provide <emphasis>Trivial File Transfer
|
|
Protocol</emphasis>  (TFTP) so that they can download basic
|
|
configuration files from the <filename>/boot</filename>
|
|
directory. However, when used unrestrictively, TFTP allows users
|
|
anywhere in the world to download any world-readable file from your
|
|
system. If this is not what you want, restrict TFTP service to the
|
|
<filename>/boot</filename> directory.<footnote
|
|
id="X-087-2-FNIT06"><para> We will come back to this topic in <xref
|
|
linkend="X-087-2-appl">.
|
|
</para>
|
|
</footnote>
|
|
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>access</primary><secondary>restricting</secondary></indexterm>
|
|
You might also want to restrict certain services to users from certain
|
|
hosts, say from your local network. In <xref linkend="X-087-2-appl">,
|
|
we introduce <command>tcpd</command>, which does this for a variety of
|
|
network applications. More sophisticated methods of restricting access
|
|
to particular hosts or services will be explored later in <xref
|
|
linkend="X-087-2-firewall">.
|
|
</para>
|
|
|
|
<para>
|
|
Another important point is to avoid “dangerous”
|
|
software. Of course, any software you use can be dangerous because
|
|
software may have bugs that clever people might exploit to gain access
|
|
to your system. Things like this happen, and there's no complete
|
|
protection against it. This problem affects free software and
|
|
commercial products alike.<footnote id="X-087-2-FNIT07"><para> There
|
|
have been commercial Unix systems (that you have to pay lots of money
|
|
for) that came with a setuid-<systemitem
|
|
role="userid">root</systemitem> shell script, which allowed users to
|
|
gain <systemitem role="userid">root</systemitem> privilege using a
|
|
simple standard trick.
|
|
</para>
|
|
</footnote> However, programs that require special privilege are inherently
|
|
more dangerous than others, because any loophole can have drastic
|
|
consequences.<footnote id="X-087-2-FNIT08"><para>
|
|
In 1988, the RTM worm brought much of the Internet to a grinding halt, partly
|
|
by exploiting a gaping hole in some programs including the
|
|
<command>sendmail</command> program. This hole has long since been fixed.
|
|
</para>
|
|
</footnote>
|
|
If you install a setuid program for network purposes, be doubly
|
|
careful to check the documentation so that you don't create a security
|
|
breach by accident.
|
|
</para>
|
|
|
|
<para>
|
|
<INDEXTERM><PRIMARY>ssh tools</PRIMARY></INDEXTERM>
|
|
<INDEXTERM><PRIMARY>authentication</PRIMARY><SECONDARY>issues</SECONDARY></INDEXTERM>
|
|
Another source of concern should be programs that enable login or
|
|
command execution with limited authentication. The
|
|
<command>rlogin</command>, <command>rsh</command>, and
|
|
<command>rexec</command> commands are all very useful, but offer very
|
|
limited authentication of the calling party. Authentication is based
|
|
on trust of the calling host name obtained from a name server (we'll
|
|
talk about these later), which can be faked. Today it should be
|
|
standard practice to disable the <command>r</command> commands
|
|
completely and replace them with the <command>ssh</command> suite of
|
|
tools. The <command>ssh</command> tools use a much more reliable
|
|
authentication method and provide other services, such as encryption
|
|
and compression, as well.
|
|
</para>
|
|
|
|
<para>
|
|
<indexterm><primary>tripwire command</primary></indexterm>
|
|
You can never rule out the possibility that your precautions might
|
|
fail, regardless of how careful you have been. You should therefore
|
|
make sure you detect intruders early. Checking the system log files is
|
|
a good starting point, but the intruder is probably clever enough to
|
|
anticipate this action and will delete any obvious traces he or she
|
|
left. However, there are tools like <command>tripwire</command>,
|
|
written by Gene Kim and Gene Spafford, that allow you to check vital
|
|
system files to see if their contents or permissions have been
|
|
changed. <command>tripwire</command> computes various strong
|
|
checksums over these files and stores them in a database. During
|
|
subsequent runs, the checksums are recomputed and compared to the
|
|
stored ones to detect any modifications.
|
|
|
|
<indexterm class="endofrange" startref="chit.netwks.intro">
|
|
</para>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
</chapter>
|
|
|