目录
设置bond options参数mode、miimon、xmit_hash_policy
bond mode4 最大带宽只能达到单个物理带宽上限的可能原因
简略
什么是bond
什么是bond：网卡bond（绑定），也称作网卡捆绑。就是将两个或者更多的物理网卡绑定成一个虚拟网卡。
Bond的作用： 1.提高网卡的吞吐量。2.增强网络的高可用（某个物理网卡不工作了，其他顶上），同时也能实现负载均衡。
（https://www.cnblogs.com/xuezhimin-esage-2020/p/14411837.html）
bond的七种模式
mode=0 负载模式（模式0），平衡抡循环策略，load balancing (round-robin)，两块网卡都工作，有自动备援，需要 交换机的配合设置（需要交换机做链路聚合）。
mode=1 主备模式（模式1），fault-tolerance (active-backup)，工作方式是主 从备份,既默认情况下一块网卡工作,另一块做备份。
mode=2 平衡策略 XOR policy 。XOR Hash负载分担，基于指定的传输HASH策略传输数据包，此模式提供负载平衡和容错能力，（bond参数xmit_hash_policy选择hash策略，需要交换机配置port channel）
mode=3 广播策略broadcast 。此模式提供了容错能力
mode=4 动态链接聚合策略， IEEE 802.3ad Dynamic link aggregation ，多个端口捆绑成一条高带宽链路，同时几个端口进行链路负载均衡，（bond参数xmit_hash_policy选择hash策略，需要交换机配合设置，注意并不是）
3.大多数switch(交换机)需要经过特定配置才能支持802.3ad模式
外出流量的slave选举是基于传输hash策略，该策略可以通过xmit_hash_policy选项选择（相关内容在本文搜索xmit_hash_policy），缺省是XOR策略。
mode=5 基于每个slave网卡的速率选择传输网卡，Adaptive transmit load balancing 为适配器传输负载均衡。该 模式的必要条件：ethtool 支持获取每个 slave 的速率
mode=6 平衡负载模式 Adaptive load balancing ，有自动备援，该模式包含 了 balance-tlb 模式，同时加上针对 IPV4 流量的接收负载均衡(receive load balance, rlb)，而且不需要任何 switch(交换机)的支持。
查看和监控
查看bond
ip a|grep bond0
查看bond的属性
nmcli c show bond0
监控 bond0 状态：
watch -n 1 cat /proc/net/bonding/bond0 ，
存在两个物理网口，且 bond 模式为 active-backup ，此时实际在用的网卡为 ens37 （
Currently Active Slave 显示哪个就是在用哪个）
（参考：https://blog.csdn.net/m0_59586152/article/details/125503956）
注意事项
- 一些bond 模式需要交换机一起设置才能生效，所以别忘了设置交换机。
- bond mode4 默认hash是layer2，带宽达不到子网卡之和。
- 一些hash算法不兼容mode4 （如mtu小导致切片的）
nmtui配置bond
(本段摘自：https://blog.csdn.net/qq_44777532/article/details/125749980)
1、在命令行终端使用nmtui命令，进入nmtui页面
选择"Edit a connection"
2、添加bond组，如图所示
选择<add>-->选择bond-->create
3、配置bond信息，如图所示
4、选择add时，在bond0设备中添加网卡时，需分别添加ens33和ens37,具体配置如下
5、添加完成后，在网卡页面会新增一个bond类型的网卡，如图所示
6、重启激活bond0网卡
7、登陆终端验证bond0网卡是否生效
#1、查看bond状态信息
[root@localhost ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: ens33
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0Slave Interface: ens33
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0c:29:78:3a:f1
Slave queue ID: 0Slave Interface: ens37
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0c:29:78:3a:fb
Slave queue ID: 0#2、查看本地IP情况，验证设置的bond0是否生效
[root@localhost ~]# ifconfig
bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500
inet 192.168.100.40 netmask 255.255.255.0 broadcast 192.168.100.255
inet6 fe80::10d:90b:59bb:a41f prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:78:3a:f1 txqueuelen 1000 (Ethernet)
RX packets 102 bytes 11808 (11.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 110 bytes 23827 (23.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0ens33: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500
ether 00:0c:29:78:3a:f1 txqueuelen 1000 (Ethernet)
RX packets 9911 bytes 933898 (912.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4312 bytes 1347298 (1.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0ens37: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500
ether 00:0c:29:78:3a:f1 txqueuelen 1000 (Ethernet)
RX packets 2600 bytes 237471 (231.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 115 bytes 12729 (12.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 430 bytes 36710 (35.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 430 bytes 36710 (35.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255
ether 52:54:00:84:25:5a txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
（命令行配置见：https://blog.csdn.net/qq_44777532/article/details/125749980）
设置bond options参数mode、miimon、xmit_hash_policy
（可以参考：《超详细linux手动配置单网卡和双网卡(bond0和team）以及DNS，linux网络配置详细说明》http://t.csdn.cn/Sn2fi ）
network管理的，网口配置文件在 /etc/sysconfig/network-scripts/下面，配置
BONDING_OPTS = "mode=1 miimon=100 updelay=600000 primary=em1"
NetworkManager管理的：使用nmtui 设置的,网口配置文件在这里设置（options配置也这里的网口配置文件中）
vim /etc/NetworkManager/system-connections/
例子：
1，修改对应网口的bond的options参数：
命令行修改：
sudo nmcli connection modify bond0 bond.options mode=802.3ad,miimon=80 #逗号隔开
添加和修改bond0网口链接的bond参数
nmcli connection modify bond0 +bond.options xmit_hash_policy=layer3+4 #+号
删除bond0网口链接的bond参数
nmcli connection modify bond0 -bond.options xmit_hash_policy=layer3+4 # -号
也可以编辑配置文件修改：
vim /etc/NetworkManager/system-connections/bond4.nmconnection
#修改[bond]部分，如修改hash模式
……
[ethernet]
[bond]
downdelay=0
miimon=100
mode=802.3ad
updelay=0
xmit_hash_policy=layer 3+4
[ipv4]
……
2、修改后，重新加载配置和启用
nmcli c reload
nmcli d reapply bond4 #bond4 是我bond网口的名字
3 查看设置结果
命令行查看：
nmcli c show bond4
也可以查看配置文件：
cat /proc/net/bonding/bond4
[root@node110 ~]# cat /proc/net/bonding/bond4
Ethernet Channel Bonding Driver: v5.15.67-6.cl9.x86_64
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0
802.3ad info
LACP active: on
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: 10:70:fd:69:92:d4
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 2
Actor Key: 29
Partner Key: 337
Partner Mac Address: f8:53:29:95:5a:d1
详细说明
网卡绑定原理
在正常情况下，网卡的工作模式为直接模式（Direct Model），该模式下的网卡只接收目地址是自己 Mac地址的帧。将别的数据帧都滤掉，以减轻驱动程序的负担。
但是网卡也支持另外一种混杂模式，可以接收网络上所有的帧。Bonding运行在这个模式下，使用两块网卡虚拟成为一块网卡，这个聚合起来的设备看起来是一个单独的以太网接口设备，通俗点讲就是两块网卡具有相同的IP地址而并行链接聚合成一个逻辑链路工作。物理网卡把相应的数据帧传送给bond驱动程序处理。通过网卡绑定可以实现网络设备的冗余和负载均衡。（ https://blog.csdn.net/yuan_jiaoyoung/article/details/129792714）
官网说明文档
文档获取方式：见文章末尾
bond的七种模式详细说明
balance-rr （mode=0 ）
Round-robin policy（平衡抡循环策略，负载模式，load balancing）【默认】
提供负载平衡和容错能力。交换机需要配置聚合口，思科叫port channel。
特点：
负载均衡：
轮转策略，轮流在每一个slave网卡上发送数据包，（即：第1个包走eth0，下一个包就走eth1….一直循环下去，直到最后一个传输完毕），此模式提供负载平衡。
高可用：
一条链路故障会自动切换正常链路。
注意事项：
1，但一个连接或者会话的数据包从不同的接口发出，中途再经过不同的链路，在客户端很有可能会出现数据包无序到达的问题，而无序到达的数据包需要重新要求被发送，这样网络的吞吐量就会下降。
2，需要 交换机的配合设置（需要交换机做链路聚合）
active-backup（mode=1）
Active-backup policy（主-备份策略）【常用】
特点：
- 主备策略，只有一块网卡是活动状态（active），另一块是备用的（standby）。当一个宕掉另一个马上由备份转换为主设备。
- mac地址是外部可见得，从外面看来，bond的MAC地址是唯一的，以避免switch(交换机)发生混乱。
此模式只提供了容错能力；由此可见此算法的优点是可以提供高网络连接的可用性，但是它的资源利用率较低，只有一个接口处于工作状态，在有 N 个网络接口的情况下，资源利用率为1/N
注意事项：
所有流量都在active链路上处理，交换机配置的是捆绑的话将不能工作，因为交换机往两块网卡发包，有一半包是丢弃的。
主备模式下发生一次故障切换，在新激活的slave接口上会发送一个或者多个gratuitous ARP。
主salve接口上以及配置在接口上的所有VLAN接口都会发送gratuitous ARP，需要在这些接口上配置了至少一个IP地址。VLAN接口上发送的的gratuitous ARP将会附上适当的VLAN id。
balance-xor （mode=2）
XOR policy（平衡策略）【不常用】
表示XOR Hash负载分担，和交换机的聚合强制不协商方式配合。（bond参数xmit_hash_policy选择hash策略，需要交换机配置port channel）
特点：基于指定的传输HASH策略传输数据包。缺省的策略是：(源MAC地址 XOR 目标MAC地址) % slave数量。其他的传输策略可以通过xmit_hash_policy选项指定，此模式提供负载平衡和容错能力.
Bond2中通过xmit_hash_policy指定Slave调度策略，默认为上边讲到的layer2。
broadcast（mode=3）
（广播策略）【不常用】mode=3 或 mode=broadcast 同效
特点：
所有包从所有网络接口发出，此模式适用于金融行业，因为他们需要高可靠性的网络，不允许出现任何问题。需要和交换机的聚合强制不协商方式配合。
缺点：只有冗余机制，但过于浪费网络中的资源及本机的网络设备资源。
802.3ad （mode=4）
IEEE 802.3ad Dynamic link aggregation（IEEE 802.3ad 动态链接聚合）
链路聚合，又称端口聚合、端口捆绑技术。功能是将交换机的多个低带宽端口捆绑成一条高带宽链路，同时通过几个端口进行链路负载均衡，避免链路出现拥塞现象。
特点：
启动时会根据IEEE 802.3ad规范创建一个聚合组。使用动态链接聚合策略，所有Slave网卡共享同样的速率和双工设定。
必要条件：
1．支持使用ethtool工具获取每个slave网卡的速率和双工设定；
2．需要交换机支持IEEE 802.3ad 动态链路聚合（Dynamic link aggregation）模式
IEEE 802.3ad规范：
IEEE 802.3ad主要是对链路聚合控制协议进行了一定的标准和规范。
3.大多数switch(交换机)需要经过特定配置才能支持802.3ad模式
外出流量的slave选举是基于传输hash策略，该策略可以通过xmit_hash_policy选项选择（相关内容在本文搜索xmit_hash_policy），缺省是XOR策略。需要注意的 是，并不是所有的传输策略都是802.3ad适应的，尤其考虑到在802.3ad标准43.2.4章节提及的包乱序问题。不同的实现可能会有不同的适应 性。（所以要802.3ad 使用layer3+4，需要确保数据流不会分段，既应用程序发的数据包不大于PMTUD ？）
LACP
在 IEEE 802.3ad 中，“链路聚合控制协议”（LACP）自动通知交换机应该聚集哪些端口。IEEE 802.3ad 聚合配置之后，链路聚合控制协议数据单元（LACPDU）就会在服务器和交换机之间进行交换。LACP 会通知交换机在聚合中配置的适配器应作为交换机上的一个适配器来考虑，而不再有用户干涉。
balance-tlb（mode=5）
Adaptive transmit load balancing（适配器传输负载均衡）【不常用】
自适应传输负载均衡：
根据每个slave的负载(相对速度)决定从哪个接口发送数据包，接收时使用当前轮到的slave。如果接收的slave接口故障，其它slave接口将接管它的mac地址继续接收。
前提：每个slave网卡支持ethtool获取速率。而且ARP监控不可用。
特点：不需要任何特别的switch(交换机)支持的通道bonding。
缺点：不支持发送负载均衡
balance-alb（mode=6）
Adaptive load balancing（适配器适应性负载均衡）【较少使用】
特点：
该模式包含了balance-tlb模式，同时加上针对IPV4流量的接收负载均衡(receive load balance, rlb)，而且不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的。bonding驱动截获本机发送的ARP应答，并把源硬件地址改写为bond中某个slave的唯一硬件地址，从而使得不同的对端使用不同的硬件地址进行通信。
自适应负载均衡：
前提：每个slave网卡支持ethtool获取速率
每个slave网卡支持启用时重新设置硬件地址
在5的tlb基础上增加了rlb(接收负载均衡receive load balance).不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的.
特点：该模式包含了balance-tlb模式，同时加上针对IPV4流量的接收负载均衡(receive load balance, rlb)，而且不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的。bonding驱动截获本机发送的ARP应答，并把源硬件地址改写为bond中某个slave的唯一硬件地址，从而使得不同的对端使用不同的硬件地址进行通信。
来自服务器端的接收流量也会被均衡。当本机发送ARP请求时，bonding驱动把对端的IP信息从ARP包中复制并保存下来。当ARP应答从对端到达 时，bonding驱动把它的硬件地址提取出来，并发起一个ARP应答给bond中的某个slave。
使用ARP协商进行负载均衡的一个问题是：每次广播 ARP请求时都会使用bond的硬件地址，因此对端学习到这个硬件地址后，接收流量将会全部流向当前的slave。这个问题可以通过给所有的对端发送更新 （ARP应答）来解决，应答中包含他们独一无二的硬件地址，从而导致流量重新分布。
当新的slave加入到bond中时，或者某个未激活的slave重新 激活时，接收流量也要重新分布。接收的负载被顺序地分布（round robin）在bond中最高速的slave上
当某个链路被重新接上，或者一个新的slave加入到bond中，接收流量在所有当前激活的slave中全部重新分配，通过使用指定的MAC地址给每个 client发起ARP应答。下面介绍的updelay参数必须被设置为某个大于等于switch(交换机)转发延时的值，从而保证发往对端的ARP应答 不会被switch(交换机)阻截。
必要条件：
条件1：ethtool支持获取每个slave的速率；
条件2：底层驱动支持设置某个设备的硬件地址，从而使得总是有个slave(curr_active_slave)使用bond的硬件地址，同时保证每个bond 中的slave都有一个唯一的硬件地址。如果curr_active_slave出故障，它的硬件地址将会被新选出来的 curr_active_slave接管
其实mod=6与mod=0的区别：mod=6，先把eth0流量占满，再占eth1，….ethX；而mod=0的话，会发现2个口的流量都很稳定，基本一样的带宽。而mod=6，会发现第一个口流量很高，第2个口只占了小部分流量。
mode5和mode6不需要交换机端的设置，网卡能自动聚合。mode4需要支持802.3ad。mode0，mode2和mode3理论上需要静态聚合方式。
但实测中mode0可以通过mac地址欺骗的方式在交换机不设置的情况下不太均衡地进行接收。
原文链接：Linux网卡bond的七种模式详解_cccdddbbb88的博客-CSDN博客_linux网卡模式
原文链接：https://blog.csdn.net/cuichongxin/article/details/116160277
bond 驱动的选项options说明
（参数和例子：https://blog.csdn.net/youlang2010/article/details/20462301）
Bonding驱动的选项是通过在加载时指定参数来设定的。可以通过insmod或modprobe命令的命令行参数来指定，但通常在/etc/modprobe.conf配置文件中指定，或其他的配置文件中
常用
1.miimon： miimon是用来进行链路监测的。 比如:miimon=100，那么系统每100ms监测一次链路连接状态，如果有一条线路不通就转入另一条线路。
2.mode： bond的工作模式，他共有0，1，2，3，4，5，6六种模式，常用为0，6，1三种
3.xmit_hash_policy：hash算法
更多
刚开始配置bond的时候，建议在另一个终端运行"tail -f /var/log/messages"来观察bonding驱动的错误信息【译注：/var/log/messages一般会打印内核中的调试信息】有些参数必须要正确的设定，比如miimon、arp_interval和arp_ip_target，否则在链接故障时会导致严重的网络性能退化。
具体的参数列表：
1）primay
指定哪个slave成为主设备（primary device），取值为字符串，如eth0，eth1等。只要指定的设备可用，它将一直是激活的slave。只有在主设备（primary device）断线时才会切换设备。这在希望某个slave设备优先使用的情形下很有用，比如，某个slave设备有更高的吞吐率
注意： primary选项只对active-backup模式有效
2）updelay
指定当发现一个链路恢复时，在激活该链路之前的等待时间，以毫秒计算。该选项只对miimon链路侦听有效。updelay应该是miimon值的整数倍，如果不是，它将会被向下取整到最近的整数。缺省值为0
3）arp_interval
指定ARP链路监控频率，单位是毫秒(ms)。如果APR监控工作于以太兼容模式（模式0和模式2）下，需要把switch(交换机)配置为在所有链路上均匀的分发网络包。如果switch(交换机)被配置为以XOR方式分发网络包，所有来自ARP目标的应答将会被同一个链路上的其他设备收到，这将会导致其他设备的失败。ARP监控不应该和miimon同时使用。设定为0将禁止ARP监控。缺省值为0
4）arp_ip_target
指定一组IP地址用于ARP监控的目标，它只在arp_interval > 0时有效。这些IP地址是ARP请求发送的目标，用于判定到目标地址的链路是否工作正常。该设定值为ddd.ddd.ddd.ddd格式。多个IP地址通过逗号分隔。至少指定一个IP地址。最多可以指定16个IP地址。缺省值是没有IP地址
5）downdelay
指定一个时间，用于在发现链路故障后，等待一段时间然后禁止一个slave，单位是毫秒(ms)。该选项只对miimon监控有效。downdelay值应该是miimon值的整数倍，否则它将会被取整到最接近的整数倍。缺省值为0
6）lacp_rate
指定在802.3ad模式下，我们希望的链接对端传输LACPDU包的速率。可能的选项：
（1）slow 或者 0
请求对端每30s传输LACPDU
（2）fast 或者 1
请求对端每1s传输LACPDU
（3）缺省值是slow
7）max_bonds
为bonding驱动指定创建bonding设备的数量。比如：如果max_bonds为3，而且bonding驱动还没有加载，那么bond0，bond1，bond2将会被创建。缺省值为1
6）miimon
指定MII链路监控频率，单位是毫秒(ms)。这将决定驱动检查每个slave链路状态频率
0表示禁止MII链路监控。100可以作为一个很好的初始参考值。下面的use_carrier选项将会影响如果检测链路状态。更多的信息可以参考“高可靠性”章节。缺省值为0
8）mode
指定bonding的策略。缺省是balance-rr （round robin，循环赛）。可选的mode包括：0，1，2，3，4，5，6
原文链接：https://blog.csdn.net/youlang2010/article/details/20462301
bonding链路监测方法
官方文档里说有两种针对链路的监测方法（注意：这两种监测不能同时使用）
第一种：miimon（这种方法是最常见的，此方法使用系统的mii-tool命令进行监测）
模块加载设置（/etc/modprobe.conf）：
# Start of bonding configure
alias bond0 bonding
options bond0 miimon=100 mode=1
注意：使用cat /proc/net/bonding/bond0，可查看Bonding Mode: load balancing (round-robin)状态
options bond0 miimon=100 mode=0
注意：使用cat /proc/net/bonding/bond0，可查看Bonding Mode: load balancing ((active-backup))状态
root@Web:~# mii-tool
eth0: negotiated 100baseTx-HD, link ok
eth1: negotiated 100baseTx-HD, link ok
缺点：这种方法，只能监测交换机与该网卡之间的链路；如果它们之外的链路的地方断了,而交换机本身没有问题，也就是说你的网卡和交换机之间还是UP状态,它是不会认为网络中断，除非你的网卡是DOWN状态，它才会把链路转到另一块网卡上，就像是拔掉网线一样，或者把交换机端口shutdown一样
第二种：arp（这种方法比较实用，你可以把它看作是arp的ping（二层ping），但是可能会给网关造成一定的压力）
模块加载：
alias bond0 bonding
options bond0 arp_interval=100 arp_ip_target=192.168.1.1 mode=active-backup primary=eth0
解析如下：
arp_interval=100，表示arp的检测时间，等同于miimon=100的作用
arp_ip_target=192.168.1.1，表示arp检测的目标IP，必须是同网段的，最好就是网关
注意：如果使用arp来ping网关不通，那么在/proc/net/bonding/bond0里会一会down，一会up的
优点：使用arp这种方法，如果交换机的上出现问题，网络不通，它就会把链转到另一块网卡上，但是不管是哪种方法，在第一块网卡出现问题，链路转到第二块后，如果第一块恢复正常，链路自己不会恢复的
原文链接：https://blog.csdn.net/youlang2010/article/details/20462301
bond的hash算法xmit_hash_policy
xmit_hash_policy:
（参考：https://blog.csdn.net/QTM_Gitee/article/details/124412205）
在balance-xor和802.3ad模式下选择不同的hash模式，以用于slave选举。
xmit_hash_policy配置项：
xmit_hash_policy=layer2
(source MAC XOR destination MAC) % slave数量
解释：使用硬件MAC地址的XOR来生成哈希
xmit_hash_policy=layer2+3
(((source IP XOR destination IP) AND 0xffff) XOR ( source MAC XOR destination MAC )) % slave数量
解释：使用硬件 MAC 地址及 IP 地址生成哈希
xmit_hash_policy=layer3+4
((source port XOR dest port) XOR((source IP XOR dest IP) AND 0xffff)% slave数量
解释：使用硬件 端口号 及 IP 地址生成哈希
layer2
“layer2”策略使用源和目标MAC地址以及以太网协议类型的异或。
公式为： (源MAC地址 XOR 目的MAC地址）% slave数目
计算如下：
hash = source MAC XOR destination MAC XOR packet type ID
slave number = hash modulo slave count
该算法会将某个网络对（network peer）上所有的流量全部分配到同一个slave上。
如果网络流量在这个系统和多个其他系统之间在同一个广播域中，这是一个很好的算法。
如果此系统与多个其它系统之间的网络流量通过默认网关，则应该考虑另一种算法。
该算法兼容802.3ad。
如果没有提供配置，这是默认策略。
layer2+3
layer2+3 策略使用源和目标 MAC 地址和 IP 地址的异或。
计算如下：
hash = source MAC XOR destination MAC XOR packet type ID
hash = hash XOR source IP XOR destination IP
hash = hash XOR (hash RSHIFT 16)
hash = hash XOR (hash RSHIFT 8)
hash = hash RSHIFT 1
slave number = hash modulo slave count
这个算法将到一个特定的IP地址所有的流量放在同一个slave上。
如果此系统与多个其他系统之间的网络流量通过默认网关，这是一个很好的算法。
如果网络流量主要在该系统和另一个系统之间，则应考虑另一种算法。
对于非 IP 流量，公式与“layer2”传输策略相同。
该算法兼容802.3ad。
layer3+4
layer3+4 策略使用源端口和目标端口以及 IP 地址的异或。
计算如下：
hash = source port , destination port (如标题)
hash = hash XOR source IP XOR destination IP
hash = hash XOR (hash RSHIFT 16)
hash = hash XOR (hash RSHIFT 8)
hash = hash RSHIFT 1
slave number = hash modulo slave count
如果此系统和另一个系统之间的网络流量使用相同的 IP 但多个端口，这个算法是一个不错的选择。
对于非 IP 流量，公式与“layer2”传输策略相同。
此算法不完全适配 802.3ad
该算法并不完全符合802.3ad的要求,一个同时包含分段和未分段数据包的TCP或UDP会话将会在两个接口之间分割数据包,这可能导致数据传输乱序。大多数流量类型不会这样，因为TCP很少分段数据流 ，而大多数UDP流量不是持续会话。其他的802.3ad实现可能不会容忍这种不符合标准的情况。摘自：kernel.org/doc/Documentation/networking/bonding.txt
（所以要802.3ad 使用layer3+4，需要确保数据流不会分段，既应用程序发的数据包不大于PMTUD ？）
该策略在可能的时候使用上层协议的信息来生成hash。这将允许特定网络对（network peer）的流量分摊到多个slave上，尽管同一个连接（connection）不会分摊到多个slave上。
针对未分片的TCP和UDP包的计算公式为：
((源端口 XOR 目的端口) XOR ((源IP XOR 目的IP) AND 0xFFFF) % slave数目
对于已分片TCP或UDP包，以及其他的IP包，源端口和目的端口的信息被忽略了；
对于非IP流量，采用和layer2一样的hash策略。 该策略期望模仿某些交换机的行为，比如带PFC2的Cisco交换机，以及某些Foundry和IBM的产品。
缺省设置
缺省设置是layer2。该选项在bonding 2.6.3加入，在早期版本中，该参数不存在，只只是layer2策略。
1.layer2： 使用二层帧头作为计算分发出口的参数，这导致通过同一个网关的数据流将完全从一个端口发送，为了更加细化分发策略，必须使用一些三层信息，然而却增加了计算开销。
2.layer2+3： 在1的基础上增加了三层的ip报头信息，计算量增加了，然而负载却更加均衡了，一个个主机到主机的数据流形成并且同一个流被分发到同一个端口，根据这个思想，如果要使负载更加均衡，我们在继续增加代价的前提下可以拿到4层的信息。
3.layer3+4：
layer3+4 该策略在可能的时候使用上层协议的信息来生成hash。这将允许特定网络对（network peer）的流量分摊到多个slave上，尽管同一个连接（connection）不会分摊到多个slave上。
除了这3种策略，还有（请阅读官方说明Chapter 3. Configuring network bonding Red Hat Enterprise Linux 9 | Red Hat Customer Portal）
bond详细介绍
一、Bond简介
Bond技术即bonding，它是Linux Kernel的一个模块，能将多块物理网卡绑定到一块虚拟网卡上，并通过修改网口驱动让多块网卡看起来是一个单独的以太网接口设备，外界看到的只有一个IP，一般用于解决网卡的单点故障或网卡负载较高的场景。
多网卡绑定实际上需要提供一个额外的软件的bond驱动程序实现。通过驱动程序可以将多块网卡屏蔽。对TCP/IP协议层只存在一个Bond网卡，在Bond程序中实现网络流量的负载均衡，即将一个网络请求重定位到不同的网卡上，来提高总体网络的可用性。
二、Bond技术原理
Bond技术需要物理网卡开启混杂模式才能正常工作。在混杂模式下，网卡不是仅接收 “目的MAC地址=自身MAC地址”的以太网帧，而是接收网络上所有的数据帧。
为了实现多块网卡的协同工作，Bond将自己的MAC地址复制到各个物理网卡上，让所有的网卡共享同一个MAC地址。这个方式就要求所有的网卡都要支持BIOS，这样才能够让操作系统将MAC地址写到网卡上。
单物理网卡的Bond网卡，Bond网卡的MAC地址和物理网卡的物理地址是一致的。
多物理网卡的Bond网卡，其中一块物理网卡会被设置为 Master，其他的网卡则都是Slave，Bond网卡的MAC地址=Master物理网卡的MAC地址，然后再将这个MAC地址复制到其他物理网卡上。
所以在安装网卡时，我们需要指定Bond网卡，以及Bond网卡所对应的标志为Master的物理网卡。
三、网卡Bond模式
网卡Bond模式总共有7种，最常用的是，在网络流量较大的场景下推荐使用负载模式（Bond0），而在可靠性要求较高的场景下则推荐使用主备模式（Bond1）。接下来将对这7种模式进行简单的介绍以及优缺点对比。
1）模式0
此模式使用轮询策略，即顺序的在每一个被bond的网卡上发送数据包，这种模式提供负载均衡和容错能力。Bond0可以保证bond虚拟网卡和被bond的两张或多张物理网卡拥有相同的MAC地址，其中bond虚拟网卡的MAC地址是其中一张物理网卡的MAC地址，而bond虚拟网卡的MAC地址是根据bond自己实现的一个算法来选择的。
在bond0模式下，如果一个连接或者会话的数据包从不同的网口发出，途中再经过不同的链路，则在客户端很有可能会出现数据包无序到达的现象，而无序到达的数据包一般需要重新发送，这样网络的吞吐量就会下降。另外，如果做bond0的两张或多张网卡接到了同一交换机上，还需对交换机配置聚合模式。
2）模式1
此模式使用主备策略，在所有做bond1的物理网卡中，同一时刻只有一张网卡被激活，当且仅当活动网卡失效时才会激活其他的网卡。这种模式下做bond的两张或多张网卡的MAC地址和Bond虚拟网卡的MAC地址相同，而Bond的MAC地址是Bond创建启动后活动网卡的MAC地址。
这种模式要求主被网卡能快速的切换，即当主网卡出现故障后能迅速地切换至备用网卡。切换过程中，上层的应用几乎不受影响，因为Bond的驱动程序会临时接管上层应用的数据包，存放至数据缓冲区，等待备用网卡启动后再发送出去。但是如果切换时间过长，则会引起缓冲区的溢出，导致丢包。
3）模式2
此模式的默认选择策略是：选择网卡的序号=(源MAC地址 XOR 目标MAC地址) % Slave网卡（从网卡）的数量。其他的传输策略可以通过xmit_hash_policy配置项指定。
4）模式3
模式3使用广播策略，数据包会被广播至所有Slave网卡进行传送。
5）模式4
模式4使用动态链接聚合策略，启动时会创建一个聚合组，所有Slave网卡共享同样的速率和双工设定，需要交换机支持IEEE 802.3ad动态链路聚合模式。支持使用ethtool工具获取每个slave网卡的速率和双工设定。
6）模式5
模式5基于每个slave网卡的速率选择传输网卡，支持使用ethtool工具获取每个slave网卡的速率。
7）模式6
模式6包含了bond5模式，同时还支持对IPV4流量接收时的负载均衡策略，而且不需要任何交换机的支持，支持只是用ethtool获取每个Slave的速率，要求底层驱动支持设置某个网卡设备的硬件地址。
介绍完这7种模式之后，我们简单对这7种模式的优缺点进行简单的对比，具体的内容请参考以下图1所示。
图1 Bond网卡7种模式优缺点对比
目录： /proc/sys/net/ipv4/conf #查看网卡
watch -n 1 cat /proc/net/bonding/bond0 #监控 bond0 状态，
问题记录和探讨
bond mode4 最大带宽只能达到单个物理带宽上限的可能原因
可能是bond 驱动xmit_hash_policy参数设置的原因，
在balance-xor和802.3ad模式下选择不同的hash模式，以用于slave选举。
可能的取值有：
layer2
使用硬件MAC地址的XOR来生成hash。公式为： (源MAC地址 XOR 目的MAC地址）% slave数目 该算法会将某个网络对（network peer）上所有的流量全部分配到同一个slave上。
layer3+4
该策略在可能的时候使用上层协议的信息来生成hash。这将允许特定网络对（network peer）的流量分摊到多个slave上，尽管同一个连接（connection）不会分摊到多个slave上。 针对未分片的TCP和UDP包的计算公式为： ((源端口 XOR 目的端口) XOR ((源IP XOR 目的IP) AND 0xFFFF) % slave数目 对于已分片TCP或UDP包，以及其他的IP包，源端口和目的端口的信息被忽略了；对于非IP流量，采用和layer2一样的hash策略。 该策略期望模仿某些交换机的行为，比如带PFC2的Cisco交换机，以及某些Foundry和IBM的产品。 该算法不完全适应802.3ad，一个单一的TCP或UDP会话同时包含有分片和未分片的包将会导致包在两个接口上传递，这将会导致投递乱序。大多数流量不会满足这种条件，正如TCP很少分片，而大多数UDP流量不会在长期的会话中存在。其他的802.3ad实现有可能不能容忍这样的不适应性。
缺省设置是layer2。该选项在bonding 2.6.3加入，在早期版本中，该参数不存在，只只是layer2策略。
1.layer2： 使用二层帧头作为计算分发出口的参数，这导致通过同一个网关的数据流将完全从一个端口发送，为了更加细化分发策略，必须使用一些三层信息，然而却增加了计算开销。
2.layer2+3： 在1的基础上增加了三层的ip报头信息，计算量增加了，然而负载却更加均衡了，一个个主机到主机的数据流形成并且同一个流被分发到同一个端口，根据这个思想，如果要使负载更加均衡，我们在继续增加代价的前提下可以拿到4层的信息。
3.layer3+4：
layer3+4 该策略在可能的时候使用上层协议的信息来生成hash。这将允许特定网络对（network peer）的流量分摊到多个slave上，尽管同一个连接（connection）不会分摊到多个slave上。
多client时 各client的流量分配测试：bonding mode 4 测试_https://blog.csdn.net/signmem/article/details/77161220
双25GE网卡做bond4测试，其中一个网口没有流量一个网口可以打满
修改服务器bond网口mode4,双25GE网卡做bond4测试，https://blog.csdn.net/weixin_29185167/article/details/119588686
使用bond4聚合端口未达到带宽扩容原因_https://blog.csdn.net/chunfangzhang/article/details/103796646
例子：
（摘自：https://blog.csdn.net/chunfangzhang/article/details/103796646）
背景：两台服务器应用程序之间涉及到数据传输，其中服务器A 有万兆口，而服务器B只有4个千兆口，由于需要尽可能的提升传输速率，采用服务器A ----交换机----- 服务器B 的方式进行组网
根据网上现有资料，最快捷的方式是使用基于LACP（链路聚合控制） 的bond方式来使服务器B的4个端口进行聚合，对外表现为聚合后的带宽，即4000Mb/s 的传输效果； 配置方法：1、 服务器B上配置 采用bond4 模式进行配置（网上有很多现成的配置步骤可自行搜索）2、交换机 配置 必须把 对应接入到服务器B上的4根网线 在交换机上对应的端口进行配置，即新建一个聚合组，并且将对应的4个端口加入到创建的聚合组中，比较重要的一点是，创建的聚合组在配置时应该允许 所有VLAN 通过，否则在聚合组中会出现几个端口没有处于被选中的状态。当聚合组中几个端口都处于被选中状态以后，基本上交换机上就被制完毕了。
最终的效果：没有达到预期制定的，上升到4000Mbps的目标，因为至始至终 服务器A 与 服务器B 之间都只有一个进程在运行，同时开启多个进程以后，两台服务器之间的总带宽可能会达到4000Mbps,但单个进程之间的传输数据不会超过一个 网口的总传输能力，即1000Mbps, 至于原因， bond4在配置时，选择的协议配置方式是基于layer3+4 的方式，由于两个进程之间的数据连接建立好以后，通过哪个网卡传输数据是基于IP和PORT的不同来区分的，对于只有一个进程的情况，服务器B认为服务器A传过来的数据都是来自同一个IP同一个PORT，因此就都往同一个网卡上丢数据了，导致总的带宽不会超过一个网卡的传输极限（1000Mbps）,如果再多启动几个别的程序，或者让服务器B同时与别的服务器进行数据传输，会发现服务器B的传输总带宽确实是可以达到4000Mbps,也就是说配置的bond4还是起作用的。但这种方式并没有实现我的目标，所以就此作罢。 以上是基于我自己对搜索到的资料和实际操作后的一点理解，还望多多指教，不喜勿喷！
官方资料
redhat linux的bond资料：
Chapter 3. Configuring network bonding Red Hat Enterprise Linux 9 | Red Hat Customer Portal
访问：
Product Documentation for Red Hat Enterprise Linux 9 | Red Hat Customer Portal
选择系统版本：
往下拉找到网络部分：Configuring and managing networking
扫一扫
4141
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
