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>Search


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


Packet Loss Occurs to the VPN Service of the NE80 Owing to Incorrect QoS Configuration

Publication Date:  2012-07-27 Views:  3 Downloads:  0

Issue Description

The network diagram is as follows:
The NE80 and S8016s run the Layer 3 MPLS VPN. The VPN service is enabled on the SOFT3000. For the purpose of protecting the VPN service, QoS is configured on both the NE80 and the S8016s. The version of the NE80 is V5.30 and that of the S8016s is V3.10.
Symptom: When you ping the SOFT3000 for the VPN NGN service from S8016 A, packet loss occurs. When you ping the SOFT3000 from S8016 B, no packet loss occurs. Other services are normal and there is no traffic overflow on the interconnected ports. 

Alarm Information

 The SOCK process of S8016 A accounts for a high percentage (20%) of the CPU usage. 

Handling Process

1. Some leaky buckets that discard packets are disabled on S8016A. The effect is insignificant. Run the deb ip packet command. The CPU needs to process packets which contain the address 59.xx.79.241, 59.xx.12.97, or 59.xx.19.241. Packet loss should be caused by attacks from external networks. Among these three addresses, the first two cannot learn ARP entries from the S8016s and the last one is a Layer 3 interface address on the S8016s. In this way, the CPU needs to process these packets when external networks search for these addresses. The S8016s discard these packets but the CPU usage is affected.
After three blackhole routes are configured on the NE80, the CPU usage occupied by the SOCK process is 8%, which indicates that the configurations take effect. Ping the SOFT3000. Packet loss still occurs and the problem is not solved.
2. Check the QoS configuration. The QoS configuration on the NE80 is incorrect.
The original QoS configuration on the NE80 is as follows:
acl number 10001
rule ip
traffic classifier any-ngn
if-match acl 10001
traffic behavior action-ef
remark ip-precedence 4 //The service type that 4 corresponds to is AF.
traffic policy eacl-ef
classifier any-ngn behavior action-ef precedence 0
interface GigabitEthernet14/0/2
qos queue af4 cir 10000 pir 15000 length 256 weight 1 //The limited bandwidth for AF is 10 Mbps.
qos queue ef cir 100000 pir 110000 length 256 //The limited bandwidth for EF is 100 Mbps.
trust upstream default
EF should have been specified for VPN NGN traffic flows. AF4, however, is specified because the IP preference is configured incorrectly. The committed bandwidth for AF4 on the interface is 10 Mbps. When the traffic is greater than 10 Mbps, packet loss will occur. This indicates that the NGN traffic of S8016A exceeds 10 Mbps whereas the traffic of S8016 B is low.
View the packets in the AF queue. A lot of packets are discarded from the AF queue.
display qos queue statistics GigabitEthernet 14/0/2 af4
discarded : 13608926/39502685409 packets/bytes //After EF is specified for VPN NGN traffic flows, no packet loss occurs.
The configuration is modified as follows:
traffic behavior action-ef
remark ip-precedence 5 ------After the IP preference is changed to 5, the configuration can correspond to the qos queue ef cir 100000 pir 110000 length 256 on the interface. 


Root Cause

 1. Because the SOCK process accounts a high percentage of the CPU usage, packet loss may be caused by attacks.
2. Because the other IP services are normal, packet loss may be caused by the QoS configuration. 


In the current version, you cannot view the traffic of each queue.
The default mapping table between IP preference and service type is as follows:
0 be
1 af1 green
2 af2 green
3 af3 green
4 af4 green
5 ef green
6 ef green
7 ef green