Voice VLAN and Data VLAN on the same port?

Im studying for CCENT and I was under the impression that you could only configure a port as an access port to a single VLAN or be a trunk port.
So Im poking around production switches at work and I noticed this

interface GigabitEthernet0/1
 switchport access vlan 10
 switchport mode access
 switchport voice vlan 2

Also under show vlan many of the ports are set to both vlan 10 and vlan 2.

Are voice vlans somehow different? Do these ports act as trunks for both vlans and just follow some other protocol than 802.1q?

Im guessing this is just out of the scope of the CCENT which is why I havent heard of it.

Find more posts tagged with

Comments

RouteMyPacket

You are right, a port can only be assigned one "access" vlan. The "voice" vlan is different and so this is why you see the configuration

No they are not trunks. Not sure if it's out of scope but you need to know it regardless. You will find yourself adding a port to a particular data vlan or voice vlan so you will need to know how to perform that action

AwesomeGarrett

Well, its kind of a trunk. When applying the command switchport voice vlan (vlan-id) it creates a "speacial" type of trunk according to Cisco. It does not explicitly make it a trunk (and for CCENT purposes it is not a trunk) but that is how it essentially works.

If have also seen the following:

switchport mode trunk
switchport trunk native vlan 100
switchport trunk allowed vlan 150

This was on a CE300, didn't look up the information on it but I assume it does not support the voice vlan command. From what I could tell it accomplished the same thing by having the data VLAN be the native vlan and the voice vlan allowed over the trunk.

olaHalo

Thanks for the quick replies guys!
So are items are the Voice VLAN tagged in anyway?

AwesomeGarrett

Traffic across both VLAN's will be tagged with with their respective 802.1q tag.

olaHalo

AwesomeGarrett wrote: »

Traffic across both VLAN's will be tagged with with their respective 802.1q tag.

Frames are tagged on Access ports? I thought they were only tagged on Trunks.
So if I have a situation like the original post, the frames are being tagged?

interface GigabitEthernet0/1  
switchport access vlan 10  
switchport mode access  
switchport voice vlan 2

I'm trying to understand how the devices know where to send the data when I have a phone and regular a host on one access port.
Sorry for all the questions. This is all fairly new to me. And thanks for the responses.

jdballinger

The frame will be tagged on an access port according to what VLAN the port is a part of. In the case of the original post, the vlan it is tagged as will be dependent on the type of packet being sent, whether it is voice or not. Trunks don't tag traffic (unless it is untagged, in which case it gets the native VLAN tag), instead trunks carry multiple VLANs.

Make sense? And no worries about asking questions, we're all here to help!

AwesomeGarrett

olaHalo wrote: »

Frames are tagged on Access ports? I thought they were only tagged on Trunks.

They have to be tagged in order to set the class of service bits for QoS. A regular Ethernet frame does not have anywhere to set QoS.

olaHalo wrote: »

I'm trying to understand how the devices know where to send the data when I have a phone and regular a host on one access port.Sorry for all the questions. This is all fairly new to me. And thanks for the responses.

The phone knows which VLAN the voice VLAN is either by CDP if it's a Cisco phone or by statically configuring it on the phone and the packets generated by the phone go directly to the voice VLAN. Packet received by the phone from the PC go to the access VLAN.

olaHalo

AwesomeGarrett wrote: »

They have to be tagged in order to set the class of service bits for QoS. A regular Ethernet frame does not have anywhere to set QoS.

The phone knows which VLAN the voice VLAN is either by CDP if it's a Cisco phone or by statically configuring it on the phone and the packets generated by the phone go directly to the voice VLAN. Packet received by the phone from the PC go to the access VLAN.

Thanks AwesomeGarrett
Looks like I need to setup a lab to better visualize how the traffic is moving.

jdballinger wrote: »

The frame will be tagged on an access port according to what VLAN the port is a part of. In the case of the original post, the vlan it is tagged as will be dependent on the type of packet being sent, whether it is voice or not. Trunks don't tag traffic (unless it is untagged, in which case it gets the native VLAN tag), instead trunks carry multiple VLANs.

