Cable Modems init(r1) init(r2), DOCSIS Cable Modems going offline?
DOCSIS Cable Modems init(r1) init(r2) are stuck or offline! Many of us have been there before – one or more DOCSIS cable modems init(r1) init(r2) stuck in one of numerous “init()” conditions – how do we interpret these messages and what do we do?
A recent reader wrote in and had just this problem. DOCSIS cable modems going offline and getting stuck in “R1” or “R2” condition, or Cable Modems init(r1) init(r2), because these are the status conditions displayed on the DOCSIS CMTS when the “show cable modem” command is issued on the CMTS command line (CLI). So lets look at a few examples using a Cisco CMTS command line. In the ideal world you only have a few cable modems to troubleshoot and when you type the “show cable modem” command, you get the following results:
brady# show cable modem
Interface Prim Online Timing Rec QoS CPE IP address MAC address
Sid State Offset Power
Cable2/0/U0 5 online 2289 0.00 2 0 10.1.1.25 0050.7366.2223
Cable2/0/U0 6 online 2811 -0.25 5 0 10.1.1.22 0050.7366.1e01
Cable2/0/U0 7 online 2811 -0.50 5 0 10.1.1.20 0030.96f9.65d9
To interpret this, start with “Cable2/0/U0, which means the CMTS card in slot #2 (Cable2), downstream 0 (/0/), upstream 0 (U0) there are three cable modems “online”. All of the cable modems have a primary Service IDentifier (Sid) of 5, 6 and 7. The upstream receive RF power in dBmV is right within the sweet spot of where the CMTS would like them to be (around 0 dBmV +/- 0.5 dBmV). The cable modems have IP address and you can also see the cable modem MAC addresses. Everything looks great!
Next scenario. Same CMTS card, same cable modems. Two of the cable modem are offline and one is stuck in init(r1).
brady#show cable modem
Interface Prim Online Timing Rec QoS CPE IP address MAC address
Sid State Offset Power
Cable2/0/U0 5 offline 2287 0.00 2 0 10.1.1.25 0050.7366.2223
Cable2/0/U0 6 init(r1) 2813 12.00 2 0 10.1.1.22 0050.7366.1e01
Cable2/0/U0 7 offline 2810 0.25 2 0 10.1.1.20 0030.96f9.65d9
Right now we don’t know why two of the cable modems are offline, and there is nothing we can learn about them until they attempt to range and register again or maybe they are just unplugged. So let’s look at the one that is in the init(r1) state. First we look at it transmit power and see that its upstream receive power is 12.00 dBmV. That is way too high. Sure the CMTS is able to measure the RF power, but it is not likely able to reliably demodulate the data coming from the cable modem. If you want you can run a command just on that cable modem “show controllers cable-modem 6“, where 6 is the Sid of the cable modem that is in init(r1). This will show the absolute transmit power of the cable modem, which is likely 8 dBmV, or the lowest level possible that the modem can transmit. The solution is to add attenuation in the return path. If you are in the field, you should also be able to verify this with a hand-held DOCSIS meter, which would indicate that your transmit power is too low.
Next scenario, which is much more common, especially in the summer time, is the following:
brady# show cable modem
Interface Prim Online Timing Rec QoS CPE IP address MAC address
Sid State Offset Power
Cable2/0/U0 5 init(r2) 2289 !-8.00 2 0 10.1.1.25 0050.7366.2223
Cable2/0/U0 6 online 2811 -0.25 5 0 10.1.1.22 0050.7366.1e01
Cable2/0/U0 7 online 2811 -0.50 5 0 10.1.1.20 0030.96f9.65d9
Here you have a cable modem that is at -8.00 dBmV and it has an exclamation point “!” beside it. The power level is too low and the exclamation point indicates that the cable modem is at its maximum transmit power. Now you have too much loss in the RF plant. This happens most often in the summer time when heat causes the coax to expand, causing more loss in addition to semiconductors in RF and fiber-optic equipment in aerial plant to become less efficient, also causing more loss. This is an indicator that you have not built-in enough head-room into your return path to accommodate for plant fluctuations. It can also mean that you have equipment failing or just another subscriber who added a splitter between their cable modem and the CMTS. If it clears up when the temperature cools down, that doesn’t mean your job is done. It does mean that you need to go out with a hand-held meter, find out where the excess loss is occurring and resolve it. If the hand-held meter is showing max-transmit power you will know that the cable modem will do the same.
Once you are beyond init(r1) and init(r2), you are likely clear of fundamental RF impairments, though impulse noise and other time-dependent RF ingressors can still cause data loss. Next the cable modem will complete initial ranging, init(rc). The next hurdles you must cross are:
- DHCP init(d)
- Getting an IP address init(i)
- Downloading the DOCSIS configuration file init(o)
- Getting the Time-of-Day (ToD) init(t)
- And finally registering, which depending upon configuration has two primary states as follows:
- No security (no BPI+) init(online)
- Security (BPI+) init(pt)
These represent the main CMTS CLI states that you will see when issuing the “show cable modem” command. There a number of descriptions that I have not listed that provide error messages when the cable modem is not doing working properly, such as if it is rejecting the BPI+ security key. However the main intent of this article was to focus on the first two messages, init(r1) and init(r2). I will let it up to my readers to let me know if you desire further explanations on the remainder of the CMTS error messages.
To wrap things up, you are likely aware that diagnostic logs are also available on each cable modem. Though much less informative, these logs will often display “t3”, “t4”, “sync”, and “qam-lock” lock failures with are indicative of RF impairments. They may also show messages such as “Critical (3) UCD invalid or channel unusable…” messages, which can indicate that your cable modem is being load balanced to another upstream channel which it is not able to range and register with – again often due to upstream impairments. One such issue that I will be talking about after SCTE Cable-Tec Expo in November is “Impaired Service” where a DOCSIS 3.0 cable modem has four upstream transmitters. In the case where a DOCSIS 3.0 cable modem is not using upstream channel bonding, it can do an upstream channel change (UCC) without ever leaving the channel it is currently on. This means if it is unable to lock to an upstream channel when it receives the UCC, the customer will never notice a disruption of service. That is a very nice feature to have in place during upstream load balancing in a single channel environment before you migrate to upstream channel bonding and just one more reason to justify your investment in DOCSIS 3.0 cable modems.
Upcoming events can be seen under Broadband Events. Previous events can be seen under the blog.
- If you watch on youtube please hit the subscribe button!
- Let us know what you think and remember to share!
- You can find slides at the bottom of the page and some on slideshare.
- Find out about events or articles by following us on Twitter, LinkedIn or Facebook too.
Also available on iTunes, Google Podcasts, Spotify, vurbl see podcasts “get your tech on”.
Many thanks Brady that article hit the spot! I’ll follow along on the site and FB. We’re starting that move over here (Bahamas) to voice so I’ve been checking out your blog accordingly.
Glad you have this site running as the Docsis standard is not an easy read for some of us : )
Brady, excellent article. Just wanted to point out though that the asterisk “*”, according to Cisco, does not mean max power — it means the device has recently adjusted power. Cisco states the exclamation point “!” means max power.
No biggie, just wanted to point it out.
Joshua,
Thanks for the feedback and catching the “*” in the article. I very much appreciate readers who catch my typos, which ensures that I’m providing accurate information to my readers. I’ve since corrected the article. I’ve often had to go back and refresh my memory on what the “*” actually meant. I thought it was me losing brain cells, but after looking at the Cisco IOS change history, I was glad to see that the meaning of the “*” has indeed changed over time. For instance, from Cisco:
Then, in a different Cisco document:
But back to your point, which is the “*” vs. the “!” point:
Which is what I think is most important to readers. I was also pleased to see the following, which I had only encountered during DOCSIS protocol analysis of cable modems:
So seeing an “!” point in the Timing Offset section is a fairly significant issue. A cable modem which cannot transmit within its timing window has the potential of transmitting on top of another cable modem which will corrupt both the transmission of the its own signal and the transmission of the cable modem it is interfering with.
-Brady
Brady,
I appreciate the follow up.
I just reread your article and would also like to add for other readers the “online(d)” state. If the output of a show cable modem displays a modem with the “online(d)”, this indicates the modem’s “NetworkAccess” MIB within the TFTP config file is set to “0”. This is a typical way of disconnecting service without a physical change to RF connectivity.
Then there are the “reject” states. Most common issue I have seen is “reject(c)”. This is most likely due to CoS or QoS settings mismatch. DOCSIS 1.1 service flow configs on a legacy 1.0 modem, improper concatenated burst settings, etc. So if someone out there runs into this one, I’d recommend going over your upstream, TFTP config, and modem QoS/DOCSIS capabilities to make sure everything is compatible.
Great input Joshua. Thanks.
I just copied and sent this information in an email to my Head end tech’s they seem to think the problem is the CMTS. This article made it extremely easy to make them get back to work and find out where the problem is. Thanks man.
Hello Brady,
I greatly appreciate your effort to educate new students step in to this field.
I have to ask regarding the 2nd scenario, the 12dbmv power is measured at CMTS or at cable modem? If it is measured at cable modem so it makes sense.
But if this power is measured at CMTS then it is completely beyond my understanding that how could the power level is raised after the cable modem is transmitting at 8dbmv.
Also i am using arriss C4c CMTS i get the upstream power 9dbmv measured at CMTS and that of cable modem is 50dbmv measured at cable modem. And these power levels are considered normal power. But you called the power level 0 and +/- 0.5dbmv a sweet spot. Are we following different standards or is it because of difference Docsis 1,2 and 3.
Also please if you have any blog specialized for cable modem power, i seriously have problem with understand the cable modem power issues.
I will greatly appreciate your reply that you often do!
BR
Adeel
Hi Adeel,
The init() commands are generated by the CMTS, so typically they represent what the CMTS is seeing. Specifically with respect to power levels as you are asking, these are upstream receive power levels from signals transmitted by cable modems when they reach the CMTS. Most CMTS vendors default to a 0 dBmV (dB milli-volt) input at the CMTS upstream connector. Don’t confuse this with dBuV (dB micro-volt) or dBm (dB milli-watt), which are all significantly different power levels (0 dBm = 48.75 dBmV).
The sweet spot I mentioned was the tolerance that a CMTS will allow a cable modem to stay online before kicking it off. This can be configured on most CMTSs, but there are also some limitations in the hardware over which the A/D converter can still accommodate the a wide dynamic range.
I hope this helps with your question.
-Brady