Tag: lldp

ShoreTel LLDP Followup

A while ago I wrote a post about the experience I had setting up LLDP on Cisco switches with ShoreTel phones. Since then I have learned a trick or two and though I’d give a little update.

In the post I mentioned changing the configuration files for the phones on the ShoreTel server in order to correctly set the language and country, thus making the dial tone etc sound correct to end users. Unfortunately, this approach is broken. While it works to start with, we found that ShoreTel overwrites the configuration files periodically and removes the custom settings enter, which is a pain un the UK when the default country for ShoreTel is USA.

To get around this, there are some other configuration files which I was made aware of by our ShoreTel partner. Fortunately though ShoreTel provide some custom configuration files for each phone which are included in the main configuration file. The table below shows which custom configuration file you need for each model of phone.

Capture.PNG

So within the c:\inetpub\ftproot\sevgcustom.txt file for the IP 230g phones we use, all we have to do is add the following to the file.

# Please consult Shoreline support before editing or deleting this file

Include “Country_7.txt”
Include “Language_4.txt”

And done. If you reboot a phone, you will see it downloads the sevgcustom.txt file from the server and the language and country settings are all correct.

Don’t forget to change the configuration files for any other model phones you have!

Shoretel, LLDP and DHCP headache

During the process of migrating to new DHCP servers my colleague noticed a lot of inactive leases in the DHCP scope for our data subnets. After cross referencing MAC addresses it became apparent that the leases belonged to our Shoretel IP phones. All of the phones also have active leases in the VoIP DHCP Scope.

First of all we took a look at the DHCP scope options. Option 156 was enabled on both scopes, containing the following.

ftpservers=192.168.***.***,country=7,language=4,layer2tagging=1,vlanid=200

We decided to break out trusty Wireshark to try and figure out what was going on. From here we could see what was going on. When the phones were booting up they were doing the following:

  1. Trying LLDP
  2. Requesting DHCP lease from the untagged vlan on the switchport they were plugged into (data subnet)
  3. Retrieving option 156 from the data scope and reconfiguring themselves to tag voice traffic with vlanid.
  4. Requesting DHCP lease from the tagged vlan on the switchport they were plugged into (voice vlan)
  5. Continuing normal boot.

Step 2 is where the phones were getting the lease in the data subnet.

We decided to try lldp-med on the Cisco 2960S switches that we use for access.

This is probably a good time to mention that all of this was tested thoroughly in a controlled environment before it was rolled out to end users. We are not responsible if you break your phone system after reading about our investigations here.

conf terminal
!
lldp-run
!
interface range Gi1/0/1-48
switchport mode access
switchport access vlan 100
switchport voice vlan 200

I won’t go into detail about the QoS config we are running. It is there though, just not shown here.

Next we removed option 156 from the data scope and changed the string in option 156 on the voice scope to the following.

ftpservers=192.168.***.***

After rebooting the phones they did the following.

  1. Negotiated LLDP with the switch.
  2. Requested DHCP lease from the tagged vlan on the switchport they were plugged into (voice vlan)
  3. Retrieved option 156 from the voice scope and reconfigured themselves NOT to tag voice traffic.
  4. Requested DHCP lease from the untagged vlan on the switchport they were plugged into (data subnet)
  5. Used a cached config file and continued booting.

Strange. We did some more tinkering and found that if we added the layer2tagging=1,vlanid=200 options back to the option 156 string and rebooted the phone they stayed in the correct vlan. From this we took an educated guess that the phones were assuming the defaults of layer2tagging=0,vlanid=0 if the option were not specified in the option 156 string.

Next we removed option 156 from the voice scope and added option 66, which it a Boot Server Address, and set it to the ftpservers address from the option 156 string, 192.168.***.***.

We rebooted the phones and they did the following.

  1. Negotiated LLDP with the switch.
  2. Requested DHCP lease from the tagged vlan on the switchport they were plugged into (voice vlan)
  3. Retrieved option 66 from the voice scope.
  4. Contacted the FTP server.
  5. Continued booting normally.

Success! Or so we thought. The country and language of the phones had both reverted to 1 and 1, meaning the dial tone was different, although the language was still English.

To get around this we changed the config files for the phones on the FTP server. The files were stored in c:inetpubftproot on the Shoreware Director server. The file names are shore_model.txt, where model is referred to on the white label on the back of every model. The original config file looked like this.

There is an updated method to accomplish this, whcih you can find in my newwer post ShoreTel LLDP Followup.

shore_s6g_text

We changed it to the following.

shore_s6g_text_modified

After a quick reboot the phones were back to their normal selves.