Cisco.IP.Telephony.Planning.Design.Implementation.Operation.and.Optimization [Electronic resources] نسخه متنی

Network Infrastructure Design Tasks

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.

Designing IP Addressing and VLAN Scheme

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.

Table 5-3. VLAN/Subnet Assignment for XYZ 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
Seattle	211	SEA_data1	10.2.11.0/24	User PCs
Dallas	31	DAL_voice1	10.3.1.0/24	IP Phones
Dallas	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
Melbourne	511	MEL_data1	10.5.11.0/24	User PCs
Brisbane	61	BRI_voice1	10.6.1.0/24	IP Phones
Brisbane	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.

Designing DHCP and TFTP Services

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.

Central Site LAN Infrastructure

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.

Figure 5-2. XYZ IPT LAN Architecture at Central Sites

[View full size image]

Central Site LAN QoS Design

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.

Table 5-5. Traffic Classification Recommendations
Traffic Type	Layer 2 COS	Layer 3 IP Precedence	Layer 3 DSCP (PHB)
Voice RTP^[1]	5	5	46 (EF^[2])
Voice control (SCCP^[3], H.323, MGCP^[4])	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.

Access Layer Catalyst 6500 QoS Configuration Guidelines

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.

Figure 5-3. XYZ IPT LAN QoS Configuration Summary

[View full size image]

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.shtml

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.shtml#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

Distribution and Core Layer Catalyst 6500 QoS Configuration Guidelines

Follow these steps to configure the distribution and core layer Catalyst 6500 switches at the central sites:

Step 1.

Enable QoS switch wide:


Cat6k-dist> (enable) Set qos enable

Step 2.

Place the voice-control traffic into queue 2, as discussed in the previous section:


cat6k-dist> (enable) set qos map 1p2q2t tx 2 1 cos 3
cat6k-dist> (enable) set qos map 2q2t tx 2 1 cos 3

Step 3.

Map CoS and IP precedence values to the standard DSCP values:


cat6k-dist> (enable) set qos cos-dscp-map 0 8 16 26 32 46 48 56
cat6k-dist> (enable) set qos ipprec-dscp-map 0 8 16 26 32 46 48 56

Step 4.

Configure the interfaces that connect to CallManager servers.

CallManager sets the DSCP value to 46 (ToS 5/PHB EF) for bearer (RTP) traffic (streaming music files, conference bridge streams, and so forth). It also sets the DSCP value to 26 (ToS 3/PHB AF31) for all VoIP-control traffic (such as SCCP, H.323, and MGCP). However, CallManager does not use 802.1q Layer 2 encapsulation.

To ensure that the packets leaving the CallManager are set to the right value, you should configure the switch port connecting to CallManager servers to trust the DSCP/IP precedence. However, due to current limitations on the Catalyst 6500 switch, as explained in Step 5 of the preceding section, the port trust state on 10/100 ports cannot be set to trust-dscp or trust-ipprec. As a workaround, you need to configure a QoS ACL that trusts DSCP and map the ACL to the CallManager port. The following example shows how to configure QoS settings for ports that connect to CallManager servers:


cat6k-dist> (enable) set port qos CM-port trust trust-dscp
! Use the above command if you are using new generation line cards; otherwise,
! use the ACLs as described below. If you use the above command on older      
! line cards, returns an error message "Trust type trust-dscp not             
! supported on this port"                                                     
cat6k-dist> (enable) set port qos CM-port port-based
cat6k-dist> (enable) set qos acl ip ACL_TRUST_DSCP trust-dscp ip any any
cat6k-dist> (enable) commit qos acl ACL_TRUST_DSCP
cat6k-dist> (enable) set qos acl map ACL_TRUST_DSCP CM-port
! The above command maps the ACL named TRUST_DSCP to the CallManager Port.    
! CM-Port is the port number where the CallManager server is connected.

Step 5.

Connect the interfaces to the voice gateways.

CallManager, Cisco H.323, MGCP voice gateways, and VG248 gateways can set IP precedence and DSCP values for VoIP-control and bearer traffic. However, because of the same limitations discussed in Step 5 in the preceding section, you should use the ACLs to trust the markings made by the voice gateways.

The following example shows the QoS configurations needed on switch ports connecting to voice gateways at the central site:


cat6k-dist> (enable) set port qos VoIPGW-port trust trust-dscp
! Use the above command if you are using new generation line cards; otherwise,
! use the ACLs as described below. If you use the above command on older line 
! cards, it returns an error message "Trust type trust-dscp not supported on  
! this port"                                                                  
cat6k-dist> (enable) set port qos VoIPGW-port port-based
cat6k-dist> (enable) set qos acl ip ACL_TRUST_DSCP trust-dscp ip any any
cat6k-dist> (enable) commit qos acl ACL_TRUST_DSCP
cat6k-dist> (enable) set qos acl map ACL_TRUST_DSCP VoIPGW-port
! VoIPGW-Port is the port number where the VoIP gateways are connected.

