I’ll admit it. The voice VLAN confuses the hell out of me. In our production network we assign an access VLAN and a separate voice VLAN to each user switchport:
int f0/1
switchport access vlan 100
switchport voice vlan 200
My understanding is that this is a trunk. We’re trunking VLANs 100 and 200 to the IP phone. But if you do a ‘show interfaces trunk’ command, the ports configured for a voice and data VLAN do not show up as trunks. And if we look at the switchport setting for the port, we can also verify that it is not trunking(output is from a 3640 with a NM-16ESW module emulated via Dynamips):
sw1(config-if)#do sh int f0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Disabled
Access Mode VLAN: 100 (VLAN0100)
Trunking Native Mode VLAN: 1 (default)
Trunking VLANs Enabled: ALL
Trunking VLANs Active: 100
Priority for untagged frames: 0
Override vlan tag priority: FALSE
Voice VLAN: 200
Appliance trust: none
The 3560 configuration guide even goes so far as to warn you:
Note Voice VLAN is only supported on access ports and not on trunk ports, even though the configuration is allowed.
Also, I’ve been told “No silly little man, those aren’t trunk links.” Okay. Then how the hell are we passing two separate VLANs between the IP phone and the switchport?
This dilemma was recently raised on GroupStudy:
Dear groups,
If we said switchport voice vlan under the interface, it’s mean the port become a trunk ?
When we have switchport access vlan also, which one is tag with vlan header after exiting the port ? Voice vlan or data vlan ?
The official Cisco stance is that this is not a trunk:
Cisco calls this a Multi-Vlan access port, and NOT a trunk port. if it were a trunk port, according to Cisco, it would flood all vlans configured on the switch out to the phone. As you probably know already, a port configured for voice Vlan does not flood out all Vlans to the phone, just the voice vlan frames (tagged) and the data frames ( untagged ).
Multiservice switches supports a new parameter for IP Telephony support that makes the access port a multi-VLAN access port. The new parameter is called an auxiliary VLAN. Every Ethernet 10/100/1000 port in the switch is associated with two VLANs
– A Native VLAN for data service that is identified by the port VLAN identifier or PVID
– An Auxiliary VLAN for voice service that is identified by the voice VLAN identified or VVID.
– During the initial CDP exchange with the access switch, the IP phone is configured with a VVID.
– The IP phone also supplied with a QoS configuration using Cisco Discovery Protocol. Voice traffic is separated from data, and supports a different trust boundary.
Data packets between the multiservice access switch and the PC or workstation will be on the native VLAN. All packets going out on the native VLAN of a 802.1q port are sent untagged by the access switch. The PC or workstation connected to the IP phone usually sends untagged packets.
Voice packets will be tagged by the IP phone based on the Cisco Discovery Protocol information from the access switch.
*The multi-VLAN access ports are not trunk ports, even though the hardware is set to dot1q trunk*. The hardware setting is used to carry more than two VLANs, but the port is still considered an access port that is able to carry one native VLAN and the Auxiliary VLAN. The ‘switchport host’ command can be applied to a multi-VLAN access port on the access switch.
If I understand this correctly, although the switchport is configured to use two different VLANs, only the voice VLAN traffic is actually tagged by the IP Phone. The data VLAN is sent untagged (making use of the native VLAN dot1q feature). This STILL sounds like trunking to me though. 🙂 This gives me high school Physics flashbacks about photons (“Is it a wave or a particle?” “It’s both…and neither.” <head explodes>). Scott Morris agrees:
That’s a fancy name for a small trunk. I agree. If you have tagged frames, it’s a trunk.
If it has two wheels and pedals, it’s a bicycle. They have some weird looking ones these days, but they’re still bicycles. Call it a multi-unicycled transportation device if you want, but it’s still a bicycle.
Would you see anything different if you turned off CDP, set the port as a trunk port, used the trunk allowed vlan command to only allow the access/voice vlans, set the native vlan to equal the data vlan and went down that path?
Scott Morris, CCIE4 #4713, JNCIE-M #153, JNCIS-ER, CISSP, et al.
CCSI/JNCI-M/JNCI-ER
Senior CCIE Instructor
So I guess that I’ll just have to accept the whole trunk/non-trunk duality when it comes to the voice VLAN.
CCIE Pursuit Blog 
Wow, what a coincidence. I was just pondering this exact issue regarding the “Mini-trunk”. Thank you for this post !!! It is quite clear now.
Comment by DY — January 1, 2009 @ 8:38 pm |
Nice explanation…although we know this but always confuse when need explanation…you made it quite clear..thx Scott.
Comment by yagnesh — January 3, 2009 @ 7:31 am |
On a somewhat related topic, I’ve been looking around trying to find out how to connect an Alcatel IP phone (which will have a PC daisy-chained) to a Cisco switch port (3750). There is a ton of reference to Cisco Voice port configs (including QoS/CDP/Auto-QoS) and things of that nature but nothing from my searches that show what the Cisco port config should be for non-Cisco IP phones to a Cisco switch (with QoS as well).
Any assistance would be greatly appreciated!
Comment by J R — January 3, 2009 @ 11:40 pm |
Thanks a lot for the explanation. This one’s always created a lot of confusion until now.
Comment by Lejoe — January 4, 2009 @ 12:20 am |
Hi,
How you have configured Non-Cisco IP Phones. Since CDP does not support non-cisco devices, how you made it to work
Comment by RBK — May 30, 2009 @ 12:40 pm |
mmm, i humbly disagree. i can see where a cisco purist might call this a trunk. (course, in the world outside of cisco, everybody else calls it a “tagged port” as in 802.1q tag; what everyone else calls a trunk is what Cisco calls an etherchannel. but, back to ciscospeak…)
i agree, it is true that if CDP is turned off on the switchport, the phone can still put traffic in the VVLAN by using a trunk config (in IOS). this was actually “the way” to do it when the stuff first came out:
switchport trunk encapsulation dot1q ! enable .1q tagging
switchport mode trunk ! tag frames with .1q tags
switchport trunk native vlan DVLAN ! untagged frames are in DVLAN
switchport access vlan VVLAN ! tagged frames are in VVLAN
–> Note to J R: i have used this for an Avaya IP phone with a 3750; this probably would work with your Alcatel <–
if you look at the CatOS syntax, though, you’ll note that the syntax is indeed “auxvlan,” not “voicevlan”. It’s still an auxillary vlan on the IOS machines; IOS just has a user-friendlier name.
i’d submit that the port is not a trunk, because although it sends “tagged” (.1q tags) frames, it sends tagged frams to ONLY the telephone – but **only if** the switchport knows about the telephone via CDP. The switchport doesn’t have the option to carry ISL wrappers, or negotiate DTP. (or, it shouldn’t negotiate DTP)
now, of course, 802.1p isn’t supposed to exist on anything but a trunk link. but since that’s counter to my argument, i’m going to ignore that little tidbit for now. 😛
anyhow, to see how CDP plays into things, you can try this little experiment:
if you let a phone pull an IP in the VVLAN, then remove CDP from the switchport where the phone is attached, the phone will be unable to communicate in the VVLAN (net result, you won’t get dialtone on the phone). it’ll need to pull a new IP (and re-register) in the DVLAN
further on, hook up an IP phone to a switchport on “Switch A”, then hook up “Switch B” behind that ip phone (it’ll work, trust me. i have some interesting customers). now, on “Switch B” behind the phone, configure different DVLAN’s on access ports. configure the uplink to the IP phone as a trunk. the computers behind that switch will be unable to communicate to the switch on the far side of the phone. This of course is expected, because “Switch B” is connected to the access port of the IP phone. Makes sense, knowing all that we know about layer2.
But, the same thing happens if you remove the IP phone from the toplogy, disable DTP on both switches, and configure “switch B” as a trunk port. (if you leave DTP enabled, then it will negotiate to be a trunk port). this is because “switch B” is trunking, but “switch A” is not.
When “Switch A” receives the CDP advertisement from the IP phone, it knows that anything to do with that device’s MAC Address belongs in the VVLAN (Aux-VLAN). Frames coming from MAC Addresses NOT advertised as an IP Phone by CDP should go into the DVLAN (Access VLAN).
*If CDP is disabled on the switchport, then the IP phone falls into the DVLAN; no tagging takes place* e.g. no-CDP = no-“trunk”
CDP is the magic that makes the access port APPEAR like a mini-trunk port. The switch tags the frames for the phone, but only if the phone tells the switch via CDP that it’s a phone. CDP does more than some people realize. It’s not just for mapping out networks (as an aside, cisco IP phones will also pass through 802.1x authentication as long as CDPv2 is enabled).
so, my vote: nope, not a trunk link. it’s the magic tagged-frame-bunny being pulled out of the cdp-magic-hat =)
Comment by bryce — January 6, 2009 @ 12:16 am |
“further on, hook up an IP phone to a switchport on “Switch A”, then hook up “Switch B” behind that ip phone (it’ll work, trust me. i have some interesting customers).”
I stared at this sentence for about 5 seconds, picturing the config in my head, then busted out laughing. Thanks for that, and for sharing the results of your experimentation.
Comment by Sergio — October 22, 2009 @ 9:57 am |
As a note… If ever dealing with Avaya VoIP on a Cisco network, you can still use this. It doesn’t just apply to cisco phones… As far as I can tell it applies to any taggable device that supports untagged and a single tagged frame. I work with both and life got a lot easier when i found out you could make an Avaya phone work without putting the port in trunk mode.. and it is a lot cleaner in the config.
Comment by Thomas — January 7, 2009 @ 11:14 pm |
It seems that bryce is drawing the trunk/notrunk line based on whether the Cisco-specific features (VTP and DTP) are playing a role in the behavior of the port.
It’s a challenge for me, because like Scott Morris, I’ve always thought that the presence of tagged frames == trunk. …But I’m adjusting my thinking, because bryce’s language seems more accurate.
bryce seems to be saying that “Trunk” is a Cisco-speak for “tagging + magic”
The magic includes distribution of the VLAN database, dynamic configuration of the ports, and so forth.
I think we can all agree that the access ports with Cisco phones in this discussion are running 802.1Q tags.
Are we in agreement so far?
I hope so, because I’m still a little fuzzy on some operational details.
Reading between the lines based on various descriptions, and my own observation, it seems that both the phone and the switch are learning something from CDP:
The phone is learning which VLAN tag should contain its packets (and conversely, which tag it should use for voice transmissions).
The switch is learning that a phone is present, and responds by tagging the voice traffic.
I’m typing this post on a PC cabled to an Avaya phone. The switchport is configured with the usual ‘switchport access vlan’ and ‘switchport voice vlan’ commands. Data and voice are both working.
The switch does NOT see any CDP neighbors on the port (Avaya phone).
There’s a suprise here: when I fire up wireshark on this PC, I see UNtagged traffic from both VLANs (arp broadcasts, HSRP hellos, etc…)
As far as I can tell, nothing has told the Avaya phone which tag is relevant, and nothing has told the switch that a phone is plugged in.
I THINK that the switch, having been configured for a voice VLAN on this port, but not detecting a CDP-configurable Cisco phone, is merging both VLANs UNtagged on this access port.
Am I interpreting things correctly?
I suppose it’s possible that things on the switch end of the phone look different than they do on the PC end (which is all I can see).
Comment by chris — February 3, 2009 @ 11:37 am |
I want to know whether data traffic from SW to IPPhone is tagged? I read CCNA Curriculum “Data destined for PC5 coming from port F0/18 is tagged with VLAN 20 on the way to the phone, which strips the VLAN tag before the data is forwarded to PC5”.
Comment by Trinh Thanh Su — February 25, 2009 @ 10:31 pm |
– Does you Avaya Phone have an IP from the Data Vlan(a)?
a If Yes(a) – then your only using the Data network.
a If No(a) – Then Did you have to hard code the IP into the Avaya phone(b)?
– If yes(b) – then traffic is probably being transmitted on both Vlans (and dropped at the L3 with the wrong subnet).
– If no(b) – Magic?
Comment by Huh? — May 20, 2009 @ 4:16 pm |
Thats a good amount of confusing posts, so let’s set the record straight:
1) Switchport voice vlan has a two-fold function: provisioning of the vvid by CDP, and trunking of the voice vlan as part of a multi-vlan access port.
2) In access mode, the result is that you end up with an undocumented dot1q trunk, that for all intents and purposes appears as an access port (in commands output such as “show int fa 0/1 switchport”), or as Cisco refers to, a multi-vlan access port. Now as far as I recall, this special dot1q trunk required DTP to be enabled on the interface (the default), i.e. no taken out with “swi noneg”. There is conflicting info in the literature on that, so proper experimentation would yield and answer.
3) In trunk mode, all you are using is the CDP provisioning aspect of the command, as your port is already a trunk and will trunk whatever VLANs are allowed.
4) In a port that is set to trunk mode, any access mode command is quite simply ignored. The reverse also holds true.
A previous poster confused everyone with this:
switchport trunk encapsulation dot1q ! enable .1q tagging
switchport mode trunk ! tag frames with .1q tags
switchport trunk native vlan DVLAN ! untagged frames are in DVLAN
switchport access vlan VVLAN ! tagged frames are in VVLAN
The above config would have worked without the “switchport access vlan” command, which is absolutely not responsible for the tagging of voice vlan traffic. The port being in trunk mode is the reason why the voice traffic was flowing through, as it what quite simply dot1q tagged and flew in through whatever vlans were allowed (in the above, the default is to allow trunking of all vlans).
Phones from various manufacturers can have their VLANs provisioned by DHCP, LLDP, CDP or other proprietary mechanisms. Cisco’s prefered way is by CDP, but they will support DHCP provisioning too, and I’m sure LLDP support will creep in soon as Cisco moves to LLDP. Mitel phones will behave like Cisco phone, in that Mitel uses CDP (switchport voice vlan X), LLDP and then DHCP to obtain its voice vlan.
I’ve had success with any of the below configs:
** Dynamic port **
switchport access vlan 1
switchport voice vlan 2
** Access port **
switchport mode access
switchport access vlan 1
switchport voice vlan 2
** Trunk port **
switchport mode trunk
switchport trunk native vlan 1
switchport voice vlan 2
switchport trunk allowed vlan 1,2
Of all the above, the simpler and safer way is the “access port” config, where you dont have to mind the trunk security, and yet the port is statically set as an access port, and wont trunk anything else than the voice vlan.
Comment by Mat — August 4, 2009 @ 3:04 am |
Alot of talk here about CDP, which is all well and good, but what it the IP Phone is a non Cisco phone?
I believe the best config is;
switchport mode access
switchport access vlan 50
switchport voice vlan 100
This way the Voice and Data VLANs are hard coded. No CDP necessary so this works with non cisco phones.
Comment by Luca — October 6, 2009 @ 5:45 pm |
By the way, when you apply this settings for voice vlan, why does the native vlan remain “Vlan 1”, and not set to “vlan 100”, as your data vlan is? (refering to your sw1(config-if)#do sh int f0/1 switchport command output)
Thanks for clarification!
Gilles
Comment by Gilles — October 10, 2009 @ 2:07 pm |
I left comment #7 a couple of years ago, and still believe I was on the right track with “trunk” in Cisco-speak = 802.1Q tagging + magic. Working with that definition, a multi-vlan access port is not a trunk.
I’m posting now to clarify my wireshark experience. I saw UN-tagged frames on both VLANs because my silly windows PC configured its NIC to throw tags away. The traffic probably was tagged, but I couldn’t see it.
Comment by chris — July 20, 2011 @ 9:37 am |