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

MA5600T OLT TOIP and VOD service interruputed issue.

Publication Date:  2012-07-25 Views:  33 Downloads:  0
Issue Description
OLT version: V800R005C36B066
ONT version: V100R001C01B032
On Oct 23, 2008, customer reported that after upgrade to R4, services on 36 ONTs in a site were interrupted, including mostly TOIP services and few VOD services. Due to TOIP service interruption, calls cannot be made until the live box was reset. The symptom of VOD service interruption was not clear (the users may be unable to watch the video) and this interruption was temporarily rectified by resetting the STB. It was learned that the anti-MAC spoofing and anti-IP spoofing functions were enabled at that time, and after the users were online for 6-7 minutes in the DHCP dialup mode, the bound IP and MAC address entries disappeared.
Alarm Information
Null
Handling Process
To rectify this fault, set the aging time of the users in the existing network to more than 10 minutes (600s). Considering proper exchange of packets, the aging time of half an hour (1800s) is recommended.
1. After the aging time is modified, when the aging time of a user times out and the user receives the first ARP response packet, the aging time is renewed to 1800s, and the user sends the ARP probing packet only before the aging time times out. In this way, even when some users fail to receive the response packets in the first probing due to the insufficiency of system processing, in the second probing, however, when the ARP probing packets arrive, there are much fewer response packets than in the first probing (this is because the users who receive the response packets in the first probing do not send the ARP probing packets in the second probing), thus preventing a packet congestion. After the user receives a response packet, the corresponding entry will not be deleted, and the services will not be affected.
2. When the current probing time is set to 420s, the online user must send a probing packet every two minutes, which causes excessive ARP packets in the network and affects the network performance. After the aging time is modified, the above-mentioned fault will not occur.
Root Cause
1.On the MA5600T R56, the online users are recorded in the user table in the sequence of online time. In the aging probing, the ARP probing packets are sent to users according to the sequence of users recorded in the user table. For details on the probing mechanism, see the following attachment:
2.The aging mechanism of the security feature is to divide 8000 users into 24 segments, and send packets to poll a segment of users every 5s. In addition, during the release process, the packets are released successively for the segment of users, and the tasks are not switched in the release cycle. According to the storage mechanism described in (1), even when there are only 300 users, the users are allocated to the same segment in the user table. In extreme conditions, the aging probing ARP packets of more than 300 (8000/24) users can be sent instantaneously. In other words, more than 300 ARP response packets are to be received at the same time.
3.In normal conditions, the system CPU can process more than 1000 packets per second, which, however, is only an average value in a second. The packet receiving queue in the drive chip of the OLT supports only 250 packets. When the rate of incoming packets gets too high, the excessive packets are discarded.
4.There is another factor that causes this fault: On this site, the aging time is set to 420s, which is too short. In the current aging mechanism, each user must send a probing packet every two minutes. As a result, every time it is the excessive user who sends the probing packet.
5.The R2 version which was used before upgrade did not have the same fault. In the R2 version, the user entry is stored with the HASH index of MAC + VLAN. In this mechanism, all the users are randomly allocated to the 8000 entries. Therefore, in the polling of one segment of users, it does not happen that more than 300 users need to send the probing packets at the same time.
Suggestions
Null

END