switchport voice vlan dot1p command

Answered Question
Jan 23rd, 2009

Hi every body!

I am sorry to bring up another question. As i am reviewing my book for my exam, some questions came to my mind.

Earlier , i discussed the 'switchport voice vlan dot1p" with net pro Jon, Giuseppe and Lejoe.

The command " switchport voice vlan dot1p" tells ip phone to use vlan 0 for voice and native vlan for pC data.

For voice vlan, vlan id field in dot1q header would be filled with zeros.

But how about if the ip phone has been instructed to trust cos value from pc which is using native vlan. since cos values must be passed , dot1q header is needed in frame from pc. But my question is what would be there in vlan feild? if you say nothing, does nothing mean zeros? if nothing mean zeros then how would switch connected to ip phone distinguish between vlan 0(voice vlan) and native vlan as both are identified with zeros in vlan id field in dot1q header.

Thanks a lot!

I have this problem too.
0 votes
Correct Answer by lejoe.thomas about 7 years 10 months ago

Hi Sarah,

A multivlan case occurs when using option

switch voice vlan x

With switchport voice vlan dotlp, a single vlan is used to carry both voice and data, in the above case vlan 3.

My question is if switch send priority -tagged frames as untagged frames to uplink switch, how would the cos values be passed as you said earlier, untagged frames means no dot1q header?

Switch is not sending priority tagged frames to the neigboring switch, it would remark the those priority frames with VID 3, making them vlan tagged frames carrying COS and VID.

If switch is configured to send as untagged frame, how would the cos values be passed?

I dont think it would send untagged frames, if it were sending untagged frames, then no COS information could be passed. COS is not carried beyond the next-hop.However, we must remember Layer 3 precedence is still retained.

HTH

Lejoe

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
lejoe.thomas Fri, 01/23/2009 - 19:36

Hi Sarah,

If the phone is configured to trust cost value from PC, we must assume the PC is capable of marking COS values in frames, i.e can send a priority tagged frame (based on 802.1p) just like the phone

There are two types of Tagged Frames

1)Priority Tagged Frames

2)Vlan Tagged Frames

Priority Tagged frame is a tagged frame whose tag header contains VID equal to Null VLAN ID

Vlan tagged frames is tagged frame whose tag header contains VID set to something other than null VLAN ID. (not our focus at this point)

This NULL VID is a hexadecimal value of 0. It indicates the Tag header only contains the user priority bits (i.e no VLAN identifier is specified).

So if the PC marks priority bits, it will also set the VID to null VID (i.e value 0) and all traffic on ingress at the switchport (voice and data), will fall into the native vlan. Since the switch is incapable of classifying which is voice (marked by phone )and which is data (marked by PC) because both are sending priority tagged frames with VID set to 0. (Switch is just thinking , hmmm...I guess both are voice)

However, If the PC was sending untagged traffic, then only the IP phone is setting priority tagged frames, it becomes easier for the Switch.

So I'd recommend to always configure

switchport voice vlan xx for IP phones.

Read page 68

Section 9.3.2.3 VID format

http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf

From the above discussion

But my question is what would be there in vlan feild? if you say nothing, does nothing mean zeros?

Yes , the null VID

if nothing mean zeros then how would switch connected to ip phone distinguish between vlan 0(voice vlan) and native vlan as both are identified with zeros in vlan id field in dot1q header.

Remember anything set with null VID will acquire Vlan classification on switchport ingress as per the IEEE paper (NOTE 1). So according to the switch, both voice and vlan (priority tagged) will fall into the same vlan.

Its good we keep coming back to voice vlan discussions :)

HTH

Lejoe

sarahr202 Fri, 01/23/2009 - 20:23

"if the PC marks priority bits, it will also set the VID to null VID (i.e value 0) and all traffic on ingress at the switchport (voice and data), will fall into the native vlan."

here is what my book says"switchport voice vlan dot1p command will cause the voice traffic to use vlan 0 and pc data traffic native vlan"

thanks a lot Lejoe!

Looks like my book is wrong again.

lejoe.thomas Fri, 01/23/2009 - 20:31

Hi Sarah,

