This commit is contained in:
gferg 2001-01-05 22:21:41 +00:00
parent 221ce02025
commit e3683984bc
57 changed files with 36532 additions and 0 deletions

View File

@ -0,0 +1,92 @@
<appendix id="X-087-2-appendix.brewery"><title>Example Network:<?lb>The Virtual Brewery</title>
<indexterm><primary>Virtual Brewery</primary></indexterm>
<indexterm><primary>Brewery, Virtual</primary></indexterm>
<para>
Throughout this book we've used the following example that is a little less
complex than Groucho Marx University and may be closer to the tasks you will
actually encounter.
</para>
<para>
The Virtual Brewery is a small company that brews, as the name suggests,
virtual beer. To manage their business more efficiently, the virtual brewers
want to network their computers, which all happen to be PCs running the
brightest and shiniest production Linux kernel. <xref linkend = "x-087-2-appendix.brewery.diagram"> shows the network configuration.
</para>
<para>
On the same floor, just across the hall, there's the Virtual Winery, which
works closely with the brewery. The vintners run an Ethernet of their own.
Quite naturally, the two companies want to link their networks once they are
operational. As a first step, they want to set up a gateway host that
forwards datagrams between the two subnets. Later, they also want to have a
UUCP link to the outside world, through which they exchange mail and news. In
the long run, they also want to set up PPP connections to connect to offsite
locations and to the Internet.
</para>
<para>
The Virtual Brewery and the Virtual Winery each have a class C subnet of
the Brewery's class B network, and gateway to each other via the host
<systemitem role="sitename">vlager</systemitem>, which also supports the
UUCP connection. <xref linkend = "x-087-2-appendix.brewery.subsidiary"> shows the configuration.
</para>
<figure id="X-087-2-appendix.brewery.diagram">
<title>The Virtual Brewery and Virtual Winery subnets</title>
<graphic fileref="lag2_aa01.jpg"></graphic>
</figure>
<figure id="X-087-2-appendix.brewery.subsidiary">
<title>The Virtual Brewery Network</title>
<graphic fileref="lag2_aa02.jpg"></graphic>
</figure>
<sect1><title>Connecting the Virtual Subsidiary Network</title>
<para>
The Virtual Brewery grows and opens a branch in another city. The
subsidiary runs an Ethernet of its own using the IP network number
<systemitem role="sitename">172.16.3.0</systemitem>, which is subnet 3 of the
Brewery's class B network. The host
<systemitem role="sitename">vlager</systemitem> acts as the gateway for the
Brewery network and will support the PPP link; its peer at the new branch is
called <systemitem role="sitename">vbourbon</systemitem> and has an IP address
of <systemitem role="sitename">172.16.3.1</systemitem>. This network is
illustrated in <xref linkend="X-087-2-appendix.brewery.subsidiary">.
</para>
<para>
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
</para>
<para>
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
</para>
<para>
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
</para>
</sect1>
</appendix>

View File

@ -0,0 +1,92 @@
<appendix id="X-087-2-appendix.cables"><title>Useful Cable Configurations</title>
<para>
If you wish to connect two computers together and you don't have an Ethernet
network, you will need either a serial null modem cable, or a PLIP parallel
cable.
</para>
<para>
These cables can be bought off the shelf, but are much cheaper and fairly
simple to make yourself.
</para>
<sect1 id="X-087-2-cable.plip"><title>A PLIP Parallel Cable</title>
<para>
<indexterm><primary>PLIP (Parallel Line IP) protocol</primary><secondary>null printer cable for</secondary></indexterm>
To make a parallel cable to use for PLIP, you will need two 25-pin
connectors (called DB-25) and a cable with at least eleven conductors.
The cable must not be any longer than 15 meters (50 feet). The cable may or may
not have a shield, but if you are building a long cable, it is probably
a good idea to have one.
</para>
<para>
If you look at the connector, you should be able to read tiny numbers
at the base of each pin&mdash;from 1 for the pin at the top left (if you hold
the broader side up) to 25 for the pin at the bottom right. For the null
printer cable, you have to connect the following pins of both connectors
with each other, as shown in <xref linkend="X-087-2-cable.plip.diagram">.
</para>
<para>
All remaining pins remain unconnected. If the cable is shielded, the
shield should be connected to the DB-25's metallic shell on just
<emphasis>one</emphasis> end.
</para>
</sect1>
<sect1 id="X-087-2-cable.serial"><title>A Serial NULL Modem Cable</title>
<para>
<indexterm><primary>SLIP (Serial Line IP) protocol</primary><secondary>null modem cable for</secondary></indexterm>
<indexterm><primary>PPP (Point-to-Point Protocol)</primary><secondary>null modem cable for</secondary></indexterm>
A serial null modem cable will work for both SLIP and PPP. Again, you
will need two DB-25 connectors. This time your cable requires only
eight conductors.
</para>
<para>
You may have seen other NULL modem cable designs, but this one allows you
to use hardware flow control&mdash;which is far superior to XON/XOFF
flow control&mdash;or none at all. The conductor configuration is
shown in <xref linkend="X-087-2-cable.nullmodem.diagram">:
</para>
<para>
Again, if you have a shield, you should connect it to the first pin at one
end only.
</para>
<figure id="X-087-2-cable.plip.diagram">
<title>Parallel PLIP cable</title>
<graphic fileref="lag2_ab01.jpg"></graphic>
</figure>
<para>
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
</para>
<figure id="X-087-2-cable.nullmodem.diagram">
<title>Serial NULL-Modem cable</title>
<graphic fileref="lag2_ab02.jpg"></graphic>
</figure>
<para>
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
&numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp; &numsp;
</para>
</sect1>
</appendix>

