DHCP daemon issue after CUCM upgrade 11.5 -> 12.5

[willsupport]

Hi all,

after the upgrade of my CUCM from 11.5 to 12.5, the built-in DHCP service on the CUCM stopped working.

The IP Phones are not able to acquire ip anymore.

Checking the logs on RTMT, i see this after i restart DHCP Monitor Service:

: 0: cucm-pub.confag.locale.confag.locale: Feb 23 2019 08:16:50.181 UTC : %UC_JAVAAPPLICATIONS-3-CiscoDhcpdFailure: %[Reason=dhcpd is stopped][ClusterID=][NodeID=cucm-pub.confag.locale]: DHCP Daemon stop running.

Can someone help me with this issue? Before the upgrade all was working fine

Thanks,

Alessandro

[Jonathan Schulenberg]

Wow, someone actually uses the co-resident dhcpd! The overwhelming consensus is not to do that; even the SRND recommends against it.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab12/collab12/netstruc.html#pgfId-1184975

If you have less than a 1000 devices in the cluster, your best bet here is probably a TAC case to find what is likely a new defect. If I were you, I would just move DHCP to your normal (hopefully redundant) DHCP server; or, run it on a router instead.

[willsupport]

Hi Jonathan,

thanks for your reply. I already opened a tac yesterday, but they will contact me on monday.
I was wondering if someone hitted this problem too, so i can solve until that day.

Thanks,
Alessandro

[carstenlp]

Hi Alessandro,

Did you ever find a solution for this? I'm having the same problem on 12.5.1.11900-146. I have opened a TAC case however but was wondering if you found a solution.

Thanks and have a nice day.

[Marc El Achkar]

Hello,

Any update about this issue? Did the TAC reply?

[willsupport]

Hi,

we did a rollback to the previous version. TAC was useless in this case

[Roger Kallberg]

Seems like an awfully long way to roll back to a prior version of CM if the only reason is that the DHCP service in CM does not work. Why not use another system, for example a Windows server, for the DHCP service?

[yogesh.mhatre]

Thanks Will and Roger.

Rolling back to older version is not feasible. We used a centralized DHCP server to assign IP addresses.

Cisco should release a patch to fix this issue or going forward should stop DHCP service entirely if its not reliable.

Regards,

Yogesh Mhatre

[yogesh.mhatre]

I recently installed CUCM 12.5.1.10000-22 in LAB and enabled DHCP on CUCM. DHCP on CUCM is not working at all.

Tried different subnet's, restarted DHCP Monitor service, etc. Its doesn't work, can't see Server handing IP Address to phone.

If i configure DHCP on Router or switch or Window, it works fine no issues.

Any update on the TAC case. Is this related to aby BUG?

[carstenlp]

There's an issue with the DHCP server in this version of CUCM. You need to upgrade to 12.5SU3 in order for the DHCP service to function properly.

Have a nice day.

[Roger Kallberg]

As pointed out previously it's strongly advised to not use the DHCP service in CM. You would be much better off to use any other service to provide the DHCP service to your network.

[carstenlp]

Instead of Cisco not recommending using their own built in DHCP server they should just remove the feature entirely. I have a few customers who are still using this feature and I learned the hard way that the DHCP is not working in 12.0 and 12.5 (3000+ phones unregistered over night).

How this feature passed testing and QA is beyond me.

[Roger Kallberg]

Can not agree more with you on this. It never worked particular well and frankly I have never came across any customer during all the years when I was a consultant that actually used this. Primarily I guess that all of them had other things in their networks that needed DHCP services so none of them ever thought about using the phone system to provide this service. It should be put to sleep and get axed from the system once and for all.

[murrayj00]

Agreed!   

Can confirm that this bug exists on 12.5.1 SU4 as well.   The problem is that the DHCP Daemon is disabled in the OS settings.   TAC can go in and re-enable/start it but it doesn't survive a reboot.   We tried setting it to start on boot and thought we had it whipped, not so fast.   Recent restart of the CUCM nodes proved that it reverts back to disabled.