linux双网卡绑定(3)

4. 查询Bonding配置
=================================

4.1 Bonding配置
---------------------------------

  每个bonding设备对应于一个只读文件，存在于/proc/net/bonding目录，文件内容包括bonding配置的信息，选项以及每个slave的状态。

  例如，在使用参数mode=0，miimon=1000时，加载驱动后，/proc/net/bonding/bond0的内容为：

    Ethernet Channel Bonding Driver: 2.6.1 (October 29, 2004)
        Bonding Mode: load balancing (round-robin)
        Currently Active Slave: eth0
        MII Status: up
        MII Polling Interval (ms): 1000
        Up Delay (ms): 0
        Down Delay (ms): 0

        Slave Interface: eth1
        MII Status: up
        Link Failure Count: 1

        Slave Interface: eth0
        MII Status: up
        Link Failure Count: 1

  根据你配置、状态、以及bonding驱动版本的差异，上述内容的精确格式和内容有可能不同。

4.2 网路配置
---------------------------------

  网络配置可以通过ifconfig命令查看，Bonding设备会设上MASTER标记，slave设备会设上SLAVE标记。ifconfig的输出不包含哪个slave关联于哪个master的关系。

  在上例中，bond0接口是master（MASTER），而eth0和eth0是slave（SLAVE）。注意除了TLB和ALB模式外，所有 bond0的slave和bond0有着同样的MAC地址（HWaddr），TLB和ALB需要每个slave有独立的MAC地址。

# /sbin/ifconfig
bond0     Link encap:Ethernet  HWaddr 00:C0:F0:1F:37:B4
          inet addr:XXX.XXX.XXX.YYY  Bcast:XXX.XXX.XXX.255  Mask:255.255.252.0
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:7224794 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3286647 errors:1 dropped:0 overruns:1 carrier:0
          collisions:0 txqueuelen:0

eth0      Link encap:Ethernet  HWaddr 00:C0:F0:1F:37:B4
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:3573025 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1643167 errors:1 dropped:0 overruns:1 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:10 Base address:0x1080

eth1      Link encap:Ethernet  HWaddr 00:C0:F0:1F:37:B4
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:3651769 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1643480 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:9 Base address:0x1400

5. 交换机配置
=================================

  在本节中，"交换机(switch)"指被bond设备直接连接的系统（也就是说，另一端电缆连接着的），这可能是一个专职的交换机设备，也可能是其它的系统（比如，另一个运行Linux的系统）。

  active-backup、balance-tlb和balance-alb模式不需要对交换机做任何的配置。

  802.3ad模式需要交换机有对应的配置为802.3ad聚合的端口，具体的配置方法因交换机类型而异，比如，Cisco 3550系列交换机要求对应的端口首先必须被分组在一个单独的etherchannel实例，然后这个etherchannel设置为"lacp"模式已启用802.3ad（取代标准EtherChannel）。

  balance-rr、balance-xor和broadcast模式通常需要交换机对应的端口被分组在一起，不同的交换机对分组有着不同的命名，可能会被叫做“etherchannel”（比如上文的Cisco示例），或者叫做“trunk group”，或者其他类似的命令。对于这些模式，每个交换机也会有它自己的针对到bond的传输策略的配置选项。典型的选择包括对每个MAC地址或者 IP地址进行XOR操作，两端的传输策略不一定完全一致。对这三种模式，bonding模式会针对一个EtherChannel组选择一种传输策略；所有这三种模式都会和另一个EtherChannel组进行互操作。

----------------------------------------------------------------------------------------
The balance-rr, balance-xor and broadcast modes generally
require that the switch have the appropriate ports grouped together.
The nomenclature for such a group differs between switches, it may be
called an "etherchannel" (as in the Cisco example, above), a "trunk
group" or some other similar variation.  For these modes, each switch
will also have its own configuration options for the switch's transmit
policy to the bond.  Typical choices include XOR of either the MAC or
IP addresses.  The transmit policy of the two peers does not need to
match.  For these three modes, the bonding mode really selects a
transmit policy for an EtherChannel group; all three will interoperate
with another EtherChannel group.
----------------------------------------------------------------------------------------

6. 支持802.1q VLAN
=================================

  我们可以使用8021q驱动在一个bond接口上配置VLAN设备，然而，只有来自8021q设备和经过(pass through)bonding的数据包缺省会被打上VLAN标记。自生成的数据包，比如，bonding的学习包、在ALB模式生成ARP包或者ARP 监测机制的ARP包，这些包都会被bonding自身在内部打上标记。因此，bonding必须要“学习”在它上面的VLAN ID的配置，然后使用这些ID来标记自生成的数据包。

  简单起见，为了支持那些可以使用VLAN hardware acceleration offloading的适配器，bonding接口把它自身声明为一个完全hardware offloading能力的设备，它通过获取add_vid/kill_vid通知来获取必备的信息，然后它把这些动作传播给slave。在混合的适配器类型下，那些打上硬件加速标记的数据包，如果经过一个不支持offloading的适配器，bonding驱动将“un-accelerated”，因此 VLAN标记依然存在正确的位置。