Make sense? And no worries about asking questions, we're all here to help!

I think I am getting the picture now.
I thought that the frame was only tagged before it is sent over a trunk.

cisco_trooper

This interface will have a phone attached to it. As a previous poster stated it IS sort of a trunk, but it is being handled by the phone. For your purposes and probably for your exam you will not consider it a trunk, and in the field it is not generally referred to as a trunk, but it is in fact a trunk to the phone which is acting as a switch and forwarding the traffic on the data domain on to the workstation attached to the phone.

Winzer

jdballinger wrote: »

The frame will be tagged on an access port according to what VLAN the port is a part of. In the case of the original post, the vlan it is tagged as will be dependent on the type of packet being sent, whether it is voice or not. Trunks don't tag traffic (unless it is untagged, in which case it gets the native VLAN tag), instead trunks carry multiple VLANs.

You actually have it all backwards.

Frames are NOT tagged when going through an access port precisely because there is only one VLAN carried through the port.
Frames going trough a trunk are ALWAYS tagged; otherwise there is no way for the device on the other end to know which VLAN the frame belongs to, since the trunk carries multiple VLANs.

The only exception is the native VLAN, which is untagged traffic going through a trunk.

This is how you have a VoIP phone and a computer plugged into a single port.
The native VLAN is used by the computer (usually plugged into the phone), the tagged VLAN is used by the phone (and the phone is configured to tag all its traffic for that VLAN).

instant000

I was going to say what cisco_trooper said.

Dieg0M

There seems to be a lot of confusion here. Remember this:
-Access ports associated with the "access vlan" command send untagged traffic
-Trunk ports send tagged AND untagged traffic. Untagged traffic for trunk ports are associated with the "native VLAN" command.
The voice vlan is not supported on trunk ports because both voice vlan and access vlan are untagged traffic. Instead we refer to a port that supports the voice feature as a multi VLAN access port. So how does 2 set of untagged traffic coexist on a port? Well, the voice vlan command is not exactly "untagged" traffic, it introduces a new type of VLAN; the auxiliary VLAN. Instead of tagging a VLAN using 802.1q or ISL, the switch will use CDP to send the auxiliary VLAN ID.

AwesomeGarrett

Dieg0M wrote: »

There seems to be a lot of confusion here. Remember this:
-Access ports associated with the "access vlan" command send untagged traffic
-Trunk ports send tagged AND untagged traffic. Untagged traffic for trunk ports are associated with the "native VLAN" command.
The voice vlan is not supported on trunk ports because both voice vlan and access vlan are untagged traffic. Instead we refer to a port that supports the voice feature as a multi VLAN access port. So how does 2 set of untagged traffic coexist on a port? Well, the voice vlan command is not exactly "untagged" traffic, it introduces a new type of VLAN; the auxiliary VLAN. Instead of tagging a VLAN using 802.1q or ISL, the switch will use CDP to send the auxiliary VLAN ID.

How would the phone extend the QoS trust to the incoming frames from the PC without it being tagged?

Dieg0M

CDP is used to communicate information such as auxiliary VLAN ID, per-port power management details, and QoSconfiguration.

olaHalo

Dieg0M wrote: »

There seems to be a lot of confusion here. Remember this:
-Access ports associated with the "access vlan" command send untagged traffic
-Trunk ports send tagged AND untagged traffic. Untagged traffic for trunk ports are associated with the "native VLAN" command.
The voice vlan is not supported on trunk ports because both voice vlan and access vlan are untagged traffic. Instead we refer to a port that supports the voice feature as a multi VLAN access port. So how does 2 set of untagged traffic coexist on a port? Well, the voice vlan command is not exactly "untagged" traffic, it introduces a new type of VLAN; the auxiliary VLAN. Instead of tagging a VLAN using 802.1q or ISL, the switch will use CDP to send the auxiliary VLAN ID.

Thank you very much. That seems to have cleared it up.

powmia

Dieg0M wrote: »

