问题描述

近期同事转来一个 case ,说是在测试环境上线主备负载均衡设备,无法正常形成 HA,检查发现主备设备之间无法 ping 通,诡异的是主备负载均衡设备直连接在一组核心堆叠交换机上,同属于一个 Vlan,近似直连不通,而同 Vlan 或跨 Vlan 的其他主机到主备负载均衡设备均能正常 ping 通,问题仅存在于主备设备之间。

网络拓扑如下

相同vlan互通实验 相同vlan不能通信_tcp/ip

设备

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

数据包文件如下,简要分析:

  1. LB-01 设备上 LB-02 的 ARP 信息正常;
  2. LB-01 发起 ICMP Request ,但是没有 ICMP Response 回来,所以 Ping 结果不通;
  3. LB-01 收到 LB-02 发来的 ARP 广播请求,查询 LB-01 的 MAC 地址,LB-01 正常返回 ARP 响应。但该过程持续不断,疑似 LB-02 并没有收到响应。

相同vlan互通实验 相同vlan不能通信_网络_02

LB-02

数据包文件如下,简要分析:

  1. LB-02 设备上始终无 LB-01 的 ARP 信息;
  2. LB-02 不断发起 ARP 广播请求,查询 LB-01 的 MAC 地址,但无法接收到来自 LB-01 的 ARP 响应;
  3. LB-02 设备上也无法收到来自 LB-01 的 ICMP Request 数据包。

相同vlan互通实验 相同vlan不能通信_相同vlan互通实验_03


结合 LB-01 和 LB-02 的数据包文件分析,可基本推断出数据包丢失在中间交换机上,疑似 LB-01 的数据包均未能正常转发至 LB-02 ,进一步在交换机上进行抓包分析。


Switch

交换机为 H3C S6800 型号,两台采用 IRF 堆叠,镜像源端口 Te1/0/42 和 Te2/0/42 后,在 LB-02 上做了一次 Ping 操作后,所抓取到的数据包文件,简要分析如下:

  1. 数据包 1 为交换机连接 LB-02 的端口入方向上抓取到的 LB-02 发起的 ARP 广播请求,查询 LB-01 的 MAC 地址,证明交换机能正常收到;
  2. 数据包 2 为交换机连接 LB-01 的端口出方向上抓取到的 LB-02 发起的 ARP 广播请求,查询 LB-01 的 MAC 地址,证明交换机能正常转发;
  3. 数据包 3 为交换机连接 LB-01 的端口入方向上抓取到的 LB-01 响应 LB-02 ARP 请求的响应单播数据包,证明交换机能正常收到;
  4. 但之后交换机却并没有将数据包 3 正常转发给 LB-02 ;
  5. 此过程循环 4 次,为 Ping 操作持续请求 ARP 信息过程。

相同vlan互通实验 相同vlan不能通信_网络协议_04

之后向 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,重新换了一个通用稳定版本引导重启后,主备负载均衡设备即恢复正常通讯。

该问题很少见,但排查定位较简单,主要是合理判断丢包点,对于源端目的端需要证明能发能响应,中间设备需要证明能收也能转发。