QoS woes!

[ctmega]

I am seeing a weird issue with QoS on my ShoreTel network. I have Diffserv/TOS set to 184 and still occasionally see conversations that are not tagged. I am using omnipeek to capture the packets and 99% of my traffic is tagged but occasionally some phone-to-switch and switch-to-phone (ie... caller goes out over a PRI connected to a T1 device) is not tagged in either direction. On my Cisco switches I have tagged the ports that the switches are connected to and that seems to have addressed the issue from the switch to the phones but not vice-versa.

From what I understand the Diffserv/TOS setting in SWD is the only place to specify the 184 value. I would really like to know with certanty that packets are being tagged. Has anyone else run into this issue?

Any thoughts/help would be appreciated.

I DO have an open case with ShoreTel TAC.

[Jlorenz]

That would be correct,
A question, Do these Phones always not Tag? or for example See a Tag on one call then not on another?

If the later can you replicate this via a routing View Point?

What I mean is if the Phone call that is tagged is it being routed through another Route / Gateway / Etc, Etc

If the Call not being tagged is goiing out another direction?

Just something to look at. Technically once the phone is Rebooted and has the Info frm Call Control (aka Diff 184) the technically all calls should be tagged.

I will say, it just may be possible you found a bug

I am seeing a weird issue with QoS on my ShoreTel network. I have Diffserv/TOS set to 184 and still occasionally see conversations that are not tagged. I am using omnipeek to capture the packets and 99% of my traffic is tagged but occasionally some phone-to-switch and switch-to-phone (ie... caller goes out over a PRI connected to a T1 device) is not tagged in either direction. On my Cisco switches I have tagged the ports that the switches are connected to and that seems to have addressed the issue from the switch to the phones but not vice-versa.

From what I understand the Diffserv/TOS setting in SWD is the only place to specify the 184 value. I would really like to know with certanty that packets are being tagged. Has anyone else run into this issue?

Any thoughts/help would be appreciated.

I DO have an open case with ShoreTel TAC.

[duncan2424]

Switch Uplink Configuration - QoS trust

If you are using Cisco switches, the problem you are observing may be related to how the uplink ports between switches are configured.

Althought the phone may be correctly tagging its packets with the appropriate COS value, if the switch port is not configured to trust the device, then the COS values will be overwritten. Example:

switch#auto qos voip trust
or
switch#mls qos trust cos

This configuation must also be present on the links between switches or trunks so that switch A trusts the COS values it recieves from switch B without overriding those values.

QoS should be an end to end implementation. There might be a place along the various paths you have where this is not implemented. If this is not the case, then as previously mentioned, there could be a bug .

I hope this helps.

[drvoip]

QOS ShoreTEl

The CISCO Trust COS only apply to the transfer of 8021.p COS marks at the frame level to the IP TOS values and would have no impact on the ShoreTel DSCP markings. It is important to note that ShoreTel currently only marks DSCP on the media stream between phone end points, not on switch to switch or phone to switch connections. At the end of the day, the DSCP markings are of no value on your LAN. The only way to set precedence on a LAN is to use a VLAN tag and set the COS value in the Tag per the 802.1p specifications. In version 9 this is suppose to change, but I still dont see this being useful to LAN QOS. Also note that ShoreTel does not enable you to separately mark call setup messages.

[cburgy]

The CISCO Trust COS only apply to the transfer of 8021.p COS marks at the frame level to the IP TOS values and would have no impact on the ShoreTel DSCP markings. It is important to note that ShoreTel currently only marks DSCP on the media stream between phone end points, not on switch to switch or phone to switch connections. At the end of the day, the DSCP markings are of no value on your LAN. The only way to set precedence on a LAN is to use a VLAN tag and set the COS value in the Tag per the 802.1p specifications. In version 9 this is suppose to change, but I still dont see this being useful to LAN QOS. Also note that ShoreTel does not enable you to separately mark call setup messages.

This is inaccurate. Most enterprise grade switches will perform QOS based on the TOS header at Layer 3. They inspect the packets for the TOS value (DSCP is an extension of the original TOS standard to provide more quality levels). You can do this in Cisco switches with mls qos trust dscp. You'll want to pay more attention on the DSCP to COS mappings in Cisco because their switches do not have nearly as many hardware queues as some of the other solutions.

On HP, Foundry, Extreme, Enterasys and Juniper, they all do the same thing.

Version 9 doesn't change this behavior. 9.0 incorporates DSCP tagging from Shoreware Director. Previously, you need to use a switch or router to perform the marking for Shoretel from the server.

You also CAN mark the signaling traffic with a DSCP value. This is accomplished via the configuration files and is not currently available to configure via Director.

You can also setup 802.1P tagging if you so desire from the custom configuration files.... This was from the much earlier days before TOS matured and switches were performing QOS based upon TOS/DSCP.

[drvoip]

ShoreTel QOS on CISCO switches

Chris I dont log in here very often, so this is a late reply. I think we can agree on the difference between COS and TOS, frame and IP. Different manufactures will handle things differently. Quality of Service or QOS remains an interesting and challenging configuration for most engineers deploying VoIP solutions. Generally you are concerned about QOS on both your Local Area network (LAN) and your Wide Area Network (WAN). Though the principles and configuration for COS and DSCP markings are easily discoverable by anyone who takes the time to research these concepts, their application on various network components can be bit more challenging. Generally, QOS on a LAN makes use of COS bits in the VLAN tag and DSCP in the TOS byte of an IP packets for WAN router access. How these markings interoperate with different manufactures however, is really interesting. Take for example, the installation of ShoreTel equipment on Ethernet switches provided by CISCO.

Generally a CISCO QOS configuration is enabled with the command “mls qos” which is a global configuration command. What you need to understand is that this command calls into action a wide variety of switch characteristics that may or may not be applicable to your deployment. You need to know exactly what happens when this command is activated. You can not just “cut and paste” this configuration! For Example:

Mls qos trust device cisco-phone

Mls qos trust cos

These commands make use of CISCO’s proprietary discover protocol to know that an IP phone is connected to the switch port. Great if you are deploying CISCO phones, but what happens if you are deploying ShoreTel phones? This command tells the switch that QOS markings are to be trusted if they ORIGINATE by the phone. If they originate by the computer plugged into the phone, ignore it unless additional trust parameters enable it, Now, if a device other than a CISCO phone is connected to this switch port, guess what happens? The COS marketing are ignored and overwritten with a default COS of 0. This means that your ShoreTel phones will never get a TOS marking through to the Level 3 routers and you will wonder why your excellent QOS configuration is not working.

ShoreTel can mark the RTP media stream for QOS, assuming you set them up in Call Control Options. Generally, you will set this to a value of 0X2e or 46 in Decimal, the equivalent of CISCO Express Forwarding. However, when these packets hit the CISCO switch interface configured with the normally excellent CISCO QOS configurations it will trash your QOS down to best efforts. Take away: when using CISCO switches, TURN OFF AUTO QOS or; enter the following interface level command for each switch port: (config-if-range)#mls qos trust dscp

I would like to be able to mark the call control with a different calls then the media stream. ShoreTel does not make that easy to do. In many cases at this point, we are using ACL to classify traffic by source IP address. For example we do not see DSCP on media streams from the server, so we now use source IP address to assure these streams are put in the proper que. In any case it is an interesting area of VoIP and I enjoyed the dialog and opportunity to discuss the subject.