LLDP with VoIP Phones

Introduction

The purpose of this document is to give guidance on which phones have been actively used in projects and are known to work well with the Tellabs GPON system. In general, most devices are transparent, but some phones are not compliant with the standards and require some additional configuration for proper operation. The list below is not an exhaustive list and any phone should be able to work with the system. Some phones just require a slightly different configuration for operation.

Document Number

ENG-010405

Applies To

This applies to all Tellabs OLAN products.

Tested Phones

The following phones have been deployed with the Tellabs OLAN product:

Phones known to Support LLDP-MED

• Avaya 9600 Series with firmware release 1.2.1 or above.
• Avaya 4600 Series with firmware release 2.6 or above.
• Cisco 7906G
• Cisco 7911G
• Cisco 7931G
• Cisco 7941G/GE
• Cisco 7942G
• Cisco 7945G
• Cisco 7961G/GE
• Cisco 7962G
• Cisco 7965G
• Cisco 7970G/GE
• Cisco 7975G
• Nortel IP Phone 1110
• Nortel IP Phone 1120E with firmware 0624C23
• Nortel IP Phone 1140E with firmware 0624C23
• Nortel IP Phone 1210
• Nortel IP Phone 1220
• Nortel IP Phone 1230
• Nortel IP Phone 2001 with firmware version 0604DAD and above
• Nortel IP Phone 2002 Phase 2 with firmware version 0604DAD and above
• Nortel IP Phone 2004 Phase 2 with firmware version 0604DAD and above
• Nortel IP Phone 2007 with firmware version 0621C3A and above
• Ring Central/Polycom VVX201
• Ring Central/Polycom IP335

Importance of LLDP MED to Voice

The Link Layer Discovery Protocol (LLDP) is a vendor-neutral link layer protocol in the Internet Protocol Suite used by network devices for advertising their identity, capabilities, and neighbors on an IEEE 802 local area network. The protocol is formally referred to by the IEEE as Station and Media Access Control Connectivity Discovery, specified in standards document IEEE 802.1AB.

LLDP-MED is an extension of the protocol which was published as part of ANSI-TIA-1057 and supports:

• Auto discovery of LAN policies such as VLAN, Layer 2 Pbit marking, and DSCP settings.
• Device location discovery for E911
• Extended management of PoE endpoints.
• Inventory Management to find the manufacturer, software and hardware versions and serial or asset number.

LLDP and LLDP Med are used by switches to perform automatic configuration of the VoIP VLAN on the VoIP phone. It is also used by some phones to perform communicate fine grained power information to the switch and in some cases to request 802.3at power levels from the ONT.

LLDP MED and Voice VLAN

For phones that support the configuration of Voice VLANs via LLDP, the Tellabs OLAN system can be configured to pass this information on to the phone.  This is done with the Network Policy TLV in the LLDP messages.

Configuring the system to send the Network Policy TLV allows the phone during its boot cycle to configure itself automatically with the Voice VLAN.

There are several steps to configuring the LLDP Network Policy on the system.

The TX Interval for LLDP also needs to be modified to have a 60-second interval.

This dialog is reached by clicking on the NE in the common tree, right-clicking, and selecting:

Protocol->Link Layer Discovery->Configuration Tab

Next, the user needs to ensure that the LLDP Profile has LLDP Enabled, LLDP-MED is enabled, and the Network Policy is Enabled.

Attributes Recommended Being Enabled

• Admin State - Must be enabled for LLDP to be sent/received.
• Capabilities - Enables use of LLDP-MED capabilities.
• Network Policy - Sends VLAN ID to phone for VoIP.
• Extended Power via MDI(PSE) - Recommended to always be enabled as it allows negotiation of fine-grained power control.
• Delay Untagged VLAN Access - This should be set if LLDP is being used to communicate the VLAN ID to the phone. If the phone is sending its traffic untagged, this is not required. The default of 60 seconds typically works well. This Attribute will only be present in OLT/EMS load SR30.0 and above. It it not used in earlier releases.
• LLDP VLAN Assignment Delay (sec) - Defines the max amount of time to wait before allowing default VLAN access without LLDP exchange. This attribute will only be present in OLT/EMS load SR30.0 and above. It was not used in earlier releases.
   

The service profile also needs several attributes set:

• Class of Service - nrt-VBR, this will put the voice traffic on a separate TCONT on the PON. The nrt-VBR TCONT is serviced prior to UBR so therefore, it will give it higher QoS on the PON.
• 802.1p Marking Mode - Set to Static. Since only the phone is on this VLAN, we can statically mark all of the voice traffic with the desired priority.
• 802.1p Priority - Typical priority is 5 in most installations. Should be governed by your local policy.
• Subscriber VLAN - The VLAN ID to be sent to the phone. Subscriber VLAN indicates that the traffic from the phone should be tagged on ingress with the specified VLAN.
• LLDP DSCP - Optional, defines the DSCP to be used by the phone. It will be sent to the phone in LLDP messages.
• LLDP Application Type - Should be set to an application type of 1, which is Voice.
  • Polycom CX600 Lync Phone requires an application type of 9. The polycom phone is not compliant with LLDP and can sometimes miss the VLAN assignment in the LLDP message. When the system sees an application type of 9, it knows the phone is not compliant and performs special handling on the LLDP interface to ensure proper VLAN assignment. This may also occur with other phones. If the user notes unreliable VLAN assignment, select an application type of 9.

Then the LLDP profile and service profile need to be assigned to the line.

The user can view the LLDP exchange via the Ethernet Port->Protocol->Link Layer Discovery on the Status Tab.

The following screen shows the Network Policy attribute and VLAN ID. It also shows the result of the LLDP Extended Power Via MDI attributes, which are used for fine-grained PoE power control.
 

Common Phone Issues

Many vendor phones do not properly implement the LLDP interface, which can lead to issues with LLDP-managed phones. This section will define some of the common issues seen and recommended ways to resolve the issues.

Tellabs has done its best to put in workarounds where possible for phones incorrectly implementing LLDP. It is recommended that you always run at least FP27.1_015130 or greater load to get the benefit of these workarounds.

Typical Problems

There are several classes of problems that are seen in the field related to the improper LLDP-MED implementation by phones:

• The phone will end up registered on the Data VLAN.
• PCs will not be able to get onto the Data VLAN when Max Macs are set to 1 on Data VLAN.
• Cisco Phones stuck in Configuring state on Reboot/Upgrade of OLT.

Tellabs has implemented workarounds to most of these issues with incorrect LLDP implementation in the FP27.1_015130 maintenance release.

Phone Registered on the Data VLAN

The Cisco IP Phones demonstrate the following boot-up sequence:

1. Send DHCP request untagged (no 802.1q header).
2. Send IPv6 Router Solicitation (DHCPv6)
3. Send CDP
4. Finally, send LLDP-MED

If a port has both an untagged data VLAN and a tagged Voice VLAN on the same port, this may result in the phone getting registered on the Data VLAN.

Since the LLDP-MED is coming last, the Cisco IP phone may end up getting an IP on the Data VLAN. If a route exists on the Data VLAN back to the CUCM, then the phone may also get registered on the Data VLAN.

Tellabs has put in code that ensures that reception of packets on the untagged VLAN will be suppressed until the LLDP TLV posture of the neighbor device has been confirmed to match the posture advertised by the OLT. This means that the DHCP and CDP messages will be suppressed on the untagged VLAN until it is determined what, if any, LLDP support is available on the neighbor device.

To enable this behavior, the RSTP profile must have three attributes configured:

• Administrative state set to Enable
• Admin Edge Port flag set
• Not required, but in most situations Enable BPDU Guard Violation should be set
   

PC cannot get online when Max MACs are set to 1

One other consequence of the phone's implementations is that if the system administrator has set Max MACs to 1, the phone may talk on the untagged VLAN and steal the MAC entry, causing the PC to be denied. This can be resolved in pre-FP27.1 releases by setting the Max MACs to 2. The system in releases after the FP27.1 maintenance release will also ignore CDP requests when counting MACs. This allows Max MACs to be set to 1 and work.

Cisco Phones stuck in Configuring State after Reboot/Upgrade

If the OLT revokes the LLDP-MED Network Policy (Network Policy is the TLV that has the VLAN for the phone), such as what may happen during a software upgrade or reconfiguration of a profile, the IP Phone can get stuck showing "Configuring IP" and will no longer be operational. According to the specification, this should not cause an issue, but appears to cause a problem for Cisco phones. If the phone goes into this state, it must be rebooted. Note: as a workaround, this can be done remotely by changing the PoE profile of the phone to disable delivery of PoE and then change the profile back to deliver power. This will turn all phones off, then on with a single change.

Code was placed into the system in the FP27.1 maintenance release to wait until the LLDP posture is determined before allowing packets upstream on the untagged VLAN.

Ring Central / Polycom Phone LLDP Issues

Several of the Ring Central phones require specific LLDP configurations for proper operation of the phone. If the LLDP is not set up correctly, the phone will not acquire the Voice VLAN and will not come online.

The Ring Central phones require:

• Chassis ID - subtype(5) Network address
• Port ID - subtype(3) MAC address
• TTL
• Port Description
• System Name
• System Capabilities
• LLDP-MED - Capibilities
• LLDP-MED - Network Policy
• LLDP-MED - Inventory

Below is a sample profile to be used with Ring Central / Polycom Phones.

Video