svn commit: r42014 - in head/en_US.ISO8859-1/books/handbook: advanced-networking audit basics boot config disks eresources install kernelconfig mac mail multimedia network-servers ports security users
Glen Barber
gjb at FreeBSD.org
Sun Jun 23 22:37:08 UTC 2013
Author: gjb
Date: Sun Jun 23 22:37:08 2013
New Revision: 42014
URL: http://svnweb.freebsd.org/changeset/doc/42014
Log:
MF ISBN:
Merged /projects/print2013/en_US.ISO8859-1:r40693-40726
Merged /projects/ISBN_1-57176-407-0/en_US.ISO8859-1:r40727-41455,
41457-41469,41472-41477,41479-41513,41515-41521,41523-41577,
41579-41581,41583-42013
Notes: This merge entirely excludes the en_US/books/handbook/ppp-and-slip/
changes. They will need to be looked at a bit more closely.
Note to translators: I am very, very sorry. There was no *clean* way
to merge this as separate commits. Trust me, I tried.
The revision logs for the ISBN branch should provide some insight to what
content has changed. I am more than happy to help out here. Sorry :(
Approved by: doceng (implicit)
Modified:
head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
head/en_US.ISO8859-1/books/handbook/audit/chapter.xml
head/en_US.ISO8859-1/books/handbook/basics/chapter.xml
head/en_US.ISO8859-1/books/handbook/boot/chapter.xml
head/en_US.ISO8859-1/books/handbook/config/chapter.xml
head/en_US.ISO8859-1/books/handbook/disks/chapter.xml
head/en_US.ISO8859-1/books/handbook/eresources/chapter.xml
head/en_US.ISO8859-1/books/handbook/install/chapter.xml
head/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.xml
head/en_US.ISO8859-1/books/handbook/mac/chapter.xml
head/en_US.ISO8859-1/books/handbook/mail/chapter.xml
head/en_US.ISO8859-1/books/handbook/multimedia/chapter.xml
head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
head/en_US.ISO8859-1/books/handbook/ports/chapter.xml
head/en_US.ISO8859-1/books/handbook/security/chapter.xml
head/en_US.ISO8859-1/books/handbook/users/chapter.xml
Directory Properties:
head/en_US.ISO8859-1/ (props changed)
Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Sun Jun 23 21:55:52 2013 (r42013)
+++ head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Sun Jun 23 22:37:08 2013 (r42014)
@@ -11,7 +11,7 @@
<sect1 id="advanced-networking-synopsis">
<title>Synopsis</title>
- <para>This chapter will cover a number of advanced networking
+ <para>This chapter covers a number of advanced networking
topics.</para>
<para>After reading this chapter, you will know:</para>
@@ -27,7 +27,7 @@
</listitem>
<listitem>
- <para>How to make FreeBSD act as a bridge.</para>
+ <para>How to make &os; act as a bridge.</para>
</listitem>
<listitem>
@@ -36,8 +36,9 @@
</listitem>
<listitem>
- <para>How to set up network PXE booting with an NFS root file
- system.</para>
+ <para>How to set up network <acronym>PXE</acronym> booting
+ with an
+ <acronym>NFS</acronym> root file system.</para>
</listitem>
<listitem>
@@ -45,16 +46,18 @@
</listitem>
<listitem>
- <para>How to set up IPv6 on a FreeBSD machine.</para>
+ <para>How to set up <acronym>IPv6</acronym> on a &os;
+ machine.</para>
</listitem>
<listitem>
- <para>How to configure ATM.</para>
+ <para>How to configure <acronym>ATM</acronym>.</para>
</listitem>
<listitem>
- <para>How to enable and utilize the features of CARP, the
- Common Address Redundancy Protocol in &os;</para>
+ <para>How to enable and utilize the features of the Common
+ Address Redundancy Protocol (<acronym>CARP</acronym>) in
+ &os;.</para>
</listitem>
</itemizedlist>
@@ -71,13 +74,13 @@
</listitem>
<listitem>
- <para>Know how to configure and install a new FreeBSD kernel
+ <para>Know how to configure and install a new &os; kernel
(<xref linkend="kernelconfig"/>).</para>
</listitem>
<listitem>
- <para>Know how to install additional third-party
- software (<xref linkend="ports"/>).</para>
+ <para>Know how to install additional third-party software
+ (<xref linkend="ports"/>).</para>
</listitem>
</itemizedlist>
@@ -105,22 +108,21 @@
one to the other. This is called
<firstterm>routing</firstterm>. 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>,
- communicate through this <emphasis>gateway</emphasis>. There
- are three types of destinations: individual hosts, subnets, and
+ <quote>gateway</quote>. The pair indicates that when trying
+ to get to 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
+ used if none of the other routes apply. There are also three
types of gateways: individual hosts, interfaces (also called
- <quote>links</quote>), and Ethernet hardware addresses (MAC
- addresses).</para>
+ <quote>links</quote>), and Ethernet hardware
+ (<acronym>MAC</acronym>) addresses.</para>
<sect2>
<title>An Example</title>
- <para>To illustrate different aspects of routing, we will use
- the following example from <command>netstat</command>:</para>
+ <para>This example &man.netstat.1; output illustrates several
+ aspects of routing:</para>
<screen>&prompt.user; <userinput>netstat -r</userinput>
Routing tables
@@ -138,9 +140,8 @@ host2.example.com link#1 UC
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
- <link linkend="network-routing-default">next section</link>)
+ <para>The first two lines specify the default route, described
+ in more detail in <xref linkend="network-routing-default"/>,
and the <hostid>localhost</hostid> route.</para>
<indexterm><primary>loopback device</primary></indexterm>
@@ -149,66 +150,60 @@ host2.example.com link#1 UC
<literal>localhost</literal> is <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.</para>
+ out over the network.</para>
<indexterm>
<primary>Ethernet</primary>
<secondary>MAC address</secondary>
</indexterm>
- <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 (<literal>Expire</literal> column) associated
- with this type of route, which is used if we fail to hear from
- the host in a specific amount of time. When this happens, the
- route to this host will be automatically deleted. These hosts
- are identified using a mechanism known as RIP (Routing
- Information Protocol), which figures out routes to local hosts
- based upon a shortest path determination.</para>
+ <para>The addresses beginning with <hostid
+ role="mac">0:e0:</hostid> are Ethernet hardware addresses,
+ also known as <acronym>MAC</acronym> addresses. &os; will
+ automatically identify any hosts, <hostid>test0</hostid> in
+ the example, on the local Ethernet and add a route for that
+ host over the Ethernet interface,
+ <devicename>ed0</devicename>. This type of route has a
+ timeout, seen in the <literal>Expire</literal> column, which
+ is used if the host does not respond in a specific amount of
+ time. When this happens, the route to this host will be
+ automatically deleted. These hosts are identified using the
+ Routing Information Protocol (<acronym>RIP</acronym>), which
+ calculates routes to local hosts based upon a shortest path
+ determination.</para>
<indexterm><primary>subnet</primary></indexterm>
- <para>FreeBSD will also add subnet routes for the local subnet
- (<hostid role="ipaddr">10.20.30.255</hostid> is the broadcast
- address for the subnet
- <hostid role="ipaddr">10.20.30</hostid>, and
- <hostid role="domainname">example.com</hostid> is the domain
- name associated with that subnet). The designation
+ <para>&os; will add subnet routes for the local subnet.
+ <hostid role="ipaddr">10.20.30.255</hostid> is the broadcast
+ address for the subnet <hostid role="ipaddr">10.20.30</hostid>
+ and <hostid role="domainname">example.com</hostid> is the
+ domain name associated with that subnet. The designation
<literal>link#1</literal> refers to the first Ethernet card in
- the machine. You will notice no additional interface is
- specified for those.</para>
+ the machine.</para>
+
+ <para>Local network hosts and local subnets have their routes
+ automatically configured by a daemon called &man.routed.8;.
+ If it is not running, only routes which are statically defined
+ by the administrator will exist.</para>
+
+ <para>The <literal>host1</literal> line refers to the host
+ by its Ethernet address. Since it is the sending host, &os;
+ knows to use the loopback interface
+ (<devicename>lo0</devicename>) rather than the Ethernet
+ interface.</para>
- <para>Both of these groups (local network hosts and local
- subnets) have their routes automatically configured by a
- daemon called <application>routed</application>. If this is
- not run, then only routes which are statically defined (i.e.,
- 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 knows to use the loopback interface
- (<devicename>lo0</devicename>) rather than sending it out over
- the Ethernet interface.</para>
-
- <para>The two <literal>host2</literal> lines are an example of
- what happens when we use an &man.ifconfig.8; alias (see the
- section on Ethernet for reasons why we would do this). The
+ <para>The two <literal>host2</literal> lines represent aliases
+ which were created using &man.ifconfig.8;. The
<literal>=></literal> symbol after the
- <devicename>lo0</devicename> interface says that not only are
- we using the loopback (since this address also refers to the
- local host), but specifically it is an alias. Such routes
+ <devicename>lo0</devicename> interface says that an alias
+ has been set in addition to the loopback address. Such routes
only show up on the host that supports the alias; all other
- hosts on the local network will simply have a
+ hosts on the local network will have a
<literal>link#1</literal> line for such routes.</para>
- <para>The final line (destination subnet
- <hostid role="ipaddr">224</hostid>) deals with multicasting,
- which will be covered in another section.</para>
+ <para>The final line (destination subnet <hostid
+ role="ipaddr">224</hostid>) deals with
+ multicasting.</para>
<para>Finally, various attributes of each route can be seen in
the <literal>Flags</literal> column. Below is a short table
@@ -247,7 +242,7 @@ host2.example.com link#1 UC
<row>
<entry>C</entry>
<entry>Clone: Generates a new route based upon this
- route for machines we connect to. This type of route
+ route for machines to connect to. This type of route
is normally used for local networks.</entry>
</row>
@@ -276,25 +271,24 @@ host2.example.com link#1 UC
<para>When the local system needs to make a connection to a
remote host, it checks the routing table to determine if a
known path exists. If the remote host falls into a subnet
- that we know how to reach (Cloned routes), then the system
- checks to see if it can connect along that interface.</para>
+ that it knows how to reach, the system checks to see if it
+ can connect using that interface.</para>
<para>If all known paths fail, the system has one last option:
the <quote>default</quote> route. This route is a special
type of gateway route (usually the only one present in the
system), and is always marked with a <literal>c</literal> in
the flags field. For hosts on a local area network, this
- gateway is set to whatever machine has a direct connection to
- the outside world (whether via PPP link, DSL, cable modem, T1,
- or another network interface).</para>
-
- <para>If you are configuring the default route for a machine
- which itself is functioning as the gateway to the outside
- world, then the default route will be the gateway machine at
- your Internet Service Provider's (ISP) site.</para>
+ gateway is set to the system which has a direct connection to
+ the Internet.</para>
- <para>Let us look at an example of default routes. This is a
- common configuration:</para>
+ <para>The default route for a machine which itself is
+ functioning as the gateway to the outside world, will be the
+ gateway machine at the Internet Service Provider
+ (<acronym>ISP</acronym>).</para>
+
+ <para>This example is a common configuration for a default
+ route:</para>
<mediaobject>
<imageobject>
@@ -308,14 +302,15 @@ host2.example.com link#1 UC
</mediaobject>
<para>The hosts <hostid>Local1</hostid> and
- <hostid>Local2</hostid> are at your site.
- <hostid>Local1</hostid> is connected to an ISP via a dial up
- PPP connection. This PPP server computer is connected through
- a local area network to another gateway computer through an
- external interface to the ISPs Internet feed.</para>
+ <hostid>Local2</hostid> are on the local network.
+ <hostid>Local1</hostid> is connected to an
+ <acronym>ISP</acronym> using a
+ <acronym>PPP</acronym> connection. This
+ <acronym>PPP</acronym> server is connected through a local
+ area network to another gateway computer through an external
+ interface to the <acronym>ISP</acronym>.</para>
- <para>The default routes for each of your machines will
- be:</para>
+ <para>The default routes for each machine will be:</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="3">
@@ -343,26 +338,28 @@ host2.example.com link#1 UC
</tgroup>
</informaltable>
- <para>A common question is <quote>Why (or how) would we set
- the <hostid>T1-GW</hostid> to be the default gateway for
- <hostid>Local1</hostid>, rather than the ISP server it is
- connected to?</quote>.</para>
-
- <para>Remember, since the PPP interface is using an address on
- the ISP's local network for your side of the connection,
- routes for any other machines on the ISP's local network will
- be automatically generated. Hence, you will already know how
+ <para>A common question is <quote>Why is
+ <hostid>T1-GW</hostid> configured as the default gateway for
+ <hostid>Local1</hostid>, rather than the
+ <acronym>ISP</acronym> server it is connected
+ to?</quote>.</para>
+
+ <para>Since the <acronym>PPP</acronym> interface is using an
+ address on the <acronym>ISP</acronym>'s local network for
+ the local side of the connection, routes for any other
+ machines on the <acronym>ISP</acronym>'s local network will
+ be automatically generated. The system already knows how
to reach the <hostid>T1-GW</hostid> machine, so there is no
- need for the intermediate step of sending traffic to the ISP
- server.</para>
+ need for the intermediate step of sending traffic to the
+ <acronym>ISP</acronym>'s server.</para>
- <para>It is common to use the address
- <hostid role="ipaddr">X.X.X.1</hostid> as the gateway address
- for your local network. So (using the same example), if your
- local class-C address space was
- <hostid role="ipaddr">10.20.30</hostid> and your ISP was using
- <hostid role="ipaddr">10.9.9</hostid> then the default routes
- would be:</para>
+ <para>It is common to use the address <hostid
+ role="ipaddr">X.X.X.1</hostid> as the gateway address for
+ the local network. So, if the local class C address space is
+ <hostid role="ipaddr">10.20.30</hostid> and the
+ <acronym>ISP</acronym> is using <hostid
+ role="ipaddr">10.9.9</hostid>, the default routes would
+ be:</para>
<informaltable frame="none" pgwide="1">
<tgroup cols="2">
@@ -387,19 +384,19 @@ host2.example.com link#1 UC
</informaltable>
<para>The default route can be easily defined in
- <filename>/etc/rc.conf</filename>. In our example, on
- the <hostid>Local2</hostid> machine, we added the following
- line in <filename>/etc/rc.conf</filename>:</para>
+ <filename>/etc/rc.conf</filename>. In this example, on
+ <hostid>Local2</hostid>, add the following line to
+ <filename>/etc/rc.conf</filename>:</para>
<programlisting>defaultrouter="10.20.30.1"</programlisting>
- <para>It is also possible to do it directly from the command
- line with the &man.route.8; command:</para>
+ <para>It is also possible to add the route directly using
+ &man.route.8;:</para>
<screen>&prompt.root; <userinput>route add default 10.20.30.1</userinput></screen>
<para>For more information on manual manipulation of network
- routing tables, consult the &man.route.8; manual page.</para>
+ routing tables, refer to &man.route.8;.</para>
</sect2>
<sect2 id="network-dual-homed-hosts">
@@ -407,32 +404,27 @@ host2.example.com link#1 UC
<indexterm><primary>dual homed hosts</primary></indexterm>
- <para>There is one other type of configuration that we should
- cover, and that is a host that sits on two different networks.
- Technically, any machine functioning as a gateway (in the
- example above, using a PPP connection) counts as a dual-homed
- host. But the term is really only used to refer to a machine
- that sits on two local-area networks.</para>
-
- <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 latter
- if there is one physical network segment, but two logically
- separate subnets.</para>
+ <para>A a dual-homed system is a host which resides on two
+ different networks.</para>
+
+ <para>The dual-homed machine might have two Ethernet cards, each
+ having an address on a separate subnet. Alternately, the
+ machine can have one Ethernet card and uses &man.ifconfig.8;
+ aliasing. The former is used if two physically separate
+ Ethernet networks are in use and the latter if there is one
+ physical network segment, but two logically separate
+ subnets.</para>
<para>Either way, routing tables are set up so that each subnet
knows that this machine is the defined gateway (inbound route)
to the other subnet. This configuration, with the machine
- acting as a router between the two subnets, is often used when
- we need to implement packet filtering or firewall security in
+ acting as a router between the two subnets, is often used
+ to implement packet filtering or firewall security in
either or both directions.</para>
- <para>If you want this machine to actually forward packets
- between the two interfaces, you need to tell FreeBSD to enable
- this ability. See the next section for more details on how
- to do this.</para>
+ <para>For this machine to forward packets between the two
+ interfaces, &os; must be configured as a router, as
+ demonstrated in the next section.</para>
</sect2>
<sect2 id="network-dedicated-router">
@@ -440,10 +432,10 @@ host2.example.com link#1 UC
<indexterm><primary>router</primary></indexterm>
- <para>A network router is simply a system that forwards packets
- from one interface to another. Internet standards and good
- engineering practice prevent the FreeBSD Project from enabling
- this by default in FreeBSD. You can enable this feature by
+ <para>A network router is a system that forwards packets from
+ one interface to another. Internet standards and good
+ engineering practice prevent the &os; Project from enabling
+ this by default in &os;. This feature can be enabled by
changing the following variable to <literal>YES</literal> in
&man.rc.conf.5;:</para>
@@ -451,23 +443,21 @@ host2.example.com link#1 UC
<para>This option will set the &man.sysctl.8; variable
<varname>net.inet.ip.forwarding</varname> to
- <literal>1</literal>. If you should need to stop routing
- temporarily, you can reset this to <literal>0</literal>
- temporarily.</para>
+ <literal>1</literal>. To stop routing, reset this to
+ <literal>0</literal>.</para>
<indexterm><primary>BGP</primary></indexterm>
<indexterm><primary>RIP</primary></indexterm>
<indexterm><primary>OSPF</primary></indexterm>
- <para>Your new router will need routes to know where to send the
- traffic. If your network is simple enough you can use static
- routes. FreeBSD also comes with the standard BSD routing
- daemon &man.routed.8;, which speaks RIP (both version 1 and
- version 2) and IRDP. Support for BGP v4, OSPF v2, and other
+ <para>The new router will need routes to know where to send the
+ traffic. If the network is simple enough, static routes can
+ be used. &os; comes with the standard BSD routing daemon
+ &man.routed.8;, which speaks <acronym>RIP</acronym> versions
+ 1 and 2, and <acronym>IRDP</acronym>. Support for
+ <acronym>BGP</acronym>v4, <acronym>OSPF</acronym>v2, and other
sophisticated routing protocols is available with the
- <filename role="package">net/zebra</filename> package.
- Commercial products such as <application>&gated;</application>
- are also available for more complex network routing
- solutions.</para>
+ <filename role="package">net/zebra</filename> package or
+ port.</para>
</sect2>
<sect2 id="network-static-routes">
@@ -486,7 +476,7 @@ host2.example.com link#1 UC
<sect3>
<title>Manual Configuration</title>
- <para>Let us assume we have a network as follows:</para>
+ <para>Consider the following network:</para>
<mediaobject>
<imageobject>
@@ -520,21 +510,16 @@ host2.example.com link#1 UC
</textobject>
</mediaobject>
- <para>In this scenario, <hostid>RouterA</hostid> is our &os;
+ <para>In this scenario, <hostid>RouterA</hostid> is a &os;
machine that is acting as a router to the rest of the
- Internet. It has a default route set to
- <hostid role="ipaddr">10.0.0.1</hostid> which allows it to
- connect with the outside world. We will assume that
- <hostid>RouterB</hostid> is already configured properly and
- knows how to get wherever it needs to go. (This is simple
- in this picture. Just add a default route on
- <hostid>RouterB</hostid> using
- <hostid role="ipaddr">192.168.1.1</hostid> as the
- gateway.)</para>
+ Internet. It has a default route set to <hostid
+ role="ipaddr">10.0.0.1</hostid> which allows it to
+ connect with the outside world. <hostid>RouterB</hostid> is
+ already configured properly as it uses <hostid
+ role="ipaddr">192.168.1.1</hostid> as the gateway.</para>
- <para>If we look at the routing table for
- <hostid>RouterA</hostid> we would see something like the
- following:</para>
+ <para>The routing table on <hostid>RouterA</hostid> looks
+ something like this:</para>
<screen>&prompt.user; <userinput>netstat -nr</userinput>
Routing tables
@@ -546,14 +531,12 @@ default 10.0.0.1 UG
10.0.0.0/24 link#1 UC 0 0 xl0
192.168.1.0/24 link#2 UC 0 0 xl1</screen>
- <para>With the current routing table <hostid>RouterA</hostid>
- will not be able to reach our Internal Net 2. It does not
- have a route for
- <hostid role="ipaddr">192.168.2.0/24</hostid>. One way to
- alleviate this is to manually add the route. The following
- command would add the Internal Net 2 network to
- <hostid>RouterA</hostid>'s routing table using
- <hostid role="ipaddr">192.168.1.2</hostid> as the next
+ <para>With the current routing table, <hostid>RouterA</hostid>
+ cannot reach Internal Net 2 as it does not have a route for
+ <hostid role="ipaddr">192.168.2.0/24</hostid>. The
+ following command adds the Internal Net 2 network to
+ <hostid>RouterA</hostid>'s routing table using <hostid
+ role="ipaddr">192.168.1.2</hostid> as the next
hop:</para>
<screen>&prompt.root; <userinput>route add -net 192.168.2.0/24 192.168.1.2</userinput></screen>
@@ -566,39 +549,34 @@ default 10.0.0.1 UG
<sect3>
<title>Persistent Configuration</title>
- <para>The above example is perfect for configuring a static
- route on a running system. However, one problem is that the
- routing information will not persist if you reboot your &os;
- machine. Additional static routes can be
- entered in <filename>/etc/rc.conf</filename>:</para>
+ <para>The above example configures a static route on a
+ running system. However, the routing information will not
+ persist if the &os; system reboots. Persistent static
+ routes can be entered in
+ <filename>/etc/rc.conf</filename>:</para>
<programlisting># Add Internal Net 2 as a static route
static_routes="internalnet2"
route_internalnet2="-net 192.168.2.0/24 192.168.1.2"</programlisting>
<para>The <literal>static_routes</literal> configuration
- variable is a list of strings separated by a space. Each
- string references to a route name. In our above example we
- only have one string in <literal>static_routes</literal>.
- This string is <replaceable>internalnet2</replaceable>. We
- then add a configuration variable called
+ variable is a list of strings separated by a space, where
+ each string references a route name. This example only
+ has one string in <literal>static_routes</literal>,
+ <replaceable>internalnet2</replaceable>. The variable
<literal>route_<replaceable>internalnet2</replaceable></literal>
- where we put all of the configuration parameters we would
- give to the &man.route.8; command. For our example above we
- would have used the command:</para>
+ contains all of the configuration parameters to
+ &man.route.8;. This example is equivalent to the
+ command:</para>
<screen>&prompt.root; <userinput>route add -net 192.168.2.0/24 192.168.1.2</userinput></screen>
- <para>so we need <literal>"-net 192.168.2.0/24
- 192.168.1.2"</literal>.</para>
-
- <para>As said above, we can have more than one string in
- <literal>static_routes</literal>. This allows us to create
- multiple static routes. The following lines shows an
- example of adding static routes for the
- <hostid role="ipaddr">192.168.0.0/24</hostid> and
- <hostid role="ipaddr">192.168.1.0/24</hostid> networks on an
- imaginary router:</para>
+ <para>Using more than one string in
+ <literal>static_routes</literal> creates multiple static
+ routes. The following shows an example of adding static
+ routes for the <hostid role="ipaddr">192.168.0.0/24</hostid>
+ and <hostid role="ipaddr">192.168.1.0/24</hostid>
+ networks:</para>
<programlisting>static_routes="net1 net2"
route_net1="-net 192.168.0.0/24 192.168.0.1"
@@ -609,36 +587,24 @@ route_net2="-net 192.168.1.0/24 192.168.
<sect2 id="network-routing-propagation">
<title>Routing Propagation</title>
- <indexterm><primary>routing propagation</primary></indexterm>
- <para>We have already talked about how we define our routes to
- the outside world, but not about how the outside world finds
- us.</para>
-
- <para>We already know that routing tables can be set up so that
- all traffic for a particular address space (in our examples, a
- class-C subnet) can be sent to a particular host on that
- network, which will forward the packets inbound.</para>
-
- <para>When you get an address space assigned to your site, your
- service provider will set up their routing tables so that all
- traffic for your subnet will be sent down your PPP link to
- your site. But how do sites across the country know to send
- to your ISP?</para>
-
- <para>There is a system (much like the distributed DNS
- information) that keeps track of all assigned address-spaces,
- and defines their point of connection to the Internet
- Backbone. The <quote>Backbone</quote> are the main trunk
- lines that carry Internet traffic across the country, and
- around the world. Each backbone machine has a copy of a
- master set of tables, which direct traffic for a particular
- network to a specific backbone carrier, and from there down
- the chain of service providers until it reaches your
- network.</para>
-
- <para>It is the task of your service provider to advertise to
- the backbone sites that they are the point of connection (and
- thus the path inward) for your site. This is known as route
+ <para>When an address space is assigned to a network, the
+ service provider configures their routing tables so that all
+ traffic for the network will be sent to the link for the
+ site. But how do external sites know to send their packets
+ to the network's <acronym>ISP</acronym>?</para>
+
+ <para>There is a system that keeps track of all assigned
+ address spaces and defines their point of connection to the
+ Internet backbone, or the main trunk lines that carry Internet
+ traffic across the country and around the world. Each
+ backbone machine has a copy of a master set of tables, which
+ direct traffic for a particular network to a specific
+ backbone carrier, and from there down the chain of service
+ providers until it reaches your network.</para>
+
+ <para>It is the task of the service provider to advertise to
+ the backbone sites that they are the point of connection, and
+ thus the path inward, for a site. This is known as route
propagation.</para>
</sect2>
@@ -646,24 +612,22 @@ route_net2="-net 192.168.1.0/24 192.168.
<title>Troubleshooting</title>
<indexterm>
- <primary><command>traceroute</command></primary>
+ <primary>&man.traceroute.8;</primary>
</indexterm>
- <para>Sometimes, there is a problem with routing propagation,
- and some sites are unable to connect to you. Perhaps the most
+ <para>Sometimes, there is a problem with routing propagation
+ and some sites are unable to connect. Perhaps the most
useful command for trying to figure out where routing is
- breaking down is the &man.traceroute.8; command. It is
- equally useful if you cannot seem to make a connection to a
- remote machine (i.e., &man.ping.8; fails).</para>
-
- <para>The &man.traceroute.8; command is run with the name of the
- remote host you are trying to connect to. It will show the
- gateway hosts along the path of the attempt, eventually either
+ breaking down is &man.traceroute.8;. It is useful when
+ &man.ping.8; fails.</para>
+
+ <para>When using &man.traceroute.8;, include the name of the
+ remote host to connect to. The output will show the gateway
+ hosts along the path of the attempt, eventually either
reaching the target host, or terminating because of a lack of
connection.</para>
- <para>For more information, see the manual page for
- &man.traceroute.8;.</para>
+ <para>For more information, refer to &man.traceroute.8;.</para>
</sect2>
<sect2 id="network-routing-multicast">
@@ -676,19 +640,18 @@ route_net2="-net 192.168.1.0/24 192.168.
<primary>kernel options</primary>
<secondary>MROUTING</secondary>
</indexterm>
- <para>FreeBSD supports both multicast applications and multicast
- routing natively. Multicast applications do not require any
- special configuration of FreeBSD; applications will generally
- run out of the box. Multicast routing
- requires that support be compiled into the kernel:</para>
+ <para>&os; natively supports both multicast applications and
+ multicast routing. Multicast applications do not require any
+ special configuration of &os;; as applications will generally
+ run out of the box. Multicast routing requires that support
+ be compiled into a custom kernel:</para>
<programlisting>options MROUTING</programlisting>
- <para>In addition, the multicast routing daemon, &man.mrouted.8;
- must be configured to set up tunnels and
- <acronym>DVMRP</acronym> via
+ <para>The multicast routing daemon, &man.mrouted.8;, must be
+ configured to set up tunnels and <acronym>DVMRP</acronym> via
<filename>/etc/mrouted.conf</filename>. More details on
- multicast configuration may be found in the manual page for
+ multicast configuration may be found in
&man.mrouted.8;.</para>
<note>
@@ -697,8 +660,8 @@ route_net2="-net 192.168.1.0/24 192.168.
which has largely been replaced by &man.pim.4; in many
multicast installations. &man.mrouted.8; and the related
&man.map-mbone.8; and &man.mrinfo.8; utilities are available
- in the &os; Ports Collection as
- <filename role="package">net/mrouted</filename>.</para>
+ in the &os; Ports Collection as <filename
+ role="package">net/mrouted</filename>.</para>
</note>
</sect2>
</sect1>
@@ -735,83 +698,92 @@ route_net2="-net 192.168.1.0/24 192.168.
<para>Most wireless networks are based on the &ieee; 802.11
standards. A basic wireless network consists of multiple
stations communicating with radios that broadcast in either
- the 2.4GHz or 5GHz band (though this varies according to the
+ the 2.4GHz or 5GHz band, though this varies according to the
locale and is also changing to enable communication in the
- 2.3GHz and 4.9GHz ranges).</para>
+ 2.3GHz and 4.9GHz ranges.</para>
- <para>802.11 networks are organized in two ways: in
- <emphasis>infrastructure mode</emphasis> one station acts as a
- master with all the other stations associating to it; the
- network is known as a BSS and the master station is termed an
- access point (AP). In a BSS all communication passes through
- the AP; even when one station wants to communicate with
- another wireless station messages must go through the AP. In
- the second form of network there is no master and stations
- communicate directly. This form of network is termed an IBSS
- and is commonly known as an
- <emphasis>ad-hoc network</emphasis>.</para>
+ <para>802.11 networks are organized in two ways. In
+ <emphasis>infrastructure mode</emphasis>, one station acts as
+ a
+ master with all the other stations associating to it, the
+ network is known as a <acronym>BSS</acronym>, and the master
+ station is termed an access point (<acronym>AP</acronym>).
+ In a <acronym>BSS</acronym>, all communication passes through
+ the <acronym>AP</acronym>; even when one station wants to
+ communicate with another wireless station, messages must go
+ through the <acronym>AP</acronym>. In the second form of
+ network, there is no master and stations communicate directly.
+ This form of network is termed an <acronym>IBSS</acronym>
+ and is commonly known as an <emphasis>ad-hoc
+ network</emphasis>.</para>
<para>802.11 networks were first deployed in the 2.4GHz band
using protocols defined by the &ieee; 802.11 and 802.11b
standard. These specifications include the operating
- frequencies, MAC layer characteristics including framing and
- transmission rates (communication can be done at various
- rates). Later the 802.11a standard defined operation in the
- 5GHz band, including different signalling mechanisms and
- higher transmission rates. Still later the 802.11g standard
- was defined to enable use of 802.11a signalling and
- transmission mechanisms in the 2.4GHz band in such a way as to
- be backwards compatible with 802.11b networks.</para>
+ frequencies and the <acronym>MAC</acronym> layer
+ characteristics, including framing and transmission rates,
+ as communication can occur at various rates. Later, the
+ 802.11a standard defined operation in the 5GHz band, including
+ different signaling mechanisms and higher transmission rates.
+ Still later, the 802.11g standard defined the use of 802.11a
+ signaling and transmission mechanisms in the 2.4GHz band in
+ such a way as to be backwards compatible with 802.11b
+ networks.</para>
- <para>Separate from the underlying transmission techniques
+ <para>Separate from the underlying transmission techniques,
802.11 networks have a variety of security mechanisms. The
original 802.11 specifications defined a simple security
- protocol called WEP. This protocol uses a fixed pre-shared key
- and the RC4 cryptographic cipher to encode data transmitted on
- a network. Stations must all agree on the fixed key in order
- to communicate. This scheme was shown to be easily broken and
- is now rarely used except to discourage transient users from
- joining networks. Current security practice is given by the
- &ieee; 802.11i specification that defines new cryptographic
- ciphers and an additional protocol to authenticate stations to
- an access point and exchange keys for doing data
- communication. Further, cryptographic keys are periodically
- refreshed and there are mechanisms for detecting intrusion
- attempts (and for countering intrusion attempts). Another
+ protocol called <acronym>WEP</acronym>. This protocol uses a
+ fixed pre-shared key and the RC4 cryptographic cipher to
+ encode data transmitted on a network. Stations must all
+ agree on the fixed key in order to communicate. This scheme
+ was shown to be easily broken and is now rarely used except
+ to discourage transient users from joining networks. Current
+ security practice is given by the &ieee; 802.11i specification
+ that defines new cryptographic ciphers and an additional
+ protocol to authenticate stations to an access point and
+ exchange keys for data communication. Cryptographic keys
+ are periodically refreshed and there are mechanisms for
+ detecting and countering intrusion attempts. Another
security protocol specification commonly used in wireless
- networks is termed WPA. This was a precursor to 802.11i
- defined by an industry group as an interim measure while
- waiting for 802.11i to be ratified. WPA specifies a subset of
- the requirements found in 802.11i and is designed for
- implementation on legacy hardware. Specifically WPA requires
- only the TKIP cipher that is derived from the original WEP
- cipher. 802.11i permits use of TKIP but also requires support
- for a stronger cipher, AES-CCM, for encrypting data. (The AES
- cipher was not required in WPA because it was deemed too
+ networks is termed <acronym>WPA</acronym>, which was a
+ precursor to 802.11i. <acronym>WPA</acronym> specifies a
+ subset of the requirements found in 802.11i and is designed
+ for implementation on legacy hardware. Specifically,
+ <acronym>WPA</acronym> requires only the
+ <acronym>TKIP</acronym> cipher that is derived from the
+ original <acronym>WEP</acronym> cipher. 802.11i permits use
+ of <acronym>TKIP</acronym> but also requires support for a
+ stronger cipher, AES-CCM, for encrypting data. The
+ <acronym>AES</acronym> cipher was not required in
+ <acronym>WPA</acronym> because it was deemed too
computationally costly to be implemented on legacy
- hardware.)</para>
+ hardware.</para>
- <para>Other than the above protocol standards the other
- important standard to be aware of is 802.11e. This defines
- protocols for deploying multi-media applications such as
- streaming video and voice over IP (VoIP) in an 802.11 network.
- Like 802.11i, 802.11e also has a precursor specification
- termed WME (later renamed WMM) that has been defined by an
+ <para>The other standard to be aware of is 802.11e. It defines
+ protocols for deploying multimedia applications, such as
+ streaming video and voice over IP (<acronym>VoIP</acronym>),
+ in an 802.11 network. Like 802.11i, 802.11e also has a
+ precursor specification termed <acronym>WME</acronym> (later
+ renamed <acronym>WMM</acronym>) that has been defined by an
industry group as a subset of 802.11e that can be deployed now
- to enable multi-media applications while waiting for the final
+ to enable multimedia applications while waiting for the final
ratification of 802.11e. The most important thing to know
- about 802.11e and WME/WMM is that it enables prioritized
- traffic use of a wireless network through Quality of Service
- (QoS) protocols and enhanced media access protocols. Proper
- implementation of these protocols enable high speed bursting
- of data and prioritized traffic flow.</para>
+ about 802.11e and
+ <acronym>WME</acronym>/<acronym>WMM</acronym> is that it
+ enables prioritized traffic over a wireless network through
+ Quality of Service (<acronym>QoS</acronym>) protocols and
+ enhanced media access protocols. Proper implementation of
+ these protocols enables high speed bursting of data and
+ prioritized traffic flow.</para>
- <para>&os; supports networks that operate
- using 802.11a, 802.11b, and 802.11g. The WPA and 802.11i
+ <para>&os; supports networks that operate using 802.11a,
+ 802.11b, and 802.11g. The <acronym>WPA</acronym> and 802.11i
security protocols are likewise supported (in conjunction with
- any of 11a, 11b, and 11g) and QoS and traffic prioritization
- required by the WME/WMM protocols are supported for a limited
- set of wireless devices.</para>
+ any of 11a, 11b, and 11g) and <acronym>QoS</acronym> and
+ traffic prioritization required by the
+ <acronym>WME</acronym>/<acronym>WMM</acronym> protocols are
+ supported for a limited set of wireless devices.</para>
</sect2>
<sect2 id="network-wireless-basic">
@@ -820,63 +792,59 @@ route_net2="-net 192.168.1.0/24 192.168.
<sect3>
<title>Kernel Configuration</title>
- <para>To use wireless networking, you need a wireless
- networking card and to configure the kernel with the
- appropriate wireless networking support. The latter is
- separated into multiple modules so that you only need to
- configure the software you are actually going to use.</para>
-
- <para>The first thing you need is a wireless device. The most
- commonly used devices are those that use parts made by
- Atheros. These devices are supported by the &man.ath.4;
- driver and require the following line to be added to
+ <para>To use wireless networking, a wireless networking card
+ is needed and the kernel needs to be configured with the
+ appropriate wireless networking support. The kernel is
+ separated into multiple modules so that only the required
+ support needs to be configured.</para>
+
+ <para>The most
+ commonly used wireless devices are those that use parts made
+ by Atheros. These devices are supported by &man.ath.4;
+ and require the following line to be added to
<filename>/boot/loader.conf</filename>:</para>
<programlisting>if_ath_load="YES"</programlisting>
<para>The Atheros driver is split up into three separate
- pieces: the proper driver (&man.ath.4;), the hardware
- support layer that handles chip-specific functions
- (&man.ath.hal.4;), and an algorithm for selecting which of
- several possible rates for transmitting frames
- (ath_rate_sample here). When this support is loaded as
- kernel modules, these dependencies are automatically handled
- for you. If, instead of an Atheros device, you had another
- device you would select the module for that device;
- e.g.:</para>
+ pieces: the driver (&man.ath.4;), the hardware support
+ layer that handles chip-specific functions
+ (&man.ath.hal.4;), and an algorithm for selecting the
+ rate for transmitting frames. When this support is loaded
+ as kernel modules, any dependencies are automatically
+ handled. To load support for a different type of wireless
+ device, specify the module for that device. This example
+ is for devices based on the Intersil Prism parts
+ (&man.wi.4;) driver:</para>
<programlisting>if_wi_load="YES"</programlisting>
- <para>for devices based on the Intersil Prism parts
- (&man.wi.4; driver).</para>
-
<note>
- <para>In the rest of this document, we will use an
- &man.ath.4; device, the device name in the examples must
- be changed according to your configuration. A list of
+ <para>The examples in this section use an &man.ath.4;
+ device and the device name in the examples must be
+ changed according to the configuration. A list of
available wireless drivers and supported adapters can be
- found in the &os; Hardware Notes. Copies of these notes
- for various releases and architectures are available on
+ found in the &os; Hardware Notes, available on
the <ulink
url="http://www.FreeBSD.org/releases/index.html">Release
- Information</ulink> page of the &os; Web site. If a
- native &os; driver for your wireless device does not
- exist, it may be possible to directly use the &windows;
- driver with the help of the
- <link linkend="config-network-ndis">NDIS</link> driver
+ Information</ulink> page of the &os; website. If a
+ native &os; driver for the wireless device does not
+ exist, it may be possible to use the &windows; driver
+ with the help of the <link
+ linkend="config-network-ndis">NDIS</link> driver
wrapper.</para>
</note>
- <para>With that, you will need the modules that implement
- cryptographic support for the security protocols you intend
- to use. These are intended to be dynamically loaded on
- demand by the &man.wlan.4; module but for now they must be
- manually configured. The following modules are available:
- &man.wlan.wep.4;, &man.wlan.ccmp.4; and &man.wlan.tkip.4;.
- Both &man.wlan.ccmp.4; and &man.wlan.tkip.4; drivers are
- only needed if you intend to use the WPA and/or 802.11i
- security protocols. If your network does not use
- encryption, you will not need &man.wlan.wep.4; support. To
+ <para>In addition, the modules that implement cryptographic
+ support for the security protocols to use must be loaded.
+ These are intended to be dynamically loaded on demand by
+ the &man.wlan.4; module, but for now they must be manually
+ configured. The following modules are available:
+ &man.wlan.wep.4;, &man.wlan.ccmp.4;, and &man.wlan.tkip.4;.
+ The &man.wlan.ccmp.4; and &man.wlan.tkip.4; drivers are
+ only needed when using the <acronym>WPA</acronym> or
+ 802.11i security protocols. If the network does not use
+ encryption, &man.wlan.wep.4; support is not needed. To
load these modules at boot time, add the following lines to
<filename>/boot/loader.conf</filename>:</para>
@@ -884,17 +852,16 @@ route_net2="-net 192.168.1.0/24 192.168.
wlan_ccmp_load="YES"
wlan_tkip_load="YES"</programlisting>
- <para>With this information in the system bootstrap
- configuration file (i.e.,
- <filename>/boot/loader.conf</filename>), you have to reboot
- your &os; box. If you do not want to reboot your machine
- for the moment, you can load the modules by hand using
+ <para>Once this information has been added to
+ <filename>/boot/loader.conf</filename>, reboot the &os;
+ box. Alternately, load the modules by hand using
&man.kldload.8;.</para>
<note>
- <para>If you do not want to use modules, it is possible to
- compile these drivers into the kernel by adding the
- following lines to your kernel configuration file:</para>
+ <para>For users who do not want to use modules, it is
+ possible to compile these drivers into the kernel by
+ adding the following lines to a custom kernel
+ configuration file:</para>
<programlisting>device wlan # 802.11 support
device wlan_wep # 802.11 WEP support
@@ -907,13 +874,12 @@ options AH_SUPPORT_AR5416 # enable AR541
device ath_rate_sample # SampleRate tx rate control for ath</programlisting>
<para>With this information in the kernel configuration
- file, recompile the kernel and reboot your &os;
+ file, recompile the kernel and reboot the &os;
machine.</para>
</note>
- <para>When the system is up, we could find some information
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-head
mailing list