By using switchport voice vlan dotlp, switch is informing the phone to use priority tagged frames for voice. So voice will use null VID 0, and PC, which is sending untagged traffic will fall into native vlan.

Normally priority tagged frames incur vlan reclassification on ingress, which why I said chances are both voice and vlan will fall into the native vlan.

HTH

Lejoe

sarahr202 Fri, 01/23/2009 - 21:27

As you said before null vlan and native vlan will be identified by zeros in vlan id field in dot1q header. From switch perspective, both are using the same vlan call it null or native.

Is it correct ?

lejoe.thomas Fri, 01/23/2009 - 22:12

Hi Sarah,

With the option switchport voice vlan dotlp.

The phone is being informed to use null vlan ID, 0 for voice. However, PC is sending untagged traffic.

On ingress at switchport, the IEEE standard mentions a switch must never transmit priority tagged frames (those with VID 0). Hence it must associate such frames with an actual VID or send it untagged. Depending on how the port is configured (trunk mode), such frames will fall into the native vlan.

If the PC is capable marking of COS, it will do the same as an IP phone, with dotlp option configured.

So finally switch will receive all frames from the PC and Voice from IP phone with null VID set. From that point, as per the standard it must associate it with valid VID for transmission or send it untagged.

As you said before null vlan and native vlan will be identified by zeros in vlan id field in dot1q header. From switch perspective, both are using the same vlan call it null or native.

Is it correct ?

Yes (for null VID), for priority tagged (from phone to switch ingress) frames, since they must use dotlq header, just to set user priority bits, it sets VID in the frame to 0. When such frames enter the switchport, as per standards the switch must (Section 8.4.4 of the paper) tag it with a non null VID or send it untagged. Native vlan should be non-null VID, which the switch associates with such frames.

HTH

Lejoe

sarahr202 Sat, 01/24/2009 - 08:41

Thanks a lot Lejoe!

First let me get the terminology straight.

Priority tagged frames are frame with vlan id=null

Quote from the your link:

"NOTE 1-The specification of the ingress and egress rules for VLAN-Aware Bridges (8.6, 8.8) is such that a Bridge

does not propagate priority-tagged frames; a received priority-tagged frame will acquire a VLAN classification on

ingress, and will therefore either be forwarded as an untagged frame, or as a tagged frame tagged with that VLAN classification,

depending upon the egress configuration for that VLAN. priority-tagged frames are therefore only ever generated

by end stations"

what is untagged frame? is it not the frame with vlan id=0?

If you mean untagged mean no dot1q header, then cos values would be lost, so only thing i could think of untagged frame is frame with vlan id=0

.

So when a switch receives a frame with vlan id=0, it could be that priority tagged frame (vlan id=o) from phone and untagged frame( vlan id=0) from PC.

The question is a switch must make a distinguish between the two. According the the link" a received priority-tagged frame will acquire a VLAN classification on

ingress, and will therefore either be forwarded as an untagged frame, or as a tagged frame tagged with that VLAN "

So switch must figure it out which frame is priority tagged frame and untagged frame .

How would switch determine that given that both types are identified by vlan id=0?

thanks a lot!

lejoe.thomas Sat, 01/24/2009 - 16:15

Hi Sarah,

An untagged frame would be one with no dotlq header at all.

With a phone and pc example, switch receives priority tagged frames from phone for voice [VID:0]and untagged from from phone for PC [no dotlq header at all].

Now from the above you can see as long as PC is not marking COS, phone is setting VID for voice frames to 0 and sending frames from PC as untagged.

So that's how the switch would distinguish between the two.

HTH

Lejoe

sarahr202 Sat, 01/24/2009 - 19:30

how about when pc start setting cos values and trust is extended to it. This time Pc needs dot1q header to carry cos values. Then what would be vlan id field carry?

Let say we have following setup:

sw---------ip phone--------PC

I use the command on sw

mls qos extend trust

switchport voice vlan dot1p

switchport access vlan 3

According to my book, voicetraffic will use vlan 0 or priority-tagged frames.

Pc will use native vlan (untagged)

Pc is also setting the cos value so it needs dot1q header. Now what would be in vlan id field in dot1q header?

thanks a lot!

sarahr202 Sat, 01/24/2009 - 20:15

correction to my last post

