某局点终端频繁出现到网关不通问题处理经验案例

典型AC-FITap 组网，集中转发，网关在核心交换机上

某局点反馈该局点所有PC频繁出现到外网丢包，到网关不通的问题，且每次丢包一般短时间内就能恢复，已经做过网络优化，终端信号强度、AP空口利用率以及协商速率均正常。

和客户沟通，客户反馈问题现场与某桌面管理软件强相关，只要安装该软件，就会出现这个问题。但是用有线网或者更换tp-link就没有问题。初步怀疑使用我司无线环境时，和该桌面软件配合会有兼容性问题。经过抓包分析，当PC出现丢包时， PC上没有网关的ARP信息（PC地址为10.3.92.247，网关地址为10.3.92.1），也就无法封装数据包与外界通信：

结合其他抓包信息，发现PC发出了ARP请求报文，请求网关的mac，但是没有收到相应的ARP应答报文，所以PC的网关mac会被老化掉：

经过以上分析，发现由于网关没有给PC终端回复ARP应答报文，导致PC上网关的ARP超时老化，导致丢包。后续排查网关为什么不回复ARP应答报文。结合异常终端抓包分析，发现安装该桌面软件的PC终端，每隔60秒会使用ARP REQUEST广播报文请求本网段内的所有地址，如下图：

进一步在AC上起同网段地址测试发现，终端到网关丢包的时候实际上到AC是正常的。这时候就得怀疑是不是网关设备（我们V5的105）是否存在arp保护功能。通过查看配置发现并没有arp-filter等arp保护的相关配置。也就是说应该和arp保护无关。进一步就需要考虑交换机对arp报文的处理机制了，由于ARP报文会经过交换机的CPU处理，所以交换机为了保护CPU处理正常的业务报文或协议报文，防止ARP报文攻击，默认会对每个槽位设置一个保护值（当前设备是100），一旦该槽位收到的ARP报文超过该值，就会丢弃ARP报文。经过现场查看S105交换机上无线控制器AC所在槽位（slot 7）的ARP上送CPU的情况和丢弃情况，发现已经超过了100，为376 pps，并且有大量的ARP被丢弃，大约10亿左右：

 为了进一步验证是否由于该桌面软件的定期扫描影响无线用户使用，在桌面管理软件的服务端将定期扫描的策略关闭，在核心上查看交换机对ARP报文的处理情况，发现该值为19，小于100：

基于当前环境，发现有线用户以及连接tp用户安装该桌面软件时，不会出现丢包。根据以上分析，排查交换机有线用户接入槽位的ARP报文统计情况，查看各业务槽位的ARP统计情况，明显小于100，见下图：

至此，基本确认清楚。无线有问题是因为无线用户较多，且均安装有该软件，因此其arp扫描报文相对于有线侧要多很多，更容易触发arp限速阈值。tp没问题是因为其无线业务网关在ap本身，且一般关联一到两个终端，因此不存在此类问题。

 同软件厂商相关人员确认该扫描策略的作用，并建议关闭不必要的扫描策略