Most of the Cisco voice gateways set the DSCP and IP precedence values for call-control signaling and media (bearer) packets. If you have voice gateways in your network that cannot set the DSCP and IP precedence values for the bearer and call-control traffic, you can use extended access lists to match the packets carrying this type of traffic and rewrite the DSCP and IP precedence values.

Step 6.

Connect the interfaces to the WAN routers.

This step discusses the configuration needed on the switch ports of the Cisco Catalyst switches that connect to the WAN aggregator routers at the central sites. Configure the ports to trust the DSCP values set by the other routers and switches at the remote sites. If the remote site routers or switches do not set the DSCP value, you need to classify and mark DSCP values for the incoming packets at the WAN aggregation router. The following example shows how to configure trust for the ports of the central site connecting to WAN routers at the central site:


cat6k-dist> (enable) set port qos WAN-port trust trust-dscp
! Use the above command if you are using new generation line cards; otherwise,
! use the ACLs as described below. If you use the above command on older line 
! cards it returns an error message "Trust type trust-dscp not supported on   
! this port"                                                                  
cat6k-dist> (enable) set port qos WAN-port port-based
cat6k-dist> (enable)  set qos acl ip ACL_TRUST_WAN trust-dscp any
cat6k-dist> (enable)  commit qos acl ACL_TRUST_WAN
cat6k-dist> (enable)  set qos acl map ACL_TRUST_WAN WAN-port
! Where WAN-port is the port number where the WAN router(s) are connected

Step 7.

Configure unused switch ports.

The distribution and core switches are not supposed to connect any IP Phone or any other device that might affect the QoS configuration. The CoS and ToS values for the switch ports that are in a not-connected state or ports connecting to unknown or untrusted devices should have their CoS and ToS values rewritten to 0. The following example shows the unused switch port configurations:


cat6k-dist> (enable) set port qos unused-ports port-based
cat6k-dist> (enable) set port qos unused-ports untrusted
! By default, all ports are in the untrusted state when QoS is enabled.

Remote-Site IPT Infrastructure

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.

Figure 5-4. Remote-Site IPT Architecture: Seattle and Melbourne

[View full size image]

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.

Figure 5-5. Remote-Site IPT Architecture: Dallas and Brisbane

[View full size image]

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

Remote-Site LAN QoS Design

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.

Figure 5-6. Remote-Site QoS Configuration Guidelines

[View full size image]

Configuring the Remote-Site LAN Switches for QoS

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.

Table 5-6. Values for Layer 2 QoS
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.

Table 5-7. Queue Assignments Based on CoS Values for the Catalyst 3550 Switch
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.

Configuring Catalyst 3550 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:

Step 1.

Enable QoS globally on the Catalyst 3550 switch:


S3550(config)#mls qos

Step 2.

Modify the default CoS-to-DSCP mapping:


S3550(config)#mls qos map cos-dscp 0 8 16 26 34 46 48 56

Step 3.

Modify the default DSCP-to-CoS mapping:


S3550(config)#mls qos map dscp-cos 0 8 16 26 34 46 48 56

Step 4.

Turn on priority queuing (which is disabled by default) on the switch interfaces that connect the IP Phones:


S3550(config)# interface range fastethernet 0/2 - 24
S3550(config-if-range)#priority-queue out

Step 5.

Place the CoS 5 traffic into the priority queue, which is queue 4, and the CoS 3 traffic into queue 3. Note that CoS 6 and CoS 7 value packets are placed in queue 4, and CoS 4 value packets are placed in queue 3.


S3550(config)# interface range fastethernet 0/2 - 24
S3550(config)# no shutdown
S3550(config)# duplex auto
S3550(config-if-range)#wrr-queue cos-map 1 0
R3550(config-if-range)#wrr-queue cos-map 2 1 2
S3550(config-if-range)#wrr-queue cos-map 3 3 4 6 7
! Placing the CoS 3 traffic into queue 3. CoS 4 value packets are     
! also placed in queue 3.                                             
S3550(config-if-range)#wrr-queue cos-map 4 5
! Placing the CoS 5 traffic into the priority queue, which is queue 4.
! CoS 6 and CoS 7 values packets are also placed in queue 4.

Step 6.

Enable QoS features on the switch ports connecting the IP Phones:


S3550(config)# interface range fastethernet 0/2 - 24
! Select the interfaces where the IP Phones are connected             
S3550(config-if-range)# mls qos trust cos
! Trusts the CoS values set by the IP phone                           
S3550(config-if-range)#switchport voice vlan 21
! Create the Voice VLAN 21                                            
S3550(config-if-range)#switchport access vlan 211
! Create the Data VLAN 211                                            
S3550(config-if-range)#switchport priority extend cos 0
! Untrust the PC port located in the IP phone                         
S3550(config-if-range)#spanning-tree portfast
! Disable the spanning tree cycles and bring the port to              
! forwarding state immediately

Step 7.

