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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
