AP-ONU-OLT组网本地转发模式下特定报文丢失问题排查

AC旁挂核心，（WA6500a）面板AP-ONU-OLT光网络组网，本地转发。

无

（WA6500a）面板AP下关联的无线终端和其下行口连接的有线终端，偶发随机出现TCP报文丢失或不通的情况，同一时间同一终端ping故障节点IP地址不会出现丢包。

由于是本地转发，AP下有线和无线终端访问的故障节点的流量不经过AC，因此只需关注终端—AP—ONU—OLT—故障节点之间的报文流量。

由于是光网络无法在中间链路配置传统的镜像抓包，因此只能尝试利用设备自带的抓包或者debug功能来捕获报文进行分析。

首先一线找到了交换机侧，在OLT上抓包或流统等操作发现：故障时刻终端和需访问的节点之间的icmp，TCP等报文均被正常处理和转发了，因此找到无线侧要求排查。

由于现场使用的WA6500a AP版本很老，而且暂时也不方便升级，而AP也暂无抓包的功能，因此想到了使用AP packet debug的方法在AP上开启mac-forward，wlan-forward和ar5drv（驱动）debug搜集故障时候终端与节点之间的报文交互，并使用链接：

https://zhiliao.h3c.com/Tool/details/5249的工具进行报文解析，从而快速定位问题。

请知，在使用该debug方法的时候，

① 如果是收集该AP关联的无线终端，则需要同时收集故障终端：ar5drv，wlan-forward和mac-forward的debug报文，这是因为无线终端发送的报文首先到达AP的底层驱动后，在上送平台转发时候报文会经过ar5drv并被debug打印出来，然后报文在wlan转发平台侧被处理，从而被wlan-forward的debug打印记录到，最后通过有线侧转发被mac-forward打印记录到，最终通过AP的有线口上送，如果是下行报文则方向相反，可据此类推。

② 如果是收集该面板AP下行有线口连接的有线终端，则只需打印mac-forward的debug报文即可，这是由于有线终端的流量不经过wlan-forward的无线平台转发和ar5drv的无线驱动转发。

## 注意：由于debug是经过AP的CPU处理的，因此若AP工作在NSS硬转或者其它硬转模式，则流量报文可能不会被wlan-forward或者mac-forward的debug日志记录。

由于现场的WA6500a使用比较老的版本，在该版本下AP是工作在CPU软转模式下的，因此报文均能被记录到，恰好此时有人反馈某WA6500a面板AP下一个有线终端出现了ping某个地址不丢包且延时低，但是TCP类型报文不通的问题，并反馈了故障有线终端的mac地址（连接在AP的GE1/0/4下行口上），于是在AP上开启如下mac-forward debug的命令并复现故障记录：

[AP-Probe] debugging system internal mac-forwarding packet content 90:f0:52:98:20:5c

<AP> debugging mac-forwarding packet

<AP> debugging mac-forwarding error

分析过程如下：

1. 该AP上的所有TCP报文呈现从GE1/0/4口收到报文，然后从GE1/0/1口（AP上行有线口，连接ONU）发出，TCP报文的源IP均是???(保密)，推测是测试终端的IP地址，但是GE1/0/1口没有收到来自有线侧的TCP回复报文。

2. 不同的是icmp报文，AP的mac-forward显示即有从GE1/0/4口收到的，然后通过GE1/0/1口转发至有线侧，然后AP收到了来自有线侧的回复报文，并通过GE1/0/4口发送至终端。

 上述mac-forward debug反映的结果和实际故障现象（ping包不丢，但是TCP报文不通）完全一致，可以说明AP对于报文的处理和转发是正确的，而TCP报文不同的原因应当是AP没有收到来自有线侧的TCP回复报文，或者有线侧处理有问题导致没有回复报文，从目前来看后者的可能性更大。

后经交换侧排查发现现场使用的老ONU版本确实存在已知问题导致TCP报文的vlan被错误处理而没有被正确转发，TCP报文实际在ONU上丢失。

交换机侧ONU排查和解决其自身软件故障。