There seems to be a lot of confusion here. Remember this:
-Access ports associated with the "access vlan" command send untagged traffic
-Trunk ports send tagged AND untagged traffic. Untagged traffic for trunk ports are associated with the "native VLAN" command.
The voice vlan is not supported on trunk ports because both voice vlan and access vlan are untagged traffic. Instead we refer to a port that supports the voice feature as a multi VLAN access port. So how does 2 set of untagged traffic coexist on a port? Well, the voice vlan command is not exactly "untagged" traffic, it introduces a new type of VLAN; the auxiliary VLAN. Instead of tagging a VLAN using 802.1q or ISL, the switch will use CDP to send the auxiliary VLAN ID.

This is completely inaccurate.

Auxilary VLAN is just a term used in some documentation. It's still just a 802.1q VLAN.

The voice vlan is tagged with an 802.1q VLAN tag.

CDP is used for nothing more than to have the phone gather information about which tag to use.

The DSCP markings to use for QoS are assigned by CUCM once a phone is on the voice vlan and receives its TFTP info.

The QoS is carried in an 802.1p field... which means that there HAS to be an 802.1q tag. If you don't assign a voice vlan to the interface, it will just be a tag with a value of the native vlan (access vlan).

If you want proof:

First set a port up in the traditional manner:

(data -> vlan 10 : voice -> vlan 20)

int g0/1
sw mo acc
sw acc vlan 10
sw voice vlan 20
!

Then, manually configure the vlan on the phone to use vlan 20 and set the port up as such:

int g0/2
sw trunk encap dot
sw mode trunk
sw trunk native vlan 10
sw tru all vlan 10,20
!

They will function the same. An access port with the voice vlan command is just a trunk that is setup in a convenient manner that prunes the trunk to two vlans (one native, one tagged) and tells CDP to send the voice vlan in it's updates as opposed to the native vlan that would normally be sent in CDP.

More proof?

Take two switches and connect them together. VTP mode transparent, turn off DTP ("switchport nonegotiate" on the ports between them). Configure one switch with the g0/1 config above, and the other switch with the g0/2 config above... look... an 802.1q trunk. Everything will function as normal.

fredrikjj

I've never understood why there are these arbitrary rules and switchport commands when it comes to vlans on access ports. The maximum of 1 "untagged" vlan is obvious, but beyond that, why do I need a special "voice vlan" command when it's just a dot1q tag.

interface GigabitEthernet0/1
switchport access vlan 10
switchport mode access
switchport voice vlan 2

This makes a lot more sense:
switchport vlan 10
switchport vlan 2 dot1q

What if I want to create a dot1q "access port" to a server. Two commands at least "switchport mode trunk" to even allow dot1q and then "switchport trunk allowed X".

Explain this reasoning behind this complicated syntax to me.

networker050184

Yep, what powmia said is correct. You are creating a trunk with regular old VLAN tags when you use a voice VLAN. Cisco just makes it a bit confusing with the voice and access VLAN configuration you use to accomplish it.

Magic Johnson

So there is no difference as long as config'd properly between access+voice and standard trunk? Is there a reason why access+voice is preferred?

Legacy User

The benefit of having the port set as an access and voice port is that you can connect your computer to your ip phone and just have one cable running from the ip phone to the switch instead of having 2 cables (1 for computer, 1 for phone) running to the switch.

Specifying a port as a voice vlan just lets the switch know there is voice traffic and data on the same line and sends it off voice traffic to the correct vlan.

powmia

Magic Johnson wrote: »

So there is no difference as long as config'd properly between access+voice and standard trunk? Is there a reason why access+voice is preferred?

The benefit is so that the switch sends the vlan ID of the voice vlan in CDP messages when it is configured with a voice vlan.

Magic Johnson

Ah right get it, so you'd have to do a hell of a lot more configuration to get it to work if configured as a trunk port whereas access + voice is much easier.

Your example was very interesting though powmia!

I work in a MITEL and HP environment (for switches at least) and their 'tagging' and 'untagging' is just a bit different!

Winzer

Correct me if I'm wrong, but I thought assigning a voice vlan also automatically applied QoS so that voice gets priority over the native vlan.