----------------------------------------------------------------------------------------
  For reasons of simplicity, and to support the use of adapters
that can do VLAN hardware acceleration offloading, the bonding
interface declares itself as fully hardware offloading capable, it gets
the add_vid/kill_vid notifications to gather the necessary
information, and it propagates those actions to the slaves.  In case
of mixed adapter types, hardware accelerated tagged packets that
should go through an adapter that is not offloading capable are
"un-accelerated" by the bonding driver so the VLAN tag sits in the
regular location.
----------------------------------------------------------------------------------------

  在从属slave至少有一个的情况下，VLAN接口"必须"被增加在bonding接口的最上面。直到第一个slave加入前，bonding接口的硬件地址将是00:00:00:00:00:00。如果VLAN接口在第一个slave加入前被创建，它会选择一个全0的硬件地址，一旦第一个slave加入到bond，bond设备自己就会选择slave的硬件地址，VLAN设备也将会使用这个地址。

  同时，要注意到如果所有的slave都被从bond移除，而bond上还有一个或多个VLAN接口时，类似的问题也会发生，当新的slave加入，bonding接口将获取第一个slave的硬件地址，而这可能和当前VLAN接口的硬件地址不一样（当前VLAN接口的硬件地址是从之前的 slave上获取的）。

  有两种方法来保证VLAN设备一直使用正确的硬件地址，即使所有slave被从bond接口上移除：

  1. 移除所有VLAN接口，然后重新创建它们

  2. 手动设置bonding接口的硬件地址，使它和VLAN接口的硬件地址一致。

  要注意改变一个VLAN接口的硬件地址将会改变它下面的设备（比如bonding接口）到混杂模式，这有可能不是你期望的结果。

7. 链路监控
=================================

  当前的bonding驱动支持两种模式，来监控slave设备的链路状态：ARP监控和MII监控。

  由于bonding驱动自身的实现限制，现在我们不可能同时启用ARP和MII监控。

7.1 ARP监控操作
---------------------------------

  ARP监控正如其名字所暗示的：它想网络上的对端系统发送ARP请求，并且通过ARP相应作为链路是否可用的标志，这可以保证网络两端的流量确实是通的。

  ARP监控依赖于设备驱动来验证流量是否是通的，进一步，驱动必须保留上次接收时间，dev->last_rx，以及传输起始时间，dev->trans_start。如果这些值不会被驱动更新，则ARP监控立刻会认为对应于该驱动的slave出现了故障，这些slave将会进入断开状态。如果网络监控工具（比如tcpdump）显示ARP请求和相应都正常，那有可能是你的设备驱动没有更新last_rx和 trans_start。

7.2 配置多ARP目的地址
---------------------------------

  尽管ARP监控可以只用一个目的地址来实现，但在高可靠性（High Availability）环境下，如果能够对多个目的地址进行监控也是很有用的。在只有一个目的地址的情况下，如果目标本身被关闭或者遇到问题以致无法响应ARP请求，这时额外的一个目标（或更多）可以增加ARP监控的可靠性。

  多ARP目的地址之间必须以逗号分割，如下：

# 3个目的地址的ARP监控选项示例
alias bond0 bonding
options bond0 arp_interval=60 arp_ip_target=192.168.0.1,192.168.0.3,192.168.0.9

  如果只有一个目的地址，配置也很类似：

# 只有1个目的地址的ARP监控选项示例
alias bond0 bonding
options bond0 arp_interval=60 arp_ip_target=192.168.0.100

7.3 MII监控操作
---------------------------------

  MII监控通过监控本地网络接口的载波状态来实现监控链路状态。可以通过3种方法之一来实现：通过依赖设备驱动来维护载波状态；通过查询设备的MII寄存器；或者通过给设备发送ethtool查询。

  如果模块参数use_carrier被设为1（缺省值），MII监控将会依赖于设备来获取载波状态信息（通过netif_carrier子系统）。正如前文介绍的use_carrier参数信息，如果MII监控不能发现设备的载波消失（比如当电缆被物理拔断时），那有可能时设备不支持 netif_carrier。

  如果use_carrier为0，MII监控首先会查询设备（通过ioctl）的MII寄存器并检查链路状态，如果查询失败（返回载波断开不属于失败），则MII监控会发送一个ethtool ETHOOL_GLINK查询以尝试获取类似的信息，如果两种方法都失败了（设备不支持或者在处理MII寄存器和ethtool查询时发生了错误），那么 MII监控将会假定链路是正常的。

