UntagPvidOnly Affect QoS???

[m@sterbl@ster]

Hello Everyone,
 
When a packet is egressing an access port, does the QoS occur before or after 802.1Q tags are removed by the VLAN tagging function (e.g. untagpvidonly)?

The reason I ask is I have been searching for an explanation as to why every Nortel and Avaya document recommends "UntagPvidOnly" , as apposed to "UntagAll(access)" in a VoIP environment. I understand how these settings affect the tags of packets egressing a switch port, but I am struggling to see the benefit of a phone receiving voice traffic tagged or untagged.

At the present time all our access ports are set to "UntagAll" and everything appears to be operating perfectly fine.
 
Before I go and change every port's VLAN config in our entire network I was hoping someone can ease my frustration on this topic.

Thanks a million,
Bryan

[Michael McNamara]

Hi Bryan and welcome to the forums!

There's no need to go about changing all your switch configurations.

The real use of UnTagPVIDOnly has to-do with the ability to use a PC port on the back of the IP phone to provide connectivity to a single personal computer and IP phone over a single CAT5/6 cable drop. When switching both data and voice traffic across the network it's generally advisable to segment them into separate VLANs. In this scenario the voice VLAN is tagged (802.1q) while the data traffic is untagged (PVID). The scenario allows you to generically configured every switch port to support an IP phone (requires the use of ADAC/LLDP), you no longer need to identify which ports are used for IP telephony... just set every port to UnTagPVIDOnly, enable ADAC/LLDP and set the PVID to the data VLAN for that switch/stack/closet/building/etc.

The other benefit is that since the voice VLAN packets are already in an 802.1q format they'll have the 802.1p/CoS (Layer 2) bits on them along with the IP DiffServ (Layer 3) bits.

If you only have a few dozen IP phones then there's no real worry and no need to segment then into their own VLANs, etc. If you have hundreds of IP phones with hundreds of PCs then you might want to consider making some changes. If you are running thousands of IP phones with thousands of PCs then you'd most probably already be having speech/quality issues.

