Checking the configurations of the device, the engineer found that the apply system-bucket 4 31 traffic-rate 0 command was configured on NE40B. Because the two GE interfaces on NE40B connecting the NE80E were not at the same slot, the fault was believed relevant to the slot.ĩ. With the source address (the address of the interface connecting the NE80E), pinging the addresses of peer interfaces on NE40B connecting the NE80E, the engineer found that one interface could not be successfully pinged.Ĩ. The problem was focused on the network between NE40B and the NE80E.ħ. Pinging the loopback address of the NE80E on NE40B, the engineer also detected packet loss. Pinging the loopback address of NE40A on NE40B, the engineer detected packet loss.
UNABLE TO PING LOOPBACK ADDRESS PC
Similarly, with the source address (the address of the interface connecting the server), pinging the address of the PC (the number of ping packets was 20), the engineer found that NE40B failed to receive ping request packets.Ħ. Enabling debug ip icmp on NE40B and, with the source address (the address of the interface connecting the server), pinging (the number of ping packets was 20) the address of the interface on NE40A connecting the PC on NE40B, the engineer found that there were normal numbers of request packets and response packets. Checking MPLS LSP and VPNv4 routes, the engineer found public network labels and private network labels were both normally allocated.ĥ. Checking the setting of the address and the gateway on the PC, the engineer found both were normal.Ĥ. Checking the loopback route and the next hop of the peer PE, the engineer found nothing wrong.ģ.
Checking VPN 1 routes, the engineer found that PEs at both ends could learn the route of the network segment between the peer PE and the CE and that the next hop was the loopback address of the peer PE.Ģ.
0 kommentar(er)
