Note:
Following templates are coming from Cisco documentation as Cisco recommends. However you may have to tweak or adjust certain settings in order to meet your specific needs.

LAN Quality of Service Templates

Overview

The purpose of this document is to outline the local area network (LAN) quality of service templates that will be implemented by you Unified Communications engineers. This document contains basic configuration details that should be followed during any UC deployment. The configurations contained within this document are based on Ciscos Quality of Service SRND and Unified Communications Manager SRND. For a comprehensive list of configuration details, reference the Cisco Quality of Service SRND and Cisco Unified Communications Manager SRND.

The configurations in this document should be considered as the base line for any implementation and should be included in any implementation as part of the standard delivery process. LAN traps should be conducted after implementing the QoS to ensure that proper markings are being set and maintained throughout the enterprise.

The following devices are covered in this FAQ
* Catalyst 3550 Switches
* Catalyst 2960/2970/3560/3750 Switches
* Catalyst 4500 Switches with Native IOS up to Supervisor Engine 7E
* Catalyst 6500 Switches with Native IOS

Markings

The following markings are used to designate traffic, per the Cisco SRND. These are the markings that you will account for in the base professional services implementation pricing.


Soft Clients

When IP Phones are deployed in conjunction with other soft clients, such as CIPC, CUVA, or CUPC, then it is important to ensure the proper marking of soft client UC traffic. This is accomplished through the use of access lists and service policies.

The voice component of a call can be classified in one of two ways, depending on the type of call in progress. A voice-only (or normal) telephone call would have the media classified as CoS 5 (IP Precedence 5 or PHB EF), while the audio channel of a video conference would have the media classified as CoS 4 (IP Precedence 4 or PHB AF41). All the Cisco IP Video Telephony products adhere to the Cisco Corporate QoS Baseline standard, which requires that the audio and video channels of a video call both be marked as CoS 4 (IP Precedence 4 or PHB AF41). The reasons for this recommendation include, but are not limited to, the following:
* To preserve lip-sync between the audio and video channels
* To provide separate classes for audio-only calls and video calls

Cisco Unified Personal Communicator and Cisco IP Communicator with Cisco Unified Video Advantage are both voice and video capable, which presents two challenges when using the ACL and policy map for packet classification and DSCP re-marking. First, Cisco Unified Personal Communicator uses the same IP address and UDP port range to source voice and video streams. The ACL that is based on IP address and port number is not granular enough to differentiate a voice call from a video call in order to apply appropriate DSCP re-marking. Second, Cisco IP Communicator uses the same IP address and UDP port range to source its voice packets. Similarly, the ACL is not granular enough to differentiate the voice stream of an audio-only call from the voice stream of a video call. Therefore, using the ACL and policy-map for packet classification and DSCP re-marking is not a feasible QoS solution for software-based endpoints.

Because both Cisco Unified Personal Communicator and Cisco IP Communicator with Cisco Unified Video Advantage mark their signaling and media packets correctly as they ingress the network, Cisco recommends configuring the policy map to trust the DSCP marking of incoming traffic and apply traffic policing and rate limiting.

1. Catalyst 3550

The Catalyst 3550 switch mode is generally found in the access layer of the LAN. This model supports a 1P3Q1T queuing model.

Global Commands

These commands are entered on a global level and are necessary in all QoS implementations. They are used to properly map COS and DSCP values as well as to associate these markings with the appropriate interface queue and threshold.


Trunk Port Commands

Trunk ports, which could include connections to other switches, as well as Dot1Q connections to routers, should be configured to trust the DSCP markings from the neighboring device.


Voice Servers, WAN Routers, Gateways

Generally speaking, devices such as voice servers, WAN routers, and voice gateways can be trusted, similar to trunk ports.


IP Phones without Soft Clients

When IP Phones are deployed in an environment without other soft clients such as CIPC, CUVA, or CUPC, then the configuration for these access ports can be to simply trust the COS of the IP Phones. If a client will have any soft clients in the enterprise, it is recommended that you follow the configuration template for IP Phones with Soft clients as it is not feasible to know exactly which ports may or may not have soft clients active.


IP Phones with Soft Clients

