Limiting outgoing SMTP bandwidth

[ts_sa_ryan]

Hi,

I have a network with a few mail servers, and I'm trying to prevent outgoing SMTP traffic from using all of our bandwidth and therefore interrupting other services such as web, ftp, etc.

Mail from all servers is sent through a filtering appliance, but unfortunately this appliance doesn't have any throttling controls. Therefore, I'm trying to resolve the issue by configuring our Cisco 2801 router.

I've read a lot about traffic shaping, policing, rate-limiting, and class-maps, policy-maps, etc. I'm a little confused on which would be the best option to either A) limit outgoing SMTP traffic to a specific maximum bandwidth amount, or B) give SMTP traffic a lower priority than any other traffic so that even if all bandwidth is used other traffic can still get through. I'm also not sure which interface the configuration should be applied to.

Can someone provide an example of the configuration necessary to simply limit outgoing SMTP traffic to 5 Megabit maximum of a 10 Megabit connection?

Here's what I tried, but I'm not sure if it accomplishes what I want or not:

class-map match-any SMTP_traffic

match protocol smtp

policy-map SMTP_shape

class SMTP_traffic

    bandwidth 5000

interface FastEthernet0/0 <==outside interface

ip address XX.XX.XX.XX 255.255.255.252

duplex auto

speed auto

no mop enabled

service-policy output SMTP_shape

Any help would be greatly appreciated. I'm not decided on setting a bandwidth limit vs. prioritizing the traffic, so I would appreciate any information regarding that choice as well.

Thank you!

[smitesh kharecha]

Hi Ryan,

Prioritizion is generally used when you have time sensitive or critical traffic.

Since, in your case it is SMTP traffic; which is generally not considered priority traffic.

Hence, traffic rate limit is the better solution.

Also, since you want to control the traffic of SMTP that the best solution.

Please rate if helpful.

HTH,

Smitesh

[sean_evershed]

Hi,

This is a useful article for comparing the merits of policing vs shaping.

If you don't want to start dropping mail after it exceeds your defined threshold then shaping would be a better option.

With policing you could remark your traffic to a lower priority. This will have little effect however since the markings will be ignored by your ISP.

http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

No, what you got won't do what you want but what you want might not be the best solution either.

Instead of limiting SMTP to 50%, setting a bandwidth allowance, I think, is a better approach.  What you have now will guarantee SMTP 50% of the bandwidth when there's congestion but if there's more available bandwidth, SMTP may use it.

You could try what you have and/or use what you have with a lower reservation for SMTP.

If you really want to cap SMTP bandwidth, you would add a shape or police command to the class, but again, if bandwidth is otherwise not being used why limit SMTP?

PS:

BTW, you might find just using FQ in class-default a good solution for all your traffic.

[ts_sa_ryan]

Thanks for the replies everyone.

When you say that my current configuration guarantees SMTP 50% when there's congestion, does that mean it LIMITS it to 50%? If not, it almost seems like I have it backwards...I should guarantee other protocols amounts of bandwidth so that if outgoing SMTP saturates our bandwidth, traffic such as http will be guaranteed some of its own bandwidth...

I've thought about it again, and here's what I would really like to accomplish: Outgoing SMTP can use all available bandwidth when it's available, but if other network traffic is present, SMTP needs to be limited in some way to ensure other services remain accessible. I believe shaping would be the best method to accomplish this, but I'm not sure. I've never done any type of Cisco configuration like this before, so if someone could write a rough example of the commands and I can modify the numbers, etc. that would be much, much appreciated.

So far, I'm thinking of changing my policy-map from:

policy-map SMTP_shape

     class SMTP_traffic

          bandwidth 5000

to:

policy-map SMTP_shape

     class SMTP_traffic

     shape average 5242880 <==assuming it wants it in bits

Then, with "show policy-map interface", I should be able to look and see if shaping is active at a given time. Does this sound like it will accomplish what I described above?

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Actually you're partially correct, as your policy doesn't define the bandwidth for the other traffic.  So, something like:

policy-map SMTP_shape

     class SMTP_traffic

          bandwidth percent 50

     class class-default

          bandwidth percent 50

You can adjust percentages to suit your needs.

NB: some of the older IOS version only allow you, by default, to explicitly defined up to 75% non-default.  Also of your IOS is new enough, you could add fair-queue to both classes, which I would recommend.

Again, with something like above, you shouldn't need to shape or police.

PS:

BTW, just FQ in class-default might work well for you.  Ethernet interfaces default to FIFO, which permits bandwidth hogs to be adverse to other traffic.

[ts_sa_ryan]

Joseph, thanks again for the reply!

I may just try fair-queue under the class-default if I'm not happy with the way this works out.

When classes are set to "bandwidth percent 50", what is it calculating 50% of? Do I need to define the available bandwidth of the interface first? Can I avoid doing that by specifying an amount of bandwidth rather than a percent? I would rather do percent, as our ISP allows us to temporarily exceed our alloted bandwidth.

This configuration only applies during periods of congestion, correct? How does the router determine when congestion is present?

Finally, am I right in explaining this configuration as follows: During periods of congestion, non-SMTP traffic will be guaranteed 50% of the available bandwidth and SMTP traffic will be guaranteed 50%. This way, if SMTP traffic hogs bandwidth, other traffic will be guaranteed 50%. If other traffic hogs bandwidth, SMTP will be guaranteed 50%. Therefore, neither SMTP nor other outgoing traffic should be able to totally "clog" our pipe.

[Joseph W. Doherty]

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not   be construed as rendering professional advice of any kind.  Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

I may just try fair-queue under the class-default if I'm not happy with the way this works out.

You may want to try it first as in allows all active flows to share bandwidth, by default, equally.

When classes are set to "bandwidth percent 50", what is it  calculating 50% of?

Whatever it believes the available bandwidth to be.  By default, should be the full (connected) bandwidth of your FastEthernet interface (i.e. 10 or 100 Mbps), but can be modified by the interface bandwidth statement or a shaper.

Do I need to define the available bandwidth of the  interface first?

Often no, if the (connected) bandwidth is the correct value.

Can I avoid doing that by specifying an amount of  bandwidth rather than a percent?

Yes.

I would rather do percent, as our ISP  allows us to temporarily exceed our alloted bandwidth.

That's interesting.  If you've subscribed to less than line rate, depending on provider handling of oversubscription and/or costing, you might want to shape.

This configuration only applies during periods of congestion, correct?

Yes, correct.

How does the router determine when congestion is present?

When packets queue.

Finally,  am I right in explaining this configuration as follows: During periods  of congestion, non-SMTP traffic will be guaranteed 50% of the available  bandwidth and SMTP traffic will be guaranteed 50%. This way, if SMTP  traffic hogs bandwidth, other traffic will be guaranteed 50%. If other  traffic hogs bandwidth, SMTP will be guaranteed 50%. Therefore, neither  SMTP nor other outgoing traffic should be able to totally "clog" our  pipe.

Correct.