LAN QOS when IP Phone is not set to use/send QOS markings?

[Dean Romanelli]

Hi All,

So I have IP phones on my LAN, which connect to our VOIP host via the internet.  The phones are configured & set up by the VOIP host company and sent to us for LAN plug-in.  Our VOIP host does not use QoS markings on the phones themselves, so the phones do not send any DSCP markings.

If that is the case, there is no point in me configuring QOS on my switches to trust the DSCP correct?  If so, can I configure a policy on the switches to tag the VOIP packets with a dscp value to get it to the WAN edge reliably, and would it make sense to do so?

[Joseph W. Doherty · Accepted solution]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Correct, if none of your traffic has valid DSCP tags, not much point in trusting the DSCP tag.  BTW, if you don't trust the tag, and you enable QoS, many switches will then set the DSCP tag to zero.

Sure, if your switches support it, you can tag packets with the DSCP tag you believe they should have.  If your phone are using VLAN tagged CoS, you can often "translate" those to DSCP tags.

Whether it makes sense to do this depends on whether you ever intend to use DSCP tags with QoS polices.  (NB: you don't need DSCP tags to treat traffic differently.)

[Dean Romanelli]

Thanks Joseph. So if I have QOS enabled and trusting a DSCP value that never comes in, the switch is setting the DSCP marking to 0, which basically means best effort right?

My switches are the Cisco Small Business line, so I am going to say they probably don't support creating service policies for QOS marking, but not sure.  Also, for access points, I read that AP's do not construct internal DSCP values.  Does that mean that if the phones are not sending DSCP markings, the AP will not tag the traffic with the marking of my choosing if I wanted to do so?

The phones don't do COS either, unfortunately.

Is there a way I can still give my VOIP traffic priority in the switch without using DSCP/COS markings?

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

So if I have QOS enabled and trusting a DSCP value that never comes in, the switch is setting the DSCP marking to 0, which basically means best effort right?

Yes, DSCP zero is BE, but trusting DSCP means you accept what's there, i.e. you don't reset it.  Not trusting DSCP, on many Cisco switches, with QoS enabled, will set DSCP to zero.

Is there a way I can still give my VOIP traffic priority in the switch without using DSCP/COS markings?

Yes, there often is at least on Cisco Enterprise switches (and routers).  I'm unfamilar with Cisco's Small Business line switches.  On some "smart" switches, you can analyze the content of the packet and base QoS on that.  For example, VoIP bearer packets would likely be UDP, and might use only certain UDP ports.  Some Cisco devices, like some of their routers, support NBAR which can did deeper into the packets, and so allow you to, also for example, match SIP packets.

DSCP tags provide a fast/efficient way for QoS to "know" how to treat a packet.

[Dean Romanelli]

Thank you Sir.

[Dean Romanelli]

Joseph,

Another follow up on this one I just thought of: If I choose to tag the VOIP packets that arrive on my switchport with a service policy applied to said switchport which tags those packets with dscp ef and dscp cs3, then I don't need to configure that switchport with "trust dscp" in order for it to be preserved over to the trunk port for sending to the neighbor switch right?

[Joseph W. Doherty]

Correct.

BTW, you can have ingress service policy and trust dscp, if both, former takes precedence.  Also neither (directly) controls egress marking on an egress trunk.

[Dean Romanelli]

Excellent. 

And on that trunk port, all I need is mls qos trust dscp right? No need to configure service policy on trunk port itself right?

[Joseph W. Doherty]

Also correct, unless you have some need to analyze the ingress traffic.  (For example, an upstream switch that doesn't fully trust a downstream switch.)

[Dean Romanelli]

Ok, awesome.  Really appreciate all of your help Sir.  Thanks again.

[Dean Romanelli]

Hi Joseph,

As far as auto QoS goes, would that be the same as we are talking about here in that there is no point in setting up auto QoS on the switch if the phones are not sending markings? Or is auto QoS smart enough to recognize what is a VOIP packet and what is a data packet without using markings and appropriately prioritize?