connecting to an ip wan

C H A P T E R 8 Connecting to an IP WAN The previous chapters have focused on Voice over IP (VoIP) within the IP network at a single site. The gateway in such a setup would interconnect public switched telephone network (PSTN), PBX, and other plain old telephone service (POTS) endpoints with voice- enabled IP endpoints, such as IP phones. VoIP over the WAN has several applications, such as connecting multiple sites, allowing service providers to terminate long-distance and local voice calls, providing voice services to telecommuters, and so on. In this chapter you will learn • Applications for connecting to an IP WAN • Design considerations when using VoIP over an IP WAN • Quality of Service issues and solutions • Configuring Quality of Service to fit a provider’s MPLS standards • Providing fax and modem services within a VoIP network • Ways to secure your VoIP traffic Applications for Connecting to an IP WAN Connecting voice gateways over an IP WAN allows you to send voice and video to other locations as IP packets. For businesses that have geographically distributed offices, using IP telephony to call between offices can be more cost effective than making long-distance calls. IP telephony is increasingly becoming a need for businesses that spread their offices globally. It lets you leverage your investment in WAN bandwidth between offices. The WAN connection can be a direct circuit between sites, such as a T1; a virtual circuit, including Frame Relay; ATM permanent virtual circuit (PVC); or a shared connection, as with a Synchronous Optical Network (SONET) ring. Communication between the voice gateways could rely on your service provider, such as with Multiprotocol Label Switching (MPLS), or on the Internet, as when using a virtual private network (VPN) between sites. Satellite links are also an option, provided their speed and reliability are acceptable. 220 Chapter 8: Connecting to an IP WAN The following are some situations in which IP WAN connections might be appropriate: • Your company is using VoIP at multiple sites. Sending voice over the WAN connections between them is a way to make intracompany phone calls without using the PSTN. Voice performance is better with a full-mesh topology. In a hub-and-spoke design, spoke-to-spoke phone calls have to go through the hub, adding extra delay to the call. Careful attention to quality of service (QoS) is essential when sending Voice over Frame Relay (VoFR) or Voice over ATM (VoATM). PPP has no built-in QoS mechanisms; therefore, it needs multilevel precedence and preemption (MLPP) to be deployed to ensure that latency and delay requirements for voice are met. • You want to do “tail end hop-off,” which turns a long-distance call into a local one. (In tail end hop-off, you route voice traffic that is bound for a phone in a particular area to your voice gateway in that area. The voice gateway then routes the traffic out to the PSTN as a local call.) • A company that wants to preserve its PBX investment yet avoid the cost of POTS lines and trunks can take advantage of existing WAN links for voice between sites. In this case, the voice gateway translates between the internal analog voice and the external VoIP. You need to create dial peers that point to the PBX and to the other voice gateways. • Companies might want to centralize their PSTN connections and require remote sites to route all voice traffic bound to the PSTN through a central site. The central site needs enough PRI connections to handle the calls, and each remote site needs only minimal POTS lines in case the WAN connection is lost or for emergency calls. This centralization is normally done when all the sites are located in the same area. • Centralizing Cisco CallManagers reduces the financial investment in IP telephony. In a centralized design, Cisco CallManagers communicate with the other voice devices over an IP WAN. Signaling between phones and CallManagers, and between gateways and CallManagers, is sent over the WAN. Voice media traffic flows directly between the IP phones and the gateway at the remote site and might not traverse the WAN. Design Considerations In most scenarios, voice and data are sent together on the same WAN connection. Sending voice along with data over a WAN network requires additional planning and configuration. This book focuses on gateways, but you must plan for voice flow throughout your network and configure every network device appropriately. Quality of Service 221 Be sure to consider the following areas when designing a voice-enabled WAN: • Bandwidth—Estimate the number of calls you anticipate over the WAN, plus the amount of data traffic, and ensure that you have enough bandwidth. For more information on bandwidth planning, see Chapter 16, “Deploying Gatekeepers.” • Call admission control (CAC)—If the gateway sends out more calls than the WAN can handle, the quality of all calls suffers. Chapter 11, “Influencing Path Selection,” covers CAC. • QoS—If voice will share the WAN link with data, you should protect voice (and video) from data. The next section of this chapter covers QoS. • Security—Consider how secure your network must be and what devices the voice traffic will traverse. For more information on security, see the “Security” section later in this chapter. Quality of Service Typically, data and voice traffic travel across the same WAN link. This can be a problem, because data tends to be transmitted in bursts and could use up all the bandwidth, leaving none for voice. QoS techniques help protect voice (and video) from data. Planning is the most important part of QoS. In most networks, it is not enough to classify traffic as “voice” and “nonvoice” and give preference to voice. Most networks have various types of traffic, each with its own network needs and importance to the company. Although this book concentrates on voice, an effective QoS policy examines all the network applications and involves policy makers in deciding how to handle that data through the network. Your goal should be a consistent, end-to-end QoS strategy throughout your company. One of your first tasks is to determine the needs of each network application. Voice is sensitive to delay, jitter, and drops. High-quality voice and interactive video have the following recommendations: • A maximum of 150 ms of one-way delay • A maximum of 30 ms of jitter • A maximum of 1 percent packet loss One cause of delay is small voice packets having to wait behind larger data packets to be sent out an interface. Jitter, which is variable delay, can result when some voice packets are sent out quickly and some have to wait. Drops happen when an interface queue is completely full—something much more likely to occur if voice has to share a queue with data. Thus, when you are sending voice and data across a WAN it is especially important to plan and implement QoS measures to increase the chances of voice always having the bandwidth it needs. 222 Chapter 8: Connecting to an IP WAN QoS involves three tasks: • Classifying traffic • Marking the classified traffic • Configuring network devices to treat traffic differently based on the markings The modular quality of service command-line interface (MQC) is the recommended method of implementing QoS. It involves using class maps to classify traffic, using policy maps to mark traffic or specify how it will be treated, and applying the policy using the service-policy command. In the following sections, you will look at using MQC with voice gateways. NOTE A full explanation of QoS is beyond the scope of this book. You can find detailed information in the Cisco QoS Solution Reference Network Design document at http:// www.cisco.com/go/srnd, or in these books: • Cisco Catalyst QOS: Quality of Service in Campus Networks by Michael Flannagan, Richard Froom, and Kevin Turek • End-to-End QoS Network Design: Quality of Service in LANs, WANs, and VPNs by Christina Hattinghand and Tim Szigeti Using Class Maps to Classify Traffic Classifying traffic requires looking at it and identifying it according to some characteristic, such as port number or source address. After you classify traffic, you can configure routers and switches to treat it differently from other traffic. The MQC uses class maps to classify traffic. Classification can be based on many different things, but voice is typically identified by looking in the OSI Layer 4, Layer 3, or Layer 2 packet headers. Classifying at Layer 4 You can classify traffic based on the port number in the TCP or User Datagram Protocol (UDP) packet header. Each voice application uses specific port numbers. Table 8-1 lists the default port numbers that common voice-related protocols use. Quality of Service 223 1 SCCP = Skinny Client Control Protocol 2 MGCP = Media Gateway Control Protocol 3 RTP = Real-Time Transport Protocol 4 SIP = Session Initiation Protocol You can use either an access list or a class map to identify this traffic based on the port number. Example 8-1 shows how to do this with an access list. The access list is created and then referenced in a class map. This example classifies the SCCP signaling traffic separately from the voice RTP traffic. This configuration gives you two class maps that break out two types of traffic, as verified in Example 8-2. The class map VOICE identifies the RTP traffic that is permitted in access list RTP, and the class map SIGNALING identifies the SCCP traffic that is permitted in access list SCCP. What about the rest of the data traveling around the network? A default class exists, and anything that is not explicitly identified falls into that, as shown in Example 8-2. Table 8-1 Voice Protocols and Port Numbers Protocol Port(s) Used SCCP 1 TCP ports 2000–2002 MGCP 2 UDP 2427 and 2727; TCP 2428 H.323 UDP 1718 and 1719; TCP 1720 and 1721 RTP 3 UDP ports 16,384–32,767 SIP 4 TCP and UDP port 5060 (Cisco implementation) Example 8-1 Configuring Access Lists and Class Maps VGateway#conf t VGateway(config)#ip access-list extended RTP VGateway(config-ext-nacl)#permit udp any any range 16383 32767 ! VGateway(config-ext-nacl)#ip access-list extended SCCP VGateway(config-ext-nacl)#permit tcp any any range 2000 2002 VGateway(config-ext-nacl)#exit ! VGateway(config)#class-map match-all VOICE VGateway(configs-cmap)#match access-group name RTP ! VGateway(configs-cmap)#class-map match-all SIGNALING VGateway(configs-cmap)#match access-group name SCCP 224 Chapter 8: Connecting to an IP WAN Example 8-3 shows a class map that matches RTP traffic directly. Using a class map in this way lets you bypass configuring an access list for RTP. However, you need to beware of two pitfalls in this technique. First, using a class map this way matches only the even ports in the range you specify. RTP bearer traffic uses the even ports, and control traffic uses the odd ports. Therefore, matching against RTP in a class map breaks out only the voice-bearer traffic, not the control traffic. Second, the way you specify the range of ports is not intuitive. In the access list shown in Example 8-1, the starting and ending port numbers are listed. In a class map, the starting port is specified, but the second number is not the ending port number. The second number is what you would add to the first number to get the ending port. For instance, suppose that you wanted to start at port 16383 and match the next 2000 ports. In that case, you would give the match ip rtp 16383 2000 command. That would match ports 16383 through 18383 (16383 plus 2000). In Example 8-3, class map Voice-Bearer matches the even ports in the range 16383 through 32766 (16383 plus 16383.) Notice that no option is available to match SCCP, MGCP, H.323, or SIP. Example 8-2 Verifying Class Map Configuration VGateway#show class-map Class Map match-any class-default (id 0) Match any Class Map match-all VOICE (id 2) Match access-group name RTP Class Map match-all SIGNALING (id 3) Match access-group name SCCP Example 8-3 Using a Class Map to Identify RTP Traffic VGateway(config)#class-map Voice-Bearer VGateway(config-cmap)#match ? access-group Access group any Any packets class-map Class map cos IEEE 802.1Q/ISL class of service/user priority values destination-address Destination address fr-de Match on Frame-relay DE bit input-interface Select an input interface to match ip IP specific values mpls Multi Protocol Label Switching specific values not Negate this match result protocol Protocol qos-group Qos-group source-address Source address VGateway(config-cmap)#match ip ? dscp Match IP DSCP (DiffServ CodePoints) precedence Match IP precedence Quality of Service 225 Classifying at Layer 3 A second way to identify traffic is to look at the Type of Service (ToS) field in the Layer 3 IP header. The first six bits of this field are called the differentiated services code point (DSCP) bits. They are typically set to a decimal value of 46 for voice-bearer traffic. In the past, Cisco recommended setting voice signaling traffic to DSCP 31. However, the current recommendation is to set it to Class Selector (CS)3. You can use an access list to identify traffic with a certain DSCP value, or match against it in a class map. Example 8-4 shows an access list that looks at the DSCP value in packets. As you can see from the example, you can list the DSCP either as a decimal value or its DiffServ per-hop behavior (PHB) value. The second access list, VOICE-SIG, permits both CS3 and Assured Forwarding (AF)31 to allow for devices that might not yet be transitioned to using only CS3 for signaling. After you create the access lists, you associate them with class maps. rtp Match RTP port nos VGateway(config-cmap)#match ip rtp 16383 16383 ! VGateway(config-cmap)#do show class-map Class Map match-any class-default (id 0) Match any Class Map match-all Voice-Bearer (id 2) Match ip rtp 16383 16383 Example 8-4 Using an Access List to Match DSCP VGateway(config)#ip access-list extended VOICE-BRR VGateway(config-ext-nacl)#permit ip any any dscp ? <0-63> Differentiated services codepoint value af11 Match packets with AF11 dscp (001010) af12 Match packets with AF12 dscp (001100) af13 Match packets with AF13 dscp (001110) af21 Match packets with AF21 dscp (010010) af22 Match packets with AF22 dscp (010100) af23 Match packets with AF23 dscp (010110) af31 Match packets with AF31 dscp (011010) af32 Match packets with AF32 dscp (011100) af33 Match packets with AF33 dscp (011110) af41 Match packets with AF41 dscp (100010) af42 Match packets with AF42 dscp (100100) af43 Match packets with AF43 dscp (100110) cs1 Match packets with CS1(precedence 1) dscp (001000) cs2 Match packets with CS2(precedence 2) dscp (010000) cs3 Match packets with CS3(precedence 3) dscp (011000) cs4 Match packets with CS4(precedence 4) dscp (100000) cs5 Match packets with CS5(precedence 5) dscp (101000) cs6 Match packets with CS6(precedence 6) dscp (110000) cs7 Match packets with CS7(precedence 7) dscp (111000) default Match packets with default dscp (000000) Example 8-3 Using a Class Map to Identify RTP Traffic (Continued) 226 Chapter 8: Connecting to an IP WAN Using a class map to identify traffic based on a DSCP value is shown in Example 8-5. Notice in the output of the show class-map command that, although you specified the decimal DSCP value when configuring the class map, the router has translated that to its Diffserv value of expedited forwarding (EF). The number in parenthesis in Example 8-5 is the decimal value. Classifying at Layer 2 A third way to identify traffic is by looking at the 802.1Q trunking tag or ISL trunking header. There are three bits called the class of service (COS), which are bits that you can set to identify different types of traffic. These bits are usually set to a decimal value of 5 for voice. You can match these bits in a class map. Of course, this only works if the router has an interface that is performing Ethernet trunking. Example 8-6 shows a class map that identifies traffic at Layer 2 by the CoS value. ef Match packets with EF dscp (101110) VGateway(config-ext-nacl)#permit ip any any dscp ef ! VGateway(config-ext-nacl)#ip access-list extended VOICE-SIG VGateway(config-ext-nacl)#permit ip any any dscp cs3 VGateway(config-ext-nacl)#permit ip any any dscp af31 Example 8-5 Using a Class Map to Match DSCP VGateway(config)#class-map DSCP_46 VGateway(config-cmap)#match dscp 46 ! VGateway(config-cmap)#class-map CS3 VGateway(config-cmap)#match ip dscp cs3 ! VGateway#show class-map Class Map match-all CS3 (id 6) Match ip dscp cs1 (8) Class Map match-all DSCP_46 (id 5) Match dscp ef (46) Example 8-6 Using a Class Map to Match CoS VGateway(config)#class-map COS-Voice VGateway(config-cmap)#match cos ? <0-7> Enter up to 4 class-of-service values separated by white-spaces VGateway(config-cmap)#match cos 5 ! VGateway#show class-map Class Map match-all COS-Voice (id 4) Match cos 5 Example 8-4 Using an Access List to Match DSCP (Continued) Quality of Service 227 Cisco IP phones place an 802.1 tag on the voice traffic they send. The CoS is set to 5 for voice-bearer traffic and 3 for voice-signaling traffic. Any traffic from a PC that is connected to the phone is sent untagged. QoS should be enabled on the directly connected switch, and the switch interface should be set to trust the Cisco phone. When this happens, the switch looks at the CoS value before it removes the Layer 2 header, and it translates it into a DSCP value as the packet moves through the switch. Untagged PC traffic gets a DSCP value of 0 by default. When the packet is sent out a switch interface, it is marked at Layer 3 with that DSCP value. (It might also have a CoS value if the outgoing interface is a trunk interface.) Configure the switch to put the desired DSCP value on any packets that you want marked. Their Layer 2 header changes as they move through the network, but you can match against that unchanging Layer 3 DSCP value. Using Policy Maps After you have identified the interesting traffic, you can mark it or set policies for it. Marking traffic involves setting the DSCP bits or the CoS bits. You should classify and mark traffic as close to the end devices as possible, because classifying traffic uses router and switch resources. This is most important for routers, which perform QoS in software. Imagine if every router and switch in the network had to look into every packet to examine its port number. It is much more efficient if the first switch that a packet touches does the classifying and then sets a DSCP value based on the type of traffic it is. Then every other switch and router in the network can trust that the marking is correct and treat the traffic accordingly. This creates a trust boundary at the access switch. The MQC applies policies to the traffic that has been classified by using a policy map. A policy map references the previously created class maps and then specifies what is to be done with traffic in each class. The traffic could, for example, be marked, allocated a minimum bandwidth, limited to a maximum bandwidth, prioritized, or even dropped altogether. You apply policy maps to interfaces. A separate queue is created at the interface for each class map, and the traffic that is identified by each class map is placed in its queue. This allows you to treat each of the classes of traffic differently. Example 8-7 shows an example of marking traffic in a policy map. The class map CoS- Voice was created in Example 8-6. It identifies traffic with a CoS value of 5 in the 802.1Q trunking tag. This example creates a policy map that marks all the traffic classified by CoS- Voice with a DSCP value of 46 (or EF). Example 8-7 Marking Traffic Using a Policy Map VGateway(config)#policy-map COS-TO-DSCP VGateway(config-pmap)#class COS-Voice VGateway(config-pmap-c)#set dscp 46 ! VGateway(config-pmap-c)#class class-default VGateway(config-pmap-c)#set dscp 0 ! VGateway#show policy-map 228 Chapter 8: Connecting to an IP WAN Notice that in Example 8-7, all traffic other than that marked with a CoS of 5 is set to a DSCP of 0 under the default class. If you have routing traffic, it is a good idea to break that out separately before classifying everything else as DSCP 0. Notice also that even though the policy map was configured using decimal values, when you display it, those are translated to the PHB values. You most commonly use a policy map to specify different treatment for the traffic in each queue created by a class map. Setting policy and marking traffic are not mutually exclusive—you can do both of them to the same class. Voice is typically placed in a priority queue, called a low-latency queue (LLQ). It is important to understand that this is a strict priority queue. If any traffic is in the queue, it is sent out before other traffic. You can limit the amount of bandwidth used by the priority queue, however, so that other traffic is not starved. How much bandwidth should you allow in the priority queue? In planning your bandwidth requirements, take into account the anticipated data load plus the voice load. The amount of bandwidth allocated per call varies depending on the coding/decoding (codec) used. Codec describes methods of compressing voice. The most typically used are G.711, which is uncompressed voice, and G.729, which is a type of compressed voice. G.711 is usually used in the LAN where bandwidth is plentiful. G.729 is typically used in the WAN, where you have lower bandwidth links. A G.711 call, sent at 64 kbps, has a payload size of 160 bytes. A G.729 call, sent at 8 kbps, uses a payload size of 20 bytes. IP, UDP, and RTP headers are put onto each packet. The IP header is 20 bytes, UDP is 8 bytes, and RTP is 12 bytes, totaling an additional 40 bytes for each VoIP packet. You have the option of compressing the IP, UDP, and RTP headers, which reduces the header overhead to 2 to 4 bytes, thus reducing the entire packet size and using less bandwidth. For more information on compression, see the “Compression” section later in this chapter. When you are planning bandwidth allocation, also take into consideration the Layer 2 headers to be used. For instance, Ethernet adds an 18-byte header, whereas Frame Relay adds only 6 bytes. Multilink PPP also has a 6-byte header. The ATM header is 5 bytes. If you use MPLS in your WAN network, the MPLS edge router adds a 4-byte header. If you are sending voice over the Internet, you might want to encrypt it in an IPsec tunnel for added security. IPsec adds 50 to 57 bytes of overhead. Secure Real-Time Transport Protocol (SRTP) encrypts the payload of IP voice packets and adds 4 bytes to the packet. As a general rule, 21 to 320 kbps of bandwidth is required per call, depending on the codec and overhead. A good recommendation when running voice and data through the same Policy Map COS-TO-DSCP Class COS-Voice set dscp ef Class class-default set dscp default Example 8-7 Marking Traffic Using a Policy Map (Continued) [...]... using an optional Non-Standard Facilities (NSF) field The Cisco fax relay handles fax calls based on T.30 standards, and thus cannot interpret these capabilities You can cause 252 Chapter 8: Connecting to an IP WAN the gateway to overwrite the NSF field with zeros using the VoIP dial peer command fax nsf 000000 You might need to change the rate at which faxes are sent By default, faxes use the same bandwidth... recognize the type of call, they change to these settings for the duration of the call Passthrough is sensitive to packet loss, delay, and jitter You can use redundancy with passthrough to send an extra copy of each packet, to help mitigate packet loss This does result in higher bandwidth use, however 250 NOTE Chapter 8: Connecting to an IP WAN A third method, Store and Forward, is used only for faxes... e-mail server and allows faxes to be sent as TIFF attachments to e-mails You can use Toolkit Command Language (Tcl) scripts to provide some fax-related services, also Tcl interactive voice response (IVR) scripts are typically used with Store and Forward faxing Tcl scripts can also provide fax detection and fax rollover applications Fax detection allows one phone number to be used for both voice and fax calls... Sector (ITU-T) standards govern such things as fax resolution, identifying tones, handshaking procedures, and transmission speeds They have developed over time from Group 1 to Group 3 standards The Group 3, or “G3,” standard is currently the most commonly used It allows fax transmission rates over analog lines of up to 14,400 bps Group 4 (G4) is a standard for transmitting faxes over ISDN, and it can... T.38 Fax Low Speed Redundancy: 0MGCP T.38 Fax High Speed Redundancy: 0 254 Chapter 8: Connecting to an IP WAN Configuring T.38 Fax Relay for H.323 and SIP Gateways H.323 and SIP gateways use the same basic configuration for T.38 fax relay They do not use NSE messages to signal the other gateway to switch to fax mode, unless you specifically configure it Instead, they use H.323 or SIP messages Configure dial... the router to send redundant packets when doing lowspeed faxing, to cover for any dropped packets The default value is 0, which means no redundancy • hs-redundancy value causes the router to send redundant packets when doing highspeed faxing, to cover for any dropped packets The default value is 0, which means no redundancy • fallback configures a fallback way to handle faxing if the gateway cannot negotiate... in Example 8-18 Commands to verify the configuration include show atm vc and show policy-map interface Compression Another way to lower serialization delay values is to send smaller packets The payload in voice packets tends to be fairly small However, each packet has to carry an IP header, a UDP header, and an RTP header that totals 40 bytes of overhead When voice is sent across a WAN, it is usually... for the MPLS provider to honor the customer DSCP markings and guarantee bandwidth to the video traffic You must do this at the egress from the PE router to the CE router, and between the P routers within the MPLS network MPLS providers typically have a limited number of service levels, and their equipment is programmed to respond to specific DSCP values Many companies find it easiest to just adopt the service... models in the AS5000 series It does not need to be enabled, unless you have used a different method and want to re-enable it The command to enable Cisco fax relay is fax protocol cisco You can give this command under an individual dial peer, or under voice service voip configuration mode to affect all dial peers You can tweak Cisco fax relay in a few ways For instance, Error Correction Mode (ECM) is enabled... into the MPLS cloud At each site, it also needs to reclassify the traffic back into its original seven groups and remark it accordingly The company decides to place voice, video, and call signaling in the real-time, prioritized class It would not be a good idea to mix voice and video over a slow link (less than 768 kbps), because video packets tend to be large and thus take longer to serialize onto . network • Ways to secure your VoIP traffic Applications for Connecting to an IP WAN Connecting voice gateways over an IP WAN allows you to send voice and video to other locations as IP packets Chapter 8: Connecting to an IP WAN The following are some situations in which IP WAN connections might be appropriate: • Your company is using VoIP at multiple sites. Sending voice over the WAN connections. it is especially important to plan and implement QoS measures to increase the chances of voice always having the bandwidth it needs. 222 Chapter 8: Connecting to an IP WAN QoS involves three