How to limit SMTP traffic trough router

Unanswered Question
Jan 26th, 2009


I know with class-map and policy-map we can limit smtp going through a router..

Please send me some example configuration


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
itdsmartnet Mon, 01/26/2009 - 03:02

here is the configuration.

class-map matchany SMTP_TRAFFIC

match protocol smtp

policy-map SMTP


bandwidth 1240000

then apply it on the interface e.g

int fastEthernet 0/0

service-policy input SMTP

Giuseppe Larosa Mon, 01/26/2009 - 03:04

Hello Anas,

SMPTP traffic uses well known port TCP 25 on the server side.

So knowing this and depending on the direction of traffic you can shape this traffic (or you can police but police actually drops packets)

access-list 111 permit tcp any any eq 25

if in direction to server

access-list 112 permit tcp any eq 25 any

if traffic is coming from server to users

class-map match-any SMTP_traffic

match ip address 111 112

policy-map shape-SMTP

class SMTP_traffic

shape average 128000 100000

when you need to apply the policy map outbound (shaping works only outbound)

int gi0/1

service-policy shape-SMTP out

Hope to help


Joseph W. Doherty Mon, 01/26/2009 - 06:07

Waseem's approach wouldn't limit your traffic, although a variation of what's shown could deprioritze SMTP traffic when there's congestion.


class-map match-any SMTP

match protocol SMTP

policy-map CBWFQ

class SMTP

bandwidth percent 1

interface ...

service-policy output CBWFQ

Giuseppe's approach caps your SMTP's bandwidth all the time and can only be used on output. A variation of his approach would be to use a police statement rather than a shaper statment. You would then have the option to limit traffic on input or output. Also, he's using ACLs for matching, but later IOS would, I believe, also allow NBAR match (as shown above).

Depending on your needs, don't forget you might need to control bandwidth demand in both directions.

Giuseppe Larosa Tue, 01/27/2009 - 08:30

Hello Joseph,

just two notes:

we have seen some threads of people complaining NBAR doesn't match the protocol they are looking for.

My understanding is that NBAR classification is on the server side (well known port).

So depending on the direction of traffic NBAR could also not match.

(this can be platform dependent)

I would use NBAR only with protocols that use dynamic ports of if already used for other traffic classes.

second note:

I had thought of a police approach but then I remembered that SMTP and e-mail is not supposed to be real-time service (oftern users think so and complain ).

So I would shape it instead of policing I don't see any issue in delaying the packets of an e-mail message.

Being TCP based also policing is useful because we cannot expect huge losses.

I think the target here is to limit bw usage from SMTP application on the link.

CBWFQ has the advantage of flexibility (but I never seen it applied inbound too) giving space to SMTP if the link is empty.

Of course this (shaping) can be done only outbound and so direction and position of the server becomes important.

Hope to help


Joseph W. Doherty Tue, 01/27/2009 - 16:45

Giuseppe, I use NBAR protocol matching extensively. Haven't noticed too many matching issues for the protocols it knows. (One issue I've encountered, NBAR for NetBIOS doesn't recognize port 445, only the original ports 137, 138, 139. Such as documented,

Of course, there's many protocols it doesn't know, where you either need to define custom NBAR or ACLs. However, it's certainly possible one could have issues using it that might be avoided by using an ACL.

You raise an interesting point about it only matches, for non-stateful NBAR, well known ports. However, I think it looks at both source and destination ports for the well known port number. If true, it should match against traffic to or from the server. I.e. which would be like a combination of the two ACLs you used.

My post didn't recommend NBAR rather than using an ACL, only that you could (assuming NBAR matches SMTP as we desire).

On your second point, using shaping vs. policing, I agree. My information, again, wasn't a proposal to police rather than shape, just that you could and it allows the option of being used for input. I normally much prefer shaping rather than policing.

(Never seen CBWFQ used inbound? Certainly much more common outbound. I've found using CBWFQ inbound a handy way to give me data rates for different types of traffic ingressing an interface without needing to tap something like NetFlow.)

I also agree SMTP shouldn't be real-time, so it's certainly reasonable to control it relative to other traffic. However, in such cases, I prefer depriorization over shaping or policing. Let more important traffic have the bandwidth, when it needs it, but why hold back SMTP if the bandwidth is available? The sample policy I posted will allow SMTP usage of full link bandwidth, yet only guarantee it 1% if there's contention for the link's bandwidth.

Giuseppe Larosa Wed, 01/28/2009 - 02:15

Hello Joseph,

thanks for your feedback on NBAR usage.

I have limited experience with it and having seen some threads with problems on matching I preferred to provide an advice.

Best Regards


anasatfirst Tue, 01/27/2009 - 10:40

Thanks to all for replying...

I need some document explaining on Police/bandwidth/priority commands of class map...

I have read something about them but I need to know the deference among them...

Thanks again


This Discussion