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 whatsoever (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
Joseph, it is indeed one LLQ, however, the LLQ consists of 2 priority queues. In essence, I'm asking whether a priority queue, can discriminate against packets with DSCP values of different drop priorities. Truncated configuration below:
Michael, you don't have two priority queues, you have two LLQ classes that map into the single/same LLQ. (I'm fussing over terminology, because there was [still?] PQ for software routers and PQ on many Catalyst switches. LLQ isn't exactly PQ because it has implicit policers.)
I also understand, I believe, what you are trying to acheive, which is to have different drop preferences (per DSCP marking), within the same LLQ class, when there's congestion. I didn't recall any such features when I wrote my initial post, but at that time I was at home and couldn't check. Just now, I logged onto an ISR running 12.4(24)T3, which supports HQF, and setting a class to LLQ precludes many other egress options. I also tried defining a service-policy in the LLQ class, but again, child policy egress features are rejected because the parent class is a LLQ class.
As you wondered in your original post, you might be able to obtain the behavior you desire using a non-LLQ class. To mimic LLQ de-scheduling behavior, you could set the bandwidth for that class very high, perhaps 99%, and police or shape to keep from monopolizing all the bandwidth. If you shape, which will queue overrate traffic, you could then use a child policy with WRED and set different drop preferences per DSCP marking.
e.g.
class-map match-any Priority
match dscp af43
match dscp af42
match dscp af41
match dscp cs3
match dscp ef
policy-map Priority-drops
class class-default
random-detect dscp-based
policy-map ato-gig-ipl-out-child
class NETWORK
bandwidth remaining percent 99
set dscp cs6
class Priority
bandwidth percent 99
shape average percent 30
service-policy Priority-drops
