cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Announcement“Cisco Design Thinking Workshop”. Cisco Small Business is excited to invite its Silicon Valley customers to an exclusive interactive one-day session between customers and product Managers.  If you are interested in this exclusive workshop, please fill out the Registration Form. For more information, please check out our FAQ


Get the latest new and information the November issue of the Cisco Small Business Monthly Newsletter

1432
Views
0
Helpful
5
Replies
Highlighted

SPA514G 'DHCP failed' errors with dhcp load sharing/failover setup

I have what appears to be a reproducible test case where my SPA514G phones (with firmware 7.5.5) will reboot after every (about) 4.5 times the dhcp renewal interval with the reboot reason being "DHCP failed".  The issue only occurs when running my isc dhcp servers is load-sharing/failover mode.  If only one dhcp server is operating, the phones continue to operate indefinitely.  It appears to be a dhcp client issue with the phone, possibly related to the issue resolved in CSCtu59498.  Only phones (and I only have SPA514G phones) on this lan segment have the problem (other devices work fine). My WAG is there is a problem when multiple offers are received by the phone and only one is completed.

Steps I have taken to isolate/reproduce the issue.

* Setup ISC DHCP servers in load-sharing/failover configuration (on same lan segment as phones).

* Configure dhcp server to return the basic info (netmask, router, ntp, dns), with a renewal time of 180 seconds.

* Configure dhcp server to assign static IP to the phone.

* Start up either dhcp server alone

* Factory reset phone

* Phone comes up, gets address, stays alive indefinitely (or at least longer than I was willing to wait).

* Shutdown active dhcp server

* Start other dhcp server alone

* Factory reset phone

* Phone comes up, gets address, stays alive indefinitely.

* Shutdown active dhcp server

* Start both dhcp servers, make sure they come up in load-sharing mode.

* Factory reset phone

* Phone comes up, gets address, will reboot with "DHCP failed" reason after 13:40 uptime (and continues to reboot after every 13:40 uptime).

* Shutdown either dhcp server, and the phone will then reboot one last time, and then stays operational (just as in the previous tests with just one dhcp server running).

I have pcap files from a mirror port watching the phone port.  From a quick look, there is nothing unusual about the dhcp conversations.


If I change the renewal time to 5 minutes (from 3 minutes), the phone will reboot with "DHCP failed" after about 22 minutes (exact time was not documented).  This is also about 4.5 times the renewal time.  I did not test with other renewal times (the original problem I started tracking was a reboot after a couple of days of operation, which is consistent with my original dhcp renewal time of 12 hours, but the exact reboot time was not documented).

I do not have a Cisco support contract for these phones (although they were recently purchased new, so in theory they are under warranty), so AFAIK I cannot open a direct TAC case.  I can provide more details (specific servers, switches, dhcp server configuration) if needed.


Thanks for any assistance or ideas.

(My current workaround is to only run one dhcp server).

Everyone's tags (4)
5 REPLIES 5
Beginner

Hi, I know this post is quite

Hi, I know this post is quite old but we have exactly the same issue.  We have two dhcp servers win2k8r2.  Logs on the DHCP server show the renew occurs without errors.  But, the phone will continue to ask for a lease renew each half life of the remaining time like if it didn't renew at all. At the end of the process, when the phone thinks the lease is over, it reboots ang get the same IP from the same server. DHCP servers pool are split so they don't give the same IP from the two servers.

Did someone out there solve this issue ?

 

Beginner

Hello,This is a really

Hello,

This is a really interesting case you have there. In order for this to be investigated further I suggest you do the following things:

- first upgrade the phones to the latest firmware available which is the 7.5.6, then test to see if you'll have the same behaviour.

- register on the cisco.com site if you haven't done so till now and afterwards call us in order to open a support ticket so we can investigate further this problem (a cisco ID is needed and the serial number of a phone that is under warranty). On the below link you can find the phone numbers of the support center.

http://www.cisco.com/c/en/us/support/web/tsd-cisco-small-business-support-center-contacts.html

- if you have a managed switch, please try to capture the traffic that is being sent few minutes before the problem occurs, because otherwise the file will be too large and we won't be able to analyze it.

Feel free to come back to me if more information or help is needed.

Best Regards,

 

Advocate

upgrade the phones to the

upgrade the phones to the latest firmware available which is the 7.5.6, then test to see if you'll have the same behaviour.

Test should be done on 7.5.6, but you may consider downgrade to an older version then. 7.5.6 has been released with  annoying bug that may damage mental health of your receptionist. You has been warned.

Looks like there is now an

Looks like there is now an open bug on this issue (or at least one that appears to have the same symptom and workaround):  CSCuw45255 

Beginner

Re: Looks like there is now an

A little different scenario on my end, but it was a SPA 502G which was getting the DHCP failed reason, and would reboot about every 3.5 times the lease time. This fix took more then a year, but early on we noticed statically setting the phone was the fix but we could not do that for this customer. 

 

To fix I applied to the phone: 

<DHCP_Option_To_Use group=\"Provisioning/Configuration_Profile\">82,160,159,60,43,125</DHCP_Option_To_Use>

<DNS_Server_Order group=\"System/Optional_Network_Configuration\">DHCP,Manual</DNS_Server_Order>

 

Mainly DHCP option 82 being added was the fix from what I could tell. After I added it rebooted 5 more times (a lot more than 3.5 times the lease time) this time around but then stopped with no further problems after that.