Solved: ip phone on native vlan

sarahr202 · ‎12-28-2008

Hi every body!

My book says"The voice packets must be carried over a unique voice vlan known as the voice vlan id or vvid or over the regular data vlan known as native vlan or the port vlan id,pvid. the qos information from the voice packets also must be carried."

1) Is voice vlan or vlan 0 is created by default on all switches?

2)based on following from the above excerpt:

"or over the regular data vlan known as native vlan or the port vlan id,pvid. the qos information from the voice packets also must be carried."

1) Can we use other vlan say vlan 3 for voice packets? or as the book say voice vlan or native vlan only?

If we use native vlan for voice packets then cos information would be lost(assuming 802.1q). When switch receives the frame without cos value, it will assume cos=0 or switch change cos=0 value to some other value in accordance with configured policy on the switch. This will cause an overhead as switch has to do extra work compared to if voice packets were carried over regular vlan say vlan 0 , because switch's port would be configured to trust the cos values in frame from ip phone and thereby do not have to check against configured policy. Is my understanding correct?

thanks a lot!

lejoe.thomas · ‎12-28-2008

Hi,

True native vlan means, VID (VLAN ID) in the tag field is not set. But user priority bits in the tag field is set, where COS is marked. Hence why I said two parts in the tag field VID and priority bits. And the IP phone is doing this.

HTH

Lejoe

View solution in original post

Giuseppe Larosa · ‎12-28-2008

Hello Sarah,

starting from the following may help

SW-RM-SXR000-A-C-1(config-if)#switchport voice vlan ?

<1-4094> Vlan for voice traffic

dot1p Priority tagged on PVID

none Don't tell telephone about voice vlan

untagged Untagged on PVID

These are the possible options for voice vlan.

The best is to use a dedicated voice vlan with its own vlan-id an 802.1Q header with a non-zero vlan-id and 802.1p bits set to 5.

Then comes the dot1p option:

frames stay within the access vlan of the port as PC frames but an 802.1Q header is added the vlan-id is set to 0 to allow the switch to accept the frame, the 802.1p field has 5 value.

none : the switch doesn't tell anything about the voice vlan on CDP/LLDP messages out the port.

Note: for security reasons frames with arbitrary vlan-id in 802.1Q tags are discarded in modern switches (to avoid single vlan hopping attacks)

untagged: the switch says voicevlan = access vlan and instructs the phone to not use any form of tagging.

Clearly only the first two options can provide end-to-end QoS with the first to be preferred for different reasons: for example to avoid to have PCs and phones to compete for IP addresses on the same DHCP scope, for better security and so on

Hope to help

Giuseppe

View solution in original post

lejoe.thomas · ‎12-28-2008

Hi Sarah,

It's not that native vlan frames are not tagged.

eg:

PC1 - Vlan 20 connected to switch 1

PC2 - Vlan 20 connected to switch 2

On both switch 1 and 2 , native vlan on the trunk port connecting the switches are set to vlan 20.

If PC1 generates a frame to PC2 or vice versa, there is still dot1.q header associated with frame specifying the VLAN ID [20]. A simple capture of frames on the trunk port on either switch 1 or switch 2 will reveal this.

i.e Even frames in native vlan are tagged with native vlan ID. It's just that frames appearing untagged on a trunk port are put into the native vlan configured.

Getting back to IP phones, IP phones do generate [voice] frames with 802.1q header, thus being able to set priority bits.

**correction to my previous post, which said native vlan means VID is not set. Even when frames are destined for the native vlan, the VID is set to the native vlan configured. When they say native vlan frames are not tagged, they are referring to untagged frames appearing at a for instance trunk port and are tagged with native VLAN configured on the trunk port.

HTH

Lejoe

View solution in original post

Jon Marshall · ‎12-29-2008

Giuseppe

I learn something new every day :-)

So for my benefit to summarise

1) Use non-native vlan for voice. This will have 802.1q tag and so can carry Cos value.

2) The dot1p option - this is the one i wasn't aware of. A vlan tag is added but the vlan id is 0, kind of like a placeholder, just so the vlan tag can carry CoS markings.

3) No tag at all and therefore no CoS.

Sarah

Just to add to what has already been said. The native vlan by definition is untagged but you can change this by telling the switch to tag ALL vlans including the native vlan which would then allow the native vlan to carry CoS markings.

