os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Nitpick English changes to make the chapter more understandable.

Browse source
This commit is contained in:
Chern Lee 2001-08-20 18:48:45 +00:00
parent 3752f1a2de
commit d9b35c6b35
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=10412
1 changed files with 72 additions and 62 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

134
en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
View file

@ -1,7 +1,7 @@
<!--
The FreeBSD Documentation Project
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.90 2001/08/16 18:35:00 chern Exp $
$FreeBSD: doc/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.91 2001/08/16 18:42:51 chern Exp $
-->
<chapter id="advanced-networking">
@ -85,27 +85,31 @@
<indexterm><primary>routing</primary></indexterm>
<indexterm><primary>gateway</primary></indexterm>
<indexterm><primary>subnet</primary></indexterm>
<para>For one machine to be able to find another, there must be a
<para>For one machine to be able to find another over a network, there
must be a
mechanism in place to describe how to get from one to the other. This is
called Routing. A <quote>route</quote> is a defined pair of addresses: a
<quote>destination</quote> and a <quote>gateway</quote>. The pair
indicates that if you are trying to get to this
<emphasis>destination</emphasis>, send along through this
<emphasis>destination</emphasis>, communicate through this
<emphasis>gateway</emphasis>. There are three types of destinations:
individual hosts, subnets, and <quote>default</quote>. The
<quote>default route</quote> is used if none of the other routes apply.
We will talk a little bit more about default routes later on. There are
also three types of gateways: individual hosts, interfaces (also called
<quote>links</quote>), and Ethernet hardware addresses.</para>
<quote>links</quote>), and Ethernet hardware addresses (MAC addresses).
</para>
<sect2>
<title>An Example</title>
<para>To illustrate different aspects of routing, we will use the
following example which is the output of the command <command>netstat
-r</command>:</para>
<screen>Destination Gateway Flags Refs Use Netif Expire
following example from <command>netstat</command>:</para>
<screen>&prompt.user; netstat -r
Routing tables
Destination Gateway Flags Refs Use Netif Expire
default outside-gw UGSc 37 418 ppp0
localhost localhost UH 0 181 lo0
@ -118,8 +122,9 @@ host2.foobar.com link#1 UC 0 0
224 link#1 UC 0 0</screen>
<indexterm><primary>default route</primary></indexterm>
<para>The first two lines specify the default route (which we will cover
in the next section) and the <hostid>localhost</hostid> route.</para>
<para>The first two lines specify the default route (which we
will cover in the <link linkend="routing-default">next
section</link>) and the <hostid>localhost</hostid> route.</para>
<indexterm><primary>loopback device</primary></indexterm>
<para>The interface (<literal>Netif</literal> column) that it specifies
@ -127,15 +132,16 @@ host2.foobar.com link#1 UC 0 0
<devicename>lo0</devicename>, also known as the loopback device. This
says to keep all traffic for this destination internal, rather than
sending it out over the LAN, since it will only end up back where it
started anyway.</para>
started.</para>
<indexterm>
<primary>Ethernet</primary>
<secondary>MAC address</secondary>
</indexterm>
<para>The next thing that stands out are the <hostid
role="mac">0:e0:...</hostid> addresses. These are Ethernet hardware
addresses. FreeBSD will automatically identify any hosts
<para>The next thing that stands out are the addresses beginning
with <hostid role="mac">0:e0:</hostid>. These are Ethernet
hardware addresses, which are also known as MAC addresses.
FreeBSD will automatically identify any hosts
(<hostid>test0</hostid> in the example) on the local Ethernet and add
a route for that host, directly to it over the Ethernet interface,
<devicename>ed0</devicename>. There is also a timeout
@ -157,8 +163,9 @@ host2.foobar.com link#1 UC 0 0
<para>Both of these groups (local network hosts and local subnets) have
their routes automatically configured by a daemon called
<command>routed</command>. If this is not run, then only routes which
are statically defined (ie. entered explicitly) will exist.</para>
<application>routed</application>. If this is not run, then only
routes which are statically defined (ie. entered explicitly) will
exist.</para>
<para>The <literal>host1</literal> line refers to our host, which it
knows by Ethernet address. Since we are the sending host, FreeBSD
@ -232,7 +239,7 @@ host2.foobar.com link#1 UC 0 0
</informaltable>
</sect2>
<sect2>
<sect2 id="routing-default">
<title>Default Routes</title>
<indexterm><primary>default route</primary></indexterm>
@ -274,9 +281,9 @@ host2.foobar.com link#1 UC 0 0
<tgroup cols="3">
<thead>
<row>
<entry>host</entry>
<entry>default gateway</entry>
<entry>interface</entry>
<entry>Host</entry>
<entry>Default Gateway</entry>
<entry>Interface</entry>
</row>
</thead>
@ -330,7 +337,7 @@ Local1 (10.20.30.1, 10.9.9.30) --&gt; T1-GW (10.9.9.1)
used to refer to a machine that sits on two local-area
networks.</para>
<para>In one case, the machine as two Ethernet cards, each having an
<para>In one case, the machine has two Ethernet cards, each having an
address on the separate subnets. Alternately, the machine may only
have one Ethernet card, and be using &man.ifconfig.8; aliasing. The former is
used if two physically separate Ethernet networks are in use, the
@ -414,15 +421,15 @@ Local1 (10.20.30.1, 10.9.9.30) --&gt; T1-GW (10.9.9.1)
<title>Introduction</title>
<indexterm><primary>IP subnet</primary></indexterm>
<indexterm><primary>bridge</primary></indexterm>
<para>It is sometimes useful to divide one physical network (i.e., an
Ethernet segment) into two separate network segments, without having
<para>It is sometimes useful to divide one physical network (such as an
Ethernet segment) into two separate network segments without having
to create IP subnets and use a router to connect the segments
together. A device that connects two networks together in this
fashion is called a bridge. and a FreeBSD system with two network
fashion is called a bridge. A FreeBSD system with two network
interface cards can act as a bridge.</para>
<para>The bridge works by learning the MAC layer addresses (i.e.,
Ethernet addresses) of the devices on each of its network interfaces.
<para>The bridge works by learning the MAC layer addresses
(Ethernet addresses) of the devices on each of its network interfaces.
It forwards traffic between two networks only when its source and
destination are on different networks.</para>
@ -467,8 +474,8 @@ Local1 (10.20.30.1, 10.9.9.30) --&gt; T1-GW (10.9.9.1)
needed without IP Masquerading (NAT).</para>
<para>An example is a small company that is connected via DSL or ISDN
to their ISP. They have a 13 address global IP allocation for their
ISP and have 10 PCs on their network. In this situation, using a
to their ISP. They have a 13 globally-accessible IP addresses
from their ISP and have 10 PCs on their network. In this situation, using a
router-based firewall is difficult because of subnetting
issues.</para>
@ -503,7 +510,7 @@ Local1 (10.20.30.1, 10.9.9.30) --&gt; T1-GW (10.9.9.1)
<secondary>options BRIDGE</secondary>
</indexterm>
<para>To enable kernel support for bridging, add the</para>
<para>To enable kernel support for bridging, add the:</para>
<programlisting>options BRIDGE</programlisting>
@ -541,13 +548,13 @@ Local1 (10.20.30.1, 10.9.9.30) --&gt; T1-GW (10.9.9.1)
<sect2>
<title>Enabling the Bridge</title>
<para>Add the line</para>
<para>Add the line:</para>
<programlisting>net.link.ether.bridge=1</programlisting>
<para>to <filename>/etc/sysctl.conf</filename> to enable the bridge at
runtime. If you want the bridged packets to be filtered by &man.ipfw.8;,
you should also add</para>
you should also add:</para>
<programlisting>net.link.ether.bridge_ipfw=1</programlisting>
@ -594,8 +601,8 @@ Local1 (10.20.30.1, 10.9.9.30) --&gt; T1-GW (10.9.9.1)
<indexterm><primary>NFS</primary></indexterm>
<para>Among the many different file systems that FreeBSD supports is
the Network File System or NFS. NFS allows you
to share directories and files on one machine with one or more other
machines via the network they are attached to. Using NFS, users and
to share directories and files on one machine with others
via the network they are attached to. Using NFS, users and
programs can access files on remote systems as if they were local
files.</para>
@ -630,7 +637,7 @@ Local1 (10.20.30.1, 10.9.9.30) --&gt; T1-GW (10.9.9.1)
<emphasis>wants</emphasis> the data that the server side
<emphasis>has</emphasis>. The server shares its data with the
client. In order for this system to function properly a few
processes have to be configured and running properly.</para>
processes have to be configured and running.</para>
<para>The server has to be running the following daemons:</para>
<indexterm>
@ -759,7 +766,7 @@ nfs_client_flags="-n 4"</programlisting>
<programlisting>/a -maproot=0 host.domain.com box.example.com</programlisting>
<para>In order for a client to share an exported file system it must
<para>In order for a client to access- an exported file system it must
have permission to do so. Make sure your client is listed in your
<filename>/etc/exports</filename> file.</para>
@ -797,7 +804,8 @@ nfs_client_flags="-n 4"</programlisting>
</indexterm>
<screen>&prompt.root; <userinput>mount server:/home /mnt</userinput></screen>
<para>This will mount <filename>/home</filename> on the server on
<para>This will mount the <filename>/home</filename> directory on the
server at
<filename>/mnt</filename> on the client. If everything is setup
correctly you should be able to go into /mnt on the client and see
all the files that are on the server.</para>
@ -992,7 +1000,7 @@ Exports list on foobar:
<hostid>freebox</hostid> is the host (interface) name of a FreeBSD
system with a lower-performance Ethernet adapter. Also,
<filename>/sharedfs</filename> will be the exported NFS
filesystem (see <command>man exports</command>), and
filesystem (see &man.exports.5;), and
<filename>/project</filename> will be the mount point on the
client for the exported file system. In all cases, note that
additional options, such as <option>hard</option> or
@ -1523,7 +1531,8 @@ hostname myclient.mydomain</programlisting>
should discuss your needs with them.</para>
<para>If you are planning to connect two LAN segments together,
ie: home LAN to the office LAN, this is the simplest lowest
such as your home LAN to the office LAN, this is the simplest
lowest
maintenance solution. Since you are buying the equipment for
both sides of the connection you can be assured that the link
will work.</para>
@ -1602,22 +1611,23 @@ ISDN BRI line</literallayout>
<para>One large advantage of most routers/bridges is that they allow you
to have 2 <emphasis>separate independent</emphasis> PPP connections to
2 separate sites at the <emphasis>same</emphasis> time. This is not
supported on most TA's, except for specific(expensive) models that
have two serial ports. Do not confuse this with channel bonding, MPP
supported on most TA's, except for specific (usually expensive) models
that
have two serial ports. Do not confuse this with channel bonding, MPP,
etc.</para>
<para>This can be very useful feature, for example if you have an
<para>This can be very useful feature if, for example, you have an
dedicated ISDN connection at your office and would like to
tap into it, but do not want to get another ISDN line at work. A router
at the office location can manage a dedicated B channel connection
(64Kbs) to the Internet, as well as a use the other B channel for a
(64Kbps) to the Internet and use the other B channel for a
separate data connection. The second B channel can be used for
dial-in, dial-out or dynamically bond(MPP etc.) with the first B channel
for more bandwidth.</para>
dial-in, dial-out or dynamically bonding (MPP, etc.) with the first
B channel for more bandwidth.</para>
<indexterm><primary>IPX/SPX</primary></indexterm>
<para>An Ethernet bridge will also allow you to transmit more than just
IP traffic, you can also send IPX/SPX or whatever other protocols you
IP traffic. You can also send IPX/SPX or whatever other protocols you
use.</para>
</sect2>
</sect1>
@ -1747,7 +1757,7 @@ ISDN BRI line</literallayout>
<sect2>
<title>How Does It Work?</title>
<para>There are three types of hosts in an NIS environment; master
<para>There are three types of hosts in an NIS environment: master
servers, slave servers, and clients. Servers act as a central
repository for host configuration information. Master servers
hold the authoritative copy of this information, while slave
@ -1952,7 +1962,7 @@ ISDN BRI line</literallayout>
have its own independent set of maps.</para>
<para>NIS master and slave servers handle all NIS requests with
the <command>ypserv</command> daemon. <command>Ypserv</command>
the <command>ypserv</command> daemon. <command>ypserv</command>
is responsible for receiving incoming requests from NIS clients,
translating the requested domain and map name to a path to the
corresponding database file and transmitting data from the
@ -2163,14 +2173,13 @@ Don't forget to update map ypservers on ellington.</screen>
21 * * * * root /usr/libexec/ypxfr passwd.byuid</programlisting>
<para>These two lines force the slave to sync its maps with
the maps on the master server. Although this is
not mandatory, because the master server
tries to make sure any changes to its NIS maps are
communicated to its slaves, the password
information is so vital to systems that depend on the server,
that it is a good idea to force the updates. This is more
important on busy networks where map updates might not always
complete.</para>
the maps on the master server. Although these entries are
not mandatory, since the master server attempts to ensure
any changes to its NIS maps are communicated to its slaves
and because password information is vital to systems
depending on the server, it is a good idea to force the
updates. This is more important on busy networks where map
updates might not always complete.</para>
<para>Now, run the command <command>/etc/netstart</command> on the
slave server as well, which again starts the NIS server.</para>
@ -2195,7 +2204,7 @@ Don't forget to update map ypservers on ellington.</screen>
several slaves, for example), <command>ypbind</command> will
use the address of the first one to respond. From that point
on, the client system will direct all of its NIS requests to
that server. <command>Ypbind</command> will
that server. <command>ypbind</command> will
occasionally <quote>ping</quote> the server to make sure it is
still up and running. If it fails to receive a reply to one of
its pings within a reasonable amount of time,
@ -2236,7 +2245,7 @@ nis_client_enable="YES"</programlisting>
the NIS server's password maps an account. There are
many ways to configure your NIS client by changing this
line. See the <link linkend="netgroups">netgroups
part</link> below for more information.
section</link> below for more information.
For more detailed reading see O'Reilly's book on
<literal>Managing NFS and NIS</literal>.</para>
</note>
@ -2293,9 +2302,10 @@ nis_client_enable="YES"</programlisting>
address fails to match a rule, the request will be ignored and a
warning message will be logged. If the
<filename>/var/yp/securenets</filename> file does not exist,
ypserv will allow connections from any host.</para>
<command>ypserv</command> will allow connections from any host.</para>
<para>The ypserv program also has support for Wietse Venema's
<para>The <command>ypserv</command> program also has support for Wietse
Venema's
<application>tcpwrapper</application> package. This allows the
administrator to use the <application>tcpwrapper</application> configuration
files for access control instead of
@ -2400,7 +2410,7 @@ basie&prompt.root;</screen>
<title>Using Netgroups</title>
<indexterm><primary>netgroups</primary></indexterm>
<para>The method shown in the previous chapter works reasonably
<para>The method shown in the previous section works reasonably
well if you need special rules for a very small number of
users and/or machines. On larger networks, you
<emphasis>will</emphasis> forget to bar some users from logging
@ -2420,7 +2430,7 @@ basie&prompt.root;</screen>
a Good Thing if you are forced to deal with such a situation.
On the other hand, this complexity makes it almost impossible to
explain netgroups with really simple examples. The example
used in the remainder of this chapter demonstrates this
used in the remainder of this section demonstrates this
problem.</para>
<para>Let us assume that your successful introduction of NIS in
@ -2945,7 +2955,7 @@ lrwxr-xr-x 1 root wheel 14 Nov 8 14:27 libscrypt.so@ -> libscrypt.so.2
<sect2>
<title>What this Section Covers</title>
<para>This handbook section attempts to describe only the parts
<para>This section attempts to describe only the parts
of the DHCP system that are integrated with FreeBSD;
consequently, the server portions are not described. The DHCP
manual pages, in addition to the references below, are useful