Navigator
Online Users

In total there are 2 users online :: 1 registered, 0 hidden and 1 guest

Most users ever online was 72 on Sat Jul 06, 2013 4:32 am

Registered users: Bing [Bot] based on users active over the past 5 minutes

Last Online
In order to view the online list you have to be registered and logged in.



We are a free and open
community, all are welcome.

Click here to Register

init(rc) issue

7225, 7246, 10012 all Cisco CMTS related Chat here.

init(rc) issue

PostAuthor: sonny420 » Tue Feb 05, 2013 11:27 pm

Dear All


i got a init(rc) problem in cable modem .
my CMTS is Ubr10K+ pre4 + 20x20
ios is 12.2(33)SCC7

1. cm w-online ping cm ip is timeout but ping docsis is ok . in this state , cpe can't connection to internet , also can't get ip address from dhcp server.
2. after cm reboot , will stop init(rc) --> offline --> init(rc)
3. after clear cm delete , cm become w-online agalin.

it random happen in online cable modem .

is anyone have see this problem before ?

Sonny

sonny420
Board User
 
Posts: 3
Joined: Tue Feb 05, 2013 10:00 pm

Re: init(rc) issue

PostAuthor: mbowe » Wed Feb 13, 2013 4:25 pm

I have same CMTS hardware as you

I have seen that same problem at one stage in the past

Worst affected were Arris D3 modems

Our CMTS was running 12.2(33)SCE3 at the time. You say you have SCC7. I wonder if SCC7 shares some affected code with SCE3? I see SCC7 was published April 2011, SCE3 was published May 2011. So I reckon there is a good chance the same bug affects both.

Anyway, we ended up sending some CM debugs through to Arris and they told us :

Based upon the following logs:

[INFO] [DOCSIS.CMSTATUS(pid=185)]: CM-STATUS - Event CmStatEv_SecChlMddTimeOut SM set Hold-Off timer to 1000 mSec
[INFO] [DOCSIS.CMSTATUS(pid=185)]: CM-STATUS - Event CmStatEv_SecChlMddTimeOut SM set Hold-Off timer to 1000 mSec
[INFO] [DOCSIS.CMSTATUS(pid=185)]: CM-STATUS - Event CmStatEv_QamFecLockRecover SM set Hold-Off timer to 600 mSec
[INFO] [DOCSIS.CMSTATUS(pid=185)]: CM-STATUS - Event CmStatEv_QamFecLockFail SM set Hold-Off timer to 780 mSec
[INFO] [DOCSIS.HAL(pid=249)]: MPT-ISR :: QamFecLost portId 5.
[INFO] [DOCSIS.HAL(pid=249)]: MPT-ISR :: QamFecLost portId 6.
[INFO] [DOCSIS.HAL(pid=249)]: MPT-ISR :: QamFecLost portId 7.
[INFO] [DOCSIS.HAL(pid=249)]: MPT-ISR :: QamFecRecovery portId 8.
[INFO] [DOCSIS.HAL(pid=249)]: MPT-ISR :: QamFecLost portId 5.
[INFO] [DOCSIS.HAL(pid=249)]: MPT-ISR :: QamFecLost portId 6.
[INFO] [DOCSIS.HAL(pid=249)]: MPT-ISR :: QamFecLost portId 7.
[INFO] [DOCSIS.HAL(pid=249)]: MPT-ISR :: QamFecLost portId 8.
[INFO] [DOCSIS.HAL(pid=249)]: MPT-ISR :: QamFecLost portId 5.
[INFO] [DOCSIS.HAL(pid=249)]: MPT-ISR :: QamFecLost portId 6.
[INFO] [DOCSIS.HAL(pid=249)]: MPT-ISR :: QamFecLost portId 7.

...and the fact the CMTS is a Cisco CMTS, experienced guess is the CMTS and CM are failing to negotiate partial service when there is a bonding impairment. This results in the CMTS sending on a downstream that the CM is not receiving on. Bad.

The root cause, in the opinion of ARRIS, is that Cisco CMTS does not support CM-STATUS messages. CM-STATUS is required by D3.0 (not sure whether Silver or Gold level) and the ARRIS D3.0 CMs implement CM-STATUS, but the Cisco CMTS does not as far as we know. They may have fixed this in recent (current) IOS firmware, so we are not sure. The C4 CMTS, for your reference, fully suppots CM-STATUS, so this is not an issue on the C4.