Jon

View solution in original post

lejoe.thomas · ‎12-29-2008

Hi Sarah,

If the switch port allows configuration the command switchport voice vlan dotlp, we know that it supports 802.1p standard.

HTH

Lejoe

View solution in original post

lejoe.thomas · ‎12-28-2008

Hi Sarah,

The IP Phones send traffic marked with Layer 3 precedence and Layer 2 CoS, both of which are set to 5.

There are two ways you can configure a switch port to carry to carry voice traffic.

1) Specifying the voice vlan

eg: switchport voice vlan 30

Here the switch is informing the IP phone using CDP to send voice traffic using 802.1q frames for the specified VLAN (30) or simply said tag voice frames with vlan 30. With this, the phone is also able to set COS as user priority bits. The phone listens to this and sends frames marked with layer 2 CoS 5 and layer 3 precendence 5. The frame coming from a PC attached to phone are untagged and we can specify the vlan to which it belongs. This voice vlan is manually created. So, you use your own voice vlan.

2) switchport voice vlan dotlp or what you refer to as using 802.1p priority tagged frames

Switch informs the phone to use 802.1p priority tagging on voice traffic and use default vlan 0 to carry all traffic. So I guess, vlan 0 exists by default. All documentations say vlan 0

**My thoughts it should be vlan 1 (default native vlan), but then that would mean I am claiming the cisco documentations are wrong.

--802.1p allows users to specify priorities of their traffic. This is 3 bit field in 802.1q header, where COS is marked.

--802.lq contains tag field, with a 3 bit priority field and 12 bit Vlan ID.

When they say default native vlan 0, It means frames are still using 802.lq header with priority bits set or COS marked for VLAN 0 (for voice traffic). This is how it is able to carry QoS for voice traffic.

The phone is always tagging voice traffic unless it is explicitly [COS set] asked to send to so[COS not set]

Let say even if this information is lost, as soon as packet experiences layer 3 forwarding, the old lan header is discarded, the Layer 3 precedence still exists for QOS.

HTH

Lejoe

sarahr202 · ‎12-28-2008

thanks Lejoe!

Let me quote part of your reply.

"When they say default native vlan 0, It means

frames are still using 802.lq header with priority bits set or COS marked for VLAN 0 (for voice traffic). This is how it is able to carry QoS for voice traffic."

I think 802.1q does not add header to native vlan's frame.

lejoe.thomas · ‎12-28-2008

Hi,

True native vlan means, VID (VLAN ID) in the tag field is not set. But user priority bits in the tag field is set, where COS is marked. Hence why I said two parts in the tag field VID and priority bits. And the IP phone is doing this.

HTH

Lejoe

sarahr202 · ‎12-28-2008

thanks Lejoe!

You were correct.

The 802.1q header has cos field but it was not used and defined. 802.1p standard defines the use of cos service.

How can we find if switch supports 802.1p besides 802.1q ?

I think for a switch to support ip phone, it must support the 802.1p not just 802.1q.

Am I correct?

thanks a lot!

sarahr202 · ‎12-28-2008

sorry to bother you Lejoe.

Let me quote from my cisco press book

"IEEE 802.1 Q

Each frame is tagged with a 12-bit vlan id and user field. The user field contains three 802.1p priority bits that indicate the frame cos,a unitless value rangng from 0 to 7.Frames from native vlan are not tagged ,so they receive a default cos that is configured on the receiving switch"

According to book, native vlan frame are not tagged so they dont have cos values or cos=0,they receive default cos on receiving switch.

But your post say though frames from native vlan are untagged but they carry cos value.

Could you please explain that?

thanks a lot!

Giuseppe Larosa · ‎12-28-2008

Hello Sarah,

starting from the following may help

SW-RM-SXR000-A-C-1(config-if)#switchport voice vlan ?

<1-4094> Vlan for voice traffic

dot1p Priority tagged on PVID

none Don't tell telephone about voice vlan

untagged Untagged on PVID

These are the possible options for voice vlan.

The best is to use a dedicated voice vlan with its own vlan-id an 802.1Q header with a non-zero vlan-id and 802.1p bits set to 5.

Then comes the dot1p option:

