Anybody else having problems with these modems (Arris DG860P2) in their plant?
Originally it was thought that it was old firmware (7.5) that was causing problems when shifting from 3.2cw 32qam upstream to 6.4cw 64qam.
Now it doesn't seem to matter. Even after updating to 9.1.103S5E the problems persist.
I can plug one of these modems into a micro-plant (2 foot cable directly off of downstream 0 on a 2x8 and an upstream port with a 2way splitter reversed to the modem with a data filter and a ton of attenuation to put the DS power to the modem at -4 and the US power at 42) and they come online instantly.
When I plug them into my test plant (with similar power and fantastic SNR stats) some come online instantly, and others just sit for 24 hours or more. Sometimes the 7.5.125E firmware comes up, sometimes it doesn't. Sometimes the 7.5.50A firmware comes up. Sometimes it doesn't. Sometimes the 9.1.103S5E firmware comes up, sometimes it doesn't.
When I called Arris on this we solved a slew of other problems, but not this one.
Was curious if anybody else was having problems with this model in particular.
The current theory is some sort of fault in the plant, but I have been unable to determine one for the life of me.
I've tested power levels from the back of the box all of the way through to the combining, to the lasers, past the lasers, to the taps. I can't find ANYTHING, and I have the feeling it is simply because I don't know what I'm looking for.
No other modems have issues. Just these.
I'd rip hair out, but I went bald at my last job.
Pulled this off of another post here snmp tree-family TapView 1.3.6.1 - include non-volatile
snmp tree-family TapView 1.3.6.1.4.1.9.9.252 - exclude non-volatile
snmp tree-family TapView 1.3.6.1.4.1.9.9.394 - exclude non-volatile
snmp tree-family TapView 1.3.6.1.4.1.9.9.399 - exclude non-volatile
snmp tree-family TapView 1.3.6.1.4.1.20858.10.19 - exclude non-volatile
snmp tree-family TapView 1.3.6.1.4.1.4491.2.2.9.1.1 - exclude non-volatile
snmp tree-family TapView 1.3.6.1.4.1.4491.2.2.9.1.2 - exclude non-volatile
snmp tree-family SNMPv3View 1.3.6.1 - include non-volatile
snmp tree-family SNMPv3View 1.3.6.1.4.1.9.9.252 - exclude non-volatile
snmp tree-family SNMPv3View 1.3.6.1.4.1.9.9.394 - exclude non-volatile
snmp tree-family SNMPv3View 1.3.6.1.4.1.9.9.399 - exclude non-volatile
snmp tree-family SNMPv3View 1.3.6.1.4.1.20858.10.19 - exclude non-volatile
snmp tree-family SNMPv3View 1.3.6.1.4.1.4491.2.2.9.1.1 - exclude non-volatile
snmp tree-family SNMPv3View 1.3.6.1.4.1.4491.2.2.9.1.2 - exclude non-volatile
snmp tree-family docsisManagerView 1.3.6.1 - include non-volatile
snmp tree-family docsisManagerView 1.3.6.1.4.1.9.9.252 - exclude non-volatile
snmp tree-family docsisManagerView 1.3.6.1.4.1.9.9.394 - exclude non-volatile
snmp tree-family docsisManagerView 1.3.6.1.4.1.9.9.399 - exclude non-volatile
snmp tree-family docsisManagerView 1.3.6.1.6.3.16.1.5.2 - exclude non-volatile
snmp tree-family docsisManagerView 1.3.6.1.4.1.20858.10.19 - exclude non-volatile
snmp tree-family docsisManagerView 1.3.6.1.4.1.4491.2.2.9.1.1 - exclude non-volatile
snmp tree-family docsisManagerView 1.3.6.1.4.1.4491.2.2.9.1.2 - exclude non-volatile
!
Could it be that my BSR64K is missing the mibs?
I would enable telnet, connect in from the LAN side and watch the console to see what the modem is doing
Whether it is failing to lock, or whether it is locking but rejecting config etc
It appears that I am a victim of simply not knowing the systems of my new place of employ and/or simply not putting two and two together.
The problem apparently cleared up after I removed the mac addresses from the previous dhcp server. The routing recognized the mac on both sides, and was apparently black-holing about half of the incoming information.
Do still have one modem that is stuck in init(o) that is officially the outlier here, is not in both dhcp systems, doing the "I'm going to take a day to come online" thing.