The command ' mls qos extend trust be ignored and command " switchport priority extend trust " be considered instead.

thanks

lejoe.thomas Sun, 01/25/2009 - 01:25

Hi Sarah,

switchport voice vlan dot1p

switchport access vlan 3

From my understanding if you use the option dotlp. Considering only voice traffic for now, the switch will pass voice traffic through VLAN 3 with the COS value. (based on my understanding of IEEE, vlan classification decides it must remark vlan 0 with vlan 3)

Now when the

switchport priority extend trust

is added and PC is marking COS.

With the above option, IP phone passes the data frames without any remarking of COS fields.

PC generated data frames will the be same as voice frames. Both are priority tagged, hence VID is 0

The switch classifies both of them to be in VLAN 3 because switch cannot transmit priority tagged frames.

Now I guess you might ask me, voice frames are supposed to transmitted by switch as VID:0 and cos and PC frames with its cos and VID:3. No, based on my understanding of the paper, all traffic with dotlp will get remarked with VID:3 in the above case because switch simply cannot transmit priority tagged frames (VID:0).

The idea with dotlp is to use 1 vlan to transmit both voice and data. Voice is marked with COS and data is not marked with COS.

HTH

Lejoe

sarahr202 Sun, 01/25/2009 - 06:55

Hi Lejoe!

According to ieee paper, you sent, a switch can not transmit priority -tagged frames. Switch transmit such frames either using the vlan on the port which receive the such frames or as untagged frames.

My question is if switch send priority -tagged frames as untagged frames to uplink switch, how would the cos values be passed as you said earlier, untagged frames means no dot1q header?

Suppose we have sw1---sw2-----ip phone---pc

Sw2 is configured with:

switchport access vlan 3

switchport voice vlan dot1p

switchport priority extend trust

Let say sw2 receives a frame from its uplink sw1. This frame is destined to ip phone.How would switch transmit the frame to ip phone? with vlan id of port connected to ip phone? as priority-tagged frame?

how would sw2 tansmit the frame destined to pc? using port vlan or untagged?

thanks a lot!

lejoe.thomas Sun, 01/25/2009 - 15:07

Hi Sarah,

My question is if switch send priority -tagged frames as untagged frames to uplink switch, how would the cos values be passed as you said earlier, untagged frames means no dot1q header?

Well it can send it untagged or associate it with non null VID. In this case it will associate both voice and data with VID:3

Let say sw2 receives a frame from its uplink sw1. This frame is destined to ip phone.How would switch transmit the frame to ip phone? with vlan id of port connected to ip phone? as priority-tagged frame?

how would sw2 tansmit the frame destined to pc? using port vlan or untagged?

Since port is configured as access, the switch should send frames untagged (strip dotlq), once it determines based on QOS, which frame should go first. This would apply to both Phone and PC.

HTH

Lejoe

sarahr202 Sun, 01/25/2009 - 17:06

The port is not configured as access port but as multivlan access port.

Recall you sent me a link about that a while ago.

Dot1q header will be removed at destination switch which is in our case is three port switch in the ip phone.

"My question is if switch send priority -tagged frames as untagged frames to uplink switch, how would the cos values be passed as you said earlier, untagged frames means no dot1q header?

Well it can send it untagged or associate it with non null VID"

If switch is configured to send as untagged frame, how would the cos values be passed?

Thanks a lot!

Correct Answer
lejoe.thomas Sun, 01/25/2009 - 17:16

Hi Sarah,

A multivlan case occurs when using option

switch voice vlan x

With switchport voice vlan dotlp, a single vlan is used to carry both voice and data, in the above case vlan 3.

My question is if switch send priority -tagged frames as untagged frames to uplink switch, how would the cos values be passed as you said earlier, untagged frames means no dot1q header?

Switch is not sending priority tagged frames to the neigboring switch, it would remark the those priority frames with VID 3, making them vlan tagged frames carrying COS and VID.

If switch is configured to send as untagged frame, how would the cos values be passed?

I dont think it would send untagged frames, if it were sending untagged frames, then no COS information could be passed. COS is not carried beyond the next-hop.However, we must remember Layer 3 precedence is still retained.

HTH

Lejoe

Actions

This Discussion