Hi, we have deployed docsis 3.0 modems on our network for a while now.
Recently, we've seen modems, not many at once, getting stuck in init(o). They're staying in that state for minutes or hours. At some point, they'll come online by themselves.
We can manually accelerate the process by using baseline config files(network access, cpe number, US/DS services flows) and rebooting the modem. Depending on the modem's model, we may need to include a factory default mib in the config file.
When the modem does come online, we can put back the original config file that was created in the production provisioning process. We then reboot it one last time and it comes back online again.
This problems is intermittent and we having a hard time replicating it or getting some good logs.
Thank you.
Try to find out if those hanging modems actually are in full mtc-mode. Probably it could be problem with partial service on upstream bonding. I got the same with TCM471's - had to align the plant to use them :)
How modem and what software? I had a similar problem, the solution proved to exchange software. Add the file's try "SnmpMibObject saCmDsBonding.0 Integer 0," then the modem will log on 1 DS.
Right now, there's 3 cases.
One gateway modem needs a 30/30/30 reset to get back online. We weren't able to get some logs. The workaround does it's job.
Another gateway modem got stuck at init(o) because of an incompatibility between an old factory firmware and a docsisonly mib.
Those 2 cases are fairly "standard" init(o) problem.
This is where it gets interesting. In my experience, traditionnaly, an upstream impaired modem won't range. However, since there's lots of different states in docsis 3, a modem can get to a state where it will be able to range, but it won't be able to work after processing it's config file.
You can easily test that with a variable attenuator where the upstream signal will get to the CMTS too low.
Another case would be where you go from 16QAM to 64 QAM in a node. We still have to investigate this one.
Cheers,