Optimum switchport configuration for IP Phones

[alfista16]

Hello community,

After quite some research, I have not concluded to which is the best practice in terms of configuring Cisco switchports to IP Phones. Two options:

Option #1:

Switch(config-if)#switchport mode access

Switch(config-if)#switchport access vlan 10

Switch(config-if)#switchport voice vlan 20

(leaving QoS out of the discussion for now)

Option #2:

Switch(config-if)#switchport mode trunk

Switch(config-if)#switchport native vlan 10

Switch(config-if)#switchport allowed vlan 10,20

What are the pros and cons of each implementation?

Most discussions conclude to the fact that they are practically the same.

And one more question, if I may.

The article below shows an implementation of Option#1:

https://mrncciew.com/2013/07/26/voip-phone-switchport-config/

It seems that the switch sends tagged traffic out the access port for voice vlan (which practically makes Option#1 a trunk port,as well)

Thing is that, surprisingly enough, as per the conclusion of the article, the switch also tags the traffic out that port for the access vlan as well! (vlan 140 in the example and screenshot in the article)

CCNA documentation says that traffic sent out access ports is always untagged. Can anyone please explain?

[Philip D'Ath]

The actual config will vary based on switch config.  Cisco have a macro called cisco-phone on every switch that applies config related to that switch model (including QoS config).

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-1SY/config_guide/sup2T/15_1_sy_swcg_2T/smart_port_macros.html#76174

Switch(config-if)#macro apply cisco-phone $AVID 10 $VVID 20

[alfista16]

Thank you for your prompt response Philip.

I suspect that the "cisco-phone" macro applies to Cisco IP Phones, or anyway to IP Phones from vendors ready to interoperate with Cisco switches. My question is more generic, however, and concerns any kind of IP Phones (say Polycom, Yealink, Avaya, ZTE, whatever)

If you could also check the link on my question, it shows a switch configured via Option #1 that sends tagged traffic out its access port (screenshots included in the link). Is this supposed to be the case indeed when we select Option #1?

[Philip D'Ath]

If it is a phone that supports the use of the "voice vlan", then make it an access port.

[mlund]

Hi

There is a similar discussion in this thread.

https://supportforums.cisco.com/t5/lan-switching-and-routing/native-vlan-tagging/m-p/3348414#/M408313

However, in option 1, the command "switchport voice vlan 20" is used to signal with cdp the information to the phone that it should use vlan 20 to send voice vlan and it should tagg this traffic. And also if a pc is connected to the back of the phone the phone deliver that traffic untagged. If the phone connected does not understand cdp, then this port will be a normal access-port sending all traffic untagged.

If there is a phone connected to the port that does not understand cdp, and you still want to use different vlans for voice and data, then opton 2 is what you use.

You are right, it can be confusing with an access-port that is sending tagged traffic, but this is what is happening if the cdp is negotiated correctly. I have heard people calling this port a minitrunk, because it is actually an 2 vlan enabled trunk.

/Mikael

[alfista16]

Hello Mikael,

Thank you very much for your detailed response and the link!

In the discussion (link) that you quoted, it is mentioned that the IP Phone can receive the VLAN via DHCP Options, instead of CDP.

In that case the following happens:

1. The IP Phone boots for the first time by sending a DHCP discover (untagged - IP phone is not yet VLAN-aware). This will apparently be sent to the access vlan of the switchport and received by the data network DHCP server.

2. The DHCP server responds and instructs the IP Phone to use a specific VLAN ID for its voice traffic. This is the same vlan that the switch uses in the "switchport voice vlan X" command. After the IP Phone receives the correct VLAN ID by the DHCP server, it then reboots

3. After the reboot, the IP phone now assigns the correct VLAN ID on its voice traffic. The PC connected behind the IP Phone, is still not VLAN-aware. It sends untagged traffic to the switch via the IP Phone.

So, my understanding from this point on is that the switch access port receives untagged traffic from the PC (access vlan) and tagged traffic from the IP Phone (voice vlan). My questions:

1. Can you please confirm?

2. Would this whole behavior change if we used CDP? As per my understanding, this is just another method to provision a VLAN to the IP Phone. It does not change the fact that switch ports send/receive tagged traffic in the voice vlan and untagged traffic in the access vlan.

3. Any other link discussin the above would be more than welcome.

Thanks again,

George

[mlund]

Hi

Glad it helped.

1.   Yes, You are correct

2.   Yes, You are correct here also.

/Mikael

[alfista16]

Thanks again for getting back Mikael.

If the above statements are correct, then I am afraid i will have to return to the first question:

Why does the switch tag traffic outgoing from the access vlan in the following article?

https://mrncciew.com/2013/07/26/voip-phone-switchport-config/

I know it needs some time to read, so if it helps I am talking about the "But you can see from switch to Phone still traffic will be tagged on vlan 140."section where the switch tags traffic with access vlan 140.

[Joseph W. Doherty]

Interesting! This implies the VoIP phone will strip the VLAN tag off the frame before it forwards the frame to the PC. The only reason I could see doing this, is to take "advantage" of the CoS.

Several years ago, we discovered some Cisco VoIP phone, could not handle 100 Mbps of PC traffic without delaying it. I wonder if this might have been happening.

[alfista16]

It is interesting indeed. But quite confusing at the same time, for a guy who is currently studying CCNA theory, where access ports are strictly supposed to send and receive untagged traffic only! :) (that's me)

Especially while at the same time Cisco officially declares in an older article that access vlan (native vlan for the article's scope) sends untagged traffic and only the voice vlan tags the traffic. See "Multi-VLAN Access Ports" here: http://www.ciscopress.com/articles/article.asp?p=1315434&seqNum=4:

"Data packets between the multiservice access switch and the PC or workstation are on the native VLAN. All packets going out on the native VLAN of an IEEE 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 are tagged by the IP phone based on the CDP information from the access switch."

[Joseph W. Doherty]

Yes, your later reference is what I would suspect.

The only way to know for sure, for your device, it get on the access port port and capture the frames.

[Joseph W. Doherty]

"If there is a phone connected to the port that does not understand cdp, and you still want to use different vlans for voice and data, then opton 2 is what you use."

You can still use option 1. I work in an environment that has thousands of VoIP phones, both Cisco and Brand X, the latter not using CDP. We configure the ports alike.

[mlund]

Hi Joseph

I have always used option 2, but it's good to know that option1 is also working for non cisco phones.

/Mikael

[alfista16 · Accepted solution]

Hello everyone.

Thank you all for your contribution. Let me please share some findings after capturing traces on a 3850 L3 switch port. It will be more interesting to start with the "legacy" Option#2, i.e. a trunk port with native vlan 10 and allowed vlans 10 and 20:

Option#2 (trunk ports)

- The switch sends CDP to the IP Phone, tagged with default vlan 1. This is not a typo, again vlan 1. You may confirm this on Cisco's official 3850 documentation, here: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/3se/vlan/configuration_guide/b_vlan_3se_3850_cg/b_vlan_3se_3850_cg_chapter_0110.html

"To reduce the risk of spanning-tree loops or storms, you can disable VLAN 1 on any individual VLAN trunk port by removing VLAN 1 from the allowed list. When you remove VLAN 1 from a trunk port, the interface continues to send and receive management traffic, for example, Cisco Discovery Protocol (CDP), Port Aggregation Protocol (PAgP), Link Aggregation Control Protocol (LACP), DTP, and VTP in VLAN 1."

With this config, I would not expect the IP Phones to learn their voice vlan via CDP, since they do not expect incoming tagged traffic on vlan 1.

- CDP includes various fields, among which a field "advertising" its Native VLAN 10. There is no field for the allowed vlan 20. Again, those CDP frames are tagged with VLAN=1, and thus should never actually reach the IP Phone, who is vlan-unaware when first connected to a switch port.

- The switch also sends STP messges, both tagged (for allowed vlan 20) and untagged (for native vlan 10)

Option#1 (access vlan / voice vlan, a.k.a Multi VLAN Access Port - MVAP, a.k.a "mini-trunk")

- The switch sends CDP frames untagged, as expected (we are having an access port here)

- CDP "advertises" its Native vlan 10 and its VoIP vlan 20. In this scenario, the IP phones (vlan - unaware as they are) could very well be provisioned via CDP, i.e. they could "learn" the voice vlan via CDP, assuming they support CDP of course.

- The switch also sends STP BPDUs, both untagged (for access vlan 10) and also tagged for voice vlan 20.

Some additional notes:

1. I have seen configs where people enter the "switchport access vlan 10" and "switchport voice vlan 20" commands on a trunk port (Option#1), i.e. a port that explicitly includes the "switchport mode trunk":

- The "switchport access vlan 10" command does not affect the trunk port anyhow.

- The "switchport voice vlan 20" command, if added on a trunk port, advertises via CDP the VoIP vlan 20. This would make sense if the CDP messages were actually received by the IP Phones. But again, when in trunk mode with native vlan=10, the CDP frames are generated by the switch tagged on default vlan=1.. Thus, they never reach the IP phone, so i am wondering why anyone would use the "switch voice vlan 20" command on a trunk port.

- As a conclusion, in order for the IP Phone to learn its voice vlan via CDP, the only approach is Option#1 - access mode with voice vlan

Hope this helps.

Please feel free to comment.

Regards,

George