Cisco Support Community
Community Member

QOS input scheduling on 6K

I am looking for advice on how to best configure QOS for VoIP on a GigEtherChannel between two 6509s.

Most of the Cisco docs / case studies suggest configuring a trust DSCP state on core trunks, but this seems to be not ideal to me.

The QOS flowcharts confuse me somewhat, because the scheduling side is very unclear when the port is configured for any trust state other than 'trust-CoS'. The flowcharts suggest that no input scheduling takes place, and just shows the traffic going straight to the switching engine. This doesn't make sense to me, there must be *some* sort of queuing prior to the switching engine. Is it just a FIFO arrangement?

Doesn't it make sense to configure the core trunks to be 'trust-CoS' so that the benefits of strict priority queues etc can be used? I thought about using a trust CoS port state and also applying an ACE of trust DSCP, thereby getting input queue scheduling based on received CoS and still having the benefits of the DSCP granularity for output queue scheduling and policing (if needed in the future).

Any help would be much appreciated.

Phil Dotchon


Re: QOS input scheduling on 6K

The Url below is one of the best ones I have found for configuring Qos on a 6k. I hope that it is what you are looking for

Community Member

Re: QOS input scheduling on 6K

Thanks Beth, yes I've seen the config guides and they are generally good. I'm pretty convinced the best way to go is to configure core trunks as trust-cos, so that the benefits of strict priority queues and other scheduling features are used. It also seems reasonable to then apply a trust DSCP ACE to the port, so that any IP DSCP is preserved and used for output scheduling and policing.

What is disappointing is that there does not seem to be any Cisco documentation that discusses these points. For example, in a Layer 3 switched design, where core links are purely layer 3 routed, the design guides suggest configuring these ports/links as non-trunks, turn off VTP etc. But this seems to negate all the advantages of input port scheduling and make them FIFO queues! Why not make these links 802.1q trunks that carry just one Vlan and then the input scheduling will work properly. Surly Cisco has considered this option, so what are the pros and con's of doing this?!

Of course, if these are point to point links you could argue that the scheduling has already been done at the transmit end, so the traffic inbound at the remote end is already in the correct order. That’s fine until there is some congestion at the receiving end which causes Head of Line blocking.

Perhaps the only way to get this definitively answered to open a case, though I'd rather not go down that route for a number of reasons...



CreatePlease to create content