Virgin Media Community

[Roger_Gooner]

You will enhance your chances of getting help from VM by putting the hub back into router mode.

[Guybrush85]

---

@Andrew-G wrote:

Unless you had the BQM running beforehand and seen that the Hub 4 offered a clean BQM, no log error messages, and consistent upstream modulation, then I'm not convinced that the Hub 4 would be any better, as there's no obvious reason to expect the Hub 5 will be worse at managing the noise issues that can occur on a DOCSIS connection.  I'd certainly expect more glitches in the Hub 5 user interface and router firmware as the device is newer, but those aren't really involved in the cable modem activity which is mostly what a BQM monitors, and the cable modem is essentially mathematics processing most of which I'd expect to be done in hardware.

If you look at the BQM trace from 1am this morning to 5:50am, that's as good as you'll ever see on DOCSIS, and suggest there's nothing wrong with the hub, but the nastiness that's very obvious elsewhere looks like line conditions are deteriorating when the local network is busy.  

---

So the BQM is actually the same BQM from the hub 4. It's taking the MAC from my router I believe, which is why it's pulled the same IP from the DHCP lease. The outage was me simply getting the new hub setup etc before flipping back to modem mode.

The friend I mentioned round the corner with the hub 5 called as he was having disconnections and his BQM looked terrible (mainly the big red spikes). He called up and they 'sent a signal' and the usual waffle, but interestingly he's now showing QAM 64! I'll give it the old reboot before I head off to bed and we'll see how the BQM compares to the hub 4 in the morning.

@roger - thanks. Had it before when I had an upstream issue (maybe not a coincidence) a few months back. When a VM team member can look at this, I can flip it back to router mode for them to do the usual tests. 

[Andrew-G]

A BQM monitors your external IP address, not a MAC address; If the IP address didn't change when you swapped hubs you'll be OK, but it is worth checking - although VM IP addresses are "sticky" they can and do change, and swapping hub might contribute to that (or not).  As the CMTS will often re-allocate a released IP, your BQM may still show a plot, but it would be monitoring the connection of somebody else in the same neck of the woods.   

[Guybrush85]

What I mean is that DHCP assigns IPs based on a MAC and as the MAC is that of the external router and not the hub, so long as the lease time hasn't passed (and from my experience the lease time seems to be days not hours), then I can swap hub and keep the same IP, so easy to see that before and after on the BQM.

I gave the hub a bounce with no hope or expectation it would fix anything... It didn't, but the logs filled up with the same messages from earlier.

I do wonder since the page to request the hub 5 seems to have been there in error if there's something missing on my account and resending the signal may not harm. Just a theory.

Time Priority Description

29-11-2021 21:56:29	notice	CM-STATUS message sent. Event Type Code: 5; Chan ID: 159; DSID: N/A; MAC Addr: N/A; OFDM/OFDMA Profile ID: N/A.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:56:19	notice	REGISTRATION COMPLETE - Waiting for Operational status
29-11-2021 21:56:13	warning	REG-RSP-MP Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:56:13	warning	RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:56:13	warning	Dynamic Range Window violation
29-11-2021 21:56:13	warning	Dynamic Range Window violation
29-11-2021 21:56:13	warning	RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:56:07	notice	DS profile assignment change. DS Chan ID: 32; Previous Profile: ; New Profile: 1 2 3.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:55:30	critical	DHCP FAILED - Discover sent, no offer received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:55:20	critical	DHCP FAILED - Discover sent, no offer received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:55:15	critical	DHCP FAILED - Critical field invalid in response ;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:55:14	critical	DHCP FAILED - Discover sent, no offer received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:55:07	critical	DHCP FAILED - Critical field invalid in response ;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:55:06	critical	DHCP FAILED - Discover sent, no offer received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:55:04	critical	DHCP FAILED - Critical field invalid in response ;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:55:03	critical	DHCP FAILED - Critical field invalid in response ;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:55:03	critical	DHCP FAILED - Discover sent, no offer received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:55:03	notice	TLV-11 - unrecognized OID;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:55:01	warning	DHCP WARNING - Non-critical field invalid in response ;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:54:59	notice	Honoring MDD; IP provisioning mode = IPv4
29-11-2021 21:54:55	critical	DHCP FAILED - Critical field invalid in response ;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:54:54	critical	DHCP FAILED - Discover sent, no offer received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:54:50	critical	DHCP FAILED - Critical field invalid in response ;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:54:45	critical	SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
29-11-2021 21:54:35	critical	SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;

[Roger_Gooner]

It's the modem which negotiates with the CMTS to get the DHCP-assigned WAN IP address which it hands to the router. Something is clearly going wrong and an obvious thing to try is a hub swap.

[Guybrush85]

---

@Roger_Gooner wrote:

It's the modem which negotiates with the CMTS to get the DHCP-assigned WAN IP address which it hands to the router. Something is clearly going wrong and an obvious thing to try is a hub swap.

---

And what do you think it assigns an IP based on and is stored within the DHCP client table? The MAC address, and that's the router when in modem mode. 

[Guybrush85]

So update overnight, the upstream is now at QAM 64 and throughout the night latency looks about as good as it gets - I will have to see how it is today during core hours.

Network logs have had no more noise since rebooting, so it appears to only have generated those messages during boot up. 

[Tudor]

A little clarity on DHCP. There are two parts to DHCP on your router, the LAN side DHCP server (gives out IP addresses) and the WAN side DHCP client to a DHCP server on VM premises(receives a DHCP address). They are not connected in any way.

[Guybrush85]

---

@Tudor wrote:

A little clarity on DHCP. There are two parts to DHCP on your router, the LAN side DHCP server (gives out IP addresses) and the WAN side DHCP client to a DHCP server on VM premises(receives a DHCP address). They are not connected in any way.

---

Not sure who you're saying is incorrect here. If you put you put "modem 1" into modem mode and plug in "client 1", disconnect it and then plug in "client 2" (both different machines/routers whatever). Do you think you would get the same WAN IP assigned? 

Now if you swap out "modem 1" with "modem 2" but "client 1" stays the same, do you think would get the same WAN IP? 

[gitty]

The modem (not the built-in router) has its own ip address that is used for internal communication. That is what those DHCP messages in the modem log are related to.