此内容没有您所选择的语言版本。
11.2.5. Configuring a VLAN over a Bond
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
IP
addresses.
Warning
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. See the Red Hat Knowledgebase article Why is bonding in not supported with direct connection using crossover cables? for more information.
Note
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 the
bonding.txt
file in the kernel-doc package (see Section 31.9, “Additional Resources”).
Check the available interfaces on the server:
Copy to Clipboard
Copied!
Toggle word wrap
Toggle overflow
Procedure 11.1. Configuring the Interfaces on the Server
- Configure a slave interface using
eth0
:The use of the NAME directive is optional. It is for display by a GUI interface, such as nm-connection-editor and nm-applet.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Configure a slave interface using
eth1
:The use of the NAME directive is optional. It is for display by a GUI interface, such as nm-connection-editor and nm-applet.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Configure a channel bonding interface
ifcfg-bond0
:The use of the NAME directive is optional. It is for display by a GUI interface, such as nm-connection-editor and nm-applet. In this example MII is used for link monitoring, see the Section 31.8.1.1, “Bonding Module Directives” section for more information on link monitoring.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Check the status of the interfaces on the server:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Procedure 11.2. Resolving Conflicts with Interfaces
The interfaces configured as slaves should not have
IP
addresses assigned to them apart from the IPv6
link-local addresses (starting fe80
). If you have an unexpected IP
address, then there may be another configuration file with ONBOOT set to yes
.
- If this occurs, issue the following command to list all
ifcfg
files that may be causing a conflict: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 thegrep -r "ONBOOT=yes" /etc/sysconfig/network-scripts/ | cut -f1 -d":" | xargs grep -E "IPADDR|SLAVE"
~]$ grep -r "ONBOOT=yes" /etc/sysconfig/network-scripts/ | cut -f1 -d":" | xargs grep -E "IPADDR|SLAVE" /etc/sysconfig/network-scripts/ifcfg-lo:IPADDR=127.0.0.1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ifcfg-eth1
file was incorrectly configured, the display might look similar to the following:grep -r "ONBOOT=yes" /etc/sysconfig/network-scripts/ | cut -f1 -d":" | xargs grep -E "IPADDR|SLAVE"
~]# grep -r "ONBOOT=yes" /etc/sysconfig/network-scripts/ | cut -f1 -d":" | xargs grep -E "IPADDR|SLAVE" /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
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 “down” and “up” again or restart the network service as
root
:If you are using NetworkManager, you might need to restart it at this point to make it forget the unwantedCopy to Clipboard Copied! Toggle word wrap Toggle overflow IP
address. Asroot
:service NetworkManager restart
~]# service NetworkManager restart
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Procedure 11.3. Checking the bond on the Server
- Bring up the bond on the server as
root
:ifup /etc/sysconfig/network-scripts/ifcfg-bond0
~]# ifup /etc/sysconfig/network-scripts/ifcfg-bond0 Determining if ip address 192.168.100.100 is already in use for device bond0...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Check the status of the interfaces on the server:Notice that
Copy to Clipboard Copied! Toggle word wrap Toggle overflow eth0
andeth1
havemaster bond0 state UP
andbond0
has status ofMASTER,UP
. - View the bond configuration details:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Check the routes on the server:
ip route
~]$ ip route 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
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Procedure 11.4. Configuring the VLAN on the Server
Important
At the time of writing, it is important that the bond has slaves and that they are “up” before bringing up the VLAN interface. At the time of writing, adding a VLAN interface to a bond without slaves does not work. In Red Hat Enterprise Linux 6, setting the ONPARENT directive to
yes
is important to ensure that the VLAN interface does not attempt to come up before the bond is up. This is because a VLAN virtual device takes the MAC address of its parent, and when a NIC is enslaved, the bond changes its MAC address to that NIC's MAC address.
Note
A VLAN slave cannot be configured on a bond with the
fail_over_mac=follow
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.
Some older network interface cards, loopback interfaces, Wimax cards, and some Infiniband devices, are said to be VLAN challenged, meaning they cannot support VLANs. This is usually because the devices cannot cope with VLAN headers and the larger MTU size associated with VLANs.
- Create a VLAN interface file
bond0.192
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Bring up the VLAN interface as
root
:ifup /etc/sysconfig/network-scripts/ifcfg-bond0.192
~]# ifup /etc/sysconfig/network-scripts/ifcfg-bond0.192 Determining if ip address 192.168.10.1 is already in use for device bond0.192...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Enabling VLAN tagging on the network switch. Consult the documentation for the switch to see what configuration is required.
- Check the status of the interfaces on the server:Notice there is now
Copy to Clipboard Copied! Toggle word wrap Toggle overflow bond0.192@bond0
in the list of interfaces and the status isMASTER,UP
. - Check the route on the server:Notice there is now a route for the
ip route
~]$ ip route 192.168.100.0/24 dev bond0 proto kernel scope link src 192.168.100.100 192.168.10.0/24 dev bond0.192 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
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 192.168.10.0/24
network pointing to the VLAN interfacebond0.192
.
Configuring the Second Server
Repeat the configuration steps for the second server, using different
IP
addresses but from the same subnets respectively.
Test the bond is up and the network switch is working as expected:
Copy to Clipboard
Copied!
Toggle word wrap
Toggle overflow
Testing the VLAN
To test that the network switch is configured for the VLAN, try to ping the first servers' VLAN interface:
Copy to Clipboard
Copied!
Toggle word wrap
Toggle overflow
No packet loss suggests everything is configured correctly and that the VLAN and underlying interfaces are
“up”.
Optional Steps
- If required, perform further tests by removing and replacing network cables one at a time to verify that failover works as expected. Make use of the ethtool utility to verify which interface is connected to which cable. For example:Where integer is the number of times to flash the LED on the network interface.
ethtool --identify ifname integer
ethtool --identify ifname integer
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - The bonding module does not support
STP
, therefore consider disabling the sending of BPDU packets from the network switch. - 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
portfast
command.