We have run into an issue where the router behind a cable modem can't renew its dhcp lease or loses it WAN ip address. Some of our techs have figured out that they can just unplug and reconnect the ethernet cable that runs between the modem and the CPE router and the router will instantly grab an IP and be online. We used to reboot the modems and the routers but recently our guys have been trying this and it seems to work. Arris and our provisioning software company aren't much help. Has anybody run into anything like this? We generally are using the Arris CM820A Docsis 3 modem and the TM804G and TM822G voice modems. We have a new Cisco cBR-8 CMTS. This problem also was around with our old Cisco ubr10K.
We have uBR10k and cBR8 with lots of those Arris modems, no problem.
What firmware version are you running on the Arris modems ?
What DHCP server are you using?
If it were me, I would capture the DHCP conversations to see where it is going wrong
Eg on the CMTS
debug cable mac-address xxxx.xxxx.xxxx <== the CPE router mac
debug cable dhcp
And on the DHCP server you can wireshark/tcpdump the DHCP traffic as well
I would capture the initial DISCOVER/OFFER/REQUEST/ACK (sounds like they are working), and then I would leave it running and watch what happens during the renew phases (sounds like this are failing?). If renews are failing it will eventually drop back to the DISCOVER phase again and the device should get back online. Although I have seen some devices reboot their DHCP stack when renews fail resulting in a dropout for the customer.
If need be, temporarily drop the lease times right down to something like 30 min so you can see the whole cycle happen in a short period of time.
We've come across this recently with two different model Arris emta/gateways while upgrading to cBR8s. The example below lists the firmware and model number at the end. The other model which i forgot was using the same firmware:
ARRIS DOCSIS 3.0 / PC 1.5 Touchstone Residential Gateway <>
It's odd and doesn't happen on every upgrade, but the most recent one we had about 50 of those down on one chassis and 20-25 on the other. I spent hours trying to figure it out before learning other systems have come across this issue and a power cycle fixed it.
They get stuck in init(o) or init(t) for a big and then keep repeating the cycle from start. I had a bunch of debugs running on one of them and found they get to DHCPACK and then just reboot and start over again. One common thing among all of them was horrible Miss counts in the flap list for whichever upstream they tried to register on. Did some test commands, turned off privacy, mtc-mode on the upstream, and a bunch of other stuff but nothing worked. Eventually they came up the next day and when i looked at the upstreams they were all perfect.