Hello there,
I am trying desperately to get the Motorola SB3100, SB4100 to accept DOCSIS 1.1 configuration files. According to what I have read on Motorola's documentation, these modems should support DOCSIS 1.1. However, when using a DOCSIS 1.1 service flow config scheme config, the modem gets stuck on the online light (flashing) and the CMTS reports "init(o)" status. Sh cable modem verbose reports:
MAC Version : DOC1.0
QoS Provisioned Mode : DOC1.0
So my best guess here is that these modem's firmware are out of date. So I went to motorola for the firmware update. Long story short, I get a "sorry we don't support this product" reply as well as the "you really should upgrade your modems" followed by "even if you tried to update the firmware, you wouldn't be able to without our proprietary tool". So here I am, stuck with these DOCSIS 1.0 modems holding me back from getting the whole plant operating on DOCSIS 1.1 QoS. All of my modems use the same config file for provisioning. In other words, there is no seperation of config files based on modem vendor besides our eMTAs and setting this up would be unrealistic and not really an option.
So my question is -- does anyone out there have an updated DOCSIS 1.1 capable firmware for these modems and also if so, do you have the "upgrade tool" Motorola insists is the only method of upgrading by?
One might just ask well why don't we do away with these ancient modems? I have asked the same but unfortunately that's not a decision I can make.
Anyway, using a DOCSIS 1.0 config scheme, these SB4100 and 3100 modems come online and surf fine. However, my upstreams are limited to 1.5 Meg up and downstreams to 5 Meg down. Why is this? We are doing 256 Quam down and 16 Quam up and I am testing off of a clean downstream and upstream (noise and traffic is lab environment). Is there some type of limit on the throughput capabilities of 1.0 that I am mising here?
Using the same DOCSIS 1.1 scheme on a DOCSIS 2.0 capable modem such as the SB5100, I have no problems.
Oh and one other thing I have noticed -- If a SB5100 downloads a DOCSIS 1.1 config file, it will not download the 1.0 config file again. I'm guessing this may have something to do with the newly assigned QoS provision for 1.1 (service flow)? Maybe the CMTS isn't allowing the modem to downgrade?
Any help, tips or support is greatly appreciated.
Thanks!
Will You accept an email?
Yes email to j@jcm.me.
Docsis 1.1 is not too much of a problem for those modems the firmware is available still on the Motorola businessonline website. Contact Motorola for a login.
However, BPI+ will not be possible on modems that have not had their certificates updated. Older Motorola modems came with a certificate that is now expired and the only way to replace it, was through a Motorola proprietary web based tool (i.e. website), that was shut down a few years ago, 2009 I believe. I believe this is the tool they are referring too.
As to your other questions,
1. DHCP -- it should be possible to give docsis1.0 modems 1.0 configs and everything else 1.1 configs. I know it is possible with dhcpd and Cisco CNR probaly with mst other DHCP servers also. Using dhcpd
if ((substring(option vendor-class-identifier,0,9) = "docsis1.1") or (substring(option vendor-class-identifier,0,9) = "docsis2.0") or (substring(option vendor-class-identifier,0,9) = "docsis3.0")){
filename = "CM_docsis1.1_HS1.bin";
option bootfile-name = "CM_docsis1.1_HS1.bin";
} else {
filename = "CM_docsis1.0_HS1.bin";
option bootfile-name = "CM_docsis1.0_HS1.bin";
}
2. Upstream and downstream speed issues.... There is a document linked to in this post http://docsis.org/node/1063 about throughput, though the title says docsis1.1 and 2.0 the document linked inside applies to all versions of docsis.
I'm not too concerned about BPI. In fact, I don't even think it's setup on this CMTS.
Also, as far as the configs go, I know exactly how to implement alternate configs through CNR but the problem is getting this automated through billing. Imagine a CSR trying to apply different rate codes to modems just because of the model number.... Not too practical.
FYI rate codes in billing system = CNR provisioning type.
Throughput I have checked, double checked, and triple checked using that overview/guide. For some reason though, the speeds I am getting just don't add up to those outlined.
For example, it is stated that:
After setting the bursts to 4000, here's the overview of what speeds you can expect :
3.2width 16qam = aggregate 8.9Mbps available
with default minislot-size 2 = peak modem speed 5.6Mbps
we would tweak minislot-size to 4 = peak modem speed 7.6Mbps
However, what I get in reality (clean, test upstream no other traffic):
After setting the bursts to 4000, here's the overview of what speeds you can expect :
3.2width 16qam = aggregate 8.9Mbps available
with default minislot-size 2 = peak modem speed 1.5Mbps
we would tweak minislot-size to 4 = peak modem speed 3.5Mbps
The only way I can get anywhere close to the 7MBps is by jacking the minislot size up to 16 and max burst to 55000. I'm also using fragmentation at 3500.
Been a long time since I used cisco CNR but I don't believe that it requires creating a new type for each model.
I believe the feature was called client-class processing and it would look at the client-class-identifier field in the dhcp request and apply specific settings to that class, I believe you could set the criteria to anything you want.
so the way it worked is that if the first 9 chars of the identifier are docsis1.1 or docsis2.0 or docsis3.0 give them a specific config
i.e. CM_docsis1.1_somefile.bin
whereas in your normal policy you would put the docsis1.0 config file name
i.e. CM_docsis1.0_somefile.bin
so that way if the modem comes in with a identifier with docsis1.1, docsis2.0 or docsis3.0 it will get the docsis1.1 config otherwise it will get the default config.
It may be easier to set it up so that if it is a docsis1.1+ modem it gets one tftp server otherwise it gets the default tftp server.
the only downside I remember was that it required a bit more work to setup and there was a performance hit, which was minimized if you had fewer client-classes. Using the tftp server approach you could get away with 3 client-classes, one for docsis1.1, docsis2.0 and docsis3.0.
Also,
Just logged in to Motorola DigitalCM and I don't see anything for the 4100 or 3100 series modems. The oldest I see are 5100 series.
3100 and 4100 firmware are housed at https://mobilityonline.motorola.com/login.aspx the DigitalCM is for newer firmwares
The modems need to be upgraded with specific firmware files in order to enable docsis 1.1. After that's done they'll accept more recent firmware updates. For the SB3100 and SB4100 you'll need SB3100-1.4.8.13-SCM01-NOSH.hex.bin and SB4100-1.4.8.5-SCM01-NOSH.hex.bin.