I-Routes45,

Actually the configuration you posted initially does what you need to do, but definitely is not the best practice. Actually i would heavily not recommend that

Please note that the way you chose to do it is by picking a low latency queue to serve the smtp traffic every time there is smtp traffic on the network. That means that if you have a SMTP packet sitting in queue behind any other packet, that smtp packet will be served first.

Indeed by putting in priority 256 , this also means that the traffic is both guaranteed and policed to 256 kbits and cannot go over that value.

This type of setup with LLQ is used usually for sensitive traffic which cannot afford any drops (such as voice traffic). If in the future you need to put in voice or any other sensitive traffic on top of this network be aware that you already created an LLQ with 256kbits for your smtp traffic.

Definitely you do not need LLQ for smtp

I would rather go with the following setup

class-map match-any smtp

match protocol smtp

match access-group 199

!

policy-map limit

class smtp

bandwidth 256

police 256000 conform-action transmit exceed-action drop

class class-default

fair-queue

!

The above says that 256kbits will be guaranteed, but even if the bandwidth is free, it will not exceed 256kbits.

If you don't need any guaranteed bandwidth just drop the bandwidth statement.

Remember SMTP is not a delay sensitive protocol, so it's better to go this way as opposed to serving SMTP every time a packet is found in the queue, which will starve other traffic every time an email is sent

I'd advise you to read about LLQ and see for yourself if you really needed. My oppinion is you don't and is detrimental to you.

http://www.cisco.com/en/US/docs/ios/12_0t/12_0t7/feature/guide/pqcbwfq.html

"is this config ok if i want to limit the bandwidth for any smtp traffic anytime to 256K ? "

No, since the LLQ policer only activates when there's interface congestion. (I.e. SMTP could utilize full bandwidth) As other posters have noted, you would need to define policer (or shaper, though not mentioned by others) to insure data rate was always limited to 256 Kbps.

PS:

Other notes:

As an other poster has noted, you probably don't want to place SMTP into LLQ.

Your class-map smtp shouldn't need both match statements; either alone should work.

You don't need nbar protocol-discovery to use NBAR within your class-map.

Instead of limiting SMTP, you might want to just deprioritize it relative to other traffic. In this way, it can use otherwise available bandwidth, but not impede more important traffic.

e.g.

policy-map limit

class smtp

bandwidth 8

or

bandwidth percent 1

or

bandwidth remaining percent 1

class class-default

fair-queue