RSS Subscription 167 Posts and 2,769 Comments

Configuring Lync DHCP using Cisco DHCP Servers (VLAN and PIN Auth)

I recently had a project where all DHCP Servers were Cisco switches.  During the configuration, we noticed that a certain DHCP Configuration worked on certain Cisco switches but not the rest but a configuration was found that worked on all switches.  More on the specifics in the VLAN section below.  In this article, I will show you how to figure out how to configure the 120 and 43 options on a Cisco switch as well as how to configure the VLAN ID using the two different methods mentioned above. Thanks to Dave Howe from Microsoft for helping out with the PIN Authentication Settings for Cisco DHCP.

PIN Authentication Settings

STEP 1

Run DHCPUtil.exe to find out hex data values for DHCP Options 120 and 43

C:\Program Files\Microsoft Lync Server 2010\> DHCPUtil.exe -sipserver  pool01.contoso.com

Sip Server FQDN:  pool01.contoso.com

Certificate Provisioning Service URL:  https://pool01.contoso.com:443/CertProv/CertProvisioningService.svc

Option 120: 00076578616D706C6503636F6D00

Vendor Class Identifier: MS-UC-Client

Option 43 (for vendor=MS-UC-Client):

Sub-Option 1 <UC Identifier>: 4D532D55432D436C69656E74

Sub-Option 2 <URL Scheme>: 6874747073

Sub-Option 3 <Web Server FQDN>: 6578616D706C652E636F6D

Sub-Option 4 <Port>: 343433

Sub-Option 5 <Relative Path for Cert Prov>: 2F4365727450726F762F4365727450726F7669736

96F6E696E67536572766963652E737663

STEP 2

Build DHCP Option 120 hex value for Cisco DHCP using DHCPUtil.exe output info

Option 120 = hex 00076578616D706C6503636F6D00

STEP 3

Build DHCP Option 43 hex value for Cisco DHCP using DHCPUtil.exe output info

Note:  Format of DHCP Option 43 hex value:

