CCNP Switch Notes Voice and Video in a Campus Network
Voice over IP (VoIP) has become common in the business world, and now Video over IP is becoming more integrated into networks. Neither should be added to a network without advance planning to ensure good voice and video quality. Some benefits of converging voice, video, and data networks include:
Consolidating network expenses: Only one wire and one switch port are needed per user. One network to provision and manage.
More efficient bandwidth use: Bandwidth can be used for data when there is not an active voice/video session.
Lower telephony costs: Internal calls use the data network, rather than the PSTN.
Innovative services: Ability to unify a company’s various methods of communication.
For service providers, the ability to sell new services: Can lead to increased revenue, flexibility in pricing, and access to new communication devices. Voice, video, and data have different network requirements. Voice requirements include low bandwidth, little delay, small amounts of jitter (variable delay), small amounts of packet loss, a highly available network, and PoE. Security requirements are about average, but management is highly important.
Video requirements depend on whether it is a one-way stream or an interactive video session. One-way streams use a fairly steady amount of bandwidth but in interactive sessions the bandwidth varies widely. Typical requirements include high bandwidth, little delay, small amounts of jitter, and little packet loss. High availability is not as important, and PoE is not needed. Security and management needs are medium.
Data requirements typically include high bandwidth, but delay and jitter are not crucial. A highly available network is needed, but PoE is not. Data security should be high, with medium management levels.
VoIP in a Campus Network
Figure 8-1 shows some components of a VoIP system, which can include the following:
- IP phones: Provide voice and applications to the user
- Cisco Unified Communications Manager (UCM): Serves as an IP PBX. Registers phones, controls calls
- Voice gateways: Translates between PSTN and IP calls and provides backup to the Cisco UCM (IP PBX, or Call Agent)
- Gatekeepers: An optional component that can do call admission control, allocate bandwidth for calls, and resolve phone numbers into IP addresses
- Video conferencing unit: Allows voice and video in the same phone call
- Multipoint control unit: Allows multiple participants to join an audio and/or video conference call
- Application server: Provides services such as Unity voice mail and Presence
VoIP traffic consists of two types: voice bearer and call control signaling. Voice bearer traffic is carried over the UDPbased Real Time Protocol (RTP). Call control uses one of several different protocols to communicate between the phone and UCM and between the UCM and the voice gateways.
Preparing the Network for VoIP
When adding voice or video to an existing network, you should examine several things in advance to provide the high level of availability users expect in their phone system:
- What features are needed?: Power for IP phones, security for voice calls, and Quality of Service (QoS) to control bandwidth, delay, jitter, and packet loss.
- The physical plant: Cabling at least CAT-5
- Electrical power for the IP phones: Use either PoE from Catalyst switch or power inline module, or a power brick.
- Bandwidth: Commit no more than 75 percent of bandwidth. Consider all types of traffic: voice, video, and data.Have more than enough bandwidth if possible. Include both voice and call-control traffic in your planning.
- Network management: Monitor and proactively manage the network so that it is always available. Need voice VLANs on the switches and DHCP for the phones.
- High availability: Provide redundant hardware links. Need uninterruptible power supply (UPS) with auto-restart,monitoring, and four-hour response contract. Might need generator backup. Maintain correct operating temperatures.
Network and Bandwidth Considerations
The network requirements for VoIP include:
- Maximum delay of 150–200 ms (one-way)
- No more than 1 percent packet loss
- Maximum average jitter of 30 ms
- Bandwidth of 21–106 kbps per call, plus approximately 150 bps per phone for control traffic
A formula to use when calculating bandwidth needed for voice calls is as follows:
(Packet payload + all headers) * Packet rate per second
Voice VLANs
Cisco switches can be configured to dynamically place IP telephones into a Voice, or auxiliary, VLAN separate from the data VLANs. They can do this even when the phone and PC are physically connected to the same switch port. Voice VLANs enable phones to be dynamically placed in a separate IP subnet from hosts, to have QoS (using 802.1Q/p headers) and security policies applied, and make troubleshooting easier
Cisco IP phones have a small internal switch that places an 802.1q tag on voice traffic and marks the Class of Service (CoS) bits in the tag. Data traffic is sent untagged over the native VLAN. The switch port does not actually become a trunk and still can be configured as an access port. It is considered a multi-VLAN access port.
Power over Ethernet (PoE) Switches
IP phones can receive power from PoE switches, eliminating the need for an electrical plug.
Two power standards are the Cisco Inline PoE and the IEEE’s 802.3af standard. Both have a method for sensing that a powered device is connected to the port. 802.3af specifies a method for determining the amount of power needed by the device. Cisco devices, when connected to Cisco switches, can additionally use CDP to send that information. Most IP phones require no more than 15 W of power specified in 802.3af, but some new phones, access points, and surveillance cameras require more. The 802.3at standard will specify up to 30 W of power. Some Cisco switches can currently supply up to 20 W.
Because a switch assumes 15.4 W of power until the connected device tells it the amount needed (via CDP), calculate your power budget based on 15.4 W for all devices because if the switch reboots, all ports will ask for 15.4 W until they get the correct information. Non-CDP devices always get allocated 15.4 W.
Cisco PoE switches automatically detect and provide power. To disable this function, or to reenable it, use the interface command power inline {never | auto}. To view interfaces and the power allotted to each, use show power inline[interface].
QoS for VoIP
QoS gives special treatment to certain traffic at the expense of others. Using QoS in the network has several advantages:
- Prioritizes access to resources so that critical traffic can be served
- Allows good management of network resources
- Allows service to be tailored to network needs
- Allows mission-critical applications to share the network with other data
People sometimes think that there is no need for QoS strategies in a LAN. However, switch ports can experience congestion because of port speed mismatches, many people trying to access the switch backbone, and many people trying to send traffic to the same switch port (such as a server port). Voice and video traffic contends with, and can be affected by, data traffic within both the WAN and the LAN.
QoS Actions
Three QoS strategies are commonly implemented on interfaces in which traffic enters the switch:
- Classification: Distinguishing one type of traffic from another. After traffic is classified, other actions can be performed on it. Some classification methods include access lists, ingress interface, and NBAR.
- Marking: At Layer 2, placing an 802.1p CoS value within the 802.1Q frame tag. At Layer 3, setting IP Precedence or Differentiated Services Code Point (DSCP) values in the packet’s IP header.
- Policing: Determining whether a specific type of traffic is within preset bandwidth levels. If so, it is usually allowed and might be marked. If not, the traffic is typically marked or dropped. CAR and class-based policing are examples of policing techniques.
Other QoS techniques are typically used on outbound interfaces:
- Traffic shaping and conditioning: Attempts to send traffic out in a steady stream at a specified rate. Buffers traffic that goes above that rate and sends it when there is less traffic on the line.
- Queuing: After traffic is classified and marked, one way it can be given special treatment is to be put into different queues on the interface to be sent out at different rates and times. Some examples include priority queuing, weighted fair queuing, and custom queuing. The default queuing method for a switch port is FIFO.
- Dropping: Normally interface queues accept packets until they are full and then drop everything after that. You can implement prioritized dropping so that less important packets are dropped before more important ones, such as with Weighted Random Early Detection (WRED).
DSCP Values
Differentiated services provide levels of service based on the value of certain bits in the IP header or the 802.1Q tag.Each hop along the way must be configured to treat the marked traffic the way you want; this is called per-hop behavior (PHB).
In the Layer 2 802.1q tag, you use the three 802.1p bits to set the CoS value. Voice is usually set to 5 and video to 4.
In the Layer 3 IP header, you use the 8-bit ToS field. You can set either IP Precedence using the top 3 bits or
Differentiated Services Code Points (DSCP) using the top 6 bits of the field. The bottom 2 bits are set aside for congestion notification. The default DSCP value is 0, which corresponds to best-effort delivery.
The six DSCP bits can be broken down into two sections: The first 3 bits define the DiffServ Assured Forwarding (AF) class, and the next 2 bits define the drop probability within that class. The sixth bit is 0 and unused. AF classes 1–4 are defined, and within each class, 1 is low drop probability, 2 is medium, and 3 is high (meaning that traffic is more likely to get dropped if there is congestion). These are shown in Table 8-1.
Table 8-1 DSCP Assured Forwarding Values
Low Drop | Medium Drop | High Drop | |
Class 1 | AF11 | AF12 | AF13 |
Class 2 | AF21 | AF22 | AF23 |
Class 3 | AF31 | AF32 | AF33 |
Class 4 | AF41 | AF42 | AF43 |
Voice bearer traffic uses an Expedited Forwarding value of DSCP 46 to give it higher priority within the network.
Trust Boundaries
When IP traffic comes in already marked, the switch has some options about how to handle it. It can:
- Trust the DSCP value in the incoming packet, if present.
- Trust the IP Precedence value in the incoming packet, if present.
- Trust the CoS value in the incoming frame, if present.
- Classify the traffic based on an IP access control list or a MAC address access control list.
Mark traffic for QoS as close to the source as possible. If the source is an IP telephone, it can mark its own traffic. If not, the building access module switch can do the marking. If those are not under your control, you might need to mark at the distribution layer. Classifying and marking slows traffic flow, so do not do it at the core. All devices along the path should then be configured to trust the marking and provide a level of service based on it. The place where trusted marking is done is called the trust boundary.
Configuring VoIP Support on a Switch
Before implementing VoIP, plan the following:
- PoE: Ensure that enough power is available for all phones, with a UPS backup.
- Voice VLAN: Determine the number of VLANs needed and the associated IP subnets. Add DHCP scopes for the phones, and add the phone networks to the routing protocol.
- QoS: Decide which marking and queues will be used. Implement AutoQoS and then tune as needed
- Fast Convergency: To enhance high availability, tune the routing and HSRP/VRRP/GLBP timers.
- Test Plan: Test the voice implementation thoroughly before converting users to it. Check that both the phone and PC get the correct IP addresses, that the phone registers with the UCM, and that calls to and from the phone succeed.
Manual Configuration
To associate a voice VLAN with a switch port, use the following:
Switch(config-if)#switchport voice vlanvlan-ID
To configure an IOS switch to trust the markings on traffic entering an interface, use the following:
Switch(config-if)#mls qos trust {dscp | cos}
To configure the switch to trust the traffic markings only if a Cisco phone is connected, use the following:
Switch(config-if)#mls qos trust device cisco-phone
To set a COS value for frames coming from a PC attached to the phone, use the following:
Switch(config-if)#switchport priority extend coscos-value
To verify the interface parameters, use the following:
Switch(config-if)#show interfaces interface switchport
To verify the QoS parameters on an interface, use the following:
Switch(config-if)#show mls qos interface interface
Using AutoQoS
When AutoQoS is enabled, the switch configures its interfaces based on a best-practices template. AutoQoS has the following benefits:
- Automatic discovery and classification of network applications.
- Creates QoS policies for those applications.
- Configures the switch to support Cisco IP phones and network applications. Manual configuration can also be done afterward.
- Sets up SNMP traps for network reporting.
- Configures consistently across your network when used on all routers and switches.
CDP must be enabled for AutoQoS to function properly with Cisco IP phones.
AutoQoS commands for switches running Native IOS are shown in Table 8-3.
Table 8-3 AutoQoS Commands for IOS
Video over IP
Video traffic roughly falls into one of three categories: many-to-many, many-to-few, and few-to-many.
Many-to-many includes interactive video, such as Telepresence, Webex, desktop video conferencing, and other peer-topeer video and collaboration applications. The data flow is client-to-client, or MCU-to-client. Bandwidth needs for high definition video vary during the session but are high-up to 12 Mb/s per location, with compression.
Many-to-few sessions represent IP surveillance cameras. The video flow is from the camera source to a storage location, from storage to a client, or from the source to a client. These typically require up to 4 Mb/s of bandwidth per camera.
Few-to-many describes the typical streaming video, either from an internal company source or an Internet source. It also applies to digital signage media. This is the most predictable of all video streams and users typically tolerate less-thanperfect quality. Traffic flows are from storage-to-client or from server-to-client.
QoS Requirements for Video
Video traffic should be compressed because of its high bandwidth needs, but this causes a lot of variation in network traffic. A picture that does not change much can compress well, resulting in fairly low bandwidth use. But when there are a lot of changes in the picture, such as when someone moves or shares a new document, compression does not work as well, which results in high bandwidth use. In contrast, voice traffic is fairly steady.
Video should be placed in its own queue and might be prioritized depending on company requirements. Consider placing interactive and streaming video into different queues. Aim to provide no more than 200 ms of latency for most video applications.
Make sure that there is sufficient bandwidth in the network before adding video applications