8. 潜在问题缘由
=================================

8.1 路由历险记
---------------------------------

  如果配置了bonding，很重要的一点是slave设备不能拥有传递到master的路由（或者，通常根本没有路由），比如，假定bonding设备bond0有两个slave：eth0和eth1，路由表如下：

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.0.0.0        0.0.0.0         255.255.0.0     U        40 0          0 eth0
10.0.0.0        0.0.0.0         255.255.0.0     U        40 0          0 eth1
10.0.0.0        0.0.0.0         255.255.0.0     U        40 0          0 bond0
127.0.0.0       0.0.0.0         255.0.0.0       U        40 0          0 lo

  路由配置有可能持续更新设备的接收/发送次数（ARP监控需要），但可能旁路了bonding设备（在这个示例里，外出到网络网络10的流量将会在bond0之前使用eth0或者eth1）。

  ARP监控（以及ARP本身）可能会被这个配置所混淆，因为ARP请求（ARP监控生成）会在某个接口（bond0）上发出，但对应的响应在另一个接口上到达（eth0），这个响应将会被视为一个未关联ARP响应（因为ARP通过接口进行匹配）。MII监控不会被路由表状态所影响。

  这里的解决方法是：保证slave没有它们自己的路由，如果由于某些原因它们必须要有，这些路由不要传递到它们的master，通常情况下都是这样的，但某些特别的配置或者错误的操作或者静态添加路由可能会导致问题。

8.2 Ethernet设备重命名
---------------------------------

  有些系统，它的网络配置脚本没有直接把网络接口名和物理设备关联（如果关联的话，同样的物理设备总是有同样的"ethX"名），对于这些系统，可能需要增加一些特别的逻辑到/etc/modules.conf或者/etc/modprobe.conf（由系统中安装的部件决定）。

  比如，某个modules.conf包含如下内容：

alias bond0 bonding
options bond0 mode=some-mode miimon=50
alias eth0 tg3
alias eth1 tg3
alias eth2 e1000
alias eth3 e1000

  如果eth0和eth1都是bond0的slave，则当bond0接口启用时，这两个设备可能被重新排序，这是因为bonding会被首先加载，然后它的slave设备驱动才会加载，既然没有其他驱动被加载，当e1000驱动加载时，它将会把eth0和eth1认为是它的设备，但是bonding配置尝试把eth2和eth3从属过来（而eth2和eth3可能被赋予tg3设备）。

  增加如下内容：

add above bonding e1000 tg3

  这样，当bonding加载时，将会导致modprobe在tg3前加载e1000。该命令在modules.conf手册里有完整的描述。

  对于使用modprobe.conf（或者modprobe.conf.local）的系统，同样的问题也会发生。这时，可以在modprobe.conf（或modprobe.conf.local）加入如下内容（所有内容在同一行，这里清晰起见分行了）：

install bonding /sbin/modprobe tg3; /sbin/modprobe e1000;
    /sbin/modprobe --ignore-install bonding

  这将会导致，当加载bonding模块时，除了执行正常的操作，同时还执行指定的命令，该命令以正确的顺序加载设备驱动，然后以--ignore- install来调用modprobe，这将导致随后调用通常的操作。完整的描述在modprobe.conf和modprobe的手册里。

8.3 速度变慢或Miimon无法监测到链路异常
---------------------------------

  缺省地，bonding会启用use_carrier选项，这将使得bonding信任设备来维护载波状态。

  正如在上文选项一节所述，某些驱动不支持netif_carrier_on/_off链路状态跟踪系统，当启用use_carrier，bonding将会永远认为链路是正常的，而不管它们的实际状态。

  而且，某些驱动虽然支持netif_carrier，但并不实时维护它，比如只是以某个固定的间隔轮训。在这种情况下，miimon会检测到链路异常，但是可能在某个很长的时间间隔后，如果发现miimon很慢才能检测到链路异常，尝试着设置use_carrier=0，看看能不能改善。如果可以改善，则很可能是驱动需要一个很长的固定间隔才会检查载波状态，而且没有缓存MII寄存器的值（因此当use_carrier=0时查询寄存器可以正常工作）；如果use_carrier=0不能解决问题，则可能是驱动缓存了MII寄存器的值，或者是其它的问题。

  同时，请记住miimon只会检查设备的载波状态，它无法判定设备是否处于打开状态，或对端交换机的状态，或交换机拒绝传输流量，即使载波状态依然正常。