View File

@ -0,0 +1,432 @@
<appendix id="X-087-2-appendix.gpl"><title>Linux Network Administrator's Guide, Second Edition <?lb>Copyright Information</title>
<para>
Copyright &copy; 1993 Olaf Kirch
<?troff .br>
Copyright &copy; 2000 Terry Dawson
<?troff .br>
Copyright on O'Reilly printed version &copy; 2000 O'Reilly &amp; Associates
<?troff .br>
</para>
<para>
<?troff .hw linuxdoc>
<INDEXTERM><PRIMARY>copyright information</PRIMARY></INDEXTERM>
The online version of this book, which at this time of printing
contains exactly the same text as the O'Reilly printed version, is
available under the GNU FDL. Rights to reprint the document under the
FDL include the right to print and distribute printed copies of the
online version. Rights to copy the O'Reilly printed version are
reserved. You can find the online copy of the license at <systemitem
role="url">http://www.oreilly.com/catalog/linag/licenseinfo.html</systemitem>.
The book is available at <systemitem
role="url">http://www.linuxdoc.org/LDP/nag/nag.html</systemitem> and
<systemitem
role="url">http://www.oreilly.com/catalog/linag/</systemitem>, and may
be reposted by others at other locations.
</para>
<para>
Permission is granted to copy, print, distribute, and modify the
online document under the terms of the GNU Free Documentation License,
Version 1.1, or any later version published by the Free Software
Foundation; with the Invariant Sections being the Acknowledgments (in
the <emphasis>Preface</emphasis> and <xref linkend="X-087-2-appendix.gpl">." Further acknowledgments can be added outside
the Invariant Section. The Front-Cover Text must read:
</para>
<literallayout>
<emphasis>Linux Network Administrator's Guide</emphasis>
by Olaf Kirch and Terry Dawson
Copyright &copy; 1993 Olaf Kirch
Copyright &copy; 2000 Terry Dawson
Copyright on O'Reilly printed version &copy; 2000 O'Reilly &amp; Associates
</literallayout>
<para>
<INDEXTERM id="GNU.FDL" class=startofrange><PRIMARY>GNU Free Documentation License (FDL)</PRIMARY></INDEXTERM>
The following is a copy of the GNU Free Documentation License, which
is also at <systemitem
role="url">http://www.gnu.org/copyleft/fdl.html</systemitem>.
</para>
<literallayout>
Version 1.1, March 2000
Copyright &copy; 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
</literallayout>
<sect1><title>0. Preamble</title>
<para>
The purpose of this License is to make a manual, textbook, or other
written document "free" in the sense of freedom: to assure everyone
the effective freedom to copy and redistribute it, with or without
modifying it, either commercially or noncommercially. Secondarily,
this License preserves for the author and publisher a way to get
credit for their work, while not being considered responsible for
modifications made by others.
</para>
<para>
This License is a kind of "copyleft," which means that derivative
works of the document must themselves be free in the same sense. It
complements the GNU General Public License, which is a copyleft
license designed for free software.
</para>
<para>
We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the
software does. But this License is not limited to software manuals;
it can be used for any textual work, regardless of subject matter or
whether it is published as a printed book. We recommend this License
principally for works whose purpose is instruction or reference.
</para>
</sect1>
<sect1><title>1. Applicability and Definitions</title>
<para>
This License applies to any manual or other work that contains a
notice placed by the copyright holder saying it can be distributed
under the terms of this License. The "Document," below, refers to any
such manual or work. Any member of the public is a licensee, and is
addressed as "you."
</para>
<para>
A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.
</para>
<para>
A "Secondary Section" is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall subject
(or to related matters) and contains nothing that could fall directly
within that overall subject. (For example, if the Document is in part a
textbook of mathematics, a Secondary Section may not explain any
mathematics.) The relationship could be a matter of historical
connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical or political position regarding
them.
</para>
<para>
The "Invariant Sections" are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the notice
that says that the Document is released under this License.
</para>
<para>
The "Cover Texts" are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
the Document is released under this License.
</para>
<para>
A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public, whose contents can be viewed and edited directly and
straightforwardly with generic text editors or (for images composed of
pixels) generic paint programs or (for drawings) some widely available
drawing editor, and that is suitable for input to text formatters or
for automatic translation to a variety of formats suitable for input
to text formatters. A copy made in an otherwise Transparent file
format whose markup has been designed to thwart or discourage
subsequent modification by readers is not Transparent. A copy that is
not "Transparent" is called "Opaque."
</para>
<para>
<?troff .hw generated>
Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format, SGML
or XML using a publicly available DTD, and standard-conforming simple
HTML designed for human modification. Opaque formats include
PostScript, PDF, proprietary formats that can be read and edited only
by proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the
machine-generated HTML produced by some word processors for output
purposes only.
</para>
<para>
The "Title Page" means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the material
this License requires to appear in the title page. For works in
formats that do not have any title page as such, "Title Page" means
the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.
</para>
</sect1>
<sect1><title>2. Verbatim Copying</title>
<para>
You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies
to the Document are reproduced in all copies, and that you add no other
conditions whatsoever to those of this License. You may not use
technical measures to obstruct or control the reading or further
copying of the copies you make or distribute. However, you may accept
compensation in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in section 3.
</para>
<para>
You may also lend copies, under the same conditions stated above, and
you may publicly display copies.
</para>
</sect1>
<sect1><title>3. Copying in Quantity</title>
<para>
If you publish printed copies of the Document numbering more than 100,
and the Document's license notice requires Cover Texts, you must enclose
the copies in covers that carry, clearly and legibly, all these Cover
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
the back cover. Both covers must also clearly and legibly identify
you as the publisher of these copies. The front cover must present
the full title with all words of the title equally prominent and
visible. You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve
the title of the Document and satisfy these conditions, can be treated
as verbatim copying in other respects.
</para>
<para>
If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto adjacent
pages.
</para>
<para>
If you publish or distribute Opaque copies of the Document numbering
more than 100, you must either include a machine-readable Transparent
copy along with each Opaque copy, or state in or with each Opaque copy
a publicly-accessible computer-network location containing a complete
Transparent copy of the Document, free of added material, which the
general network-using public has access to download anonymously at no
charge using public-standard network protocols. If you use the latter
option, you must take reasonably prudent steps, when you begin
distribution of Opaque copies in quantity, to ensure that this
Transparent copy will remain thus accessible at the stated location
until at least one year after the last time you distribute an Opaque
copy (directly or through your agents or retailers) of that edition to
the public.
</para>
<para>
It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give
them a chance to provide you with an updated version of the Document.
</para>
</sect1>
<sect1><title>4. Modifications</title>
<para>
You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release
the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution
and modification of the Modified Version to whoever possesses a copy
of it. In addition, you must do these things in the Modified Version:
</para>
<orderedlist numeration="upperalpha">
<listitem><para>Use in the Title Page (and on the covers, if any) a title distinct
from that of the Document, and from those of previous versions
(which should, if there were any, be listed in the History section
of the Document). You may use the same title as a previous version
if the original publisher of that version gives permission.
</para></listitem>
<listitem><para>List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified
Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has less than five).
</para></listitem>
<listitem><para>State on the Title page the name of the publisher of the
Modified Version, as the publisher.
</para></listitem>
<listitem><para>Preserve all the copyright notices of the Document.
</para></listitem>
<listitem><para>Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.
</para></listitem>
<listitem><para>Include, immediately after the copyright notices, a license notice
giving the public permission to use the Modified Version under the
terms of this License, in the form shown in the Addendum below.
</para></listitem>
<listitem><para>Preserve in that license notice the full lists of Invariant Sections
and required Cover Texts given in the Document's license notice.
</para></listitem>
<listitem><para>Include an unaltered copy of this License.
</para></listitem>
<listitem><para>Preserve the section entitled "History," and its title, and add to
it an item stating at least the title, year, new authors, and
publisher of the Modified Version as given on the Title Page. If
there is no section entitled "History" in the Document, create one
stating the title, year, authors, and publisher of the Document as
given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
</para></listitem>
<listitem><para>Preserve the network location, if any, given in the Document for
public access to a Transparent copy of the Document, and likewise
the network locations given in the Document for previous versions
it was based on. These may be placed in the "History" section.
You may omit a network location for a work that was published at
least four years before the Document itself, or if the original
publisher of the version it refers to gives permission.
</para></listitem>
<listitem><para>In any section entitled "Acknowledgements" or "Dedications,"
preserve the section's title, and preserve in the section all the
substance and tone of each of the contributor acknowledgements
and/or dedications given therein.
</para></listitem>
<listitem><para>Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section numbers
or the equivalent are not considered part of the section titles.
</para></listitem>
<listitem><para>Delete any section entitled "Endorsements." Such a section
may not be included in the Modified Version.
</para></listitem>
<listitem><para>Do not retitle any existing section as "Endorsements"
or to conflict in title with any Invariant Section.
</para></listitem>
</orderedlist>
<para>
If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant. To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.
</para>
<para>
You may add a section entitled "Endorsements," provided it contains
nothing but endorsements of your Modified Version by various
parties&mdash;for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a
standard.
</para>
<para>
You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list
of Cover Texts in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or
through arrangements made by) any one entity. If the Document already
includes a cover text for the same cover, previously added by you or
by arrangement made by the same entity you are acting on behalf of,
you may not add another; but you may replace the old one, on explicit
permission from the previous publisher that added the old one.
</para>
<para>
The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or
imply endorsement of any Modified Version.
</para>
</sect1>
<sect1><title>5. Combining Documents</title>
<para>
You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified
versions, provided that you include in the combination all of the
Invariant Sections of all of the original documents, unmodified, and
list them all as Invariant Sections of your combined work in its
license notice.
</para>
<para>
The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy. If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original
author or publisher of that section if known, or else a unique number.
Make the same adjustment to the section titles in the list of
Invariant Sections in the license notice of the combined work.
</para>
<para>
In the combination, you must combine any sections entitled "History"
in the various original documents, forming one section entitled
"History"; likewise combine any sections entitled "Acknowledgements,"
and any sections entitled "Dedications." You must delete all sections
entitled "Endorsements."
</para>
</sect1>
<sect1><title>6. Collections of Documents</title>
<para>
You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies of this
License in the various documents with a single copy that is included in
the collection, provided that you follow the rules of this License for
verbatim copying of each of the documents in all other respects.
</para>
<para>
You may extract a single document from such a collection, and distribute
it individually under this License, provided you insert a copy of this
License into the extracted document, and follow this License in all
other respects regarding verbatim copying of that document.
</para>
</sect1>
<sect1><title>7. Aggregation with Independent Works</title>
<para>
A compilation of the Document or its derivatives with other separate
and independent documents or works, in or on a volume of a storage or
distribution medium, does not as a whole count as a Modified Version
of the Document, provided no compilation copyright is claimed for the
compilation. Such a compilation is called an "aggregate," and this
License does not apply to the other self-contained works thus compiled
with the Document, on account of their being thus compiled, if they
are not themselves derivative works of the Document.
</para>
<para>
If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one quarter
of the entire aggregate, the Document's Cover Texts may be placed on
covers that surround only the Document within the aggregate.
Otherwise they must appear on covers around the whole aggregate.
</para>
</sect1>
<sect1><title>8. Translation</title>
<para>
Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section 4.
Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections. You may include a
translation of this License provided that you also include the
original English version of this License. In case of a disagreement
between the translation and the original English version of this
License, the original English version will prevail.
</para>
</sect1>
<sect1><title>9. Termination</title>
<para>
You may not copy, modify, sublicense, or distribute the Document except
as expressly provided for under this License. Any other attempt to
copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this
License will not have their licenses terminated so long as such
parties remain in full compliance.
</para>
</sect1>
<sect1><title>10. Future Revisions of this License</title>
<para>
The Free Software Foundation may publish new, revised versions
of the GNU Free Documentation License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See
<systemitem
role="url">http://www.gnu.org/copyleft/</systemitem>.
</para>
<para>
Each version of the License is given a distinguishing version number.
If the Document specifies that a particular numbered version of this
License "or any later version" applies to it, you have the option of
following the terms and conditions either of that specified version or
of any later version that has been published (not as a draft) by the
Free Software Foundation. If the Document does not specify a version
number of this License, you may choose any version ever published (not
as a draft) by the Free Software Foundation.
</para>
</sect1>
<INDEXTERM startref="GNU.FDL" class=endofrange>
</appendix>

