MS-350, DHCP, and VOIP

[RichBottiglieri]

I'm experiencing an odd issue, and I was wondering if anyone in the community has seen this before.

We have Meraki MS-350 switches running firmware 14.33. We are using Yealink T48S VOIP phones with GoToConnect as our service provider. The desk phones are on a separate VLAN and DHCP is enabled on the VLAN.

After a recent desk phone firmware update, our desk phones are unable to successfully register with GoToConnect upon rebooting. I am able to ping the phone and access its web GUI from my desktop PC VLAN. The phone certainly appears like it is functioning normally on the network except for registering with the provider.

The workaround is to either set a static IP address on the phone or to reserve the IP address on the Meraki switch. If either of those things are done, the phone comes up and registers without a problem. If I remove the IP reservation and reboot the phone, it will grab another IP address and fail to register again. I cannot understand why this might be. My gut feeling is that this is a bug in the phone firmware, but the VOIP provider hasn't been able to nail this one down definitively.

Has anyone run across something like this? Is it generally best practice to reserve the IP addresses of desk phones on a VLAN? Any insight would be appreciated.

Thanks in advance!

Rich

[DarrenOC]

Never had to set static IPs on phones and I’ve worked on numerous voice platforms.

Sounds like a bug with the firmware the phones are running.  Are you able to roll back the firmware?

[RichBottiglieri]

Totally agree, and I'm working on that with them. Still, from the phone's perspective, what is it seeing differently about the network when the IP address is reserved versus when it's just dynamically assigned?

[DarrenOC]

LLDP or LLDP-MED is broken maybe hence why it can’t find a dhcp server?

[RichBottiglieri]

You beat me to it!

I went ahead and removed the DHCP reservation from my phone. Upon a resync, the phone came up and it failed to register. I rebooted the phone again, but the problem persisted.

From the admin interface of the phone, I went in and disabled LLDP and CDP, rebooted, and voila, the phone registers and comes back up.

I've asked the vendor for their guidance on this, but this seems to be a firmware issue.

Thanks.

[RichG]

Do you have a voice VLAN set on those ports?  The voice VLAN is given out via LLDP, so the phone may be seeing it and trying (failing) to tag traffic on that VLAN.  Removing the voice VLAN from the port will remove it from the LLDP advertisement so the phones will use the untagged VLAN.  If it isn't there, maybe changing the untagged VLAN and putting the VLAN you want the phones to use in the voice VLAN field will make them properly tag the packets and it will work.  Either way, this will give you and their support team more data points.

[RichBottiglieri]

Thanks, @RichG. Right now, I only have the VLAN field populated with the correct VLAN. I will switch to using the Voice VLAN field and see if that helps. This isn't something I ever had to do before, though, so it would be new. Still, I'd rather manage these things on my side as opposed to waiting for the VOIP provider to get around to it. I'll try it and report back.

[RichBottiglieri]

@RichG, I just populated a dummy value in the "VLAN" field and used the correct VLAN number for the "Voice VLAN" field, and it's all working. Interesting that this was never required before, but I'll do some validation both in the office and with the vendor before making this change on all of my phone ports. Thanks for the tip!

[RichG]

Configuring a port for access with a voice VLAN essentially configures it as a trunk port with the access VLAN as the native VLAN and the voice VLAN as an allowed VLAN.  It also advertises the voice VLAN in LLDP.  Phones are supposed to listen for that, then do DHCP with tagged packets on the voice VLAN instead of untagged packets on the native VLAN.  That way you can have your workstations on the native VLAN and the phones on the voice VLAN without dedicated phone ports configured.  Here's the obligatory Meraki documentation:

https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Configuring_the_MS_Access_Switch_for...

It sounds like the latest firmware of the phones isn't properly handling the case where LLDP doesn't give it a voice VLAN.  They should just use the native VLAN in that case.  Disabling LLDP causes them to not see any LLDP and not try whatever incorrect behavior they are doing when the see LLDP.  Hopefully, configuring the voice VLAN on the switch so LLDP has it defined will make them behave in a more reasonable way.  (And it's probably what you want in the long run anyway.)

If that does fix it, make sure you pass that on to their support people to help them find the bug in their firmware.

[RichBottiglieri]

@RichG, this seems to have done the trick. Quick question, though. The VOIP phones have two ports: "Internet" and "PC". The "PC" port on most of our phones is unused since our PCs are plugged directly into their own port on the switch (and on a separate VLAN). However, I do have a few portable IP phones that I currently have plugged into the "PC" port of the phone. In this case, should both VLAN and Voice VLAN be set to the voice VLAN value?

[RichG]

No, the VLAN should be set to the VLAN that the workstation should be on if it wasn't connected through the phone and the voice VLAN should be set to the voice VLAN.  The phone (or at least every VoIP phone I've ever dealt with) will pass through untagged traffic to the PC port on the phone.  

If you want the phone and the workstation to be on the same VLAN, then you should leave the voice VLAN blank (which these phones don't seem to like) so all the traffic is untagged.  From your original post, it sounds like you already have separate voice and workstation VLANs, you just weren't using the voice VLAN feature.

[RichBottiglieri]

Yeah, so that's the issue. The portable phone is currently plugged into the "PC" port on the phone. Before this firmware update, that wasn't a problem since I wasn't making use of the "Voice VLAN" value on the switch port, and the "VLAN" value was just set to the voice VLAN value.

Now that it seems I'm required to use this field, it looks like I'll need to connect those portable phones to their own port on the switch and use the voice VLAN value just as I did for the desktop phones.