Because both Cisco Unified Personal Communicator and Cisco IP Communicator with Cisco Unified Video Advantage mark their signaling and media packets correctly as they ingress the network, Cisco recommends configuring the policy map to trust the DSCP marking of incoming traffic and apply traffic policing and rate limiting. It should be noted that this document includes IP Phone control traffic for SCCP, Secure SCCP, and SIP implementations.

The client can elect to add additional classes for other applications that fall into the Bulk, Transactional, or Interactive classes such as Oracle, FTP, etc by configuring additional ACLs and class-maps. You will be creating classes for voice and video. All other traffic not included in these classes will be policed at 5Mbps. This helps protect the environment from DoS attacks, and will not affect legitimate traffic.

Policers

Since we are going to be marking traffic from PCs to higher classes within the QoS policies, we need to ensure that we do not open the infrastructure up to a DoS attack from these PCs by allowing them to transmit more data than necessary in each class. This is done with policers. By policing unexpected packets to DSCP 8 (scavenger), we have made excessive packets with policed markings a lower priority than 0.


Access Lists

Access lists (ACLs) are used to properly identify traffic that will need to be marked at the point of ingress. These ACLs will deviate from LAN segment to LAN segment, as both the voice VLAN and data VLAN may differ from location to location within a deployment.


Class-Maps

Class-Maps are created to place the traffic identified by the access lists into the appropriate QoS classes. The 3550 switch can classify based on VLAN ID, so hierarchy classes are utilized for this switch. In the following example, VV refers to the Voice VLAN ID.


Policy-Maps

Policy-Maps are created in order to take action on traffic within a class. In these examples, the policers assume that the voice only calls will use G.711 and that video calls will not exceed 384k. If a voice codec with a higher bandwidth was used, such as G.722, the policer for the voice class would need to be altered to 320k, instead of 128k.


IP Phone and PC Ports

In order to enforce the classifications and policies, the policy-map must be applied to the ingress of all IP Phone and PC ports.


2. Catalyst 2960/2970/3560/3750

These Catalyst switch models are generally found in the access layer of the LAN, although in some deployments, the 3750 is used in the distribution level. These models support a 1P3Q3T queuing model.

Global Commands

These commands are entered on a global level and are necessary in all QoS implementations. They are used to properly map COS and DSCP values as well as to associate these markings with the appropriate interface queue and threshold.


Trunk Port Commands

Trunk ports, which could include connections to other switches, as well as Dot1Q connections to routers, should be configured to trust the DSCP markings from the neighboring device.


Voice Servers, WAN Routers, Gateways

Generally speaking, devices such as voice servers, WAN routers, and voice gateways can be trusted, similar to trunk ports.

IP Phones without Soft Clients

When IP Phones are deployed in an environment without other soft clients such as CIPC, CUVA, or CUPC, then the configuration for these access ports can be to simply trust the COS of the IP Phones. If a client will have any soft clients in the enterprise, it is recommended that you follow the configuration template for IP Phones with Soft clients as it is not feasible to know exactly which ports may or may not have soft clients active.


IP Phones with Soft Clients

Because both Cisco Unified Personal Communicator and Cisco IP Communicator with Cisco Unified Video Advantage mark their signaling and media packets correctly as they ingress the network, Cisco recommends configuring the policy map to trust the DSCP marking of incoming traffic and apply traffic policing and rate limiting. It should be noted that this document includes IP Phone control traffic for SCCP, Secure SCCP, and SIP implementations.

The client can elect to add additional classes for other applications that fall into the Bulk, Transactional, or Interactive classes such as Oracle, FTP, etc by configuring additional ACLs and class-maps. You will be creating classes for voice and video. All other traffic not included in these classes will be policed at 5Mbps. This helps protect the environment from DoS attacks, and will not affect legitimate traffic.

Policers

Since we are going to be marking traffic from PCs to higher classes within the QoS policies, we need to ensure that we do not open the infrastructure up to a DoS attack from these PCs by allowing them to transmit more data than necessary in each class. This is done with policers. By policing unexpected packets to DSCP 8 (scavenger), we have made excessive packets with policed markings a lower priority than 0.


Access Lists

