Intel万兆网卡背靠背连接ping不通那点事儿

Posted 2020-09-28 veli

对那些整天喊着“玩大的，玩狠的”口号的人来说，Intel万兆网卡背靠背连接ping不通那点事儿，根本就不算个事儿。所以，如果你正好是喜欢喊口号的朋友，就不要往下看了，因为我要讲述的，你可能不感兴趣，也很可能看不懂。

今天，是我加入I公司3个多月以来最有成就感的一天，因为打赢了一个硬仗。1个多月以前，我所在的项目小组给我分配了一个bug,  该bug可简单描述为：两张Intel 82599的万兆网卡，通过光纤背靠背连接后，彼此ping不通。从接受任务到今天，一共持续了33天，其间多次被各种杂事儿所打断，但总的投入时间累计也至少有8个工作日。直到今天，我才真正定位了这个bug的root cause(I公司称之为根因 Orz)，真是“山重水复疑无路，蓦然回首，那人却在灯火阑珊处”。 既然玩不了大的，也玩不了狠的，咱就玩点实在的吧。

1. 问题概述

存储结点Ann与应用主机结点Ben上各有一张Intel 82599万兆网卡（ixgbe), 网卡与网卡之间使用光纤背靠背连接。在A结点和B结点都给网卡的Interface配置上IPv4地址，彼此无法ping通。

[NODE Ann]
	eth1: 00:25:64:ba:8d:be : 192.168.53.110
	eth2: 00:25:64:ba:8d:bd : 192.168.54.110

[NODE Ben]
	eth1: 00:25:63:ba:8d:be : 192.168.53.100
	eth2: 00:25:63:ba:8d:be : 192.168.54.100

2. 定位过程

• 01 在应用主机结点Ben上ping -I 192.168.53.100 192.168.53.110; 然后在Ben上使用tcpdump抓包，用wireshark查看，发现arp请求包从Ben发出，但未收到arp响应包； （令人痛苦的是，存储结点Ann上没有tcpdump,只能从应用主机上单方面抓包）
• 02 在Ann和Ben上手工配置arp记录，再ping, 可以相互ping通，说明网卡，光模块和光纤都没有问题，排除硬件故障；
• 03 检查Ann和Ben上的万兆网卡驱动（ixgbe.ko), 发现Ben上的网卡驱动版本比较低，于是升级Ben的操作系统，与Ann保持一致，再ping, 还是ping不通；
• 04 检查Ann和Ben上有没有SELinux设置，Ann没有，Ben有；于是关闭Ben上的SELinux设置，再ping, 还是ping不通；
• 05 检查Ann和Ben上有没有防火墙firewalld, Ann没有，Ben有；于是关闭Ben上的firewall设置病重启，再ping, 还是ping不通；
• 06 检查Ann和Ben上有没有iptables服务，Ann没有，Ben也没有；
• 07 在Ben上安装dropwatch, 启动一个ping -I 192.168.53.100 192.168.53.110; 然后启动dropwatch, 发现有丢包，而是与arp错误密切相关，但是丢包原因不清楚；
• 08 坐下来研读ARP协议（RFC826） （耗时1个周末);
• 09 使用arping从Ann上向Ben发出arping, 成功；再使用arping从Ben上向Ann发出arping, 失败；好了，于是可以90%确定为是存储结点Ann的问题；
• 10 在存储结点Ann上查看arptables服务，发现正在运行，再使用arptables -L查看规则，发现了4条DROP的规则，与Ann上的82599网卡对应的网络接口正好对应，于是99%确定为存储结点Ann的问题;
• 11 在存储结点Ann上搜索源代码，找到root cause，原来是存储软件在启动的时候，发现82599网卡对应的网络接口（eth1, eth2）并没有配置IPv4地址，于是设置ARP规则将eth1, eth2的inbound和outbound的ARP包都通通drop掉，因此，从应用主机Ben上发出arp请求广播包，没有收到arp响应包就很好理解了。Ben发出去的arp请求包石沉大海，是因为被Ann设置的ARP规则给drop掉了。