问题描述
近期同事转来一个 case ,说是在测试环境上线主备负载均衡设备,无法正常形成 HA,检查发现主备设备之间无法 ping 通,诡异的是主备负载均衡设备直连接在一组核心堆叠交换机上,同属于一个 Vlan,近似直连不通,而同 Vlan 或跨 Vlan 的其他主机到主备负载均衡设备均能正常 ping 通,问题仅存在于主备设备之间。
网络拓扑如下
设备 | IP | MAC |
LB-01 | 10.0.0.1 | 4b:00:05:92:01:02 |
LB-02 | 10.0.0.2 | 4b:00:05:92:00:09 |
问题分析
考虑到网络拓扑、网络配置和故障现象极其简单,验证的方式也很明确,确认数据包丢在哪即可。
LB-01
数据包文件如下,简要分析:
- LB-01 设备上 LB-02 的 ARP 信息正常;
- LB-01 发起 ICMP Request ,但是没有 ICMP Response 回来,所以 Ping 结果不通;
- LB-01 收到 LB-02 发来的 ARP 广播请求,查询 LB-01 的 MAC 地址,LB-01 正常返回 ARP 响应。但该过程持续不断,疑似 LB-02 并没有收到响应。
LB-02
数据包文件如下,简要分析:
- LB-02 设备上始终无 LB-01 的 ARP 信息;
- LB-02 不断发起 ARP 广播请求,查询 LB-01 的 MAC 地址,但无法接收到来自 LB-01 的 ARP 响应;
- LB-02 设备上也无法收到来自 LB-01 的 ICMP Request 数据包。
结合 LB-01 和 LB-02 的数据包文件分析,可基本推断出数据包丢失在中间交换机上,疑似 LB-01 的数据包均未能正常转发至 LB-02 ,进一步在交换机上进行抓包分析。
Switch
交换机为 H3C S6800 型号,两台采用 IRF 堆叠,镜像源端口 Te1/0/42 和 Te2/0/42 后,在 LB-02 上做了一次 Ping 操作后,所抓取到的数据包文件,简要分析如下:
- 数据包 1 为交换机连接 LB-02 的端口入方向上抓取到的 LB-02 发起的 ARP 广播请求,查询 LB-01 的 MAC 地址,证明交换机能正常收到;
- 数据包 2 为交换机连接 LB-01 的端口出方向上抓取到的 LB-02 发起的 ARP 广播请求,查询 LB-01 的 MAC 地址,证明交换机能正常转发;
- 数据包 3 为交换机连接 LB-01 的端口入方向上抓取到的 LB-01 响应 LB-02 ARP 请求的响应单播数据包,证明交换机能正常收到;
- 但之后交换机却并没有将数据包 3 正常转发给 LB-02 ;
- 此过程循环 4 次,为 Ping 操作持续请求 ARP 信息过程。
之后向 H3C 厂商开 case 后,通过如下流统配置得到同样现象,仅在 Te1/0/42 端口入方向匹配到 4 个 ARP 响应包,但是没有在 Te2/0/42 端口出方向匹配到任何 ARP 响应包。
acl mac 4000
rule 0 permit type 0806 ffff source-mac 4b00-0592-0102 ffff-ffff-ffff dest-mac 4b00-0592-0009 ffff-ffff-ffff
rule 1 permit type 0806 ffff source-mac 4b00-0592-0009 ffff-ffff-ffff dest-mac 4b00-0592-0102 ffff-ffff-ffff
#
traffic classifier arp operator and
if-match acl mac 4000
#
traffic behavior arp
accounting packet
#
qos policy arp
classifier arp behavior arp
#
interface ten-GigabitEthernet1/0/42
qos apply policy arp inbound
qos apply policy arp outbound
#
interface ten-GigabitEthernet2/0/42
qos apply policy arp inbound
qos apply policy arp outbound
#
<Switch>dis qos policy interface ten-g1/0/42
Interface: Ten-GigabitEthernet1/0/42
Direction: Inbound
Policy: arp
Classifier: arp
Operator: AND
Rule(s) :
If-match acl mac 4000
Behavior: arp
Accounting enable:
4 (Packets)
Interface: Ten-GigabitEthernet1/0/42
Direction: Outbound
Policy: arp
Classifier: arp
Operator: AND
Rule(s) :
If-match acl mac 4000
Behavior: arp
Accounting enable:
0 (Packets)
<Switch>dis qos policy interface ten-g2/0/42
Interface: Ten-GigabitEthernet2/0/42
Direction: Inbound
Policy: arp
Classifier: arp
Operator: AND
Rule(s) :
If-match acl mac 4000
Behavior: arp
Accounting enable:
0 (Packets)
Interface: Ten-GigabitEthernet2/0/42
Direction: Outbound
Policy: arp
Classifier: arp
Operator: AND
Rule(s) :
If-match acl mac 4000
Behavior: arp
Accounting enable:
0 (Packets)
问题总结
后续经 H3C TAC + 研发进行流统以及故障诊断排查后,初步判断为交换机软件版本 BUG,重新换了一个通用稳定版本引导重启后,主备负载均衡设备即恢复正常通讯。
该问题很少见,但排查定位较简单,主要是合理判断丢包点,对于源端目的端需要证明能发能响应,中间设备需要证明能收也能转发。