配置ARP严格学习导致PING不通问题

发布时间:  2012-12-13 浏览次数:  117 下载次数:  0
问题描述

核心网设备HLR通过vrrp的方式接入两台NE40E(版本V300R003C02B608),其中PE1为master,PE2为backup,业务上行走PE1,回程流量到PE1或者PE2上,两台NE40E间使用eth trunk互联,走心跳报文和业务流量。
  首先发现,从B-PE和Hub-PE2 ping A城市HLR(10.179.143.84)时都可以通,之后将PE2上的HLR相关的ARP表项目删除后,发现从Hub-PE2 ping不通HLR,HLR的arp表项在PE2上不能建立,在PE2上的打开debug arp开关,发现PE2在收到来自Hub-PE2的ping包后已经触发了arp申请到HLR,而且HLR也回(并且从debug信息看设备已经收到了),但是没有HLR的arp表项创建,然后直接在PE2上ping HLR,arp表项创建成功,之后Hub-PE2 ping HLR正常,同样的测试做了3次,现象一致。而从B-PE一直能ping通HLR。
(注:HLR上行为主备,端口均up,但只有主用端口在工作,在本文中主用端口连PE1)

 

处理过程
 

1.经在PE2上查看arp,发现HLR相关的arp表项不能建立,这是ping不通的直接原因,需要找到ARP表项不能生成的根因;

2.使用debugging arp process查看arp报文交互情况
在Hub-PE2 ping HLR,且arp表项不能建立时的报文交互如下:收到了来自HRL的ARP reply报文,但是没能生成对应的ARP表项。
*0.2908861836 PEBGL02 ARP/7/arp_send:Slot=8;Send an ARP Packet, operation : 1, sender_eth_addr : 0018-829b-e981,sender_ip_addr : 10.179.143.83, target_eth_addr : 0000-0000-0000, target_ip_addr : 10.179.143.84
*0.2908861930 PEBGL02 ARP/7/arp_rcv:Slot=1;Receive an ARP Packet, operation : 2, sender_eth_addr : 0018-8299-25b1, sender_ip_addr : 10.179.143.84, target_eth_addr : 0018-829b-e981, target_ip_addr : 10.179.143.83


从PE2上ping HLR时的arp报文交互如下,能建立正常的ARP表项。
*0.2909001160 PEBGL02 ARP/7/arp_send:Slot=1;Send an ARP Packet, operation : 1, sender_eth_addr : 0018-829b-e981,sender_ip_addr : 10.179.143.83, target_eth_addr : 0000-0000-0000, target_ip_addr : 10.179.143.84
*0.2909001161 PEBGL02 ARP/7/arp_rcv:Slot=1;Receive an ARP Packet, operation : 2, sender_eth_addr : 0018-8299-25b1, sender_ip_addr : 10.179.143.84, target_eth_addr : 0018-829b-e981, target_ip_addr : 10.179.143.83
*0.2909001161 PEBGL02 ARP/7/arp_process:Slot=1;The arp process, IP: 10.179.143.84, the process function: ETHARP_ProcArpEntryFromOtherLPU , the information: main board /IO board receive arp from other board!

正常建立的arp表项:
10.179.143.84   0018-8299-25b1  20        DF1         Eth-Trunk1     signal
通过比较可以发现两点不同:
一是,前者从slot8发出arp 请求报文,从slot1收到arp的响应报文;后者从slot1发出arp 请求报文,从slot1收到arp的响应报文;

二是,后者收到arp响应报文后,启动了arp_process来生成表项,而前者没有。
经查看配置,发现:
#
interface Vlanif11 -----------捆绑arrp和HLR互联
 description ** HLR Signal **
 ip binding vpn-instance signal
 ip address 10.179.143.83 255.255.255.240
 vrrp vrid 11 virtual-ip 10.179.143.81
#
有slot1和slot8的端口同时属于vlan11,并且PE2在系统模式下配置了arp learning strict。
在Hub-PE2 ping不通HLR的情形下,arp报文的收发在不同的单板上,在配置了arp learning strict的情况下,造成学习不到arp。

3.经确认,ping报文到达设备PE2后,发现出口为vlanif,如果arp,则选择vlanif的一个成员口,例如本文中的8号板,此时会在8号板先产生一个假的arp表项,临时指导转发(其实是把当前的报文丢弃),然后发送ARP请求,此请求会在1号板和8号板都发出,arp应答如果从1号板收到的话,则由于1号板没有假的arp表项,在配置了严格学习的情况下,造成了无法学习到arp。这个问题的关键在于1号单板没有生成假表项。
至此,问题根因找到。(在规格列表上,当前NE40E所有版本均不支持vlanif的场景下配置arp learning strict) 

根因
 

ARP严格学习配置导致ARP表学习失败

解决方案
配置ARP严格学习要注意使用场景。
建议与总结
配置ARP严格学习要注意使用场景。

END