The principle of 7 bond modes of multiple network cards
Linux Multi-NIC Teaming
There are seven NIC bond modes (0~6) bond0, bond1, bond2, bond3, bond4, bond5, bond6
There are three commonly used
mode=0: Balanced load mode, with automatic backup, but requires "Switch" support and settings.
mode=1: Automatic backup mode, if one of the lines is disconnected, the other lines will automatically backup.
mode=6: Balanced load mode, with automatic backup, no need for "Switch" support and settings.
It should be noted that if you want to make load balancing in mode 0, it is not enough to just set options bond0 miimon=100 mode=0. The switch connected to the network card must be specially configured (the two ports should be aggregated), because The two network cards used for bonding use the same MAC address. From the principle analysis (bond runs in mode 0):
In mode 0, the IPs of the network cards bound by bond are all modified to the same mac address. If these network cards are connected to the same switch, then there are multiple ports corresponding to this mac address in the arp table of the switch, then the switch Which port should a packet sent to this mac address be forwarded to? Under normal circumstances, the mac address is unique in the world. One mac address corresponding to multiple ports must confuse the switch. Therefore, if the bond under mode0 is connected to the switch, the ports of the switch should be aggregated (cisco is called ethernetchannel, and foundry is called portgroup), because after the switch is aggregated, several ports under the aggregation are also bundled into a mac Address. Our solution is to connect the two network cards to different switches.
There is no need to configure a switch in mode6 mode, because the two network cards used for bonding use different MAC addresses.
Description of seven bond modes:
The first mode: mod=0, namely: (balance-rr) Round-robin policy
Features: The sequence of transmitting data packets is sequentially transmitted (ie: the first packet goes to eth0, the next packet goes to eth1.... It continues to cycle until the last transmission is completed). This mode provides load balancing and fault tolerance; but we know that If the data packets of a connection or session are sent from different interfaces, and then go through different links in the middle, the problem of out-of-order arrival of data packets is likely to occur on the client side, and the out-of-order data packets need to be re-requested. send, so the throughput of the network will drop
The second mode: mod=1, that is: (active-backup) Active-backup policy
Features: Only one device is active, when one is down, the other is immediately converted to the main device by the backup. The mac address is visible from the outside. From the outside, the MAC address of the bond is unique to avoid confusion in the switch. This mode only provides fault tolerance; it can be seen that the advantage of this algorithm is that it can provide high availability of network connections, but its resource utilization is low, and only one interface is in a working state. In the case of N network interfaces, Resource utilization is 1/N
The third mode: mod=2, that is: (balance-xor) XOR policy (balance policy)
Features: Data packets are transmitted based on the specified transmission HASH strategy. The default policy is: (source MAC address XOR destination MAC address) % slave count. Other transport policies can be specified via the xmit_hash_policy option, this mode provides load balancing and fault tolerance
The fourth mode: mod=3, namely: broadcast (broadcast strategy)
Features: Each packet is transmitted on each slave interface, this mode provides fault tolerance
The fifth mode: mod=4, that is: (802.3ad) IEEE 802.3ad Dynamic link aggregation
Features: Create an aggregate group that shares the same speed and duplex settings. According to the 802.3ad specification, multiple slaves work under the same active aggregate.
Slave election for outgoing traffic is based on the transport hash policy, which can be changed from the default XOR policy to other policies via the xmit_hash_policy option. It should be noted that not all transmission strategies are 802.3ad compliant, especially considering the packet out-of-order problem mentioned in Section 43.2.4 of the 802.3ad standard. Different implementations may have different adaptations.
Requirements:
Condition 1: ethtool supports getting the speed and duplex settings of each slave
Condition 2: switch (switch) supports IEEE 802.3ad Dynamic link aggregation
Condition 3: Most switches (switches) need to be specifically configured to support 802.3ad mode
The sixth mode: mod=5, namely: (balance-tlb) Adaptive transmit load balancing (adapter transmit load balancing)
Features: Channel bonding that does not require any special switch (switch) support. Outgoing traffic is distributed on each slave based on the current load (calculated based on speed). If the slave receiving data fails, another slave takes over the MAC address of the failed slave.
Necessary conditions for this mode: ethtool supports getting the rate of each slave
The seventh mode: mod=6, namely: (balance-alb) Adaptive load balancing (adapter adaptive load balancing)
Features: This mode includes the balance-tlb mode, plus receive load balance (rlb) for IPV4 traffic, and does not require any switch (switch) support. Receive load balancing is achieved through ARP negotiation. The bonding driver intercepts the ARP reply sent by the local machine, and rewrites the source hardware address to the unique hardware address of a slave in the bond, so that different peers use different hardware addresses to communicate.
Incoming traffic from the server is also balanced. When the local machine sends an ARP request, the bonding driver copies the peer's IP information from the ARP packet and saves it. When the ARP reply arrives from the peer, the bonding driver extracts its hardware address and sends an ARP reply to a slave in the bond. One problem with using ARP negotiation for load balancing is that the bond's hardware address is used every time an ARP request is broadcast, so after the peer learns this hardware address, all incoming traffic will flow to the current slave. This problem can be solved by sending updates (ARP replies) to all peers containing their unique hardware addresses, causing traffic to be redistributed. When a new slave is added to the bond, or when an inactive slave is reactivated, the incoming traffic is also redistributed. The received load is sequentially distributed (round robin) on the fastest slaves in the bond
When a link is reconnected, or a new slave is added to the bond, the received traffic is redistributed among all currently active slaves, and an ARP reply is sent to each client by using the specified MAC address. The updelay parameter described below must be set to a value greater than or equal to the forwarding delay of the switch (switch), so as to ensure that the ARP reply sent to the peer end will not be blocked by the switch (switch).
Requirements:
Condition 1: ethtool supports obtaining the rate of each slave;
Condition 2: The underlying driver supports setting the hardware address of a device, so that there is always a slave (curr_active_slave) that uses the hardware address of the bond, while ensuring that each slave in the bond has a unique hardware address. If curr_active_slave fails, its hardware address will be taken over by the newly elected curr_active_slave
In fact, the difference between mod=6 and mod=0: mod=6, first fill eth0 traffic, then eth1, ... ethX; and mod=0, you will find that the traffic of the two ports is very stable, basically the same bandwidth. And mod=6, you will find that the first port has high traffic, and the second port only accounts for a small part of the traffic.
Linux network port binding
Through the network port bonding (bond) technology, network port redundancy and load balancing can be easily achieved, so as to achieve the purpose of high availability and high reliability. Premise agreement:
The two physical network ports are: eth0, eth1
The virtual port after binding is: bond0
The server IP is: 192.168.0.100
The first step is to configure the settings file:
/etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.0.100
NETMASK=255.255.255.0
NETWORK=192.168.0.0
BROADCAST=192.168.0.255
#BROADCAST broadcast address
/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
The second step is to modify the modprobe related setting files and load the bonding module:
1. Here, we directly create a dedicated setting file /etc/modprobe.d/bonding.conf to load bonding
[root @ test ~] # vi /etc/modprobe.d/bonding.conf
#addition
alias bond0 bonding
options bonding mode=0 miimon=200
2. Load the module (you don't need to load it manually after restarting the system)
[root@test ~]# modprobe bonding
3. Confirm whether the module is loaded successfully:
[root@test ~]# lsmod | grep bonding
bonding 100065 0
The third step, restart the network, and then confirm the situation:
[root@test ~]# /etc/init.d/network restart
[root@test ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
……
[root@test ~]# ifconfig | grep HWaddr
bond0 Link encap:Ethernet HWaddr 00:16:36:1B:BB:74
eth0 Link encap:Ethernet HWaddr 00:16:36:1B:BB:74
eth1 Link encap:Ethernet HWaddr 00:16:36:1B:BB:74
From the confirmation information above, we can see 3 important information:
1. The current bonding mode is active-backup
2. Now the network port in Active state is eth0
3. The physical address of bond0, eth1 is the same as the physical address of eth0 in active state, so as to avoid confusion of the upper switch.
Unplug any network cable, and then visit your server to see if the network is still connected.
The fourth step, the system starts automatic binding and increases the default gateway:
[root @ test ~] # vi /etc/rc.d/rc.local
#addition
ifenslave bond0 eth0 eth1
route add default gw 192.168.0.1
#If you can access the Internet, you don't need to add routes. The 0.1 address is modified according to the environment.
------------------------------------------------------------------------
Note: The front is only the case where two network ports are bound to one bond0. If we want to set up multiple bond ports, for example, the physical network ports eth0 and eth1 form bond0, and eth2 and eth3 form bond1.
Then the setting method of the network port setting file is the same as the method mentioned in step 1 above, except that the settings of /etc/modprobe.d/bonding.conf cannot be simply superimposed as follows:
alias bond0 bonding
options bonding mode=1 miimon=200
alias bond1 bonding
options bonding mode=1 miimon=200
There are 2 correct setting methods:
First, you can see that in this way, the mode of multiple bond ports can only be set to the same:
alias bond0 bonding
alias bond1 bonding
options bonding max_bonds=2 miimon=200 mode=1
Second, in this way, the mode of different bond ports can be set to be different:
alias bond0 bonding
options bond0 miimon=100 mode=1
install bond1 /sbin/modprobe bonding -o bond1 miimon=200 mode=0
Take a closer look at the two setting methods above. Now if you want to set up 3, 4, or even more bond ports, you should be too!
Postscript: Briefly introduce the meaning of some parameters in options when loading the bonding module above:
The frequency of miimon monitoring network links, the unit is milliseconds, we set it to 200 milliseconds.
The number of bond ports configured by max_bonds
The mode bond mode mainly includes the following types. In general practical applications, 0 and 1 are used more often.
If you want to understand the characteristics of these modes in depth, you need to rely on the reader to check the data and do it yourself.
from：http://support.huawei.com/ecommunity/bbs/10155553.html