Access lists (ACLs) are used to properly identify traffic that will need to be marked at the point of ingress. These ACLs will deviate from LAN segment to LAN segment, as both the voice VLAN and data VLAN may differ from location to location within a deployment.


Class-Maps

Class-Maps are created to place the traffic identified by the access lists into the appropriate QoS classes. A class-map is created for each traffic type for which an ACL was created.


Policy-Maps

Policy-Maps are created in order to take action on traffic within a class. In these examples, the policers assume that the voice only calls will use G.711 and that video calls will not exceed 384k. If a voice codec with a higher bandwidth was used, such as G.722, the policer for the voice class would need to be altered to 320k, instead of 128k.


IP Phone and PC Ports

In order to enforce the classifications and policies, the policy-map must be applied to the ingress of all IP Phone and PC ports.


3. Catalyst 4500 Sup II to Sup IV

These Catalyst switch models can be found in the access, distribution, or core layers of the LAN. These models support a 1P3Q1T queuing model.

Global Commands

These commands are entered on a global level and are necessary in all QoS implementations. They are used to properly map COS and DSCP values as well as to associate these markings with the appropriate interface queue and threshold.


Trunk Port Commands

Trunk ports, which could include connections to other switches, as well as Dot1Q connections to routers, should be configured to trust the DSCP markings from the neighboring device.

Fast Ethernet


Gigabit Ethernet


Voice Servers, WAN Routers, Gateways

Generally speaking, devices such as voice servers, WAN routers, and voice gateways can be trusted, similar to trunk ports.

Fast Ethernet


Gigabit Ethernet


IP Phones without Soft Clients

When IP Phones are deployed in an environment without other soft clients such as CIPC, CUVA, or CUPC, then the configuration for these access ports can be to simply trust the COS of the IP Phones. If you will have any soft clients in the enterprise, it is recommended that you follow the configuration template for IP Phones with Soft clients as it is not feasible to know exactly which ports may or may not have soft clients active.

Fast Ethernet


Gigabit Ethernet


IP Phones with Soft Clients

Because both Cisco Unified Personal Communicator and Cisco IP Communicator with Cisco Unified Video Advantage mark their signaling and media packets correctly as they ingress the network, Cisco recommends configuring the policy map to trust the DSCP marking of incoming traffic and apply traffic policing and rate limiting. It should be noted that this document includes IP Phone control traffic for SCCP, Secure SCCP, and SIP implementations.

You can elect to add additional classes for other applications that fall into the Bulk, Transactional, or Interactive classes such as Oracle, FTP, etc by configuring additional ACLs and class-maps. You will be creating classes for voice and video. All other traffic not included in these classes will be policed at 5Mbps. This helps protect the environment from DoS attacks, and will not affect legitimate traffic.

Policers

Since we are going to be marking traffic from PCs to higher classes within the QoS policies, we need to ensure that we do not open the infrastructure up to a DoS attack from these PCs by allowing them to transmit more data than necessary in each class. This is done with policers. By policing unexpected packets to DSCP 8 (scavenger), we have made excessive packets with policed markings a lower priority than 0.


Access Lists

Access lists (ACLs) are used to properly identify traffic that will need to be marked at the point of ingress. These ACLs will deviate from LAN segment to LAN segment, as both the voice VLAN and data VLAN may differ from location to location within a deployment.


Class-Maps

Class-Maps are created to place the traffic identified by the access lists into the appropriate QoS classes. A class-map is created for each traffic type for which an ACL was created.


Policy-Maps

Policy-Maps are created in order to take action on traffic within a class. In these examples, the policers assume that the voice only calls will use G.711 and that video calls will not exceed 384k. If a voice codec with a higher bandwidth was used, such as G.722, the policer for the voice class would need to be altered to 320k, instead of 128k.


IP Phone and PC Ports

In order to enforce the classifications and policies, the policy-map must be applied to the ingress of all IP Phone and PC ports.

FastEthernet


Gigabit Ethernet


4. Catalyst 4500 Sup VI-E

These Catalyst switch models can be found in the access, distribution, or core layers of the LAN. These models support a 1P3Q1T queuing model.

Global Commands

