此内容没有您所选择的语言版本。
31.8. Specific Kernel Module Capabilities
This section explains how to enable specific kernel capabilities using various kernel modules.
31.8.1. Using Channel Bonding
Red Hat Enterprise Linux allows administrators to bind NICs together into a single channel using the
bonding
kernel module and a special network interface, called a channel bonding interface. Channel bonding enables two or more network interfaces to act as one, simultaneously increasing the bandwidth and providing redundancy.
To channel bond multiple network interfaces, the administrator must perform the following steps:
- Configure a channel bonding interface as outlined in Section 11.2.4, “Channel Bonding Interfaces”.
- To enhance performance, adjust available module options to ascertain what combination works best. Pay particular attention to the
miimon
orarp_interval
and thearp_ip_target
parameters. See Section 31.8.1.1, “Bonding Module Directives” for a list of available options and how to quickly determine the best ones for your bonded interface.
31.8.1.1. Bonding Module Directives
It is a good idea to test which channel bonding module parameters work best for your bonded interfaces before adding them to the
BONDING_OPTS="<bonding parameters>"
directive in your bonding interface configuration file (ifcfg-bond0
for example). Parameters to bonded interfaces can be configured without unloading (and reloading) the bonding module by manipulating files in the sysfs
file system.
sysfs
is a virtual file system that represents kernel objects as directories, files and symbolic links. sysfs
can be used to query for information about kernel objects, and can also manipulate those objects through the use of normal file system commands. The sysfs
virtual file system has a line in /etc/fstab
, and is mounted under the /sys/
directory. All bonding interfaces can be configured dynamically by interacting with and manipulating files under the /sys/class/net/
directory.
In order to determine the best parameters for your bonding interface, create a channel bonding interface file such as
ifcfg-bond0
by following the instructions in Section 11.2.4, “Channel Bonding Interfaces”. Insert the SLAVE=yes
and MASTER=bond0
directives in the configuration files for each interface bonded to bond0. Once this is completed, you can proceed to testing the parameters.
First, bring up the bond you created by running
ifconfig bond<N>
up
as root:
~]# ifconfig bond0 up
If you have correctly created the
ifcfg-bond0
bonding interface file, you will be able to see bond0
listed in the output of running ifconfig
(without any options):
~]# ifconfig
bond0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth0 Link encap:Ethernet HWaddr 52:54:00:26:9E:F1
inet addr:192.168.122.251 Bcast:192.168.122.255 Mask:255.255.255.0
inet6 addr: fe80::5054:ff:fe26:9ef1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:207 errors:0 dropped:0 overruns:0 frame:0
TX packets:205 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:70374 (68.7 KiB) TX bytes:25298 (24.7 KiB)
[output truncated]
To view all existing bonds, even if they are not up, run:
~]# cat /sys/class/net/bonding_masters
bond0
You can configure each bond individually by manipulating the files located in the
/sys/class/net/bond<N>/bonding/
directory. First, the bond you are configuring must be taken down:
~]# ifconfig bond0 down
As an example, to enable MII monitoring on bond0 with a 1 second interval, you could run (as root):
~]# echo 1000 > /sys/class/net/bond0/bonding/miimon
To configure bond0 for
balance-alb
mode, you could run either:
~]# echo 6 > /sys/class/net/bond0/bonding/mode
...or, using the name of the mode:
~]# echo balance-alb > /sys/class/net/bond0/bonding/mode
After configuring options for the bond in question, you can bring it up and test it by running
ifconfig bond<N> up
. If you decide to change the options, take the interface down, modify its parameters using sysfs
, bring it back up, and re-test.
Once you have determined the best set of parameters for your bond, add those parameters as a space-separated list to the
BONDING_OPTS=
directive of the /etc/sysconfig/network-scripts/ifcfg-bond<N>
file for the bonding interface you are configuring. Whenever that bond is brought up (for example, by the system during the boot sequence if the ONBOOT=yes
directive is set), the bonding options specified in the BONDING_OPTS
will take effect for that bond. For more information on configuring bonding interfaces (and BONDING_OPTS
), see Section 11.2.4, “Channel Bonding Interfaces”.
The following list provides the names of many of the more common channel bonding parameters, along with a descriptions of what they do. For more information, see the brief descriptions for each
parm
in modinfo bonding
output, or the exhaustive descriptions in the bonding.txt
file in the kernel-doc package (see Section 31.9, “Additional Resources”).
Bonding Interface Parameters
-
arp_interval=<time_in_milliseconds>
- Specifies (in milliseconds) how often ARP monitoring occurs. When configuring this setting, a good starting point for this parameter is
1000
.Important
It is essential that botharp_interval
andarp_ip_target
parameters are specified, or, alternatively, themiimon
parameter is specified. Failure to do so can cause degradation of network performance in the event that a link fails.If using this setting while inmode=0
ormode=2
(the two load-balancing modes), the network switch must be configured to distribute packets evenly across the NICs. For more information on how to accomplish this, see thebonding.txt
file in the kernel-doc package (see Section 31.9, “Additional Resources”).The value is set to0
by default, which disables it. -
arp_ip_target=<ip_address>[,<ip_address_2>,…<ip_address_16>]
- Specifies the target IP address of ARP requests when the
arp_interval
parameter is enabled. Up to 16 IP addresses can be specified in a comma separated list. -
arp_validate=<value>
- Validate source/distribution of ARP probes; default is
none
. Other valid values areactive
,backup
, andall
. -
downdelay=<time_in_milliseconds>
- Specifies (in milliseconds) how long to wait after link failure before disabling the link. The value must be a multiple of the value specified in the
miimon
parameter. The value is set to0
by default, which disables it. - lacp_rate=<value>
- Specifies the rate at which link partners should transmit LACPDU packets in 802.3ad mode. Possible values are:
slow
or0
— Default setting. This specifies that partners should transmit LACPDUs every 30 seconds.fast
or1
— Specifies that partners should transmit LACPDUs every 1 second.
-
miimon=<time_in_milliseconds>
- Specifies (in milliseconds) how often MII link monitoring occurs. This is useful if high availability is required because MII is used to verify that the NIC is active. To verify that the driver for a particular NIC supports the MII tool, type the following command as root:
~]#
ethtool <interface_name> | grep "Link detected:"
In this command, replace <interface_name> with the name of the device interface, such aseth0
, not the bond interface. If MII is supported, the command returns:Link detected: yes
If using a bonded interface for high availability, the module for each NIC must support MII. Setting the value to0
(the default), turns this feature off. When configuring this setting, a good starting point for this parameter is100
.Important
It is essential that botharp_interval
andarp_ip_target
parameters are specified, or, alternatively, themiimon
parameter is specified. Failure to do so can cause degradation of network performance in the event that a link fails. -
mode=<value>
- Allows you to specify the bonding policy. The <value> can be one of:
balance-rr
or0
— 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.active-backup
or1
— Sets an active-backup policy for fault tolerance. Transmissions are received and sent out via the first available bonded slave interface. Another bonded slave interface is only used if the active bonded slave interface fails.balance-xor
or2
— 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.broadcast
or3
— Sets a broadcast policy for fault tolerance. All transmissions are sent on all slave interfaces.802.3ad
or4
— Sets an IEEE 802.3ad dynamic link aggregation policy. Creates aggregation groups that share the same speed and duplex settings. Transmits and receives on all slaves in the active aggregator. Requires a switch that is 802.3ad compliant.balance-tlb
or5
— Sets a 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.balance-alb
or6
— Sets an Adaptive Load Balancing (ALB) policy for fault tolerance and load balancing. Includes transmit and receive load balancing forIPv4
traffic. Receive load balancing is achieved throughARP
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.
-
num_unsol_na=<number>
- Specifies the number of unsolicited IPv6 Neighbor Advertisements to be issued after a failover event. One unsolicited NA is issued immediately after the failover.The valid range is
0 - 255
; the default value is1
. This parameter affects only the active-backup mode. -
primary=<interface_name>
- Specifies the interface name, such as
eth0
, of the primary device. Theprimary
device is the first of the bonding interfaces to be used and is not abandoned unless it fails. This setting is particularly useful when one NIC in the bonding interface is faster and, therefore, able to handle a bigger load.This setting is only valid when the bonding interface is inactive-backup
mode. See thebonding.txt
file in the kernel-doc package (see Section 31.9, “Additional Resources”). -
primary_reselect=<value>
- Specifies the reselection policy for the primary slave. This affects how the primary slave is chosen to become the active slave when failure of the active slave or recovery of the primary slave occurs. This parameter is designed to prevent flip-flopping between the primary slave and other slaves. Possible values are:
always
or0
(default) — The primary slave becomes the active slave whenever it comes back up.better
or1
— The primary slave becomes the active slave when it comes back up, if the speed and duplex of the primary slave is better than the speed and duplex of the current active slave.failure
or2
— The primary slave becomes the active slave only if the current active slave fails and the primary slave is up.
Theprimary_reselect
setting is ignored in two cases:- If no slaves are active, the first slave to recover is made the active slave.
- When initially enslaved, the primary slave is always made the active slave.
Changing theprimary_reselect
policy viasysfs
will cause an immediate selection of the best active slave according to the new policy. This may or may not result in a change of the active slave, depending upon the circumstances -
updelay=<time_in_milliseconds>
- Specifies (in milliseconds) how long to wait before enabling a link. The value must be a multiple of the value specified in the
miimon
parameter. The value is set to0
by default, which disables it. -
use_carrier=<number>
- Specifies whether or not
miimon
should use MII/ETHTOOL ioctls ornetif_carrier_ok()
to determine the link state. Thenetif_carrier_ok()
function relies on the device driver to maintains its state withnetif_carrier_on/off
; most device drivers support this function.The MII/ETHROOL ioctls tools utilize a deprecated calling sequence within the kernel. However, this is still configurable in case your device driver does not supportnetif_carrier_on/off
.Valid values are:1
— Default setting. Enables the use ofnetif_carrier_ok()
.0
— Enables the use of MII/ETHTOOL ioctls.
Note
If the bonding interface insists that the link is up when it should not be, it is possible that your network device driver does not supportnetif_carrier_on/off
. -
xmit_hash_policy=<value>
- Selects the transmit hash policy used for slave selection in
balance-xor
and802.3ad
modes. Possible values are:0
orlayer2
— Default setting. This parameter uses the XOR of hardware MAC addresses to generate the hash. The formula used is:(<source_MAC_address> XOR <destination_MAC>) MODULO <slave_count>
This algorithm will place all traffic to a particular network peer on the same slave, and is 802.3ad compliant.1
orlayer3+4
— Uses upper layer protocol information (when available) to generate the hash. This allows for traffic to a particular network peer to span multiple slaves, although a single connection will not span multiple slaves.The formula for unfragmented TCP and UDP packets used is:((<source_port> XOR <dest_port>) XOR ((<source_IP> XOR <dest_IP>) AND
0xffff
) MODULO <slave_count>For fragmented TCP or UDP packets and all other IP protocol traffic, the source and destination port information is omitted. For non-IP traffic, the formula is the same as thelayer2
transmit hash policy.This policy intends to mimic the behavior of certain switches; particularly, Cisco switches with PFC2 as well as some Foundry and IBM products.The algorithm used by this policy is not 802.3ad compliant.2
orlayer2+3
— Uses a combination of layer2 and layer3 protocol information to generate the hash.Uses XOR of hardware MAC addresses and IP addresses to generate the hash. The formula is:(((<source_IP> XOR <dest_IP>) AND
0xffff
) XOR ( <source_MAC> XOR <destination_MAC> )) MODULO <slave_count>This algorithm will place all traffic to a particular network peer on the same slave. For non-IP traffic, the formula is the same as for the layer2 transmit hash policy.This policy is intended to provide a more balanced distribution of traffic than layer2 alone, especially in environments where a layer3 gateway device is required to reach most destinations.This algorithm is 802.3ad compliant.