here is the configuration.
class-map matchany SMTP_TRAFFIC
match protocol smtp
then apply it on the interface e.g
int fastEthernet 0/0
service-policy input SMTP
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
shape average 128000 100000
when you need to apply the policy map outbound (shaping works only outbound)
service-policy shape-SMTP out
Hope to help
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
bandwidth percent 1
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.
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.
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, 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.
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.
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...
if you are going to use a router
QoS config guide for 12.4
and enterprise QoS SRND
Hope to help