9. SNMP代理
=================================

  如果运行SNMP代理，bonding驱动应该在任何网络驱动参与到bond前被加载，这个要求是由于接口索引（ipAdEntIfIndex）被关联到第一个有着指定IP地址的被发现的接口，也就是说，对每个IP地址只有一个ipAdEntIfIndex，比如，如果eth0和eth1是bond0的 slave，eth0的驱动在bonding驱动前被加载，IP地址的接口将会被关联到eth0接口，配置如下，IP地址192.168.1.1将会使用接口索引2，这将指向ifDescr表（ifDescr.2）中的eth0：

     interfaces.ifTable.ifEntry.ifDescr.1 = lo
     interfaces.ifTable.ifEntry.ifDescr.2 = eth0
     interfaces.ifTable.ifEntry.ifDescr.3 = eth1
     interfaces.ifTable.ifEntry.ifDescr.4 = eth2
     interfaces.ifTable.ifEntry.ifDescr.5 = eth3
     interfaces.ifTable.ifEntry.ifDescr.6 = bond0
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 5
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 4
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1

  如果在所有参与到bond的网络驱动加载前加载bonding驱动，我们可以避免这个问题。如下是一个示例，它会首先加载bonding驱动，IP地址192.168.1.1被正确地关联到ifDescr.2：

     interfaces.ifTable.ifEntry.ifDescr.1 = lo
     interfaces.ifTable.ifEntry.ifDescr.2 = bond0
     interfaces.ifTable.ifEntry.ifDescr.3 = eth0
     interfaces.ifTable.ifEntry.ifDescr.4 = eth1
     interfaces.ifTable.ifEntry.ifDescr.5 = eth2
     interfaces.ifTable.ifEntry.ifDescr.6 = eth3
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 6
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 5
     ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1

  当某些发行包没有在ifDescr中报告接口名，IP地址和IfIndex的关联依然保留，而且SNMP功能，比如Interface_Scan_Next将会报告这些关联。

10. 混杂模式
=================================
  当运行网络监控工具，比如tcpdump，经常会要打开设备德混杂模式，这样所有流量都会被发现（不仅仅看到目标为本机的流量）。bonding驱动处理针对bonding主设备的混杂模式（比如bond0），并把设定传播给其他slave设备。

  对于balance-rr，balance-xor，broadcast和802.3ad模式，混杂模式设置会被传播给所有slave。

  对于active-backup，balance-tlb和balance-alb模式，混杂模式设置仅会被传播给激活的slave。

  对于balance-tlb模式，激活的slave是指当前正在接收inbound流量的slave。

  对于balance-alb模式，激活的slave是指用做"primary"的slave，这个slave用于模式相关的控制流量，对于发送到未指定对端或如果流量未做均衡。

----------------------------------------------------------------------------------------

  For balance-alb mode, the active slave is the slave used as a
"primary."  This slave is used for mode-specific control traffic, for
sending to peers that are unassigned or if the load is unbalanced.

----------------------------------------------------------------------------------------

  对于active-backup，balance-tlb和balance-alb模式，当激活的slave改变时（比如由于链路异常），混杂设定会被传播给新的激活slave。

11. 配置Bonding用于高可靠性（High Availability，缩写为HA）
==========================================================
  High Availability指提供最大网络可靠性的配置，通过在主机和其他设备间的冗余或备份设备、链路或交换机，目标是提供最大的网络链接可靠性（要求网络一直可用），尽管其它的配置可能提供更高的吞吐量（性能）。

11.1 单交换机拓扑下的HA
---------------------------------

  如果两个主机（或一个主机和一个交换机）通过多个物理链路直连，想要优化最大带宽就不具有可行性。在这种情况下，只有一个交换机（或对端），如果它坏了，那没有替代的链接来接替。此外，bonding负载均衡模式支持成员的链路监控，因此如果单个链路坏了，负载将会被均衡到剩余的设备。

  参看第12节“配置Bonding用于最大吞吐量”，如果你想配置只有一个对端设备的bonding。

11.2 多交换机拓扑下的HA
---------------------------------
  如果有多个交换机，bonding和网络的配置戏剧性的发生了变化。在多交换机拓扑下，在网络可靠性和可用贷款间存在着平衡。

  如下是一个简单的网络，配置用于最大化网络可靠性：

                |                                     |
                |port3                           port3|
          +-----+----+                          +-----+----+
          |          |port2       ISL      port2|          |
          | switch A +--------------------------+ switch B |
          |          |                          |          |
          +-----+----+                          +-----++---+
                |port1                           port1|
                |             +-------+               |
                +-------------+ host1 +---------------+
                         eth0 +-------+ eth1

  在该配置中，两个交换机间存在着一个链路（交换机间链路，ISL，Inter Switch Link），并存在多个连到外部的端口（每个交换机上的"port3"），从技术角度看，把它扩充到3个或更多交换机没有任何问题。

