We have 76 T46G SIP phones on our network. Some are running firmware version 28.71.0.224, and some are running 28.72.0.25.
They are all connected to Juniper ex3300 series switches, all of which run Junos 12.3R6.6. The switches are powering the phones over PoE. The switches have LLDP and LLDP-MED enabled on all ports.
We are seeing that phones randomly do not get assigned to the correct VLAN, as advertised by the switch to which they are connected.
Has anyone else had trouble with LLDP-MED on the T46G??
We are doing a deployment right now, and it is proven very difficult to troubleshoot this potentially spurious issue.
Thank you.
Yes we do have, with 28.72.0.25, out of unknown reason.
For now, as workaround, we use dhcp option 132 in our untagged data vlan dhcp scope, with string value <id_of_tagged_voice_vlan>.
From this, the phones will get ip addresses out of data network first, but then move over to voice vlan. Not nice, but worked reliable so far.
Hope this helps.
Thanks for the info. Have you contacted yealink support about this bug?
Also, we are using Windows Server as our DHCP server. I have attached a screenshot for configuring the Option 132 setting. Do you know how to configure it properly?
Does this setting not assign the VOIP vland-id to all machines in the data vlan?!
Thank you for helping with the workaround.
I did not have talked with Yealink about the problem until now. For the workaround I use for the moment you will need:
1) You have to configure your switches to act as dhcp proxy / use ip helper addresses to forward the dhcp requests from your machines to your dhcp server. We dont use Juniper, so I cannot tell you the specific commands.
2) You need to configure your dhcp server with 2 dhcp scopes for a) <ip_scope_for_vlan_data> and b) <ip_scope_for_vlan_voice>. At a) you configure option 132 = <vlan_id_voice>. At b) you probably want to configure a Vendor Class "yealink" with option 43 = <http://your_provisioning_server/yealink> or whatever else points to you Provisioning Server.
By that, all phones will first get ip addresses out of you data scope, seeing 132, move over to vlan_voice, do a second request for another ip there, see also option 43 and therefor request from your provisioning server the common and mac files.
Option 132 will be ignored by your pc's, only used by your phones.
For further information you also might take a look at "VLAN Feature on Yealink IP Phones.pdf" from Yealink (probably you already have done so).
I dont see a screenshot from you, sorry. But we use Windows dhcp too, w2k8r2.
I didn't had time to take a deeper look into our problem with LLDP, same time pressure as you. Just looking for a quick solution to get around it.
Thanks Timalex!
I do have the Juniper switches configured to do DHCP relaying between VLANs, etc, so that part of the config is ready.
I forgot to attach the screenshot to the last posting... it IS attached to this one. Do you know how to complete the configuration dialog for option 132 on Microsoft DHCP server?
Also, I opened a support ticket with Yealink about this problem, and they have suggested that it may be an issue with lack of sufficient power to the phones while they are booting up. We are investigating.
Thanks!
(06-23-2014 08:25 PM)joebocop Wrote: [ -> ]Also, I opened a support ticket with Yealink about this problem, and they have suggested that it may be an issue with lack of sufficient power to the phones while they are booting up. We are investigating.
I would not agree to this. Think it's a matter of timing or/and specific implemetation of LLDP.
First guess, our Cisco switches do something called "Smartports", they configure the port settings dynamically on what they find by CDP or LLDP discovery protocols. It might be that the information about the voice-vlan coming from the switch is just not reaching the phones at the correct moment ...
Second, and I believe this one is actually what happens, some switches like our Ciscos send LLDP informations by more than one packet, which have to been taken into consideration by the phones LLDP implementation. The phones have to wait a little bit after the first LLDP packet received, if some more information ist coming in (remember, LLDP ist stateless). Digium agreed in the past already that they had this problem with their phone firmware. And fixed it.
Quote:1_3_3_0_55755
Issues Resolved:
The phone now accommodates certain Cisco switches and 'switchport mode trunk', a setting that could take a long time to negotiate the link with the Digium phones. This extra delay prevented the phone from acquiring LLDP-MED information.
Phone now looks at additional packets from the switch until it receives all the LLDP-MED settings. This accommodates certain Cisco switches (eg. Cisco SG500X) that do not send all the LLDP-MED policy settings on the first packet to the phone.
Phone now sends an LLDP packet with TTL of zero, to clear the cache on the switch so that it responds with the proper LLDP-MED settings.
For dhcp configuration please take a look at the two attachments for what I did:
Hi joebocop,
My colleague will deal with your issue in the ticket.
Sincerely thanks for your support to Yealink product!
Best regards!
Any news until today about what's going wrong with setting voice vlan by LLDP-MED in this case?
Is Yealink aware about the tiny difficulties in LLDP information exchange I cited above from Digium Support?
Thanks for updating me about this topic.
Hi,
We haven't begun the troubleshooting process yet. Yealink tech support has requested some packet captures and advanced logging from a phone exhibiting the behaviour, and I have not yet provided them with that data. I will definitely update this thread as things progress. Thanks again for the help!
I have this issue as well. WE have T22P and T46G phones. Running the latest firmware on them (as of today). Most of the time the T22P get the right VLAN, but not always. The T46G seem to always be worse and right now I have two that simply won't go to the right VLAN using LLDP.
I use a Cisco SG500 POE switch. LLDP is setup. The switch uses smartport as someone mentioned.
It is very annoying.