cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1565
Views
5
Helpful
8
Replies

How to limit SMTP traffic trough router

anasatfirst
Level 1
Level 1

Hi..

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

Please send me some example configuration

Thanks

8 Replies 8

itdsmartnet
Level 1
Level 1

here is the configuration.

class-map matchany SMTP_TRAFFIC

match protocol smtp

policy-map SMTP

class SMTP_TRAFFIC

bandwidth 1240000

then apply it on the interface e.g

int fastEthernet 0/0

service-policy input SMTP

Giuseppe Larosa
Hall of Fame
Hall of Fame

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

Giuseppe

Joseph W. Doherty
Hall of Fame
Hall of Fame

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

e.g.

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.

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

Giuseppe

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, http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6558/ps6616/prod_case_study09186a00800ad0ca.html.)

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.

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

Giuseppe

anasatfirst
Level 1
Level 1

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: