Voice VLAN or regular VLAN?

[study_voip]

Hello,

We plan to deploy Cisco IPT in a new office, we have dedicated cables for IP phones, and no plan to connect PC behind the IP phone, and we have Cisco 3750 switches, my question is

for the switch port which connecting to the IP phone, do I need to configure as Voice VLAN or just regular data VLAN?

I am thinking to configure the ports as access port instead of trunk as well, what is your suggestion?

Thanks

[rchilcote]

It's a Cisco best practice to use a voice vlan, but from a pure technical perspective it should work fine. I would encourage you to at least use a dedicated voice vlan subnet and not mix data and voice subnets, though.

With all but the oldest switches (3524XL, 5500s, ETC) you don't need to configure the switch ports as trunks with the "switchport mode trunk" command. As long as you have the following commands the phones will work fine.

interface f0/3

switchport access vlan 160

switchport voice vlan 260

spanning-tree portfast

So, I think you should consider setting all of your ports up this way just for the fact that you can place either a phone or a data device on any port on the switch. The data device will automatically be placed in the access vlan and if a phone happens to be placed there, then with the help of CDP, it will dynamically create an 802.1Q trunk and use the voice vlan. This also gives you the future capability to use a single cable solution if you wish without any reconfig.

Also, layer 2 QoS will only work over a trunk. If you set up the ports as standard access ports, then you will need to configure them to trust DSCP values from the phones. This gives the possibility of a smart user connecting to one of these ports with a PC and setting all of his traffic to use say DSCP EF. In that scenario your switch would trust that traffic from the PC and possibly cause qos issues with the rest of your phones. Not very likely, but a possibility. If you set up your switch ports to trust COS, then you don't have that problem.

Hope this helped.

[Chris Deren]

Absolutely use Voice VLAN, for QoS and Security reasons.

Chris

[Rob Huffman]

Hi Guy,

Just thought I would add this reference doc to the great info you have received from Robert and Chris;

When you deploy voice, Cisco recommends that you enable two VLANs at the access layer: a native VLAN for data traffic and a voice VLAN under Cisco IOS or Auxiliary VLAN under CatOS for voice traffic.

Separate voice and data VLANs are recommended for the following reasons:

Address space conservation and voice device protection from external networks

Private addressing of phones on the voice or auxiliary VLAN ensures address conservation and ensures that phones are not accessible directly via public networks. PCs and servers are typically addressed with publicly routed subnet addresses; however, voice endpoints should be addressed using RFC 1918 private subnet addresses.

QoS trust boundary extension to voice devices

QoS trust boundaries can be extended to voice devices without extending these trust boundaries and, in turn, QoS features to PCs and other data devices.

Protection from malicious network attacks

VLAN access control, 802.1Q, and 802.1p tagging can provide protection for voice devices from malicious internal and external network attacks such as worms, denial of service (DoS) attacks, and attempts by data devices to gain access to priority queues via packet tagging.

Ease of management and configuration

Separate VLANs for voice and data devices at the access layer provide ease of management and simplified QoS configuration.

To provide high-quality voice and to take advantage of the full voice feature set, access layer switches should provide support for:

802.1Q trunking and 802.1p for proper treatment of Layer 2 CoS packet marking on ports with phones connected

Multiple egress queues to provide priority queuing of RTP voice packet streams

The ability to classify or reclassify traffic and establish a network trust boundary

Inline power capability (Although inline power capability is not mandatory, it is highly recommended for the access layer switches.)

Layer 3 awareness and the ability to implement QoS access control lists (These features are required if you are using certain IP telephony endpoints, such as a PC running a softphone application, that cannot benefit from an extended trust boundary.)

Spanning Tree Protocol (STP)

To minimize convergence times and maximize fault tolerance at Layer 2, enable the following STP features:

PortFast

Enable PortFast on all access ports. The phones, PCs, or servers connected to these ports do not forward bridge protocol data units (BPDUs) that could affect STP operation. PortFast ensures that the phone or PC, when connected to the port, is able to begin receiving and transmitting traffic immediately without having to wait for STP to converge.

From this CCM SRND doc;

Cisco Unified Communications SRND Based on Cisco Unified CallManager 4.x

Network Infrastructure

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guide_chapter09186a00806e8c42.html

Hope this helps and best of luck with your rollout!

Rob

[study_voip]

Thanks for all your guys' input.

I am going to disable all the IP phone PC port, so it is impossible to have data traffic in the "voiced" VLAN.

I planned to setup regular data vlan for voice traffic, and all ports connecting IP phones will be setup as "Access" instead of "trunk".

to do this, the challenge part is from Qos, and access port will have no sense about the Cos value, therefore, I need to do more configuration on the switch to "override" the Cos/DSCP value from the real data port, and map some DSCP value (EF) to the traffic for voice.

at switch uplink port (trunk), I need to classify those traffic and put the traffic to different queue.

thanks again for your input

[paolo bevilacqua]

Hi,

Just want to add one small practical point to address your concern about QoS. In LAN designs, at 100 / 1000 speeds, QoS for voice is very rarely a real concern. That is, in order to have quality issues, things should go so wrong, that not only the voice would suffer.

You can configure all the queues you want, but they are destined to stay empty all the time :)