IP Phone stuck in Configuring IP

[Peter Mirabile]

We recently upgraded from CUCM 4.x to CUCM 7.x. When booting up phones that were previously registered with CUCM 4.x, the phone sits at "Configuring IP".

This was a migration from 4.x, so all IP address schemes are the same. The phones are getting the IP address from DHCP pool on switches.

Could this be a CDP issue? Are there any issues if I perform a CDP reset? Didn't want to break anything without verifying.

Thanks

[KonradStepniewski]

Is it problem for all phones or just few?

If all I would check if TFTP server and Call Manager processes are running on CUCM server. Check it from serviceability page.

After upgarde make sure you have all licenses as CUCM 7.x needs more than 4.x.

[Peter Mirabile]

Just a few phones that were in our inventory that were registered to the prior 4.x system. The DHCP server keeps coming back as 255.255.255.255.

I've tried the factory reset on the phone as well.

[Peter Mirabile]

One thing I noticed was if I plugged the phone into a port where another phone was already registered, the phone would boot up with no problems. Once I put if back on the existing switchport, I still have the same issue.

Both switchports are configured exactly the same.

PORT THAT WORKS

interface FastEthernet1/0/35

switchport access vlan 5

switchport trunk encapsulation dot1q

switchport trunk native vlan 5

switchport mode trunk

switchport voice vlan 160

srr-queue bandwidth share 10 10 60 20

srr-queue bandwidth shape 10 0 0 0

mls qos trust device cisco-phone

mls qos trust cos

auto qos voip cisco-phone

no mdix auto

spanning-tree portfast

PORT THAT DOES NOT WORK

interface FastEthernet3/0/16

switchport access vlan 5

switchport trunk encapsulation dot1q

switchport trunk native vlan 5

switchport mode trunk

switchport voice vlan 160

srr-queue bandwidth share 10 10 60 20

srr-queue bandwidth shape 10 0 0 0

mls qos trust device cisco-phone

mls qos trust cos

auto qos voip cisco-phone

no mdix auto

spanning-tree portfast

This is strange.

[Centronix]

I have the same problem. I even tried to restart the switches and did a factory reset. Now the phones are stuck trying to download the configs from Callmanager. Help

[paolo bevilacqua]

Verify switch config and that IOS is decently current.

[Centronix]

The switch configs are fine and the IOS is recent. A lot of the phones on the same switch work fine but there's a handful that are just stuck. All port configs are the same etc.

[paolo bevilacqua]

Config? Which device does DHCP ?

[David Hailey]

Centronix,

My first question for you would be: Did you upgrade the firmware on the phones to a version compatible with CUCM 7x prior to migrating the phones over?  If not, I would suspect that a handful of your phones may have failed to upgrade properly and you'll need to attempt a hard reset to see if they can pull the new firmware successfully.

Hailey

Please rate helpful posts!

[Centronix]

@ David, I didn't do a firmware upgrade prior to installing the phones. Some of these phones are brand new. I tried a hard reset so they can download new firmware and they got stuck on the firmware upgrade screen. They've been on the same screen for hours.

I have a Microsoft box doing DHCP but I don't think that's relevant

[David Hailey]

The DHCP, IMO, is not relevant.  The firmware is the problem.  Unfortunately, it sounds like some of your phones (new or not - it doesn't matter in many cases) have failed to upgrade their firmware and are now stuck in a cycle of not being able to upgrade.  You can try a factory reset but you're not guaranteed that will work - contrary to popular belief.  But, it's worth a shot.  You likely should open a TAC case and see what they have to say as well.

Hailey

Please rate helpful posts!

[paolo bevilacqua]

I don't agree that DHCP is not relevant, to the contrary in my expereince it's the reason of most phone startup troubles.

For example, is the request getting to the server in first place? And, is the server giving both option 66 and option 150 in the correct format ?

You can also span one port to wireshark to see exactly what is going on. Likely once you fix one, you fix them all.

[David Hailey]

Your phones were registered prior to upgrade and now after upgrade,

some are not...correct?

Sent from my iPhone

On May 12, 2010, at 4:28 PM, "p.bevilacqua"

[Jason Aarons]

What version device defaults were you running in 4x, you should have upgraded phone loads prior to the upgrade and

to what exact version of CUCM 7x are you at now and what are the current device defaults.  I suspect you may need to downgrade the 7x device defaults to something older, then try rebooting those phones. Next step would be a wireshark capture/ccm trace of the tftp process to find out what is happening.

[Centronix]

My apologies for not responding to this when I found the solution (which was a few years ago). The problem was DHCP. I ran out of IP Addresses. After increasing the scope, it worked fine.