traffic shaping for C2620 on IOS12.5

can anyone give me any tips on doing traffic shaping for our old 2620 router. what i'd like to do is to prevent one protocol (smtp) from using up all bandwidth on the serial0 (leased line).

our line mainly services dns, web and email (exchange2003). once in a while, when there are lots of email with large attachments going out, our leased line gets so congested that no web traffic can get in... what i'd like to do is to shape our traffic to allow email to consume at most 90% of the bandwidth if there's little other traffic going on. But will scale back to allow more traffic from other protocols (web in particular).

anybody can give advice or sample configs?

also, is it easy to monitor bandwidth consumption by protocol? i mean, using something like mrtg, can you monitor usage sorted by protocol?



- ron

Reply to
Ronnie Corny
Loading thread data ...


I'm not sure what IOS version you are using though as 12.5 does not exist, you will either have 12.1, 12.2, 12.3 or even 12.4 installed. If any of the following commands don't work then you may have to upgrade the software.

First you need to tell the router the bandwidth of the link:-

int s0/0 bandwdith 256

By default you can only prioritise up to 75% of the total interface bandwidth, this isn't ideal so you can configure the router to allow up to 90% to be used in your QOS policy:-

int s0/0 max-reserved-bandwidth 90

Create access-lists to define your applications (if you aren't hosting DNS or WWW then you can remove the indented lines):-

access-list 101 permit tcp any any eq www access-list 101 permit tcp any eq www any access-list 101 permit tcp any any eq 443 access-list 101 permit tcp any eq 443 any access-list 101 permit udp any any eq domain access-list 101 permit udp any eq domain any

access-list 102 permit tcp any any eq smtp access-list 102 permit tcp any eq smtp any

Now create class-maps which reference the access-lists:-

class-map match-any applications match access-group 101

class-map match-any smtp match access-group 102

Now create the QOS Policy:-

policy-map qos-policy class applications priority percent 40 class smtp priority percent 40 class class-default fair-queue

And apply it to your interface:-

int s0/0 service-policy output qos-policy

This policy will allow any application to use the full 256k, however, when the Interface becomes congested (you are transmitting more than

256k) the policy will allocate 40% of the bandwidth to your applications and 40% of the bandwidth to SMTP leaving 20% for anything else. Adjust the figures to match your environment.

Use the "show policy-map interface s0/0" command to see how much bandwdith is utilised in each class. You can use MRTG to query an OID which is associated with each class, to monitor the bandwdith utilisation of each class - however I have never set this up.

I hope this helps,


R> can anyone give me any tips on doing traffic shaping for our old 2620

Reply to

hi James

thanks for the tips... this really helps a lot...

you're right, i mistyped my IOS version... it's 12.3(5b)... haven't taken time to upgrade the IOS yet as i have to schedule the few minutes of downtime...


- ron

Reply to
Ronnie Corny

You shouldn't use priority command because it could lead to starvation of other traffic... This is suitable only for delay non-tolerant apps such as VoIP. You should use bandwidth percent command, but keep in mind that if prioritized traffic rate exceeds bandwidth percent rate this traffic becomes best effort if not otherwise specified, so it's suitable only for small bw traffic such as RDP and telnet, but it works relatively ok for http traffic in my case. So, if you want to absolutely ensure that smtp traffic doesn't eat all bw you have even if your prioritized classes exceeded their reserved bw then you must shape smtp traffic: instead of bandwidth percent, just type shape average under policy-map config mode. Of course, if there is a little amount of traffic other then SMTP this could be a wasting of bw since SMTP is no longer able to posses the whole bw even if there is no other traffic currently flowing trough the link.

B.R. Igor

Reply to
Igor Mamuzic


Warning - wandering a bit OT.

You can definately reduce the impact of this with QoS however you may also wish to consider looking at the source of the problem.

Maybe you are getting the following:-

I have seen Exchange fill up networks before.

This can happen if you are sending big e-mails to a lot of different addresses e.g. a mail-shot with an attached document.

The problem is that (Exchange 2000 numbers) by default MS in their wisdom have allowed exchange to have 10,000 sessions open simultaneously. When something like a mailshot arrives it tries to send too much at once.

Exchange system Manager/Administrative Groups/ First Administrative Group/Servers/your-server/ Protocols/SMTP/whatever-it-is/Right-click

Properties/Delivery/Outbound Connections

Limit number of connections 5 (was 10,000) " " per domain 2 (was bigger)

I just fancy these numbers as opposed to fewer since it protects you from a conection getting hung up stalling the mail queue forever.

By all means try a few more.

To exacerbate the problem observations that I have made suggest to me that the Windows 2000 Server (and others) TCP stack was broken which meant that the link was in fact incorrectly oversubscribed and even the mail did not get through.

Finally, if you are sending single e-mails to multiple addresses you can defer the break-out of these e-mails into individual mesasges. Typically the e-mail client sends a single message to the local e-mail server. It then breaks out the messages and sends the individual messages out. Alterntively - if you configure your server to relay messages via your ISP (say) you can defer this break-out process to the ISP's mail server. Under the circumstances described this can reduce your link traffic.

BTW - (Exchange 2000 again) Configuring a smart host on the "server" will not accomplish the deferal. You need to do it with a routing group.

YMMV with other exchange versions.

Reply to

Hi Igor and James

thanks for taking time to help out...

my main traffic is only http and smtp... with very minor domain (DNS) and others (ntp, ssh, etc.), would these be affected by the priority command?

I think our bandwidth consumption comes out like 95% smtp and the other 4% http and 1% all other protocols... i was thinking of getting a better read on this usage, that's why i was thinking of monitoring bandwidth consumption per protocol using mrtg...

what's the difference between "bandwidth percent 45" and "priority percent

45" in the policy-map?

I'd really like to get this right for our system... currently, i've got it set at "priority percent 45" but we haven't seen how it affects the line yet.


- ron

Reply to
Ronnie Corny

Hello Ronnie,

- 'bandwidth percent 45' command reserves 45% of interface bw in the case that interface is congested (there are some packets in the outbound queue or you may even see some outbound queue drops).

- 'priority percent' sends packets for that traffic class before the other traffic no matter if interface is congested or not. This could lead to starvation of other non-priority classes, but ensures so called low latency QoS because reduces latency at the minimum possible. So, it's mainly used for VoIP, because VoIP takes a little bw, but it needs a minimum latency possible. In both cases if traffic rate for those classes rises above 45 % of interface bw traffic then QoS stops and this traffic is treated as best effort unless otherwise configured.

You may wish to investigate:

formatting link
B.R. Igor

Reply to
Igor Mamuzic

hi Igor


so, in this case, my best bet is to change this the "priority percent" command to "bandwidth percent"? like - policy-map qos-policy class applications bandwidth percent 45 class smtp bandwidth percent 45 class class-default fair-queue

what i would like to happen is that when our mail server starts sending large amounds of email, is that it can consume as much bandwidth as it possible. But when there's any other protocol, it should be able to give up a little bit and allow other protocol up to 10% of bandwidth... and up 45% if that other protocol is http.

we don't run voip right now and our only traffic are smtp, http, ntp, dns, ssh and ssl...

i don't think our http traffic will ever cause any congestion... as our users don't use this line for normal use... the line is reserved for traffic outside our LAN...

i actually downloaded that qos config guide... but most of the qos samples seem to involve voice...

i'm also quite confused about the "shape command"... will slowly read up on it...

again, thanks for the advice...


- ron

Reply to
Ronnie Corny

that's right.... B.R. Igor

that's right....

B.R. Igor

Reply to
Igor Mamuzic Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.