These commands are entered on a global level and are necessary in all QoS implementations. They are used to properly map COS and DSCP values as well as to associate these markings with the appropriate interface queue and threshold.

Table Map


Access Lists

Access lists (ACLs) are used to properly identify traffic that will need to be marked at the point of ingress. These ACLs will deviate from LAN segment to LAN segment, as both the voice VLAN and data VLAN may differ from location to location within a deployment.


Class Maps


Policy Maps


Access Ports


Trunk Ports


5. Catalyst 4500 Sup 7-E

The per-port/per-VLAN policing model is essentially the same for the Catalyst 4500-E Supervisor 6-E, except that it does not require a global policed-DSCP map and thus the policing commands are slightly different; also no trust-DSCP statement is required on the interface(s)


Data Vlan Interfaces


Voice Vlan Interfaces


6. Catalyst 4500: Supervisor V-10GE

6.1. Per-Port UBRL (User-Based Rate Limiting)

UBRL adopts microflow policing capability to dynamically learn traffic flows and rate limit each unique flow to an individual rate and, as such, is a highly effective and efficient policing tool, particularly at the distribution ayer in a medianet campus network.

UBRL is available on Supervisor Engine V-10GE with NetFlow support. UBRL can be applied to ingress traffic on routed interfaces and is typically used in environments where a per-user, granular rate limiting mechanism is required, such as at the distribution layer, to provide a second line of policing defense in the campus. Like other policers, UBRL can be used to drop or remark exceeding flows.

A flow is defined by five-tuples (IP source address, IP destination address, IP protocol field, Layer 4 protocol source, and destination ports), which are the same for each packet in the flow. Flow-based policers apply a single policy to discrete flows without having to specify the virtually-infinite tuple-combinations. UBRL can also be applied with source or destination flow masks; these masks apply an aggregate microflow policing policy to multiple flows sharing the same source or IP destination addresses.

In the per-port UBRL Model, a class map matches on a microflow basis and aggregates these by source addresses. Then a policer applies an aggregate limit to all microflows sharing a common source IP address, remarking traffic in excess of the policing rate.

Remarking is performed by configuring a policed-DSCP map with the global configuration command qos map dscp policed, which specifies which DSCP values are subject to remarking (if out-of-profile) and what these values should be remarked to (which in the case of scavenger class QoS policies, the remarking value is CS1/DSCP 8).

UBRL is supported on Layer 3 interfaces and can be applied on either a per-port or per-port/per-VLAN-basis

Per-Port UBRL Configuration Example on a Catalyst 4500 Supervisor V-10GE



6.2. Per-Port/Per-VLAN UBRL (User-Based Rate Limiting)

In contrast with the previous example, if the campus distribution block is using a Layer 2/Layer 3 design, and as such has Layer 2 trunked interfaces (TenGigabitEthernet 1/1 and 1/2) connecting it to the access layer switches, then UBRL can be applied on a per-port/per-VLAN basis. In this case, separate UBRL policies can be applied to each VLAN traversing the trunked interfaces via per-port/per-VLAN UBRL policies as each VLAN is routed through the switch.

To highlight policy flexibility, additional levels of classification are included in this second UBRL example (which incidentally can also be applied to the per-port UBRL model). Instead of applying a blanket UBRL policy to all endpoints, separate UBRL polices can be applied to different types of endpoints or application-and-endpoint-combinations. For example, VoIP from Cisco IP phones in the VVLAN can be rate limited to 128 Kbps, while signaling traffic from these endpoints can be limited to 32 kbps. Similarly, TelePresence endpoints in the VVLAN (which mark their media flows to CS4) can be limited to 25 Mbps. All other endpoint-generated traffic in the VVLAN can be limited to 32 kbps per endpoint.

Similar policy granularity can be applied to the DVLAN policer, if desired. However in this example, a simplified DVLAN policer is applied to all flows to ensure that any DVLAN endpoint transmitting at more than 5% capacity (an example value) of the access edge 10/100/1000 switch ports are subject to data plane policing/scavenger class QoS.

Static DSCP-trust is configured on the physical ports and the per-port/per-VLAN UBRL policers are applied to their respective VLANs within the trunked interface.

