Application Note

ST AppNote 10325 (AN 10325) August 17, 2011

Best Practice Recommendations for VLANs and QoS with ShoreTel

Description:
Environment:

This application note discusses the use of Virtual LANs, DHCP scopes and Quality of Service in a ShoreTel IP-PBX Voice over IP environment
ShoreTel IP-PBX versions 9 12

Introduction
Network Administrators must consider a multitude of complex configuration options and networking parameters when designing a large local area network (LAN). Those options can include the use of Virtual LANs (VLANs) and Quality of Service (QoS) configurations. This document will briefly describe the use and purpose of VLANs and then explain, in detail, several implementation strategies for VLANs and QoS in a Voice over IP (VoIP) network. Configuration samples are included. For simplicity sake all configuration examples are given using Cisco IOS command structures. Please refer to your network equipment manufacturers documentation in order to apply the ideas and concepts presented in this document to your specific equipment and environment.

Contents
Application Note .............................................................................................................................. 1 Introduction ..................................................................................................................................... 1 Contents .......................................................................................................................................... 2 Understanding VLANs ..................................................................................................................... 2 ShoreTel IP Phones in a VLAN environment ................................................................................... 7 DHCP ............................................................................................................................................... 9 Quality of Service (QoS) on the LAN and WAN .............................................................................. 10 Local Area Network Quality of Service .......................................................................................... 11 Using Auto-QoS.............................................................................................................................. 12 Wide Area Network Quality of Service........................................................................................... 13 Caveats ......................................................................................................................................... 19 Conclusion..................................................................................................................................... 19 References .................................................................................................................................... 20 Appendix A: Auto-QoS .................................................................................................................... 20

Understanding VLANs
Virtual LANs (VLANs) are a networking design construct by which more than one layer-2 (L2) network can exist on a single network segment while still separating broadcast domains. In a converged network containing both voice and data, it is highly recommended that the voice and data packets be separated into distinct VLANs. Failure to do so may result in poor voice quality, packet loss, client to server communication issues, and lost call control/setup traffic. The benefits of placing data and voice traffic in separate VLANs and implementing QoS strategies include: Reduction in the number of Ethernet switches required in the network Broadcast packets from the data network are not sent to the voice network Large data traffic flows do not interfere with more time sensitive voice traffic Congestion, packet loss, and viruses on the data network will not affect the voice network Consider the design differences between the following two networks. The first diagram (figure 1) illustrates an enterprise network with two Ethernet switches. These switches are layer-2 only and do not support VLANs. All devices on a single switch must therefore be in the same layer-2 broadcast domain and must be assigned IP addresses in the same IP subnet. In this first network, each switch has its own unique IP subnet and its own broadcast domain. All ports on the switch are assigned to (that is, are members of) a single subnet/broadcast domain and devices on that switch can only communicate to devices on another subnet by sending traffic to an external, layer-3 (L3) device (e.g. a router) which acts as the default gateway for the devices on each subnet. 2

ROUTER CONFIGURATION interface FastEthernet 0/0 ip address 1.1.1.1 255.255.255.0 interface FastEthernet 0/1 ip address 2.2.2.1 255.255.255.0

Figure 1 In figure 1, if a device needs to be reassigned from one network to the other (say, an employee is reassigned from the QA department to the HR department) the device needs to be physically disconnected from the original switch, configured with a new IP address and default gateway and physically reconnected to the other switch.

In the second diagram (figure 2) the two non-VLAN-capable L2 switches have been replaced by a single VLAN-capable L2 switch. (Note: newly added and significant configuration settings have been colored in BLUE.)

L2 SWITCH CONFIGURATION vlan 10 name QA interface FastEthernet1 switchport mode access (the default) switchport access vlan 10 interface FastEthernet2 switchport access vlan 10 interface FastEthernet3 switchport access vlan 10 vlan 20 name HR interface FastEthernet4 switchport access vlan 20 interface FastEthernet5 switchport access vlan 20 interface FastEthernet6 switchport access vlan 20 interface FastEthernet7 switchport mode trunk switchport trunk encapsulation dot1q

ROUTER CONFIGURATION interface FastEthernet 0/0.10 encapsulation dot1q 10 ip address 1.1.1.1 255.255.255.0 interface FastEthernet 0/0.20 encapsulation dot1q 20 ip address 2.2.2.1 255.255.255.0

