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 Local PE Could Not Successfully Ping the CE in the Commissioning of the MPLS L3 VPN Because of the Improper Configuration of the System Bucket

Publication Date:  2012-07-27 Views:  38 Downloads:  0
Issue Description
The version of the NE40 is V3.1 R2358 and the version of the NE80E is V300R001C01B052.
The networking is as follows:
PC-----------NE40A-----------------NE80E------------------NE40B-----------server
four POS links and two GE links
1. NE40A and the NE80E were connected through four POS interfaces. The NE80E and NE40B were connected through two GE interfaces. NE40A acted as the PE and an attached PC accessed VPN 1. NE40B acted as the PE and an attached server also accessed VPN 1. The NE80E acted as the P device. OSPF was adopted as the IGP protocol.
2. The PC and NE40A could successfully ping each other, but the PC could not successfully ping the address of the interface on NE40B connecting the server. On NE40B, the address of the interface on NE40A connecting the PC could be successfully pinged, but the address of the PC could not. 

 
Alarm Information
Null
Handling Process
1. 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.
2. Checking the loopback route and the next hop of the peer PE, the engineer found nothing wrong.
3. Checking the setting of the address and the gateway on the PC, the engineer found both were normal.
4. Checking MPLS LSP and VPNv4 routes, the engineer found public network labels and private network labels were both normally allocated.
5. 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. 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.
6. Pinging the loopback address of NE40A on NE40B, the engineer detected packet loss. Pinging the loopback address of the NE80E on NE40B, the engineer also detected packet loss. The problem was focused on the network between NE40B and the NE80E.
7. 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.
8. Because the two GE interfaces on NE40B connecting the NE80E were not at the same slot, the fault was believed relevant to the slot.
9. Checking the configurations of the device, the engineer found that the apply system-bucket 4 31 traffic-rate 0 command was configured on NE40B. The interface that could not be successfully pinged was just at slot 4. After the command was removed, the problem was solved.
10. The command leading to the fault was added to guard against ICMP attack. However, because the value was set to 0, ICMP packets could not be forwarded. Any ICMP packet whose destination address was the IP address of the interface of NE40B at slot 4 was discarded because the bandwidth of ICMP packets of this type was set to 0 Kbit/s.
11. For the ICMP packet sent to NE40B, why were the ping request packet sent from NE40A to NE40B and the ping request packet sent from the PC to NE40B or the ping response packet sent from the PC to NE40B processed differently (for the former, there was a normal response)? Because there were two links from the NE80E to NE40B and also two equal-cost routes. When the NE80E forwarded ICMP packets to NE40B, the ICMP packets were hashed to different links according to the quintuple feature, hence different processing results. That is, ICMP packets hashed to the interface at slot 4 were rejected and others were accepted. 

 
Root Cause
 1. In most cases, ping failures are related to route problems.
2. The ping failure in the commissioning of the MPLS L3 VPN was possibly caused by the route confusion as a result of network segment sharing by different sites in the VPN.
3. For the MPLS L3 VPN, if a PE can successfully ping the address of the interface on the peer PE connecting the CE, this PE should be able to successfully ping the CE except that the PC acting as the CE is configured with a firewall to disable pings or is set with incorrect gateway and mask when assigned with an IP address. 

 
Suggestions
1. Bucket No.31 of system-bucket can be set to 4 Kbit/s to prevent attacks. It is not recommended to set the value lower than 4, say, 0 Kbit/s or 2 Kbit/s.
2. In case a CE cannot be successfully pinged, you can consider conducting the ping test between CEs. 
 

END