Finding the VLAN ID
Topic Last Modified: 2012-10-17
Devices can join a virtual LAN (VLAN) in order to separate the Voice over IP (VoIP) traffic from other traffic in the subnet. The first step for a device connecting to Lync Server is to determine the ID of the VLAN to join.
Devices in running Lync Server will first send an Linked Layer Discovery Protocol (LLDP) request to the switch. If the switch does not respond in time, the device falls back to DHCP to discover the VLAN.Not all switches are LLDP enabled, and prior to Lync Server, DHCP was the only method available for a device to discover its VLAN ID.
Issue: The switch is set up to provide VLAN ID, but fails to respond for some reason. This may be due to a problem on the switch or on the device. The device displays Acquiring IP Address on the Sign In screen.
To determine that the device is unable to obtain a VLAN, check the device’s System Information.
To check System Information, on the Acquiring IP Address screen press Cancel. In the Sign In screen, select Advanced from the options available, and then select System Information. Scroll down to view the VLAN ID. If the value is 0, then the device has been unable to obtain a VLAN identifier.
Resolution: The device is incorrectly connected to the network. Check that the device has the LAN cables correctly connected. One LAN cable should connect the device to the network, and the other connect to anything downstream from the device such as a computer (in the case where network ports are limited, connecting the device between a computer and the wall is a way to introduce a device without requiring an additional dedicated port for the device). To do this, reset the device. The device will turn on and cycle through the bootstrapping process and should present the user with the option of entering their credentials (if the device has no valid credentials, for example if this is the first time the device has been used), or will connect to the Registrar and display the Home screen.
Resolution: The switch is not set up correctly to return the VLAN ID. If the network has been set up so that the Switch should be providing the device with the VLAN, verify that the switch the device is connecting to is set up to publish a VLAN.
Issue The Switch is not set up to provide the VLAN, instead DHCP is intended to provide the device with this information. For details, see "Issue 1: No Response from Switch" section in this topic.
Resolution: Check the DHCP server(s) the device would send DHCPDiscover queries to. The DHCP server(s) for the scope of addresses in which devices will be connecting must be set up with Option 43: VLAN enabled.
Option 43 is not enabled by default on most DHCP servers. It must be enabled on all scopes for which devices running Lync will be signing in. Option 43 is used to provide vendor-specific information. In the case of Lync Server, all devices include this option and their class id when sending DHCPDiscover and DHCPRequest. This allows the DHCP server to recognize the unique ms-uc-client class, and respond with appropriate information, such as a VLAN.
The following applies to issues 1 and 2:
The initial search for a VLAN will release any previously acquired device IP address.
The device waits 6 seconds for the LLDP query sent to the switch to be responded to. Switches do not return error responses to the LLDP query, so a timeout can be assumed to be a failure, a network drop out or timeout, or both.
VLAN IDs are cached, so that they can be reused and the device will connect quickly when it is restarted. If the cached VLAN ID is incorrect, the device will release the ID and try to obtain a new one.
The class ID for devices running Lync is MS-UC-Client.
DHCPUtil.exe is a tool provided in the Lync Server Resource Kit that helps determine which DHCP options have been set up on a Windows DHCP server, and helps set up any missing option correctly. For details, see Using DHCPUtil.
For details about the DHCP protocol, see "How DHCP Technology Works" at http://go.microsoft.com/fwlink/p/?LinkId=202876.
A VLAN ID is not required for all network connectivity, however we recommend using one for all enterprise deployments because it separates the VoIP traffic from other network traffic.