某局点S6800当F5切换时终端arp表项更新慢问题

/

/

现场S6800设备在互联的F5设备进行主备倒换时，概率出现S6800上关于部分终端ARP更新慢的问题，现场通过手动刷新S6800的表项或者等8分钟左右表项才自动刷新。

针对前方反馈的组网信息进行梳理以及抓包，可以明确现场S6800虽然作为终端的网关，但是S6800学习终端的ARP全来源于F5代为发送的免费ARP报文，此种ARP报文的MAC地址均是F5主设备的MAC地址，因此当F5主备倒换时，F5会重新发送免费ARP报文给S6800设备，对应的MAC地址会发生切换。

在模拟复现时发现，在S6800设备上发现确实存在部分arp无法更新：

从切换前和切换后的设备softcar计数看，收到的ARP报文有大量的丢弃增长：

 ===============debug rxtx softcar show slot 1=============== 

ID  Type                RcvPps Rcv_All    DisPkt_All Pps  Dyn Swi Hash ACLmax

0   ROOT                0      77942      0          1000 S   On  SMAC 0

29  ARP                 0      37619      16340      1000 S   On  SMAC 8

  ===============debug rxtx softcar show slot 1=============== 

ID  Type                RcvPps Rcv_All    DisPkt_All Pps  Dyn Swi Hash ACLmax

0   ROOT                0      78196      0          1000 S   On  SMAC 0

29  ARP                 0      39819      18070      1000 S   On  SMAC 8

S6800每秒上送cpu能处理的arp报文时1000个，如果瞬时超过即可能导致丢弃。因此进一步抓包以明确现场F5发送ARP的方式:

通过上述抓包的时间和编号可以明确现场F5在主备切换时，在非常短的0.04秒内总共发送了1100个ARP报文，超过了设备1000PPS的能力导致拥塞丢包。

进一步和F5确认机制，现场终端110个左右，每个IP会发送5次，一次发送两个报文，因此110*5*2=1100和上述抓包吻合。

综上，现场F5主备倒换时，短时间内发送了大量arp超过了S6800的cpu处理能力导致部分终端更新失败，现场可以调大F5的发送周期解决或者更换S6805设备（5000PPS）解决。   

1.调大F5的发送周期解决

2.更换S6805设备（5000PPS）解决。