VoIP traffic has strict requirements concerning delay and jitter (variance in packet delay). To meet the requirements for IP telephony, the Cisco AVVID IP telephony solution uses a range of IP QoS features, such as classification, queuing, congestion detection, traffic shaping, and compression. Figure 13-2 illustrates the differences between VoIP traffic and data traffic.

Figure 13-2. Differences in IP Flow Behavior Between Data and Voice Traffic

The overall goal of QoS in the network is to minimize packet loss, delay, and jitter. A network that experiences congestion also experiences these problems. QoS configurations give critical applications a higher priority for service such that the critical applications experience less service degradation during times of congestion. In many networks, IP telephony is the most critical application. However, in many large enterprise networks, other applications are equally critical, such as financial transaction processing, stock tickers, and so on.

Applying classification, marking, traffic conditioning, congestion avoidance, and congestion management, as discussed in Chapter 10, allows you to design a network that is capable of supporting IP telephony with other critical applications. The next section discusses another useful tool in deploying IP telephony with Cisco IP Phones: voice VLANs.

Cisco IP Phones have an additional port for a PC connection; as a result, many Cisco IP Phone installations daisy-chain a PC to the Cisco IP Phone. Because both the Cisco IP Phone and the workstation reside on the same interface, configuring the respective Catalyst switch interface for a specific VLAN results in both the Cisco IP Phone and workstation residing in the same VLAN. Figure 13-3 illustrates the Cisco IP Phone and workstation topology.

Figure 13-3. Cisco IP Phone Daisy-Chain Topology

Cisco Catalyst switches support a unique feature, referred to as voice VLANs in Cisco IOS, that places the Cisco IP Phone and workstation in separate VLANs. Voice VLANs allow a single access port to overlay a second VLAN for strictly VoIP traffic.

Besides the Catalyst switch configuration, no additional configuration is necessary on the Cisco IP Phone to use voice VLANs. The following steps detail, at a high level, how voice VLANs, configured with a specific VLAN ID, operate on Catalyst switches:

Cisco IP Phones also mark their egress frames with specific differentiated services code point (DSCP) and class of service (CoS) values. With voice VLANs, the Cisco IP Phone still sends ingress frames from the workstation attached to the PC port of the phone without a VLAN tag. As a result, the attached workstation still operates in the access VLAN. Figure 13-4 depicts a logical representation of voice VLANs.

Figure 13-4. Logical Depiction of Voice VLANs

With Cisco IP Phones in their own IP subnets and VLANs, network administrators can easily identify and troubleshoot network problems. In addition, network administrators can create and enforce QoS or security policies on a per-VLAN basis. With the voice VLAN feature, Cisco enables network administrators to gain all the advantages of physical infrastructure convergence while maintaining separate logical topologies for voice and data terminals, creating an effective way to manage a multiservice network.

To configure Catalyst switches running Cisco IOS for voice VLANs, use the following command:

switchport voice vlan {vlan-id | dot1p | none | untagged}

vlan-id refers to the 802.1Q tagged VLAN that is used for traffic to and from the Cisco IP Phone. The switch informs the Cisco IP Phone of this VLAN by using CDP. This is the recommended configuration for Catalyst switches using Cisco IP Phones. The dot1p option configures the switch to inform the Cisco IP Phone to use 802.1P priority tagging for IP phone traffic and to use the default native VLAN (VLAN 0) for all traffic. This configuration is useful in trusting ingress CoS values from IP phones without using a separate voice VLAN. This configuration is common for third-party IP phones that do not support CDP. The none option effectively disables the voice VLAN feature, and the Cisco IP Phone uses its own configuration to send untagged frames. The untagged option configures the switch to inform the Cisco IP Phone to explicitly use untagged frames.

Example 13-1 illustrates an interface configured for voice VLANs. Note that the voice VLAN feature refers to the native VLAN as the access VLAN.

(text deleted)
!
mls qos
!
(text deleted)
!
interface FastEthernet0/24
 switchport access vlan 2
 switchport mode dynamic desirable
 switchport voice vlan 700
 mls qos trust cos
 spanning-tree portfast
!
(text deleted)
!

In Example 13-1, the Cisco IP Phone transmits all of its frames with an 802.1Q tag for VLAN 700. The workstation that is attached to the Cisco IP Phone resides in VLAN 2, and both the Cisco IP Phone and the Catalyst switch transmit and receive all traffic to and from the workstation without a VLAN tag on the native (access) VLAN. The switch also trusts all ingress CoS values in the configuration shown in Example 13-1; refer to Chapter 10 for more details on the QoS configurations.

Cisco CatOS refers to voice VLANs as auxiliary VLANs. To configure auxiliary VLANs in Cisco CatOS, use the following command:

set port auxiliaryvlan mod/ports {vlan | untagged | dot1p | none}

