svn commit: r43920 - head/en_US.ISO8859-1/books/handbook/advanced-networking
Warren Block
wblock at FreeBSD.org
Fri Feb 14 03:48:49 UTC 2014
Author: wblock
Date: Fri Feb 14 03:48:49 2014
New Revision: 43920
URL: http://svnweb.freebsd.org/changeset/doc/43920
Log:
Whitespace-only fixes, translators please ignore. Slightly modified
patch supplied by Allan Jude.
Modified:
head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Fri Feb 14 02:33:56 2014 (r43919)
+++ head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Fri Feb 14 03:48:49 2014 (r43920)
@@ -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
<title>Bluetooth</title>
<authorgroup>
- <author><personname><firstname>Pav</firstname><surname>Lucistnik</surname></personname><contrib>Written
- by </contrib><affiliation>
- <address><email>pav at FreeBSD.org</email></address>
- </affiliation></author>
+ <author>
+ <personname>
+ <firstname>Pav</firstname>
+ <surname>Lucistnik</surname>
+ </personname>
+ <contrib>Written by </contrib>
+ <affiliation>
+ <address>
+ <email>pav at 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::begemotBridgeDefault
<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>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>
+ <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>
+
+ <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 ðerchannel; (<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 ðerchannel; (<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>
-
- <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><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>
- <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</prog
<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 at 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</prog
<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</pro
<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</pro
<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</pro
<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</pro
<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</pro
<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</pro
<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</pro
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</pro
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>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>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>
</sect1>
<!--
<sect1 xml:id="network-atm">
@@ -5684,10 +5723,21 @@ route_hostD="192.168.173.4 hatm0 0 102 l
(<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 l
<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 l
<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 l
<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 l
<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 testpas
<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
<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 <sy
</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
<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>
More information about the svn-doc-all
mailing list