[networking-guide] master: DHCP: Updates to Chapter (5e54f4a)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 5e54f4a32b9efc7e7fd12f1b0719ffed4705df67
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Sat Jul 26 15:02:01 2014 +0200
DHCP: Updates to Chapter
Thanks to ljozsa and jpopelka for their reviews.
>---------------------------------------------------------------
en-US/DHCP_Servers.xml | 134 ++++++++++++++++++++++++++----------------------
1 files changed, 72 insertions(+), 62 deletions(-)
diff --git a/en-US/DHCP_Servers.xml b/en-US/DHCP_Servers.xml
index 1116210..1e2dcc5 100644
--- a/en-US/DHCP_Servers.xml
+++ b/en-US/DHCP_Servers.xml
@@ -22,6 +22,10 @@
</indexterm>
<para><systemitem class="protocol">DHCP</systemitem> is useful for automatic configuration of client network interfaces. When configuring the client system, you can choose <systemitem class="protocol">DHCP</systemitem> instead of specifying an <systemitem class="protocol">IP</systemitem> address, netmask, gateway, or <systemitem class="protocol">DNS</systemitem> servers. The client retrieves this information from the <systemitem class="protocol">DHCP</systemitem> server. <systemitem class="protocol">DHCP</systemitem> is also useful if you want to change the <systemitem class="protocol">IP</systemitem> addresses of a large number of systems. Instead of reconfiguring all the systems, you can just edit one configuration file on the server for the new set of <systemitem class="protocol">IP</systemitem> addresses. If the <systemitem class="protocol">DNS</systemitem> servers for an organization changes, the changes happen on the <systemitem class="protocol">DHCP</systemitem> s
erver, not on the <systemitem class="protocol">DHCP</systemitem> clients. When you restart the network or reboot the clients, the changes go into effect.</para>
<para>If an organization has a functional <systemitem class="protocol">DHCP</systemitem> server correctly connected to a network, laptops and other mobile computer users can move these devices from office to office.</para>
+ <para>
+ Note that administrators of <systemitem class="protocol">DNS</systemitem> and <systemitem class="protocol">DHCP</systemitem> servers, as well as any provisioning applications, should agree on the host name format used in an organization. See <xref linkend="sec-Recommended_Naming_Practices" /> for more information on the format of host names.
+</para>
+
</section>
<section
id="sec-dhcp-configuring-server">
@@ -31,7 +35,7 @@
<secondary>server configuration</secondary>
</indexterm>
- <para>The <package>dhcp</package> package contains an <firstterm>Internet Systems Consortium</firstterm> (<acronym>ISC</acronym>) <systemitem class="protocol">DHCP</systemitem> server. First, install the package as the superuser:</para>
+ <para>The <package>dhcp</package> package contains an <firstterm>Internet Systems Consortium</firstterm> (<acronym>ISC</acronym>) <systemitem class="protocol">DHCP</systemitem> server. Install the package as <systemitem class="username">root</systemitem>:</para>
<screen>~]# <command>yum install dhcp</command>
</screen>
<para>Installing the <package>dhcp</package> package creates a file, <filename>/etc/dhcp/dhcpd.conf</filename>, which is merely an empty configuration file. As <systemitem class="username">root</systemitem>, issue the following command:</para>
@@ -54,7 +58,7 @@
<indexterm>
<primary>dhcpd.conf</primary>
</indexterm>
- <para>The first step in configuring a <systemitem class="protocol">DHCP</systemitem> server is to create the configuration file that stores the network information for the clients. Use this file to declare options and global options for client systems.</para>
+ <para>The first step in configuring a <systemitem class="protocol">DHCP</systemitem> server is to create the configuration file that stores the network information for the clients. Use this file to declare options for client systems.</para>
<para>The configuration file can contain extra tabs or blank lines for easier formatting. Keywords are case-insensitive and lines beginning with a hash sign (<literal>#</literal>) are considered comments.</para>
<para>There are two types of statements in the configuration file:</para>
<itemizedlist>
@@ -69,7 +73,7 @@
<primary>DHCP</primary>
<secondary>options</secondary>
</indexterm>
- <para>The parameters that start with the keyword option are referred to as <firstterm>options</firstterm>. These options control DHCP options; whereas, parameters configure values that are not optional or control how the DHCP server behaves.</para>
+ <para>The parameters that start with the keyword option are referred to as <firstterm>options</firstterm>. These options control <systemitem class="protocol">DHCP</systemitem> options; whereas, parameters configure values that are not optional or control how the <systemitem class="protocol">DHCP</systemitem> server behaves.</para>
<indexterm>
<primary>DHCP</primary>
<secondary>global parameters</secondary>
@@ -84,13 +88,13 @@
<para>Instead of changing a <systemitem class="protocol">DHCP</systemitem> configuration file and restarting the service each time, using the <command>omshell</command> command provides an interactive way to connect to, query, and change the configuration of a <systemitem class="protocol">DHCP</systemitem> server. By using <command>omshell</command>, all changes can be made while the server is running. For more information on <command>omshell</command>, see the <command>omshell</command> man page.</para>
</note>
<para>In <xref
- linkend="subnet"/>, the <filename>routers</filename>, <filename>subnet-mask</filename>, <filename>domain-search</filename>, <filename>domain-name-servers</filename>, and <filename>time-offset</filename> options are used for any <filename>host</filename> statements declared below it.</para>
+ linkend="subnet"/>, the <command>routers</command>, <command>subnet-mask</command>, <command>domain-search</command>, <command>domain-name-servers</command>, and <command>time-offset</command> options are used for any <command>host</command> statements declared below it.</para>
<indexterm>
<primary>DHCP</primary>
<secondary>subnet</secondary>
</indexterm>
- <para>For every <filename>subnet</filename> which will be served, and for every <filename>subnet</filename> to which the <systemitem class="protocol">DHCP</systemitem> server is connected, there must be one <filename>subnet</filename> declaration, which tells the <systemitem class="protocol">DHCP</systemitem> daemon how to recognize that an address is on that <filename>subnet</filename>. A <filename>subnet</filename> declaration is required for each <filename>subnet</filename> even if no addresses will be dynamically allocated to that <filename>subnet</filename>.</para>
- <para>In this example, there are global options for every <systemitem class="protocol">DHCP</systemitem> client in the subnet and a <filename>range</filename> declared. Clients are assigned an <systemitem class="protocol">IP</systemitem> address within the <filename>range</filename>.</para>
+ <para>For every subnet which will be served, and for every subnet to which the <systemitem class="protocol">DHCP</systemitem> server is connected, there must be one <command>subnet</command> declaration, which tells the <systemitem class="protocol">DHCP</systemitem> daemon how to recognize that an address is on that subnet. A <command>subnet</command> declaration is required for each subnet even if no addresses will be dynamically allocated to that subnet.</para>
+ <para>In this example, there are global options for every <systemitem class="protocol">DHCP</systemitem> client in the subnet and a <command>range</command> declared. Clients are assigned an <systemitem class="protocol">IP</systemitem> address within the <command>range</command>.</para>
<example
id="subnet">
<title>Subnet Declaration</title>
@@ -103,8 +107,7 @@
range 192.168.1.10 192.168.1.100;
}</programlisting>
</example>
- <para>To configure a <systemitem class="protocol">DHCP</systemitem> server that leases a dynamic <systemitem class="protocol">IP</systemitem> address to a system within a subnet, modify <xref
- linkend="dynamic-ip"/> with your values. It declares a default lease time, maximum lease time, and network configuration values for the clients. This example assigns <systemitem class="protocol">IP</systemitem> addresses in the <filename>range</filename> <systemitem class="ipaddress">192.168.1.10</systemitem> and <systemitem class="ipaddress">192.168.1.100</systemitem> to client systems.</para>
+ <para>To configure a <systemitem class="protocol">DHCP</systemitem> server that leases a dynamic <systemitem class="protocol">IP</systemitem> address to a system within a subnet, modify the example values from <xref linkend="dynamic-ip"/>. It declares a default lease time, maximum lease time, and network configuration values for the clients. This example assigns <systemitem class="protocol">IP</systemitem> addresses in the <command>range</command> <systemitem class="ipaddress">192.168.1.10</systemitem> and <systemitem class="ipaddress">192.168.1.100</systemitem> to client systems.</para>
<example
id="dynamic-ip">
<title>Range Parameter</title>
@@ -119,9 +122,9 @@ subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.100;
}</programlisting>
</example>
- <para>To assign an <systemitem class="protocol">IP</systemitem> address to a client based on the MAC address of the network interface card, use the <filename>hardware ethernet</filename> parameter within a <filename>host</filename> declaration. As demonstrated in <xref
- linkend="static-ip"/>, the <filename>host apex</filename> declaration specifies that the network interface card with the MAC address <systemitem class="etheraddress">00:A0:78:8E:9E:AA</systemitem> always receives the <systemitem class="protocol">IP</systemitem> address <systemitem class="ipaddress">192.168.1.4</systemitem>.</para>
- <para>Note that you can also use the optional parameter <filename>host-name</filename> to assign a host name to the client.</para>
+ <para>To assign an <systemitem class="protocol">IP</systemitem> address to a client based on the MAC address of the network interface card, use the <command>hardware ethernet</command> parameter within a <command>host</command> declaration. As demonstrated in <xref
+ linkend="static-ip"/>, the <command>host apex</command> declaration specifies that the network interface card with the MAC address <systemitem class="etheraddress">00:A0:78:8E:9E:AA</systemitem> always receives the <systemitem class="protocol">IP</systemitem> address <systemitem class="ipaddress">192.168.1.4</systemitem>.</para>
+ <para>Note that you can also use the optional parameter <option>host-name</option> to assign a host name to the client.</para>
<example
id="static-ip">
<title>Static IP Address Using DHCP</title>
@@ -133,12 +136,10 @@ subnet 192.168.1.0 netmask 255.255.255.0 {
</example>
<indexterm>
<primary>DHCP</primary>
- <secondary>
- <filename>shared-network</filename>
- </secondary>
+ <secondary><command>shared-network</command></secondary>
</indexterm>
- <para>All subnets that share the same physical network should be declared within a <filename>shared-network</filename> declaration as shown in <xref
- linkend="shared-network"/>. Parameters within the <filename>shared-network</filename>, but outside the enclosed <filename>subnet</filename> declarations, are considered to be global parameters. The name of the <filename>shared-network</filename> must be a descriptive title for the network, such as using the title 'test-lab' to describe all the subnets in a test lab environment.</para>
+ <para>All subnets that share the same physical network should be declared within a <command>shared-network</command> declaration as shown in <xref
+ linkend="shared-network"/>. Parameters within the <command>shared-network</command>, but outside the enclosed subnet declarations, are considered to be global parameters. The name assigned to <command>shared-network</command> must be a descriptive title for the network, such as using the title <quote>test-lab</quote> to describe all the subnets in a test lab environment.</para>
<example
id="shared-network">
<title>Shared-network Declaration</title>
@@ -146,13 +147,13 @@ subnet 192.168.1.0 netmask 255.255.255.0 {
option domain-search "test.redhat.com";
option domain-name-servers ns1.redhat.com, ns2.redhat.com;
option routers 192.168.0.254;
- more parameters for EXAMPLE shared-network
+ #more parameters for EXAMPLE shared-network
subnet 192.168.1.0 netmask 255.255.252.0 {
- parameters for subnet
+ #parameters for subnet
range 192.168.1.1 192.168.1.254;
}
subnet 192.168.2.0 netmask 255.255.252.0 {
- parameters for subnet
+ #parameters for subnet
range 192.168.2.1 192.168.2.254;
}
}</programlisting>
@@ -162,7 +163,7 @@ subnet 192.168.1.0 netmask 255.255.255.0 {
<secondary>group</secondary>
</indexterm>
<para>As demonstrated in <xref
- linkend="group"/>, the <filename>group</filename> declaration is used to apply global parameters to a group of declarations. For example, shared networks, subnets, and hosts can be grouped.</para>
+ linkend="group"/>, the <command>group</command> declaration is used to apply global parameters to a group of declarations. For example, shared networks, subnets, and hosts can be grouped.</para>
<example
id="group">
<title>Group Declaration</title>
@@ -186,19 +187,19 @@ subnet 192.168.1.0 netmask 255.255.255.0 {
</example>
<note>
<title>Using the Example Configuration File</title>
- <para>The example configuration file provided can be used as a starting point and custom configuration options can be added to it. To copy it to the proper location, use the following command:</para>
-<screen><command>cp /usr/share/doc/dhcp/dhcpd.conf.example /etc/dhcp/dhcpd.conf</command></screen>
-
+ <para>You can use the provided example configuration file as a starting point and add custom configuration options to it. To copy this file to the proper location, use the following command as <systemitem class="username">root</systemitem>:</para>
+ <screen>~]# <command>cp /usr/share/doc/dhcp-<replaceable><version_number></replaceable>/dhcpd.conf.example /etc/dhcp/dhcpd.conf</command></screen>
+ <para>... where <replaceable><version_number></replaceable> is the <systemitem class="protocol">DHCP</systemitem> version number.</para>
</note>
- <para>For a complete list of option statements and what they do, refer to the <filename>dhcp-options</filename> man page.</para>
+ <para>For a complete list of option statements and what they do, see the <filename>dhcp-options(5)</filename> man page.</para>
</section>
<section
id="lease-database">
<title>Lease Database</title>
- <para>On the DHCP server, the file <filename>/var/lib/dhcpd/dhcpd.leases</filename> stores the DHCP client lease database. Do not change this file. DHCP lease information for each recently assigned IP address is automatically stored in the lease database. The information includes the length of the lease, to whom the IP address has been assigned, the start and end dates for the lease, and the MAC address of the network interface card that was used to retrieve the lease.</para>
+ <para>On the <systemitem class="protocol">DHCP</systemitem> server, the file <filename>/var/lib/dhcpd/dhcpd.leases</filename> stores the <systemitem class="protocol">DHCP</systemitem> client lease database. Do not change this file. <systemitem class="protocol">DHCP</systemitem> lease information for each recently assigned <systemitem class="protocol">IP</systemitem> address is automatically stored in the lease database. The information includes the length of the lease, to whom the <systemitem class="protocol">IP</systemitem> address has been assigned, the start and end dates for the lease, and the MAC address of the network interface card that was used to retrieve the lease.</para>
<para>All times in the lease database are in Coordinated Universal Time (UTC), not local time.</para>
<para>The lease database is recreated from time to time so that it is not too large. First, all known leases are saved in a temporary lease database. The <filename>dhcpd.leases</filename> file is renamed <filename>dhcpd.leases~</filename> and the temporary lease database is written to <filename>dhcpd.leases</filename>.</para>
- <para>The DHCP daemon could be killed or the system could crash after the lease database has been renamed to the backup file but before the new file has been written. If this happens, the <filename>dhcpd.leases</filename> file does not exist, but it is required to start the service. Do not create a new lease file. If you do, all old leases are lost which causes many problems. The correct solution is to rename the <filename>dhcpd.leases~</filename> backup file to <filename>dhcpd.leases</filename> and then start the daemon.</para>
+ <para>The <systemitem class="protocol">DHCP</systemitem> daemon could be killed or the system could crash after the lease database has been renamed to the backup file but before the new file has been written. If this happens, the <filename>dhcpd.leases</filename> file does not exist, but it is required to start the service. Do not create a new lease file. If you do, all old leases are lost which causes many problems. The correct solution is to rename the <filename>dhcpd.leases~</filename> backup file to <filename>dhcpd.leases</filename> and then start the daemon.</para>
</section>
<section>
<title>Starting and Stopping the Server</title>
@@ -212,21 +213,21 @@ subnet 192.168.1.0 netmask 255.255.255.0 {
</indexterm>
<indexterm>
<primary>DHCP</primary>
- <secondary>
- <filename>dhcpd.leases</filename>
- </secondary>
+ <secondary><filename>dhcpd.leases</filename></secondary>
</indexterm>
<indexterm>
<primary>dhcpd.leases</primary>
</indexterm>
<important>
<title>Starting the DHCP Server for the First Time</title>
- <para>When the <systemitem class="protocol">DHCP</systemitem> server is started for the first time, it fails unless the <filename>dhcpd.leases</filename> file exists. Use the command <command>touch /var/lib/dhcpd/dhcpd.leases</command> to create the file if it does not exist.</para>
- <para>If the same server is also running BIND as a <systemitem class="protocol">DNS</systemitem> server, this step is not necessary, as starting the <command>named</command> service automatically checks for a <filename>dhcpd.leases</filename> file.</para>
+ <para>When the <systemitem class="protocol">DHCP</systemitem> server is started for the first time, it fails unless the <filename>dhcpd.leases</filename> file exists. You can use the command <command>touch /var/lib/dhcpd/dhcpd.leases</command> to create the file if it does not exist. If the same server is also running BIND as a <systemitem class="protocol">DNS</systemitem> server, this step is not necessary, as starting the <command>named</command> service automatically checks for a <filename>dhcpd.leases</filename> file.</para>
+ <para>
+ Do not create a new lease file on a system that was previously running. If you do, all old leases are lost which causes many problems. The correct solution is to rename the <filename>dhcpd.leases~</filename> backup file to <filename>dhcpd.leases</filename> and then start the daemon.
+ </para>
</important>
- <para>To start the DHCP service, use the following command:</para>
+ <para>To start the <systemitem class="protocol">DHCP</systemitem> service, use the following command:</para>
<screen><command>systemctl start dhcpd.service</command></screen>
- <para>To stop the DHCP server, type:</para>
+ <para>To stop the <systemitem class="protocol">DHCP</systemitem> server, type:</para>
<screen><command>systemctl stop dhcpd.service</command></screen>
<para>By default, the DHCP service does not start at boot time. To configure the daemon to start automatically at boot time, run:</para>
<screen><command>systemctl enable dhcpd.service</command></screen>
@@ -242,17 +243,23 @@ subnet 192.168.1.0 netmask 255.255.255.0 {
<primary>DHCP</primary>
<secondary>command line options</secondary>
</indexterm>
- <para>If more than one network interface is attached to the system, but the DHCP server should only be started on one of the interfaces, configure the DHCP server to start only on that device. In <filename>/etc/sysconfig/dhcpd</filename>, add the name of the interface to the list of <command>DHCPDARGS</command>:</para>
- <programlisting># Command line options here
-DHCPDARGS=eth0</programlisting>
- <para>This is useful for a firewall machine with two network cards. One network card can be configured as a DHCP client to retrieve an IP address to the Internet. The other network card can be used as a DHCP server for the internal network behind the firewall. Specifying only the network card connected to the internal network makes the system more secure because users can not connect to the daemon via the Internet.</para>
- <para>Other command line options that can be specified in <filename>/etc/sysconfig/dhcpd</filename> include:</para>
+ <para>If more than one network interface is attached to the system, but the <systemitem class="protocol">DHCP</systemitem> server should only listen for <systemitem class="protocol">DHCP</systemitem> requests on one of the interfaces, configure the <systemitem class="protocol">DHCP</systemitem> server to listen only on that device. The <systemitem class="protocol">DHCP</systemitem> daemon will only listen on interfaces for which it finds a subnet declaration in the <filename>/etc/dhcp/dhcpd.conf</filename> file.</para>
+ <para>This is useful for a firewall machine with two network cards. One network card can be configured as a <systemitem class="protocol">DHCP</systemitem> client to retrieve an <systemitem class="protocol">IP</systemitem> address to the Internet. The other network card can be used as a <systemitem class="protocol">DHCP</systemitem> server for the internal network behind the firewall. Specifying only the network card connected to the internal network makes the system more secure because users can not connect to the daemon via the Internet.</para>
+ <para>
+ To specify command line options, copy and then edit the <filename>dhcpd.service</filename> file as the <systemitem class="username">root</systemitem> user. For example, as follows:
+ <screen>~]# <command>cp /usr/lib/systemd/system/dhcpd.service /etc/systemd/system/</command>
+~]# <command>vi /etc/systemd/system/dhcpd.service</command></screen>
+Edit the line under section [Service]:
+<synopsis>ExecStart=/usr/sbin/dhcpd -f -cf /etc/dhcp/dhcpd.conf -user dhcpd -group dhcpd --no-pid <replaceable>your_interface_name(s)</replaceable></synopsis>
+Then, as the <systemitem class="username">root</systemitem> user, restart the service:
+<screen>~]# <command>systemctl --system daemon-reload</command>
+~]# <command>systemctl restart dhcpd</command></screen>
+ </para>
+ <para>Command line options can be appended to <command>ExecStart=/usr/sbin/dhcpd</command> in the <filename>/etc/systemd/system/dhcpd.service</filename> unit file under section [Service]. They include:</para>
<itemizedlist>
<listitem>
<para>
- <command>-p <replaceable>portnum</replaceable>
- </command> — Specifies the UDP port number on which <command>dhcpd</command> should listen. The default is port 67. The DHCP server transmits responses to the DHCP clients at a port number one greater than the UDP port specified. For example, if the default port 67 is used, the server listens on port 67 for requests and responses to the client on port 68. If a port is specified here and the DHCP relay agent is used, the same port on which the DHCP relay agent should listen must be specified. Refer to <xref
- linkend="dhcp-relay-agent"/> for details.</para>
+ <command>-p <replaceable><portnum></replaceable></command> — Specifies the UDP port number on which <command>dhcpd</command> should listen. The default is port 67. The <systemitem class="protocol">DHCP</systemitem> server transmits responses to the <systemitem class="protocol">DHCP</systemitem> clients at a port number one greater than the UDP port specified. For example, if the default port 67 is used, the server listens on port 67 for requests and responds to the client on port 68. If a port is specified here and the <systemitem class="protocol">DHCP</systemitem> relay agent is used, the same port on which the <systemitem class="protocol">DHCP</systemitem> relay agent should listen must be specified. See <xref linkend="dhcp-relay-agent" /> for details.</para>
</listitem>
<listitem>
<para>
@@ -270,7 +277,7 @@ DHCPDARGS=eth0</programlisting>
<listitem>
<para>
<command>-lf <replaceable>filename</replaceable>
- </command> — Specifies the location of the lease database file. If a lease database file already exists, it is very important that the same file be used every time the DHCP server is started. It is strongly recommended that this option only be used for debugging purposes on non-production machines. The default location is <filename>/var/lib/dhcpd/dhcpd.leases</filename>.</para>
+ </command> — Specifies the location of the lease database file. If a lease database file already exists, it is very important that the same file be used every time the <systemitem class="protocol">DHCP</systemitem> server is started. It is strongly recommended that this option only be used for debugging purposes on non-production machines. The default location is <filename>/var/lib/dhcpd/dhcpd.leases</filename>.</para>
</listitem>
<listitem>
<para>
@@ -287,18 +294,21 @@ DHCPDARGS=eth0</programlisting>
</indexterm>
<indexterm>
<primary>DHCP</primary>
- <secondary>
- dhcrelay
- </secondary>
+ <secondary>dhcrelay</secondary>
</indexterm>
<indexterm>
- <primary>
- dhcrelay
- </primary>
+ <primary>dhcrelay</primary>
</indexterm>
- <para>The DHCP Relay Agent (<command>dhcrelay</command>) allows for the relay of DHCP and BOOTP requests from a subnet with no DHCP server on it to one or more DHCP servers on other subnets.</para>
- <para>When a DHCP client requests information, the DHCP Relay Agent forwards the request to the list of DHCP servers specified when the DHCP Relay Agent is started. When a DHCP server returns a reply, the reply is broadcast or unicast on the network that sent the original request.</para>
+ <para>
+ The DHCP Relay Agent (<application>dhcrelay</application>) enables the relay of <systemitem class="protocol">DHCP</systemitem> and <systemitem class="protocol">BOOTP</systemitem> requests from a subnet with no <systemitem class="protocol">DHCP</systemitem> server on it to one or more <systemitem class="protocol">DHCP</systemitem> servers on other subnets.
+ </para>
+
+ <para>
+ When a <systemitem class="protocol">DHCP</systemitem> client requests information, the DHCP Relay Agent forwards the request to the list of <systemitem class="protocol">DHCP</systemitem> servers specified when the DHCP Relay Agent is started. When a <systemitem class="protocol">DHCP</systemitem> server returns a reply, the reply is broadcast or unicast on the network that sent the original request.
+ </para>
+
<para>The DHCP Relay Agent listens for DHCP requests on all interfaces unless the interfaces are specified in <filename>/etc/sysconfig/dhcrelay</filename> with the <computeroutput>INTERFACES</computeroutput> directive.</para>
+
<para>To start the DHCP Relay Agent, use the following command:</para>
<screen><command>systemctl start dhcrelay.service</command></screen>
</section>
@@ -311,13 +321,12 @@ DHCPDARGS=eth0</programlisting>
<primary>Multihomed DHCP</primary>
<secondary>server configuration</secondary>
</indexterm>
- <para>A multihomed DHCP server serves multiple networks, that is, multiple subnets. The examples in these sections detail how to configure a DHCP server to serve multiple networks, select which network interfaces to listen on, and how to define network settings for systems that move networks.</para>
- <para>Before making any changes, back up the existing <filename>/etc/sysconfig/dhcpd</filename> and <filename>/etc/dhcp/dhcpd.conf</filename> files.</para>
- <para>The DHCP daemon listens on all network interfaces unless otherwise specified. Use the <filename>/etc/sysconfig/dhcpd</filename> file to specify which network interfaces the DHCP daemon listens on. The following <filename>/etc/sysconfig/dhcpd</filename> example specifies that the DHCP daemon listens on the <filename>eth0</filename> and <filename>eth1</filename> interfaces:</para>
- <programlisting>DHCPDARGS="eth0 eth1";</programlisting>
- <para>If a system has three network interfaces cards -- <filename>eth0</filename>, <filename>eth1</filename>, and <filename>eth2</filename> -- and it is only desired that the DHCP daemon listens on <filename>eth0</filename>, then only specify <computeroutput>eth0</computeroutput> in <filename>/etc/sysconfig/dhcpd</filename>:</para>
- <programlisting>DHCPDARGS="eth0";</programlisting>
- <para>The following is a basic <filename>/etc/dhcp/dhcpd.conf</filename> file, for a server that has two network interfaces, <filename>eth0</filename> in a 10.0.0.0/24 network, and <filename>eth1</filename> in a 172.16.0.0/24 network. Multiple <computeroutput>subnet</computeroutput> declarations allow different settings to be defined for multiple networks:</para>
+ <para>A multihomed <systemitem class="protocol">DHCP</systemitem> server serves multiple networks, that is, multiple subnets. The examples in these sections detail how to configure a <systemitem class="protocol">DHCP</systemitem> server to serve multiple networks, select which network interfaces to listen on, and how to define network settings for systems that move networks.</para>
+ <para>Before making any changes, back up the existing <filename>/etc/dhcp/dhcpd.conf</filename> file.</para>
+ <para>The <systemitem class="protocol">DHCP</systemitem> daemon will only listen on interfaces for which it finds a subnet declaration in the <filename>/etc/dhcp/dhcpd.conf</filename> file.</para>
+ <para>The following is a basic <filename>/etc/dhcp/dhcpd.conf</filename> file, for a server that has two network interfaces, <interface>eth0</interface> in a <systemitem class="ipaddress">10.0.0.0/24</systemitem> network, and <interface>eth1</interface> in a <systemitem class="ipaddress">172.16.0.0/24</systemitem> network. Multiple <computeroutput>subnet</computeroutput> declarations allow you to define different settings for multiple networks:</para>
+
+
<programlisting>default-lease-time <replaceable>600</replaceable>;
max-lease-time <replaceable>7200</replaceable>;
subnet 10.0.0.0 netmask 255.255.255.0 {
@@ -336,8 +345,8 @@ subnet 172.16.0.0 netmask 255.255.255.0 {
<computeroutput>subnet <replaceable>10.0.0.0</replaceable> netmask <replaceable>255.255.255.0</replaceable>;</computeroutput>
</term>
<listitem>
- <para>A <computeroutput>subnet</computeroutput> declaration is required for every network your DHCP server is serving. Multiple subnets require multiple <computeroutput>subnet</computeroutput> declarations. If the DHCP server does not have a network interface in a range of a <computeroutput>subnet</computeroutput> declaration, the DHCP server does not serve that network.</para>
- <para>If there is only one <computeroutput>subnet</computeroutput> declaration, and no network interfaces are in the range of that subnet, the DHCP daemon fails to start, and an error such as the following is logged to <filename>/var/log/messages</filename>:</para>
+ <para>A <computeroutput>subnet</computeroutput> declaration is required for every network your <systemitem class="protocol">DHCP</systemitem> server is serving. Multiple subnets require multiple <computeroutput>subnet</computeroutput> declarations. If the <systemitem class="protocol">DHCP</systemitem> server does not have a network interface in a range of a <computeroutput>subnet</computeroutput> declaration, the <systemitem class="protocol">DHCP</systemitem> server does not serve that network.</para>
+ <para>If there is only one <computeroutput>subnet</computeroutput> declaration, and no network interfaces are in the range of that subnet, the <systemitem class="protocol">DHCP</systemitem> daemon fails to start, and an error such as the following is logged to <filename>/var/log/messages</filename>:</para>
<programlisting>dhcpd: No subnet declaration for eth0 (0.0.0.0).
dhcpd: ** Ignoring requests on eth0. If this is not what
dhcpd: you want, please write a subnet declaration
@@ -373,8 +382,9 @@ dhcpd: Not configured to listen on any interfaces!</programlisting>
</listitem>
</varlistentry>
</variablelist>
- <para>For further information, see the <computeroutput>dhcpd.conf(5)</computeroutput> man page.</para>
- <section
+ <para>For further information, see the <filename>dhcpd.conf(5)</filename> man page.</para>
+
+ <section
id="sec-dns_Host_Configuration">
<title>Host Configuration</title>
<indexterm>
@@ -464,7 +474,7 @@ host interface1 {
<para>make the name in the <computeroutput>host</computeroutput> declaration unique.</para>
</listitem>
</itemizedlist>
- <para>When a name given in a <computeroutput>host</computeroutput> declaration is not unique, the DHCP daemon fails to start, and an error such as the following is logged to <filename>/var/log/messages</filename>:</para>
+ <para>When a name given in a <computeroutput>host</computeroutput> declaration is not unique, the <systemitem class="protocol">DHCP</systemitem> daemon fails to start, and an error such as the following is logged to <filename>/var/log/messages</filename>:</para>
<programlisting>dhcpd: /etc/dhcp/dhcpd.conf line 31: host interface0: already exists
dhcpd: }
dhcpd: ^
9 years, 9 months
[networking-guide] master: DNS: Updates and add "Recommended Naming Practices" (d5669c0)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit d5669c03d19de2e46607635e19ac497653f84e6e
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Sat Jul 26 12:53:06 2014 +0200
DNS: Updates and add "Recommended Naming Practices"
Thanks to thozza for his review
thanks to pspacek for "Recommended Naming Practices"
>---------------------------------------------------------------
en-US/DNS_Servers.xml | 28 +++++++++++++---------------
1 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/en-US/DNS_Servers.xml b/en-US/DNS_Servers.xml
index 7d88873..d304d67 100644
--- a/en-US/DNS_Servers.xml
+++ b/en-US/DNS_Servers.xml
@@ -15,7 +15,7 @@
<see>DNS</see>
</indexterm>
<para>
- <systemitem class="protocol">DNS</systemitem> (Domain Name System), is a network system that associates host names with their respective <systemitem class="protocol">IP</systemitem> addresses. For users, this has the advantage that they can refer to machines on the network by names that are usually easier to remember than the numerical network addresses. For system administrators, using a <systemitem class="protocol">DNS</systemitem> server, also known as a <firstterm>nameserver</firstterm>, enables changing the <systemitem class="protocol">IP</systemitem> address for a host without ever affecting the name-based queries.
+ <systemitem class="protocol">DNS</systemitem> (Domain Name System), is a distributed database system that is used to associate host names with their respective <systemitem class="protocol">IP</systemitem> addresses. For users, this has the advantage that they can refer to machines on the network by names that are usually easier to remember than the numerical network addresses. For system administrators, using a <systemitem class="protocol">DNS</systemitem> server, also known as a <firstterm>nameserver</firstterm>, enables changing the <systemitem class="protocol">IP</systemitem> address for a host without ever affecting the name-based queries. The use of the <systemitem class="protocol">DNS</systemitem> databases is not only for resolving <systemitem class="protocol">IP</systemitem> addresses to domain names and their use is becoming broader and broader as DNSSEC is deployed.
</para>
<section id="sec-Introduction_to_DNS">
<title>Introduction to DNS</title>
@@ -24,7 +24,7 @@
<see>BIND</see>
</indexterm>
<para>
- <systemitem class="protocol">DNS</systemitem> is usually implemented using one or more centralized servers that are authoritative for certain domains. When a client host requests information from a nameserver, it usually connects to port 53. The nameserver then attempts to resolve the name requested. If it does not have an authoritative answer, or does not already have the answer cached from an earlier query, it queries other nameservers, called <firstterm>root nameservers</firstterm>, to determine which nameservers are authoritative for the name in question, and then queries them to get the requested name.
+ <systemitem class="protocol">DNS</systemitem> is usually implemented using one or more centralized servers that are authoritative for certain domains. When a client host requests information from a nameserver, it usually connects to port 53. The nameserver then attempts to resolve the name requested. If the nameserver is configured to be a recursive name servers and it does not have an authoritative answer, or does not already have the answer cached from an earlier query, it queries other nameservers, called <firstterm>root nameservers</firstterm>, to determine which nameservers are authoritative for the name in question, and then queries them to get the requested name. Nameservers configured as purely authoritative, with recursion disabled, will not do lookups on behalf of clients.
</para>
<section id="sec-dns-introduction-zones">
<title>Nameserver Zones</title>
@@ -36,28 +36,22 @@
<primary>resource record</primary>
<see>BIND</see>
</indexterm>
- <indexterm>
- <primary>fully qualified domain name</primary>
- </indexterm>
- <indexterm>
- <primary><acronym>FQDN</acronym></primary>
- <see>fully qualified domain name</see>
- </indexterm>
<para>
- In a <systemitem class="protocol">DNS</systemitem> server such as BIND (Berkeley Internet Name Domain), all information is stored in basic data elements called <firstterm>resource records</firstterm> (RR). The resource record is usually a <firstterm>fully qualified domain name</firstterm> (FQDN) of a host, and is broken down into multiple sections organized into a tree-like hierarchy. This hierarchy consists of a main trunk, primary branches, secondary branches, and so on.
+ In a <systemitem class="protocol">DNS</systemitem> server, all information is stored in basic data elements called <firstterm>resource records</firstterm> (<acronym>RR</acronym>). Resource records are defined in <ulink url="http://www.rfc-editor.org/rfc/rfc1034.txt">RFC 1034</ulink>. The domain names are organized into a tree structure. Each level of the hierarchy is divided by a period (<literal>.</literal>). For example: The root domain, denoted by <literal>.</literal>, is the root of the <systemitem class="protocol">DNS</systemitem> tree, which is at level zero. The domain name <systemitem class="domainname">com</systemitem>, referred to as the <firstterm>top-level domain</firstterm> (<acronym>TLD</acronym>) is a child of the root domain (<literal>.</literal>) so it is the first level of the hierarchy. The domain name <systemitem class="domainname">example.com</systemitem> is at the second level of the hierarchy.
</para>
<example id="example-dns-introduction-zones-rr">
- <title>A simple resource record</title>
- <screen>bob.sales.example.com</screen>
+ <title>A Simple Resource Record</title>
+ <para>
+ An example of a simple <firstterm>resource record</firstterm> (<acronym>RR</acronym>):</para>
+ <screen>example.com. 86400 IN A 192.0.2.1</screen>
+ <para>
+ The domain name, <systemitem class="domainname">example.com</systemitem>, is the <firstterm>owner</firstterm> for the RR. The value <literal>86400</literal> is the <firstterm>time to live</firstterm> (<acronym>TTL</acronym>). The letters <literal>IN</literal>, meaning <quote>the Internet system</quote>, indicate the <firstterm>class</firstterm> of the RR. The letter <literal>A</literal> indicates the <firstterm>type</firstterm> of RR (in this example, a host address). The host address <systemitem class="ipaddress">192.0.2.1</systemitem> is the data contained in the final section of this RR. This one line example is a RR. A set of RRs with the same type, owner, and class is called a <firstterm>resource record set</firstterm> (<acronym>RRSet</acronym>).</para>
</example>
<indexterm>
<primary>BIND</primary>
<secondary>zones</secondary>
<tertiary>description</tertiary>
</indexterm>
- <para>
- Each level of the hierarchy is divided by a period (that is, <literal>.</literal>). In <xref linkend="example-dns-introduction-zones-rr" />, <literal>com</literal> defines the <firstterm>top-level domain</firstterm>, <literal>example</literal> its subdomain, and <literal>sales</literal> the subdomain of <literal>example</literal>. In this case, <literal>bob</literal> identifies a resource record that is part of the <systemitem class="domainname">sales.example.com</systemitem> domain. With the exception of the part furthest to the left (that is, <literal>bob</literal>), each of these sections is called a <firstterm>zone</firstterm> and defines a specific <firstterm>namespace</firstterm>.
- </para>
<indexterm>
<primary>BIND</primary>
<secondary>types</secondary>
@@ -71,6 +65,10 @@
<para>
Zones are defined on authoritative nameservers through the use of <firstterm>zone files</firstterm>, which contain definitions of the resource records in each zone. Zone files are stored on <firstterm>primary nameservers</firstterm> (also called <firstterm>master nameservers</firstterm>), where changes are made to the files, and <firstterm>secondary nameservers</firstterm> (also called <firstterm>slave nameservers</firstterm>), which receive zone definitions from the primary nameservers. Both primary and secondary nameservers are authoritative for the zone and look the same to clients. Depending on the configuration, any nameserver can also serve as a primary or secondary server for multiple zones at the same time.
</para>
+
+<para>
+ Note that administrators of <systemitem class="protocol">DNS</systemitem> and <systemitem class="protocol">DHCP</systemitem> servers, as well as any provisioning applications, should agree on the host name format used in an organization. See <xref linkend="sec-Recommended_Naming_Practices" /> for more information on the format of host names.
+</para>
</section>
<section id="sec-dns-introduction-nameservers">
<title>Nameserver Types</title>
9 years, 9 months
[networking-guide] master: Bonding: Major update to chapter (722ea9a)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 722ea9a3a20763ae6268febced982647c3c36364
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Sat Jul 26 12:36:58 2014 +0200
Bonding: Major update to chapter
>---------------------------------------------------------------
en-US/Configure_Network_Bonding.xml | 83 ++++++++++++++++++-----------------
1 files changed, 42 insertions(+), 41 deletions(-)
diff --git a/en-US/Configure_Network_Bonding.xml b/en-US/Configure_Network_Bonding.xml
index 525381d..bf00546 100644
--- a/en-US/Configure_Network_Bonding.xml
+++ b/en-US/Configure_Network_Bonding.xml
@@ -7,16 +7,13 @@
<title>Configure Network Bonding</title>
<para>
- <application>Fedora</application> allows administrators to bind multiple network interfaces together into a single, bonded, channel. Channel bonding enables two or more network interfaces to act as one, simultaneously increasing the bandwidth and providing redundancy.
+ Fedora allows administrators to bind multiple network interfaces together into a single, bonded, channel. Channel bonding enables two or more network interfaces to act as one, simultaneously increasing the bandwidth and providing redundancy.
</para>
-<section id="sec-Configure_Network_Bonding_Using_NetworkManager">
- <title>Configure Network Bonding Using NetworkManager</title>
-
<section id="sec-Bond-Understanding_the_Default_Behavior_of_Master_and_Slave_Interfaces">
<title>Understanding the Default Behavior of Master and Slave Interfaces</title>
<para>
-When controlling bonded slave interfaces using <systemitem class="daemon">NetworkManager</systemitem>, and especially when fault finding, keep the following in mind:
+When controlling bonded slave interfaces using the <systemitem class="daemon">NetworkManager</systemitem> daemon, and especially when fault finding, keep the following in mind:
<orderedlist>
<listitem>
<para>
@@ -57,11 +54,11 @@ When controlling bonded slave interfaces using <systemitem class="daemon">Networ
</para>
</section>
- <section
- id="sec-Establishing_a_Bond_Connection">
- <title>Establishing a Bond Connection</title>
+ <section id="sec-Creating_a_Bond_Connection_Using_a_GUI">
+ <title>Creating a Bond Connection Using a GUI</title>
<para>You can use the GNOME <application>control-center</application> utility to direct <application>NetworkManager</application> to create a Bond from two or more Wired or InfiniBand connections. It is not necessary to create the connections to be bonded first. They can be configured as part of the process to configure the bond. You must have the MAC addresses of the interfaces available in order to complete the configuration process.</para>
-
+ <section id="sec-Establishing_a_Bond_Connection">
+ <title>Establishing a Bond Connection</title>
<procedure
id="procedure-Adding_a_New_Bond_Connection">
<title>Adding a New Bond Connection</title>
@@ -72,13 +69,13 @@ When controlling bonded slave interfaces using <systemitem class="daemon">Networ
</step>
<step>
- <para>Click the plus symbol to open the selection list. Select <guilabel>Bond</guilabel>. The <guilabel>Editing Bond Connection <replaceable>1</replaceable></guilabel> window appears.</para>
+ <para>Click the plus symbol to open the selection list. Select <guilabel>Bond</guilabel>. The <guilabel>Editing Bond connection <replaceable>1</replaceable></guilabel> window appears.</para>
</step>
<step>
<para>On the <guilabel>Bond</guilabel> tab, click <guibutton>Add</guibutton> and select the type of interface you want to use with the bond connection. Click the <guibutton>Create</guibutton> button. Note that the dialog to select the slave type only comes up when you create the first slave; after that, it will automatically use that same type for all further slaves.</para>
</step>
<step>
- <para>The <guilabel>Editing bond0 slave 1</guilabel> window appears. Fill in the MAC address of the first interface to be bonded. Click the <guibutton>Save</guibutton> button.</para>
+ <para>The <guilabel>Editing bond0 slave 1</guilabel> window appears. Use the <guilabel>Device MAC address</guilabel> drop-down menu to select the MAC address of the interface to be bonded. The first slave's MAC address will be used as the MAC address for the bond interface. If required, enter a clone MAC address to be used as the bond's MAC address. Click the <guibutton>Save</guibutton> button.</para>
</step>
<step>
<para>The name of the bonded slave appears in the <guilabel>Bonded connections</guilabel> window. Click the <guibutton>Add</guibutton> button to add further slave connections.</para>
@@ -86,7 +83,7 @@ When controlling bonded slave interfaces using <systemitem class="daemon">Networ
<step><para>Review and confirm the settings and then click the <guilabel>Save</guilabel> button.</para>
</step>
<step>
- <para>Edit the bond-specific settings by referring to <xref linkend="bh-Configuring_the_Bond_Tab"/> below.</para>
+ <para>Edit the bond-specific settings by referring to <xref linkend="sec-Configuring_the_Bond_Tab"/> below.</para>
</step>
</procedure>
@@ -121,24 +118,24 @@ When controlling bonded slave interfaces using <systemitem class="daemon">Networ
</listitem>
<listitem>
<para>
- <guilabel>All users may connect to this network</guilabel> — Select this box to create a connection available to all users on the system. Changing this setting may require root privileges. See <xref linkend="sec-System-wide_and_Private_Connection_Profiles"/> for details. To prevent unexpected behavior during installation, ensure that this check box remains selected for any network interface that you configure.
+ <guilabel>All users may connect to this network</guilabel> — Select this box to create a connection available to all users on the system. Changing this setting may require root privileges. See <xref linkend="sec-System-wide_and_Private_Connection_Profiles"/> for details.
</para>
</listitem>
<listitem>
<para>
- <guilabel>Automatically connect to VPN when using this connection</guilabel> — Select this box if you want <application>NetworkManager</application> to auto-connect to a VPN connection when it is available. Select the VPN from the dropdown menu.
+ <guilabel>Automatically connect to VPN when using this connection</guilabel> — Select this box if you want <application>NetworkManager</application> to auto-connect to a VPN connection when it is available. Select the VPN from the drop-down menu.
</para>
</listitem>
<listitem>
<para>
- <guilabel>Firewall Zone</guilabel> — Select the firewall zone from the dropdown menu.
+ <guilabel>Firewall Zone</guilabel> — Select the firewall zone from the drop-down menu.
</para>
</listitem>
</itemizedlist>
</step>
<step>
- <para>Edit the bond-specific settings by referring to <xref linkend="bh-Configuring_the_Bond_Tab"/> below.</para>
+ <para>Edit the bond-specific settings by referring to <xref linkend="sec-Configuring_the_Bond_Tab"/> below.</para>
</step>
</procedure>
<bridgehead
@@ -156,14 +153,14 @@ When controlling bonded slave interfaces using <systemitem class="daemon">Networ
</para>
</listitem>
<listitem>
- <para>IPv6 settings for the connection, click the <guilabel>IPv6 Settings</guilabel> tab and proceed to <xref
+ <para><systemitem class="protocol">IPv6</systemitem> settings for the connection, click the <guilabel>IPv6 Settings</guilabel> tab and proceed to <xref
linkend="sec-Configuring_IPv6_Settings"/>.
</para>
</listitem>
</itemizedlist>
- <bridgehead
- id="bh-Configuring_the_Bond_Tab">Configuring the Bond Tab</bridgehead>
+ <section id="sec-Configuring_the_Bond_Tab">
+ <title>Configuring the Bond Tab</title>
<para>If you have already added a new bond connection (refer to <xref
linkend="procedure-Adding_a_New_Bond_Connection"/> for instructions), you can edit the <guilabel>Bond</guilabel> tab to set the load sharing mode and the type of link monitoring to use to detect failures of a slave connection.</para>
<variablelist>
@@ -194,7 +191,7 @@ When controlling bonded slave interfaces using <systemitem class="daemon">Networ
<guilabel>Round-robin</guilabel>
</term>
<listitem>
- <para>Sets a round-robin policy for fault tolerance and load balancing. Transmissions are received and sent out sequentially on each bonded slave interface beginning with the first one available.</para>
+ <para>Sets a round-robin policy for fault tolerance and load balancing. Transmissions are received and sent out sequentially on each bonded slave interface beginning with the first one available. This mode might not work behind a bridge with virtual machines without additional switch configuration.</para>
</listitem>
</varlistentry>
@@ -212,7 +209,7 @@ When controlling bonded slave interfaces using <systemitem class="daemon">Networ
<guilabel>XOR</guilabel>
</term>
<listitem>
- <para>Sets an XOR (exclusive-or) policy for fault tolerance and load balancing. Using this method, the interface matches up the incoming request's MAC address with the MAC address for one of the slave NICs. Once this link is established, transmissions are sent out sequentially beginning with the first available interface.</para>
+ <para>Sets an XOR (exclusive-or) policy. Transmissions are based on the selected hash policy. The default is to derive a hash by XOR of the source and destination MAC addresses multiplied by the modulo of the number of slave interfaces. In this mode traffic destined for specific peers will always be sent over the same interface. As the destination is determined by the MAC addresses this method works best for traffic to peers on the same link or local network. If traffic has to pass through a single router then this mode of traffic balancing will be suboptimal.</para>
</listitem>
</varlistentry>
@@ -221,7 +218,7 @@ When controlling bonded slave interfaces using <systemitem class="daemon">Networ
<guilabel>Broadcast</guilabel>
</term>
<listitem>
- <para>Sets a broadcast policy for fault tolerance. All transmissions are sent on all slave interfaces.</para>
+ <para>Sets a broadcast policy for fault tolerance. All transmissions are sent on all slave interfaces. This mode might not work behind a bridge with virtual machines without additional switch configuration.</para>
</listitem>
</varlistentry>
@@ -239,16 +236,16 @@ When controlling bonded slave interfaces using <systemitem class="daemon">Networ
<guilabel>Adaptive transmit load balancing</guilabel>
</term>
<listitem>
- <para>Sets an adaptive Transmit Load Balancing (TLB) policy for fault tolerance and load balancing. The outgoing traffic is distributed according to the current load on each slave interface. Incoming traffic is received by the current slave. If the receiving slave fails, another slave takes over the MAC address of the failed slave.</para>
+ <para>Sets an adaptive Transmit Load Balancing (TLB) policy for fault tolerance and load balancing. The outgoing traffic is distributed according to the current load on each slave interface. Incoming traffic is received by the current slave. If the receiving slave fails, another slave takes over the MAC address of the failed slave. This mode is only suitable for local addresses known to the kernel bonding module and therefore cannot be used behind a bridge with virtual machines.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
- <guilabel>Active Load Balancing</guilabel>
+ <guilabel>Adaptive load balancing</guilabel>
</term>
<listitem>
- <para>Sets an Active Load Balancing (ALB) policy for fault tolerance and load balancing. Includes transmit and receive load balancing for <systemitem class="protocol">IPv4</systemitem> traffic. Receive load balancing is achieved through <systemitem class="protocol">ARP</systemitem> negotiation.</para>
+ <para>Sets an Adaptive Load Balancing (ALB) policy for fault tolerance and load balancing. Includes transmit and receive load balancing for <systemitem class="protocol">IPv4</systemitem> traffic. Receive load balancing is achieved through <systemitem class="protocol">ARP</systemitem> negotiation. This mode is only suitable for local addresses known to the kernel bonding module and therefore cannot be used behind a bridge with virtual machines.</para>
</listitem>
</varlistentry>
@@ -299,7 +296,8 @@ When controlling bonded slave interfaces using <systemitem class="daemon">Networ
<guilabel>ARP</guilabel>
</term>
<listitem>
- <para>The address resolution protocol (<systemitem class="protocol">ARP</systemitem>) is used to probe one or more peers to determine how well the link layer connections are working. It is dependent on the device driver providing the transmit start time and the last receive time. Two options are available:</para>
+ <para>The address resolution protocol (<systemitem class="protocol">ARP</systemitem>) is used to probe one or more peers to determine how well the link-layer connections are working. It is dependent on the device driver providing the transmit start time and the last receive time.</para>
+ <para>Two options are available:</para>
<variablelist>
<varlistentry>
@@ -323,10 +321,12 @@ When controlling bonded slave interfaces using <systemitem class="daemon">Networ
</varlistentry>
</variablelist>
+ </section>
</section>
</section>
+
<section id="sec-Network_Bonding_Using_the_Command_Line_Interface">
<title>Using the Command Line Interface (CLI)</title>
<para>
@@ -335,9 +335,10 @@ When controlling bonded slave interfaces using <systemitem class="daemon">Networ
<section id="sec-Check_if_Bonding_Kernel_Module_is_Installed">
<title>Check if Bonding Kernel Module is Installed</title>
<para>
- In <application>Fedora</application>, the bonding module is loaded by default. If necessary, you can make sure that the module is loaded by issuing the following command as <systemitem class="username">root</systemitem>:
- <screen>~]# <command>modprobe --first-time bonding</command>
-modprobe: ERROR: could not insert 'bonding': Module already in kernel</screen>
+ In Fedora, the bonding module is not loaded by default. You can load the module by issuing the following command as <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>modprobe --first-time bonding</command></screen>
+ This activation will not persist across system restarts. See the <citetitle pubwork="book">&MAJOROSVER; System Administrator's Guide</citetitle> for an explanation of persistent module loading.</para>
+ <para>
To display information about the module, issue the following command:
<screen>~]$ <command>modinfo bonding</command></screen>
See the <filename>modprobe(8)</filename> man page for more command options.
@@ -356,8 +357,8 @@ See the <filename>modprobe(8)</filename> man page for more command options.
<para>
The following is a sample channel bonding configuration file:
</para>
- <example id="ex-Sample_ifcfg-bond0_Interface_Configuration_File">
- <title>Sample ifcfg-bond0 Interface Configuration File</title>
+ <example id="ex-Example_ifcfg-bond0_Interface_Configuration_File">
+ <title>Example ifcfg-bond0 Interface Configuration File</title>
<programlisting>DEVICE=bond0
IPADDR=192.168.1.1
NETMASK=255.255.255.0
@@ -400,27 +401,27 @@ NM_CONTROLLED=no</programlisting>
</section>
- <section id="sec-Network_Bonding_sec-Using_the_NetworkManager_Command_Line_Tool_nmcli">
+ <section id="sec-Network_Bonding_Using_the_NetworkManager_Command_Line_Tool_nmcli">
<title>Using the NetworkManager Command Line Tool, nmcli</title>
<para>
- To create a bond, with name <interface>mybond0</interface>, issue a command as follows:
- <screen>~]$ <command>nmcli con add type bond con-name mybond0 ifname mybond0 mode active-backup</command>
+ To create a bond, named <replaceable>mybond0</replaceable>, issue a command as follows:
+ <screen>~]$ <command>nmcli con add type bond con-name <replaceable>mybond0</replaceable> ifname <replaceable>mybond0</replaceable> mode active-backup</command>
Connection 'mybond0' (9301ff97-abbc-4432-aad1-246d7faea7fb) successfully added.</screen>
To add a slave interface, issue a command in the following form:
- <screen>~]$ <command>nmcli con add type bond-slave ifname ens7 master mybond0</command></screen>
+ <screen>~]$ <command>nmcli con add type bond-slave ifname <replaceable>ens7</replaceable> master <replaceable>mybond0</replaceable></command></screen>
To add additional slaves, repeat the previous command with a new interface, for example:
- <screen>~]$ <command>nmcli con add type bond-slave ifname ens3 master mybond0</command>
+ <screen>~]$ <command>nmcli con add type bond-slave ifname <replaceable>ens3</replaceable> master <replaceable>mybond0</replaceable></command>
Connection 'bond-slave-ens3-1' (50c59350-1531-45f4-ba04-33431c16e386) successfully added.</screen>
Note that as no <command>con-name</command> was given for the slaves, the name was derived from the interface name by prepending the type. At time of writing, <application>nmcli</application> only supports Ethernet slaves.
</para>
<para>
In order to bring up a bond, the slaves must be brought up first as follows:
- <screen>~]$ <command>nmcli con up bond-slave-ens7</command>
+ <screen>~]$ <command>nmcli con up bond-slave-<replaceable>ens7</replaceable></command>
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/14)</screen>
-<screen>~]$ <command>nmcli con up bond-slave-ens3</command>
+<screen>~]$ <command>nmcli con up bond-slave-<replaceable>ens3</replaceable></command>
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/15)</screen>
Now bring up the bond as follows:
-<screen>~]$ <command>nmcli con up bond-mybond0</command>
+<screen>~]$ <command>nmcli con up bond-<replaceable>mybond0</replaceable></command>
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/16)</screen>
</para>
<para>
@@ -463,7 +464,7 @@ Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkMa
<listitem>
<para>
<filename
- class="directory">/usr/share/doc/kernel-doc-<replaceable><kernel_version></replaceable>/Documentation/</filename> — This directory, which is provided by the <package>kernel-doc</package> package, contains information on bonding. Before accessing the kernel documentation, you must run the following command as <systemitem class="username">root</systemitem>:</para>
+ class="directory">/usr/share/doc/kernel-doc/Documentation/</filename> — This directory, which is provided by the <package>kernel-doc</package> package, contains information on bonding. Before accessing the kernel documentation, you must run the following command as <systemitem class="username">root</systemitem>:</para>
<screen>~]# <command>yum install kernel-doc</command></screen>
<para>
<filename>/usr/share/doc/kernel-doc-<replaceable>version</replaceable>/Documentation/networking/bonding.txt</filename> — Describes the Linux bonding driver.
@@ -488,7 +489,7 @@ Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkMa
<term><citetitle pubwork="book">&MAJOROSVER; System Administrator's Guide</citetitle></term>
<listitem>
<para>
- Explains the use of bonding module directives.
+ Explains the use of kernel module capabilities.
</para>
</listitem>
</varlistentry>
9 years, 9 months
[networking-guide] master: Major update to Team chapter (c3906a2)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit c3906a2dabccf8fdf2abdfd86f54b3e141cc2331
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Fri Jul 25 08:43:50 2014 +0200
Major update to Team chapter
Thanks to fleitner, jtluka, and jpriko for their reviews.
>---------------------------------------------------------------
en-US/Configure_Network_Teaming.xml | 288 +++++++++++++++++++----------------
1 files changed, 157 insertions(+), 131 deletions(-)
diff --git a/en-US/Configure_Network_Teaming.xml b/en-US/Configure_Network_Teaming.xml
index 75bad7c..1b6740e 100644
--- a/en-US/Configure_Network_Teaming.xml
+++ b/en-US/Configure_Network_Teaming.xml
@@ -9,7 +9,7 @@
<section id="sec-Understanding_Network_Teaming">
<title>Understanding Network Teaming</title>
<para>
- The combining or aggregating together of network links in order to provide a logical link with higher throughput, or to provide redundancy, is known by many names such as <quote>channel bonding</quote>, <quote>Ethernet bonding</quote>, <quote>port trunking</quote>, <quote>channel teaming</quote>, <quote>NIC teaming</quote>, <quote>link aggregation</quote>, and so on. This concept as originally implemented in the Linux kernel is widely referred to as <quote>bonding</quote>. The term Network Teaming has been chosen to refer to this new implementation of the concept. The existing bonding driver is unaffected, Network Teaming is offered as an alternative and does not replace bonding in <application>Fedora</application>.
+ The combining or aggregating together of network links in order to provide a logical link with higher throughput, or to provide redundancy, is known by many names such as <quote>channel bonding</quote>, <quote>Ethernet bonding</quote>, <quote>port trunking</quote>, <quote>channel teaming</quote>, <quote>NIC teaming</quote>, <quote>link aggregation</quote>, and so on. This concept as originally implemented in the Linux kernel is widely referred to as <quote>bonding</quote>. The term Network Teaming has been chosen to refer to this new implementation of the concept. The existing bonding driver is unaffected, Network Teaming is offered as an alternative and does not replace bonding in Fedora.
</para>
<para>
Network Teaming, or Team, is designed to implement the concept in a different way by providing a small kernel driver to implement the fast handling of packet flows, and various user-space applications to do everything else in user space. The driver has an <firstterm>Application Programming Interface</firstterm> (<acronym>API</acronym>), referred to as <quote>Team Netlink API</quote>, which implements Netlink communications. User-space applications can use this API to communicate with the driver. A library, referred to as <quote>lib</quote>, has been provided to do user space wrapping of Team Netlink communications and RT Netlink messages. An application daemon, <systemitem class="daemon">teamd</systemitem>, which uses Libteam lib is also provided. One instance of <systemitem class="daemon">teamd</systemitem> can control one instance of the Team driver. The daemon implements the load-balancing and active-backup logic, such as round-robin, by using additional code referre
d to as <quote>runners</quote>. By separating the code in this way, the Network Teaming implementation presents an easily extensible and scalable solution for load-balancing and redundancy requirements. For example, custom runners can be relatively easily written to implement new logic via <systemitem class="daemon">teamd</systemitem>, and even <systemitem class="daemon">teamd</systemitem> is optional, users can write their own application to use <application>libteam</application>.
@@ -74,6 +74,51 @@
</table>
</section>
+
+<section id="sec-Team-Understanding_the_Default_Behavior_of_Master_and_Slave_Interfaces">
+<title>Understanding the Default Behavior of Master and Slave Interfaces</title>
+<para>
+When controlling teamed port interfaces using the <systemitem class="daemon">NetworkManager</systemitem> daemon, and especially when fault finding, keep the following in mind:
+<orderedlist>
+ <listitem>
+ <para>
+ Starting the master interface does not automatically start the port interfaces.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Starting a port interface always starts the master interface.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Stopping the master interface also stops the port interfaces.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A master without ports can start static <systemitem class="protocol">IP</systemitem> connections.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A master without ports waits for ports when starting <systemitem class="protocol">DHCP</systemitem> connections.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A master with a <systemitem class="protocol">DHCP</systemitem> connection waiting for ports completes when a port with a carrier is added.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A master with a <systemitem class="protocol">DHCP</systemitem> connection waiting for ports continues waiting when a port without a carrier is added.
+ </para>
+ </listitem>
+</orderedlist>
+</para>
+</section>
+
<section id="sec-Understanding_the_Network_Teaming_Daemon_and_the_Runners">
<title>Understanding the Network Teaming Daemon and the "Runners"</title>
<para>
@@ -148,11 +193,11 @@ The Team daemon, <systemitem class="daemon">teamd</systemitem>, uses <applicatio
<para>
To see some examples of the command format, issue the following command:
<screen>~]$ <command>bond2team --examples</command></screen>
- New files will be created in a directory whose name starts with <filename class="directory">/tmp/bond2slave.XXXXXX</filename>, where XXXXXX is a random string. After creating the new configuration files, move the old bonding files to a backup folder and then move the new files to the <filename class="directory">/etc/sysconfig/network-scripts/</filename> directory. See the <filename>bond2team(1)</filename> man page for further details.
+ New files will be created in a directory whose name starts with <filename class="directory">/tmp/bond2team.XXXXXX/</filename>, where XXXXXX is a random string. After creating the new configuration files, move the old bonding files to a backup folder and then move the new files to the <filename class="directory">/etc/sysconfig/network-scripts/</filename> directory. See the <filename>bond2team(1)</filename> man page for further details.
</para>
</section>
-<section id="sec-Selecting_Interfaces_to_Use_as_Port_for_a__Network_Team">
+<section id="sec-Selecting_Interfaces_to_Use_as_Port_for_a_Network_Team">
<title>Selecting Interfaces to Use as Ports for a Network Team</title>
<para>
To view the available interfaces, issue the following command:
@@ -163,32 +208,41 @@ The Team daemon, <systemitem class="daemon">teamd</systemitem>, uses <applicatio
link/ether 52:54:00:6a:02:8a brd ff:ff:ff:ff:ff:ff
3: em2: <BROADCAST,MULTICAST,UP,LOWER_UP > mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether 52:54:00:9b:6d:2a brd ff:ff:ff:ff:ff:ff</screen>
-From the available interfaces, determine which are suitable for adding to your network team and then proceed to <xref linkend="sec-Configure_a_Network_Team"/>
+From the available interfaces, determine which are suitable for adding to your network team and then proceed to <xref linkend="sec-Selecting_Network_Team_Configuration_Methods"/>
</para>
+ <note>
+ <para>
+ The Team developers prefer the term <quote>port</quote> rather than <quote>slave</quote>, however <application>NetworkManager</application> uses the term <quote>team-slave</quote> to refer to interfaces that make up a team.</para>
+ </note>
</section>
-<section id="sec-Configure_a_Network_Team">
- <title>Configure a Network Team</title>
+<section id="sec-Selecting_Network_Team_Configuration_Methods">
+<title>Selecting Network Team Configuration Methods</title>
- <bridgehead id="bh-sec-Configure_a_Network_Team_Using_NM">Configure a Network Team Using NetworkManager</bridgehead>
<para>
- To configure a network team using a graphical user interface, see <xref linkend="sec-Creating_a_Network_Team_Using_a_GUI" />
+ <emphasis role="bold">To configure a network team using a graphical user interface</emphasis>, see <xref linkend="sec-Creating_a_Network_Team_Using_a_GUI" />
</para>
- <bridgehead id="bh-sec-Configure_a_Network_Team_Using_the_CLI">Configure a Network Team Using the Command Line Interface (CLI)</bridgehead>
+
<para>
- To create a network team using the command line, use <systemitem class="daemon">teamd</systemitem> commands. To use this method, proceed to <xref linkend="sec-Creating_a_Network_Team_Using_teamd"/>.
+ <emphasis role="bold">To create a network team using the Team daemon</emphasis>, <systemitem class="daemon">teamd</systemitem>, proceed to <xref linkend="sec-Creating_a_Network_Team_Using_teamd"/>.
</para>
+
<para>
- To create a network team using configuration files, proceed to <xref linkend="sec-Creating_a_Network_Team_Using_ifcfg_Files" />.
+ <emphasis role="bold">To create a network team using configuration files</emphasis>, proceed to <xref linkend="sec-Creating_a_Network_Team_Using_ifcfg_Files" />.
</para>
+ <para>
+ <emphasis role="bold">To create a network team using the command line tool</emphasis>, <application>nmcli</application>, proceed to <xref linkend="sec-Configure_Network_Teaming_Using_nmcli"/>.
+ </para>
+
+</section>
<section id="sec-Creating_a_Network_Team_Using_a_GUI">
<title>Creating a Network Team Using a GUI</title>
<section
id="sec-Establishing_a_Team_Connection">
<title>Establishing a Team Connection</title>
- <para>You can use the GNOME <application>control-center</application> utility to direct <application>NetworkManager</application> to create a team from two or more Wired or InfiniBand connections. It is not necessary to create the connections to be teamded first. They can be configured as part of the process to configure the team. You must have the MAC addresses of the interfaces available in order to complete the configuration process.</para>
+ <para>You can use the GNOME <application>control-center</application> utility to direct <application>NetworkManager</application> to create a team from two or more Wired or InfiniBand connections. It is not necessary to create the connections to be teamed first. They can be configured as part of the process to configure the team. You must have the MAC addresses of the interfaces available in order to complete the configuration process.</para>
<procedure
id="procedure-Adding_a_New_Team_Connection">
@@ -203,10 +257,10 @@ From the available interfaces, determine which are suitable for adding to your n
<para>Click the plus symbol to open the selection list. Select <guilabel>Team</guilabel>. The <guilabel>Editing Team Connection <replaceable>1</replaceable></guilabel> window appears.</para>
</step>
<step>
- <para>On the <guilabel>Team</guilabel> tab, click <guibutton>Add</guibutton> and select the type of interface you want to use with the team connection. Click the <guibutton>Create</guibutton> button. Note that the dialog to select the slave type only comes up when you create the first slave; after that, it will automatically use that same type for all further slaves.</para>
+ <para>On the <guilabel>Team</guilabel> tab, click <guibutton>Add</guibutton> and select the type of interface you want to use with the team connection. Click the <guibutton>Create</guibutton> button. Note that the dialog to select the port type only comes up when you create the first port; after that, it will automatically use that same type for all further ports.</para>
</step>
<step>
- <para>The <guilabel>Editing team0 slave 1</guilabel> window appears. Fill in the MAC address of the first interface to be bonded.</para>
+ <para>The <guilabel>Editing team0 port 1</guilabel> window appears. Fill in the MAC address of the first interface to be added to the team.</para>
</step>
<step>
<para>
@@ -219,12 +273,12 @@ From the available interfaces, determine which are suitable for adding to your n
</para>
</step>
<step>
- <para>The name of the teamed slave appears in the <guilabel>Teamed connections</guilabel> window. Click the <guibutton>Add</guibutton> button to add further slave connections.</para>
+ <para>The name of the teamed port appears in the <guilabel>Teamed connections</guilabel> window. Click the <guibutton>Add</guibutton> button to add further port connections.</para>
</step>
<step><para>Review and confirm the settings and then click the <guilabel>Save</guilabel> button.</para>
</step>
<step>
- <para>Edit the team-specific settings by referring to <xref linkend="bh-Configuring_the_Team_Tab"/> below.</para>
+ <para>Edit the team-specific settings by referring to <xref linkend="sec-Configuring_the_Team_Tab"/> below.</para>
</step>
</procedure>
@@ -259,24 +313,24 @@ From the available interfaces, determine which are suitable for adding to your n
</listitem>
<listitem>
<para>
- <guilabel>All users may connect to this network</guilabel> — Select this box to create a connection available to all users on the system. Changing this setting may require root privileges. See <xref linkend="sec-System-wide_and_Private_Connection_Profiles"/> for details. To prevent unexpected behavior during installation, ensure that this check box remains selected for any network interface that you configure.
+ <guilabel>All users may connect to this network</guilabel> — Select this box to create a connection available to all users on the system. Changing this setting may require root privileges. See <xref linkend="sec-System-wide_and_Private_Connection_Profiles"/> for details.
</para>
</listitem>
<listitem>
<para>
- <guilabel>Automatically connect to VPN when using this connection</guilabel> — Select this box if you want <application>NetworkManager</application> to auto-connect to a VPN connection when it is available. Select the VPN from the dropdown menu.
+ <guilabel>Automatically connect to VPN when using this connection</guilabel> — Select this box if you want <application>NetworkManager</application> to auto-connect to a VPN connection when it is available. Select the VPN from the drop-down menu.
</para>
</listitem>
<listitem>
<para>
- <guilabel>Firewall Zone</guilabel> — Select the firewall zone from the dropdown menu.
+ <guilabel>Firewall Zone</guilabel> — Select the firewall zone from the drop-down menu.
</para>
</listitem>
</itemizedlist>
</step>
<step>
- <para>Edit the team-specific settings by referring to <xref linkend="bh-Configuring_the_Team_Tab"/> below.</para>
+ <para>Edit the team-specific settings by referring to <xref linkend="sec-Configuring_the_Team_Tab"/> below.</para>
</step>
</procedure>
<bridgehead
@@ -300,60 +354,23 @@ From the available interfaces, determine which are suitable for adding to your n
</listitem>
</itemizedlist>
- <bridgehead
- id="bh-Configuring_the_Team_Tab">Configuring the Team Tab</bridgehead>
- <para>If you have already added a new team connection (refer to <xref
- linkend="procedure-Adding_a_New_Team_Connection"/> for instructions), you can enter a custom JSON configuration string in the text box or import a configuration file. Click <guilabel>Save</guilabel> to apply the JSON configuration to the team interface.</para>
+<section id="sec-Configuring_the_Team_Tab">
+<title>Configuring the Team Tab</title>
+ <para>If you have already added a new team connection you can enter a custom JSON configuration string in the text box or import a configuration file. Click <guilabel>Save</guilabel> to apply the JSON configuration to the team interface.</para>
<para>
For examples of JSON strings, see <xref linkend="sec-Configure_teamd_Runners" />
</para>
+ <para>
+ See <xref linkend="procedure-Adding_a_New_Team_Connection"/> for instructions on how to add a new team.
+ </para>
+ </section>
</section>
+ </section>
-<section id="sec-Team-Understanding_the_Default_Behavior_of_Master_and_Slave_Interfaces">
-<title>Understanding the Default Behavior of Master and Slave Interfaces</title>
-<para>
-When controlling teamed port interfaces using the <systemitem class="daemon">NetworkManager</systemitem> daemon, and especially when fault finding, keep the following in mind:
-<orderedlist>
- <listitem>
- <para>
- Starting the master interface does not automatically start the port interfaces.
- </para>
- </listitem>
- <listitem>
- <para>
- Starting a port interface always starts the master interface.
- </para>
- </listitem>
- <listitem>
- <para>
- Stopping the master interface also stops the port interfaces.
- </para>
- </listitem>
- <listitem>
- <para>
- A master without ports can start static <systemitem class="protocol">IP</systemitem> connections.
- </para>
- </listitem>
- <listitem>
- <para>
- A master without ports waits for ports when starting <systemitem class="protocol">DHCP</systemitem> connections.
- </para>
- </listitem>
- <listitem>
- <para>
- A master with a <systemitem class="protocol">DHCP</systemitem> connection waiting for ports completes when a port with a carrier is added.
- </para>
- </listitem>
- <listitem>
- <para>
- A master with a <systemitem class="protocol">DHCP</systemitem> connection waiting for ports continues waiting when a port without a carrier is added.
- </para>
- </listitem>
-</orderedlist>
-</para>
-</section>
-</section>
+
+<section id="sec-Configure_a_Network_Team_Using-the_Command_Line">
+ <title>Configure a Network Team Using the Command Line</title>
<section id="sec-Creating_a_Network_Team_Using_teamd">
@@ -373,21 +390,21 @@ activebackup_ethtool_3.conf loadbalance_1.conf roundrobin.conf</sc
"runner": {"name": "activebackup"},
"link_watch": {"name": "ethtool"},
"ports": {
- "em1": {
+ "eth1": {
"prio": -10,
"sticky": true
},
- "em2": {
+ "eth2": {
"prio": 100
}
}
}</screen>
- Create a working directory to store <systemitem class="daemon">teamd</systemitem> configuration files. For example, as normal user, enter a command with the following format:
- <screen>~]$ <command>mkdir ~/teamd_working_configs</command></screen>
+ Create a working configurations directory to store <systemitem class="daemon">teamd</systemitem> configuration files. For example, as normal user, enter a command with the following format:
+ <screen>~]$ <command>mkdir ~/<replaceable>teamd_working_configs</replaceable></command></screen>
Copy the file you have chosen to your working directory and edit it as necessary. As an example, you could use a command with the following format:
- <screen>~]$ <command>cp /usr/share/doc/teamd-*/example_configs/activebackup_ethtool_1.conf ~/teamd_working_configs/activebackup_ethtool_1.conf</command></screen>
+ <screen>~]$ <command>cp /usr/share/doc/teamd-*/example_configs/activebackup_ethtool_1.conf \ ~/<replaceable>teamd_working_configs</replaceable>/activebackup_ethtool_1.conf</command></screen>
To edit the file to suit your environment, for example to change the interfaces to be used as ports for the network team, open the file for editing as follows:
- <screen>~]$ <command>vi ~/teamd_working_configs/activebackup_ethtool_1.conf</command></screen>
+ <screen>~]$ <command>vi ~/<replaceable>teamd_working_configs</replaceable>/activebackup_ethtool_1.conf</command></screen>
Make any necessary changes and save the file. See the <filename>vi(1)</filename> man page for help on using the <application>vi</application> editor or use your preferred editor.
</para>
<para>
@@ -395,19 +412,21 @@ activebackup_ethtool_3.conf loadbalance_1.conf roundrobin.conf</sc
<screen>~]$ <command>ip link show</command>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
-2: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
+2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether 52:54:00:d5:f7:d4 brd ff:ff:ff:ff:ff:ff
-3: ens7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
+3: em2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether 52:54:00:d8:04:70 brd ff:ff:ff:ff:ff:ff</screen>
In this example we see that both the interfaces we plan to use are <quote>UP</quote>.
</para>
<para>
To take down an interface, issue a command as <systemitem class="username">root</systemitem> in the following format:
- <screen>~]# <command>ip link set down ens6</command></screen>
+ <screen>~]# <command>ip link set down em1</command></screen>
Repeat for each interface as necessary.
</para>
<para>
- To create a team interface based on the configuration file, as <systemitem class="username">root</systemitem> user, change to the <filename class="directory">teamd_working_configs</filename> directory and then issue a command in the following format:
+ To create a team interface based on the configuration file, as <systemitem class="username">root</systemitem> user, change to the working configurations directory (<replaceable>teamd_working_configs</replaceable> in this example):
+ <screen>~]# <command>cd /home/<replaceable>user</replaceable><replaceable>teamd_working_configs</replaceable></command></screen>
+ Then issue a command in the following format:
<screen>~]# <command>teamd -g -f activebackup_ethtool_1.conf -d</command>
Using team device "team0".
Using PID file "/var/run/teamd/team0.pid"
@@ -483,26 +502,24 @@ runner:
<title>Creating a Network Team Using ifcfg Files</title>
<para>
To create a networking team using <literal>ifcfg</literal> files, create a file in the <filename class="directory">/etc/sysconfig/network-scripts/</filename> directory as follows:
- <screen>DEVICE="team0"
-DEVICETYPE="Team"
-ONBOOT="yes"
-BOOTPROTO="static"
-IPADDR="192.168.11.1"
-NETMASK="255.255.255.0"
-TEAM_CONFIG='{"runner": {"name": "activebackup"}, "link_watch": {"name": "ethtool"}}'
-NM_CONTROLLED="no"</screen>
+ <screen>DEVICE=team0
+DEVICETYPE=Team
+ONBOOT=yes
+BOOTPROTO=static
+IPADDR=192.168.11.1
+NETMASK=255.255.255.0
+TEAM_CONFIG='{"runner": {"name": "activebackup"}, "link_watch": {"name": "ethtool"}}'</screen>
This creates the interface to the team, in other words, this is the master.
</para>
<para>
- To create a slave to be a member of <interface>team0</interface>, create one or more files in the <filename class="directory">/etc/sysconfig/network-scripts/</filename> directory as follows:
- <screen>DEVICE="eth1"
-HWADDR="D4:85:64:01:46:9E"
-DEVICETYPE="TeamPort"
-ONBOOT="yes"
-TEAM_MASTER="team0"
-TEAM_PORT_CONFIG='{"prio": 100}'
-NM_CONTROLLED="no"</screen>
-Add additional slave interfaces similar to the above as required, changing the DEVICE and HWADDR field to match the ports (the network devices) being enslaved. If port priority is not specified by <literal>prio</literal> it defaults to <literal>0</literal>; it accepts negative and positive values in the range <literal>-32,767</literal> to <literal>+32,767</literal>.
+ To create a port to be a member of <interface>team0</interface>, create one or more files in the <filename class="directory">/etc/sysconfig/network-scripts/</filename> directory as follows:
+ <screen>DEVICE=eth1
+HWADDR=D4:85:64:01:46:9E
+DEVICETYPE=TeamPort
+ONBOOT=yes
+TEAM_MASTER=team0
+TEAM_PORT_CONFIG='{"prio": 100}'</screen>
+Add additional port interfaces similar to the above as required, changing the DEVICE and HWADDR field to match the ports (the network devices) being added. If port priority is not specified by <literal>prio</literal> it defaults to <literal>0</literal>; it accepts negative and positive values in the range <literal>-32,767</literal> to <literal>+32,767</literal>.
</para>
<para>
Specifying the hardware or MAC address using the <command>HWADDR</command> directive will influence the device naming procedure. This is explained in <xref linkend="ch-Consistent_Network_Device_Naming" />.
@@ -578,15 +595,15 @@ em1: up 100 fullduplex</screen>
<title>Setting the Active Port Options of a Team Using teamnl</title>
<para>
To set the <option>activeport</option> option in a network team, using the <application>teamnl</application> utility, issue the following command as <systemitem class="username">root</systemitem>:
- <screen>~]# <command>teamnl team0 setoption activeport 5</command>
-~]# <command>teamnl team0 getoption activeport</command>
+ <screen>~]# <command>teamnl team0 setoption activeport 5</command></screen>
+To check the change in team port options, issue the following command as <systemitem class="username">root</systemitem>:
+<screen>~]# <command>teamnl team0 getoption activeport</command>
5</screen>
</para>
</section>
</section>
-
<section id="sec-Controlling_teamd_with_teamdctl">
<title>Controlling teamd with teamdctl</title>
@@ -594,25 +611,25 @@ em1: up 100 fullduplex</screen>
In order to query a running instance of <systemitem class="daemon">teamd</systemitem> for statistics or configuration information, or to make changes, the control tool <application>teamdctl</application> is used.
</para>
<para>
-To view the current team state of a team <interface>team0</interface>, enter the following command:
- <screen>~]$ <command>teamdctl team0 state view</command></screen>
+To view the current team state of a team <interface>team0</interface>, enter the following command as <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>teamdctl team0 state view</command></screen>
For a more verbose output:
- <screen>~]$ <command>teamdctl team0 state view -v</command></screen>
+ <screen>~]# <command>teamdctl team0 state view -v</command></screen>
</para>
<para>
For a complete state dump in JSON format (useful for machine processing) of <interface>team0</interface>, use the following command:
- <screen>~]$ <command>teamdctl team0 state dump</command></screen>
+ <screen>~]# <command>teamdctl team0 state dump</command></screen>
</para>
<para>
For a configuration dump in JSON format of <interface>team0</interface>, use the following command:
- <screen>~]$ <command>teamdctl team0 config dump</command></screen>
+ <screen>~]# <command>teamdctl team0 config dump</command></screen>
</para>
<para>
To view the configuration of a port <interface>em1</interface>, that is part of a team <interface>team0</interface>, enter the following command:
- <screen>~]$ <command>teamdctl team0 port config dump em1</command></screen>
+ <screen>~]# <command>teamdctl team0 port config dump em1</command></screen>
</para>
<section id="sec-Add_a_port_to_a_Network_Team">
@@ -638,10 +655,12 @@ To view the configuration of a port <interface>em1</interface>, that is part of
To apply a JSON format configuration to a port <interface>em1</interface> in a network team <interface>team0</interface>, issue a command as <systemitem class="username">root</systemitem> in the following format:
<screen>~]# <command>teamdctl team0 port config update em1 <replaceable>JSON-config-string</replaceable></command></screen>
Where <replaceable>JSON-config-string</replaceable> is the configuration as a string of text in JSON format. This will update the configuration of the port using the JSON format string supplied. An example of a valid JSON string for configuring a port would be the following:
- <screen>{
+ <screen>
+{
"prio": -10,
"sticky": true
}</screen>
+Use single quotes around the JSON configuration string and omit the line breaks.
</para>
<para>
Note that the old configuration will be overwritten and that any options omitted will be reset to the default values. See the <filename>teamdctl(8)</filename> man page for more team daemon control tool command examples.</para>
@@ -659,6 +678,9 @@ To view the configuration of a port <interface>em1</interface>, that is part of
<section id="sec-Configure_teamd_Runners">
<title>Configure teamd Runners</title>
+ <para>
+ Runners are units of code which are compiled into the Team daemon when an instance of the daemon is created. For an introduction to the <systemitem class="daemon">teamd</systemitem> runners, see <xref linkend="sec-Understanding_the_Network_Teaming_Daemon_and_the_Runners" />.
+ </para>
<section id="sec-Configure_the_broadcast_Runner">
<title>Configure the broadcast Runner</title>
@@ -679,7 +701,7 @@ Please see the <filename>teamd.conf(5)</filename> man page for more information.
<section id="sec-Configure_the_random_Runner">
<title>Configure the random Runner</title>
<para>
- The random runner behaves similarly to the roundrobin runner, but it does not do percentage calculations and therefore uses less system resources.
+ The random runner behaves similarly to the roundrobin runner.
</para>
<para>
To configure the random runner, using an editor as <systemitem class="username">root</systemitem>, add the following to the team JSON format configuration file:
@@ -848,7 +870,7 @@ Please see the <filename>teamd.conf(5)</filename> man page for more information.
"link_watch": {"name": "ethtool"},
"ports": {"em1": {}, "em2": {}}
}</screen>
- Configuration for connection to a <firstterm>link access control protocol</firstterm> (<acronym>LACP</acronym>) capable counterpart. The LACP runner should use <application>ethtool</application> to monitor the status of a link. It does not make sense to use any other link monitoring method besides the <application>ethtool</application> because, for example in the case of <application>arp_ping</application>, the link would never come up. The reason is that the link has to be established first and only after that can packets, ARP included, go through. Using <application>ethtool</application> prevents this because it monitors each link layer individually.</para>
+ Configuration for connection to a <firstterm>link aggregation control protocol</firstterm> (<acronym>LACP</acronym>) capable counterpart. The LACP runner should use <application>ethtool</application> to monitor the status of a link. It does not make sense to use any other link monitoring method besides the <application>ethtool</application> because, for example in the case of <application>arp_ping</application>, the link would never come up. The reason is that the link has to be established first and only after that can packets, ARP included, go through. Using <application>ethtool</application> prevents this because it monitors each link layer individually.</para>
<para>
Active load balancing is possible with this runner in the same way as it is done for the loadbalance runner. To enable active transmit (Tx) load balancing, add the following section:
<screen>"tx_balancer": {
@@ -916,9 +938,8 @@ Please see the <filename>teamd.conf(5)</filename> man page for more information.
This configuration uses <application>arp_ping</application> as the link watcher. The <option>missed_max</option> option is a limit value of the maximum allowed number of missed replies (ARP replies for example). It should be chosen in conjunction with the <option>interval</option> option in order to determine the total time before a link is reported as down.
</para>
<para>
- To load a new configuration for a team port <interface>em2</interface>, with JSON configuration string <replaceable>JSON-config-string</replaceable>, issue the following command as <systemitem class="username">root</systemitem>:
- <screen>
-~]# port config update em2 <replaceable>JSON-config-string</replaceable></screen>
+ To load a new configuration for a team port <interface>em2</interface>, from a file containing a JSON configuration, issue the following command as <systemitem class="username">root</systemitem>:
+ <screen>~]# port config update em2 <replaceable>JSON-config-file</replaceable></screen>
Note that the old configuration will be overwritten and that any options omitted will be reset to the default values. See the <filename>teamdctl(8)</filename> man page for more team daemon control tool command examples.
</para>
</section>
@@ -967,13 +988,13 @@ Please see the <filename>teamd.conf(5)</filename> man page for more information.
</para>
<para>
- To configure the host name from which to derive the <systemitem class="protocol">IPv6</systemitem> address target address for the NS/NA packets, add or edit a section as follows:
+ To configure the host name that is resolved to the <systemitem class="protocol">IPv6</systemitem> address target address for the NS/NA packets, add or edit a section as follows:
<screen>
"link_watch": {
"name": "nsna_ping",
"target_host": "MyStorage"
}</screen>
- Host name to be converted to an <systemitem class="protocol">IPv6</systemitem> address which will be used as the target address for the NS/NA packets. An <systemitem class="protocol">IPv6</systemitem> address can be used in place of a host name.
+The <quote>target_host</quote> option contains the host name to be converted to an <systemitem class="protocol">IPv6</systemitem> address which will be used as the target address for the NS/NA packets. An <systemitem class="protocol">IPv6</systemitem> address can be used in place of a host name.
</para>
<para>
Please see the <filename>teamd.conf(5)</filename> man page for more information.
@@ -985,7 +1006,7 @@ Please see the <filename>teamd.conf(5)</filename> man page for more information.
<section id="sec-Configure_Port_Selection_Override">
<title>Configure Port Selection Override</title>
<para>
-The physical port which transmits a frame is normally selected by the kernel part of the team driver, and is not relevant to the user or system administrator. The output port is selected using the policies of the selected team mode (<systemitem class="daemon">teamd</systemitem> runner). On occasion however, it is helpful to direct certain classes of outgoing traffic to certain physical interfaces to implement slightly more complex policies. By default the team driver is multiqueue aware and 16 queues are created when the driver initializes (see <filename>/usr/share/doc/kernel-doc-<replaceable>version</replaceable>/Documentation/networking/multiqueue.txt</filename> for details). If more or less queues are desired, the Netlink attribute <command>tx_queues</command> can be used to change this value during the team driver instance creation.
+The physical port which transmits a frame is normally selected by the kernel part of the team driver, and is not relevant to the user or system administrator. The output port is selected using the policies of the selected team mode (<systemitem class="daemon">teamd</systemitem> runner). On occasion however, it is helpful to direct certain classes of outgoing traffic to certain physical interfaces to implement slightly more complex policies. By default the team driver is multiqueue aware and 16 queues are created when the driver initializes (see <filename>/usr/share/doc/kernel-doc/Documentation/networking/multiqueue.txt</filename> for details). If more or less queues are desired, the Netlink attribute <command>tx_queues</command> can be used to change this value during the team driver instance creation.
</para>
<para>
The queue ID for a port can be set by the port configuration option <option>queue_id</option> as follows:
@@ -993,7 +1014,7 @@ The queue ID for a port can be set by the port configuration option <option>queu
{
"queue_id": 3
}</screen>
-These queue ID's can be used in conjunction with the <application>tc</application> utility to configure a multiqueue queue discipline and filters to bias certain traffic to be transmitted on certain slave devices. For example, if using the above configuration and wanting to force all traffic bound to <systemitem class="ipaddress">192.168.1.100</systemitem> to use <interface>eth1</interface> in the team as its output device, issue commands as <systemitem class="username">root</systemitem> in the following format:
+These queue ID's can be used in conjunction with the <application>tc</application> utility to configure a multiqueue queue discipline and filters to bias certain traffic to be transmitted on certain port devices. For example, if using the above configuration and wanting to force all traffic bound to <systemitem class="ipaddress">192.168.1.100</systemitem> to use <interface>eth1</interface> in the team as its output device, issue commands as <systemitem class="username">root</systemitem> in the following format:
<screen>~]# <command>tc qdisc add dev team0 handle 1 root multiq</command>
~]# <command>tc filter add dev team0 protocol ip parent 1: prio 1 u32 match ip dst \</command>
<command> 192.168.1.100 action skbedit queue_mapping 3</command></screen>
@@ -1002,9 +1023,9 @@ This mechanism of overriding runner selection logic in order to bind traffic to
</section>
<section id="sec-Configure_BPF-based_Tx_Port_Selectors_for_Hash_Computation_Algorithm">
- <title>Configure BPF-based Tx Port Selectors for Hash Computation Algorithm</title>
+ <title>Configure BPF-based Tx Port Selectors</title>
<para>
- The loadbalance and LACP runners uses hashes of packets to sort network traffic flow. The hash computation mechanism is based on the <firstterm>Berkeley Packet Filter</firstterm> (<acronym>BPF</acronym>) code. The BPF code is used to generate a hash rather than make a policy decision for incoming packets. The hash length is 8 bits giving 256 variants. This means many different <firstterm>socket buffers</firstterm> (<acronym>SKB</acronym>) can have the same hash and therefore pass traffic over the same link. The use of a short hash is a quick way to sort traffic into different streams for the purposes of load balancing across multiple links. In static mode, the hash is only used to decided out of which port the traffic should be sent. In active mode, the runner will continually reassign hashes to different ports in an attempt to reach a perfect balance.</para>
+ The loadbalance and LACP runners uses hashes of packets to sort network traffic flow. The hash computation mechanism is based on the <firstterm>Berkeley Packet Filter</firstterm> (<acronym>BPF</acronym>) code. The BPF code is used to generate a hash rather than make a policy decision for outgoing packets. The hash length is 8 bits giving 256 variants. This means many different <firstterm>socket buffers</firstterm> (<acronym>SKB</acronym>) can have the same hash and therefore pass traffic over the same link. The use of a short hash is a quick way to sort traffic into different streams for the purposes of load balancing across multiple links. In static mode, the hash is only used to decide out of which port the traffic should be sent. In active mode, the runner will continually reassign hashes to different ports in an attempt to reach a perfect balance.</para>
<para>
The following fragment types or strings can be used for packet Tx hash computation:
@@ -1085,37 +1106,42 @@ Connection 'Team0' (fcafb3f0-4c95-48df-9e28-7ac7213f38ba) successfully added.</s
</para>
<para>
To view the team interfaces just configured, issue a command as follows:
- <screen>~$ <command>nmcli connection show</command>
+ <screen>~]$ <command>nmcli connection show</command>
NAME UUID TYPE TIMESTAMP-REAL
Team0 fcafb3f0-4c95-48df-9e28-7ac7213f38ba team never
team-ServerA 981eb129-1707-4a2e-a6ea-413330d96c10 team never</screen>
</para>
<para>
To load a team configuration file for a team that already exists, issue a command as follows:
- <screen>~]$ <command>nmcli connection modify team-ServerA team.config <replaceable>JSON-Config</replaceable></command></screen>
+ <screen>~]$ <command>nmcli connection modify team-ServerA team.config <replaceable>JSON-config</replaceable></command></screen>
+ You can specify the team configuration either as JSON string or provide a file name containing the configuration. The file name can include the path. In both cases, what is stored in the <parameter>team.config</parameter> property is the JSON string. In the case of a JSON string, use single quotes around the string and paste the entire string to the command line.
+</para>
+<para>
+ To review the <parameter>team.config</parameter> property, enter a command as follows:
+ <screen>~]$ <command>nmcli conn show team-ServerA | grep team.config</command></screen>
</para>
<para>
- To add, or enslave, an interface to the team, with name <interface>team-slave-ens3</interface>, issue a command as follows:
+ To add an interface to the team, with name <interface>team-slave-ens3</interface>, issue a command as follows:
<screen>~]$ <command>nmcli connection add type team-slave ifname ens3 master Team0</command>
Connection 'team-slave-ens3' (a33d5d32-87d7-4dc4-8a27-5a44aabfa440) successfully added.</screen>
Notice that the name was derived from the interface name by prepending the type.
Alternatively, specify a name with <option>con-name</option> as follows:
- <screen>~]$ <command>nmcli con add type team-slave con-name Team0-slave1 ifname ens3 master Team0</command>
-Connection 'Team0-slave1' (adbf21f2-51b6-492f-8fc8-48b831383ac9) successfully added.
-~]$ <command>nmcli con add type team-slave con-name Team0-slave2 ifname ens7 master Team0</command>
-Connection 'Team0-slave2' (e5317075-c0c1-472f-b25d-0433b0297ea3) successfully added.</screen>
-At time of writing, <application>nmcli</application> only supports Ethernet slaves.
+ <screen>~]$ <command>nmcli con add type team-slave con-name Team0-port1 ifname ens3 master Team0</command>
+Connection 'Team0-port1' (adbf21f2-51b6-492f-8fc8-48b831383ac9) successfully added.
+~]$ <command>nmcli con add type team-slave con-name Team0-port2 ifname ens7 master Team0</command>
+Connection 'Team0-port2' (e5317075-c0c1-472f-b25d-0433b0297ea3) successfully added.</screen>
+At time of writing, <application>nmcli</application> only supports Ethernet ports.
</para>
<para>
- In order to bring up a team, the slaves must be brought up first as follows:
- <screen>~]$ <command>nmcli connection up Team0-slave1</command>
+ In order to bring up a team, the ports must be brought up first as follows:
+ <screen>~]$ <command>nmcli connection up Team0-port1</command>
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)</screen>
-<screen>~]$ <command>nmcli connection up Team0-slave2</command>
+<screen>~]$ <command>nmcli connection up Team0-port2</command>
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)</screen>
</para>
<para>
-You can verify the team interface was brought up by the activation of the slaves, as follows:
+You can verify the team interface was brought up by the activation of the ports, as follows:
<screen>~]$ <command>ip link</command>
3: Team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT
link/ether 52:54:00:76:6f:f0 brd ff:ff:ff:ff:ff:f</screen>
@@ -1178,7 +1204,7 @@ Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkMa
class="directory">/usr/share/doc/kernel-doc-<replaceable><kernel_version></replaceable>/Documentation/</filename> — This directory, which is provided by the <package>kernel-doc</package> package, contains information on bonding which is also relevant to teaming. Before accessing the kernel documentation, you must run the following command as <systemitem class="username">root</systemitem>:</para>
<screen>~]# <command>yum install kernel-doc</command></screen>
<para>
- <filename>/usr/share/doc/kernel-doc-<replaceable>version</replaceable>/Documentation/networking/multiqueue.txt</filename> — Describes kernel support for multiqueue devices.
+ <filename>/usr/share/doc/kernel-doc/Documentation/networking/multiqueue.txt</filename> — Describes kernel support for multiqueue devices.
</para>
</listitem>
</itemizedlist>
@@ -1189,7 +1215,7 @@ Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkMa
<para>
<variablelist>
<varlistentry>
-<term><ulink url="www.libteam.org"/></term>
+<term><ulink url="http://www.libteam.org"/></term>
<listitem>
<para>
The upstream project.
@@ -1198,7 +1224,7 @@ Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkMa
</varlistentry>
<varlistentry>
-<term><ulink url="www.w3schools.com/json/json_syntax.asp"/></term>
+<term><ulink url="http://www.w3schools.com/json/json_syntax.asp"/></term>
<listitem>
<para>
An explanation of JSON syntax.
9 years, 9 months
[networking-guide] master: Remove redundent check (d188033)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit d188033018eb18b6c191b85663e509dfab8eb6af
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Jul 21 23:13:05 2014 +0200
Remove redundent check
>---------------------------------------------------------------
en-US/Configure_Network_Teaming.xml | 9 +--------
1 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/en-US/Configure_Network_Teaming.xml b/en-US/Configure_Network_Teaming.xml
index 18112e6..75bad7c 100644
--- a/en-US/Configure_Network_Teaming.xml
+++ b/en-US/Configure_Network_Teaming.xml
@@ -132,17 +132,10 @@ The Team daemon, <systemitem class="daemon">teamd</systemitem>, uses <applicatio
</para>
</section>
<!--Topics, Tasks:-->
-<section id="sec-Check_if_the_Network_Teaming_Daemon_is_Installed">
- <title>Check if the Network Teaming Daemon is Installed</title>
- <para>
- To check if <systemitem class="daemon">teamd</systemitem> is installed, run the following command as <systemitem class="username">root</systemitem>:
- <screen>~]# <command>yum install teamd</command></screen>
- </para>
-</section>
<section id="sec-Install_the_Network_Teaming_Daemon">
<title>Install the Network Teaming Daemon</title>
<para>
- To install <systemitem class="daemon">teamd</systemitem>, run the following command as <systemitem class="username">root</systemitem>:
+ The networking teaming daemon, <systemitem class="daemon">teamd</systemitem>, is not installed by default. To install <systemitem class="daemon">teamd</systemitem>, issue the following command as <systemitem class="username">root</systemitem>:
<screen>~]# <command>yum install teamd</command></screen>
</para>
</section>
9 years, 9 months
[networking-guide] master: Correction: Link Aggregation Control Protocol (2f13774)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 2f13774f2b1ae3d3131580331c4a54f5e27050ea
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Jul 21 23:12:07 2014 +0200
Correction: Link Aggregation Control Protocol
>---------------------------------------------------------------
en-US/Configure_Network_Teaming.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/en-US/Configure_Network_Teaming.xml b/en-US/Configure_Network_Teaming.xml
index 9e19670..18112e6 100644
--- a/en-US/Configure_Network_Teaming.xml
+++ b/en-US/Configure_Network_Teaming.xml
@@ -104,7 +104,7 @@ The Team daemon, <systemitem class="daemon">teamd</systemitem>, uses <applicatio
</listitem>
<listitem>
<para>
- lacp (implements the 802.3ad Link Access Control Protocol)
+ lacp (implements the 802.3ad Link Aggregation Control Protocol)
</para>
</listitem>
</itemizedlist>
9 years, 9 months
[networking-guide] master: Add table id (5583c44)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 5583c44302cf9c0cfe297f40adb29ab2d7d49708
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Jul 21 23:02:45 2014 +0200
Add table id
A Comparison of Features in Bonding and Team
>---------------------------------------------------------------
en-US/Configure_Network_Teaming.xml | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/en-US/Configure_Network_Teaming.xml b/en-US/Configure_Network_Teaming.xml
index 4c4956a..9e19670 100644
--- a/en-US/Configure_Network_Teaming.xml
+++ b/en-US/Configure_Network_Teaming.xml
@@ -28,7 +28,8 @@
<section id="sec-Comparison_of_Network_Teaming_to_Bonding">
<title>Comparison of Network Teaming to Bonding</title>
- <table frame='all'><title>A Comparison of Features in Bonding and Team</title>
+ <table id="Bonding_Teaming_Comparison" frame='all'>
+ <title>A Comparison of Features in Bonding and Team</title>
<tgroup cols='3' align='left' colsep='1' rowsep='1'>
<colspec colname='c1'/>
<colspec colname='c2'/>
9 years, 9 months
[networking-guide] master: Team prefers port rather than slave interface (6eec07f)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 6eec07fc77443d7240e378c23e795997b7dbbcf8
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Jul 21 22:59:14 2014 +0200
Team prefers port rather than slave interface
>---------------------------------------------------------------
en-US/Configure_Network_Teaming.xml | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/en-US/Configure_Network_Teaming.xml b/en-US/Configure_Network_Teaming.xml
index 2059436..4c4956a 100644
--- a/en-US/Configure_Network_Teaming.xml
+++ b/en-US/Configure_Network_Teaming.xml
@@ -319,41 +319,41 @@ From the available interfaces, determine which are suitable for adding to your n
<section id="sec-Team-Understanding_the_Default_Behavior_of_Master_and_Slave_Interfaces">
<title>Understanding the Default Behavior of Master and Slave Interfaces</title>
<para>
-When controlling teamed slave interfaces using <systemitem class="daemon">NetworkManager</systemitem>, and especially when fault finding, keep the following in mind:
+When controlling teamed port interfaces using the <systemitem class="daemon">NetworkManager</systemitem> daemon, and especially when fault finding, keep the following in mind:
<orderedlist>
<listitem>
<para>
- Starting the master interface does not automatically start the slave interfaces.
+ Starting the master interface does not automatically start the port interfaces.
</para>
</listitem>
<listitem>
<para>
- Starting a slave interface always starts the master interface.
+ Starting a port interface always starts the master interface.
</para>
</listitem>
<listitem>
<para>
- Stopping the master interface also stops the slave interfaces.
+ Stopping the master interface also stops the port interfaces.
</para>
</listitem>
<listitem>
<para>
- A master without slaves can start static <systemitem class="protocol">IP</systemitem> connections.
+ A master without ports can start static <systemitem class="protocol">IP</systemitem> connections.
</para>
</listitem>
<listitem>
<para>
- A master without slaves waits for slaves when starting <systemitem class="protocol">DHCP</systemitem> connections.
+ A master without ports waits for ports when starting <systemitem class="protocol">DHCP</systemitem> connections.
</para>
</listitem>
<listitem>
<para>
- A master with a <systemitem class="protocol">DHCP</systemitem> connection waiting for slaves completes when a slave with a carrier is added.
+ A master with a <systemitem class="protocol">DHCP</systemitem> connection waiting for ports completes when a port with a carrier is added.
</para>
</listitem>
<listitem>
<para>
- A master with a <systemitem class="protocol">DHCP</systemitem> connection waiting for slaves continues waiting when a slave without a carrier is added.
+ A master with a <systemitem class="protocol">DHCP</systemitem> connection waiting for ports continues waiting when a port without a carrier is added.
</para>
</listitem>
</orderedlist>
9 years, 9 months
[networking-guide] master: Correction: JSON format configuration file (a113cab)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit a113cab211b9cb37a4144631891c3d2655551d62
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Jul 21 22:51:57 2014 +0200
Correction: JSON format configuration file
>---------------------------------------------------------------
en-US/Configure_Network_Teaming.xml | 50 +++++++++++++++++++++++------------
1 files changed, 33 insertions(+), 17 deletions(-)
diff --git a/en-US/Configure_Network_Teaming.xml b/en-US/Configure_Network_Teaming.xml
index 775eac7..2059436 100644
--- a/en-US/Configure_Network_Teaming.xml
+++ b/en-US/Configure_Network_Teaming.xml
@@ -669,7 +669,7 @@ To view the configuration of a port <interface>em1</interface>, that is part of
<section id="sec-Configure_the_broadcast_Runner">
<title>Configure the broadcast Runner</title>
<para>
- To configure the broadcast runner, using an editor as <systemitem class="username">root</systemitem>, add the following to the team <filename>ifcfg</filename> file:
+ To configure the broadcast runner, using an editor as <systemitem class="username">root</systemitem>, add the following to the team JSON format configuration file:
<screen>
{
"device": "team0",
@@ -677,7 +677,10 @@ To view the configuration of a port <interface>em1</interface>, that is part of
"ports": {"em1": {}, "em2": {}}
}</screen>
</para>
- </section>
+<para>
+Please see the <filename>teamd.conf(5)</filename> man page for more information.
+</para>
+</section>
<section id="sec-Configure_the_random_Runner">
<title>Configure the random Runner</title>
@@ -685,7 +688,7 @@ To view the configuration of a port <interface>em1</interface>, that is part of
The random runner behaves similarly to the roundrobin runner, but it does not do percentage calculations and therefore uses less system resources.
</para>
<para>
- To configure the random runner, using an editor as <systemitem class="username">root</systemitem>, add the following to the team <filename>ifcfg</filename> file:
+ To configure the random runner, using an editor as <systemitem class="username">root</systemitem>, add the following to the team JSON format configuration file:
<screen>
{
"device": "team0",
@@ -693,12 +696,15 @@ To view the configuration of a port <interface>em1</interface>, that is part of
"ports": {"em1": {}, "em2": {}}
}</screen>
</para>
- </section>
+<para>
+Please see the <filename>teamd.conf(5)</filename> man page for more information.
+</para>
+</section>
<section id="sec-Configure_the_roundrobin_Runner">
<title>Configure the roundrobin Runner</title>
<para>
- To configure the roundrobin runner, using an editor as <systemitem class="username">root</systemitem>, add the following to the team <filename>ifcfg</filename> file:
+ To configure the roundrobin runner, using an editor as <systemitem class="username">root</systemitem>, add the following to the team JSON format configuration file:
<screen>
{
"device": "team0",
@@ -707,12 +713,14 @@ To view the configuration of a port <interface>em1</interface>, that is part of
}</screen>
A very basic configuration for roundrobin.
</para>
-
+<para>
+Please see the <filename>teamd.conf(5)</filename> man page for more information.
+</para>
</section>
<section id="sec-Configure_the_activebackup_Runner">
<title>Configure the activebackup Runner</title>
<para>
- The active backup runner can use all of the link-watchers to determine the status of links in a team. Any one of the following examples can be added to the team <filename>ifcfg</filename> file:
+ The active backup runner can use all of the link-watchers to determine the status of links in a team. Any one of the following examples can be added to the team JSON format configuration file:
</para>
<para>
<screen>
@@ -762,7 +770,7 @@ To view the configuration of a port <interface>em1</interface>, that is part of
</para>
<para>
- To configure the activebackup runner using <application>ethtool</application> as the link watcher and applying a delay, using an editor as <systemitem class="username">root</systemitem>, add the following to the team <filename>ifcfg</filename> file:
+ To configure the activebackup runner using <application>ethtool</application> as the link watcher and applying a delay, using an editor as <systemitem class="username">root</systemitem>, add the following to the team JSON format configuration file:
<screen>
{
"device": "team0",
@@ -786,7 +794,9 @@ To view the configuration of a port <interface>em1</interface>, that is part of
}</screen>
This example configuration uses the active-backup runner with <application>ethtool</application> as the link watcher. Port <interface>em2</interface> has higher priority. But the sticky flag ensures that if <interface>em1</interface> becomes active, it stays active while the link remains up. Link changes are not propagated to the runner immediately, but delays are applied.
</para>
-
+<para>
+Please see the <filename>teamd.conf(5)</filename> man page for more information.
+</para>
</section>
<section id="sec-Configure_the_loadbalance_Runner">
<title>Configure the loadbalance Runner</title>
@@ -794,7 +804,7 @@ To view the configuration of a port <interface>em1</interface>, that is part of
This runner can be used for two types of load balancing, active and passive. In active mode, constant re-balancing of traffic is done by using statistics of recent traffic to share out traffic as evenly as possible. In static mode, streams of traffic are distributed randomly across the available links. This has a speed advantage due to lower processing overhead. In high volume traffic applications this is often preferred as traffic usually consists of multiple stream which will be distributed randomly between the available links, in his way load sharing is accomplished without intervention by <systemitem class="daemon">teamd</systemitem>.
</para>
<para>
- To configure the loadbalance runner for passive transmit (Tx) load balancing, using an editor as <systemitem class="username">root</systemitem>, add the following to the team <filename>ifcfg</filename> file:
+ To configure the loadbalance runner for passive transmit (Tx) load balancing, using an editor as <systemitem class="username">root</systemitem>, add the following to the team JSON format configuration file:
<screen>
{
"device": "team0",
@@ -808,7 +818,7 @@ To view the configuration of a port <interface>em1</interface>, that is part of
</para>
<para>
- To configure the loadbalance runner for active transmit (Tx) load balancing, using an editor as <systemitem class="username">root</systemitem>, add the following to the team <filename>ifcfg</filename> file:
+ To configure the loadbalance runner for active transmit (Tx) load balancing, using an editor as <systemitem class="username">root</systemitem>, add the following to the team JSON format configuration file:
<screen>
{
"device": "team0",
@@ -823,13 +833,15 @@ To view the configuration of a port <interface>em1</interface>, that is part of
}</screen>
Configuration for active transmit (Tx) load balancing using basic load balancer.
</para>
-
+<para>
+Please see the <filename>teamd.conf(5)</filename> man page for more information.
+</para>
</section>
<section id="sec-Configure_the_LACP_Runner">
<title>Configure the LACP (802.3ad) Runner</title>
<para>
- To configure the LACP runner using <application>ethtool</application> as a link watcher, using an editor as <systemitem class="username">root</systemitem>, add the following to the team <filename>ifcfg</filename> file:
+ To configure the LACP runner using <application>ethtool</application> as a link watcher, using an editor as <systemitem class="username">root</systemitem>, add the following to the team JSON format configuration file:
<screen>
{
"device": "team0",
@@ -844,18 +856,20 @@ To view the configuration of a port <interface>em1</interface>, that is part of
}</screen>
Configuration for connection to a <firstterm>link access control protocol</firstterm> (<acronym>LACP</acronym>) capable counterpart. The LACP runner should use <application>ethtool</application> to monitor the status of a link. It does not make sense to use any other link monitoring method besides the <application>ethtool</application> because, for example in the case of <application>arp_ping</application>, the link would never come up. The reason is that the link has to be established first and only after that can packets, ARP included, go through. Using <application>ethtool</application> prevents this because it monitors each link layer individually.</para>
<para>
- Active load balancing is possible with this runner in the same why as it is done for the loadbalance runner. To enable active transmit (Tx) load balancing, add the following section:
+ Active load balancing is possible with this runner in the same way as it is done for the loadbalance runner. To enable active transmit (Tx) load balancing, add the following section:
<screen>"tx_balancer": {
"name": "basic"
}</screen>
</para>
+<para>
+Please see the <filename>teamd.conf(5)</filename> man page for more information.
+</para>
</section>
-
<section id="sec-Configure_Monitoring_of_the_Link_State">
<title>Configure Monitoring of the Link State</title>
<para>
- The following methods of link state monitoring are available. To implement one of the methods, add the JSON format string to the team <filename>ifcfg</filename> file using an editor running with <systemitem class="username">root</systemitem> privileges.
+ The following methods of link state monitoring are available. To implement one of the methods, add the JSON format string to the team JSON format configuration file using an editor running with <systemitem class="username">root</systemitem> privileges.
</para>
<section id="sec-Configure_Ethtool_for_Link-state_Monitoring">
<title>Configure Ethtool for link-state Monitoring</title>
@@ -967,7 +981,9 @@ To view the configuration of a port <interface>em1</interface>, that is part of
}</screen>
Host name to be converted to an <systemitem class="protocol">IPv6</systemitem> address which will be used as the target address for the NS/NA packets. An <systemitem class="protocol">IPv6</systemitem> address can be used in place of a host name.
</para>
-
+<para>
+Please see the <filename>teamd.conf(5)</filename> man page for more information.
+</para>
</section>
</section>
9 years, 9 months
[networking-guide] master: Team: typos and style updates (943410b)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 943410bb2a11a10060c6d1aa1d52f3eb66ce62da
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Jul 21 22:50:22 2014 +0200
Team: typos and style updates
>---------------------------------------------------------------
en-US/Configure_Network_Teaming.xml | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/en-US/Configure_Network_Teaming.xml b/en-US/Configure_Network_Teaming.xml
index 741170e..775eac7 100644
--- a/en-US/Configure_Network_Teaming.xml
+++ b/en-US/Configure_Network_Teaming.xml
@@ -12,7 +12,7 @@
The combining or aggregating together of network links in order to provide a logical link with higher throughput, or to provide redundancy, is known by many names such as <quote>channel bonding</quote>, <quote>Ethernet bonding</quote>, <quote>port trunking</quote>, <quote>channel teaming</quote>, <quote>NIC teaming</quote>, <quote>link aggregation</quote>, and so on. This concept as originally implemented in the Linux kernel is widely referred to as <quote>bonding</quote>. The term Network Teaming has been chosen to refer to this new implementation of the concept. The existing bonding driver is unaffected, Network Teaming is offered as an alternative and does not replace bonding in <application>Fedora</application>.
</para>
<para>
- Network Teaming, or Team, is designed to implement the concept in a different way by providing a small kernel driver to implement the fast handling of packet flows, and various user-space applications to do everything else in user space. The driver has an <firstterm>Application Programming Interface</firstterm> (<acronym>API</acronym>), referred to as <quote>Team Netlink API</quote>, which implements Netlink communications. User-space applications can use this API to communication with the driver. A library, referred to as <quote>lib</quote>, has been provided to do user space wrapping of Team Netlink communications and RT Netlink messages. An application daemon, <systemitem class="daemon">teamd</systemitem>, which uses Libteam lib is also provided. One instance of <systemitem class="daemon">teamd</systemitem> can control one instance of the Team driver. The daemon implements the load-balancing and active-backup logic, such as round-robin, by using additional code refer
red to as <quote>runners</quote>. By separating the code in this way, the Network Teaming implementation presents an easily extensible and scalable solution for load-balancing and redundancy requirements. For example, custom runners can be relatively easily written to implement new logic via <systemitem class="daemon">teamd</systemitem>, and even <systemitem class="daemon">teamd</systemitem> is optional, users can write their own application to use <application>libteam</application>.
+ Network Teaming, or Team, is designed to implement the concept in a different way by providing a small kernel driver to implement the fast handling of packet flows, and various user-space applications to do everything else in user space. The driver has an <firstterm>Application Programming Interface</firstterm> (<acronym>API</acronym>), referred to as <quote>Team Netlink API</quote>, which implements Netlink communications. User-space applications can use this API to communicate with the driver. A library, referred to as <quote>lib</quote>, has been provided to do user space wrapping of Team Netlink communications and RT Netlink messages. An application daemon, <systemitem class="daemon">teamd</systemitem>, which uses Libteam lib is also provided. One instance of <systemitem class="daemon">teamd</systemitem> can control one instance of the Team driver. The daemon implements the load-balancing and active-backup logic, such as round-robin, by using additional code referre
d to as <quote>runners</quote>. By separating the code in this way, the Network Teaming implementation presents an easily extensible and scalable solution for load-balancing and redundancy requirements. For example, custom runners can be relatively easily written to implement new logic via <systemitem class="daemon">teamd</systemitem>, and even <systemitem class="daemon">teamd</systemitem> is optional, users can write their own application to use <application>libteam</application>.
</para>
<para>
A tool to control a running instance of <systemitem class="daemon">teamd</systemitem> using D-bus is provided by <application>teamdctl</application>. It provides a D-Bus wrapper around the <systemitem class="daemon">teamd</systemitem> D-Bus API. By default, <systemitem class="daemon">teamd</systemitem> listens and communicates using Unix Domain Sockets but still monitors D-Bus. This is to insure that <systemitem class="daemon">teamd</systemitem> can be used in environments where D-Bus is not present or not yet loaded. For example, when booting over <systemitem class="daemon">teamd</systemitem> links D-Bus would not yet be loaded. The <application>teamdctl</application> tool can be used during run time to read the configuration, the state of link-watchers, check and change the state of ports, add and remove ports, and to change ports between active and backup states.
@@ -76,7 +76,7 @@
<section id="sec-Understanding_the_Network_Teaming_Daemon_and_the_Runners">
<title>Understanding the Network Teaming Daemon and the "Runners"</title>
<para>
-The Team daemon, <systemitem class="daemon">teamd</systemitem>, uses <application>libteam</application> to control one instance of the team driver. This instance of the team driver enslaves instances of a hardware device driver to form a <quote>team</quote> of network links. The team driver presents a network interface, <interface>team0</interface> for example, to the other parts of the kernel. The interfaces created by instances of the team driver are given names such as <interface>team0</interface>, <interface>team1</interface>, and so forth in the documentation. This is for ease of understanding and other names can be used. The logic common to all methods of teaming is implemented by <systemitem class="daemon">teamd</systemitem> and those functions that are unique to the different load sharing and backup methods, such as round-robin, are implemented by separate units of code referred to as <quote>runners</quote>. Because words such as <quote>module</quote> and <quote>mode
</quote> already have specific meanings in relation to the kernel, the word <quote>runner</quote> was chosen to refer to these units of code. The user specifies the runner in the <filename>teamd.conf</filename> file and the code is then compiled into an instance of <systemitem class="daemon">teamd</systemitem> when the instance is created. As the code for a <quote>runner</quote> is compiled into an instance of <systemitem class="daemon">teamd</systemitem> as it is being created, the code for a <quote>runner</quote> is not a plug-in, although code could be created as a plug-in for <systemitem class="daemon">teamd</systemitem> should the need arise.
+The Team daemon, <systemitem class="daemon">teamd</systemitem>, uses <application>libteam</application> to control one instance of the team driver. This instance of the team driver adds instances of a hardware device driver to form a <quote>team</quote> of network links. The team driver presents a network interface, <interface>team0</interface> for example, to the other parts of the kernel. The interfaces created by instances of the team driver are given names such as <interface>team0</interface>, <interface>team1</interface>, and so forth in the documentation. This is for ease of understanding and other names can be used. The logic common to all methods of teaming is implemented by <systemitem class="daemon">teamd</systemitem>; those functions that are unique to the different load sharing and backup methods, such as round-robin, are implemented by separate units of code referred to as <quote>runners</quote>. Because words such as <quote>module</quote> and <quote>mode</quote
> already have specific meanings in relation to the kernel, the word <quote>runner</quote> was chosen to refer to these units of code. The user specifies the runner in the JSON format configuration file and the code is then compiled into an instance of <systemitem class="daemon">teamd</systemitem> when the instance is created. A runner is not a plug-in because the code for a runner is compiled into an instance of <systemitem class="daemon">teamd</systemitem> as it is being created. Code could be created as a plug-in for <systemitem class="daemon">teamd</systemitem> should the need arise.
</para>
<para>
The following runners are available at time of writing.
@@ -127,7 +127,7 @@ The Team daemon, <systemitem class="daemon">teamd</systemitem>, uses <applicatio
</para>
</listitem>
</itemizedlist>
- There are no restrictions in the code to prevent a particular link-watcher from being used with a particular runner, however when using the <application>lacp</application> runner, <application>ethtool</application> is the only recommend link-watcher.
+ There are no restrictions in the code to prevent a particular link-watcher from being used with a particular runner, however when using the <application>lacp</application> runner, <application>ethtool</application> is the only recommended link-watcher.
</para>
</section>
<!--Topics, Tasks:-->
@@ -397,7 +397,7 @@ activebackup_ethtool_3.conf loadbalance_1.conf roundrobin.conf</sc
Make any necessary changes and save the file. See the <filename>vi(1)</filename> man page for help on using the <application>vi</application> editor or use your preferred editor.
</para>
<para>
- Note that it is essential that the interfaces to be used as ports within the team must not be active, that is to say, they must be <quote>down</quote>, when enslave them into a team device. To check their status, issue the following command:
+ Note that it is essential that the interfaces to be used as ports within the team must not be active, that is to say, they must be <quote>down</quote>, when adding them into a team device. To check their status, issue the following command:
<screen>~]$ <command>ip link show</command>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
@@ -511,7 +511,7 @@ NM_CONTROLLED="no"</screen>
Add additional slave interfaces similar to the above as required, changing the DEVICE and HWADDR field to match the ports (the network devices) being enslaved. If port priority is not specified by <literal>prio</literal> it defaults to <literal>0</literal>; it accepts negative and positive values in the range <literal>-32,767</literal> to <literal>+32,767</literal>.
</para>
<para>
- Specifying the hardware or MAC address using the <command>HWADDR</command> directive will influence the device naming procedure as explained in <xref linkend="ch-Consistent_Network_Device_Naming" />.
+ Specifying the hardware or MAC address using the <command>HWADDR</command> directive will influence the device naming procedure. This is explained in <xref linkend="ch-Consistent_Network_Device_Naming" />.
</para>
@@ -566,7 +566,7 @@ em1: up 100 fullduplex</screen>
<section id="sec-Bring_Up_an_interface_to_a_Network_Team_Using_iputils">
<title>Bring up an Interface to a Network Team Using iputils</title>
<para>
- To active or <quote>bring up</quote> an interface to a network team, <interface>team0</interface>, using the <application>ip</application> utility, issue the following command as <systemitem class="username">root</systemitem>:
+ To activate or <quote>bring up</quote> an interface to a network team, <interface>team0</interface>, using the <application>ip</application> utility, issue the following command as <systemitem class="username">root</systemitem>:
<screen>~]# <command>ip link set team0 up</command></screen>
</para>
</section>
9 years, 9 months