cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
312
Views
0
Helpful
7
Replies

Phones failing to upgrade or obtain IP

CUCM55120
Level 1
Level 1

Have a bit of a weird situation with new phones in various locations on our network.

We have Alcatel switches with just over 100 edge switches in various locations and a few thousand phones deployed of which a large number were recently deployed to replace analogue PBX devices. Recently have come across the issue that on some switches we have issues plugging in brand new out of the box phones for the first time. Upon plugging in the phones seemingly fail to obtain an IP address and will not register or go through firmware upgrade.

If we take the same phone and plug it in to another switch which does not have the issue and let it upgrade and register etc to the point it is up and running, then unplug it and move it back over to the switch with the issue it will boot up, register ok and work fine.

I can ping our TFTP from our voice VLAN on a switch that is having issues and the phone runs fine once its been plugged in elsewhere so doesn't seem to be connectivity issue in the phone not being able to reach the TFTP and CUCM. We also have existing phones up and running connected to these switches and they work fine (although I am unsure if they were possibly configured and upgraded before being moved over to their final location which is maybe why this issue has only been noticed now).

I have discussed with our network guys and they couldn't see anything obvious when comparing the config of a working switch and one that was experiencing this issue and so far neither can I but my knowledge in that area is limited. Was wondering if there was a good place to start troubleshooting this or a good guide to follow? I am relatively new to voice and we haven't had any issues in the past with phone registration so I am hoping to learn something and get this fixed.

So far it has been confirmed to be affecting 6901 and 3905 models. Bulk of our phones are 6941 but not got any new ones to test the issue with.

Thanks!

7 Replies 7

Brandon Buffin
VIP Alumni
VIP Alumni

Root of the issue seems to be not obtaining an IP address. Without an address nothing else is going to work. What device is handing DHCP? CUCM? Router? Another server? Do you need an IP helper address to route DHCP broadcasts to the proper device? Anything else that could be blocking DHCP broadcasts?

Brandon

Yep we have two IP helper addresses programmed in to our switches routing to two servers that run DHCP, DNS and NTP. This DHCP server also provides the details of TFTP IP addresses for the phones.

The IP helper addresses was first thing we checked as it seemed the likely cause of the issue. It is confusing as it looks to be a DHCP issue but the fact that we can plug in already used phones that have been working elsewhere in to these faulty switches without experiencing any problems suggests DHCP is fine. all other devices (PCs printers etc) on those switches seem to work ok and not have issues with DHCP or connectivity.

We have also tried completely deleting the phone from CUCM and adding again and performing fully hardware reset on phones and the issue persists when plugging in to the faulty switches.

It is probably worth mentioning as well we run phones on a separate voice VLAN and tag the phones, although the issue seems to occur with a new phone on a faulty switch regardless of which VLAN the port is configured for. I can ping the DHCP server from our voice VLAN on one of the switches with the issue.

Thanks for your help.

Very likely a DHCP issue. The phone works after having been plugged into another switch because it has already obtained an IP address, TFTP server, etc. If it does not receive this info when plugged into the non-working switch, it will simply retain the values it received previously. Make sure the DHCP service is enabled:

conf t
service dhcp

Brandon

Our subnets are different for each VLAN on each switch so the phone would not be able to make use an IP address on the voice VLAN from one switch and use it on another switch as that subnet would not exist on that switch.

For example IP range for voice VLANs:

Working switch - 10.122.2.0/24

Faulty switch - 10.122.3.0/24

Plugging the phone in to the faulty switch it fails DHCP.

Upon plugging it in to the working switch it is assigned an IP on 10.122.2.X through DHCP and registers as normal.

Then plugging it back in to the 'faulty switch' the phone will again successfully go through DHCP again and get an address on 10.122.3.X which means DHCP works ok on that faulty switch after the phone has been plugged and upgraded etc on a switch that is not experiencing the issue.

Also as mentioned other devices connected to the faulty switch have no issue obtaining IP addresses and seems to just be new phones having problems.

Thanks.

Interesting. May need to run a packet capture to determine what DHCP packets the phone is sending/receiving when it fails. Possibly a bug in the older version of firmware since it works after being upgraded?

Yep, it all seems to revolve around the upgrade. Once it has been upgraded and is working it seems the issue can not be reproduced as plugging back in to any switches with the fault it will not occur again. It is definitely the combination of a configuration issue or quirk on particular switches of ours and brand new out of the box phones.

I believe we did not encounter this issue earlier during the major roll out of new phones as we were registering phones as well as unboxing, connecting and upgrading the firmware at a central location before delivering them to their final location and plugging in again.

I did think to try enable span to PC port to try troubleshoot the issue but to set that up involves configuring the phone to be able to turn on span to PC port and being able to do that would mean fixing the issue before I can troubleshoot it. I think I will look at perhaps port mirroring on the switch to get a capture.

Thanks for your help.

CUCM55120
Level 1
Level 1

Resolved the issue with one of our networks guys.

Seems the affected switches were missing a line of config setting the IP helper forward delay to 0. Adding this immediately resolved the issue.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: