This document gives an overview of common DOCSIS events one might encounter within a cable modem’s DOCSIS event logs and gives a brief explanation of what each event means.
The information here is a collection from different sources such as The Volpe Firm, DSL Reports, and other reliable sources. If you have any corrections, comments or criticism; comment below!
Most modems do not have a RTC (Real Time Clock) battery. This means that any time the modem is powered off or reset by it’s reset button, it’s internal time and date is reset. Any event logs from this point until the modem can establish a connection to the network time server to retrieve the current time will usually be Jan 1 1970 or similar.
Each model of modem has different wording for the various DOCSIS events that can occur. The different wording does not indicate the event is different than the description posted here.
Most modems classify events into error levels.
Error Level | Description |
---|---|
6 Info / Notice | The modem encountered a situation which is noteworthy but does not pose any problem. |
5 Warning | The modem has used default settings for information omitted, or has ignored additional settings that it didn’t require. This will not cause any issue in a production environment. |
4 Error | The modem encountered a situation which may indicate a problem with configuration of the modem or CMTS. It was safely able to repair or ignore the issue and continue functions normally. |
3 Critical | The modem experienced an unrecoverable error and service has been disrupted. |
The cable modem has not received any periodic Upstream Channel Descriptor (UCD) messages from the CMTS within the timeout period. This error message is DOCSIS event message is U01.0, Upstream Channel Descriptor.
The cable modem did not receive a broadcast maintenance opportunity in which to transmit a Ranging Request (RNG-REQ) within the T2 timeout period (approximately 10 seconds). The cable modem is resetting its cable interface and restarting the registration process. This error message is DOCSIS event message is R01.0, Ranging Request.
The cable modem has sent 16 Ranging Request (RNG-REQ) messages without receiving a Ranging Response (RNG-RSP) message in reply from the CMTS. The cable modem is therefore resetting its cable interface and restarting the registration process. This typically is caused by noise on the upstream that causes the loss of MAC-layer messages. Noise could also raise the signal-to-noise ratio (SNR) on the upstream to a point where the cable modem’s power level is insufficient to transmit any messages. If the cable modem cannot raise its upstream transmit power level to a level that allows successful communication within the maximum timeout period, it resets its cable interface and restarts the registration process. This error message is DOCSIS event message is R03.0, Ranging Request.
The cable modem did not receive a station maintenance opportunity in which to transmit a Ranging Request (RNG-REQ) message within the T4 timeout period (30 to 35 seconds). The cable modem is resetting its cable interface and restarting the registration process. Typically, this indicates an occasional, temporary loss of service, but if the problem persists, check for possible service outages or maintenance activity on this particular headend system. This error message is DOCSIS event message is R04.0, Ranging Request.
Explanation: The cable modem has sent 3 Registration Requests (REG-REQ) to the CMTS without receiving a Registration Response (REG-RSP) within the T6 timeout period (3 seconds). The cable modem is therefore resetting its cable interface and restarting the registration process
This problem can also occur if the DOCSIS configuration file is corrupt, or if it contains a large number of vendor-specific information fields (VSIF). If the configuration file contains a large amount of VSIF information, the cable modem might generate a Registration Request (REG-REQ) that exceeds the maximum size of DOCSIS MAC-layer management messages (1514 bytes plus the header). The CMTS considers this an invalid MAC-layer management message and drops it, without replying.
The modem has an internal IP address on Cable network. About half way through the lease period, the modem will automatically attempt to renew that lease.
There were extensions added to the DHCP protocol in preparation for DHCPv4 / DHCPv6 interoperability. This means that there are a number of options transmitted with the DHCP responses that are not recognized by standard DHCP clients but generally inconsequential particularly in a IPV4 network. The modem’s DHCP client is a basic client so it can’t process the DHCP extensions so it throws the invalid field warning but completes the DHCP operation with the non-extended fields without issue.
The frequency / occurrence of this message is dependent on the modem model, firmware, and CMTS / Modem configuration. This message can safely be ignored.
The modem has an internal IP address on Cable network. It acquires it on initial connection, and about half way through the lease period.
If acquiring a DHCP lease fails then this message is logged.
Potential causes are:
- Intermittent / degraded RF signal
- Issue with the DHCP request sent by modem
- Issue with DHCP server
99.9% of the time, RF problems are the cause of this. The other 0.1% of the time, a large scale issue is taking place.
The modem is completely out of service and is unable to hear the ‘sync timing’ pulses on the cable line which occur every 20ms
The modem was rebooted by the cable operator
The Upstream transmitters are outside of the maximum range differences (12dB) – This can potentially be caused by noise on a specific upstream frequency
The modem received a unicast maintenance request however when requesting unicast descriptors received an abort message from the CMTS. The modem will now reset its cable interface.
See T4 Timeout ( Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received )
More of an informative note in the log than a warning. The MDD (Mac Domain Descriptor) is transmitted every two seconds on the downstream channels, and part of the process involves fragmenting the MDD if it’s large. The MDDs often get dropped, and if too many of them are dropped, the modem’s MDD timer expires and it begins looking for them again.
What may be happening is that one of the DS channels in use is not in the same fiber node, or not set up as a primary channel, and when the modem tries to lock onto that channel (783 for example), there is no MDD being transmitted (or an improper one) and the MDD timer expires and the modem moves on and searches for an MDD on the next available downstream.
Honoring MDD; IP provisioning mode = IPv6
DOCSIS MIMO stands for MDD IP Mode Overide. On a DOCSIS3 cable modem system, the CMTS sends a packet called an MDD (Mac Domain Descriptor) that tells the modem specific details about the cable plant, they determine whether the cable modem attempts to boot up in IPv6 or IPv4 mode. Some of those are TLV 5.1 and 5.2. You get those notices if the mode is not set in the modem config file, or if there is a difference between the current operation mode and what is transmitted in the MDD.
The TLV-11 – unrecognized OID message simply indicates that the configuration file contains different vendor (or multiple vendor) information in it.
Cable modem configuration files have multiple vendor-specific TLV-11, commonly called miscellaneous OIDs. They tell each brand of equipment how to do specific things for only that vendor. Since the config has multiple brands in it, all modems will report that error. They don’t report that error when they see their native vendor info, but will report it during digestion of a config with other VSIF OID in it.
You may see the above notice in your cable modem’s log files every time the modem registers it gets the configuration file. It should not affect the cm operation in any way.
The modem has been provided a firmware file to download via it’s configuration that it acquired via TFTP. It will now begin to download this file.
The modem has downloaded a firmware file and checked it for integrity. The file descriptor indicates it does not appear to be for this specific model or hardware version of modem and therefore the software was not installed.
This can often occur if multiple models of modem share the same template configuration file, or your modem’s model is incorrect in the CMTS’ database.
Feel free to comment with any event logs that you have come across and I will do my best to post a useful description for it!
See Also:
DOCSIS and Cable Modems – How it works :: Cable Modem Registration
Do you have any information on the following error message?
Map Request Retry Timeout;CM-MAC=e4:83:99:xx:xx:xx;CMTS-MAC=00:01:5c:xx:xx:xx;CM-QOS=1.1;CM-VER=3.0;
I see this error listed in the CableLabs OSSI technical specification for DOCSIS 3.0, but it doesn’t give much detail beyond this:
Process: Dynamic SA
Sub-Process: SA-MAP-FSM
Error Code Set: B603.0
Event ID: 66060300
CM-STATUS message sent. Event Type Code: 3; Chan ID: N/A; DSID: h; MAC Addr: N/A; OFDM/OFDMA Profile ID: N/A.
DOCSIS 3.1 Error Codes:
Source: Cisco.com, (https://www.cisco.com/c/en/us/td/docs/cable/cbr/configuration/guide/b_docsis_31_layer2_cbr_xe16_6/docsis_31_ds_resiliency_for_ofdm.pdf),
Page 2 & 3.
(Preface)
When DOCSIS3.1 CM reports non-primary RF channel failure for SCQAM or OFDM channel, actions performed by downstream resiliency is the same as DOCSIS3.0 CM.
In other words, if RF channel impairment is below the resiliency threshold, CM’s service flows are moved to Resiliency Bonding Group (RBG) or Narrow Band (NB) interface.
If RF channel impairment is above the resiliency threshold, the impaired RF channel is temporarily removed from the bonding group.
(/preface)
Event Type Code — Event Description — DS Resiliency Action
1 — MDD timeout — Move CM’s service flows to RBG/NB or suspend RF from BG.
2 — FEC lock failure — Move CM’s service flows to RBG/NB or suspend RF from BG.
4 — MDD recovery — Move CM’s service flows back to original BG.
5 — FEC lock recovery — Move CM’s service flows back to original BG.
16 — DS OFDM profile failure. A loss of FEC lock on one of the assigned downstream OFDM profiles of a channel. — DS OFDM Profile Manager will handle this event and take action.
20 — NCP profile failure. Loss of FEC lock on NCP.
21 — Loss of FEC lock on the PLC. — Event is recorded and displayed in show command.
22 — NCP profile recovery. — Event is recorded and displayed in show command.
23 — FEC recovery on PLC channel. — Event is recorded and displayed in show command.
24 — FEC recovery on OFDM profile. — Recovery of impairment reported by event 16. DS OFDM Profile Manager will handle this event and take action.
CM-STATUS message sent. Event Type Code: 3; Chan ID: N/A; DSID: h; MAC Addr: N/A; OFDM/OFDMA Profile ID: N/A.
Hello,
I was wondering if you guys had any info or a list of DOCSIS 3.0/3.1 error log definitions. Some are self explanatory, like T3 and T4 timeouts, thermal throttling, etc. but for some of the obscure ones I’ve been unable to locate explanations for what they mean. Just wondering if there exists a comprehensive list or database to search them. Any help appreciated.
Many of the DOCSIS error messages are actually documented in the CableLabs technical specification. I have many of them here. If you would like to post any specific error message you are curious about. I can look them up when I have time. Thanks.
DS Partial Service Fallback
TCS Fail on all Upstream Channels
B-INIT-RNG Failure – Retries exceeded
RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW
RNG-RSP CCAP Commanded Power Exceeds Value Corresponding to the Top of the DRW
DS profile assignment change. DS Chan ID: 32; Previous Profile: ; New Profile: 1 2.;
Warning (5) DBC-REQ denied – confirmation code 210: reject-dynamic-range-…
how about the wifi channel interference
Wifi interference does not cause any issues on the DOCSIS level.
https://highspeed.tips/wireless-802-11-troubleshooting/ would be a more appropriate place for that information. It should be covered in the ‘low bandwidth’ section but isn’t. I’m sorry I really need to update that section.
1/15/2020 19:22 69010200 6 SW Download INIT – Via Config file
1/15/2020 19:22 69010700 4 SW upgrade Failed after download -Incompatible SW file
Thanks. I have added information regarding those two events.
DHCP Failed missing!
Added. Thanks 🙂
http://www.scte.org/documents/pdf/standards/SCTE%20135-2%202013.pdf