Per-Port/Per-VLAN UBRL Configuration Example on a Catalyst 4500 Supervisor V-10GE


7. Catalyst 6500 Native IOS

These Catalyst switch models can be found in the distribution or core layers of the LAN. The queuing method is directly dependent upon the line cards. Consult the Cisco QoS SRND or line card datasheet on Cisco website documentation to ensure that the proper queuing method is configured on the switch.

Global Commands

These commands are entered on a global level and are necessary in all QoS implementations. They are used to properly map COS and DSCP values as well as to associate these markings with the appropriate interface queue and threshold.


Trunk Port Commands

Trunk ports, which could include connections to other switches, as well as Dot1Q connections to routers, should be configured to trust the DSCP markings from the neighboring device. Additionally, with Native IOS, the queue configurations are also made on the actual interfaces and are dependent upon the transmit queue support of the line cards.

2Q2T Tx Line Cards


1P2Q1T Tx Line Cards


1P2Q2T Tx Line Cards


1P3Q1T Tx Line Cards


1P3Q4T Tx Line Cards


1P3Q8T Tx Line Cards


1P7Q4T Tx Line Cards


1P7Q8T Tx Line Cards


Voice Servers, WAN Routers, Gateways

Generally speaking, devices such as voice servers, WAN routers, and voice gateways can be trusted, similar to trunk ports.

2Q2T Tx Line Cards


1P2Q1T Tx Line Cards


1P2Q2T Tx Line Cards


1P3Q1T Tx Line Cards


1P3Q8T Tx Line Cards


1P7Q8T Tx Line Cards


Access Lists

Access lists (ACLs) are used to properly identify traffic that will need to be marked at the point of ingress. These ACLs will deviate from LAN segment to LAN segment, as both the voice VLAN and data VLAN may differ from location to location within a deployment.


Class Maps


Policy Maps


Gigabit Ethernet IP Phone and PC Ports

In order to enforce the classifications and policies, the policy-map must be applied to the ingress of all IP addresses.

2Q2T Tx Line Cards


1P2Q1T Tx Line Cards


1P2Q2T Tx Line Cards


1P3Q1T Tx Line Cards


1P3Q4T Tx Line Cards


1P3Q8T Tx Line Cards


1P7Q4T Tx Line Cards


1P7Q8T Tx Line Cards


Per-Port Microflow Policing Model

Microflow policing dynamically learns traffic flows and rate limits each unique flow to an individual rate and as such, is a highly effective and efficient policing tool, particularly at the distribution layer in a medianet campus network.

Microflow policing can be applied to ingress traffic on routed interfaces and is typically used in environments where a per-user, granular rate limiting mechanism is required such as those of at the distribution layer which to provide a second-line of policing defense in the campus. Like other policers, microflow policing can be used to drop or remark exceeding flows.

Microflow policers are enabled with the police flow policy-map class-action command. A flow is defined by five-tuples (IP source address, IP destination address, IP protocol field, Layer 4 protocol source, and destination ports), which are the same for each packet in the flow. Microflow policers apply a single policy to discrete traffic flows, without having to specify the virtually-infinite tuple combinations. Microflow policing can also be applied with source or destination flow masks (with the mask src-only and mask dest-only optional keywords, respectively). These masks then apply an aggregate microflow policing policy to multiple flows sharing the same source or IP destination addresses.

In the per-port microflow policing model, a flow-based policer is applied with a mask src-only option and applies an aggregate limit to all microflows sharing a common source IP address, remarking traffic in excess of the policing rate.

Remarking is performed by configuring policed-DSCP maps with the global configuration commands mls qos map policed-dscp normal-burst (which specifies the exceeding remarking action) and mls qos map policed-dscp max-burst (which specifies the violating remarking action, in the case of a dual rate policer). These commands specify which DSCP values are subject to remarking if out-of-profile and what value these should be remarked as (which in the case of data plane policing/scavenger class QoS policies, this value is CS1/DSCP 8).

