CCNP BCMSN Exam Cram 2 (Exam Cram 642-811)
| IP telephony is a component of Cisco's AVVID framework integrating voice, video, and data in the same infrastructure. AVVID was discussed in Chapter 2, "Designing Switched Networks." Like multicasting, which was discussed in Chapter 8, "Multicasts," IP telephony presents its own set of problems and issues. Designing a scalable network with support for IP telephony is not a simple task. During the design phase, you'll have to address the following questions:
The following sections deal with these questions in more depth. Key Services
When implementing an IP telephony solution, you need to consider the four following areas:
One component of your network management strategy should deal with Voice over IP (VoIP) IP telephony as well as traditional data. Actually, your network management solution should be able to easily integrate both of these data types. In a Cisco environment, IP phones use Cisco's CallManager product for setting up, maintaining, and tearing down phone connections. Because this is a critical component in voice communications and is required to set up voice connections, implementing CallManager redundancy is critical. Actually, you need to look at not only your voice components when it comes to redundancy, but also your data components, such as routers and switches, and examine the amount of time it takes for convergence to take place at both Layer 2 and Layer 3. Any downtime experienced, even if it is for a brief period of time, can be detrimental for your phone solution. Because VoIP uses a LAN/WAN medium to deliver voice traffic, who has access to this traffic stream becomes critical: You don't want just anyone to use a protocol analyzer or packet sniffer to capture this traffic and listen in on a phone conversation. Therefore, a security policy must be drafted and security solutions must be implemented based on this policy. At a minimum, voice traffic is usually segregated from data traffic by using different VLANs. One of the most important components in ensuring a reliable and quality voice connection is QoS. QoS guarantees the following:
QoS includes solutions such as traffic classification and traffic prioritization and queuing, detecting and avoiding congestion, shaping traffic to avoid congestion, and using compression to more fully utilize available bandwidth. Picking the right solution or solutions can be a difficult task because each has its own advantages and disadvantages. Later sections in this chapter deal with these topics. Bandwidth
One key component in providing scalable, yet reliable, IP telephony solutions is ensuring that your voice traffic receives adequate bandwidth. IP telephony consists of two connections: a call control signaling connection and a voice connection. The call control signaling connection is used to establish the voice connection, which carries the actual voice traffic. This control connection can use many different standards, such as H.323 or the Media Gateway Control Protocol (MGCP), to establish the voice connection. As to design issues, both of these connections require bandwidth inside your network. A normal rule of thumb is to ensure that each of your links do not, on average, exceed 75% of the total capacity of a link. This leaves ample room for bursts in traffic as well as handling QoS issues for voice traffic. However, for networks that have little bandwidth, you'll have to determine how much bandwidth you need for voice connections to ensure that you can support them. VoIP connections typically use the Real Time Transport Protocol (RTP) to set up and maintain voice connections. This information is encapsulated in a UDP segment at the transport layer and an IP packet at the network layer. All of these protocols incur additional overhead (header information), as well as the overhead involved with the Layer 2 transport, which is typically Ethernet. RTP uses 12 bytes, UDP has an 8-byte header, IP has a 20-byte header, and Ethernet has a 14-byte header (plus an ending CRC). All of this additional information must be included in your calculation. Use this formula to figure out how much bandwidth you need to support a single voice connection: Bandwidth = (packet payload + all overhead) * packets generated per second The number of packets generated per second is based on the amount of time to generate a packet. For example, if you have a 20-millisecond packet period, this allows an IP phone to generate 50 pps. Of course, you'll need to figure out how many simultaneous voice connections you'll need to support for uplink and backbone connections. Power
Similar to a normal phone, an IP phone requires some sort of power to function. A normal phone draws a small amount of current so that features such as dial tone, ringing, and so on, can be provided. An IP phone is no different. Without some sort of power, an IP phone does not function. You need to consider two components when dealing with power: a power source and an uninterruptible power supply (UPS). First, you need some type of power source for your IP phones. Cisco's Catalyst switches can provide this power over a Category 5 cable the same cable provides both power to the IP phone as well as Ethernet connectivity. On Cisco's Catalyst switches, this requires you to purchase an Ethernet module that supports inline power on each of its Ethernet ports. Your second option is to use a special form of patch panel that can provide a power source to the IP phones when connecting the IP phones to a patch panel. A third choice is to use an external power supply that is directly attached to the phone (assuming that the phone supports this option). The second issue deals with UPS systems and redundancy. One of the reasons that a normal telephone doesn't use an electrical outlet for power is that if you lose electricity in your home, the phone still works because the power it receives is from a separate connection from power you get from the electric company. This enables you to make phone calls in emergency situations when you've lost power. Power for IP phones is just as important. If your Catalyst switch or patch panel loses power, you won't be able to use your IP phone. Therefore, you need to implement a very reliable UPS system to prevent against power loss (which is why using an external power supply for an IP phone is not recommended). This should include a robust UPS and generator backup system, 24x7 UPS monitoring, and a 4-hour service-level agreement with your UPS vendor to deal with UPS problems. Auxiliary VLANs
Auxiliary VLANs are a feature of Cisco Catalyst switches that allow IP phones to be placed in their own VLANs. You normally want to separate your VoIP traffic from your data traffic. You can easily do so with static VLAN configurations, but it becomes an issue if your IP phones are constantly being moved around the network. With auxiliary VLANs, no end-user intervention is required to put the IP phone in the correct VLAN. Auxiliary VLANs use 802.1Q and 802.1P in order to put IP phones in the correct VLAN. Using DHCP, IP phones can correctly be assigned the right IP addressing information for the auxiliary VLAN they're associated with. A physical connection can even be associated with an auxiliary VLAN for IP phones and a separate VLAN for data traffic. Notice that you are taken into a Subconfiguration mode, where you must enter the high-availability and single-router-mode commands. Good Design Practices
There are two main issues that you have to deal with when designing a scalable VoIP solution: Layer 2 (access layer) and Layer 3 (distribution layer) convergence. Within the access layer, use auxiliary VLANs with 802.1P and 802.1Q when deploying IP telephony as well as the following STP features: PortFast, UplinkFast, UDLD, and Root Guard. At the distribution layer, use the following features:
|