Where can I get more details on the options available to me?

The QoS section of the configuration guide for your IOS would be a good place to start.

E.g.

http://www.cisco.com/en/US/docs/ios/qos/configuration/guide/12_4/qos_12_4_book.html

so what would be the best option to take for this:

we have bursts of SMPT traffic going outbound.

When this bursts happens, the inbound HTTP is considerably slowed down and in some cases the HTTP is timing out.

What QoS, if any, is configured now? If none, did you try the shaper from my first post?

If the shaper alone doesn't cure the problem, I would next deprioritize SMTP, if you're positive it's the cause of your slow downs.

e.g.

class-map match-any Background

match protocol smtp

policy-map Yourname

class Background

bandwidth percent 1

class class-default

fair-queue

policy-map Shaper

class class-default

shape average percent 45

service-policy Yourname

interface FastEthernet#/#

service-policy output Shaper

no i have not tried the shapper as I'm unsure where to put it... on the WAN or LAN side?

Fa3/0 is WAN and G0/1 is LAN

is this correct?

class-map match-any SMTP_TRAFFIC_SHAPPING

match protocol smtp

!

!

policy-map PM-SHAPPER

class SMTP_TRAFFIC_SHAPPING

bandwidth percent 75

class class-default

fair-queue

policy-map SHAPPER

class class-default

shape average percent 75

service-policy PM-SHAPPER

Then I add:

service-policy output SHAPPER to the External WAN interface Fa3/0 ?

But what I dont understand is why have 2 policy-map but only 1 is applied to the interface?!?

You want to place policy on your outbound Ethernet interface, also configured for outbound.

i.e.

fastethernet3/0

service-policy outbound SHAPPER

The reason for two policies, one is nested within the other. The outer controls the overall data rate, the inner controls how congestion is managed.

PS:

If your link is 100 Mbps, but you're only supposed to use 50, you want to shape to insure a) you don't exceed the 50, b) you account for Ethernet overhead. (10% less than nomimal rate is a good place to start.)

Since you believe SMTP is what's causing the poor web performance, we want to guarantee it little bandwidth, but allow it to use more if the bandwidth is otherwise not being used.

i.e.

policy-map PM-SHAPPER

class SMTP_TRAFFIC_SHAPPING

bandwidth percent 1 adjust up if too little but at the expense of other traffic

class class-default

fair-queue

policy-map SHAPPER

class class-default

shape average percent 45 50 Mbps - 10% = 45 Mbps or 45% of 100

service-policy PM-SHAPPER

so if I want to keep 75% of available bandwidth for SMTP and 25% for web, is my bellow ok?

And how do I monitor to make sure this is what's going on?

class-map match-any SMTP_TRAFFIC_SHAPPING

match protocol smtp

!

!

policy-map PM-SHAPPER

class SMTP_TRAFFIC_SHAPPING

bandwidth percent 75

class class-default

fair-queue

policy-map SHAPPER

class class-default

shape average percent 75

service-policy PM-SHAPPER

So after some thoughts, maybe i should garantee bandwidth to HTTP instead of SMTP ? As you can see, im a litle confused... when I see outbound SMTP spikes, my page loads for inbound HTTP go from 2-3 seconds to well over 15 seconds.

So maybe I should garantee a maximum bandwidth to web and allow SMTP to use what's available whichout windering HTTP traffic inbound?

The policies I've posted will give HTTP much more bandwidth than SMTP.

Thanks Joe,

Yesterday, before I left, I changed the settings to match yours exactly:

class-map match-any SMTP_TRAFFIC_SHAPPING

match protocol smtp

!

!

policy-map PM-SHAPPER

class SMTP_TRAFFIC_SHAPPING

bandwidth percent 1

class class-default

fair-queue

policy-map SHAPPER

class class-default

shape average percent 45

service-policy PM-SHAPPER

Although, when spikes happen, I am still getting some http and https timeouts...

Sorry for the delay in responding - I was out-of-town last 3 days (w/o Internet access).

This is the type of situation that's hard to diagnose without seeing it. For instance, we're only managing outbound traffic and often the problem is caused by inbound congestion too. Also, we're working on your assumption that just SMTP is causing the issue.

It might help if you can post interface stats and policy stats when the issue arises (i.e. sh interface and show policy-map interface).