SR-IOV的限制之端口聚合

• PAgP: Cisco私有协议
• LACP: 基于IEEE 802.3ad的国际标准

在测试SR-IOV VF与CISCO 交换机作LACP端口聚合的过程中, 遇到了下面一些问题.

测试

从上面的测试结果上看:

• 当LACP DISABLE时, 所有的测试都通过.
• 当LACP ENABLE时:
  • 在一个VM里面, 把VF 1.1和VF 1.2做绑定时, 测试失败
  • 在一个VM里面, 把VF 1.1和VF 2.1做绑定时, 测试成功
  • 在一个VM里面, 把VF 1.1和VF 2.1做绑定, 且把VF 1.2和VF 2.2做绑定, 测试失败

注:

• 上图来自QA同事的测试结果
• 上面的测试主要涉及两个PF, 每个PF有4个VF

PF1: VF 1.1, VF 1.2, VF 1.3, VF 1.4
PF2: VF 2.1, VF 2.2, VF 2.3, VF 2.4

• 上面测试失败的现象都是交换机的接口显示是Down状态.
• lacp_disable 对应的CISCO的CLI是:

config#channel-group [number] mode on

其官方的解释如下:

Enables EtherChannel only, and it forces the bundling of the interface on the channel without any negotiation.

• lacp_enable 对应的CISCO的CLI是:

config#channel-group [number] mode active

其官方的解释如下:

Enables LACP unconditionally.

• 上面的测试用例可能没有任何意义, 仅仅为了测试而测试.

原因

因为现代的交换机不支持SR-IOV(换句话说, 就是现代的交换机不知道什么PF, VF之类的信息), 一物理端口对于交换机来说就是一个口，正常的情况下, 一个物理端口不会发送过来两个或两个以上的不同的LACP包. 然而, 在SR-IOV下, 真的有可能会出现一个物理端口(PF)的不同的VF发送不同的LACP包, 当这种情况出现时, 交换机就认为出现了异常, 主动的把自己的端口置为DOWN的状态.

解决方案

在交换机没有很好的支持SR-IOV之前, 下面这个方案可以解决这个问题(虽然比较脏):

• 在HOST, 把PF做BOND(此BOND的功能是负责与交换机的LACP协商).
• 在Guest OS, 再把VF做BOND(此BOND不应负责与交换机的LACP协商, 为了不让其参与LACP协商, 应该给每个GUEST OS做代码上改动)

上面这个方案有几个明显的不足:

• 在GUEST OS里面需要把发送LACP协商包的代码去掉.就是说要修改GUEST OS的相关代码
• 配置复杂: 要在HOST和GUEST两层配置BOND
• 配置不灵活: 比如在HOST这层把port1和port2做了BOND, 那么就应该在GUEST OS里面要么不做BOND,要么把port1对应的VF和port2对应的VF做BOND.

Linux下LACP BOND的模式是4

参考

• http://www.cnblogs.com/zoulongbin/p/6654545.html
• https://www.jannet.hk/zh-Hant/post/etherchannel-pagp-lacp/#lacp
• https://serverfault.com/questions/546439/can-switch-handle-multiple-lacp-teams-on-the-same-ports
• https://www.cisco.com/c/en/us/td/docs/routers/7600/ios/12-1E/command/reference/cmdref/c1.pdf