1. ethtool支持获取每个slave的速率和双工设定；
2. switch(交换机)支持IEEE 802.3ad Dynamic link aggregation。
大多数switch(交换机)需要经过特定配置才能支持802.3ad模式。
balance-tlb 或者 5
自适应的传输负载均衡：不需要任何特别的switch(交换机)支持的通道bonding。在每个slave上根据当前的负载（根据速度计算）分配外出流量。如果正在接受数据的slave出故障了，另一个slave接管失败的slave的MAC地址。
必要条件：
ethtool支持获取每个slave的速率。
balance-alb 或者 6
自适应均衡负载：该模式包含了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接管。
primary
指定哪个slave成为主设备（primary device），取值为字符串，如eth0，eth1等。只要指定的设备可用，它将一直是激活的slave。只有在主设备（primary device）断线时才会切换设备。这在希望某个slave设备优先使用的情形下很有用，比如，某个slave设备有更高的吞吐率。
primary选项只对active-backup模式有效。
updelay
指定当发现一个链路恢复时，在激活该链路之前的等待时间，以毫秒计算。该选项只对miimon链路侦听有效。updelay应该是miimon值的整数倍，如果不是，它将会被向下取整到最近的整数。缺省值为0。
use_carrier
指定miimon是否需要使用MII或者ETHTOOL ioctls还是netif_carrier_ok()来判定链路状态。MII或ETHTOOL ioctls更低效一些，而且使用了内核里废弃的旧调用序列；而netif_carrier_ok()依赖于设备驱动来维护状态（判断载波），在本文写作时，大多数但不是全部设备驱动支持这个特性。
如果bonding总是认为链路是通的，但实际上是断的，这有可能是由于你的网络设备驱动不支持netif_carrier_on/off。因为 netif_carrier的缺省状态是"carrier on"，因此如果驱动不支持netif_carrier，则会显示链路永远正常。在这种情况下，把use_carrier设为0，从而让bonding使用MII/ETHTOOL ictl来判定链路状态。
该选项设为1会使用netif_carrier_ok()，而设为0则会使用废弃的MII/ETHTOOL ioctls，缺省值是1。
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策略。