You are on page 1of 21

Application Note

ST AppNote 10325 (AN 10325)


August 17, 2011

Best Practice Recommendations for


VLANs and QoS with ShoreTel

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

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 manufacturer’s 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.

3
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 ROUTER CONFIGURATION
interface FastEthernet2 interface FastEthernet 0/0.10
switchport access vlan 10 encapsulation dot1q 10
interface FastEthernet3 ip address 1.1.1.1 255.255.255.0
switchport access vlan 10 interface FastEthernet 0/0.20
vlan 20 name HR encapsulation dot1q 20
interface FastEthernet4 ip address 2.2.2.1 255.255.255.0
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

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 it’s 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 administrator’s 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”.

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

6
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 vendor’s 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)

7
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

8
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 Server’s 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 phone’s 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”.

9
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 LAN’s
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 newer-
model 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 Cisco’s “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 Cisco’s “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 ** Defines the “VoIP Audio” class of traffic
match ip dscp ef ** Tells it to match anything already marked as EF (184)
match protocol rtp audio ** Tells it to also match any other RTP/Audio traffic

class-map match-any VIDEO_UNIT ** Defines the “Video” class of traffic


match access-group 102 ** 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 ** Define a policy map and give it the name “VOIP”
class VOIP_AUDIO ** Assigns the VOIP_AUDIO class the following:
priority percent 15 ** - Place voice in the highest priority queue and
** reserves 15% of the bandwidth for VoIP
set dscp ef ** - Make sure it stays marked with EF as it goes through the WAN

class VIDEO_UNIT ** Assigns the VIDEO_UNIT class the following:


bandwidth 20 ** - Reserve 20% of the bandwidth for the video units
set dscp af41 ** - Make sure it stays marked with medium-high priority to the WAN

class CALL_CONTROL ** Assigns the CALL_CONTROL class the following:


bandwidth 10 ** - Reserve 10% of the bandwidth but do not place in priority queue
set dscp af31 ** - Make sure it stays marked with medium level priority to the WAN

class class-default ** States all traffic not matching the above use the default
set dscp default ** Make sure it is marked with DSCP 0 (best effort) to the WAN
fair-queue ** Use Cisco’s 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 103 remark : ShoreTel VoIP Call Control and CSIS
access-list 103 permit udp any any range 5440 5448
access-list 103 permit udp any any eq 2427
access-list 103 permit udp any any eq 2727
access-list 103 permit tcp any any eq 111
access-list 103 permit udp any any eq 111
access-list 103 permit tcp any any eq 5440
access-list 103 permit tcp any any eq 31453 ** Only for Contact Center
access-list 103 permit 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 ** 32% drop rate BAD!!

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 ** 0 Drops is good!

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 ** 0 Drops is good!

Class-map: class-default (match-any)


84557179 packets, 14841300472 bytes
5 minute offered rate 52000 bps, drop rate 0 bps
Match: any

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 carrier’s 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 let’s 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 provider’s 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 Automatically Generated Command {voip}


The switch automatically enables Switch(config)# mls qos
standard QoS and configures the
CoS-to-DSCP map (maps CoS mls qos map cos-dscp 0 8 16 26 32 46 48 56
values in incoming packets to a
DSCP value).
The switch automatically maps no mls qos srr-queue input cos-map
CoS values to an ingress queue mls qos srr-queue input cos-map queue 1 threshold 2 1
and to a threshold ID. 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
The switch automatically maps no mls qos srr-queue output cos-map
CoS values to an egress queue mls qos srr-queue output cos-map queue 1 threshold 3 5
and to a threshold ID. 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
mls qos srr-queue output cos-map queue 4 threshold 3 0

The switch automatically maps no mls qos srr-queue input dscp-map


DSCP values to an ingress queue mls qos srr-queue input dscp-map queue 1 threshold 2 9 10 11 12 13 14 15
and to a threshold ID. 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

The switch automatically maps no mls qos srr-queue output dscp-map


DSCP values to an egress queue mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47
and to a threshold ID. 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

The switch automatically sets up no mls qos srr-queue input priority-queue 1


the ingress queues, with queue 2 no mls qos srr-queue input priority-queue 2
as the priority queue and queue 1 mls qos srr-queue input bandwidth 90 10
in shared mode. The switch also mls qos srr-queue input threshold 1 8 16
configures the bandwidth and mls qos srr-queue input threshold 2 34 66
buffer size for the ingress queues. mls qos srr-queue input buffers 67 33

The switch automatically mls qos queue-set output 1 threshold 1 138 138 92 138
configures the egress queue mls qos queue-set output 1 threshold 2 138 138 92 400
buffer sizes. It configures the mls qos queue-set output 1 threshold 3 36 77 100 318
bandwidth and the SRR mode mls qos queue-set output 1 threshold 4 20 50 67 400
(shaped or shared) on the egress mls qos queue-set output 2 threshold 1 149 149 100 149
queues mapped to the port. 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

Version Date Contributor Content


1.0 2006 J. Rowley Initial Release (AN130, AN131)
2.0 August, 2011 E. Heitmeier Complete Update

21

You might also like