Even if single rate policers are used, it is recommended to configure the mls qos map dscp policed max-burst markdown map, as the maximum_burst_bytes parameter for the policer is set to equal to the normal_burst_bytes parameter, unless explicitly specified otherwise. In other words, the PIR is set to equal the CIR, unless explicitly specified otherwise, and thus the exceed-action policed-dscp-transmit keywords causes PFC QoS to mark traffic down DSCP values as defined by the policed-dscp max-burst markdown map (and not the policed-dscp normal-burst markdown map).

Per-Port Microflow Policing Configuration Example on a Catalyst 6500



Per-VLAN Microflow Policing Model

In contrast with the previous example, if the campus distribution block is using a Layer 2/Layer 3 design, and as such has Layer 2 trunked interfaces (TenGigabitEthernet 3/1 and 3/2) connecting it to the access layer switches, then microflow policing can be applied on a per-VLAN basis. In this case, separate microflow policing policies can be applied to each VLAN.

To highlight policy flexibility, additional levels of classification are included in this second microflow policing example. Incidentally these additions can also be applied to the per-port microflow policing model. Instead of applying a blanket microflow policer to all endpoints, separate microflow policers can be applied to different types of endpoints or application-and-endpoint-combinations. For example, VoIP from Cisco IP phones in the VVLAN can be policed to 128 Kbps, while signaling traffic from these endpoints can be policed to 32 kbps. Similarly, TelePresence endpoints in the VVLAN (which mark their media flows to CS4) can be policed to 25 Mbps. All other endpoint-generated traffic in the VVLAN can be policed to 32 kbps per endpoint.

Similar policy granularity can be applied to the DVLAN policer, if desired. However in this example, a simplified DVLAN policer is applied to all flows to ensure that any DVLAN endpoint transmitting at more than 5% capacity (an example value) of the access edge 10/100/1000 switch ports are subject to data plane policing/scavenger class QoS.

Per-VLAN Microflow Policing Configuration Example on a Catalyst 6500



Voice Gateways

In order to ensure true end to end QoS throughout the environment, the voice gateways must be configured to properly mark control and bearer traffic sourced from their processes, including MGCP, H.323, and SIP.

MGCP Gateways

By default, MGCP gateways mark bearer traffic with DSCP EF and control traffic with AF31. This is not consistent with current standards. The following modifications should be made to all deployed MGCP gateways.


H.323/SIP Gateways

By default, H.323 and SIP dial-peers mark bearer traffic with DSCP EF and control traffic AF31. This is not consistent with current standards. The follow modifications should be made to VOIP dial-peers on all deployed H.323 and SIP gateways.


WAN Quality of Service

When you are trying to guarantee traffic service over long distance involving WAN circuits such as point-to-point, MPLS, and Metro Ethernet; then there must be QoS implementation on your WAN gateway of all ends of your location. In addition, your WAN QoS implementation must match QoS specification your service provider uses to maintain end-to-end QoS service.

As illustration, let's say you have point-to-point 1 Gbps Metro Ethernet circuit from your service provider to interconnect two of your locations. The service provider has specification that 5 Mbps is guaranteed for Class of Service (CoS) Priority 5 (EF) traffic, 5 Mbps is guaranteed for CoS Priority 2; while the remaining bandwidth is freely used for CoS default traffic.

Let's assume you have IP Phone that uses DSCP EF 5 or CoS 5 of UDP port range 16384 - 32767 for voice traffic and uses DSCP AF 41 (CS 3) or CoS 3 of SIP (UDP and TCP port range 5060 - 5061) and SCCP (TCP port range 2000 - 2002) for signalling traffic. Within LAN, you typically let these specification as default while setting all LAN switch access and trunk ports to acknowledge these traffic. Once the traffic is headed to the point-to-point circuit, then somehow you have to modify the traffic specification when you intend to match your traffic specification with the service provider specification.

Assume you like to utilize the service provider CoS 5 for the voice traffic, CoS 2 for the signalling, and remaining bandwidth is utilize for other traffic such as email, web, and file sharing. Therefore as the traffic is about to leave one location over the point-to-point circuit to reach your other location, you need to map your existing CoS 5 traffic to the service provider CoS 5, map your existing CoS 3 traffic to the service provider CoS 2, and map remaining traffic to the service provider CoS default traffic.

