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.


Pause Point in the Program Caused by the Loss of the UDP Fragment in the Multicast Service of the Smart MA5600T

Publication Date:  2012-07-25 Views:  38 Downloads:  0
Issue Description
Multicast-sever------Cisco SW ------ MA5600T ------ xdsl-board ------ modem ------STB ------TV
|--------- other-produce----xdsl-board---- the same modem ------STB ----TV
The multicast service is normal, but the picture quality of the program is a little poorer than that of the competitor and the program has pause point. In addition, the comparison between the packets captured by the two PCs that are in the place of the two clients shows that the third fragment of some UDP packets captured by the PC connected to the MA5600T is discarded. See the attachment for the packet capturing file. 
Alarm Information


Handling Process
It is suggested that the onsite engineer modify the settings to enlarge the traffic profile.
traffic table ip index 9 cir 2944 cbs 96208 pir 4480 (recommend) pbs 192416 priority 6 priority-policy local-setting 
Root Cause
1. The packet capturing file in the feedback from the filed engineer shows that the third fragment of some UDP packets captured on the client in a certain period is discarded. Surely, this is the cause of the pause point and what is next is to find out the location in which this fragment is discarded.
2. Capture packets respectively in three locations of the topology:
①Capture packets on the egress port of Cisco and perform the port mirroring on the Cisco device. Check the sequence of the packets transmitted from the upper layer device, analyze the packets (about 10 M) captured from the Cisco router, and find that the problem of discarded fragment does not occur. Only some multicast UDP packets with fewer bytes are found , which is not the problem.
②Perform the egress port mirroring on our LSW. Mirror the packets that are transmitted to the service board to the GIU port and capture packets.
MA5600T(diagnose)%%debugging lswdrv bcm-cli
BCM.0> _Mirror mode=add OutPort=8 ToPort=6
8===>This refers to the egress direction of this GE port on the LSW. The 8GE port maps the service board in slot 1
6===>This is to mirror the packet in the egress direction of port 8 to this GE port of the LSW. The 6GE port maps port 0/20/0 of this uplink board.
Analyze the captured packets (14 M) of the LSW and find that only the fragments of some two-frame packets are discarded; however, the number of discarded fragments is very small and this problem may occur only in the case of the multicast server burst.
③Use the PC to capture packets on the modem of our service board and find that the symptom is the same as that in the feedback. The third fragment of many multicast UDP packets is discarded. We are sure that the fragment is discarded by either the board or the modem.
3. Further check the parameters and commands related to the board and find that the PIR value set for the traffic profile is very small. This may be the root cause of the packet loss and the poor multicast quality:
//Configure the VCI33 VPI1 multicast service
igmp user add port 0/1/21 adsl 1 33 video 1 33 no-auth quickleave immediate
//The traffic profile of VCI33 VPI1 is rx 9 tx 15
service-port 103 vlan 401 adsl 0/1/21 vpi 1 vci 33 single-service rx-cttr 9 tx-cttr 15
//Settings of the traffic profile
traffic table ip index 9 cir 2944 cbs 96208 pir 3968 pbs 192416 priority 6 priority-policy local-setting
traffic table ip index 15 cir 384 cbs 14288 pir 768 pbs 28576 priority 6 priority-policy local-setting
The pri value of the profile in traffic-table 9 is 3968 kbps = 3968*1024 = 4063232 bps = 507904 byte/s.
//Check on the LSW the number of frames that pass the port in the downstream direction each second:
BCM.0> show c
GRMCA.ge7 : 10,243,109 +426,416 390/s
Here, 390/s is the number of frames that pass this GE port in the downstream direction each second. If each fragment is calculated as 1410 bytes, we can figure out:
390 * 1410 byte = 549900 byte/s > 507904 byte/s. Thus, a large number of packets are lost.