Shaping down to 128k

Unanswered Question
Apr 9th, 2009
User Badges:

Hello, I've done some reading on the discussion forum and see many people wanting to shape a circuit down to a certain speed. However, I'm looking to shape in a bit of a different way.

We have a couple 3MB internet circuits and during a time of congestion, I want to limit any one conversation on the link to a max of 128k. During non-congested times, anything goes.

From what I research, I want to shape rather than police, as I don't want packets dropped and I am OK with the delay as packets are queueed with shaping.

Is anybody else out there doing this?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
John Blakley Thu, 04/09/2009 - 05:39
User Badges:
  • Purple, 4500 points or more

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). ;-)


HTH,

John

mruhenkamp Thu, 04/09/2009 - 05:49
User Badges:

John,

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.

John Blakley Thu, 04/09/2009 - 06:01
User Badges:
  • Purple, 4500 points or more

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


policy-map OUTBOUND

class SHAPED

shape average 128000


int fa4

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.


HTH,

John

Joseph W. Doherty Thu, 04/09/2009 - 14:06
User Badges:
  • Super Bronze, 10000 points or more

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.

Actions

This Discussion