3000 Old Alabama Road Suite 119-434, Alpharetta, GA 30022-8555404-424-8202info@volpefirm.com

Cable Modems Stuck? | init(r1), init(r2)…

Post 154 of 192
Cable Modems Stuck in init(r1) init(r2)

DOCSIS Cable Modem stuck in init(r1) init(r2)  Cable Modems Stuck?

Many of us have been there before - one or more cable modems 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, also known as init(r1) and 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# <strong>show cable modem</strong>

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       0050.7366.2223
Cable2/0/U0 6    online     2811   -0.25  5   0       0050.7366.1e01
Cable2/0/U0 7    online     2811   -0.50  5   0       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       0050.7366.2223
Cable2/0/U0 6    <strong>init(r1)</strong>   2813    12.00 2   0       0050.7366.1e01
Cable2/0/U0 7    offline    2810    0.25  2   0       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# <strong>show cable modem</strong>

Interface   Prim Online     Timing Rec    QoS CPE IP address      MAC address
            Sid  State      Offset Power
Cable2/0/U0 5    <strong>init(r2)</strong>   2289  !-8.00  2   0       0050.7366.2223
Cable2/0/U0 6    online     2811   -0.25  5   0       0050.7366.1e01
Cable2/0/U0 7    online     2811   -0.50  5   0       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:
[list type="list2"]

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

Mr. Volpe has over 25 years of communications industry experience. He is focused on the cable and telecom industry with deep technical and business skills. Mr. Volpe is currently the president and chief technologist of the Volpe Firm and holds an MSEE with honors.

Twitter LinkedIn Google+ 

, , , , ,