When the traffic is already going over the point-to-point circuit from one location and arrive at the other location, you need set your traffic back to its original specification in order to match your traffic specification. Therefore as the traffic arrives at the other location, you need to map the service provider CoS 5 traffic to the original CoS 5 traffic, map the service provider CoS 2 to the original CoS 3, and map remaining traffic as default traffic.

As you may note that these WAN QoS mapping occurs on your WAN gateway while LAN QoS mapping occurs on your LAN. Following is one solution how the WAN QoS mapping and configuration look like. The assumption here is that your WAN gateway is a router using GigabitEthernet 0/0/0 port to connect to the WAN circuit.



For more info regarding these QoS commands, check out the following Cisco link.
Configuring the Modular Quality of Service

Example Network Design and Implementation

The information posted here is a summarized version of the Cisco AVVID QoS Design Guide. The person who posted this is not liable for any network problems or any damage caused by configuring their router to the following specification. If in doubt, open up a Cisco TAC case which a Cisco Engineer will get in touch to help you implement or troubleshoot your design or issue respectively. You may also ask the Cisco forum community for any advice but community accept no liability for any recommendations made which are then implemented.

The example below is using a Cisco 79xx IP Phone, 2924 Switch (12.0(5)XU EN, and a 2600 Router (12.2(11)T IP/FW/IDS PLUS IPSEC 56). Make sure the versions of IOS that you're running support the commands used before implementing in a production environment. It also assumes that you are using separate VLANs for data and voice (VLAN 100 for data, and 101 for voice).

This example assumes the following network setup:

Configuring the 2924 Switch:


The above port configuration allows for both voice and data traffic from separate vlans. Cisco IP Phones automatically support 802.1q trunking and 802.1p COS tagging, which will tag all outgoing voice traffic with an L2 COS of 5, and a L3 IP Precedence of 5. The 'switchport priority extend cos 0' ensures that all data traffic has it's L2 COS tag re-classified as 0. This will ensure a PC connected to the phone is not also classifying its traffic.

Additionally, if your switch supports inline power, add the following to the above configuration: 'power inline auto'

NOTE:
The 'speed auto' command is extremely important. Cisco IP phones default to auto-negotiation for speed and duplex. If the switch port is set to 100baseT full-duplex, the IP phone automatically sets its port to 100baseT half-duplex, causing a duplex mismatch.

Configuring the 2600 router

The first thing we need to do is define access-lists to match our voice traffic. We will create 2 extended ACLs, one for the voice RTP traffic, and one for the voice signaling traffic.

For Skinny, H.323, MGCP


For SIP/IAX/IAX2:


NOTE:
You may also use a 'permit ip 1.1.1.0 0.0.0.255 any' command on the signaling access-list to match all hosts in a particular subnet, assuming all IP phones are on the same subnet and their own vlan.

Next, we create class maps for each type of traffic.


Then create a policy map for the classes:


The policy-map on the router places all voice traffic into the Priority Queue, which is given 240kbps of bandwidth. All signaling traffic is in a class-based queue with 16kbps of bandwidth. And all other traffic is queued using Weighted Fair Queuing.

To determine how much bandwidth to give to voice traffic:
Number of simultaneous calls X 80 (for g711u)
Number of simultaneous calls X 11 (for g729)

Finally, apply the policy to the interface:


NOTE:
If you are using sub-interfaces, applying the policy to the fa0/0 interface will also apply it to all sub-interfaces (i.e. fa0/0.1, fa0/0.2 etc.) To apply a QoS service-policy to a specific sub-interface refer to this Cisco link.
Applying QoS Features to Ethernet Sub-interfaces

As Qos is generally configured on outgoing traffic, it will help if you have control over both sides of the link. You can also apply rate limiting to inbound traffic if you so choose, however it will only work with TCP traffic.


This rate-limit command line will allow no more than 1408kbps through; so that any excess will be dropped. Again, this only works for TCP traffic, since dropped packets will cause the sender to back off and try again slower.

-b

Discussions

»[Config] Configuring QOS on 2960 for VOIP
»[HELP] Enabling QoS on 4500 switch
»[HELP] Route Maps question
»[HELP] VOIP and data traffic with qos and vlan