AutoQoS - on which port-types?

adamparanoid

Hello,

I'm going to configure AutoQos for about 40 Switches (2960,3560 and 6500) in a LAN to support Cisco VoIP telephony. On trunk-ports, I'm going to use the "auto qos voip trust" and on access-ports, where a Cisco IP phone (and a PC) are attached, I'll use "auto qos voip cisco-phone".
But what should I do with the other access-ports, where no Phone is attached? Maybe ports for printers or other types of clients... Should I configure nothing there? Or should I just issue "mls qos cos 0" or something like that..?

Thanks in advance.

PStefanov

When mls qos is enabled, by default all ports are untrusted. So leave the ports as they are. All markings will be automatically set to 0.

Pavel

kpjungle

Ofcourse, the access port where you are attached you want to set to CoS 7 or DSCP EF

networker050184

kpjungle wrote: »

Ofcourse, the access port where you are attached you want to set to CoS 7 or DSCP EF

That goes without saying

Paul Boz

I typically do simple switch QoS as you described, and do "real" QoS on access layer routers. I'm a proponent of L3 in the access layer for this reason.

cowood2676

Paul Boz wrote: »

I typically do simple switch QoS as you described, and do "real" QoS on access layer routers. I'm a proponent of L3 in the access layer for this reason.

Doing auto qos is fine and dandy but you have got to remember that you still may face congestion problems between your access layer, distribution, and core layers. In addition to using Cisco's Awsome QOS I also use a class map for all "uplinks" to avoide congestion. It looks like this.

Create the class:
Class-map VOICE
match rtp audio

Create the policy:
Policy-map MYVOICE
class VOICE
priority 150
class class-default
fair-queue

Apply the policy---on the interface
service-policy output MYVOICE


In short this gives voice a guarenteed 150K it will use more if it is available but it will never have less than 150...In times of congestion this will save you....apply it to every uplink out of the access and distribution layers.

this gives

_maurice

I am fairly new to QoS so please correct me if I'm wrong, but doesn't applying Auto QoS at all layers (access, distro, and core) degrade CPU performance since NBAR is used everywhere. Is it better to have NBAR used at the access layer, and trust markings at the distribution and core layers?

ilcram19-2

cowood2676 wrote: »

Doing auto qos is fine and dandy but you have got to remember that you still may face congestion problems between your access layer, distribution, and core layers. In addition to using Cisco's Awsome QOS I also use a class map for all "uplinks" to avoide congestion. It looks like this.

Create the class:
Class-map VOICE
match rtp audio

Create the policy:
Policy-map MYVOICE
class VOICE
priority 150
class class-default
fair-queue

Apply the policy---on the interface
service-policy output MYVOICE



this gives

in this config i will modify the follwing stuff

Create the class:
Class-map VOICE
match dscp ef
***i will also add this***
class-map SIGNALING
match dscp af31
match dscp cs3

Create the policy:
Policy-map VoIP
class VOICE
priority 135 *****depending on G711 (64k)or G729(8K)******Also make sure you add VPN overhead*****
class SIGNALING
priority 15

***but if the line is clable or DSL it is most commonly add a shaper otherwise there can still be some packet dropping****

class class-default
shape average 384000
service-policy VOICE
service-policy SIGNALING
fair-queue

Apply the policy---on the interface
service-policy output VoIP ****this is usually a WAN Link*****


Now when you talk about QOS there is different types of qos depending on the layer that we are talking about and the purpuse of it. example layer 2 TOS,COS layer 3 dscp and ip prec there are also some out there like the one above call LLQ, CBWFQ, WRR so you need to really do a research and testing and find out where to mark, classify and apply QOS policies