Unity server issuing DHCP responses. Why?

[sdavids5670]

We had a very strange situation crop up on our network the other day. Phones started hanging when their DHCP leases expired. We put a packet sniffer on the network and discovered that DHCP requests from the phones would be answered not only by our legitimate DHCP servers (infoblox appliances) but also by the Unity server. However, the offer and ACK from the Unity server contained 0.0.0.0 as an issued IP address and it would arrive at the phone first and thus, the phone would get stuck without an IP address. This didn't affect phones which were renewing their leases before the expiration because that traffic was directed (not broadcast). We were able to resolve this simply by disabling the NIC on the Unity server and then re-enabling it. But this behavior seems very odd. The Unity server is not running a DHCP server as far as we can tell. Is Unity supposed to have this capability built into any of the Unity services? We can't seem to reproduce the behavior now.

[Tommer Catlin]

I would look in the services of the Unity Windows server and make sure that DHCP service is not running

[sdavids5670]

It's the very first thing we did. There's no service installed that looks to be a DHCP server service. There is a DHCP Client service running but that's normal for a Windows operating system.

[Tommer Catlin]

I have put in many unity systems and have never seen this problem. Unity simply sits on top of a windows server. If the server is handing out DHCP requests, you may have some other issue. Unity has no function or capabilities of to produce such DHCP information.

Possibly someone was messing around with the server and installed DHCP, then uninstalled it. I would do the following:

- install DHCP from the Windows add/remove

- uninstall DHCP

- reboot.

Possibly there is something hung on the add/remove piece.

Also, check the eventvwr for clues if something has changed, etc.

Or is someone spoofing the MAC address of the Unity server? Possibly have (2) of the same MAC addresses on the network?

[sdavids5670]

The spoofing angle is something that we thought of and unfortunately we didn't think of it until after we dump the packet captures and we didn't make not of the MAC addresses coming from the Unity server. However, it seems odd that the problem stopped as soon as we disabled the NIC. If something was spoofing it would have had to have known that we disabled the NIC. That seems unlikely. But as long as I know that it's not something native to the Unity services that's what I was looking for. Perhaps there's malware on the Unity box or, like you said, something spoofing the Unity's IP address.

[Tommer Catlin]

are the phones requesting DHCP from the Unity box, or is Unity responding to DHCP requests? When the phone boots up, it's of course looking for voice vlan information, if none is there, it will find a help address in the switch somewhere to push it over to the next place it should "look" etc. If someone has a help address pointed to Unity server, this could be why??

interesting problem though!

[sdavids5670]

An IP helper is in play. The Infoblox appliances sit on a different VLAN. That's why the Unity server's offer and ACK are reaching the phones first (because they don't have to go through additional steps of the IP helper). So the order of things was as follows:

1. Phone issued DISCOVER

2. Unity OFFER arrived (followed by OFFER from both Infoblox appliances via the IP helper)

3. Phone REQUESTS legitimate IP address from Infoblox OFFER (not Unity OFFER). So, in this particular case, the REQUEST packet contained 172.16.11.154 as the client IP.

4. Unity ACK comes in (with 0.0.0.0) before InfoBlox ACKs come in and the phone either tries to use 0.0.0.0 or just doesn't use anything and hangs.

At the same time, we were seeing other phones renewing their IP addresses but they weren't going through the same process because they were not doing the DHCP DISCOVER so they didn't have the same problem. Since the traffic was directed and not broadcast, the Unity server never interferred with those requests.