[c-nsp] WRR Confusion on 6748 blades

Chris Evans chrisccnpspam2 at gmail.com
Tue Jun 26 16:28:30 EDT 2012


Tac is right. This is a downfall of ethernet switching qos. The buffers are
carved up for the queues. My advice is to disable qos altogether or remap
all traffic and buffers  back to one queue.
On Jun 26, 2012 4:22 PM, "John Neiberger" <jneiberger at gmail.com> wrote:

> I'm getting conflicting information about how WRR scheduling and
> queueing works on 6748 blades. These blades have three regular queues
> and one priority queue. We've been told by two Cisco TAC engineers
> that if one queue is full, packets will start being dropped even if
> you have plenty of link bandwidth available. Our experience over the
> past few days dealing with related issues seems to bear this out. If a
> queue doesn't have enough bandwidth allotted to it, bad things happen
> even when the link has plenty of room left over.
>
> However, someone else is telling me that traffic should be able to
> burst up to the link speed as long as the other queues are not full.
> Our experience seems to support what we were told by Cisco, but we may
> just be looking at this the wrong way. It's possible that the queue
> only seems to be policed, but maybe most of the drops are from RED.
> I'm just not sure now.
>
> Can anyone help clear this up?
>
> Thanks!
> John
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list