View File

@ -0,0 +1,56 @@
<appendix id="X-087-2-sage.app"><title>SAGE: The System<?lb>Administrators Guild</title>
<INDEXTERM><primary>SAGE (System Administrator's Guild)</primary></INDEXTERM>
<INDEXTERM><primary>USENIX Association, SAGE</primary></INDEXTERM>
<para>
If you are not getting everything you need from posting to
<systemitem role="newsgroup">comp.os.linux.*</systemitem> groups and reading documentation, maybe it's time to
consider joining SAGE, the System Administrators Guild, sponsored by
USENIX. The main goal of SAGE is to advance system administration as
a profession. SAGE brings together system and network administrators
to foster professional and technical development, share problems and
solutions, and communicate with users, management, and vendors on
system administration topics.
</para>
<para>
Current SAGE initiatives include:
<itemizedlist>
<listitem><para>
Co-sponsoring the highly successful annual System
Administration Conferences (LISA) with USENIX.
</para></listitem>
<listitem><para>
Publishing <command>Job Descriptions for System Administrators</command>, edited by Tina
Darmohray, the first in a series of very practical booklets and resource
guides covering system administration issues and techniques.
</para></listitem>
<listitem><para>
Creating an archive site, <systemitem role="sitename">ftp.sage.usenix.org</systemitem>, for papers from the System
Administration Conferences and sysadmin-related documentation.
</para></listitem>
<listitem><para>
Establishing working groups in areas important to system administrators,
such as jobs, publications, policies, electronic information distribution,
education, vendors, and standards.
</para></listitem>
</itemizedlist>
</para>
<para>
To learn more about the USENIX Association and its Special Technical
Group, SAGE, contact the USENIX Association office at (510) 528-8649 in
the U.S., or by email to
<systemitem role="emailaddr">office@usenix.org</systemitem>.
To receive information electronically, contact
<systemitem role="emailaddr">info@usenix.org</systemitem>.
Annual SAGE membership is $25 (you must also be a member of USENIX).
Members enjoy free subscriptions to <emphasis>login:</emphasis> and
<command>Computing Systems</command>, a quarterly refereed technical journal;
discounts on conference and symposia registration; and
savings on SAGE publication purchases and other services.
</para>
<?troff .BLANK>
</appendix>

View File

@ -0,0 +1,66 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V3.1//EN" [
<!ENTITY ch00 SYSTEM "ch00.sgm">
<!ENTITY ch01 SYSTEM "ch01.sgm">
<!ENTITY ch02 SYSTEM "ch02.sgm">
<!ENTITY ch03 SYSTEM "ch03.sgm">
<!ENTITY ch04 SYSTEM "ch04.sgm">
<!ENTITY ch05 SYSTEM "ch05.sgm">
<!ENTITY ch06 SYSTEM "ch06.sgm">
<!ENTITY ch07 SYSTEM "ch07.sgm">
<!ENTITY ch08 SYSTEM "ch08.sgm">
<!ENTITY ch09 SYSTEM "ch09.sgm">
<!ENTITY ch10 SYSTEM "ch10.sgm">
<!ENTITY ch11 SYSTEM "ch11.sgm">
<!ENTITY ch12 SYSTEM "ch12.sgm">
<!ENTITY ch13 SYSTEM "ch13.sgm">
<!ENTITY ch14 SYSTEM "ch14.sgm">
<!ENTITY ch15 SYSTEM "ch15.sgm">
<!ENTITY ch16 SYSTEM "ch16.sgm">
<!ENTITY ch17 SYSTEM "ch17.sgm">
<!ENTITY ch18 SYSTEM "ch18.sgm">
<!ENTITY ch19 SYSTEM "ch19.sgm">
<!ENTITY ch20 SYSTEM "ch20.sgm">
<!ENTITY ch21 SYSTEM "ch21.sgm">
<!ENTITY ch22 SYSTEM "ch22.sgm">
<!ENTITY ch23 SYSTEM "ch23.sgm">
<!ENTITY ch24 SYSTEM "ch24.sgm">
<!ENTITY appa SYSTEM "appa.sgm">
<!ENTITY appb SYSTEM "appb.sgm">
<!ENTITY appc SYSTEM "appc.sgm">
<!ENTITY appd SYSTEM "appd.sgm">
<!ENTITY doc-index SYSTEM "index.sgml">
]>
<book id="LNAG">
<title>Linux Network Administrators Guide</title>
&ch00;
&ch01;
&ch02;
&ch03;
&ch04;
&ch05;
&ch06;
&ch07;
&ch08;
&ch09;
&ch10;
&ch11;
&ch12;
&ch13;
&ch14;
&ch15;
&ch16;
&ch17;
&ch18;
&ch19;
&ch20;
&ch21;
&ch22;
&ch23;
&ch24;
&appa;
&appb;
&appc;
&appd;
&doc-index;
</book>

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@ -0,0 +1,946 @@
<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">&thinsp;) 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 &ldquo;real&rdquo; 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 &ldquo;reserved&rdquo; or &ldquo;private&rdquo;
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&mdash;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>
</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>
</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: &ldquo;both.&rdquo;
<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&mdash;along with the corresponding netmask&mdash;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>&hellip;</entry>
<entry>&hellip;</entry>
<entry>&hellip;</entry>
<entry>&hellip;</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 &ldquo;optimal&rdquo; 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 &ldquo;Port
Unreachable.&rdquo;
</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 (&thinsp;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 &ldquo;ordinary&rdquo; 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(&thinsp;)</primary></indexterm>
<indexterm><primary>gethostbyaddr(&thinsp;)</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>&thinsp;; on Linux, these functions
are part of the standard <filename>libc</filename>. Colloquially, this
collection of functions is therefore referred to as &ldquo;the
resolver.&rdquo; 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>

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@ -0,0 +1,853 @@
<chapter id="X-087-2-accounting"><title>IP Accounting</title>
<para>
<indexterm id="chac.tcp.ip.accounting" class="startofrange"><primary>TCP/IP (Transmission Control Protocol/Internet Protocol)</primary><secondary>accounting</secondary></indexterm>
In today&rsquo;s world of commercial Internet service, it is becoming
increasingly important to know
how much data you are transmitting and receiving on your network connections.
If you are an Internet Service Provider and you charge your customers by
volume, this will be essential to your business. If you are a customer
of an Internet Service Provider that charges by data volume, you will
find it useful to collect your own data to ensure the accuracy of your
Internet charges.
</para>
<para>
There are other uses for network accounting that have nothing to do with
dollars and bills. If you manage a server that offers a number of different
types of network services, it might be useful to you to know exactly
how much data is being generated by each one. This sort of information
could assist you in making decisions, such as what hardware to buy or how
many servers to run.
</para>
<para>
The Linux kernel provides a facility that allows you to collect all sorts
of useful information about the network traffic it sees. This facility
is called <emphasis>IP accounting</emphasis>.
</para>
<sect1 id="X-087-2-accounting.kernel.config"><title>Configuring the Kernel <?lb>for IP Accounting</title>
<para>
<indexterm><primary>IP accounting</primary><secondary>kernel configuration</secondary></indexterm>
<INDEXTERM><PRIMARY>configuring</PRIMARY><SECONDARY>kernel</SECONDARY><TERTIARY SORTAS="IP accounting">for IP accounting</TERTIARY></INDEXTERM>
The Linux IP accounting feature is very closely related to the Linux
firewall software. The places you want to collect
accounting data are the same places that you would be interested in
performing firewall filtering: into and out of a network host, and in the
software that does the routing of datagrams. If you haven't read the section
on firewalls, now is probably a good time to do so, as we will be using some of
the concepts described in <xref linkend="X-087-2-firewall">.
</para>
<para>
<INDEXTERM><PRIMARY>2.0 kernels</PRIMARY><SECONDARY>IP accounting</SECONDARY></INDEXTERM>
<INDEXTERM><PRIMARY>2.2 kernels</PRIMARY><SECONDARY>IP accounting</SECONDARY></INDEXTERM>