Date: Fri, 14 Feb 2014 03:48:49 +0000 (UTC) From: Warren Block <wblock@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43920 - head/en_US.ISO8859-1/books/handbook/advanced-networking Message-ID: <201402140348.s1E3mntF017833@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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@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::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@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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402140348.s1E3mntF017833>