So, it appears that while we can configure two priority queues, IOS ends up combining them into a single priority queue. Is that correct?
This seems to make some sense given the definition of 'priority queue'. How could you give absolute priority to two separate queues? If that's the case, then you definitely would want to place voice traffic in the priority queue by itself. Perhaps then use the 'bandwidth' queueing command for video traffic and then WFQ with or without WRED for the rest of the traffic. Then again, when configuring LLQ, we are not configuring an absolute priority queue. In this case, the priority queue is good up to a certain point, limited by the amount of bandwidth apportioned to that queue. Let's say we have created a 384k PQ but we have a full T-1 available. This simply means that any traffic in that queue gets absolute priority UP TO 384k. Anything over that gets dropped. It seems to me that this leaves a lot of room for other priority queues. Why should we not be able to create yet another PQ with 384k, for example? In my mind this would mean that for a given cycle, the two priority queues would each get 384k of the 1544k available for output. However, I think this highlights the issue. We now have two priority queues and they can't be serviced at the same time, unless some sort of interleaving were possible. Hmmm.....food for thought. Queueing is just so much fun. :-) John >>> "VoIP Guy" 12/6/01 6:40:40 AM >>> I like to learn, so forgive me if I am beating this subject, but in order for me to become a CCIE, I need to know everything. I've been reading up on the real story on two priority queues, been asking a couple of CCIE's and been on CCO. Just as I suspected, there is only 1 PQ in LLQ, or any queuing method for that matter. If you enter two (or more) different classes to have strict priority, the all enter the same priority queue. To quote from Cisco: "...The Low Latency Queueing feature provides strict priority queueing for CBWFQ, reducing jitter in voice conversations. Configured by the priority command, Low Latency Queueing enables use of a single, strict priority queue within CBWFQ at the class level, allowing you to direct traffic belonging to a class to the CBWFQ strict priority queue. To enqueue class traffic to the strict priority queue, you configure the priority command for the class after you specify the named class within a policy map. (Classes to which the priority command is applied are considered priority classes.) Within a policy map, you can give one or more classes priority status. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is enqueued to the same, single, strict priority queue...." Here is the link for surther study. http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120 t/120t7/pqcbwfq.htm I am still researching Mike's claim that states that fast-switching bypasses the counters for the queue. I will set up an experiment later on today in the lab. I know for a fact that with fast-switching, there still are queues, but maybe Mike's right in stating that the counters aren't used. I'll let you know. Steve ""Steve Ridder"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > It definitly works, but I've always been told to use 1 priority queue for > voice, then CBQ the SNA and video and WFQ with WRED on the rest. > > They say voice is most important because it has the highest human > perception, and humans will notice bad voice before bad video. > > Steve > > > ""John Neiberger"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > I can immediately think of one example. Let's say you have a T-1 access > > link with multiple data types that include VoIP and video conferencing. > > You want to make sure that VoIP traffic gets its own priority queue, so > > let's say you give it 384k. You then want to give the video > > conferencing traffic another priority queue because it's such a > > high-visibility technology, so you allow it to use another 384k. > > > > This would leave roughly half of the link available for other data > > types during periods of congestion while making sure your high priority > > applications (pun intended) do not drop packets and have the lowest > > latency possible on that link. > > > > I will be attempting exactly this sometime next year when we roll out > > VoIP to a branch that already has video conferencing. To make matters > > more interesting, this is on a frame relay link, not a point-to-point > > link. Lotsa fun! > > > > I had heard, though, that only one priority statement was possible. > > You're saying that you successfully used two? That's good news for me, > > I was starting to get worried. I'd be interested to find out if it > > truly behaved as expected when experiencing congestion. If you test > > this out, please let us know what you find. > > > > Regards, > > John > > > > >>> "VoIP Guy" 12/5/01 1:51:13 PM >>> > > Has anyone ever seen 2 priority queue's in LLQ? What would be the > > reason > > and how would those 2 get serviced? Round Robin? FIFO? It does work > > beucasue I just saw it on a config and tried it myself, but can't > > figure out > > why they did it. > > > > Steve Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=28291&t=28227 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
