服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

如何在内核级别诊断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 […]