Sub-Option 1 Sub-Option 2 Sub-Option 3 Sub-Option 4 Sub-Option 5
01 Length Data 02 Length Data 03 Length Data 04 Length Data 05 Length Data
  1. Compile Sub-Option 1 from DHCPUtil.exe output:
  2. Length of data is hex value for (number of characters of Data) divided by 2 ( # of chars / 2 )

  3. Compile Sub-Option 2 from DHCPUtil.exe output:
  4. Sub-Option2
    02 Length of data Data
    02 05 6874747073
  5. Compile Sub-Option 3 from DHCPUtil.exe output:
  6. Sub-Option3
    03 Length of data Data
    03 0B 6578616D706C652E636F6D
  7. Compile Sub-Option 4 from DHCPUtil.exe output:
  8. Sub-Option4
    04 Length of data Data
    04 03 343433
  9. Compile Sub-Option 5 from DHCPUtil.exe output:
  10. Sub-Option5
    05 Length Data
    05 25 2F4365727450726F762F4365727450726F766973696F6E696E67536572766963652E737663 

     

STEP 4

Combine the five Sub-Option values to build the DHCP Option 43 hex value for Cisco DHCP:

Compiled DHCP Option 43:

Sub-Option1 Sub-Option2 Sub-Option3 Sub-Option4 Sub-Option5
01 Length Data 02 Length Data 03 Length Data 04 Length Data 05 Length Data
010C4D532D55432D436C69656E7402056874747073030B6578616D706C652E636F6D040334343305252F4365727450726F762F4365727450726F766973696F6E696E67536572766963652E737663

VLAN ID Settings with PIN Authentication Settings

There are a few ways to make this work:

  • Link Layer Discovery Protocol (LLDP)
  • Two different ways to make it work on DHCP.  DHCP is what this article will cover.

Now let’s say we have two VLAN IDs: 208 (Data) and 209 (Voice) on the same ports.  The idea here is swap the phone from the Data VLAN to the Voice VLAN. As stated earlier, we found two methods in configuring the VLAN ID Settings.  The first I will show is how it worked on a switch that supported LLDP – Catalyst 4507R – SUP-IV IOS version (cat4500-ENTSERVICESK9-M), Version 12.2(54)SGI.  The second is how it worked on the switch that was not LLDP Capable – Catalyst 6513 SUP720 (S72033_rp-PK9SV-M), Version 12.2(18)SXD7 – or higher.  Thanks to my client for enduring the painful process of figuring out the below and providing me with information and explanations on what he did to get the Cisco DHCP configured for VLAN ID as well as the switch information provided which you can see in the first two comments in this article.

LLDP Switch Data Scope (Comments in Red)

ip dhcp pool Data14_Lync (VLAN 208)

option 10 hex 00d0 (Decimal 209)

option 60 ascii “CPE-OCPHONE”

LLDP Switch Voice Scope (Comments in Red)

ip dhcp pool Voice14_Lync (VLAN 209)

option 10 hex 00d0 (Decimal 209)

option 60 ascii “CPE-OCPHONE”

option 43 hex 010C4D532D55432D436C69656E7402056874747073030B6578616D706C652E636F6D040334343305252F4365727450726F762F4365727450726F766973696F6E696E67536572766963652E737663

option 120 hex 00076578616D706C6503636F6D00

Non-LLDP Switch Data Scope (Comments in Red)

When we noticed the LLDP Switch Scope configuration wouldn’t work on a non-LLDP Switch, we tried running this on Windows DHCP.  My client sniffed the traffic and found that Windows DHCP had some 43 option information passed back to the client for the VLAN ID information.  So what we did in option 43 is specify an option 10 sub-option.  The oa is the sub option. The 02 is the length of the data field divided by 2.  The 00d1 is the hex value of the data vlan.

ip dhcp pool Data14_Lync

option 43 hex 0a0200d1

Non-LLDP Switch Voice Scope

ip dhcp pool Voice14_Lync

option 120 hex 00076578616D706C6503636F6D00

option 43 010C4D532D55432D436C69656E7402056874747073030B6578616D706C652E636F6D040334343305252F4365727450726F762F4365727450726F766973696F6E696E67536572766963652E737663

Share

20 Responses to “Configuring Lync DHCP using Cisco DHCP Servers (VLAN and PIN Auth)”

  1. on 04 May 2011 at 10:25 amMike Maz

    The Cisco DHCP server used in the examples resides on a Catalyst 6513 SUP720.
    The IOS this config will work on (S72033_rp-PK9SV-M), Version 12.2(18)SXD7 – or higher.

    The LLDP config is running on a Catalyst 4507R – SUP-IV
    IOS version (cat5400-ENTSERVICESK9-M), Version 12.2(54)SGI
    An LLDP power policy doesn't need to be defined, but might help if you are using multiple Lync phone vendors and require specific power parameters for each device. Just type "LLDP run" at the (config)# prompt.

  2. on 04 May 2011 at 10:35 amMike Maz

    Noticed a typo on the 4500 IOS.
    It should be (cat4500-ENTSERVICESK9-M), Version 12.2(54)SGI

  3. on 04 May 2011 at 9:10 pmElan Shudnow

    Thanks for providing the switch information Mike! Updated the article.

  4. on 05 May 2011 at 6:08 pm@jdscher

    Also be aware that LLDP-passed VLAN IDs of 512 and larger are currently not supported and DHCP must be used for those. This will be fixed in a future Cumulative Update for Lync Phone Edition.

    Nice write-up :) I will be pointing a few customers to this article soon I'm sure.

  5. on 12 May 2011 at 5:27 amJay Crump

    Can a Lync phone register with a Lync pool via the internet? I have a working pool with edge and proxied simple URLs in place. Lync soft client has no issues – just curious if I could register a cx600 via edge instead of internal only.

  6. on 12 May 2011 at 6:42 amElan Shudnow

    You can. Check the following URL for more information: http://www.shudnow.net/2010/11/18/lync-2010-dhcp-

  7. […] http://www.shudnow.net/2011/05/02/configuring-lync-dhcp-using-cisco-dhcp-serv&#8230; […]

  8. on 02 Jun 2011 at 8:59 amNeil

    This is so close to what I'm trying to do with a Linux DHCP server. I've been able to build our Option 43 string based on the fantastic instructions above, but the phones seem to ignore them.

    I suspect that's because we don't have the vendor class defined in dhcpd.conf but I'm unsure how that should be formatted. If 143 & 120 are turned on the phones complain about invalid certificate path. If I comment them out and turn on the Lync DHCP then the phones sign in correctly. However that's not a long term solution given we need to be able to provision phones on different subnets.

    I've gone back and checked my 43 string and am sure it's right based on the above and what we got from dhcputil.

    Appreciate any pointers on this…

    Neil.

  9. on 09 Jun 2011 at 10:18 pmElan Shudnow

    It wouldn't be because of the vendor class. You can see in my Non-LLDP example, we're not specifying the vendor class and the phones registered fine. Building DHCP Options for non-Windows is a bit of a pain in the ass. I don't really have a good answer for you. It took us 3 weeks just to figure out how to get the above to work properly with VLAN mixed in which was the biggest problem. What do you see if you run dhcputil -emulateclient and when you try Test-CSPhoneBootstrap with -verbose?

    Also keep in mind you can set up DHCP Relays from the different subnets to the subnet that has Lync DHCP to get your phones the options they need.

  10. on 13 Jun 2011 at 4:17 amNeil

    So Test-CSPhoneBootstrap was very useful. When it is running with the Lync DHCP enabled, and Options 43 & 120 disabled on the Linux DHCP server you can see Option43 & Option120 in the output and they show the correct data.

    If you then turn off the Lync DHCP, and enable the options under Linux DHCP instead then when Test-CSPhoneBootStrap reports the DHCP Options they are still encoded.

    I'm pretty sure my 43 & 120 strings are right since I've rebuilt them twice and they were the same. It does look to be a Linux DHCP issue, but I'm not sure what.

    Neil.

  11. on 13 Jun 2011 at 8:07 amNeil

    Well I got it sorted after posting the above. Put Wireshark between the phone and the servers. To cut a long story short further changes are required to the Option 43 after you've calculated it based on the above. Our Option 43 starts;

    010C4D532D55…

    In dhcpd.conf you need:

    option vendor-encapsulated-options 01:0c:4d:53:2d:55…

    Each byte must be split by a colon and don't wrap in quotes either. Same thing must be done to the Option 120.

    Hope this helps somebody…

    Neil.

  12. on 16 Jun 2011 at 5:05 pmElan Shudnow

    Thanks for posting what worked for you.

  13. […] http://www.shudnow.net/2011/05/02/configuring-lync-dhcp-using-cisco-dhcp-servers-vlan-and-pin-auth/&#160; […]

  14. […] Configuring Lync DHCP using Cisco DHCP Servers (VLAN and PIN Auth) (Elan Shudow) […]

  15. on 13 Aug 2012 at 11:37 pmIT support

    I definitely agree

  16. on 16 Aug 2012 at 12:53 amspss syntax help

    I suspect that's because we don't have the vendor class defined in dhcpd.conf but I'm unsure how that should be formatted. If 143 & 120 are turned on the phones complain about invalid certificate path. If I comment them out and turn on the Lync DHCP then the phones sign in correctly. However that's not a long term solution given we need to be able to provision phones on different subnets.

  17. on 16 Aug 2012 at 12:54 amffg

    I suspect that's because we don't have the vendor class defined in dhcpd.conf but I'm unsure how that should be formatted. If 143 & 120 are turned on the phones complain about invalid certificate path. If I comment them out and turn on the Lync DHCP then the phones sign in correctly. However that's not a long term solution given we need to be able to provision phones on different subnets.
    <a rel="new tab" href="http://www.spsshelp.org/services/">spss syntax helpp

  18. on 16 Aug 2012 at 12:55 amfgg

    I suspect that's because we don't have the vendor class defined in dhcpd.conf but I'm unsure how that should be formatted. If 143 & 120 are turned on the phones complain about invalid certificate path. If I comment them out and turn on the Lync DHCP then the phones sign in correctly. However that's not a long term solution given we need to be able to provision phones on different subnets.
    spss syntax help

  19. on 23 Jan 2014 at 5:07 pmGuy Bachar

    It seems that the DHCPUTIL in Lync 2013 gives you with the Full Option 43 value automatically without the need to make all calculations mentioned.

    that saves a lot of headache.

  20. on 16 Apr 2014 at 4:01 pmMike

    Can option 43 be configured using something other than HEX? Cisco is now limiting DHCP hex to 180 characters. Anything with a server FQDN over about 24-25 characters is going to exceed that 180 hex limit.

    Unfortunately, I have a client with a FQDN that is much longer than 24-25 characters, causing the web services part (sub-option 5) to be truncated and the phones never get the certificate.

    All tests worked great in the testing environment using SIP.TESTNETWORK.LOCAL, but their actual server and domain name are longer.

    Can a DNS alias be used? ASCII?

    Does the server name have to be the FQDN, or can it be an IP address? Can the IP address be converted to hex?

Trackback this post | Feed on Comments to this post

Leave a Reply