Chapter 4 discussed the details of the network infrastructure design and requirements to support the converged network. This section applies the design tasks and concepts learned in Chapter 4 to the XYZ network architecture.
To support the converged data and voice traffic, the network infrastructure should have proper quality of service (QoS) mechanisms enabled at the following network infrastructure elements:
Access, distribution, and core layer switches and routers
WAN aggregation routers
Remote-site routers
This section discusses the steps that you need to take to ensure that the XYZ network is ready to support IPT.
The existing IP addressing scheme used for the data network at XYZ is collected with the help of Appendix B, "IPT Planning Phase: Network Infrastructure Analysis Questionnaire." With this information, the next step is to design the IP addressing and VLAN scheme for the IPT network throughout the XYZ network. Table 5-3 shows the VLAN and subnet design for the converged network.
Location | VLAN ID | VLAN Name | VLAN Subnet | Description |
|---|---|---|---|---|
San Jose | 3 | SJC_SRV1 | 10.1.1.0/27 GW: 10.1.1.1 HSRP1: 10.1.1.2 HSRP2: 10.1.1.3 | VLAN for publisher server, TFTP server, DHCP[1] server, subscriber 1, IVR[2] 1, and other existing data center servers such as DNS[3] servers, mail servers, and so on. |
4 | SJC_SRV2 | 10.1.1.32/27 | VLAN for subscriber 2, IVR 2, and other exiting data center servers | |
5 | SJC_media | 10.1.1.64/27 | VLAN for gateways, conferencing, and transcoding resources | |
11 | SJC_voice1 | 10.1.11.0/24 GW: 10.1.11.1/24 HSRP1: 10.1.11.2/24 HSRP2: 10.1.11.3/24 | IP Phones | |
12 | SJC_voice2 | 10.1.12.0/24 | IP Phones | |
13 | SJC_voice3 | 10.1.13.0/24 | IP Phones | |
14 | SJC_voice4 | 10.1.14.0/24 | IP Phones | |
15 | SJC_voice5 | 10.1.15.0/24 | IP Phones | |
111 | SJC_data1 | 10.1.111.0/24 | User PCs | |
112 | SJC_data2 | 10.1.112.0/24 | User PCs | |
113 | SJC_data3 | 10.1.113.0/24 | User PCs | |
114 | SJC_data4 | 10.1.114.0/24 | User PCs | |
115 | SJC_data5 | 10.1.115.0/24 | User PCs | |
Seattle | 21 | SEA_voice1 | 10.2.1.0/24 | IP Phones |
211 | SEA_data1 | 10.2.11.0/24 | User PCs | |
Dallas | 31 | DAL_voice1 | 10.3.1.0/24 | IP Phones |
311 | DAL_data1 | 10.3.11.0/24 | User PCs | |
Sydney | 4 | SYD_SRV1 | 10.4.1.0/27 GW: 10.4.1.1 HSRP1: 10.4.1.2 HSRP2: 10.4.1.3 | CallManager publisher server, subscriber 1, and Unity 1 |
5 | SYD_SRV2 | 10.4.1.32/27 | CallManager subscriber 2 and Unity 2 | |
6 | SYD_GW | 10.4.1.64/27 | Sydney gateways | |
11 | SYD_voice1 | 10.4.11.0/24 | IP Phones | |
12 | SYD_voice2 | 10.4.12.0/24 | IP Phones | |
13 | SYD_voice3 | 10.4.13.0/24 | IP Phones | |
411 | SYD_data1 | 10.4.111.0/24 | User PCs | |
412 | SYD_data2 | 10.4.112.0/24 | User PCs | |
413 | SYD_data3 | 10.4.113.0/24 | User PCs | |
Melbourne | 51 | MEL_voice1 | 10.5.1.0/24 | IP Phones |
511 | MEL_data1 | 10.5.11.0/24 | User PCs | |
Brisbane | 61 | BRI_voice1 | 10.6.1.0/24 | IP Phones |
611 | BRI_data1 | 10.6.11.0/24 | User PCs |
[1] DHCP = Dynamic Host Configuration Protocol
[2] IVR = interactive voice response
[3] DNS = Domain Name System
You arrive at IP addressing and VLAN scheme shown in Table 5-3 by following these guidelines:
Use the RFC 1918 address space (nonroutable) to assign the IP addresses to the IPT devices to tighten the security of the telephony network.
Implement separate VLANs for data and voice networks.
Do not place all the IPT call-processing servers and application servers in a single VLAN. This approach prevents Layer 2 issues such as a faulty NIC on one server bringing down all servers, thereby causing a major network failure.
Whenever possible, design the IP addressing scheme so that you can do route summarization to optimize the IP routing table sizes in the routers.
Establish a standard naming convention to assign the VLAN IDs and IP addresses. This greatly helps later in troubleshooting and managing the network. For example, in Table 5-3, the servers are assigned to a VLAN with the name SJC_SRV1.
Chapter 1 in the "CallManager Clustering" section, the TFTP server stores the configuration information and binary loads for the IP Phones and other IPT endpoints. For the San Jose CallManager cluster, the DHCP server also performs the role of a TFTP server. In Sydney, the CallManager publisher server acts as a TFTP server.
In both clusters, the DHCP server is configured to send the TFTP server the IP address in DHCP custom option 150 to Cisco IP Phones and other endpoints. Because each cluster has a single TFTP server, the value of custom option 150 for all the scopes in San Jose points to the TFTP server in San Jose. Similarly, the DHCP option 150 value for all scopes in Sydney points to the IP address of the CallManager publisher server in Sydney, which is performing the job of TFTP server.
Note
The best practice is to off-load the DHCP and TFTP services from the publisher for any IPT deployments that involve more than 500 IP Phones.
This section discusses the tasks involved in making the central site LAN infrastructure at San Jose and Sydney sites ready to support IPT. Figure 5-2 shows the XYZ LAN architecture at central sites San Jose and Sydney. The central sites use Catalyst 6500 switches at the access, distribution, and core layers.
Use of the QoS features that are available in the network devices ensures voice quality in a converged network. These features must be enabled end to end in a converged network to provide high-quality voice services.
In high-bandwidth LANs (10/100/1000 Mbps Ethernet networks), the QoS concern is the smaller buffers in the switches rather than bandwidth or transmission delays. Therefore, the main objective becomes protecting time-sensitive traffic from buffer limitations.
Use the following guidelines when designing the LAN QoS for IPT networks:
Protect the voice traffic against packet drops caused by buffers or queues overflowing.
Protect video traffic and any other time-sensitive traffic against packet drops caused by buffers or queues overflowing.
Protect against individuals inadvertently or intentionally configuring their workstations to send packets by setting a high-priority Type of Service (ToS) byte.
Provide a trusted edge or trust boundary at the LAN edge to help ensure that classification is done specifically for WAN QoS.
Implement the WAN QoS configuration as accurately as possible, keeping the available bandwidth and traffic flows in mind.
The QoS policies that enforce the trusted edge verify the proper classification of class of service (CoS), ToS, and Differentiated Services Code Point (DSCP) values. LAN switches can trust incoming CoS values, allowing them to queue the traffic based on CoS values. The LAN device hands off Layer 3 IP precedence bits to the WAN device based on the recommended traffic classification for various types of traffic, as shown in Table 5-5. When deploying QoS in the network, you need to identify the number of classes of service (traffic types) that exist in the network and the type of treatment required for each traffic type.
Traffic Type | Layer 2 COS | Layer 3 IP Precedence | Layer 3 DSCP (PHB) |
|---|---|---|---|
Voice RTP[1] | 5 | 5 | 46 (EF[2]) |
3 | 3 | 26 (AF[5]31) 24 (CS3)* | |
Data | 02 | 02 | 1022 (0AF23) |
Video | 4 | 4 | 34 (AF41) |
[1] RTP = Real-Time Transport Protocol
[2] EF = Expedited Forwarding
[3] SCCP = Skinny Client Control Protocol
[4] MGCP = Media Gateway Control Protocol
[5] AF = Assured Forwarding
Also refer to Figure 4-9 in Chapter 4, which shows the detailed Layer 2 and Layer 3 classification values for various types of applications.
Note
The new Internet Engineering Task Force (IETF) standard recommends that the signaling packets be marked with DSCP value 24 (per-hop behavior [PHB] value CS3) rather than the currently used value DSCP 26 (PHB AF31), as shown in Table 5-5. Only a few endpoints, such as Cisco IP Communicator and Cisco IP SoftPhone products, implement this new change. Therefore, until this new marking is incorporated in all the products, you should reserve both values for signaling in the network.
At XYZ's San Jose and Sydney sites, the campus layer access switches are Catalyst 6500s with Policy Feature Cards (PFCs). The PFC on the Catalyst 6500 is an important component of the switch QoS functionality because it provides the capability to handle classification and marking in the IP packet at Layer 3, instead of being limited to the Layer 2 CoS values learned from 802.1p. When you are working with a Catalyst 6500 switch without a PFC, or any Layer 2 switch that can perform only Layer 2 CoS marking, you have to rely on distribution and core layer switches that can map Layer 2 CoS values to Layer 3 ToS values accurately.
XYZ is using Catalyst 6500 switches at access, distribution, and core layers, so this section covers the configuration details for Catalyst 6500 switches. The QoS Solution Reference Network Design (SRND) that is available on Cisco.com covers the configuration guidelines for other switches.
Note that the concepts and design principles remain the same regardless of the type of switch deployed in the network. The only difference you notice is in the syntax required to configure the switches.
As mentioned earlier, the classification and honoring of classified packets is an end-to-end process. The first component of this end-to-end topology could be an IP Phone. The Cisco IP Phone sets the Voice over IP (VoIP) traffic (RTP) to CoS 5 and the voice-control traffic (SCCP) to CoS 3.
Access layer switches classify the packets at the edge of the network. This classification helps to identify the type of the packet and special treatment requirements such as priority queuing or routing. IEEE 802.1p is a Layer 2 standard (CoS packet classification methodology) that has the capability to classify packets, as shown in Table 5-5. Figure 5-3 summarizes the QoS configurations that are required at every layer for the XYZ central sites.
Configuration guidelines for the access layer 6500 switches at the central sites are as follows:
Step 1. | Configure access switch ports where IP Phones are connected. The following example shows the Catalyst 6500 access switch configuration, where the ports are configured for inline power, speed, voice, and data VLANs. Refer to Table 5-3, and observe the VLAN IDs and subnets that are configured for voice and data VLANs for the San Jose central site. cat6k-access> (enable) set port inlinepower 3/1-48 auto cat6k-access> (enable) set port speed 3/1-48 auto cat6k-access> (enable) set port host 3/1-48 cat6k-access> (enable) set vlan 111 name SJC_data1 cat6k-access> (enable) set vlan 11 name SJC_voice1 cat6k-access> (enable) set vlan 111 3/1-48 cat6k-access> (enable) set port auxiliaryvlan 3/1-48 11 |
Step 2. | Enable the QoS capabilities switch wide. By default, QoS is disabled on the Catalyst switches. When you enable it by using the following command, all the switch ports are set to an untrusted state. This means that the switch rewrites the CoS, ToS, and DSCP values for all incoming packets to 0. (How to enable trusting is described later in this procedure.) Cat6k-access> (enable) Set qos enable |
Step 3. | Place voice-control traffic in proper output queues. The queuing mechanisms that are available in many Cisco switches and routers provide service guarantees such as less drops and less delay to certain types of traffic (for example, voice traffic). The Catalyst 6500 switch, with its queuing capabilities, can provide preferential treatment to voice traffic. Each port on the switch has a series of input (receive, Rx) and output (transmit, Tx) queues that are used as temporary storage areas for data. A certain amount of buffer space is allotted to each queue to store the data. These queues are implemented in application-specific integrated circuit (ASIC) hardware for each port. The number of queues implemented for each port varies depending on the hardware version of the line card. Note To determine the number of queues supported on a port, on a Catalyst 6500 switch, you can use the show port qos mod/port command, where mod is the module number and port is the port number. The older 10/100 ports on the 6348 line cards used in the Catalyst 6500 switch have a single input queue (Rx queue) with four drop thresholds (1q4t) and two output queues (Tx queue) with two drop thresholds (2q2t). Thresholds define at which point the switch can drop the packets for that queue during the congestion times. Newer line cards have one extra queue each for transmit and receivethus, two input queues (1p1q4t) and three output queues (1p2q2t). These extra queues are special-priority queues (represented by 1p). The switching engine empties the packets in the priority queues before processing the packets in any other queues. This priority queue is especially useful for voice traffic and signaling traffic, which require less delay. When you are designing the QoS in the campus switches, you should always place the voice-bearer traffic and voice-signaling traffic in the queue that has higher preference with a lower drop threshold. The switch uses the CoS value in the Ethernet frame to determine in which queue to place the frame and at what point (threshold) during the congestion to drop the frame. By default, the switch places the voice traffic (RTP traffic, which is marked with CoS 5) coming from the IP Phone in the second output queue in case of 2q2t and in the priority queue in case of 1p2q2t. However, the switch does not put the voice-control traffic in the second output queue in case of 2q2t and into the priority queue in case of 1p2q2t. Manual configuration on the switch is required to accomplish this, as shown in the following example, which illustrates the configuration commands needed to place the voice-control traffic into the second nonpriority queue: cat6k-access> (enable) set qos map 2q2t tx 2 1 cos 3 cat6k-access> (enable) set qos map 1p2q2t tx 2 1 cos 3 |
Step 4. | Map CoS and IP precedence values to the standard DSCP values. When QoS is enabled on the switches, the switch configures a series of default QoS mappings. In its default mappings, the traffic that is marked with CoS 5 and ToS (IP precedence bit value) 5 is mapped to a DSCP value of 40, and traffic that is marked with CoS 3 or ToS 3 is mapped to a DSCP value of 24. The CoS-to-DSCP mapping command and IP precedence-to-DSCP command changes these settings to mark the CoS 5 and ToS 5 traffic with a DSCP value of 46 and to map traffic with CoS 3 and ToS 3 to a DSCP value of 26. The default for video traffic is to map to the DSCP value of 32. However, referring to Table 5-5, the recommended DSCP value for video traffic is 34. Therefore, if you are deploying video in your network, you need to change the value from 32 to 34. The following example shows the configuration commands needed to map CoS-to-DSCP and IP precedence-to-DSCP values: cat6k-access> (enable) set qos cos-dscp-map 0 8 16 26 32 46 48 56 cat6k-access> (enable) set qos ipprec-dscp-map 0 8 16 26 32 46 48 56 |
Step 5. | Apply policies at interfaces that are connected to IP Phones. The following command allows you to apply access control lists (ACLs) of QoS policy based on VLAN. The default action applies ACLs of QoS policy to a port. This command is applicable to switches such as Catalyst 6500 with PFC cards. Cat6k-access> (enable) Set port qos 3/1-48 vlan based Because it is relatively easy for users to change their IP CoS, ToS, and DSCP values on their desktops, you can use the Catalyst QoS features to rewrite these values based on the port's CoS or re-mark the IP CoS, ToS, and DSCP values to 0. By setting the port default CoS value to 0 the following occurs: The Catalyst switch internally assigns a DSCP value of 0 to any inbound frame that is not tagged with an 802.1p CoS value. The trust boundary moves from the Catalyst switch to the IP Phone. The following example shows the configuration command needed to set the PC port to untrusted: Cat6k-access> (enable) Set port qos 3/1-48 trust-ext untrusted This command effectively resets the IP precedence or DSCP values of the packets that are coming from the PC to 0. This approach does not work in scenarios where you are deploying the Cisco IP SoftPhone application on the users' PCs or you need to keep the prioritizations that were set by certain applications running on the user PCs. In these cases, you need to create ACLs on the access layer switches that identify the RTP traffic that is carried in the UDP packets, the signaling traffic that is coming from the PC, and other application traffic and mark it appropriately before sending it to the distribution and core switches. You can optionally enable the policing feature on the switches to limit the amount of traffic allowed per flow, eliminating possible denial of service (DoS) attacks from the user PCs. Refer to the following URL to get a list of TCP/UDP ports used in the CallManager. This information is required while creating the ACLs. http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/products_tech_note09186a00801a62b9.l Because the IP Phones mark the voice-bearer and -signaling traffic appropriately using both CoS and DSCP, the next command configures the switch port to trust the CoS and DSCP values incoming from the IP Phone. The advantage of trusting CoS rather than DSCP is that it enables ingress scheduling on the switch port. The following example shows the configuration command needed to set the switch to "trust" the CoS value coming from the IP Phone ports: Cat6k-access> (enable) Set port qos 3/1-48 trust trust-cos The next command configures the Catalyst 6500 switch to apply CoS 0 to each incoming frame without an 802.1p tag. This command is not visible with a show configuration command because it is the default. Cat6k-access> (enable) Set port qos 3/1-48 cos 0 When you are applying this command, the switch parser might return the following error: >Trust type trust-cos not supported on port(s) 3/1-48 >Receive thresholds enabled on port(s) 3/1-48 >Trust type set to untrusted on port(s) 3/1-48 This error indicates that the switch has activated the four receive thresholds for the input queue (1q4t), and discarding will take place according to the received CoS. However, the line card in the switch does not support trusting the CoS for queuing on the transmit side. As a workaround to this issue, apply an ACL to the voice VLAN to force the Catalyst 6500 switch to trust the CoS settings coming from the IP Phones, as shown in the following example. Note that ACLs specified in this example can be applied only on Catalyst 6500 switches with a supervisory module that has a PFC. Cat6k-access> (enable) set qos acl ip ACL_VOICE_VLAN trust-cos ip any any Cat6k-access> (enable) commit qos acl ACL_VOICE_VLAN Cat6k-access> (enable) set qos acl map ACL_VOICE_VLAN 11 If you do not receive error messages while applying this command, you have new-generation line cards and do not need to apply the ACLs as shown in the example. Refer to the following URL to obtain more information on the line card limitations: http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008014f8a8.l#topic5-3 |
Step 6. | Restore QoS capabilities on interfaces that are connected to distribution switches. You need to restore the port-based QoS capabilities on the access switch interfaces (typically the gigabit links) that are connecting the distribution switch and trust the markings coming from the distribution switches. The following example shows the configuration commands needed to configure uplink ports on access switches: Cat6k-access > (enable) set port qos uplink-Port port-based Cat6k-access > (enable) set port qos uplink-Port trust trust-cos |
Follow these steps to configure the distribution and core layer Catalyst 6500 switches at the central sites:
With the centralized call-processing model, the IP Phones at the remote (branch) sites depend on the central site CallManager under normal operations. During a WAN failure, the voice gateways at the remote sites handle the call-processing requests received from the IP Phones of their respected sites. The Survivable Remote Site Telephony (SRST) feature on the voice gateways provides this functionality. Figure 5-4 shows the IPT network architecture for the Seattle and Melbourne remote sites.
As shown in Figure 5-4, the Seattle and Melbourne sites have two Cisco 3550-24 PWR switches to support 50 and 40 IP Phones, respectively. Cisco 3550-24 PWR switches have 24 inline power ports. The 3745 router at Seattle and Melbourne also has a 16-port Ethernet switch module to support additional phones if required.
Figure 5-5 depicts the remote-site IPT network for the Dallas and Brisbane sites. The Dallas and Brisbane sites use a Cisco 2651XM router as a voice gateway and WAN router.
Every remote-site router of XYZ supports the number of IP Phones required in the SRST mode. The number of IP Phones supported per router depends on the router platform and the amount of physical memory installed on the router. Refer to the following URL to access the SRST data sheet that provides the information on the platform support and the maximum number of devices supported:
http://www.cisco.com/en/US/partner/products/sw/voicesw/ps2169/products_data_sheet09186a00800888acl
The QoS requirements in the LAN at the remote sites are similar to the central site LAN QoS requirements. For smaller remote sites, you can use the low-end LAN switches with fewer capabilities. Therefore, the command syntax for configuring QoS changes slightly. Figure 5-6 summarizes the areas to focus on while configuring the QoS for the remote sites. QoS configuration is required at the LAN switches and the WAN routers.
Remote sites have Catalyst 3550-24 PWR switches. Catalyst 3550 switches have the following queuing characteristics:
The receive interface is one standard FIFO (first-in, first-out) queue (1q-FIFO) for both Fast and Gigabit Ethernet interfaces.
The transmit interface has four queues with two drop thresholds (4q2t) on a Gigabit Ethernet interface. One of the queues can be configured as the priority queue. This is indicated with 1p3q2t (one strict priority queue, three standard queues, and each queue with two configurable drop thresholds). The FastEthernet interface has four queues with no configurable drop thresholds (4q0t). Just like on the Gigabit Ethernet interface, one of the queues can be configured as the priority queue. This is indicated with 1p3q0t.
Note
For 3550 switches, you can use the show interfaces interface-name x/y capabilities command on the switch to see the number of queues that support the interfaces support.
The scheduling algorithm on the switch services the four transmit queues based on the configured Weighted Round Robin (WRR) weights and thresholds. The scheduling algorithm empties the packets waiting in the priority queue before servicing the other queues. The default scheduling policy is WRR.
Table 5-6 summarizes the queues, CoS values, and default queue assignments based on the CoS value on the Ethernet Catalyst 3550 switch. To see the default queue CoS assignments on a 3550 switch, type the command show mls qos interface interface-number queuing.
Queue Number | CoS Value |
|---|---|
4 | 6, 7 |
3 | 4, 5 |
2 | 2, 3 |
1 | 0, 1 |
Queue 4 is the priority queue. The voice-bearer (RTP) packets coming from the IP Phones, which are marked as CoS 5, should be queued into queue 4. The control packets that are marked as CoS 3 should be queued into queue 3. Table 5-7 summarizes the suitable placement of traffic into various queues based on the CoS values for the IPT deployments when using Catalyst 3550 switches.
Queue Number | CoS Value |
|---|---|
4 (priority queue) | 5 |
3 | 3, 4, 6, 7 |
2 | 1, 2 |
1 | 0 |
Note
If your deployment scenario includes other types of switches, check the product documentation and configure the switches to place the packets coming from the IP Phones tagged with CoS 5 in the priority queue. The packets with CoS 3 should be queued one level below the priority queue. This configuration technique ensures that voice packets get priority treatment over untagged packets, resulting in better voice quality in your network.
Remote sites of XYZ are using Cisco 3550-24 PWR switches. The next few sections discuss the required QoS configurations for the remote sites using Cisco 3550-24 PWR switches.
IP Phones at the remote sites connect to Catalyst 3550-24 PWR switches. To enable QoS on the Catalyst 3550 switches that are located in the Seattle site, you must follow these configuration steps:
Note
The configurations of the Catalyst 3550 switches in other remote sites such as Dallas, Brisbane, and Melbourne are similar to Seattle except that you need to put in the right data VLAN and voice VLAN numbers in the configurations.
The Catalyst 3550-24 PWR switches have 24 inline power ports, 23 of which connect to IP Phones. The remaining port connects to the WAN router.
As shown earlier in Table 5-1, the Seattle and Melbourne remote sites have more than 23 IP Phones. Hence, these sites require two switches, providing 46 ports to connect the IP Phones. However, in Seattle, to support 50 IP Phones, extra inline power Ethernet ports are required. A 16-port Ethernet switch module in the Cisco 3745 router in Seattle provides these additional ports. The Ethernet switch module can function as a Layer 2 switch connected to a Layer 3 router.
To configure an IP Phone port on the Ethernet switch module, follow these steps:
Step 1. | Include voice and data VLANs in the VLAN database. With Catalyst 3550 switches, when you configure a port in a VLAN that is not in the switch's VLAN database, the switch automatically adds the VLAN to the database. With Ethernet switch modules, you need to add the VLAN manually to the database. The following example shows the commands that you need to enter the voice and data VLANs manually into the switch's database. R3745-SEA#vlan database R3745-SEA(vlan)#vlan 211 name SEA-DATAVLAN R3745-SEA(vlan)#vlan 21 name SEA-VOICEVLAN |
Step 2. | Select the interface on the router to connect the IP Phones: R3745-SEA(config)#interface FastEthernet0/1-16 |
Step 3. | Set the encapsulation format on the port to 802.1Q. With this format, the router supports simultaneous tagged and untagged traffic on a switch port. R3745-SEA(config-if)#switchport trunk encapsulation dot1q |
Step 4. | Set the native VLAN to send and receive untagged traffic when the interface is in 802.1Q trunking mode. The traffic coming from the PC that is attached to the data port on the back of the IP Phone goes into the native VLAN. R3745-SEA(config-if)#switchport trunk native vlan 211 |
Step 5. | Configure the switch port as a trunk port: R3745-SEA(config-if)#switchport mode trunk |
Step 6. | Configure the voice VLAN: R3745-SEA(config-if)#switchport voice vlan 21 |
Step 7. | Set the switch port to override the priority received from a PC or any other attached device to the IP Phone's switch port: R3745-SEA(config-if)#switchport priority extend cos 0 |
Step 8. | Enable the Port Fast feature on the main interface to disable spanning tree in all its associated VLANs: R3745-SEA(config-if)#spanning-tree portfast |
Based on the detailed discussion in Chapters 1 and 4, the VoIP traffic consists of two unique components:
Bearer or voice (RTP) traffic
Call-control or signaling traffic
The call-control traffic carries the required signaling for call setup, call teardown, and reporting mechanisms. The bearer traffic is the actual voice conversation.
Although VoIP-control (or call-control) traffic can be UDP-based traffic, it is typically TCP-based traffic. VoIP-bearer traffic is always UDP. Because of the unique requirements of UDP and TCP, the network must treat their associated traffic flows differently.
The VoIP-bearer traffic, composed of many small UDP packets, each carrying a vital piece of the voice conversation, must be queued with an absolute minimum probability of drops or delays within the packet network. On the other hand, VoIP-control traffic is not nearly as delay sensitive as bearer traffic and, because it can be retransmitted by TCP if a packet gets lost, can be treated with less strict queuing policies with the network.
Because each type of VoIP traffic requires different treatment, the network elements must have a method of identifying and separating the flows. The most efficient way to achieve this is to combine the use of a Priority Queuing (PQ) scheme with a Class-Based Weighted Fair Queuing (CBWFQ) scheme to guarantee the required bandwidth for delay- and jitter-sensitive traffic, without starving other traffic types. The combination of PQ and CBWFQ mechanisms is known as Low Latency Queuing (LLQ).
Table 5-8 shows the traffic classifications used in the remote sites for various data flows. The voice-bearer traffic has the highest priority, followed by the VoIP-control traffic.
Class Name | DSCP Value |
|---|---|
VoIP-bearer traffic (RTP) | EF (46) |
VoIP-control traffic | AF31 (26) |
Mission-critical data | AF21 (18) |
XYZ also has mission-critical data that requires a higher priority than the other regular data traffic, which is given third priority. In every network, certain data packets are more important and require a higher priority than other, lower-priority data packets. Systems Network Architecture (SNA) protocol traffic is an example of high-priority data traffic, compared to FTP traffic. The low-priority data traffic follows the mission-critical data traffic.
The application of QoS policies requires the following three configuration procedures:
Class map Defines one or more traffic classes by specifying criteria for classifying the traffic
Policy map Defines one or more QoS policies to be applied to the traffic defined in the class maps
Service map Attaches a policy to any specific interface on the router
As depicted in Figure 5-5, designing the QoS on the WAN routers involves three tasks:
Performing DSCP-to-CoS mappings
Mapping COS-to-DSCPmapping on remote-site routers
Configuring WAN interface queuing
As shown in Figures 5-3 and 5-4, the connection between the remote-site routers and remote-site switches is an 802.1Q trunk. The remote-site WAN routers can trust the DSCP value of all incoming packets from the WAN link. WAN routers are responsible for changing the DSCP-to-CoS mappings before they pass the packets to Layer 2 switches. The DSCP-to-CoS mapping is accomplished by class-based marking. This allows the Layer 2 switch to prioritize the traffic appropriately.
Note
Because the LAN switches proposed in case of XYZ, Inc., are Layer 3-aware (Cisco Catalyst 3550 switches), they can trust the DSCP values. Therefore, there is no need to perform the DSCP-to-CoS mappings on the WAN router, as discussed in this section. This step is required only if you have Layer 2 switches (such as the Cisco 29xx series).
Example 5-1 shows the classification of packets by examining the Layer 3 DSCP value. Voice packets have a DSCP value of EF, signaling that traffic packets have a DSCP value of AF31, and mission-critical data packets have a DSCP value of AF21.
class-map match-all VOICE match ip dscp ef class-map match-all VOICE-CONTROL match ip dscp AF31 class-map match-all MISSION-CRITICAL match ip dscp AF21
After you have classified the traffic, use the policy map commands, as shown in Example 5-2, to set the CoS value. Any packet that has a DSCP value of EF will be marked with a CoS of 5, packets that have a DSCP value of AF31 will be marked with a CoS of 3, and the missioncritical data packets that have a DSCP value AF21 will be marked as CoS 2.
policy map DSCP2COS-VOICE class VOICE set cos 5 class VOICE-CONTROL set cos 3 policy map DSCP2COS-DATA class MISSION-CRITICAL set cos 2
The class map and policy maps are not effective until they are attached to the voice and data subinterface. In this case, the policy map attaches to the voice and data, as shown in Example 5-3.
interface fastethernet 0/0.21 ! Subinterface for the voice subnet for Seattle remote site service-policy output DSCP2COS-VOICE interface fastethernet 0/0.211 Subinterface for data subnet for Seattle remote site service-policy output DSCP2COS-DATA
The remote-site WAN routers must set the DSCP values for the incoming packets from the LAN switches before sending them out on the WAN link. The classification of packets shown in Table 5-8 is used.
Example 5-4 shows the classification of packets by examining the Layer 2 CoS values. Voice packets coming from the IP Phones have a CoS value of 5, and signaling traffic packets have a CoS value of 3. The mission-critical data packets are matched against an access list, because the data applications cannot set the CoS value to 2. Hence, you use the extended access list to identify the mission-critical traffic.
Note
In Example 5-4, an extended access list identifies the mission-critical data. In your network, you can add more access list statements with varying criteria to match your traffic prioritization needs.
! Matching all voice-bearer traffic coming from the IP Phones class-map match-all COS5 match cos 5 ! Matching all voice-control traffic coming from the IP Phones class-map match-all COS3 match cos 3 ! Matching all mission-critical data based on the access list class-map match-all COS2 match access-group 101 ! Applying the access list according to mission-critical data criteria access list 101 permit tcp any host 10.2.11.5 eq 80 access list 101 permit tcp 10.2.11.0 0 0.0.0.255 host 10.1.1.1 eq 80
After you have classified the traffic, use the policy map commands, as shown in Example 5-5, to set the DSCP values. Packets that have a CoS value of 5 are marked with a DSCP value of EF, packets that have a CoS value of 3 are marked with a DSCP value of AF31, and mission-critical data packets that have a CoS value of 2 are marked as DSCP value AF21.
policy map COS2DSCP-VOICE class EF set dscp ef class AF31 set dscp af31 policy map COS2DSCP-DATA class AF21 set dscp af21
The final step is to attach the policy map to the voice and data subinterface, as shown in Example 5-6.
interface fastethernet 0/0.21 service-policy input COS2DSCP-VOICE interface fastethernet 0/0.211 service-policy input COS2DSCP-DATA
On the WAN edge router (the WAN aggregator router at the central sites and the WAN router at the remote sites), voice traffic needs to be assigned to an LLQ, and voice-control traffic needs to get a minimum bandwidth guarantee by using CBWFQ mechanisms.
Referring to Table 4-4 in Chapter 4, you see that the G.729a codec requires approximately 30 kbps (26.4 kbps with PPP as the Layer 2 protocol) of bandwidth per call. XYZ is using a G.711 codec for fax calls, which consumes approximately 90 kbps (82.4 kbps with PPP as the Layer 2 protocol). Keeping these values in mind, Figure 5-1, the Seattle site is connected to the San Jose site via a 1-Mbps Frame Relay circuit (high-speed link), and the Dallas site is connected via a 512-Kbps Frame Relay circuit. The San Jose central site connects to the service provider network with a 1.5-Mbps link. Because there is a mismatch between the link bandwidths of the central and remote sites, Frame Relay Traffic Shaping (FRTS) is required to send the traffic at a consistent rate.
You need to configure the links with the following values:
Committed Burst Rate Bc = CIR (Committed Information Rate) /100
Excess Burst Rate Be = 0
Minimum CIR (mincir) = CIR
Chapter 4, in the "Serialization Delay" section, regarding link fragmentation and interleaving (LFI) and traffic shaping. Because the link from Seattle to San Jose is a high-speed link, you do not need LFI. However, traffic shaping is required because of the mismatch of link speeds at remote and central sites. Example 5-7 shows the configuration of the Seattle router.
interface Serial0/1 ! Interface connected to WAN link on Seattle router no ip address encapsulation frame-relay frame-relay traffic-shaping ! This command enables FRTS on the main interface. interface Serial0/1.50 point-to-point ! FR link to San Jose from Seattle bandwidth 1000 ip address 10.200.10.1 255.255.255.252 frame-relay interface-dlci 250 class FRTS-1000kbps ! This command applies the FRTS map-class to the DLCI. map-class frame-relay FRTS-1000kbps frame-relay cir 1000000 frame-relay bc 10000 frame-relay be 0 frame-relay mincir 1000000 no frame-relay adaptive-shaping service-policy output Remote-WAN-EDGE ! This command applies the MQC policy to the FRTS map-class. policy map Remote-WAN-Edge class VOICE priority ValueVoicefax class VOICE-CONTROL bandwidth ValueVoiceControl class MISSION-CRITICAL bandwidth ValueMissionCritical Class Class-default Fair-queue
The same classes that were used for DSCP-to-CoS mapping are used again for WAN interface queuing. Refer to Table 5-9 for the bandwidth values for ValueVoicefax, ValueVoiceControl, and ValueMissionCritical in the Seattle branch.
The Dallas site connects to the service provider via a Frame Relay link, and the San Jose site connects to the service provider via an ATM link. The conversion between ATM and Frame Relay is accomplished through Frame Relay-to-ATM Service Interworking (described in the FRF.8 [Frame Relay Forum] implementation agreement) in the carrier network. Because the link between the Dallas and San Jose sites is a low-speed link (512 Kbps), you need to use LFI to fragment the large packets to ensure that voice packets do not experience delay. Multilink PPP (MLPPP) over the ATM to Frame Relay LFI mechanism will be deployed. Figure 4-13 shows the LFI process and serialization delay matrix.
interface Serial0/1 ! Interface connected to WAN link on Dallas router no ip address encapsulation frame-relay frame-relay traffic-shaping ! This command enables FRTS on the main interface. interface Serial0/1.51 point-to-point description FR Link to San Jose from Dallas bandwidth 512 frame-relay interface-dlci 251 ppp virtual-template51 class FRTS-512kbps ! This command applies the FRTS map-class to the DLCI. interface Virtual-Template51 bandwidth 512 ip address 10.200.60.1 255.255.255.252 service-policy output Remote-WAN-EDGE ! This command applies the MQC policy to the FRTS map-class. ! The service policy is applied to the virtual template ppp multilink ppp multilink fragment-delay 10 ppp multilink interleave map-class frame-relay FRTS-512kbps frame-relay cir 512000 frame-relay bc 5120 frame-relay be 0 frame-relay mincir 512000 no frame-relay adaptive-shaping class VOICE priority ValueVoicefax class VOICE-CONTROL bandwidth ValueVoiceControl class MISSION-CRITICAL bandwidth ValueMissionCritical Class Class-default Fair-queue
Using Voice Compression" section of Chapter 4. Because sufficient bandwidth exists to send the required number of voice calls on the WAN link, you do not need to enable cRTP on the Dallas router.
Note
The Brisbane and Melbourne router configuration is similar to that of the Dallas router. Look at Table 5-10 for the appropriate values for ValueVoicefax, ValueVoiceControl, and ValueMissionCritical.
According to Figure 5-1, the San Jose site WAN router has an IMA (Inverse Multiplexing of ATM) card to connect to the service provider network via ATM at 1.5 Mbps. The remote sites connect to the service provider via Frame Relay links. The conversion between ATM and FR and vice versa is done in the carrier network using the FRF.8 standard.
The configurations for the LAN switches described earlier for the San Jose site correctly classify and mark the voice-bearer packets, call-control packets, and mission-critical data packets. Hence, on the WAN routers at the central sites, you need to classify the packets based on the received DSCP values and give the priority using the LLQ.
! The class map "VOICE" matches on all packets with the DSCP value of EF. class-map match-all VOICE match ip dscp ef ! The class map "VOICE-CONTROL" matches on all packets with the DSCP ! value of AF31. class-map match-all VOICE-CONTROL match ip dscp af31 ! The class map "MC-DATA" matches on all packets with the DSCP value of ! AF21. class-map match-all MC-DATA match ip dscp af21 ! Policy map for packets going to "WAN-EDGE-Seattle" policy map WAN-EDGE-Seattle ! For all packets that previously matched on class-map "VOICE" for ! having a DSCP value of EF, 390 kbps is allocated to the priority queue. class VOICE priority 390 ! For all packets that previously matched on class-map "VOICE-CONTROL" ! for having a DSCP value of AF31, 10 kbps bandwidth is allocated to ! this waited fair queue (WFQ). class VOICE-CONTROL bandwidth 10 ! For all packets that previously matched on class-map "MC-DATA" ! for having DSCP value of AF21, 200 kbps is allocated to the priority queue. class MC-DATA bandwidth 200 ! All other traffic is matched to "class-default" and it will be ! treated by a fair queue. class class-default fair-queue random-detect dscp-based ! Policy map for packets going to "WAN-EDGE-Dallas" policy map WAN-EDGE-Dallas ! For all packets that previously matched on class-map "VOICE" for ! having a DSCP value of EF, 210 Kbps is allocated to the priority queue. class VOICE priority 210 ! For all packets that previously matched on class-map "VOICE-CONTROL" ! for having a DSCP value of AF31, 10 Kbps is allocated to this ! waited fair queue (WFQ). class VOICE-CONTROL bandwidth 10 ! For all packets that previously matched on class-map "MC-DATA" ! for having a DSCP value of AF21, 100 Kbps bandwidth is allocated to ! this waited fair queue (WFQ). class MC-DATA bandwidth 100 ! All other traffic is matched to "class-default" and will be ! treated by a fair queue. class class-default fair-queue random-detect dscp-based policy map WAN-EDGE-Sydney class VOICE bandwidth 536 class VOICE-CONTROL bandwidth 30 class MC-DATA bandwidth 500 class class-default fair-queue random-detect dscp-based interface ATM3/0 no ip address no atm ilmi-keepalive interface ATM3/0.60 point-to-point pvc DALLAS 0/60 vbr-nrt 512 512 tx-ring-limit 10 protocol ppp Virtual-Template60 interface Virtual-Template60 bandwidth 512 ip address 10.200.60.2 255.255.255.252 service-policy output WAN-EDGE-Dallas ppp multilink ppp multilink fragment-delay 10 ppp multilink interleave interface ATM3/0.61 point-to-point pvc SEATTLE 0/61 vbr-nrt 1000 1000 tx-ring-limit 28 ip address 10.200.10.2 255.255.255.252 service-policy output WAN-EDGE-Seattle
Note
The Sydney router configuration is similar to that of the San Jose router.