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