LLDP Voice VLAN

I'm setting up a Switchvox PBX with Digium D40 phones and Cisco SG200 switches. The PBX doesn't do any CDP or LLDP advertizing so I do not expect the switch to automatically determine the voice VLAN ID and I need to manually set it. How can I configure the switch manually to publis the voice VLAN via LLDP-MED? I've been tinkering for hours and can't make it include the voice TLV in the packets. Any able to help?

On the "LLDP MET Network Policy" page, the "LLDP MED Network Policy for Voice Application" is checked for "Auto" which I believe prevents me from adding an entry for the "voice" TLV in the "LLDP MED Network Policy Table". I've unchecked that "Auto", hit "Appy", and then was able to add the table entry.

On the "LLDP MED Port Setting" page, when I select a port and click "Edit", the resuting form doesn't have an "auto" option as you seem to suggest. The "LLDP MED Status" is on by default. I've tried manually adding the voice TLV as a "User Defined Network Policy" to no avail.

I am running firmware version 1.1.2.0 on the switch. It's a SG200-50P.

I am using VLAN ID 1 for the management interface on the switches and WAPs for this network and other VLANs for various LAN and WAN networks. I have the PBX and phones pn VLAN 1 as well. I wonder if using VLAN 1 for this is somehow throwing things off.

I've been fiddling with this for a while and sniffing traffic on the port I'm using to test. I've been unab le to get the voice VLAN included in any of the LLDP packets the unit sends.

Still not working for me. I have set "Dynamic Voice VLAN" to "Disable" on the VLAN Management -> Voice VLAN -> Properties page. I have unchecked "LLDP MED Network Policy for Voice Application" on the Adminstration -> Discovery - LLDP -> LLDP MED Network Policy page. I have added an entry to the table on that same page setting Network Policy Number to 1, Application to Voice, VLAN ID to 1, VLAN Tag to Tagged, and the priority and DSCP values appropriately. I have added "1 (Voice)" to the Selected Network Policies for the port I'm testing with under the LLDP MED Port Settings page. I am still not seeing the voice VLAN TLV added to the LLDP packets on the port in question. Maybe I need to reset this unit to factory defaults and try again.

I know it's not best practice to use VLAN 1 for traffic but we do what we must sometimes. I was just wondering if there's something special about VLAN 1 in relation to this issue I'm having.

Default VLAN is 1. This is the VLAN for the management interfaces on all the switches and WAPs. The router has a limited number of physical interfaces and no support for VLANs so I'm somewhat restricted in what I can do. I have the router interfaces connected to switch ports that are untagged members of the corresponding VLANs; WAN1, WAN2, DMZ, LAN, VOIP, & MNGT. That last MNGT VLAN was where I was going to keep all the management interfaces on all the gar and use VLAN ID 1. They added a requirement after the router had already been purchased for a separate GUEST VLAN so I chose to move the phone traffic over to the MNGT VLAN and change VOIP to GUEST. I want a router interface on that MNGT/VOIP VLAN so I can manage the gear remotely via VPN through the router. That's the why.

So, I'm curious about the "illogical" comment. I have switch ports providing untagged access to the LAN VLAN. I want to be able to attach phones to these ports and have them use the MNGT VLAN (ID 1) for their voice and signaling traffic while passing through the untagged LAN traffic to the pass-through port on the back. Make sense? I'll not argue your comment except to ask what specifically is illogical.

Natively, a port on the default vlan is untagged. If your LLDP advertisement is advertising to be vlan 1 as tagged. It is not logical. Generally when you have tag voice traffic is when you will connect a computer to the telephone, which in turn would be a data vlan untagged, voice vlan tagged.

In the above scenario, if it were to be the case, using a standard trunk port, it would require a default-vlan tagged command. But ultimately I think you can likely get a much cleaner implementation.

The LLDP advertisement will be a null point, since all port by default belong to vlan 1 unless otherwise configured.

Also the issue is, the switch is only a layer 2 switch. If the router is not supporting VLAN, there will be many issues with implementation.

The scenario you describe where phone ports have the voice-vlan tagged and the pass-through data-vlan untagged is the way I've setup a number of small business networks using Polycom phones. AFAIK, it's the way they and Digium expect. They don't provide a way to configure the VLAN ID for traffic on the the phone's pass-through port; just the phone's voip traffic. I've not worked with a Cisco phone so it may be different that what you've seen.

Anyway, I was not under the impression that the SG200 switches would do layer-3. Sorry for being dense but how to I put it in lawyer-3 mode? That would definitely resolve some of my issues.

Hi Paul, I edited my previous post, releazing it is sg200 switch. Please double check. The SG300 is the larger counterpart which does.

Cisco phones are exactly the same, actually most phones I've encountered are where the operational VLAN is the voice vlan ID and the data vlan is specified. Phones by default make the operational vlan a tag packet to work in cohesion with a data vlan untagged configuration.

But the entire point is, since your default vlan 1 is, the lldp advertisement is moot since it is advertising the same information of what is the port by default - vlan 1.

In a pure layer 2 environment, only the vlans will communicate amongst themselves, which includes the routers only subnet. If the router doesn't support some sort of vlan, sub interface, multiple subnet assigned to an interface, or anything, the l2 switch won't work well to this router.

I'm using SG200's, not SG300's so that won't work for this. I'll make a note of it though for the future.

Circling back though, I believe your "illogical" comment was in reguard to a port providing both tagged and untagged access to the same VLAN. I get that and am not suggesting that. I have a internal LAN using VLAN 100 and another WiFi network using 101. I am using VLAN ID 1 for my "default" VLAN for the management interface on the switches and WAPs as well as unused switch ports. I have the "used" switch ports configured for untagged access to one or the other VLAN. One switch port for on each VLAN is connected to the corrsponding interface in the router. I have the PBX on an untagged VLAN 1 switch port. I have added VLAN 1 tagged to switch ports for phones; the ports are also set for untagged access to VLAN 100. I can manually configure the phones to use VLAN 1 for voice. All this works and will be the way I deploy it unless I can figure out this LLDP.

I had hoped for two (new for me) features:

automatic addition of the tagged voice vlan to switch ports where phones were detected

automatic vlan configuration on the phones

I have yet to see a single LLDP packet from these Digium phones so I believe the first item above is a non-started. I'm exploring the second in order to simplify the process of deploying the phones but there are only 40 of them to start with so it shouldn't be that big a deal.

There are 2 distinctions, on the IPV4 configuration of the switch, you can specify the management VLAN (under the management interface section). Versus the VLAN management (under the vlan section) you may specify the default VLAN.

From what it seems, Data vlan is 100, voice vlan is 1. Therefore your data vlan should also be the default vlan which resides at 100u.

So, it seems the management vlan (voice vlan) should be vlan 1, which is fine. The default vlan (data) should be 100u. Can you give this some tinkering or verify this is how it is working?

Once the LLDP is working, the port vlan membership should show 100u, 1t (dynamically assigning the 1t).

It's still not working as I expected but I'm thinking the Digium phones are not sending LLDP packets that the switch expects so the automatic features of the switch are not kicking in. I'm moving on using the manual configuration since this is a small deployment. Thanks much for the help on this. I'll mark your last post as "Correct" since it seems you tested it and I'm pretty sure it'd work for me if these phones behaved as expected.