Figure 2 Physical ports in the VLAN-capable Ethernet switch must be configured by the administrator to be assigned to one particular VLAN or the other. Ports in the switch are now no longer physically restricted to being in a single LAN but can be logically, or virtually, assigned to a logical LAN, called a Virtual LAN (VLAN). All ports in this new network can now be dynamically assigned to either the QA VLAN or the HR 4

VLAN and the broadcast domains for the two virtual networks are contained and isolated by the software running on the switch. Packets sent within one virtual network stay within the VLAN. Each packet is marked, internally within the switch, by a VLAN ID number called a VLAN tag (generally a number between 1 and 4096) to identify which VLAN it belongs to. The tags, though used internally, are stripped off when the packets are transmitted to devices connected to standard ports on the switch. These standard ports connected to standard devices are called untagged ports. The devices within one VLAN still need to send packets to a default gateway to be routed to another subnet. Since the switch in this example is a layer-2 only switch (and therefore has no ability to route packets; it can only switch packets) an external router is still required. But we can now take advantage of a mechanism of VLANs called VLAN tagging. VLAN tagging can be configured on a physical port when the administrator desires traffic from more than one VLAN to be carried on a single Ethernet cable. By configuring a switch port to be a VLAN-tagged switch port, and by assigning that port to carry traffic for more than one VLAN, each packet that exits on the switch will have an additional 4-byte VLAN tag inserted into the Ethernet packet. The industry standard for VLAN tagging is an IEEE specification called 802.1Q. The device connected to the VLAN-tagged port, in this case the L3 router, must be capable of understanding 802.1Q tags and its network interface must be configured to have VLAN tagging enabled and have specific VLAN IDs assigned to it. The L3 router interface should have a distinct sub-interface configured for each VLAN it will be communicating with. In our example network in figure 2, packets that are sent from the QA subnet to the router leave the switch on port 7 tagged with a VLAN ID of 10 (the administrators chosen ID for that VLAN). The router will route the packet from one of its sub-interfaces to its other sub-interface and resend the new packet out the same physical interface back to the switch; but this time the packet will have a VLAN ID tag of 20. The switch will deliver the received packet to the proper destination device in VLAN 20 (on the HR VLAN). In the third network diagram (figure 3) we have upgraded from a Layer-2, non-routing switch to a Layer-3, routing switch, often called an L3 switch. Layer-3 switches have built-in routing capabilities and can route packets between VLANs without the need for an external router. The flow of packets from a device in one VLAN to a device in the other VLAN follows the exact same steps and procedures as outlined in the above network but the forwarding and tagging of packets is all handled by one device (the L3 switch) with an internal process that acts as a multi-port virtualized router.

L3 SWITCH CONFIGURATION ... ip routing interface VLAN_10 description : QA Network ip address 1.1.1.1 255.255.255.0 interface VLAN_20 description : HR Network ip address 2.2.2.1 255.255.255.0 ...

Figure 3 In summary, VLANs can offer several advantages to a network administrator. By adding VLANs and VLAN tagging to a network design a network administrator can purchase fewer switches and has greater flexibility and management over moves and changes within the network. Conversely, adding VLANs to a network design increases its complexity and should only be done when the IT staff managing a network has a thorough understanding of networking, IP subnetting, VLANs and the specific configuration tools and options their network equipment provides. The examples of VLANs described above use two data VLANs as examples. We can apply the same concepts and principles to a converged network carrying both data and voice. The next section will discuss the addition of a voice-specific VLAN to our example network.

ShoreTel IP Phones in a VLAN environment

