dhcpd: DHCPDISCOVER from x.x.x.x via eth0: no free leases

[mark.williams]

Dear all,

I am experiencing this error message:

dhcpd: DHCPDISCOVER from 00:21:5e:95:3a:a9 via eth0: network x.x.x/24: no free leases

This is coming from my call manager.  We have two call managers connected to each other for cluster purposes.

When I further look on my switch that the CMgr is connected to, I see two dynamic mac addresses on the port to which it is connected.  I released the mac addresses and within seconds, the two mac addresses came back.  I cannot understand why there are two mac addresses associated for this one port.

When I log onto the CMgr, I see only one mac address that is not the same as the above.  The difference is in the last 4 digits (3a:a7). 

The configuration of the switch has VTP enabled and is the VTP server and connects to only one other switch in our other data center. 

The only thing I can imagine is that the switch might be applying two mac addresses to the port due to VTP (can't figure out what else that could be).

My first question is has anyone else see this type of issue on their call manager?  or, on the switch to where call manager is connected? 

The error messages is generating every two to five seconds and I am concerned that it will start affecting system performance and/or bandwitch issues, and/or dhcp lease issues.

I have restarted the callmanager devices already.  I have not reset/cleared the dhcp leases...

Any help/advice is greatly appreciated.

Version:

Active Master Version: 7.1.3.30000-1

[Jonathan Schulenberg]

I cannot imagine why you would be using DHCP on CUCM; however, the reason why you're likely seeing a second MAC is probably the iLO/RMA/CIMC which is sharing the on-board NICs. You can either reconfigure the server to use the dedicated NIC (if there is one offered on that server model) or configure the management interface properly.

Please remember to rate helpful responses and identify helpful or correct answers.

[mark.williams]

Hi Jonathan,

I am not using DHCP on the eth0 of the CUCM. I am using it on the actual CM server as you need to have some kind of DHCP for your ip telephony...I would think...

Anyway, my team didn't initially set up the CUCM.  I will take a look at your suggestion about the sharing of the on-board NICS.  Thank you very much for your feedback! :-)..

[Jonathan Schulenberg]

Using CUCM as a DHCP server is rather rare. The SRND states that it's only supported if you have less than 1000 devices. Most customers just add the Voice VLAN to their normal DHCP environment and set Option 150 for the TFTP servers.

Unified CM DHCP Sever (Standalone versus Co-Resident DHCP)
Typically DHCP servers are dedicated machine(s) in most network infrastructures, and they run in conjunction with the DNS and/or the Windows Internet Naming Service (WINS) services used by that network. In some instances, given a small Unified CM deployment with no more than 1000 devices registering to the cluster, you may run the DHCP server on a Unified CM server to support those devices. However, to avoid possible resource contention such as CPU contention with other critical services running on Unified CM, Cisco recommends moving the DHCP Server functionality to a dedicated server. If more than 1000 devices are registered to the cluster, DHCP must not be run on a Unified CM server but instead must be run on a dedicated or standalone server(s).

Note that CUCM does not provide any clustering for DHCP services as it does with CCM and other processes. You should follow normal DHCP best practices for Windows (i.e. split the scope across two servers); or, use a product capable of HA (e.g. Infoblox).

Please remember to rate helpful responses and identify helpful or correct answers.

[mark.williams]

Hi Jonathan,

Thank you again.  I didn't know that.  What I ended up doing for the short-term solution is I added the network segment that was missing leases, It was wierd as the range/segment was the address range of the CUCM servers that had fixed ip's.  The other DHCP address segments were for our two different locations.  I will speak to my team about what you suggested and see if we can apply this structure in our networks...

Thanks again for your feedback

Mark J. Williams