The networking was as follows:
The two NE80Es formed a VRRP group to provide redundant gateway services for the connected service server. The service server failed to ping the interconnection port on the master NE80E and the NE80E did not learn the ARP entries on the service sever but learned the MA C address of the service server.
Huawei excluded the link fault as the issue cause because the MAC address of the service sever could be learned and then confirmed that the issue was caused by errors in ARP packet exchanges.
To address the issue, Huawei performed the following operations and observed the following information:
1. Enabled STP on devices on a ring topology, but the issue persisted.
2. Ran the debug arp packet command to check whether the equipment configuration caused the error in ARP packet exchanges.
*0.3964282271 xxxx-CE-1.CDMA ARP/7/arp_send:Slot=1;Send an ARP Packet, op
eration : 1, sender_eth_addr : xxxx-xxxx-xxxx,sender_ip_addr : 10.255.192.66, ta
rget_eth_addr : 0000-0000-0000, target_ip_addr : 10.255.192.90
*0.3964282271 xxxx-CE-1.CDMA ARP/7/arp_rcv:Slot=4;Receive an ARP Packet,
operation : 2, sender_eth_addr : xxxx-xxxx-xxxx, sender_ip_addr : 10.255.192.90,
target_eth_addr : xxxx-xxxx-xxxx, target_ip_addr : 10.255.192.66
The information showed that ARP packets were sent from the board in slot 1 but reply packets were received at the board in slot 4. As a result, the corresponding ARP entry was not learned on the NE80E and the ping operation failed.
3. Checked the NE80E configuration and found the arp learning strict command was run, which meant if ARP packets were sent from board A but reply packets were received at another board, the corresponding ARP entry would not be learned.
The arp learning strict command configuration enabled the device to strictly check the ingress and egress boards of ARP packets and to learn an ARP entry only when the ingress and egress boards were the same.
Undo the arp learning strict command.