11.2.1 多交换机拓扑下的HA模式选择
---------------------------------

  在如上例所示的拓扑中，可用于优化可靠性的bonding模式只有active-backup和broadcast模式，其他的模式要求在同一个对端断开的所有链路能够有特定的行为。

active-backup: 通常是推荐的模式，尤其是如果交换机间存在ISL并能一起很好的工作。如果一个交换机被配置为备份交换机（比如，有更低的处理能力，更高的费用等等），则可以使用primary选项来保证期望的链路在它可用时总是用它。

broadcast：该模式是一种特定目的的模式，只在特定的需求下才需要。比如，如果两个交换机没有互联（没有ISL），而且它们连接的网络是完全独立的，在这种情况下，如果需要某些特定的单向流量能够都到达这两个独立的网络，那可能需要broadcast模式。

11.2.2 多交换机拓扑下的HA链路监控选择
---------------------------------

  链路监控的选择根本上是依赖于你的交换机，如果交换机可以在发生异常时可靠地断开端口，则MII或ARP监控都是可以的。比如，在上例中，如果"port3"在远端的链路异常，由于MII监控没有直连所以无法监测到，而ARP监控如果想监测到必须要配置为port3的远端的目标地址，这样如果没有路由器的支持，要想监测这一类错误时不可能的。

  一般来说，在多交换机拓扑下，ARP监控可以在监测端到端连接错误（可能由任何独立部件在传输流量方面的异常导致）方面提供更高层的可靠性。此外，ARP 监控应该被配置为多个目标（至少网络里的每个交换机都有一个），这可以保证不管哪个交换机可用，ARP监控总是有个合适的目标来查询。

12. 配置Bonding用于最大吞吐量（Maximizing Throughput，缩写为MT）
===============================================================

12.1 单交换机拓扑下的最大吞吐量
---------------------------------

  在单交换机配置情况下，最好的最大化吞吐量的方法依赖于应用程序和网络环境，不同的环境下，不同的负载均衡模式由不同的优点和缺点，如下文所述。

  对这些讨论，我们将把拓扑分为两类，根据大部分流量的目的地，我们把拓扑分为“网关”（gatewayed）和“本地”（local）配置。

  在网关型配置下，“交换机”主要时担当一个路由的功能，主要的网络流浪通过这个路由器到达其他网络，如下图所示：


     +----------+                     +----------+
     |          |eth0            port1|          | to other networks
     | Host A   +---------------------+ router   +------------------->
     |          +---------------------+          | Hosts B and C are out
     |          |eth1            port2|          | here somewhere
     +----------+                     +----------+

  路由器可能是一个专用的路由器设备，也可能是其它充当网关的主机。对我们的讨论，重要的一点是：从Host A来的大部分网络流量将会在到达目的地前先通过路由器到其它的网络。

  在路由器网络配置情况下，尽管Host A可能和很多其它系统通信，但所有流量将通过本地网络中的一个对端（路由器）来发送和接收。

  要说明的是：配置bonding的目的，对于两个系统通过多个物理链接直连，和网关型配置其实是一样的，在这种情况下，碰巧所有流量都通向“网关”自身，而不是网关外的其它网络。

  在本地型配置情况下，“交换机”主要充当交换的功能，主要的流量通过这个交换机到达同一个网络上的其它工作站，下图是一个示例：

    +----------+            +----------+       +--------+
    |          |eth0   port1|          +-------+ Host B |
    |  Host A  +------------+  switch  |port3  +--------+
    |          +------------+          |                  +--------+
    |          |eth1   port2|          +------------------+ Host C |
    +----------+            +----------+port4             +--------+


  同样的，交换机可以是一个专用的交换机设备，也可以是其它充当网关的主机。对我们的讨论，重要的一点是：从Host A来的大部分流量将会到达同一本地网络的其它主机（本例中的Host B和Host C）。

  总结一下，在网关型配置下，来自和发自bond设备的流量将会到网络上的同一个对端MAC地址（网关本身，比如路由器），而不管它的最终目的地是什么。在本地型配置下，流量直接来自或发往最终目的地，这样，每个目的地（Host B，Host C）将会通过它们独立的MAC地址被指定。

  网关型和本地型网络配置的差别很重要，是因为很多负载均衡模式使用本地网络源和目的地的MAC地址来做处负载均衡的决定。每种模式的具体行为在下文描述：

12.1.1 单交换机拓扑下的MT Bonding模式选择
-----------------------------------------

  这个配置是最容易配置和理解的，尽管你不得不决定哪种bonding模式对于你的需求最适合。每种模式的折衷如下所示：

