[百度分享]Bonding模块工作流程综述
最近看了一篇文章，写了一些感悟，想和大家分享一下：
  这里先说下Bonding模块工作流程综述：
  Bonding模块本质上是一个虚拟的网卡驱动（network device driver），只不过并没有真实的物理网卡与之对应，而是由这个虚拟网卡去“管辖”一系列的真实的物理网卡，所以它的代码结构和一般网卡驱动的代码结构非常类似，这是共性；除此之外，它还有自己的一些特性功能，例如特别的链路状态监控机制，绑定/解除绑定等。
  物理网卡的活动状态和链路状态
  在bonding模块中为每一个被绑定的物理网卡定义了两种活动状态和四种链路状态：注意，这里的链路状态和实际网卡真实的链路状态（是否故障、是否有网线连接）没有直接的关系，虽然bonding模块通过MII或者ARP侦测到实际网卡故障时也会改变自定义的链路状态值（例如从BOND_LINK_UP切换到BOND_LINK_FAIL随后切换到BOND_LINK_DOWN状态），但是概念上应该把这两类链路状态区分开。在本文档随后的内容中，除非特别指出，“链路状态”都指bonding模块自定义的链路状态。
  活动状态：
? BOND_STATE_ACTIVE：处于该状态的网卡是潜在的发送数据包的候选者
? BOND_STATE_BACKUP：处于该状态的网卡在选择发送数据的网卡时被排除
  链路状态：
? BOND_LINK_UP： 上线状态（处于该状态的网卡是是潜在的发送数据包的候选者）
? BOND_LINK_DOWN：故障状态
? BOND_LINK_FAIL：网卡出现故障，向状态BOND_LINK_DOWN切换中
? BOND_LINK_BACK：网卡恢复，向状态BOND_LINK_UP切换中
  一个网卡必须活动状态为BOND_STATE_ACTIVE并且链路状态为BOND_LINK_UP，才有可能作为发送数据包的候选者，注意，这里所说的数据包并不包含ARP请求，在使用ARP链路状态监控时，一个处于BOND_LINK_BACK状态的网卡也可能发送ARP请求。
bonding模块的所有工作模式可以分为两类：多主型工作模式和主备型工作模式，balance-rr和broadcast属于多主型工作模式而active-backup属于主备型工作模式。（balance-xor、自适应传输负载均衡模式（balance-tlb）和自适应负载均衡模式（balance-alb）也属于多主型工作模式，IEEE 802.3ad动态链路聚合模式（802.3ad）属于主备型工作模式。
  在多主型工作模式中，如果物理网卡不出现故障，所有的物理网卡都处于BOND_STATE_ACTIVE和BOND_LINK_UP的状态下，参与数据的收发，此时：如果工作在balance-rr模式中轮流向各个网卡发送数据，curr_active_slave字段指向前次发送数据（不包含ARP请求）的物理网卡，该指针每次发送过数据后都会切换到下一个物理网卡；在broadcast模式中向所有网卡发送数据，curr_active_slave字段除非网卡有故障发生不会切换。
  在主备型工作模式中，如果物理网卡不出现故障，只有一块网卡（活动网卡）处于BOND_STATE_ACTIVE和BOND_LINK_UP的状态下，负责数据的收发，而其他网卡（后备网卡）处于BOND_STATE_BACKUP和BOND_LINK_DOWN状态下，此时curr_active_slave字段指向当前的活动网卡。
  如果工作在active-backup模式下，可以指定一个物理网卡作为主网卡（primitive interface）,如果主网卡可用，就把主网卡作为当前活动网卡，否则在其他的可用网卡中选取一块网卡作为当前活动网卡，而一旦主网卡从故障中恢复，不管当前活动网卡是否故障都切换到主网卡。在balance-tlb和balance-alb模式中也可以指定主网卡，但是其意义和active-backup模式中并不相同。
  数据收发流程
  如果一个物理网卡被虚拟网卡绑定，则代表该网卡的数据结构struct net_device中下列字段将发生变化：
? flags字段（unsigned short）将包含IFF_SLAVE标志。
? master字段（struct net_device *）将指向虚拟网卡。
  在主备型工作模式下，所有的非活动物理网卡的flags字段还将设置IFF_NOARP标志位表示对ARP请求不做出回应。
而代表虚拟网卡的struct net_device数据结构的flags字段将包含IFF_MASTER标志。
  所有被绑定的物理网卡都将被设置相同的MAC地址和MTU值（和虚拟网卡也相同），这些值将和第一块被绑定的物理网卡保持一致（“第一块网卡”并不是一个强制条件，这是由bonding模块的启动流程造成的，我们也可以手工设置虚拟网卡的MAC地址和MTU值，这个设定同时也将用于所有被绑定的物理网卡）。另外，所有被绑定的物理网卡没有IP地址，所以不参与发送IP数据包的路由选择。
  在下面的三节中，只描述数据发送和接收过程中和bonding相关的一些特殊处理
  接收数据
  无论在何种模式下，只要物理网卡的实际链路状态正常，任何被绑定的物理网卡都可以接收数据（虽然没有IP地址，但是仍然有MAC地址），即使是处于BOND_STATE_BACKUP和BOND_LINK_DOWN状态时，这是由于BOND_STATE_BACKUP和BOND_LINK_DOWN是bonding模块自己定义的管理物理网卡所用的状态，和内核的TCP/IP栈没有任何关系，bonding模块最多在主备模式下给备用。 
  物理网卡设置IFF_NOARP标志，使它对ARP数据包不做出回应，仅此而已。
  收取数据包时，物理网卡驱动的中断处理函数把数据包放入接收队列中，随后软中断NET_RX_SOFTIRQ的处理函数net_rx_action被调用，该函数将调用接收数据包的物理网卡网卡的poll函数。
  无论一个物理网卡是否支持NAPI，函数netif_receive_skb都将在某个阶段被调用。（如果物理网卡不支持NAPI，内核使用函数process_backlog代替真实的poll调用，而process_backlog调用netif_receive_skb）。
  在netif_receive_skb函数中将调用函数skb_bond，该函数本质上作如下操作：
  if(dev->master) skb->dev = dev->master;
  即把数据包skb的物理网卡字段替换为虚拟网卡，使得该数据包看起来像是从虚拟网卡接收的一样，随后的处理和其他数据包没有任何差别，不再赘述。
  发送数据
  发送数据包时，内核根据路由选择某一个虚拟网卡作为发送接口（注意被绑定的物理网卡没有IP地址），最后调用该虚拟网卡的数据包传输接口net_device-> hard_start_xmit，注意此时该数据包中的dev字段指向虚拟网卡。net_device-> hard_start_xmit接口根据不同的工作模式指向不同的传输函数，但是无论是何种工作模式，最后bond_dev_queue_xmit函数都将被调用（以一个选定的物理网卡作为参数调用）。
  bond_dev_queue_xmit函数将作如下操作：
  skb->dev = slave_dev;
  即替换skb的dev字段为选定的物理网卡。
  随后，bond_dev_queue_xmit将调用标准的内核接口dev_queue_xmit把数据包放入选定物理网卡的发送队列中。
  ARP请求和回应
  既然被绑定物理网卡没有IP地址，那么如果接收到ARP请求之后，根据何IP地址决定是否产生应答？如果产生应答，在应答中，源IP地址应该是什么？
  答案是：被绑定物理网卡接收到ARP请求后，由于函数arp_rcv在netif_receive_skb之后被调用，而skb->dev经过netif_receive_skb的处理将指向虚拟网卡，所以是否产生应答由该物理网卡所属的虚拟网卡的IP地址决定（当然前提是物理网卡