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報文異常導致。