Enable QoS features for uplink. In all the branches, the Catalyst 3550 switches connect to the WAN routers. Because the incoming traffic from the central sites has been set with the correct DSCP values, you can configure the uplink switch port connecting to the WAN router at the branch to trust the incoming traffic markings. The following example shows the uplink configurations required on the Catalyst 3550 switch. Here the WAN router is connected to the FastEthernet 0/1 port on the Catalyst 3550 switch.


S3550(config)# interface fastethernet 0/1
! Interface connecting to the WAN router                              
S3550(config)# no shutdown
S3550(config)# priority-queue out
S3550(config-if)#wrr-queue cos-map 1 0
R3550(config-if)#wrr-queue cos-map 2 1 2
S3550(config-if)#wrr-queue cos-map 3 3 4 6 7
S3550(config-if)#wrr-queue cos-map 4 5
S3550(config-if)#mls qos trust dscp
! Trust the DSCP markings coming from the WAN router                  
S3550(config-if)#switch port mode trunk
! Configure the port connected to the WAN router as a trunk port      
S3550(config-if)#switch port trunk encapsulation dot1q
! Configure the trunk as an IEEE 802.1Q trunk

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.

Configuring the Ethernet Switch Module on the Cisco 3745 Router

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

Remote-Site WAN QoS Design

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.

Table 5-8. Traffic Classification for Remote Sites
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

Perform DSCP-to-CoS Mappings

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.

Example 5-1. Classifying the Packets Based on Incoming DSCP Values


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.

Example 5-2. Setting the CoS Values


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.

Example 5-3. Attaching the Policy Map to an Interface


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

Map CoS-to-DSCP Mapping on Remote-Site Routers

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.

Example 5-4. Classifying the Packets Based on Incoming CoS Values


! 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.

Example 5-5. Setting the DSCP Values


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.

Example 5-6. Attach the Service Policy to the Voice and Data Voice and Data Subinterfaces


interface fastethernet 0/0.21
service-policy input COS2DSCP-VOICE
interface fastethernet 0/0.211
service-policy input COS2DSCP-DATA

Configure WAN Interface Queuing

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.

Voice and FAX Bandwidth Calculations

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 B_c = CIR (Committed Information Rate) /100

Excess Burst Rate B_e = 0

Minimum CIR (mincir) = CIR

Seattle Router WAN Queuing and Traffic Shaping

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.

Example 5-7. Seattle Router Configuration


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.

Dallas Router WAN Queuing and Traffic Shaping

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.

Example 5-8. Dallas Router Configuration


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.

Central Site WAN QoS Design

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.

Example 5-9. San Jose WAN Router Configuration


! 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.

Cisco.IP.Telephony.Planning.Design.Implementation.Operation.and.Optimization [Electronic resources] نسخه متنی

Network Infrastructure Design Tasks

Designing IP Addressing and VLAN Scheme

Table 5-3. VLAN/Subnet Assignment for XYZ Network

Designing DHCP and TFTP Services

Central Site LAN Infrastructure

Figure 5-2. XYZ IPT LAN Architecture at Central Sites

Central Site LAN QoS Design

Table 5-5. Traffic Classification Recommendations

Access Layer Catalyst 6500 QoS Configuration Guidelines

Figure 5-3. XYZ IPT LAN QoS Configuration Summary

Distribution and Core Layer Catalyst 6500 QoS Configuration Guidelines

Remote-Site IPT Infrastructure

Figure 5-4. Remote-Site IPT Architecture: Seattle and Melbourne

Figure 5-5. Remote-Site IPT Architecture: Dallas and Brisbane

Remote-Site LAN QoS Design

Figure 5-6. Remote-Site QoS Configuration Guidelines

Configuring the Remote-Site LAN Switches for QoS

Table 5-6. Values for Layer 2 QoS

Table 5-7. Queue Assignments Based on CoS Values for the Catalyst 3550 Switch

Configuring Catalyst 3550 Switches

Configuring the Ethernet Switch Module on the Cisco 3745 Router

Remote-Site WAN QoS Design

Table 5-8. Traffic Classification for Remote Sites

Perform DSCP-to-CoS Mappings

Example 5-1. Classifying the Packets Based on Incoming DSCP Values

Example 5-2. Setting the CoS Values

Example 5-3. Attaching the Policy Map to an Interface

Map CoS-to-DSCP Mapping on Remote-Site Routers

Example 5-4. Classifying the Packets Based on Incoming CoS Values

Example 5-5. Setting the DSCP Values

Example 5-6. Attach the Service Policy to the Voice and Data Voice and Data Subinterfaces

Configure WAN Interface Queuing

Voice and FAX Bandwidth Calculations

Seattle Router WAN Queuing and Traffic Shaping

Example 5-7. Seattle Router Configuration

Dallas Router WAN Queuing and Traffic Shaping

Example 5-8. Dallas Router Configuration

Central Site WAN QoS Design

Example 5-9. San Jose WAN Router Configuration