I'm not sure if you can limit any "one conversation." It's either you limit all, or limit based off of protocol, source, destination, or port. For example, if you shape on ftp traffic (21), anyone using port 21 will be shaped back to 128k in congestive times. Although it will be a shared 128k, and not guaranteed 128k slice for each user using that protocol/port.
Also, keep in mind that shaping is outbound only meaning if you have users using www, p2p traffic, downloading files etc, you'll have to police the traffic on the inbound side because all of those activities are seen as inbound to the outside interface if the session is started from the inside. If you run an FTP server or WWW server, shaping would help in that regard because the traffic is leaving your network and not entering.
You would generally shape both sides of the link, and if you don't have control of both sides, the only other option would be to shape outbound and police inbound to control the overall rate.
Joseph and Edison are very well versed, and they may have some better suggestions (as well as correcting me if I'm incorrect). ;-)
Thanks for the reply. Yes, you are right, I do want to limit all conversations to a max of 128k during a time of congestion. Port, destination, source, destination, protocol, etc doesn't matter. During a time of congestion, no conversation should be utilizing any more than 128k.
And I am only concerned about outbound conversations. I am not concerned about inbound.
The only way that I think you'll be able to shape based on congestion is by specifying acls and ports/protocols to shape that type traffic. I believe that if you put it under class default, you're going to be shaped all of the time.
You'll need to figure out what type of traffic you want to shape in congestion, and create your policy from that:
ip access-list ext Web
permit ip any any eq 80
permit ip any any eq 443
permit ip any any eq 20
permit ip any any eq 21
class match-any SHAPED
match ip address Web
shape average 128000
service-policy output OUTBOUND
You *might* be able to specify "permit ip any any" and no ports and still shape in congestion, but I'm not sure how "class-default" will play into that if you're matching all traffic in something other than default. Worth a try I guess.
I don't know of any way to accomplish this with Cisco's QoS. Shapers are generally active all the time, and they don't shape per flow unless you define one shaper per staticly defined flow attributes.
As for doing what you describe, it really doesn't make much sense even if you could do it. Without a fixed number of flows, you could easily not have enough bandwidth to provide 128 Kbps per flow, and if you did have enough bandwidth to provide that, there shouldn't be any congestion.
What you might consider doing is using fair queuing to insure when there's congestion every flow will might obtain the same amount of bandwidth. Fair queue will also allow flows that don't use their full allocation to yield the surplus to flows that want more than their allocation.
Fair queuing tends to work very well. There are some cases where you want to adjust fairness. This can be done with WFQ or with CBWFQ.
One problem you might encounter on your Internet circuits, ideally you want fair queuing on both in and out, but the in for your router needs to be set on the ISP's out.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...