No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

The Ping Operation Fails Due to Unsuccessful Creation of ARP Entries on the NE40E

Publication Date:  2012-07-27 Views:  51 Downloads:  0
Issue Description

 For the topology, see the attachment.
A core network device, HLR, accesses two NE40Es (V300R003C02B608) through VRRP. In the VRRP backup group, PE1 serves as the master, and PE2 serves as the backup. The traffic sent from HLR to the upstream passes through PE1, and the traffic sent from the upstream to HLR passes through PE1 or PE2.
The two NE40Es are connected through an Eth-Trunk over which heartbeat packets and service packets are transmitted. In the outbound direction, VLANIF interfaces are bound to VRRP.
It is found that the ping from B-PE and Hub-PE2 to HLR (10.179.143.84) in city A is successful. After the HLR-related ARP entries are deleted from PE2, the ping from Hub-PE2 to HLR fails, and the HLR-related ARP entries cannot be created on PE2.
Run the debug arp command on PE2 to enable ARP debugging. The debugging result shows that after PE2 receives the ping packets from Hub-PE2, the ARP request is sent to HLR and HLR responds to the request (which is proved by the debugging result). However, the ARP entries are not created.
After that, the ping from PE2 to HLR succeeds and ARP entries can be successfully created. Then, the ping from Hub-PE2 to HLR succeeds. The same ping operation repeats three times and all the operations are successful. The ping from B-PE to HLR also succeeds.
(Note: The upstream interfaces on HLR are both Up. One serves as the master, and the other serves as the backup. The master interface is working and is connected to PE1.) 
 

Alarm Information

 Null 

Handling Process

 1. Run the debugging arp process command to view the interaction of ARP packets.
Ping HLR from Hub-PE2. The packet interaction when ARP entries fail to be created is shown below:
*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
The interaction of ARP packets during the ping from PE2 to HLR is shown below:
*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!
The ARP entry created is as follows:
10.179.143.84 0018-8299-25b1 20 DF1 Eth-Trunk1 signal
Through comparison, two differences can be found:
One is that in the first ping operation, the ARP request packet is sent from slot 8 and the ARP response packet is received by slot 1 on Hub-PE2; in the second ping operation, the ARP request packet is sent from slot 1 and the ARP response packet is received by slot 1 on PE2.
The other is that in the second ping operation, an ARP process is started on PE2 to generate ARP entries after an ARP response packet is received, and in the first ping operation, no such process is started on Hub-PE2.The associated configurations are as follows:
#
interface Vlanif11 ����VRRP is configured on VLANIF 11 connected to the 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
#
The ports in slot 1 and slot 8 belong to VLAN 11, and the arp learning strict command is configured on PE2 in the system view.
In the case that the ping from Hub-PE2 to HLR fails, the receiving and sending of ARP packets are implemented on different boards. When the arp learning strict command is configured, ARP entries cannot be learned.
3. It is confirmed that after ping packets reach PE2, the outbound interface is the VLANIF interface. If ARP is to be implemented, a member interface of the VLANIF interface is selected to forward packets, for example, an interface on the board in slot 8 in this case. Then, the board in slot 8 generates a fake ARP entry to guide forwarding for a short time (in fact, packets are discarded as guided by the entry) and then sends an ARP request. This request is sent through both the boards in slot 1 and slot 8. If the board in slot 1 receives the corresponding response, the device cannot learn ARP entries because the arp learning strict command has been configured and the board does not have any fake ARP entry. Therefore, the key is that no fake entries are generated on the board in slot 1.
This is the root cause. (On the specification list, all NE40E versions do not support the configuration of the arp learning strict command when VLANIF interfaces are concerned.)
4. Delete the arp learning strict command from PE2, and the problem is solved. 
 

Root Cause

 A check of ARP entries on PE2 shows that HLR-related ARP entries fail to be created, which leads to an unsuccessful ping operation. It is needed to find out the cause of the failed ARP creation. 

 

Suggestions

 Null 

END