| Attachment | Size |
|---|---|
 TM822G Debug.txt | 35.48 KB |
| CNR TM822G Log.txt | 6.34 KB |
| CM820A CNR Logs.txt | 1.21 KB |
I am attempting to get an Arris TM822G to connect to my Ubr10012. It is getting stuck at init(d). The Ubr is currently running in Docsis 1.1 mode. We are using CNR 6.2.3 as the DHCP Server. I have other Arris devices that work without a hitch. We are currently utilizing TM602A, TM602G,Tm604G, TM608G and I have even attached their Docsis 3.0 modem CM820A without a hitch. Th reason for this is that we will be migrating to Docsis 3.0 very soon and it would be helpful to be able to do it in steps as opposed to having to swap all of our modems at once. When I look at the DHCP log via the Emta's web interface it says it is sending a DHCPv4 request and shows the chaddr as a properly formed IPv4 MAC, but when I look in the CNR logs all I see is what appears to be a DHCPv6 CID. I have attached the logs from the CLI debugs of the Emta as well as the CNR logs for this device and the CNR logs for the CM820A that can connect without a hitch. Any assistance would be greatly appreciated.
Please provide us more information. Some debugs on the CMTS would help us.
In the priviledge mode (not config mode)
debug cable mac-address xxxx.xxxx.xxxx verbose
debug cable dhcp
debug cable ipv6 dhcp
terminal monitor
To disable all debugs:
undebug all
Other hint: Make sure that the IP Prov Mode is realy set to IPv4-Only in the MDD:
Example:
conf t
interface cable 6/1/0
cable ip-init ipv4
It's possible that the cable interface must be restart, not sure. A long time ago. You can check this first with:
show run interface cable 6/1/0 | include ip-init
If no line is shown, this setting is already set to default.
Please note the
cable ip-init ipv4is default in the cable interfaces. If you don't find this line in the cable interface it is already set.Best regards,
wittmann
* Your 822 has v7.3.115 firmware. I would recommend you upgrade to 7.3.139c
* The 822 says it is sending DISCOVER, and then looks like it throws away the response because it is "bugus" (bogus?)
* On the UBR you could view the DHCP process with : "debug cable mac-address 001d.d2e0.f4fa", "debug cable dhcp", "term mon"
* Your CNR server logs are telling you the modem is sending DISCOVER, but CNR does not know how to respond because there is no acceptable scope. This is a bit strange because I see your 820 is in the same subnet and works OK. Maybe your 820 has a reservation and the 822 does not, and you dont have any dynamic range allocated for "unprovisioned" modems to use?
* Your CNR server is saying this modem has been set to a client-class which doesn't exist "cc-subnet-inforanger". This is what I would fix first, and hopefully everything else will then start working OK. Perhaps try putting it into the same client-class as the CM820.
7.5.63b is the latest software for the 822.
You know, i recall having a similar issue when I first got the 822's in.... But now I can't remember how I fixed it. It had something to do with the way the bundle was set up...
I am attaching the debug output from the Ubr less the ipv6 debug since I am not currently deploying ipv6. I was also wondering what the process was to upgrade the firmware on the Emta from the lan side since the wan side never completes the DHCP process. TIA.
I placed the 820 and the 822 in the same scope. Neither has a reservation. All of our modems are provisioned via DHCP. As for the client-class cc-subnet-inforanger it doesn't exist. Not sure where in my CNR that piece is still laying around but I deleted that and it's associated scope when we quit using Samsung Inforangers over a decade ago.
Been a while since I used CNR but your CNR is saying there are no acceptable scopes, usually this means that your 822 is not properly authorized in the dhcp server. You should verify the mac address you have built in the CNR it sounds like it may be incorrect.
Barring that you need to troubleshoot the CNR because it is not even responding with a DHCPOFFER which is the next step in the process.
I sincerely believe that the true issue is that the only thing CNR is getting, and I am not sure why, is the CID which appears to me to be an ipv6 Mac rather than an ipv4 chaddr MAC. I suspect that until it sees an IPv4 chaddr compliant MAC it will continue to just drop the requests. In the debug logs from the Ubr I can see the chaddr is being offered but it doesn't show up in the CNR log. I was hoping someone may have some insight into why the chaddr is being sent by the modem but not making it to CNR. I have confirmed that the MAC is correctly entered and in the correct scope many, many times already. I think I will put a packet sniffer looking at the interface for th eCNR server and see if the chaddr response is getting all the way to the CNR server.