锐捷N18012 终端ping交换机偶发丢包

一、故障现象描述

二、故障排查分析

1. 从现场的抓包来看，SDN_18K交换机在丢包时间段网络中会出现大量的ARP广播报文。

2. 通过抓取SDN_18K底层信息，针对存在大量arp广播现象进行分析发现：

• SDN_18K交换机先收到终端10.64.4.160请求终端10.64.4.52的arp请求，由于super vlan启用了arp代理功能，此时SDN_18K会做代理应答，会以arp reply报文的形式回复10.64.4.160这个终端的mac为SDN_18K的mac( 300d.9e73.e950)，访问10.64.4.52将流量时候目的mac则为300d.9e73.e950。

• 按照正常报文处理逻辑，10.64.4.160收到SDN_18K的arp代理应答完成后，则是进行正常的IP数据包转发通信，但是通过现场收集的信息进行分析，10.64.4.160再次发了一份ARP应答报文。

• 交换机收到10.64.4.160的ARP应答报文，要将该应答报文转发到目标地址10.64.4.52，此时交换机查看10.64.4.52终端的ARP表项并未携带subvlanID(未携带subvlan id的原因是10.64.4.52不在线,只有静态arp表项、未有mac地址表项)。

• 交换机会直接将应答报文在supervlanID4094发出，到快转后桥组件，桥组件通过MAC地址表寻找终端的MAC地址发现没有对应的MAC地址表后，找出口失败会在supervlan下的所有subvlan进行广播。

• 由于现场交换机上的supevlan下有3000+的subvlan，导致交换机收到该arp的reply报文会在同时发3000+的arp广播报文出。
• 从现场的DEBUG来看，该终端是每秒会发送2个的ARP应答报文到交换机，这样会让交换机在某个时间节点发出6000数量的ARP广播报文。我司交换机EFMP快转处理数量在3W左右，ARP一个泛洪报文占用了快转1/5的处理性能，加上交换机处理其他正常报文也会消耗EFMP组件性能，就导致交换机概率出现丢包情况。

3. 实验室本地环境复现：

• 终端B离线，IP：10.64.4.52 MAC：0016.6cb7.5869；内部环境模拟出该准入管控终端，没有PORT和subvlan字段情况

• 正常终端A上线，IP 10.64.4.160 5803.fb22.707C，有PORT和subvlan字段情况。

• 构造终端发送核心的ARP报文，模拟核心收到终端的reply报文

• 另外1个trunk口抓包（1/14口，允许所有vlan通过）可以看到arp泛洪流量；

• 流量以10 pps打入本地交换机，丢包率1%。此时drop计数增长；

三、故障根因说明

四、故障解决方案

1. 通过取消subvlan的arp洪泛功能，减少因arp 洪泛影响交换机性能，但是该命令需要在一个sub vlan内洪泛，一旦arp reply速率≥1000pps/秒，仍旧会有少量丢包 。

2. 版本升级，新版本支持对arp reply报文过滤，可以过滤掉arp reply报文，且目的mac是核心MAC报文。版本预计在8月底发布。