某局点802.11A传输延迟丢包高的问题解决办法

某局点使用WA6620X提供无线覆盖，接入各种终端使用均正常，但是现场存在一批特殊的工业级终端，在之前的文案中已经提到这些终端由于自身驱动的原因会工作在802.11A模式下。

现在发现这些终端在无线网络工作时会发生高概率的丢包和延迟现象，但是这些终端连在某款友商无线设备下则运行稳定。由此我们需要分析和找到根因。

图1

针对这个终端ping的行为，我们开启了AP的无线抓包功能，判断丢包的来源，通过在AC上执行命令：

  packet-capture  local  ap  XXX radio  X monitor-mode channel XXX write url ftp://x.x.x.x/abc.pcap username xxxxx password simple xxxxx

来实现对AP radio的收发802.11报文捕获。通过捕获这个丢包延迟的报文分析可得，这个丢包延迟是来自于终端自身的回包慢，如图2：

图2

虽然分析上认为是终端回包带来的丢包和延迟，但是现场客户却提供了友商的某款AP产品，说这款产品与这些终端配合没有出现丢包延迟的问题，需要我们再分析。在深入分析后发现友商产品在驱动机制上存在两点异常，如下：

1、友商AP能够在这个环境下与终端发送BA和QOS DATA，看起来完全没有被WMM影响，这个在无线标准中是不可能的。唯一一种解释就是友商的判断标准没有按照规范执行。如下图：

图3

2、终端在友商产品下表现ping稳定，h3c环境下ping延迟丢包厉害，怀疑与友商产品及其反常的降速重传有关。如下图4：

图4

而这种第一个包不通之后立刻降速重传的行为，完全不是协议规范建议的做法（大部分无线设备都会尽力保持高速协商，因此重传都只会按照最高速率，只有失败多次才会降速）。对其他应用的吞吐性能影响很大，但是确实能保证报文的连通性。可以看见在友商环境下无线的高速率报文对于终端依然会丢包，但是友商产品靠着立刻降速重传赢得了稳定性。

对比一下H3C环境下的重传速率，如图5：

图5

H3C环境下重传一直按照最高速率发送，直到多次失败后才可能考虑降速（否则高吞吐性能会受到严重影响） 图中连续的54M重传终端并没有处理，显然遇到了和友商无线环境下首包没有响应一样的情况，只不过友商产品反常的降速重传与H3C不同。

针对上述的分析，H3C可以应对的调整方案：

找到了问题的结症，那么手段自然就出现了——关闭高速率协商，强制终端工作在低速协商下。 配置就如下所示：

按照这个配置手法，测试了多个信道非常稳定。与友商产品的表现相当。

在这个问题上

首先是这些特殊终端没有按照协议规范指定工作模式，因此终端自己错误的工作在802.11A模式下；

而且对无线的信噪比容忍度较差，高阶的编码报文如54Mbps 容易丢失，需要简单的编码方式如36Mbps以下才有机会传输成功。

再然后是友商产品反常的降速重传机制刚好误打误撞的与其完美兼容，按照现场反馈的信息（适配过多家无线产品，就这家厂商的这款产品兼容好一些）。

我们通过无线抓包分析了其内在的原因，找到了根因得出的解决办法就能直击要害。对症下药。