- Switching the ONT with another new ONT – Result = Fail
- Switching the STB with another new STB – Result = Fail
Due to the troubleshooting with the physical layer has fail to obtain the solution, proceed with next 2 layer, which is data layer and network layer.
Handling Process
1. Using laptop with VLC software to stimulate the STB and try to access the multicast traffic
VLC show that video is freeze, meaning multicast services has problem
Then use the TestCenter 2000 to capture packet in 2 testbed to compare the result.
Due to most laptop network card has problem sniffing packet with VLAN because it will by default strip the VLAN from the packet, thus we use the TestCenter 2000. Second testbed is multicast services with existing GPON network and is normal status.
Thus I advice 3rd party ONT to verify the ONT multicast mechanism. Apparently the ONT strip the VLAN from the multicast packet before output from the connecting ethernet port.
This conclude that the problem is with 3rd party cooperating ont.
The result for second testbed is done with customer’s computer, thus I didnt have the .cap file.
Screenshot of the result first testbed :
Root Cause
As the test result with Test Center is normal, and the testbed has been stimulated in HQ Shenzhen CTD, so initially I make preliminary elimination that the problem is not with the OLT and it should be either 3rd party ONT or STB
I also eliminate the probability problem in the 3rd party network because this is a live network with millions of users using the VOD services, the chances of it failing is very minimal.
Troubleshooting will start with physical layer, going up to data layer and network layer if necessary.
Suggestions
As the problem lies with the 3rd party ONT, cooperating ONT partner have no choice but to patch it with new version. The new version resolve the issues with the stripping of the VLAN from multicast packet
After the patch, I do the first initial test again with live multicast services and now the multicast services is normal.
Leave a comment