However, you are not likely to replace their Cisco CMTS with a C4, so Arris recommend to place the following MIB objects into the ARRIS D3.0 CM config file to prevent it from using CM-STATUS and using more blunt-force mechanisms such as resetting from the MAC layer:

arrisCmDoc30SetupSecDsLossReinitEnable.0 = enable(1)
.1.3.6.1.4.1.4115.1.3.4.1.3.4.0 = 1

arrisCmDoc30SetupPartServiceFallback20.0 = enable(1)
.1.3.6.1.4.1.4115.1.3.4.1.3.5.0 = 1

arrisCmDoc30SetupPowerSaveMode.0 = reinitmac(1)
.1.3.6.1.4.1.4115.1.3.4.1.3.18.0 = 1

The reason the MIB objects above aren't enabled by default is that the CMTS is *supposed* to support CM-STATUS. So, please understand this is not an ARRIS D3.0 CM issue/bug, but rather a feature provided by ARRIS to work around the lack of something Cisco is supposed to be doing.


So basically it sounded like some sort of Cisco bug

From memory we implemented this suggested workaround until we could upgrade to SCF2. At that point the problem was gone, and we havent seen it since.

So my recommendation is for you to move to a newer IOS. We currently have SCF4 and are planning on jumping to SCG2 soon as Cisco have supposedly patched our last batch of remaining bugs in this build. Fingers crossed they dont add any new ones.

mbowe
Board User
 
Posts: 56
Joined: Thu Dec 30, 2010 10:08 pm
Location: Down Under

Re: init(rc) issue

PostAuthor: sonny420 » Mon Feb 18, 2013 9:43 pm

Dear Mbowe

thanks your reply

right now , we still got the problem .
also had CISCO TAC online check the problem , but they can't find the problem.

this problem only happen on DOCSIS 3.0 cable modem (we have cisco DPC3008 , Moto SB6141)
and this issue have random in every slot , not only one kind cable modem , or one slot.

CISCO TAC still don't have any answer , so bad ......

sonny420
Board User
 
Posts: 3
Joined: Tue Feb 05, 2013 10:00 pm

Re: init(rc) issue

PostAuthor: mbowe » Mon Feb 18, 2013 11:09 pm

Did you try upgrading your IOS?

mbowe
Board User
 
Posts: 56
Joined: Thu Dec 30, 2010 10:08 pm
Location: Down Under

Re: init(rc) issue

PostAuthor: sonny420 » Tue Feb 19, 2013 2:09 am

mbowe wrote:Did you try upgrading your IOS?


not yet , because TAC don't have any idea about the problem
already 3 TAC ppl to check the cmts . still can't confirm the problem. also can't sure problem will solve after upgrade IOS.
only tell us the SCC7 are very old IOS.

TAC want us use cable modem console to debug .
but still search the special cable modem .

that really bad solution and bad feel .

sonny420
Board User
 
Posts: 3
Joined: Tue Feb 05, 2013 10:00 pm

Re: init(rc) issue

PostAuthor: mbowe » Tue Feb 19, 2013 4:11 am

If they don't know what is wrong, then I would upgrade.

If this works it will be a much faster resolution than waiting for TAC.

If you really dont like the new IOS then you can always roll back.

Just book the upgrade in for middle of the night. One or two controlled reboots is much better result for you and your customers than having modems randomly getting stuck offline.

Your symptoms are pretty much the same as we saw. I think an upgrade has a good chance of fixing it.

We took our first CMTS to SCG2 last week, and it is working well. Looks to have resolved all our outstanding bugs we had open with Cisco. Going to upgrade our other units to SCG2 over the coming weeks.

mbowe
Board User
 
Posts: 56
Joined: Thu Dec 30, 2010 10:08 pm
Location: Down Under

Re: init(rc) issue

PostAuthor: slimjim100 » Wed Feb 20, 2013 11:08 am

Be Careful on blind upgrades to fix unknown bugs as it is possible some of the features you might use today might not be supported in later versions of IOS or you could just find new bugs. I would work with TAC the best you can. IOS's after SCF change the MIB structure and your monitoring tools might have issues once you upgrade past SCE. Anyway please keep us posted on what you end up finding as I am sure a lot of folks find our site thru google when trying to fix there CMTS.


Cheers,

Brian
aka Slimjim100
User avatar
slimjim100
Site Admin
 
Posts: 123
Joined: Mon Jul 28, 2008 1:30 pm
Location: Georgia, USA


Return to Cisco CMTS

Who is online

Registered users: Bing [Bot]

cron