frames stay within the access vlan of the port as PC frames but an 802.1Q header is added the vlan-id is set to 0 to allow the switch to accept the frame, the 802.1p field has 5 value.

none : the switch doesn't tell anything about the voice vlan on CDP/LLDP messages out the port.

Note: for security reasons frames with arbitrary vlan-id in 802.1Q tags are discarded in modern switches (to avoid single vlan hopping attacks)

untagged: the switch says voicevlan = access vlan and instructs the phone to not use any form of tagging.

Clearly only the first two options can provide end-to-end QoS with the first to be preferred for different reasons: for example to avoid to have PCs and phones to compete for IP addresses on the same DHCP scope, for better security and so on

Hope to help

Giuseppe

Jon Marshall · ‎12-29-2008

Giuseppe

I learn something new every day :-)

So for my benefit to summarise

1) Use non-native vlan for voice. This will have 802.1q tag and so can carry Cos value.

2) The dot1p option - this is the one i wasn't aware of. A vlan tag is added but the vlan id is 0, kind of like a placeholder, just so the vlan tag can carry CoS markings.

3) No tag at all and therefore no CoS.

Sarah

Just to add to what has already been said. The native vlan by definition is untagged but you can change this by telling the switch to tag ALL vlans including the native vlan which would then allow the native vlan to carry CoS markings.

Jon

lejoe.thomas · ‎12-28-2008

Hi Sarah,

It's not that native vlan frames are not tagged.

eg:

PC1 - Vlan 20 connected to switch 1

PC2 - Vlan 20 connected to switch 2

On both switch 1 and 2 , native vlan on the trunk port connecting the switches are set to vlan 20.

If PC1 generates a frame to PC2 or vice versa, there is still dot1.q header associated with frame specifying the VLAN ID [20]. A simple capture of frames on the trunk port on either switch 1 or switch 2 will reveal this.

i.e Even frames in native vlan are tagged with native vlan ID. It's just that frames appearing untagged on a trunk port are put into the native vlan configured.

Getting back to IP phones, IP phones do generate [voice] frames with 802.1q header, thus being able to set priority bits.

**correction to my previous post, which said native vlan means VID is not set. Even when frames are destined for the native vlan, the VID is set to the native vlan configured. When they say native vlan frames are not tagged, they are referring to untagged frames appearing at a for instance trunk port and are tagged with native VLAN configured on the trunk port.

HTH

Lejoe

lejoe.thomas · ‎12-28-2008

Disregard previous post!

Lejoe

lejoe.thomas · ‎12-29-2008

disregard previous post!

Lejoe

sarahr202 · ‎12-29-2008

Lejoe help me understand your post.

Will native vlan on dot1q trunk get tagged or not?

My understanding was frames belonging to native vlan are not tagged. But you mentioned in your post that native vlan get tagged on 802.1q.

Thanks a lot and have good night!

lejoe.thomas · ‎12-29-2008

Hi Sarah,

We all know the frames belonging to native vlan are untagged. But like I mentioned in the post when I did the test and captured frames, I could see the frames were tagged (VID:20 set), even though traffic belonged to the native vlan over the trunk ports of both switches.

My conclusion was, as packets egress ports to which PC1 and PC2 are connectd, it is tagged with a VID (eg:20). Over the trunk, no stripping of the VID occured. And this why I said the untagged frames are put in the native vlan, but even frames in native vlan are tagged. I guess with 802.1q becoming a standard, there is probably no need to strip tags for the native vlan as well.

**Please still stick to the universal concept, native vlan frames are untagged and try this on your own to see the results. Plus, it always good to know what's actually happening.

HTH

Lejoe

sarahr202 · ‎12-30-2008

Thanks a lot Lejoe!

"My conclusion was, as packets egress ports to which PC1 and PC2 are connectd, it is tagged with a VID (eg:20). Over the trunk, no stripping of the VID occured"

Pc1 receives the frame without any dot1q header.

The vlan id which is part of 802.1q header, is removed at end of trunk on destination switch along with dot1q header.

Switch then forwards the frame to pc1 without any dot1q header.

Thanks a lot Lejoe for answering my questions.

lejoe.thomas · ‎12-29-2008

Hi Sarah,

If the switch port allows configuration the command switchport voice vlan dotlp, we know that it supports 802.1p standard.

HTH

Lejoe