Forum Discussion

Chobbler's avatar
Chobbler
Joining in
1 day ago

Daily CMTS‑Driven Reboot – Clean Line, Repeated Provisioning Loop

Hi Team, I wonder if you can help with this please?

I was expecting this issue to go away with the scheduled work in our area GL3 yesterday but it has not helped to cure our issue.

I’m seeing a daily forced reboot on my Hub, and after gathering evidence it looks like a CMTS provisioning/configuration loop rather than a local fault. I’d appreciate if the Forum Team could check the CMTS side for my modem’s MAC and service group.

Summary of the issue

• Hub reboots once every day, with the reboot time drifting forward by ~10 minutes each day.

• This pattern matches a 24‑hour provisioning loop.

• The reboot is visible on my ThinkBroadband BQM as a brief red bar and latency spike.

• The connection is otherwise rock‑solid.

Modem log sequence at each reboot;

Every day I see the same sequence:

• Cable Modem Reboot because of – unknown

• SYNC Timing Synchronization failure – Failed to acquire QAM/QPSK symbol timing

• No Ranging Response received – T3 time-out

• Honoring MDD; IP provisioning mode = IPv4

• DHCP WARNING – Non‑critical field invalid in response

• DS profile assignment change

• REGISTRATION COMPLETE – Waiting for Operational status

This is the classic signature of a CMTS‑initiated re‑registration, not a hub crash or local wiring issue.

 

Line quality (steady state)

When online, the line is excellent:

Downstream

• Power: +5 to +9 dBmV

• SNR: 40–42 dB

• Modulation: QAM256 (DOCSIS 3.0)

• OFDM: QAM4096, zero uncorrectables

Upstream

• DOCSIS 3.0: QAM64, power 42–43 dBmV

• OFDMA: QAM256, zero timeouts

Errors

• Post‑RS: zero or near‑zero

• OFDM uncorrectables: zero

So the physical line is clean.

 

Other observations

• Multiple US profile assignment changes (profiles 11/12/13) throughout the day.

• These do not cause instability and look like CMTS OFDMA tuning.

• The reboot, however, is separate and appears to be a provisioning/configuration loop.

 

My request

Could the Forum Team please check:

• The CMTS provisioning entry for my modem’s MAC

• Any stuck or repeated config pushes

• Service group/OFDMA configuration around the reboot time

• CMTS logs for that port at the reboot timestamp

This doesn’t appear to be a hub or wiring issue — it’s a network‑side provisioning loop.

Happy to provide timestamps, BQM screenshots, or full logs if needed.

Thanks in advance.

Chris in Gloucester GL3

 

 

4 Replies

  • Roger_Gooner's avatar
    Roger_Gooner
    Alessandro Volta
    1 day ago

    This daily scheduled CMTS-driven re-provisioning is unusual but nothing to worry about. In fact it looks like a proactive network maintenance strategy and the re-boots are a good thing in order to maintain optimal network performance. And drifting ~10 minutes per day is done to avoid a huge spike load and so not adversely affecting the majority of users simultaneously.

  • Chobbler's avatar
    Chobbler
    Joining in
    20 hours ago

    Thanks Roger. It's really annoying as it happens in the afternoon when I am trying to work and I lose data on my weather station amongst other things. It Only started around Dec 15th. I'm sure it wasn't intentional, so if really necessary why not over night?

  • Roger_Gooner's avatar
    Roger_Gooner
    Alessandro Volta
    18 hours ago

    What you see is normal behaviour. Bear in mind that VM has millions of broadband users, so everything can't be done overnight. Even though VM schedules daily CMTS-driven re-provisioning overnight, individual hubs may get updates during the day due to retries if the hub missed a previous schedule, staggered timing or targeted pushes during the day, which explains why users sometimes notice it during working hours. A brief period of loss of broadband is a small price to pay for the network stability these reboots give.

    • Chobbler's avatar
      Chobbler
      Joining in
      42 minutes ago
      1. Sounds plausible, but if so, Dec 15th 2025 was the first time my current router has started behaving normally. Since 2014 my records show mostly 24/7 connection between my intentional disconnects, like for home maintenance activities for example, or when I added a UPS. I'm not a fanatic, I just feed the met office weather data as a hobby and I have a Pi Aware aircraft ADS-B tracker feeder. The extensive data on bandwidth etc is just a useful byproduct of hobbies, data which which has suddenly been disrupted and lost. I've always had blips in latency at 6am but not enough to generate reboots. Oh, and as discussed elsewhere by others, sometimes the 2.4 stream is lost post reboot meaning I then have to boot it again myself to regain household stability.