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 |
- Compile Sub-Option 1 from DHCPUtil.exe output:
- Compile Sub-Option 2 from DHCPUtil.exe output:
- Compile Sub-Option 3 from DHCPUtil.exe output:
- Compile Sub-Option 4 from DHCPUtil.exe output:
- Compile Sub-Option 5 from DHCPUtil.exe output:
Length of data is hex value for (number of characters of Data) divided by 2 ( # of chars / 2 )
| Sub-Option2 | ||
| 02 | Length of data | Data |
| 02 | 05 | 6874747073 |
| Sub-Option3 | ||
| 03 | Length of data | Data |
| 03 | 0B | 6578616D706C652E636F6D |
| Sub-Option4 | ||
| 04 | Length of data | Data |
| 04 | 03 | 343433 |
| 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
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?
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.
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
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
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 definitely agree
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.
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.
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.
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.
Thanks for posting what worked for you.
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.
You can. Check the following URL for more information: https://www.shudnow.io/2010/11/18/lync-2010-dhcp-…
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.
Noticed a typo on the 4500 IOS.
It should be (cat4500-ENTSERVICESK9-M), Version 12.2(54)SGI
Thanks for providing the switch information Mike! Updated the article.
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.