Professional Documents
Culture Documents
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
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.
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.
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.
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:
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.
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.
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.
17
WAN INTERFACE CONFIGURATION
# show policy-map interface ser0/0
...
Serial0/0/0
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”
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
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
21