balance-rr: 该模式可以允许某个单一的TCP/IP连接在多个接口上分割（stripe）流量，而且该模式是唯一支持该功能的模式。因此它也是唯一的允许单个TCP /IP流利用多于一个的接口来提高吞吐量的模式。然而这导致一定的开销，分割通常导致对端系统接收数据时乱序，从而导致TCP/IP拥堵控制机制发生作用，通常通过重发分段。

  当然也可以调整TCP/IP的拥塞限制，通过修改sysctl的net.ipv4.tcp_reordering参数即可。通常的缺省值时3，最大可用值为127。对于一个四个接口的balance-rr模式的bond，单个TCP/IP流不应期望使用超过大概2.3个接口来提高吞吐量，即使调整过 tcp_reording的值。

  请注意，这里乱序传递只在发送方和接收方都利用多个接口bond时发生。考虑这样的配置，balance-rr模式bond流入单个高容量网络通道（比如，多个100Mb/sec以太网通过具备etherchannel功能的路由器流入一个千兆以太网），这时，来自多个100Mb设备的流量发往连接着千兆设备的目的地时，将意识不到数据包的乱序。然而，来自千兆设备发往多个100Mb设备的流量，可能看到也可能看不到流量乱序，这依赖于交换机的均衡策略。很多交换机不支持分割流量的模式（而是基于IP或MAC级地址来选择一个端口），对于这些设备，从千兆设备流向多个100Mb设备时只会利用一个接口。

  如果你想使用TCP/IP以外的协议，比如UDP，而且你的应用能够容忍乱序投递，那么这种模式可以为单个流数据包提供线性性能增长，随着加入到bond里的接口数量。

  该模式要求交换机有适当的端口配置为“etherchannel”或“trunking”。

active-backup: 对于active-backup模式，在这种网络拓扑下使用并没有什么特别的好处，因为所有的未激活备份设备都作为primary连接到同样的对端。这种情况下，一种负载均衡模式（利用链路监控）将提供同样的网络可靠性，但增加了可用带宽。此外，active-backup模式不要求交换机的任何配置，因此如果当前硬件不支持任何负载均衡模式时，该模式就很有用了。

balance-xor: 该模式将限定流量，以保证到达特定对端的流量总是从同一个接口上发出。既然目的地是通过MAC地址来决定的，因此该模式在“本地”网络配置（上文曾提及）下可以工作得很好。如果所有流量是通过单个路由器（比如上文提及的“网关”型网络配置），那该模式就不是最好的选择。

  和balance-rr一样，交换机端口需要能配置为“etherchannel”或“trunking”。

broadcast: 和active-backup类似，在这种网络拓扑下该模式没有什么特别的优点。

802.3ad: 对于这种网络拓扑，该模式是一个很好的选择。802.3ad模式是IEEE标准，因此所有实现了802.3ad的对端都可以很好的互操作。802.3ad 协议包括聚合的自动配置，因此只需要很少的对交换机的手动配置（要指出的是，只有某些设备才能使用802.3ad）。802.3ad标准也要求帧按顺序（一定程度上）传递，因此通常单个连接不会看到包的乱序。802.3ad也有些缺点：标准要求所有设备在聚合操作时，要在同样的速率和双工模式，而且，和除了balance-rr模式外的其它bonding负载均衡模式一样，任何连接都不能使用多于一个接口的带宽。

  此外，linux bonding的802.3ad实现通过对端来分发流量（通过MAC地址的XOR值），因此在“网关”型配置下，所有外出（Outgoing）流量将使用同一个设备。进入（Incoming）的流量也可能在同一个设备上终止，这依赖于对端802.3ad实现里的均衡策略。在“本地”型配置下，路两将通过 bond里的设备进行分发。

  最后，802.3ad模式要求使用MII监控，因此，ARP监控在该模式下不可用。

balance-tlb: balance-tlb模式通过对端均衡外出（outgoing）流量。既然它是根据MAC地址进行均衡，在“网关”型配置（如上文所述）下，该模式会通过单个设备来发送所有流量，然而，在“本地”型网络配置下，该模式以相对智能的方式（不是balance-xor或802.3ad模式里提及的XOR方式）来均衡多个本地网络对端，因此那些数字不幸的MAC地址（比如XOR得到同样值）不会聚集到同一个接口上。

  不像802.3ad，该模式的接口可以有不同的速率，而且不需要特别的交换机配置。不利的一面在于，该模式下所有进入的（incoming）流量会到达同一个接口；该模式要求slave接口的网络设备驱动有某种ethtool支持；而且ARP监控不可用。

balance-alb: 该模式有着所有balance-tlb有的功能（以及局限性），同时，它还会均衡从本地网络对端进入的（incoming）流量（如上文的Bonding模块选项一节所述）。

  该模式唯一额外的不利在于，网络设备驱动必须支持在设备启动时改变硬件地址。

12.1.2 单交换机拓扑下的MT链路监控
---------------------------------

  链路监控的选择很大程度上依赖于你选择的bond模式。最先进的负载均衡模式不支持ARP监控，因此就只能使用MII监控（而这不能提供如ARP监控那样的高阶端到端确认）。

