configuring Voice VLAN

Unanswered Question
Jun 11th, 2007

We are about to install a new PBX that has VoIP capabilitites and I want to make sure I am heading down the proper path for my VLAN infrastructure to support these new capabilities. For this install we have a multiple building comples with a data VLAN for each building as well as a seperate VLAN for my server farm. If we convert all the digital phones to VoIP, we will have approximately 200 phones over the entire complex.

I know that I need to have the VOIP traffic on a different VLAN than my desktop traffic. It also looks like I use the switchport voice command instead of the switchport access command to configure the new vlan. Is there anything else I need on the switchport level? All other steps for configuring the voice VLAN is the same as configuring a reglar VLAN correct? With the phone beconnected between the wall and the PC, it "knows" the different VLANS?

In regards to how the PBX and VoIP interfaces reside on the network(i.e. CLAN card, etc.), should these interfaces be in the voice VLAN or is best practice to place them in my server VLAN?

I have my VLANs seperated into buildings and/or floors. Should the voice VLANS follow the same pattern or is best practice to have the voice VLAN cover everything?

I have started reading through the Cisco IP Telephony Planning, Design, Implementation, Operation and Optimization book from Cisco Press. I am also being sent a giude from Avaya in regards to setting up VoIP. Is there any other reference material recommended??

Brent Berry

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
rob.huffman Mon, 06/11/2007 - 07:33

Hi Brent,

Here is another reference (SRND);

I would follow the same separate VVLAN for buildings/Floors as the rest of your design. This way something effecting one VVLAN (like a broadcast storm) won't take down the whole voice network.

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

bberry Mon, 06/11/2007 - 12:40

Rob,

Thanks for the info. It sounds like I am on the right path which is a good thing. I found out this morning that a new system at one of our remote locations will be going in as VoIP tomorrow night.

I am planning to place the PBX interface cards into the server VLAN and will create new VLANs specifically for the IP phones. It also looks like I need TFTP running somewhere to get the phones up as well.

The switchport access vlan # should give me a native vlan for data or is there more that I need? It looks like I also need the switchport voice vlan # for the voice traffic.

All of my access switchs will be some flavor of 2950s or some flavor of 2960s. None have POE so we will have a power brick with each phone. By default I have PortFast enables on all the switch ports unless I know there is a specific port with another switch or hub attached.

I figure there will be a gatcha or two but that is part of the learning curve. It looks like I am going to have to forgoe the lab and work straight on production.

Once again thanks...

Actions

This Discussion