Questo sito utilizza cookie di profilazione (propri e di terze parti) per ottimizzare la tua esperienza online e per inviarti pubblicità in linea con le tue preferenze. Continuando a utilizzare questo sito senza modificare le tue preferenze acconsenti all’uso dei cookie. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie clicca qui>
The website that you are visiting also provides Arabian language. Do you wish to switch language version?
يوفر موقع الويب الذي تزوره المحتوى باللغة العربية أيضًا. هل ترغب في تبديل إصدار اللغة؟
The website that you are visiting also provides Russia language Do you wish to switch language version?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
A core network device, HLR, accesses two NE40Es (V300R003C02B608) using 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. PE1 and PE2 are connected through an Eth-Trunk interface. The Heartbeat packets and services are transmitted through the Eth-Trunk link.
Both B-PE and Hub-PE2 can ping the IP address 10.179.143.84 of HLR in city A. After the ARP entries related to HLR are deleted from PE2, Hub-PE2 fails to ping HLR. The ARP entries related to HLR cannot be generated 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 generated. 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.)
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.
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 as follows: PE2 receives ARP Reply packets from HRL but fails to generate the corresponding ARP entries.*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 as follows: The result shows that the ARP entries can be generated.
*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 generated ARP entry is as follows:
0.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 -----------Associated with VRRP and connect to 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.
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.)
The configuration of ARP rigid learning causes the failure in learning ARP entries.
Delete the arp learning strict command from PE2, and the problem is resolved.