Skip to main content

Cloud

Lync 2010 and LLDP – off by just a bit

One of the very useful new features of Lync 2010 Phone Edition is support for LLDP (Link Layer Discovery Protocol) to allow phones to receive configuration information from the switches they plug into. If you have any experience with Cisco IP Telephony, you know that Cisco Discovery Protocol (CDP) is used for similar purposes to assign voice traffic to a separate VLAN. This works great, but really only with devices (like Cisco phones) that speak CDP.
LLDP is an open standard that’s been evolving over the years. I’m glad that Microsoft has chosen to comply with it for Lync Phone edition. Eventually LLDP will be used by the Lync soft clients on PCs – however thanks to a bug or some other limitation, LLDP doesn’t quite work in that regard yet. Nonetheless, I have found LLDP to work pretty well with the Lync Phone edition and Cisco switches.
However – I have identified a bug, confirmed by Microsoft: you can’t use LLDP to set a VLAN higher than 512 with Lync Phone Edition.
When you use LLDP to assign a voice VLAN to phones, you set the configuration on the switch itself. Below is what you configure on a Cisco switch:

(Global command)

LLDP run

(interface-specific command)

interface FastEthernet1/0/1

switchport access vlan 600

switchport mode access

switchport voice vlan 700

That’s it. When an LLDP-compliant device plugs in, the Cisco switch will tell it to use VLAN ID 700. However the Lync Phone edition, while it processes the VLAN 700 tag, it just won’t assign it to the phone. VLANs 1-512: fine. VLANs 513 and up: no go.
Doing some reading on the LLDP spec, the VLAN ID is a 2-octet field. 2 octets should yield a max of 65,000+ for the VLAN ID. Even if it were only 12 useable bits to account for padding, that would still get us to 4096 as the max. The limit of 512 only makes sense if it were only using 9 bits total. So there’s the issue, we need Lync Phone edition to use more than 9 bits for VLAN ID.
As I mentioned, this is a confirmed bug and should be addressed soon with a Cumulative Update.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

PointBridge Blogs

More from this Author

Follow Us