Re: [c-nsp] 3560 QoS/shaping
Jon Lewis wrote: I'm configuring my first 3560s... 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. It appears the 3560-way to do this is to use srr-queue bandwidth shape on the interface, but the syntax for this command isn't nearly as flexible... Is this possible on the 3560? 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. 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. 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. Regards, Brad ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560 QoS/shaping
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 cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560 QoS/shaping
Jon Lewis wrote: 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. In that case I think you're boned. Can you kludge up a dedicated interface for this traffic (in this scenario) to egress? 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? Only the 3750ME (on ES ports) at any decent granularity that I'm aware of - others on the list might have more to add. From memory the 4948 can do rate-based shaping of its egress queues but that would likely require messing with DSCP markings and DSCP-queue maps. Regards, Brad ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560 QoS/shaping
Not that I am mentioning anything that hasn't been discovered, but here are two great articles about it: http://blog.internetworkexpert.com/2008/02/23/catalyst-qos-3550-explained/#more-81 http://blog.internetworkexpert.com/tag/3550/ Neither one of them answers your question, but I think with 3560 (and 3750 non uplink ports have the same capability) you might not police, but you can easily direct any packet marking into any of the four queues and through shaping you can control it. In other words, you get very similar capabilities to class based queuing. In other words, could you configure one shaped queue and then put all the packets there based on COS or DSCP and then even define thresholds for different traffic. And you can also allocate buffers for various queues. Another alternative to ingress policing is storm control. Yan From: Brad Henshaw brad.hens...@qcn.com.au To: Jon Lewis jle...@lewis.org; cisco-nsp@puck.nether.net Sent: Wednesday, January 14, 2009 10:12:31 PM Subject: Re: [c-nsp] 3560 QoS/shaping Jon Lewis wrote: I'm configuring my first 3560s... 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. It appears the 3560-way to do this is to use srr-queue bandwidth shape on the interface, but the syntax for this command isn't nearly as flexible... Is this possible on the 3560? 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. 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. 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. Regards, Brad ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560 QoS/shaping
What's the difference between normal and special condition. As in are you able to do something with it, where it could go either to a shaped queue or a shared queue based on its DSCP for example? From: Brad Henshaw brad.hens...@qcn.com.au To: Jon Lewis jle...@lewis.org Cc: cisco-nsp@puck.nether.net Sent: Wednesday, January 14, 2009 11:57:32 PM Subject: Re: [c-nsp] 3560 QoS/shaping Jon Lewis wrote: 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. In that case I think you're boned. Can you kludge up a dedicated interface for this traffic (in this scenario) to egress? 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? Only the 3750ME (on ES ports) at any decent granularity that I'm aware of - others on the list might have more to add. From memory the 4948 can do rate-based shaping of its egress queues but that would likely require messing with DSCP markings and DSCP-queue maps. Regards, Brad ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
