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>


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


Something wrong with the GE port nr. 3 causes high priority traffic limitation

Publication Date:  2012-07-24 Views:  79 Downloads:  0
Issue Description
1.We set up 4 PVCs in one adsl port to test the QoS, frame length was 1400bytes, the DS rate on the modem was 4M. 
2.We have sent more than 4M to test downstream QoS, but the ADSL port test result was not correct, it seemed that PQ is not working well. 
3.The test result on SHDSL port was OK.
4.Network diagram:
interwatch M7-----(FE)---------ADSL modem 880u-t--------ADSL port 0/0/1------SCUK 0/7/3-----interwatch M7(GE).
Alarm Information
1.When the traffic goes down to ADSL ports, we tested pvc-setting of the traffic profile and we found the test result is not correct.
2.We have encountered that packets with higher priority (PID 6) are limited at the expense of packets with lower priority (PID 2). The table of ingress stream is below:
PVC        Tx(fps) PID (PG)        PID (CO)         Rx (fps)
8.34        400                0                  0               0
8.35        400                0                  2             159
8.36        100                0                  4              76
8.37        100                0                  6              76
3.PID (PG) means the priority value on packet generator, PID (CO) is priority in the traffic profile of DSLAM. Tx is number of sent frames (1400 bytes long without header) and Rx is the number of received frames on ADSL modem.
Handling Process
We have changed the level of traffic suppression for unknown unicast from level 7 to level 12:
MA5600(config-if-scu-0/7)#traffic-suppress 3 unicast value 12.
Root Cause
1.The problem was that on the GE port nr. 3, there was set unknown unicast traffic suppression to level 7. That means maximum package number was 763 pps. 2.When we tested on SHEA board, we have streamed 500 pps, but for ADBF board we have streamed 1000 pps. That was the point why there were problems on ADBF not on SHEA. As you can see from the table in Alarm Information, the lost amount of packets was about 23 percent, that were cut by SCUK logic not by ADBF board.
1.In case of SHEA board, the ingress stream speed was 500 pps, but for ADBF it was 1000 pps. 
2.So that's the reason why there was no problem in case of SHEA board, but for ADSL all incoming traffic was limited to 76% of its original value.
3.Such traffic limiting commands should be set to non limiting value by default.