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.
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.
|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!