[networking-guide] 21: VLAN over a Bond (4ea023f)
stephenw at fedoraproject.org
stephenw at fedoraproject.org
Fri Feb 6 06:46:26 UTC 2015
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : 21
>---------------------------------------------------------------
commit 4ea023f31fe10ce3f94700e8d977b52e9fc956b8
Author: Stephen Wadeley <swadeley at redhat.com>
Date: Fri Feb 6 07:45:38 2015 +0100
VLAN over a Bond
>---------------------------------------------------------------
en-US/Configure_Network_Bonding.xml | 354 ++++++++++++++++++++++++++++++++++-
1 files changed, 353 insertions(+), 1 deletions(-)
diff --git a/en-US/Configure_Network_Bonding.xml b/en-US/Configure_Network_Bonding.xml
index 59632d7..42346ce 100644
--- a/en-US/Configure_Network_Bonding.xml
+++ b/en-US/Configure_Network_Bonding.xml
@@ -505,6 +505,359 @@ BONDING_OPTS="<replaceable>bonding parameters separated by spaces</replaceable>"
<para>
Create the interfaces to be bonded as per <xref linkend="ex-Example_Slave_Interface_Configuration_File" /> and assign them to the bond interfaces as required using the <command>MASTER=bond<replaceable>N</replaceable></command> directive. For example, continuing on from the example above, if two interfaces per bond are required, then for two bonds create four interface configuration files and assign the first two using <command>MASTER=bond<replaceable>0</replaceable></command> and the next two using <command>MASTER=bond<replaceable>1</replaceable></command>.</para>
</section>
+
+ <section id="sec-Configuring_a_VLAN_over_a_Bond">
+ <title>Configuring a VLAN over a Bond</title>
+
+ <para>
+ This section will show configuring a VLAN over a bond consisting of two Ethernet links between a server and an Ethernet switch. The switch has a second bond to another server. Only the configuration for the first server will be shown as the other is essentially the same apart from the <systemitem class="protocol">IP</systemitem> addresses.</para>
+ <warning>
+ <para>
+ The use of direct cable connections without network switches is not supported for bonding. The failover mechanisms described here will not work as expected without the presence of network switches.
+ </para>
+</warning>
+
+ <note>
+ <para>
+ The active-backup, balance-tlb and balance-alb modes do not require any specific configuration of the switch. Other bonding modes require configuring the switch to aggregate the links. For example, a Cisco switch requires EtherChannel for Modes 0, 2, and 3, but for Mode 4 LACP and EtherChannel are required. See the documentation supplied with your switch and see <ulink url="https://www.kernel.org/doc/Documentation/networking/bonding.txt">https://www.kernel.org/doc/Documentation/networking/bonding.txt</ulink><!--the <filename>bonding.txt</filename> file in the <package>kernel-doc</package> package (see <xref linkend="s1-kernel-modules-additional-resources"/>)-->.
+ </para>
+ </note>
+
+<para>
+Check the available interfaces on the server:
+<screen>~]$ <command>ip addr</command><![CDATA[
+1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
+ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+ inet 127.0.0.1/8 scope host lo
+ inet6 ::1/128 scope host
+ valid_lft forever preferred_lft forever
+2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
+ link/ether 52:54:00:19:28:fe brd ff:ff:ff:ff:ff:ff
+3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
+ link/ether 52:54:00:f6:63:9a brd ff:ff:ff:ff:ff:ff]]></screen>
+</para>
+
+<procedure id="proc-Configuring_the_Interfaces_on_the_Workstation">
+<title>Configuring the Interfaces on the Server</title>
+
+ <step>
+<para>
+ Configure a slave interface using <literal>eth0</literal>:
+ <screen>~]# <command>vi /etc/sysconfig/network-scripts/ifcfg-eth0</command>
+NAME=bond0-slave0
+DEVICE=eth0
+TYPE=Ethernet
+BOOTPROTO=none
+ONBOOT=yes
+MASTER=bond0
+SLAVE=yes</screen>
+The use of the NAME directive is optional. It is for display by a GUI interface, such as <application>nm-connection-editor</application>.
+</para>
+</step>
+
+<step>
+<para>
+ Configure a slave interface using <literal>eth1</literal>:
+ <screen>~]# <command>vi /etc/sysconfig/network-scripts/ifcfg-eth1</command>
+NAME=bond0-slave1
+DEVICE=eth1
+TYPE=Ethernet
+BOOTPROTO=none
+ONBOOT=yes
+MASTER=bond0
+SLAVE=yes</screen>
+The use of the NAME directive is optional. It is for display by a GUI interface, such as <application>nm-connection-editor</application>.
+</para>
+</step>
+
+<step>
+ <para>
+ Configure a channel bonding interface <literal>ifcfg-bond0</literal>:
+ <screen>~]# <command>vi /etc/sysconfig/network-scripts/ifcfg-bond0</command>
+NAME=bond0
+DEVICE=bond0
+BONDING_MASTER=yes
+TYPE=Bond
+IPADDR=192.168.100.100
+NETMASK=255.255.255.0
+ONBOOT=yes
+BOOTPROTO=none
+BONDING_OPTS="mode=active-backup miimon=100"</screen>
+The use of the NAME directive is optional. It is for display by a GUI interface, such as <application>nm-connection-editor</application>. In this example MII is used for link monitoring, see the <xref linkend="s3-modules-bonding-directives" /> section for more information on link monitoring.
+ </para>
+ </step>
+
+ <step>
+ <para>
+ Check the status of the interfaces on the server:
+ <screen>~]$ <command>ip addr</command><![CDATA[
+1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
+ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+ inet 127.0.0.1/8 scope host lo
+ inet6 ::1/128 scope host
+ valid_lft forever preferred_lft forever
+2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
+ link/ether 52:54:00:19:28:fe brd ff:ff:ff:ff:ff:ff
+ inet6 fe80::5054:ff:fe19:28fe/64 scope link
+ valid_lft forever preferred_lft forever
+3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
+ link/ether 52:54:00:f6:63:9a brd ff:ff:ff:ff:ff:ff
+ inet6 fe80::5054:ff:fef6:639a/64 scope link
+ valid_lft forever preferred_lft forever]]></screen>
+ </para>
+ </step>
+
+ </procedure>
+
+ <procedure id="proc-Resolving_Conflicts_with_Interfaces">
+ <title>Resolving Conflicts with Interfaces</title>
+<para>
+ The interfaces configured as slaves should not have <systemitem class="protocol">IP</systemitem> addresses assigned to them apart from the <systemitem class="protocol">IPv6</systemitem> link-local addresses (starting <literal>fe80</literal>). If you have an unexpected <systemitem class="protocol">IP</systemitem> address, then there may be another configuration file with ONBOOT set to <literal>yes</literal>.</para>
+ <step>
+ <para>
+ If this occurs, issue the following command to list all <filename>ifcfg</filename> files that may be causing a conflict:
+<screen>~]$ <command>grep -r "ONBOOT=yes" /etc/sysconfig/network-scripts/ | cut -f1 -d":" | xargs grep -E "IPADDR|SLAVE"</command>
+/etc/sysconfig/network-scripts/ifcfg-lo:IPADDR=127.0.0.1</screen>
+The above shows the expected result on a new installation. Any file having both the ONBOOT directive as well as the IPADDR or SLAVE directive will be displayed. For example, if the <literal>ifcfg-eth1</literal> file was incorrectly configured, the display might look similar to the following:
+<screen>~]# <command>grep -r "ONBOOT=yes" /etc/sysconfig/network-scripts/ | cut -f1 -d":" | xargs grep -E "IPADDR|SLAVE"</command>
+/etc/sysconfig/network-scripts/ifcfg-lo:IPADDR=127.0.0.1
+/etc/sysconfig/network-scripts/ifcfg-eth1:SLAVE=yes
+/etc/sysconfig/network-scripts/ifcfg-eth1:IPADDR=192.168.55.55</screen></para>
+</step>
+<step>
+<para>
+Any other configuration files found should be moved to a different directory for backup, or assigned to a different interface by means of the HWADDR directive. After resolving any conflict set the interfaces <quote>down</quote> and <quote>up</quote> again or restart the network service as <systemitem class="username">root</systemitem>:
+<screen>~]# <command>systemctl restart network</command>
+Shutting down interface bond0: [ OK ]
+Shutting down loopback interface: [ OK ]
+Bringing up loopback interface: [ OK ]
+Bringing up interface bond0: Determining if ip address 192.168.100.100 is already in use for device bond0...
+ [ OK ]</screen>
+If you are using <application>NetworkManager</application>, you might need to restart it at this point to make it forget the unwanted <systemitem class="protocol">IP</systemitem> address. As <systemitem class="username">root</systemitem>:
+<screen>~]# <command>systemctl restart NetworkManager</command></screen>
+ </para>
+ </step>
+
+ </procedure>
+
+
+<procedure id="proc-Checking_the_bond_on_the_Server">
+ <title>Checking the bond on the Server</title>
+
+<step>
+<para>
+Bring up the bond on the server as <systemitem class="username">root</systemitem>:
+<screen>~]# <command>ifup /etc/sysconfig/network-scripts/ifcfg-bond0</command>
+Determining if ip address 192.168.100.101 is already in use for device bond0...</screen>
+</para>
+</step>
+
+ <step>
+ <para>
+ Check the status of the interfaces on the server:
+ <screen>~]$ <command>ip addr</command>
+1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
+ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+ inet 127.0.0.1/8 scope host lo
+ inet6 ::1/128 scope host
+ valid_lft forever preferred_lft forever
+2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast <computeroutput>master bond0 state UP</computeroutput> qlen 1000
+ link/ether 52:54:00:19:28:fe brd ff:ff:ff:ff:ff:ff
+3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast <computeroutput>master bond0 state UP</computeroutput> qlen 1000
+ link/ether 52:54:00:f6:63:9a brd ff:ff:ff:ff:ff:ff
+4: bond0: <BROADCAST,MULTICAST,<computeroutput>MASTER,UP</computeroutput>,LOWER_UP> mtu 1500 qdisc noqueue state UP
+ link/ether 52:54:00:19:28:fe brd ff:ff:ff:ff:ff:ff
+ inet 192.168.100.100/24 brd 192.168.100.255 scope global bond0
+ inet6 fe80::5054:ff:fe19:28fe/64 scope link
+ valid_lft forever preferred_lft forever</screen>
+ Notice that <literal>eth0</literal> and <literal>eth1</literal> have <computeroutput>master bond0 state UP</computeroutput> and <literal>bond0</literal> has status of <computeroutput>MASTER,UP</computeroutput>.
+ </para>
+ </step>
+
+ <step>
+ <para>
+View the bond configuration details:
+ <screen>~]$ <command>cat /proc/net/bonding/bond0</command>
+Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)
+
+Bonding Mode: transmit load balancing
+Primary Slave: None
+Currently Active Slave: eth0
+MII Status: up
+MII Polling Interval (ms): 100
+Up Delay (ms): 0
+Down Delay (ms): 0
+
+Slave Interface: eth0
+MII Status: up
+Speed: 100 Mbps
+Duplex: full
+Link Failure Count: 0
+Permanent HW addr: 52:54:00:19:28:fe
+Slave queue ID: 0
+
+Slave Interface: eth1
+MII Status: up
+Speed: 100 Mbps
+Duplex: full
+Link Failure Count: 0
+Permanent HW addr: 52:54:00:f6:63:9a
+Slave queue ID: 0</screen>
+</para>
+</step>
+
+<step>
+<para>
+Check the routes on the server:
+<screen>~]$ <command>ip route</command>
+192.168.100.0/24 dev bond0 proto kernel scope link src 192.168.100.100
+169.254.0.0/16 dev bond0 scope link metric 1004</screen>
+ </para>
+ </step>
+
+ </procedure>
+
+<procedure id="proc-Configuring_the_VLAN_on_the_Server">
+<title>Configuring the VLAN on the Server</title>
+
+
+<note>
+<para>
+A VLAN slave cannot be configured on a bond with the <option>fail_over_mac=follow</option> option, because the VLAN virtual device cannot change its MAC address to match the parent's new MAC address. In such a case, traffic would still be sent with the now incorrect source MAC address.</para>
+<para>
+Some older network interface cards, loopback interfaces, Wimax cards, and some Infiniband devices, are said to be <firstterm>VLAN challenged</firstterm>, meaning they cannot support VLANs. This is usually because the devices cannot cope with VLAN headers and the larger MTU size associated with VLANs.
+</para>
+</note>
+
+<step>
+<para>
+Create a VLAN interface file <literal>bond0.192</literal>:
+<screen>~]# <command>vi /etc/sysconfig/network-scripts/ifcfg-bond0.192</command>
+DEVICE=bond0.192
+NAME=bond0.192
+BOOTPROTO=none
+ONPARENT=yes
+IPADDR=192.168.10.1
+NETMASK=255.255.255.0
+VLAN=yes</screen>
+</para>
+</step>
+
+<step>
+<para>
+Bring up the VLAN interface as <systemitem class="username">root</systemitem>:
+<screen>~]# <command>ifup /etc/sysconfig/network-scripts/ifcfg-bond0.192</command>
+Determining if ip address 192.168.10.1 is already in use for device bond0.192...</screen>
+</para>
+</step>
+
+<step>
+ <para>
+ Enabling VLAN tagging on the network switch. Consult the documentation for the switch to see what configuration is required.
+ </para>
+</step>
+
+<step>
+<para>
+Check the status of the interfaces on the server:
+<screen>~]# <command>ip addr</command>
+1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
+ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+ inet 127.0.0.1/8 scope host lo
+ inet6 ::1/128 scope host
+ valid_lft forever preferred_lft forever
+2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
+ link/ether 52:54:00:19:28:fe brd ff:ff:ff:ff:ff:ff
+3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
+ link/ether 52:54:00:f6:63:9a brd ff:ff:ff:ff:ff:ff
+4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
+ link/ether 52:54:00:19:28:fe brd ff:ff:ff:ff:ff:ff
+ inet 192.168.100.100/24 brd 192.168.100.255 scope global bond0
+ inet6 fe80::5054:ff:fe19:28fe/64 scope link
+ valid_lft forever preferred_lft forever
+5: <computeroutput>bond0.192 at bond0</computeroutput>: <BROADCAST,MULTICAST,<computeroutput>MASTER,UP</computeroutput>,LOWER_UP> mtu 1500 qdisc noqueue state UP
+ link/ether 52:54:00:19:28:fe brd ff:ff:ff:ff:ff:ff
+ inet 192.168.10.1/24 brd 192.168.10.255 scope global bond0.192
+ inet6 fe80::5054:ff:fe19:28fe/64 scope link
+ valid_lft forever preferred_lft forever</screen>
+Notice there is now <literal>bond0.192 at bond0</literal> in the list of interfaces and the status is <computeroutput>MASTER,UP</computeroutput>.
+ </para>
+ </step>
+
+ <step>
+ <para>
+ Check the route on the server:
+ <screen>~]$ <command>ip route</command>
+192.168.100.0/24 dev bond0 proto kernel scope link src 192.168.100.100
+192.168.10.0/24 dev <computeroutput>bond0.192</computeroutput> proto kernel scope link src 192.168.10.1
+169.254.0.0/16 dev bond0 scope link metric 1004
+169.254.0.0/16 dev bond0.192 scope link metric 1005</screen>
+Notice there is now a route for the <systemitem class="ipaddress">192.168.10.0/24</systemitem> network pointing to the VLAN interface <literal>bond0.192</literal>.
+ </para>
+ </step>
+
+ </procedure>
+
+
+<bridgehead id="bh-Configuring_the_Second_Server">Configuring the Second Server</bridgehead>
+
+<para>
+ Repeat the configuration steps for the second server, using different <systemitem class="protocol">IP</systemitem> addresses but from the same subnets respectively.
+</para>
+
+<para>
+ Test the bond is up and the network switch is working as expected:
+ <screen>~]$ <command>ping -c4 192.168.100.100</command>
+PING 192.168.100.100 (192.168.100.100) 56(84) bytes of data.
+64 bytes from 192.168.100.100: icmp_seq=1 ttl=64 time=1.35 ms
+64 bytes from 192.168.100.100: icmp_seq=2 ttl=64 time=0.214 ms
+64 bytes from 192.168.100.100: icmp_seq=3 ttl=64 time=0.383 ms
+64 bytes from 192.168.100.100: icmp_seq=4 ttl=64 time=0.396 ms
+
+--- 192.168.100.100 ping statistics ---
+4 packets transmitted, 4 received, 0% packet loss, time 3002ms
+rtt min/avg/max/mdev = 0.214/0.586/1.353/0.448 ms</screen>
+</para>
+
+<bridgehead id="bh-Testing_the_VLAN">Testing the VLAN</bridgehead>
+
+<para>
+To test that the network switch is configured for the VLAN, try to ping the first servers' VLAN interface:
+<screen>~]# <command>ping -c2 192.168.10.1</command>
+PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
+64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=0.781 ms
+64 bytes from 192.168.10.1: icmp_seq=2 ttl=64 time=0.977 ms
+--- 192.168.10.1 ping statistics ---
+2 packets transmitted, 2 received, <literal>0% packet loss</literal>, time 1001ms
+rtt min/avg/max/mdev = 0.781/0.879/0.977/0.098 ms</screen>
+ No packet loss suggests everything is configured correctly and that the VLAN and underlying interfaces are <quote>up</quote>.
+ </para>
+
+<bridgehead id="bh-Optional_Steps">Optional Steps</bridgehead>
+
+<itemizedlist>
+ <listitem>
+ <para>
+ If required, perform further tests by removing and replacing network cables one at a time to verify that failover works as expected. Make use the of <application>ethtool</application> to verify which interface is connected to which cable. For example:
+
+ <synopsis>ethtool <option>--identify</option> <replaceable>ifname</replaceable> <replaceable>integer</replaceable></synopsis>
+ Where <replaceable>integer</replaceable> is the number of times to flash the LED on the network interface.
+</para>
+ </listitem>
+ <listitem>
+ <para>
+ The bonding module does not support <systemitem class="protocol">STP</systemitem>, therefore consider disabling the sending of BPDU packets from the network switch.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ If the system is not linked to the network except over the connection just configured, consider enabling the switch port to transition directly to sending and receiving. For example on a Cisco switch, by means of the <literal>portfast</literal> command.
+ </para>
+ </listitem>
+</itemizedlist>
+
+ </section>
+
</section>
<section
@@ -984,7 +1337,6 @@ This policy is useful for devices that cannot ever alter their MAC address, or f
</section>
</section>
-
<section id="sec-Network_Bonding_Using_the_NetworkManager_Command_Line_Tool_nmcli">
<title>Using the NetworkManager Command Line Tool, nmcli</title>
<para>
More information about the docs-commits
mailing list