5500V2 ARP

问题很明显，MSR上会删除终端IP的arp表项，当arp表项不存在时自然也就无法发送目的IP是终端IP的icmp-reply数据包了，那么为什么MSR会删除该IP地址的arp表项呢？为了进一步解决问题，我们在设备上debug arp packet和debug arp error进行进一步查看，在查看debug信息时发现了异常：

Packet discarded for ARP packet is not necessary to concerned. Interface: GE0/0  sender IP: 12.1.1.9  target IP : 12.1.1.1, VSI Index : 0, Link ID : 0

在debug信息中存在大量该报错，其中sender IP 12.1.1.9就是终端的IP地址，再出现大量该debug信息之后，MSR就删除了终端的arp表项，同时还存在另外一条debug信息也频繁出现：

*Jan  1 19:59:26:381 2011 H3C ARP/7/ARP_RCV: Received an ARP message, operation: 1, sender MAC: 0021-ccc7-e8f4, sender IP: 12.1.1.9, target MAC: 3897-d637-cdc0, target IP: 12.1.1.1

可以看到operation 为1的arp报文，其中的target MAC值并不是全0，这个并不正常，在这里了解arp报文的格式：

其中op字段即为operation字段，2个字节，4个值：

0x0001:ARP 请求

0x0002:ARP 回复

0x0003:RARP 请求

0x0004: RARP 回应当operation为1代表为arp请求报文，此时目的以太网地址应该为全0，目的IP地址为所请求的IP地址，那么目的以太网地址不为0的情况存在不存在呢？存在，免费arp的sender-mac，target-mac都一样，sender-ip，target-ip也一致，但是很明显debug信息中的并不是免费arp，arp 请求中target-mac已经存在确实不正常。为了进一步确认debug信息中的报错：Packet discarded for ARP packet，到底是什么报文导致的MSR删除arp表项，我们抓包进行了查看：

Target mac为具体的mac地址，而不是全0。终端发送了连续几个不正常的arp-request报文，之后发送了一个正常的arp-request报文（图中最后一个报文可以看到数据帧以太网头部目的mac为全f，broadcast）。问题到现在已经很清楚了，终端发送不正常的arp报文，MSR再收到多个之后删除了arp表项，此时MSR无法发送报文到终端，之后终端发送了正常的arp报文，MSR重新学习arp，此时通信恢复正常。

本地使用MSR测试时发现用户的异常报文并不会导致设备删除arp表项，客户的MSR版本较老，升级到最新版本之后客户的MSR收到异常arp不会删除arp表项，但根本原因还是客户的终端发送的arp报文异常导致。