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

Whitespace-only fixes, translators please ignore. Slightly modified

Browse source 
patch supplied by Allan Jude.
This commit is contained in:
Warren Block 2014-02-14 03:48:49 +00:00
parent db36e2322f
commit c3b20669c6
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=43920
1 changed files with 249 additions and 194 deletions
Download patch file Download diff file Expand all files Collapse all files

443
en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
View file

@ -4,7 +4,10 @@
$FreeBSD$
-->
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="advanced-networking">
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="advanced-networking">
<title>Advanced Networking</title>
<sect1 xml:id="advanced-networking-synopsis">
@ -89,9 +92,14 @@
<info>
<title>Gateways and Routes</title>
<authorgroup>
<author><personname><firstname>Coranth</firstname><surname>Gryphon</surname></personname><contrib>Contributed
by </contrib></author>
<authorgroup>
<author>
<personname>
<firstname>Coranth</firstname>
<surname>Gryphon</surname>
</personname>
<contrib>Contributed by </contrib>
</author>
</authorgroup>
</info>
@ -2264,10 +2272,18 @@ freebsdap 00:11:95:c3:0d:ac 1 54M 22:1 100 EPS</screen>
<title>Bluetooth</title>
<authorgroup>
<author><personname><firstname>Pav</firstname><surname>Lucistnik</surname></personname><contrib>Written
by </contrib><affiliation>
<address><email>pav@FreeBSD.org</email></address>
</affiliation></author>
<author>
<personname>
<firstname>Pav</firstname>
<surname>Lucistnik</surname>
</personname>
<contrib>Written by </contrib>
<affiliation>
<address>
<email>pav@FreeBSD.org</email>
</address>
</affiliation>
</author>
</authorgroup>
</info>
@ -2404,8 +2420,8 @@ Name: Pav's T39</screen>
<para>If an inquiry is performed on a remote Bluetooth device,
it will find the computer as
<quote>your.host.name (ubt0)</quote>. The name assigned to the
local device can be changed at any time.</para>
<quote>your.host.name (ubt0)</quote>. The name assigned to
the local device can be changed at any time.</para>
<para>The Bluetooth system provides a point-to-point connection
between two Bluetooth units, or a point-to-multipoint
@ -3397,86 +3413,86 @@ BEGEMOT-BRIDGE-MIB::begemotBridgeDefaultBridgeIf.0 s bridge2</screen>
<indexterm><primary>loadbalance</primary></indexterm>
<indexterm><primary>roundrobin</primary></indexterm>
<para>&os; provides the &man.lagg.4; interface which can be used
to aggregate multiple network interfaces into one virtual
interface in order to provide failover and link aggregation.
Failover allows traffic to continue to flow even if an
interface becomes available. Link aggregation works best on
switches which support <acronym>LACP</acronym>, as this
protocol distributes traffic bi-directionally while responding
to the failure of individual links.</para>
<para>&os; provides the &man.lagg.4; interface which can be used
to aggregate multiple network interfaces into one virtual
interface in order to provide failover and link aggregation.
Failover allows traffic to continue to flow even if an
interface becomes available. Link aggregation works best on
switches which support <acronym>LACP</acronym>, as this
protocol distributes traffic bi-directionally while responding
to the failure of individual links.</para>
<para>The aggregation protocols supported by the lagg interface
determine which ports are used for outgoing traffic and
whether or not a specific port accepts incoming traffic. The
following protocols are supported by &man.lagg.4;:</para>
<para>The aggregation protocols supported by the lagg interface
determine which ports are used for outgoing traffic and
whether or not a specific port accepts incoming traffic. The
following protocols are supported by &man.lagg.4;:</para>
<variablelist>
<varlistentry>
<term>failover</term>
<listitem>
<para>This mode sends and receives traffic only through
the master port. If the master port becomes
unavailable, the next active port is used. The first
interface added to the virtual interface is the master
port and all subsequently added interfaces are used as
failover devices. If failover to a non-master port
occurs, the original port becomes master once it
becomes available again.</para>
</listitem>
</varlistentry>
<variablelist>
<varlistentry>
<term>failover</term>
<listitem>
<para>This mode sends and receives traffic only through
the master port. If the master port becomes
unavailable, the next active port is used. The first
interface added to the virtual interface is the master
port and all subsequently added interfaces are used as
failover devices. If failover to a non-master port
occurs, the original port becomes master once it
becomes available again.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>fec / loadbalance</term>
<listitem>
<para>&cisco; Fast &etherchannel; (<acronym>FEC</acronym>)
is found on older &cisco; switches. It provides a
static setup and does not negotiate aggregation with the
peer or exchange frames to monitor the link. If the
switch supports <acronym>LACP</acronym>, that should be
used instead.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>fec / loadbalance</term>
<listitem>
<para>&cisco; Fast &etherchannel; (<acronym>FEC</acronym>)
is found on older &cisco; switches. It provides a
static setup and does not negotiate aggregation with the
peer or exchange frames to monitor the link. If the
switch supports <acronym>LACP</acronym>, that should be
used instead.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><acronym>lacp</acronym></term>
<listitem>
<para>The &ieee; 802.3ad Link Aggregation Control Protocol
(<acronym>LACP</acronym>) negotiates a set of
aggregable links with the peer into one or more Link
Aggregated Groups (<acronym>LAG</acronym>s). Each
<acronym>LAG</acronym> is composed of ports of the same
speed, set to full-duplex operation, and traffic is
balanced across the ports in the
<acronym>LAG</acronym> with the greatest total speed.
Typically, there is only one <acronym>LAG</acronym>
which contains all the ports. In the event of changes
in physical connectivity,
<acronym>LACP</acronym> will quickly converge to a new
configuration.</para>
<varlistentry>
<term><acronym>lacp</acronym></term>
<listitem>
<para>The &ieee; 802.3ad Link Aggregation Control Protocol
(<acronym>LACP</acronym>) negotiates a set of
aggregable links with the peer into one or more Link
Aggregated Groups (<acronym>LAG</acronym>s). Each
<acronym>LAG</acronym> is composed of ports of the same
speed, set to full-duplex operation, and traffic is
balanced across the ports in the
<acronym>LAG</acronym> with the greatest total speed.
Typically, there is only one <acronym>LAG</acronym>
which contains all the ports. In the event of changes
in physical connectivity,
<acronym>LACP</acronym> will quickly converge to a new
configuration.</para>
<para><acronym>LACP</acronym> balances outgoing traffic
across the active ports based on hashed protocol header
information and accepts incoming traffic from any active
port. The hash includes the Ethernet source and
destination address and, if available, the
<acronym>VLAN</acronym> tag, and the
<acronym>IPv4</acronym> or <acronym>IPv6</acronym>
source and destination address.</para>
</listitem>
</varlistentry>
<para><acronym>LACP</acronym> balances outgoing traffic
across the active ports based on hashed protocol header
information and accepts incoming traffic from any active
port. The hash includes the Ethernet source and
destination address and, if available, the
<acronym>VLAN</acronym> tag, and the
<acronym>IPv4</acronym> or <acronym>IPv6</acronym>
source and destination address.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>roundrobin</term>
<listitem>
<para>This mode distributes outgoing traffic using a
round-robin scheduler through all active ports and
accepts incoming traffic from any active port. Since
this mode violates Ethernet frame ordering, it should be
used with caution.</para>
</listitem>
</varlistentry>
</variablelist>
<varlistentry>
<term>roundrobin</term>
<listitem>
<para>This mode distributes outgoing traffic using a
round-robin scheduler through all active ports and
accepts incoming traffic from any active port. Since
this mode violates Ethernet frame ordering, it should be
used with caution.</para>
</listitem>
</varlistentry>
</variablelist>
<sect2>
<title>Configuration Examples</title>
@ -4234,12 +4250,19 @@ cd /usr/src/etc; make distribution</programlisting>
<sect1 xml:id="network-pxe-nfs">
<info>
<title>PXE Booting with an <acronym>NFS</acronym> Root File
System</title>
System</title>
<authorgroup>
<author><personname><firstname>Craig</firstname><surname>Rodrigues</surname></personname><affiliation>
<author>
<personname>
<firstname>Craig</firstname>
<surname>Rodrigues</surname>
</personname>
<affiliation>
<address>rodrigc@FreeBSD.org</address>
</affiliation><contrib>Written by </contrib></author>
</affiliation>
<contrib>Written by </contrib>
</author>
</authorgroup>
</info>
@ -4325,7 +4348,7 @@ cd /usr/src/etc; make distribution</programlisting>
<step>
<para>Rebuild the &os; kernel and userland (<xref
linkend="makeworld"/>):</para>
linkend="makeworld"/>):</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make buildworld</userinput>
@ -4980,16 +5003,31 @@ redirect_port tcp 192.168.0.3:80 80</programlisting>
<title><acronym>IPv6</acronym></title>
<authorgroup>
<author><personname><firstname>Aaron</firstname><surname>Kaplan</surname></personname><contrib>Originally
Written by </contrib></author>
<author>
<personname>
<firstname>Aaron</firstname>
<surname>Kaplan</surname>
</personname>
<contrib>Originally Written by </contrib>
</author>
</authorgroup>
<authorgroup>
<author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><contrib>Restructured
and Added by </contrib></author>
<author>
<personname>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
</personname>
<contrib>Restructured and Added by </contrib>
</author>
</authorgroup>
<authorgroup>
<author><personname><firstname>Brad</firstname><surname>Davis</surname></personname><contrib>Extended
by </contrib></author>
<author>
<personname>
<firstname>Brad</firstname>
<surname>Davis</surname>
</personname>
<contrib>Extended by </contrib>
</author>
</authorgroup>
</info>
@ -5011,26 +5049,26 @@ redirect_port tcp 192.168.0.3:80 80</programlisting>
<itemizedlist>
<listitem>
<para>Running out of addresses. For years the use of
RFC1918 private address space (<systemitem
class="ipaddress">10.0.0.0/8</systemitem>, <systemitem
class="ipaddress">172.16.0.0/12</systemitem>, and
<systemitem
class="ipaddress">192.168.0.0/16</systemitem>) and NAT
has slowed down the exhaustion. Even though, there are
very few remaining IPv4 addresses. The Internet
Assigned Numbers Authority (<acronym>IANA</acronym>) has
issued the last of the available major blocks to the
Regional Registries. Once each Regional Registry runs
out, there will be no more available and switching to
<acronym>IPv6</acronym> will be critical.</para>
<para>Running out of addresses. For years the use of
RFC1918 private address space (<systemitem
class="ipaddress">10.0.0.0/8</systemitem>, <systemitem
class="ipaddress">172.16.0.0/12</systemitem>, and
<systemitem
class="ipaddress">192.168.0.0/16</systemitem>) and NAT
has slowed down the exhaustion. Even though, there are
very few remaining IPv4 addresses. The Internet
Assigned Numbers Authority (<acronym>IANA</acronym>) has
issued the last of the available major blocks to the
Regional Registries. Once each Regional Registry runs
out, there will be no more available and switching to
<acronym>IPv6</acronym> will be critical.</para>
</listitem>
<listitem>
<para>Every block of IPv4 addresses allocated required
routing information to be exchanged between many routers
on the Internet, and these routing tables were getting
too large to allow efficient routing.</para>
<para>Every block of IPv4 addresses allocated required
routing information to be exchanged between many routers
on the Internet, and these routing tables were getting
too large to allow efficient routing.</para>
</listitem>
</itemizedlist>
@ -5059,7 +5097,7 @@ redirect_port tcp 192.168.0.3:80 80</programlisting>
<itemizedlist>
<listitem>
<para>Address autoconfiguration (<link
xlink:href="http://www.ietf.org/rfc/rfc2462.txt">RFC2462</link>).</para>
xlink:href="http://www.ietf.org/rfc/rfc2462.txt">RFC2462</link>).</para>
</listitem>
<listitem>
@ -5096,7 +5134,7 @@ redirect_port tcp 192.168.0.3:80 80</programlisting>
<itemizedlist>
<listitem>
<para><link
xlink:href="http://www.kame.net">KAME.net</link></para>
xlink:href="http://www.kame.net">KAME.net</link></para>
</listitem>
</itemizedlist>
@ -5146,7 +5184,7 @@ redirect_port tcp 192.168.0.3:80 80</programlisting>
<entry>128 bits</entry>
<entry>unspecified</entry>
<entry>Equivalent to <systemitem
class="ipaddress">0.0.0.0</systemitem> in
class="ipaddress">0.0.0.0</systemitem> in
<acronym>IPv4</acronym>.</entry>
</row>
@ -5155,7 +5193,7 @@ redirect_port tcp 192.168.0.3:80 80</programlisting>
<entry>128 bits</entry>
<entry>loopback address</entry>
<entry>Equivalent to <systemitem
class="ipaddress">127.0.0.1</systemitem> in
class="ipaddress">127.0.0.1</systemitem> in
<acronym>IPv4</acronym>.</entry>
</row>
@ -5324,10 +5362,11 @@ redirect_port tcp 192.168.0.3:80 80</programlisting>
add:</para>
<programlisting>ipv6_enable="YES"</programlisting>
</sect3>
<sect3>
<title><acronym>IPv6</acronym> Client Static
Configuration</title>
</sect3>
<sect3>
<title><acronym>IPv6</acronym> Client Static
Configuration</title>
<para>To statically assign the <acronym>IPv6</acronym>
address,
@ -5471,22 +5510,22 @@ redirect_port tcp 192.168.0.3:80 80</programlisting>
section 4.2 may be useful to some adminstrators.</para>
</sect2>
<sect2>
<title>Application Use of <acronym>IPv6</acronym></title>
<sect2>
<title>Application Use of <acronym>IPv6</acronym></title>
<para>Currently <acronym>IPv6</acronym> support for many
applications and services is very good, though for some
software it still needs work. For authoritative
information about the support of
<acronym>IPv6</acronym>, please consult the Official
Documentation for the software in question.</para>
<para>Currently <acronym>IPv6</acronym> support for many
applications and services is very good, though for some
software it still needs work. For authoritative information
about the support of <acronym>IPv6</acronym>, please consult
the Official Documentation for the software in
question.</para>
<para>Web, <acronym>DNS</acronym> and Mail applications
and servers have the best support for
<acronym>IPv6</acronym> because they are the most common
use case. Other applications may have varying degrees
of <acronym>IPv6</acronym> support.</para>
</sect2>
<para>Web, <acronym>DNS</acronym> and Mail applications and
servers have the best support for <acronym>IPv6</acronym>
because they are the most common use case. Other applications
may have varying degrees of <acronym>IPv6</acronym>
support.</para>
</sect2>
</sect1>
<!--
<sect1 xml:id="network-atm">
@ -5684,10 +5723,21 @@ route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr"</programlisting>
(<acronym>CARP</acronym>)</title>
<authorgroup>
<author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><contrib>Contributed
by </contrib></author>
<author><personname><firstname>Allan</firstname><surname>Jude</surname></personname><contrib>Updated
by </contrib></author>
<author>
<personname>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
</personname>
<contrib>Contributed by </contrib>
</author>
<author>
<personname>
<firstname>Allan</firstname>
<surname>Jude</surname>
</personname>
<contrib>Updated by </contrib>
</author>
</authorgroup>
</info>
@ -5700,9 +5750,11 @@ route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr"</programlisting>
<para>The Common Address Redundancy Protocol
(<acronym>CARP</acronym>) allows multiple hosts to share the
same <acronym>IP</acronym> address and provide <emphasis>high availability</emphasis>. One or more hosts can fail, and the others will
take over for the failed system transparently. In addition to the shared <acronym>IP</acronym> address, hosts also have a
unique <acronym>IP</acronym> address for management and
same <acronym>IP</acronym> address and provide <emphasis>high
availability</emphasis>. One or more hosts can fail, and the
others will take over for the failed system transparently. In
addition to the shared <acronym>IP</acronym> address, hosts also
have a unique <acronym>IP</acronym> address for management and
configuration, as in the example provided here.</para>
<sect2 xml:id="carp-ha">
@ -5711,26 +5763,24 @@ route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr"</programlisting>
<para><acronym>CARP</acronym> is often used to provide
high availability for one or more services. This example
configures failover support with three hosts, all with
unique <acronym>IP</acronym> addresses, but providing the same
web content. These machines are load balanced with a Round
Robin <acronym>DNS</acronym> configuration. The master and
backup machines are configured identically
except for their hostnames and management
<acronym>IP</acronym> addresses. These servers must have the same configuration and run
the same services.
When the failover occurs, requests to the
service on the shared <acronym>IP</acronym> address can only
be answered correctly if the backup server has access to the
same content. The backup machine has two additional
<acronym>CARP</acronym> interfaces, one for each of the
master content server's <acronym>IP</acronym> addresses. When
a failure occurs, the backup server will pick up the failed
master machine's <acronym>IP</acronym> address. Users will
not see a service failure at all.</para>
configures failover support with three hosts, all with unique
<acronym>IP</acronym> addresses, but providing the same web
content. These machines are load balanced with a Round Robin
<acronym>DNS</acronym> configuration. The master and backup
machines are configured identically except for their hostnames
and management <acronym>IP</acronym> addresses. These servers
must have the same configuration and run the same services.
When the failover occurs, requests to the service on the
shared <acronym>IP</acronym> address can only be answered
correctly if the backup server has access to the same content.
The backup machine has two additional <acronym>CARP</acronym>
interfaces, one for each of the master content server's
<acronym>IP</acronym> addresses. When a failure occurs, the
backup server will pick up the failed master machine's
<acronym>IP</acronym> address. Users will not see a service
failure at all.</para>
<para>This
example has two different masters named
<para>This example has two different masters named
<systemitem>hosta.example.org</systemitem> and
<systemitem>hostb.example.org</systemitem>, with
a shared backup named
@ -5738,10 +5788,11 @@ route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr"</programlisting>
<para>Each virtual <acronym>IP</acronym> address has a unique
identification number known as a Virtual Host Identification
(<acronym>VHID</acronym>). All of the machines that share an <acronym>IP</acronym> address have the same <acronym>VHID</acronym>.
The <acronym>VHID</acronym> for each virtual
<acronym>IP</acronym> address must be unique across the
broadcast domain of the network interface.</para>
(<acronym>VHID</acronym>). All of the machines that share an
<acronym>IP</acronym> address have the same
<acronym>VHID</acronym>. The <acronym>VHID</acronym> for each
virtual <acronym>IP</acronym> address must be unique across
the broadcast domain of the network interface.</para>
</sect2>
<sect2 xml:id="carp-10x">
@ -5754,16 +5805,17 @@ route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr"</programlisting>
<programlisting>carp_load="YES"</programlisting>
<para>The <acronym>CARP</acronym> module can also be built into the
&os; kernel as described in <xref linkend="kernelconfig"/>:</para>
<para>The <acronym>CARP</acronym> module can also be built into
the &os; kernel as described in
<xref linkend="kernelconfig"/>:</para>
<programlisting>device carp</programlisting>
<para>The hostname, management
<acronym>IP</acronym> address,
<acronym>CARP</acronym> configuration, and the <acronym>IP</acronym> address
to be shared are all set by adding entries to
<filename>/etc/rc.conf</filename>. This example is for
<para>The hostname, management <acronym>IP</acronym> address,
<acronym>CARP</acronym> configuration, and the
<acronym>IP</acronym> address to be shared are all set by
adding entries to <filename>/etc/rc.conf</filename>. This
example is for
<systemitem>hosta.example.org</systemitem>:</para>
<programlisting>hostname="hosta.example.org"
@ -5780,20 +5832,21 @@ ifconfig_em0_alias0="vhid 2 pass testpass alias <systemitem class="ipaddress">19
<para>The passwords specified with &man.ifconfig.8;
<option>pass</option> must be identical.
<acronym>CARP</acronym> will only listen to and accept
advertisements from machines with the correct password.</para>
advertisements from machines with the correct
password.</para>
</note>
<para>The third machine,
<systemitem>hostc.example.org</systemitem>,
is prepared to handle failover from
either of the previous hosts. This machine is configured
with two <acronym>CARP</acronym> <acronym>VHID</acronym>s, one
to handle the virtual <acronym>IP</acronym> address of each
of the master hosts. <option>advskew</option>, the
<acronym>CARP</acronym> advertising skew, is set to
ensure that the backup host advertises later than the
master. <option>advskew</option> controls the order of precedence when there
are multiple backup servers. Set the configuration in
<systemitem>hostc.example.org</systemitem>, is prepared to
handle failover from either of the previous hosts. This
machine is configured with two <acronym>CARP</acronym>
<acronym>VHID</acronym>s, one to handle the virtual
<acronym>IP</acronym> address of each of the master hosts.
<option>advskew</option>, the <acronym>CARP</acronym>
advertising skew, is set to ensure that the backup host
advertises later than the master. <option>advskew</option>
controls the order of precedence when there are multiple
backup servers. Set the configuration in
<filename>/etc/rc.conf</filename>:</para>
<programlisting>hostname="hostc.example.org"
@ -5843,7 +5896,8 @@ ifconfig_em0_alias1="vhid 2 advskew 100 pass testpass alias <systemitem class="i
<programlisting>if_carp_load="YES"</programlisting>
<para><acronym>CARP</acronym> can also be built into the
&os; kernel as described in <xref linkend="kernelconfig"/>:</para>
&os; kernel as described in
<xref linkend="kernelconfig"/>:</para>
<programlisting>device carp</programlisting>
@ -5881,15 +5935,16 @@ ifconfig_carp0="vhid 2 pass testpass <systemitem class="ipaddress">192.168.1.51<
</note>
<para>The third machine,
<systemitem>hostc.example.org</systemitem>, is
prepared to handle failover from either of the previous hosts.
This machine is configured with two
<acronym>CARP</acronym> devices, one to handle each of the virtual <acronym>IP</acronym> address of each of the master hosts.
Setting the <option>advskew</option>
controls the <acronym>CARP</acronym> advertising skew. The
skew ensuring that the backup hosts advertises later than the
master, and controls the order of precedence when there
are multiple backup servers. Set the configuration in
<systemitem>hostc.example.org</systemitem>, is prepared to
handle failover from either of the previous hosts. This
machine is configured with two <acronym>CARP</acronym>
devices, one to handle each of the virtual
<acronym>IP</acronym> address of each of the master hosts.
Setting the <option>advskew</option> controls the
<acronym>CARP</acronym> advertising skew. The skew ensuring
that the backup hosts advertises later than the master, and
controls the order of precedence when there are multiple
backup servers. Set the configuration in
<filename>/etc/rc.conf</filename>:</para>
<programlisting>hostname="hostc.example.org"
@ -5908,9 +5963,9 @@ ifconfig_carp1="vhid 2 advskew 100 pass testpass <systemitem class="ipaddress">1
<note>
<para>Preemption is disabled in the GENERIC &os; kernel.
If Preemption has been enabled with a custom kernel,
<systemitem>hostc.example.org</systemitem> may not
release the <acronym>IP</acronym> address back to the
original content server. The administrator can force the backup
<systemitem>hostc.example.org</systemitem> may not release
the <acronym>IP</acronym> address back to the original
content server. The administrator can force the backup
server to return the <acronym>IP</acronym> address to the
master with the command:</para>