Properly provisioning the network bandwidth is a major component of designing a successful IP telephony network. The sum of the calculated bandwidth of all applications, including those for voice, video, and data, should not exceed approximately 75 percent of the total available bandwidth for any specified link. Seventy-five percent is a recommended threshold in preventing congestion, because traffic flows tend to burst above the required bandwidth. Note that even when the total required bandwidth for all applications is under 75 percent of available bandwidth, a QoS design is still necessary and recommended. Nevertheless, if the applications need more than 75 percent of bandwidth, design the network for additional links or higher-bandwidth links.

From a traffic standpoint, a single IP telephony call consists of two data flows:

Bandwidth provisioning calculations need to include not only the voice stream traffic, but also the call control traffic.

A VoIP packet consists of the Layer 2 link header, IP header, User Datagram Protocol (UDP) header, RTP header, and voice payload. The link header varies in size according to the Layer 2 media used. Table 13-1 lists the sizes of the other headers.

The VoIP packet overhead is significant because it is a factor in determining the necessary bandwidth requirements in the multilayer switched network. Moreover, the voice sampling rate determines the bit rate. The sampling rate varies based on voice codec. The most popular codecs are G.711 and G.729, which use a total bandwidth (including the IP and Ethernet headers) of 87.2 Kbps and 31.2 Kbps, respectively. When designing a multilayer switched network, determining the amount of bandwidth needed for the maximum concurrent voice calls is a requirement, especially for low-speed WAN interfaces, using the total frame bit rate including all the headers.

For a complete discussion on bandwidth provisioning for IP telephony solutions, refer to the following document on Cisco.com:

Cisco.com also includes the TAC Voice Bandwidth Codec Calculator tool for calculating bandwidth requirements for VoIP calls.

Campus and building power availability potentially affect IP telephony solutions. IP phones can use power from several different sources. These sources include power directly from Catalyst switches with inline power capabilities, an inline power patch panel, or an AC power supply. For more information about provisioning the Catalyst 6500 family of switches for inline power, refer to the following document on Cisco.com:

Moreover, the loss of power does not affect one device at a time, and generally affects an entire building or multiple buildings. As a result, a significant power outage may affect all devices in the IP telephony solution, including the Building Distribution and Campus Backbone submodules, telephony gateways, and call-processing equipment such as Cisco CallManager servers.

To maintain a highly available IP telephony solution during power anomalies, campus networks require a power-protection strategy.

Providing high availability with a power-protection strategy requires the use of uninterruptible power supply (UPS) systems with a minimum battery life of 1 hour and a 4-hour repair time for UPS system failures. In addition, a power generator is an alternate means of providing power during an outage. The recommendation for any IP telephony solution includes a UPS or generator backup. In addition, the power-protection strategy should include UPS systems that have auto-restart capability and a service contract for 4-hour repair for the UPS system or generator.

In summary, recommendations for a power-protection strategy for an IP telephony solution deployed in a multilayer switched network include the following:

For more information about power protection requirements for IP telephony networks, consult the following white paper on Cisco.com:

In traditional voice networks, there is a distinct set of voice management concepts and processes. The convergence of voice and data has brought about a similar merge of data network and voice-only management.

In fact, this merging of management tasks and processes is one of the key benefits of using a converged network as opposed to a dedicated voice-only network. However, it is still necessary to understand the traditional voice-only management concepts to relate the features available in that technology to the converged network management techniques. When deploying IP telephony in a multilayer switched network, evaluate and design a sufficient voice network management system. For more information on network management for IP telephony solutions, refer to the following web page on Cisco.com:

Cisco SONA telephony is based on a distributed model for high availability. Cisco CallManager clusters support redundancy. All IP telephony gateways support the ability to “re-home” to a secondary Cisco CallManager in the event that a primary Cisco CallManager fails, thereby providing redundancy. This differs from call survivability in the event of a Cisco CallManager or network failure, where the call is routed to an alternate gateway, such as an MGCP gateway.

As with any network capability, you need to plan redundancy for critical components such as the CallManager and the associated gateway and infrastructure devices that support the voice network. In terms of the multilayer switched network, additional switch ports and switches may be necessary for deploying high availability within the IP telephony solution. For more information about CallManager redundancy, consult the following document on Cisco.com:

With the advent of IP telephony, which uses IP data network devices for voice communication, the potential exists for malicious attacks on call-processing components and IP telephony applications. As such, with any data network, IP telephony solutions require security methods.

To help safeguard against attacks on IP telephony components, you should implement the same security features as you would for any other network devices. In regards to the multilayer switched network, consider deploying the following security measures when deploying IP telephony solutions as a first-level security model:

As a second level of security in an IP telephony-enabled multilayer switched network, the recommended practice is to deploy the following:

The following resources and equipment are required to complete this exercise:

The purpose of this exercise is to configure interfaces of a Catalyst IOS–based switch for voice VLANs using the following parameters:

Figure 13-3, earlier in this chapter, illustrates the network layout for this configuration exercise.

In this configuration exercise, you use the commands listed in Table 13-3, which are in alphabetical order so that you can easily locate the information you need. Refer to this list if you need assistance during the configuration exercise. The table includes only the specific parameters used in the example and not all the available options for the command.