If your not using ADAC/LLDP then I would probably be more concerned about your QoS configuration then playing around with the UnTagPVIDOnly feature. At a minimum (assuming that you don't hang anything off the PC ports of the IP phone) you can just create a QoS if-group and set the if-group to 'trusted', then associate all the switch ports that are connected to your IP phones to that QoS if-group. In that way the switch will honor any CoS/QoS bits/tags that come across from the IP phones.

You can see an example configuration in this blog post.

Hopefully that helps!

Cheers!

[m@sterbl@ster]

Hello Michael,

Your detailed response is greatly appreciated.

The network I maintain has a fairly large Nortel VoIP deployment and we currently have numerous sets that have PCs plugged into the back of them.

Here is a quick summary of how I have things configured:

-no ADAC or LLDP
-separate VLANs for data and voice
-data VLAN as the PVID
-untagall on all access ports
-full dhcp on Nortel VoIP sets
-QoS via L3 classifiers (access ports untrusted)

This all seems to be operating perfectly fine from the traces that Ive done, but I may be missing an added benefit from tagging voice traffic egressing a port connected to a phone.

So to rephrase my initial question:

Doesn't a VoIP set (with a PC plugged into it), look at the destination MAC address of a packet (regardless if it is tagged or not) to check if the packet is destined for it and if not then sends it out its PC port?

Sorry to beat this to death, but I think I am really missing something here.

Thanks again Michael,
Bryan

[Michael McNamara]

Doesn't a VoIP set (with a PC plugged into it), look at the destination MAC address of a packet (regardless if it is tagged or not) to check if the packet is destined for it and if not then sends it out its PC port?

You are correct in so far as you can consider the IP phone a two port switch/bridge (there were early IP phones that had multiple switch ports available). If you take that approach though then all the devices need to be in the same VLAN, yes? Without an 802.1q header the switch can't determine which VLAN the packet should be in, again just like any other layer 2 switch. If a packet arrives at your edge switch from the IP phone untagged it will be place in the VLAN that is configured as the PVID for that port. If a packet arrives at your edge switch from the IP phone with an 802.1q header it will be placed in the appropriate VLAN so long as that VLAN is a member of the port.

You made one comment that appears (to me anyway - but please don't consider me an expert) to be contradictory. You said that you have seperate VLANs for data and voice, however, the switch ports that connect the IP phones are configured as UnTagAll (Access)? Are you sure that this statement is true, are the PCs connected to your IP phones really getting IP addresses in a different VLAN than the IP phones themselves? How many VLANs are a member of the edge switch port? Are you configuring the data VLAN ID in the IP phone?

It takes a little time to catch on to the idea but once you have it things should start to make sense.

In my environment we configure every IP phone with a standard (generic) configuration so that IP phone can be made to work at any of our locations without any additional configuration. It's made the transition for our telecom team much less painless than say having to specially configure an IP phone with specific VLANs or IP addresses per physical location. In the same sense we use a generic configuration on all our edge switches. We no longer need to know which ports will be used for IP telephony, nor does the telecom team need to contact us if they wish to move/add/replace/etc an IP phone. We use ADAC/LLDP on the ERS 5520 switches to automatically reconfigure the edge switch port when it detects an IP phone making the necessary VLAN and QoS configuration changes along with LLDP-MED providing the voice VLAN ID that the IP phone should use when communicating with the IP telephony backend. Once the LLDP-MED information has been passed the IP phone will make a DHCP request which will be tagged with the voice VLAN 802.1q header so the IP phone will get an IP address in the proper voice VLAN. Anything connected to the PC port will be passed through the IP phone untagged and when it hits the edge switch port it will be bridged to the VLAN set as the PVID for that port. Likewise any return traffic to the phone will have an 802.1q header unless the VLAN ID matches the PVID (UnTagPVIDOnly), in that case the edge switch will strip the 802.1q header and pass the untagged frame down to the IP phone which will then pass it to the PC port.

I had better proof read this really quick... I'm starting to confuse myself.

I stop there for now... let me know if that makes sense. There's probably a blog post in there somewhere.

[m@sterbl@ster]

Haha. Yes your post make total sense and thanks again for the discussion.

To clarify a few things here is an example of one of our VoIP sets booting:

1. VoIP set is set to full DHCP (Telecom guys can just plug in a new set without having to set any parameters)
2. Phone and PC send an untagged DHCP request which is tagged by the switch with the PVID (data vlan)
3. DHCP server gets both DHCP requests and responds with data IPs for both the PC and the phone
       3a -DHCP offer has Voice VLAN option
4. PC doesn't care about the Voice VLAN option and is "happy" with its DHCP settings and operates in the data VLAN
5. Phone gets Voice VLAN option, releases data IP address, reboots and begins tagging its packets with the Voice VLAN
6. Phone sends an additional DHCP request that is tagged with the Voice VLAN
7. DHCP responds by sending a Voice network IP address to the phone
       7a -DHCP offer has Signalling Server option for the phone
8. Phone gets the Voice IP info and contacts the signalling server and is "happy" operating in the Voice VLAN

I understand that this sounds like a lengthy, complex process, but it only takes the phone ~30 seconds to boot.  I am sure ADAC/LLDP could simply this, but transitioning to ADAC now with all our QoS and VLAN config would be a nightmare.

Like I said before, I have done packet traces at the switch port of the phone (with the PC plugged in it), at our network core and at the signalling server and all tags are in place and QoS appears to be operating as it should all the way through our network.

How I picture this is the switch on the back of an VoIP set is smart enough to differentiate between packets for the phone and for the PC regardless of the tagging info by the destination MACs of the frames.  So again I wondering if the QoS queuing egressing the port is done before the tags are ripped off or after?  Because if the tags are being removed before a QoS L2 VLAN classifier is applied to a packet, there would be no QoS for Voice traffic egressing a switch port.

Now I have to proof read because I am starting to scrabble my brains.

Thanks for sharing your knowledgeand your time Michael and I hope to hear from you whenever you have a free moment.

Bryan