12.2 多交换机拓扑下的最大吞吐量
---------------------------------

  可能利用多个交换机来优化吞吐量，当它们并行地配置为两个或更多系统中间的一个独立的网络，例如：

                       +-----------+
                       |  Host A   |
                       +-+---+---+-+
                         |   |   |
                +--------+   |   +---------+
                |            |             |
         +------+---+  +-----+----+  +-----+----+
         | Switch A |  | Switch B |  | Switch C |
         +------+---+  +-----+----+  +-----+----+
                |            |             |
                +--------+   |   +---------+
                         |   |   |
                       +-+---+---+-+
                       |  Host B   |
                       +-----------+

  在这种配置情况下，交换机间相互隔离。应用这种拓扑的原因可能是，对于一个有很多主机的独立网络（比如配置为高性能的Cluster系统），使用多个小型交换机可以比使用一个大型交换机要节省费用，比如，在有24个主机的网路里，三个24口交换机会比一个72口交换机的便宜得多。

  如果要访问到这个网络外面，可以使用一个独立的主机，它有一个附加的网路设备连接到外部网络，这个主机可以充当一个网关的作用。

12.2.1 多交换机拓扑下的MT Bonding模式选择
-----------------------------------------

  实际操作时，典型的应用于这种类型的bonding模式时balance-rr。历史上，在这种网络配置下，通常的关于投递数据包乱序的警告可以通过使用某些网络适配器解决，这些适配器不进行任何包组合（通过使用NAPI，或者因为设备本身只在某些数量的包到达后才产生中断）。当使用这个功能时，balance-rr模式允许两个主机间的独立连接有效地利用多于一个接口的带宽。

12.1.2 多交换机拓扑下的MT链路监控
---------------------------------

  同样的，在实际操作中，对于这种配置最常使用MII监控，由于效率相对于可用性更优先。ARP监控在这种拓扑下也可以工作，但由于它的侦测数量随着引入系统的数量而增长（记得网络里的每个主机都需要配置），因此它相对于MII监控的优点就不值一提了。

13. 交换机行为的问题
=================================

13.1 链路建立和故障恢复的延时
---------------------------------

  某些交换机会出现不合适的行为，关于交换机报告的链路启动和关闭的时间。

  首先，当链路启动时，某些交换机可能指示链路已经启动（载波有效），但在一段时间里并没有把流量从这个接口上通过，这个延迟一般是由于某种类型的自协商或路由协议，但也可能在交换机初始化时发生（比如在交换机失败后恢复时），如果你发现这是个问题，给bonding模块的updelay选项指定一个合适的值，用于指定相关接口的延时值。

  其次，某些交换机可能一次或多次“反弹”（bounce）链路状态，当链路改变状态时。这最通常在交换机初始化时发生，同样，一个合适的updelay值可以解决问题。

  要注意的是：当bonding接口没有激活的链路，驱动会立刻重用第一个链路，即使指定了updelay参数（这时updelay被忽略），如果有 slave接口等待updelay超时，第一个进入该状态的接口会立刻被重用，这可以减少网络的断线时间，如果updelay值被设得过大，而且由于这只在没有连接时发生，就算忽略updelay也没有任何问题。

  其它的关于交换机时间的考虑在于，如果交换机需要很长时间进入备份模式，在一个链路断开后不要立刻激活备份接口可能更合适。错误恢复可以通过指定bonding模块的downdelay选项来指定延时。

13.2 Incoming包重复
---------------------------------

  有时你会发现在bonding设备第一次使用时，或在它休眠了一段时间后，会发生短暂的重复数据包爆发。这很容易通过"ping"网络中的其它主机来发现，可以发现ping的输出中有重复标记（通常每个slave重复一个）。

  比如，一个在active-backup模式下的bond，有五个slave都连接到同一个交换机，输出可能如下：

# ping -n 10.0.4.2
PING 10.0.4.2 (10.0.4.2) from 10.0.3.10 : 56(84) bytes of data.
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.7 ms
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
64 bytes from 10.0.4.2: icmp_seq=2 ttl=64 time=0.216 ms
64 bytes from 10.0.4.2: icmp_seq=3 ttl=64 time=0.267 ms
64 bytes from 10.0.4.2: icmp_seq=4 ttl=64 time=0.222 ms

  这不是由于bonding驱动的错误，这是很多交换机在更新它们的MAC转发表的一个副作用。开始的时候，交换机没有关联包里的MAC地址到一个特定的交换机端口，因此它可能把这个包发送给所有的端口，直到MAC转发表被更新。既然bond绑定的接口可能占有一个交换机上的多个端口，当交换机（临时地）给所有端口发送流量时，bond设备就会收到同一个包的多份复制（每个slave设备一份）。

  重复包行为是由交换机决定的，某些交换机有这个问题，而有些没有。如果交换机有这个问题，你可能清楚MAC转发表来发现它（在大多数Cisco交换机上，特权指令“clear mac address-table dynamic”可以清楚）。

