I work for a MSO in a large metroplitan area. We are experiencing what we refer to as 'modem cycling' on what seems like random ports on a few of our Docsis 3 10k's. All modems drop at the same time, and then will come back up within a minute or so. We have seen it on some ports where it will do this every 8 minutes; sometimes it does it once every few hours. It does not happen on all ports. The return path is clean, nothing is under the upstream carriers, we've done peak holds on analyzers trying to catch spurious interference and have found nothing. We have changed u/s and d/s ports, the problem follows the node.
We came up with a test in which we took a node in the field that was experiencing this 'cycling' issue and transported it to one of our near hubsites that has an Arris C4 cable router (docsis 3 also). The cycling stopped. U/S & D/S frequencies were the same. By bring the U/S and D/S down to RF and re-transporting them to another hub, we obviously induced more noise in the process. The C4 did not burp once. We kept it on the C4 for a week and it was solid. We moved it back to the 10k and within a few hours the cycling issue began again. We have done this with cycling modems on other nodes with the same result: good on the C4, bad on the 10k.
In an attempt to try anything to resolve the issue and stop the customer complaints, we rolled the upstream back to 16qam from the 64qam it was currently set at. The cycling stopped. Since trying that with one node which has been solid for weeks, we have done that to address 4 other nodes in two different 10k hubsites. Again, on all of these upstreams, hours were spent cleaning up the return path. This obviously is not a permanent solution.
I am not a network technician, nor am I the one that goes into the CMTS's and changes the u/s qam profile. I have 30yrs in the CATV industry. There would seem to be a sensitivity on the 10k that does not exist on an Arris C4. There are no measurable anomalies in the return path. In fact, we induced noise onto a return and had to practically obliterate the carriers on our analyzer before we lost modems, and in that test we lost them gradually as the noise increased, not all at once as this issue does with no noise at all.
I am reaching out to see if anyone on this forum has experienced anything like this. Why would modems play fine on a C4 but have issues on a 10k? Is there a setting on the 10k that I could bring to the attention of our network folks that would change the sensitivity to 64qam to keep all the modems from cycling?
Any input would be appreciated. If this would be better posted on another forum, please let me know.
Sounds like you did alot of work into making sure the return is clean, thanks for that. As to why one CMTS will work and another won't, the fact that C4s and UBR10K line cards do not use the same chipsets at the PHY layer means we can't always garuntee the same behavior given the same impairments. I've seen cases similar to yours where if we change the CMTS device the behavior subsquently changes. Sometimes even same manufacturers of chipsets (say Broadcom like in our UBR10Ks) will exhibit different noise handling characteristics.
What caught my attention is you mentioned bumping down from 64QAM to 16QAM appears to have stopped this cycling. It might be worth it to look at a couple upstream configuration parameters.
1. Is pre-equalization enabled? (cable upstream
2. Is your Modulation profile custom or Cisco IOS generated? Have you tried the "robust" version of it?
3. Is there a time when modems don't drop offline but you get lost packets? (e.g. lots of FEC errors or insertion misses in "show cable flap"?)
That said I would suggest you open a TAC Service Request to get a dedicated engineer to work with you on this issue since often we have to look at the whole CMTS (e.g. version, hardware, plant conditions, etc.)