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 Downloading Speed Is Low Due to the QoS Policies Configured on the Port of the S8016

Publication Date:  2012-07-27 Views:  40 Downloads:  0
Issue Description
Symptom of the fault:
The S8016 is connected to two NE80Es upstream. To the NE80E at the telecom hub, there are two GE links. To the NE80E at Qianjin Street, there is one GE link. A 3552G switch is attached to the S8016. Under the 3552G, there is a downloading test server, whose IP address is x.x.78.78.
The NE40 is connected to two NE80Es upstream. To the NE80E at the telecom hub, there are two GE links. To the NE80E at Qianjin Street, there is one GE link. Under the FE port of the NE40, there is a VIP customer whose IP address is x.x.56.192/26, with the bandwidth of 100 Mbit/s.
The network runs OSPF. Through the downloading test, it is found that the downloading speed at x.x.56.194 of the VIP customer cannot reach 40 Mbit/s, whereas the downloading speed at other IP addresses reaches 90 Mbit/s. 
 
Alarm Information
Null
Handling Process
Problem analysis:
1. Log in to the NE40 and check the uplink. It is found that the traffic does not use the link bandwidth to the maximum and CRC errors do not increase on the port. Therefore, the first cause is eliminated.
2. Reconnect the VIP customer under the NE40 to another board. Through the downloading test, it is found that the downloading speed at x.x.56.194 is still very low. Therefore, the second cause is eliminated.
3. Check the ports of the two NE80Es connecting respectively to the S8016 and the NE40. No CRC errors are found on these ports.
On the same port of the NE40, the downloading speed varies with the IP addresses within a range of about 50 Mbit/s. The only difference in the network is the paths along which the traffic is transmitted (the hash algorithm is adopted for multiple equal-cost paths). The S8016 has three GE links, one to the NE80E at Qianjin Street and the other two to the NE80E at the telecom hub. On the S8016, configure a static route to x.x.56.194 pointing respectively to the uplink devices. Conduct the downloading test on the NE40. Filter the static route imported by the S8016 through OSPF on the S8016 to avoid loops. During the test, it is found that, when the configured static route points to one of the GE links (GE 2/0/0) to the NE80E at the telecom hub, the downloading speed is as low as 40 Mbit/s.
Check GE 2/0/0 of the S8016. The following QoS settings are displayed:
diffserv output-queue be gtraffic-be
diffserv output-queue af1 gtraffic-af1
diffserv output-queue af3 gtraffic-af3
diffserv output-queue af4 gtraffic-af4
diffserv output-queue ef gtraffic-ef
View QoS policies. It is found that a certain portion of bandwidth is reserved for AF1, AF3, AF4, and EF flows respectively.
traffic dongbeishidarenwen cdr 200000 cbs 12288 mbs 12288
traffic guangbodianshi-30m cdr 30000 psr 31000 cbs 12288 mbs 12288
traffic ngnflow-GE cdr 100000 psr 110000 cbs 131071 mbs 131071
traffic sliveflow-GE cdr 200000 psr 300000 cbs 131071 mbs 131071
traffic goldflow-GE cdr 200000 psr 250000 cbs 131071 mbs 131071
traffic car-50 cdr 50000 psr 50000 cbs 5000 mbs 5000
traffic guangbodiantai-10m cdr 10000 psr 11000 cbs 12288 mbs 12288
traffic ftraffic-be weight 71
traffic ftraffic-af1 cdr 20000 psr 30000 cbs 12288 mbs 12288 weight 15
traffic gtraffic-be weight 74
traffic car-350 cdr 350000 psr 350000 cbs 5000 mbs 5000
traffic gtraffic-af1 cdr 200000 psr 300000 cbs 12288 mbs 12288 weight 15
traffic networkcontrolflow-GE cdr 10000 psr 15000 cbs 131071 mbs 131071
traffic ftraffic-af3 cdr 20000 psr 25000 cbs 12288 mbs 12288 weight 10
traffic yiqi cdr 50000 psr 51000 cbs 12288 mbs 12288
traffic ftraffic-af4 cdr 1000 psr 2000 cbs 12288 mbs 12288 weight 4
traffic ftraffic-ef cdr 10000 psr 11000 cbs 12288 mbs 12288
traffic gtraffic-af3 cdr 200000 psr 250000 cbs 12288 mbs 12288 weight 10
traffic GuangDian-50M cdr 50000 psr 51000 cbs 12288 mbs 12288
traffic guangbodianshiju-10m cdr 10000 psr 10000 cbs 12288 mbs 12288
traffic car-20-yiqi cdr 20000 psr 20000 cbs 5000 mbs 5000
traffic gtraffic-af4 cdr 10000 psr 15000 cbs 12288 mbs 12288 weight 1
traffic gtraffic-ef cdr 100000 psr 110000 cbs 12288 mbs 12288
Check whether packets are lost in the queue at GE 2/0/0.
8016>display portqueue GigabitEthernet 2/0/0 be
The current flow queue is be
QoS flowqueue forward frames is 994032
QoS flowqueue taildrop frames is 0
QoS flowqueue reddrop frames is 110683352
The result shows that packets are lost on this port. Delete the QoS policy for EF flows on the port of the S8016 to release the reserved bandwidth not in use. Then through the test on the NE40, it is found that the downloading speed at x.x.56.194 resumes to normal. 
 
Root Cause
1. Problem related to the uplink
2. Problem related to the boards of the NE40
3. Problem related to the link along which the traffic is transmitted 
 
Suggestions
Null

END