如何在内核级别诊断Linux LACP问题?

是否有一个底层的pipe理或诊断接口,以确定在内部发生了什么?

我已经使用Linux机箱和Cisco交换机之间的链路聚合多年。 在设置新的方框时,Linux端不会响应思科LACP数据包,我定期遇到死胡同。 我一丝不苟地按照每个服务器的严格的指示,但结果似乎有所不同。

无论绑定是否包含一个或八个从属节点,tcpdump会显示所有绑定接口上来自交换机的LACP数据包,并且不会传回任何数据包。 实际上,没有数据包正在传输期间。 接口的rx_packets显示可观的stream量,但tx_packets为零。 有关MII或绑定的日志中没有什么有趣的。 甚至没有任何错误。

目前,我正在处理一个只有两个nics的盒子。 目前,我在债券中只有eth1。 显然,这是一个退化的configuration。 债券中的eth0和eth1都没有改变。 在networking堆栈完全closures的情况下,使机器难以使用。 如有必要,我可以重新configuration这两个nics,并通过一个pipe理界面(DRAC),但是我不能以这种方式复制粘贴。

一些预备:

  • 我testing了nics,端口和电缆。 当接口没有绑定时,一切都按预期工作。
  • 我已重新启动并确认模块已正确加载。
  • 我已经试过这个和没有vlan中继, 链路聚合发生在堆栈中的那一点以下,这应该不重要。
  • 交换机有工作,集群通道组转到其他Linux机器。 即使Linux机箱的发行版,内核和硬件不相同,configuration也是相同的。

这是今天下载的debian 8.6。

 Linux box 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux 

缩写configuration:

 iface eth1 inet manual auto bond0 iface bond0 inet manual slaves eth1 address 10.10.10.10 netmask 255.255.255.0 bond_mode 4 bond_miimon 100 bond_downdelay 200 bond_updelay 200 bond_xmit_hash_policy layer2+3 bond_lacp_rate slow 

有些州:

 # cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: IEEE 802.3ad Dynamic link aggregation Transmit Hash Policy: layer2+3 (2) MII Status: down MII Polling Interval (ms): 100 Up Delay (ms): 200 Down Delay (ms): 200 802.3ad info LACP rate: slow Min links: 0 Aggregator selection policy (ad_select): stable bond bond0 has no active aggregator Slave Interface: eth1 MII Status: down Speed: 1000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 78:2b:cb:5a:2b:3e Aggregator ID: N/A Slave queue ID: 0 

来自交换机eth1的入站tcpdumplogging:

 22:18:47.333928 M 44:ad:d9:6c:8d:8f ethertype Slow Protocols (0x8809), length 126: LACPv1, length 110 Actor Information TLV (0x01), length 20 System 44:ad:d9:6c:8d:80, System Priority 32768, Key 12, Port 272, Port Priority 32768 State Flags [Activity, Aggregation, Synchronization, Collecting, Distributing, Default] Partner Information TLV (0x02), length 20 System 00:00:00:00:00:00, System Priority 0, Key 0, Port 0, Port Priority 0 State Flags [none] Collector Information TLV (0x03), length 16 Max Delay 32768 Terminator TLV (0x00), length 0 

思科方面:

 interface GigabitEthernet1/0/15 switchport trunk allowed vlan 100,101,102 switchport mode trunk channel-group 12 mode active end interface Port-channel12 switchport trunk allowed vlan 100,101,102 switchport mode trunk end 

最终,交换机放弃,接口进入“独立”模式。 如果通道组中有两个接口,则它们进入独立模式。

 #show etherchannel 12 sum Flags: I - stand-alone Group Port-channel Protocol Ports ------+-------------+-----------+----------- 12 Po12(SD) LACP Gi1/0/15(I) 

我整天都在绞尽脑汁。 我已经拆除了几次,重新构build了Ciscoconfiguration。 如果不是tcpdump显示LACPv1数据包到达Linux接口,我将会看到思科端。 唉,Linux内核似乎完全忽略了数据包。 我的下一站是内核源代码,最坏的情况是用于诊断的自定义内核。 希望有人对绑定驱动有一些了解,以及它是如何正确运行的。

尝试在Linux端设置下一个LACP属性到:

 bond_downdelay 0 bond_updelay 0 bond_xmit_hash_policy layer3+4 bond_lacp_rate fast 

在Cisco侧重新创build端口信道并使LACP的速率更快:

 port-channel load-balance src-dst-ip interface GigabitEthernet1/0/15 lacp rate fast exit 

如果Cisco交换机无法lacp rate fast设置lacp rate fast则需要更新其IOS。

思科和LACP一起工作比Linux更差。 如果您的思科交换机可以,请设置port-channel load-balance src-dst-port

绑定驱动程序不会将任何LACP状态机debugging公开给用户空间,您需要知道代码并使用像SystemTap这样的内核工具,或者将自己的debugging写入您自己的绑定模块中,并为您的内核进行编译。

但是,问题是键合驱动程序认为从属closures:

 MII Status: down 

你说你有信心奴隶有链接,所以我们会忽略一个物理问题。

绑定/从属设备configuration不正确,从属设备处于pipe理closures状态,或者正在使用的驱动程序不支持netif_carrier()样式链路检测,并且需要在绑定模块的选项中设置use_carrier=1