ShoreTel leverages the use of VLANs to integrate into the network topology that you, the network administrator, have decided is most appropriate for your LAN topology. ShoreTel does not require nor dictate that you use a specific vendors equipment for your LAN edge, core, WAN, switches, routers, operating systems, etc. As long as your hardware supports the minimum recommended requirements you are free to deploy the equipment and network topology that works best for you. In the next network diagram (figure 4) we have added a mixture of standalone ShoreTel IP phones, standalone PCs, servers, a ShoreTel ShoreGear Voice Appliance and PC workstations daisy-chained through the IP phones. We start by creating a new dedicated voice VLAN (#30) on the L3 switch using the configuration below:

L3 SWITCH CONFIGURATION interface VLAN30 description : Voice Network ip address 3.3.3.1 255.255.255.0

Layer 3 switches allow the assignment of a primary, or access, VLAN, traditionally used by the data device, and a secondary, or auxiliary, voice VLAN used by VoIP telephony equipment. When a PC is daisy chained behind a telephone, the port on the Ethernet switch needs to be configured to accept traffic from both devices (IP Phone and PC) and to identify, separate, and place their traffic on the appropriate network segment/VLAN. The capabilities of an Access Port enable an Ethernet switch port to send and receive both untagged traffic and VLAN tagged traffic. This is contrasted with a dedicated trunk port which cannot access any untagged traffic; only tagged, VLAN traffic. In our example network (figure 4) each of the ports 1 through 6 are configured as access ports. Any packets received on those ports that are not tagged with an 802.1Q VLAN header will be assigned to the access Data VLAN (VLAN ID 10). Any packet that is received with an 802.1Q VLAN header with a VLAN ID of 30 will be assigned to the Voice VLAN (VLAN ID 30)

L3 SWITCH CONFIGURATION interface FastEthernet1 (and port 4) description : These ports have BOTH phone + PC switchport mode access switchport access vlan 10 switchport voice vlan 30 spanning-tree portfast no cdp enable interface FastEthernet2 (and ports 5,11,12) description : These ports have ONLY voice devices switchport mode access switchport access vlan 30 spanning-tree portfast no cdp enable interface FastEthernet3 (and ports 6 & 10) description : These ports have ONLY data devices switchport mode access switchport access vlan 10 spanning-tree portfast no cdp enable

Figure 4

DHCP
Most ShoreTel implementations allow the phones and PCs to get their IP address and other networking information from a DHCP server as shown in figure 4. The ShoreTel IP phones need to have a ShoreTel vendor-specific DHCP option (Option 156) included in the DHCP offer they receive from the DHCP server. DHCP packets are broadcast packets and, by design, are not transmitted beyond the boundaries of the VLAN the device is attached to. Therefore, most voice VLANs have an ip-helper address statement that forwards DHCP requests to the IP address of the DHCP server.

L3 SWITCH CONFIGURATION interface VLAN30 description : Adding DHCP helper ip address 3.3.3.1 255.255.255.0 ip-helper address 1.1.1.5

When a ShoreTel IP phone configured to use DHCP first boots up it will send an untagged DHCP broadcast packet requesting an IP address from the DHCP server. This packet will be seen by the Ethernet switch on the untagged access VLAN configured for that port. The IP phone will get an IP address allocated by the DHCP server from the Data VLAN. The ShoreTel administrator will have worked with the DHCP Server administrator to add a Vendor Specific Option to the DHCP Servers scope. ShoreTel uses the aforementioned Option 156 as the specific Vendor Specific Option for ShoreTel IP Phone configuration information. The Data VLAN will have option 156 set and this information, along with an IP address in the Data VLAN, is sent to the phone. Option 156 will be configured with a text string similar to the following: ftpservers=3.3.3.5,layer2tagging=1,vlanid=30 In the Option 156 text string above, the phone is told that its boot files can be downloaded from a ShoreTel server (HQ or DVS) at IP address 3.3.3.5. The layer2tagging option turns on VLAN tagging (1 is on, 0 is off) and assigns a VLAN ID of 30. Upon receipt of this information the phone immediately resets to implement these changes. On its second boot, the IP phone once again sends a DHCP broadcast request; this time using a VLAN tag with VLAN ID=30. The L3 switch receives this request on the Voice VLAN and forwards it, via the ip helper address command, to the DHCP server at IP address 1.1.1.5. The DHCP server replies with a new IP address for the phone using an IP address range and network settings from the Scope Options that are assigned for the VLAN 30 subnet. The Scope Options for VLAN 30 must also contain the same Option 156 information as the Access/Data VLAN Scope Options did. Since the phones current VLAN settings match the newly received Option 156 settings (from the second DHCP Offer) the phone continues with its boot process and request service from a ShoreTel switch. For more detailed information on configuring DHCP with ShoreTel please refer to the ShoreTel Planning and Installation Guide, Chapter 9.8 Configuring Automatic VLAN Assignment via DHCP.

As a final note, the configuration above included these two statements on the Fast Ethernet port: spanning-tree portfast no cdp enable Although these statements are not required, it is recommended that CDP (Cisco Discovery Protocol) be disabled on Ethernet ports not connected to Cisco devices to reduce unnecessary traffic. In addition, Spanning Tree should be set to either portfast or rapid spanning tree mode. This will allow faster boot times and fewer network issues when connecting to ShoreTel phones, ShoreTel switches and ShoreTel servers.

Quality of Service (QoS) on the LAN and WAN

Even in a well-designed and segmented network, congestion issues can arise as data and voice devices compete for limited bandwidth. Although congestion issues are prevalent mostly in the Wide Area Network (WAN) where bandwidth is typically smaller (1 to 5 Megabits per second (Mbps) vs. the LANs 100 to 1,000 Mbps), all Voice over IP systems are very dependent on the IP infrastructure. In the same way that a house built on an unstable foundation will eventually experience problems, a VoIP system deployed on a poorly designed IP network will struggle to perform as expected. Typically, networks operate on a best-effort delivery basis, meaning all traffic has equal priority of being delivered in a timely manner. When congestion occurs, all traffic has an equal chance of being buffered, causing network delay (latency) or, worse, being dropped entirely. Quality of Service (QoS) allows network administrators to identify and prioritize specific types of traffic and use congestion-management and congestion-avoidance techniques to provide more desirable, preferential and predictable bandwidth utilization. Most QoS implementations are based on the Differentiated Services Code Point (DSCP, or DiffServ) standard. DiffServ is a standard defined by the Internet Engineering Task Force (IETF). The DSCP architecture specifies that each packet be marked, or classified, with an appropriate priority value. This DiffServ Code Point is often set by the originating device, such as an IP Phone, or assigned to packets as they enter a network device such as by an Ethernet switch or border router.

The eight standard DSCP markings The following pages provide recommendations and basic guidelines for implementing Quality of Service for the LAN and WAN when deploying a ShoreTel IP-PBX system on your network. Please use these 10

examples as guidelines for discussion with network and security professionals to ensure implementation in accordance with your corporate security and network policies. These examples are taken from common Cisco layer 3 Ethernet switches and routers. Actual commands and syntax may be different for your model, operating system, version and/or manufacturer. Please consult the manufacturer of your network equipment or an experienced network engineer for detailed instructions on configuring Quality of Service in your specific environment.

Local Area Network Quality of Service

The amount of bandwidth available on modern LANs, as well as the speed and horsepower of newermodel switches, results in very few cases of congestion, or bandwidth contention, on the LAN. However, environments with many users and time sensitive protocols (voice, video, Citrix, Windows Terminal Server, Point-of-Sales systems, etc.) should consider implementing Quality of Service on the LAN. Each manufacturer implements QoS on their LAN switches using slightly different command structures; however, the result is the same. Enabling QoS on the LAN allows the switch to distinguish packets or packet flows from each other, assign labels to indicate the priority of the packet, make the packets comply with configured resource limits and provide preferential treatment in situations where resource contention exits. A good example of the need for LAN QoS was documented at one ShoreTel customer site. Users noticed strange call setup behavior, delayed presence updates in the ShoreTel Communicator client, and Microsoft TAPI (Telephony API) errors occurring at seemingly random times each day. Upon further investigation, it was found that IT administrators were bursting huge amounts of data on the LAN to ghost, or clone, PC hard drive configurations at the same time the abnormal voice events were occurring. Without QoS enabled, bandwidth contention contributed to packet loss and latency on the LAN switch which in turn resulted in poor Voice over IP performance. The addition of VLANs and QoS parameters to prioritize the voice VLAN over the data VLAN resolved the issue. A discussion on how to enable Quality of Service for every Ethernet switch manufacturer is beyond the scope of this document. A brief example of how to enable Ciscos Auto-QoS is described below. Please consult with your LAN switch manufacturer to create similar QoS mechanisms for your LAN environment.

11

Using Auto-QoS
The following example shows how to enable auto-qos on a Cisco Layer 3 switch. IMPORTANT: Adjusting network settings should be performed after hours during a scheduled maintenance window. Auto-QoS will instruct the switch to add numerous lines of QoS commands to its running configuration along with several statements to every interface. The switch may not respond during this timeframe and might require a reboot to fully normalize. In enable mode on the L3 switch type: #mls qos The addition of this command enables Ciscos auto-QoS feature on the switch. Auto-QoS makes assumptions about the network design and, as a result, the switch can prioritize different traffic flows and appropriately use the ingress and egress queues instead of using the default best effort behavior. When you enable auto-QoS, it automatically classifies traffic based on the traffic type and ingress packet label. The switch uses the resulting classification to set and choose the appropriate egress queue. To see the default queues applied, please see tables 35-2 thru 35-4 in the following Cisco documentation: http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_58_se/conf iguration/guide/swqos.html#wp1231112 Note: For a complete list of configuration changes applied to the Cisco switch as part of enabling Auto-QoS see Appendix A at the end of this document. Along with global QoS commands to enable ingress and egress queuing and mapping DSCP markings to queues, auto-qos adds configuration lines to each Ethernet interface. The lines added to each interface determine how the switch will handle DSCP-marked traffic from the ShoreTel phones. Depending on the IOS version and switch model, you may have different lines and/or some lines might be hidden in the running configuration because they are default. The effects of the commands in the following sample interface will be discussed below:
SAMPLE INTERFACE CONFIGURATION WITH NEW AUTO-QOS LINES # mls qos # interface FastEthernet1 switchport mode access switchport access vlan 10 switchport voice vlan 100 srr-queue bandwidth share 10 10 60 20 priority-queue out mls qos trust dscp auto qos voip trust no cdp enable spanning-tree portfast

12

srr-queue bandwidth share 10 10 60 20 Enables Shaped Round Robin (SRR) egress queuing and assigns 10%, 10%, 60% and 20% to the four egress queues, respectively, on the port for egress traffic. Each of the four queues (1, 2, 3, and 4) are guaranteed that percentage and can burst above that if other queues are idle. priority-queue out Establishes a strict priority queue for traffic that is marked with highest priority typically differentiated service code point (DSCP) value 184/EF (64) and above. mls qos trust dscp Sets the interface to trust DSCP values received from the phone. auto qos voip trust Sets the interface to trust VLAN-tagged Class of Service (CoS) values received from the phone. To take advantage of the auto-QoS defaults, you should enable auto-QoS before you configure other QoS commands. If necessary, you can fine-tune the QoS configuration, but Cisco recommends that you do so only after the auto-QoS configuration is completed. Please consult with your network professional or the Cisco Technical Assistance Center for further details or questions regarding the configuration of Cisco Auto QoS on Cisco LAN switches. Full details and complete literature on Auto QoS is located here: http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_58_se/ configuration/guide/swqos.html Enabling Auto-QoS on a Cisco Ethernet switch (or the equivalent settings on other manufacturers equipment) will set the appropriate and necessary queuing and packet scheduling parameters on the Ethernet switch ports. By configuring the ShoreTel system to mark all Real-Time Protocol (RTP) Voice Media with the proper DSCP values (see below) the prioritization of ShoreTel voice traffic on the LAN is assured.

Wide Area Network Quality of Service

In a multi-site enterprise network, bandwidth tends to be more limited and expensive over the Wide Area Network. Therefore, the necessity for bandwidth optimization via QoS technologies is greatest on the WAN. WAN QoS policies need to be configured on the WAN edge, or border, routers at both the main headquarters location as well as at all branch locations. Mechanisms to create and enforce QoS policies include: Queuing Shaping Selective-dropping, and Link-specific policies Note: A complete discussion of QoS policies for WAN technologies such as MPLS, Frame-Relay, Asynchronous Transfer Mode (ATM), Point-to-Point and Multilink over PPP (MLPPP) are beyond the scope of this document. 13

The following section highlights one sample configuration for a Cisco router using Low Latency Queuing to provide minimal delay for time sensitive protocols (VoIP) without starving other applications (email or Internet traffic) to the point of serious degradation. Low Latency Queuing allows delay-sensitive content, such as voice over IP packets, to be sent before other categories of packets are sent. This gives delay-sensitive data preferential treatment over other traffic. To configure a QoS policy you must first take inventory of what applications and protocols run on your network. As a general rule, Voice over IP packet streams are given the highest priority. Second priority is given to video, Citrix, Windows Terminal Service (WTS) and other time sensitive data applications. Third priority is given to call control traffic (call setup and teardown) as well as medium level priority data applications. Other classifications might be created for 4th, 5th, and 6th priority, but in general, all remaining application data is placed in the last, or default, queue for best effort delivery. In the following network example (Figure 5), the company is running voice, data, and video over the WAN.

Figure 5

14

ShoreTel allows you to set the DSCP value for all voice traffic with one setting using the web-based administration tool ShoreWare Director. This one setting is used for all Real-Time Protocol (RTP) packets that are sent from all ShoreTel IP phones, ShoreTel servers and ShoreGear voice appliances. In ShoreWare Director navigate to Call Control |Options and edit the value for DiffServ /ToS Byte under Voice Encoding and Quality of Service.

The recommended setting for DiffServ/ToS Byte is decimal 184 which equates to the Expedite Forwarding DSCP setting (or EF). It is recommended that you set this value early in your ShoreTel deployment as it requires a one-time reboot of all ShoreTel servers, ShoreGear voice switches and ShoreTel IP Phones in your organization. While on this edit page it is advised to set the DSCP value for video packets as well. The recommended DSCP value for the Video QoS setting is decimal 136. In addition to the voice packets (RTP data) and video packets ShoreTel also uses a number of TCP/IP ports and protocols related to call control and user presence. Though not as critical as voice, these 15

packets are also somewhat time sensitive. These ports should be manually entered into the WAN QoS configuration scheme. These additional ports include: UDP 5440 5446 Inter-Switch Call Control UDP 5447 5448 Client Application Server (CAS) (in version 12) UDP 2427 & 2727: MGCP Call Control UDP and TCP 111: Server to Switch Call Control / RPC TCP 5440: CSIS client server traffic TCP & UDP 31453: Used by ShoreTel Contact Center for client server communication The configuration commands below illustrate what the QoS configuration for the customer premise Equipment (CPE) router might look like.

Step 1: Define the classes of traffic on your network

(** comments are not part of the configuration) class-map match-any VOIP_AUDIO match ip dscp ef match protocol rtp audio class-map match-any VIDEO_UNIT match access-group 102 ** Defines the VoIP Audio class of traffic ** Tells it to match anything already marked as EF (184) ** Tells it to also match any other RTP/Audio traffic ** Defines the Video class of traffic ** Tells it to match anything in access list 102 (below)

class-map match-any CALL_CONTROL ** Defines the Call Control class of traffic match access-group 103 ** Match anything in access list 103 (below) match ip dscp af31 ** Match anything already set to DSCP AF31

Step 2: Apply policies to the classes of traffic defined above

policy-map VOIP class VOIP_AUDIO priority percent 15 set dscp ef class VIDEO_UNIT bandwidth 20 set dscp af41 class CALL_CONTROL bandwidth 10 set dscp af31 class class-default set dscp default fair-queue ** Define a policy map and give it the name VOIP ** Assigns the VOIP_AUDIO class the following: ** - Place voice in the highest priority queue and ** reserves 15% of the bandwidth for VoIP ** - Make sure it stays marked with EF as it goes through the WAN ** Assigns the VIDEO_UNIT class the following: ** - Reserve 20% of the bandwidth for the video units ** - Make sure it stays marked with medium-high priority to the WAN ** Assigns the CALL_CONTROL class the following: ** - Reserve 10% of the bandwidth but do not place in priority queue ** - Make sure it stays marked with medium level priority to the WAN ** States all traffic not matching the above use the default ** Make sure it is marked with DSCP 0 (best effort) to the WAN ** Use Ciscos recommended fair queuing policy for best effort traffic

16

Step 3: Define the Video Unit by IP address so they get medium-high priority
access-list 102 remark : Video Traffic from Video server access-list 102 permit udp host 10.1.1.5 any access-list 102 permit udp any host 10.1.1.5

Step 4: Define IP addresses, ports and protocols to be treated as call control traffic
access-list access-list access-list access-list access-list access-list access-list access-list access-list 103 103 103 103 103 103 103 103 103 remark permit permit permit permit permit permit permit permit : ShoreTel VoIP Call Control and CSIS udp any any range 5440 5448 udp any any eq 2427 udp any any eq 2727 tcp any any eq 111 udp any any eq 111 tcp any any eq 5440 tcp any any eq 31453 ** Only for Contact Center udp any any eq 31453 ** Only for Contact Center

Step 5: Apply the policy map to the outgoing serial interface on the router
interface serial0/0 description : T1 to MPLS WAN bandwidth 1536 ip address 209.191.1.1 255.255.255.0 service-policy output VOIP

Step 6: Confirm the QoS policy is applied to the WAN interface and monitor
It is important, on a routine basis, to monitor the output queues to confirm traffic is matching the policies and ensure that the number of drops in the priority queue is not growing. Queue drops are an indication you need to increase the amount of bandwidth in the priority queue, or you have too much non-voice traffic being placed in the priority queue. The command below shows the policy applied to the interface and any drops associated with the queues. #show policy-map interface serial0/0

17

WAN INTERFACE CONFIGURATION # show policy-map interface ser0/0 ... Serial0/0/0 Service-policy output: voip Class-map: VoIP_AUDIO (match-any) 29598783 packets, 5906874082 bytes 5 minute offered rate 17000 bps, drop rate 0 bps Match: ip dscp ef (46) 26411300 packets, 5531823810 bytes 5 minute rate 17000 bps Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 15 (%) Bandwidth 750 (kbps) Burst 5000 (Bytes) (pkts matched/bytes matched) 2434250/1375653329 (total drops/bytes drops) 770350/746146747 Class-map: CALL_CONTROL (match-any) 148419 packets, 9504366 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp af31 148419 packets, 9504366 bytes 5 minute rate 0 bps Queueing Class-Based Weighted Fair Queue Output Queue: Conversation 264 Bandwidth 10 (%) Bandwidth 500 (kbps) Burst 12500 (Bytes) (pkts matched/bytes matched) 11071/708974 (total drops/bytes drops) 0/0 Class-map: VIDEO_UNIT (match-any) 148419 packets, 9504366 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp af31 148419 packets, 9504366 bytes 5 minute rate 0 bps Queueing Class-Based Weighted Fair Queue Output Queue: Conversation 264 Bandwidth 20 (%) Bandwidth 900 (kbps) Burst 12500 (Bytes) (pkts matched/bytes matched) 11071/708974 (total drops/bytes drops) 0/0 Class-map: class-default (match-any) 84557179 packets, 14841300472 bytes 5 minute offered rate 52000 bps, drop rate 0 bps Match: any

** 32% drop rate BAD!!

** 0 Drops is good!

** 0 Drops is good!

18

Caveats
For this WAN QoS policy to work, you must purchase QoS from your MPLS/WAN provider. It will not help to mark traffic leaving your network into the carriers cloud if they do not honor your markings. Failure to do this can cause the carrier to discard your markings and treat all traffic as best effort in their network. QoS policies applied to Virtual Private Networks (VPNs) running over the Internet are generally ineffective. The Internet treats all traffic with equal priority and in most cases has no service level agreement regarding prioritization of traffic. ShoreTel does not recommend running voice over VPN networks as the primary method of delivering voice service. Internet based VPNs can provide temporary or backup links as part of a corporate redundancy strategy; however, lack of consistent service level agreements on Internet links make it a poor choice for mission critical applications. Never put too much traffic in the priority queue. A common mistake made by network administrators is to overload the priority queue. The thinking is if the priority queue is the highest then lets put everything in that queue such as voice, video, call control, etc. What they do not realize is the priority queue in both their router and the WAN providers network drops every single packet that exceeds the bandwidth limit for the priority queue. An overloaded priority queue will drop a tremendous amount of traffic. Voice RTP streams can handle packet loss in the range of 1 to 3%. However, call control cannot handle packet loss. Placing call control and other non-latency sensitive applications in the priority queue will cause packet loss for applications that cannot handle loss of data.

Important: No single QoS policy fits all networks. Each QoS configuration should be based on the applications running across your wide area network.

Conclusion
There are many different configuration options that were not discussed in this document. Some of them were left out for brevity sake. Some were left out because they are discussed in other ShoreTel White Papers (such as WAN QoS configuration guidelines) or the ShoreTel Documentation (such as detailed IP phone configuration options and additional DHCP scope parameters such as NTP servers, and GMT offset). Other topics are very pertinent but are beyond the scope of this document, such as: Port security Private VLANs MAC address locking/filtering Denial of Service (DOS) / Distributed DOS (DDOS) attack prevention Voice encryption Security best practices

19

References
ShoreTel Guides and References: ShoreTel Planning and Installation Guide, Chapter 9: Understanding Toll-Quality Voice ShoreTel Planning and Installation Guide, Chapter 9: Configuring DHCP for ShoreTel IP Phones IEEE 802.1Q Tagging: http://www.ieee802.org/1/pages/802.1Q.html http://ieeexplore.ieee.org/xpl/standardstoc.jsp?isnumber=27089&isYear=2003 Cisco Configuration Guides and References: http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_58_se/configur ation/guide/3750scg.html http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/autwp_wp.pdf http://www.cisco.com/en/US/customer/docs/ios/12_0s/feature/guide/fsllq26.html

Appendix A: Auto-QoS
Below is a complete list of command changes that are applied with the use of the Auto-QoS command on a Cisco L3 switch. For more information see Table 35-5 in the following document: http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_58_se/conf iguration/guide/swqos.html#wp1231112 Description The switch automatically enables standard QoS and configures the CoS-to-DSCP map (maps CoS values in incoming packets to a DSCP value). The switch automatically maps CoS values to an ingress queue and to a threshold ID. Automatically Generated Command {voip} Switch(config)# mls qos mls qos map cos-dscp 0 8 16 26 32 46 48 56 no mls qos srr-queue input cos-map mls qos srr-queue input cos-map queue 1 threshold 2 1 mls qos srr-queue input cos-map queue 1 threshold 3 0 mls qos srr-queue input cos-map queue 2 threshold 1 2 mls qos srr-queue input cos-map queue 2 threshold 2 4 6 7 mls qos srr-queue input cos-map queue 2 threshold 3 3 5 no mls qos srr-queue output cos-map mls qos srr-queue output cos-map queue 1 threshold 3 5 mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7 mls qos srr-queue output cos-map queue 3 threshold 3 2 4 mls qos srr-queue output cos-map queue 4 threshold 2 1 20

The switch automatically maps CoS values to an egress queue and to a threshold ID.

mls qos srr-queue output cos-map queue 4 threshold 3 0 The switch automatically maps DSCP values to an ingress queue and to a threshold ID. no mls qos srr-queue input dscp-map mls qos srr-queue input dscp-map queue 1 threshold 2 9 10 11 12 13 14 15 mls qos srr-queue input dscp-map queue 1 threshold 3 0 1 2 3 4 5 6 7 mls qos srr-queue input dscp-map queue 1 threshold 3 32 mls qos srr-queue input dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23 mls qos srr-queue input dscp-map queue 2 threshold 2 33 34 35 36 37 38 39 48 mls qos srr-queue input dscp-map queue 2 threshold 2 49 50 51 52 53 54 55 56 mls qos srr-queue input dscp-map queue 2 threshold 2 57 58 59 60 61 62 63 mls qos srr-queue input dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31 mls qos srr-queue input dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47 no mls qos srr-queue output dscp-map mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47 mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31 mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55 mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63 mls qos srr-queue output dscp-map queue 3 threshold 3 16 17 18 19 20 21 22 23 mls qos srr-queue output dscp-map queue 3 threshold 3 32 33 34 35 36 37 38 39 mls qos srr-queue output dscp-map queue 4 threshold 1 8 mls qos srr-queue output dscp-map queue 4 threshold 2 9 10 11 12 13 14 15 mls qos srr-queue output dscp-map queue 4 threshold 3 0 1 2 3 4 5 6 7 no mls qos srr-queue input priority-queue 1 no mls qos srr-queue input priority-queue 2 mls qos srr-queue input bandwidth 90 10 mls qos srr-queue input threshold 1 8 16 mls qos srr-queue input threshold 2 34 66 mls qos srr-queue input buffers 67 33 mls qos queue-set output 1 threshold 1 138 138 92 138 mls qos queue-set output 1 threshold 2 138 138 92 400 mls qos queue-set output 1 threshold 3 36 77 100 318 mls qos queue-set output 1 threshold 4 20 50 67 400 mls qos queue-set output 2 threshold 1 149 149 100 149 mls qos queue-set output 2 threshold 2 118 118 100 235 mls qos queue-set output 2 threshold 3 41 68 100 272 mls qos queue-set output 2 threshold 4 42 72 100 242 mls qos queue-set output 1 buffers 10 10 26 54 mls qos queue-set output 2 buffers 16 6 17 61 priority-queue out srr-queue bandwidth share 10 10 60 20

The switch automatically maps DSCP values to an egress queue and to a threshold ID.

The switch automatically sets up the ingress queues, with queue 2 as the priority queue and queue 1 in shared mode. The switch also configures the bandwidth and buffer size for the ingress queues. The switch automatically configures the egress queue buffer sizes. It configures the bandwidth and the SRR mode (shaped or shared) on the egress queues mapped to the port.

Version 1.0 2.0

Date 2006 August, 2011

Contributor J. Rowley E. Heitmeier

Content Initial Release (AN130, AN131) Complete Update

21