[c-nsp] cisco router 2800/3800 serie

[Peter Rathlev]

On Wed, 2009-08-26 at 11:06 -0400, Ryan West wrote:
> Can you elaborate a little more on the QoS portion.  It seems that the
> 3560 would be fine policing some traffic, but gets cryptic when you
> want to start shaping or provide bandwidth allocations.  Am I missing
> some obvious MQC support?

IMHO it's the 3560 that is missing some MQC support. :-)

You can do policing fine, though you are limited when defining your
class maps, where you can only match on one thing. If matching by IP ACL
only is acceptable this is no problem. If you expect matching on ACL and
something else (like DSCP), bad luck AFAIK.

This is probably because everything must fit in something that can
translate to TCAM entries. The upside is that everything's in hardware.

The shaping model on the 3560/3750 switches isn't the MQC HQoS way. It's
not a simple token bucket, so technically it's shaping; the shaping
works by reserving slots in the transmit scheduler combined with
reserving some part of the egress buffers. I haven't found anywhere
saying how deep the buffers on the 3560/3750 are (it's a combination of
seperate interface buffers (maybe just the tx ring?) and a "global" SRR
egress buffer) in bits, but I suspect that they're quite small. This
limits the shaping possibilities somewhat.

The SRR shaping works fine as a combined reserve/policy mechanism
though.

What taxes me the most is that the QoS configuration quickly becomes
very large for doing even simple things.

And that the default egress queue size configuration (even with QoS
disabled) seemingly aren't using up all available buffers. We have had
to enable QoS and just adjust egress queue sizes just so that a 100 mbps
port receiving data from a 1000 mbps port doesn't drop execessively.

Regards,
Peter