none
DHCP not handing out to VoIP Phones

    Question

  • Hello,

    We are having an issue where DHCP addresses are no longer being handed out and the DHCP error 20287 is logged. Here is the error we get:

    DHCP client request from 08000FB342BE was dropped since the applicable IP address ranges in scope/superscope SCOPENAME Scope are out of available IP addresses. This could be because of IP address ranges of a policy being out of available IP addresses.

    I expanded the scope (although it wasn't out at the time) and currently have about 60 addresses available.

    What is very strange is that the only devices not getting DHCP from this scope are VoIP phones. As in both MiTel and Yealink phones sit at "Waiting for IP address". All other devices (Apple, Linux, IPhones, Android devices) get a proper DHCP.

    I ran a wireshark from the DHCP server as well as the phone. I confirmed that the DHCP server gets the discovery packet, but as that 20287 states, it never sends ACK or an offer to the phones.

    I simplified the setup as much as possible so the server is directly plugged in to the same switch (unmanaged) as the phones. No VLANs are in place.

    I also tried deactivating the scope on one Server 2012R2 installation and installing a new role on another server as well as another scope, still the same result. 

    If I change the DHCP server to no longer be on the Windows server and instead be on my Router, it works fine. 

    Any clue as to why only my phones won't pull DHCP?


    ICS

    Tuesday, July 10, 2018 8:33 PM

Answers

  • Thanks for all the responses,

    Philip_W: I set options 125 only as I was told by MiTel that 128, 129, and 130 are not needed. Additionally I had this problem with other lines of phones (MiTel and Yealink). Even without any options set, the phones would not get DHCP.

    Travis: You are correct that their is an option to reduce the number of DHCP requests coming from the phone, I did consult MiTel regarding this and afgter an adjustment, there was no change. Still no DHCP.

    I did manage to get a workaround going, so I will mark it as an answer.

    The solution: Instead of using DHCP Options on my unmanaged data scope, setting the VLAN and having the phone then jump over to the VLAN and pull DHCP, I used LLDP-MED which is supported by MiTel and Yealink. I enabled it on my Unifi switch and set the Voice VLAN as the proper tag for the phone network. Now I don't need the DHCP Options in my unmanaged data scope, the phones just go straight to the VLAN and pull DHCP and DHCP Options normally. Not a fix to the problem, but we all have to move on with life at some point and LLDP-MED is working very well.


    ICS

    • Marked as answer by ICS-USA Friday, July 27, 2018 12:16 PM
    Friday, July 27, 2018 12:16 PM

All replies

  • Hi,

    Thanks for your question.

    Event 20287 may be caused by VoIP Phones sending request packet in short interval time. Is it possible to modify some configurations on a VoIP phone? Or is it possible to configure specific DHCP options for VoIP phones on the DHCP server?

    Have you tried configuring address reservation for VoIP phones?

    Refer to the following links:

    https://social.technet.microsoft.com/Forums/en-US/73d1d012-5b18-4039-82d3-990cb6481e98/event-id-20287-error-is-repeated-many-times-and-record-in-events?forum=winserveripamdhcpdns

    Managing DHCP after adding IP phones

    https://arstechnica.com/civis/viewtopic.php?t=190362

    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information. 

    Best regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Wednesday, July 11, 2018 2:20 AM
  • Thank you for the response,

    I tried setting a reservation with the phones MAC address and still get the same issue. The phone does not pull the reserved address I set for it in the pool. However, that MAC address I tested with no longer shows in the DHCP event admin log with error 20287.

    I reviewed the documents you posted. The arstencia article is describing what I am trying to setup. However, without getting DHCP from the untagged network, I am unable to set the DHCP option to tag the phone on the VLAN network and complete the provisioning process.

    I am unsure how I would be able to reduce the frequency of DHCP requests from these phones. But I don't know that that would be helpful considering I get the same issue across multie VOiP brands (Cisco, MiTel, Yealink).


    ICS

    Wednesday, July 11, 2018 4:00 PM
  • Hi,

    Thanks for your reply.

    Why not consult the phone manufacturer, maybe they know how to reduce the frequency of requests.

    Best regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, July 12, 2018 8:15 AM
  • Hi,
    Was your issue resolved? 
    If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.
    If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.
    If no, please reply and tell us the current situation in order to provide further help.
    Best Regards,
    Travis

    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, July 24, 2018 3:04 AM
  • I don't know exactly what kind of phones and IP PBX you're using, but for Mitel phones such as the 5215, 5220, 5320 etc. running in MiNet mode not SIP mode, which are connecting to a Mitel phone system such as a Mitel 3300 MXE/MCD or MiVoice server, you need to make sure you have configured the neccessary options on the DHCP server. Specifically you need define and then set options:

    125 Mitel - id:ipphone.mitel.com;sw_tftp=x.x.x.x;call_srv=x.x.x.x;dscp=44 

    128 TFTP-Server - x.x.x.x

    129 RTP-Server - x.x.x.x

    130 PhoneType - MITEL IP PHONE

    (where x.x.x.x is the IP of your Mitel phone system, the dscp value could also be different your setup) 

    If you don't have the correct options defined, Mitel phones will reject the DHCP offers from the server.

    Friday, July 27, 2018 8:30 AM
  • Thanks for all the responses,

    Philip_W: I set options 125 only as I was told by MiTel that 128, 129, and 130 are not needed. Additionally I had this problem with other lines of phones (MiTel and Yealink). Even without any options set, the phones would not get DHCP.

    Travis: You are correct that their is an option to reduce the number of DHCP requests coming from the phone, I did consult MiTel regarding this and afgter an adjustment, there was no change. Still no DHCP.

    I did manage to get a workaround going, so I will mark it as an answer.

    The solution: Instead of using DHCP Options on my unmanaged data scope, setting the VLAN and having the phone then jump over to the VLAN and pull DHCP, I used LLDP-MED which is supported by MiTel and Yealink. I enabled it on my Unifi switch and set the Voice VLAN as the proper tag for the phone network. Now I don't need the DHCP Options in my unmanaged data scope, the phones just go straight to the VLAN and pull DHCP and DHCP Options normally. Not a fix to the problem, but we all have to move on with life at some point and LLDP-MED is working very well.


    ICS

    • Marked as answer by ICS-USA Friday, July 27, 2018 12:16 PM
    Friday, July 27, 2018 12:16 PM
  • Hi,

    Thanks for your reply!

    Good to hear that you have solved this issue by yourself. In addition, thanks for sharing your solution in the forum as it would be helpful to anyone who encounters similar issues.

    Best regards,

    Travis


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, July 30, 2018 7:31 AM