[c-nsp] 3560 QoS/shaping

[Jon Lewis]

On Thu, 15 Jan 2009, Brad Henshaw wrote:

>> you can't police the output of a port
>> you can't even define an output service-policy for a port.
>
> This is correct as far as I'm aware.

This is awfully disappointing considering the 3560 is supposed to be the 
successor to the 3550.

> You can try the 'srr-queue bandwidth limit' to rate-limit traffic on
> egress but this is only done at the port level for ALL traffic and has
> its own limitations as it's percentage-based.

In the general case for our usual usage of 3550s, that'll likely do.  The 
deployment I'm getting ready for now is a bit of a special case, and 
rate-limiting all traffic on an egress port won't cut it.

> The only option other than what you've suggested and the srr-queue 
> bandwidth limit is to apply ingress policers on all of the relevant 
> ports. You /might/ be able to get away with using an aggregate policer 
> in this situation but I have no idea whether this would be supported at 
> ingress on the 3560.

That also won't work in this special case, as the rate-limiting/shaping is 
only to be done on a class of traffic, and only if that traffic has to 
egress through a particular port.  Under normal conditions, the traffic 
won't need to be shaped.  Only when the prefered path becomes unavailable, 
will shaping on a backup path come into play.

> You'd need a 3750ME for anything much more advanced -- and even then,
> this functionality is limited to two of the gig ports. I think the
> 3400ME's support egress policies but they have their own limits and
> retardations in this respect.

The 6500 PFC3 can do policing on ingress/egress.  Is there anything 
between the 6500 and 3550 that does?

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________