Having a very strange problem here, and I hoping someone can provide some insight. I have two CMTS's (UBR7223s) connected to the same provisioning system. One of the two UBR's is having a strange problem: If I change the ip address of a cm connected to this UBR, in the provisioning system, the modem will not be provisioned properly, and is unable to come online. It will become stuck at: init(d).
If I disconnect the cm for 24 hours, then it boots up with the new ip. It seems, for some reason the UBR's internal database is not being updated.
Any Ideas?
I would greatly appreciate any advice you can offer!
Shen
maybe help this command:
clear cable modem offline delete
try it.
regards,
wittmann
P.S. Sorry for my poor english ;)
Hello all, and thank you for your replies!
Both UBR's are running the same version of Cisco IOS: 12.2(11). I also updated the boot loader on the CMTS having difficulty. now both have version: 12.0(7). I am using Docsis server as a provisioning system. When I attempt to change the ip address, it is to one within the same IP pool, and I am actually editing the lease. Docsis servers logs show the modem requested a new ip address, and one being offered:
2008-01-25 11:16:42 10.128.80.59 mac=E06F3E8350 modem=0 sent=ACK type=CM cache=NO
2008-01-25 11:16:42 10.128.80.59 mac=E06F3E8350 modem=0 sent=OFFER type=CM cache=NO
found something else strange; If I clear the route arp-cache, the modem will be allowed to come online. The UBr will still display the old ip address, however the modem will actually have the new ip.
Any thoughts?!
P.s. This ios version does not recognize the command: clear cable modem offline delete ; thanks anyway!
Hi Shendog:
You said that you are able to get the CM to take the new IP but that the uBR
continues to display the old IP....how are you able to confirm that the CM
took the new IP? Sounds like when using CLI, you still see the old IP.
This one is interesting. Cisco TAC would probably tell you to upgrade to the
latest IOS ;-) I think that the most recently IOS train is now 12.4!
Keep me in the loop.
Hi dogwood, The modem will stay at init(d) indefinitely. If I issue the command: clear arp-cache ; the modem will complete ranging. The command: sho cab modem ; displays the modem as online but with the old ip address. Pinging the old IP yields no replies. I can however ping the modem at the new ip, and poll it via snmp.
WEIRD HUH!
Like I said before: Its as though the UBR isn't able to update its modem database with the information from the dhcp server.
I have finally resolved this most obscure, and puzzling problem. The issue was apparently related to the ip subneting on the cable interface of the UBR in question. This interface was previously set to use a /21 network; 10.128.78.1 255.255.248.0. Changing this to a /16 network fixed the issue; 10.128.78.1 255.255.0.0
I am not sure why the smaller subnet caused this odd problem. I was only able to find the solution through process of elimination. Any theorys?
From what you are saying, your cable interface was initially a 10.128.78.1/21 but you
had problems until you changed to 10.128.78.1/16.
Your problem was that 10.128.78.1/21 actually is a valid IP address in the 10.128.72.0/21
subnet that has a range between 10.128.72.1 -> 10.128.79.254
Your previous posts said that you were getting the following logs from your DHCP server:
2008-01-25 11:16:42 10.128.80.59 mac=E06F3E8350 modem=0 sent=ACK type=CM cache=NO
This IP 10.128.80.59 is outside the range of IPs for the 10.128.72.0/21 Subnet.
Once you opened up your subnet to be a /16, then 10.128.80.59 then was valid
inside the 10.128.0.0/16 subnet.
That was a wierd how the uBR responded though.
Let me know if you need any recommendations on how to better utilize your IPs for your
cable modems.
dogwood
Hello Shen:
The CM reaches init(d) which means that the uBR recieved the DHCP discover from the CM.
You're saying that you change the IP address of the CM in provisioning (manually) and
the CM doesnt go beyond init(d). I see a few possibilities:
1 - If you're manually selecting an IP for the CM, is the old IP that was previously
served to this CM now a deactivated IP? Maybe the old IP's lease hasnt expired and the
DHCP is confused?
2 - This new IP that you are provisioning for this CM, is it in a different DHCP Pool. If so,
does this DHCP pool correspond to a valid gateway IP on the cable interface?
3 - If this new IP corresponds to a new DHCP Pool, test layer 3 connectivity between the
DHCP server and the gateway IP on the cable interface.
4 - What IOS are you running on the 7223s?
Let me know what happens,
AIM: carbuslosamante
By the way, besides this one customer, is this customer impacting to your
entire customer base? I would think that if the issue were at the uBR then
it might start exhibiting other behaviour as well.
dogwood
AIM: carbuslosamante