14. 硬件相关的考量
=================================

  本节包含一些额外的信息，用于配置特定硬件平台上的bonding，或者针对特别的交换机或其它设备的bonding配置。

14.1 IBM刀片服务器（BladeCenter）
---------------------------------

  适用于JS20和类似的系统。

  在JS20刀片服务器上，bonding驱动只支持balance-rr，active-backup，balance-tlb和balance-alb模式，这主要是由于刀片服务器内部的网络拓扑所决定的，如下文所述。

JS20网络适配器信息
---------------------------------

  所有的JS20系列有两个Broadcom千兆以太网卡集成在planar（IBM这么称呼“主板”）上。在刀片的底盘（chassis）上，所有 JS20刀片的eth0端口被硬连接到#1 I/O模块，类似的，所有eth1端口被连接到#2 I/O模块。一个附加的Broadcom daughter卡可以被安装到JS20上来提供两个或更多千兆以太网卡，这些端口，也就是eth2/eth3等等，相应地被连接到#3和#4 I/O模块。

  每个I/O模块可能包含一个交换机后者一个passthrough模块（它可以让端口直连到外部的交换机）。某些bonding模式要求特定的刀片内部网络拓扑以正常工作，如下文。

  更多的刀片相关的网络信息可以在IBM红宝书上找到（www.ibm.com/redbooks）：

"IBM eServer BladeCenter Networking Options"
"IBM eServer BladeCenter Layer 2-7 Network Switching"

刀片网络配置
---------------------------------

  因为刀片可以有非常多的方法进行配置，这里的讨论将主要针对最基本的一些配置情况。

  通常，在1和2 I/O模块会里使用以太交换模块（Ethernet Switch Modules，ESM），这时，JS20的eth0和eth1端口将会连接到不同的内部交换机上（在对应的I/O模块上）。

  passthrough模块（OPM或CPM，指Optical Passthrough Modules或Copper Passthrough Modules）直接连接I/O模块到外部的交换机，通过使用#1和#2 I/O模块里的passthrough模块，JS20的eth0和eth1接口可以被重定向到外部的网络，并连接到一个外部的交换机上。

  依赖于ESM和PM的混合，展现给bonding的网络可能是一个单交换机拓扑（所有都是PM），或者是一个多交换机拓扑（一个或多个ESM，0个或多个PM），也可能把ESM连在一起，产生一个更像上文“多Switch下的高可靠性”一节描述的例子的配置。

特定模式的需求
---------------------------------

  balance-rr模式要求对bond中的设备使用PM，所有设备都连接到外部交换机上，那些交换机在对应的端口必须被配置为“etherchannel”或“trunking”，正如balance-rr通常使用时的要求一样。

  balance-alb和balance-tlb模式可以和ESM或PM（或者混合）一起工作，唯一的要求是：对这些模式，所有的网络接口必须能够到达所有通过bonding设备的流量所对应的目的地址（也就是，网络必须会聚到刀片外部的一点）。

  active-backup模式没有特别的需求。

链路监控的问题
---------------------------------

  当使用ESM时，只有ARP监控能可靠地监测到到外部交换机的链路断开，这一点也不出乎意料，但刀片cabinet考试建议“外部的”网络端口是系统的以太端口，如果这样的话，在这些“外部的”端口和JS20系统的设备间应该存在一个交换机。MII监控只能监测ESM和JS20系统间的链路异常。

----------------------------------------------------------------------------------------

  When an Ethernet Switch Module is in place, only the ARP
monitor will reliably detect link loss to an external switch.  This is
nothing unusual, but examination of the BladeCenter cabinet would
suggest that the "external" network ports are the ethernet ports for
the system, when it fact there is a switch between these "external"
ports and the devices on the JS20 system itself.  The MII monitor is
only able to detect link failures between the ESM and the JS20 system.

----------------------------------------------------------------------------------------

  当使用PM时，MII监控可以监控到“外部”端口的异常，因为这些“外部”端口是直连到JS20系统的。

其它考虑
---------------------------------

  Serial Over LAN（SoL，局域网上的串口连接）链路只能通过主以太（eth0）建立，因此如果eth0链路断开将会导致SoL连接的断开，它不会被通过其它网络流量来恢复，因此SoL系统超出了bonding驱动的控制范围。

  在使用bonding时，有可能需要关闭交换机（内部ESM，或外部交换机）的生成树功能，来避免错误恢复的延迟问题。