04-21-2009 12:26 PM - edited 03-04-2019 04:27 AM
Hi everyone,
is this config ok if i want to limit the bandwidth for any smtp traffic anytime to 256K ?
class-map match-any smtp
match protocol smtp
match access-group 199
!
policy-map limit
class smtp
priority 256
class class-default
fair-queue
!
interface FastEthernet0
ip address 69.x.x.x 255.255.255.0
ip nbar protocol-discovery
ip nat outside
service-policy output limit
!
interface Vlan1
ip address 10.x.x.x 255.255.255.0
ip nat inside
!
access-list 199 permit tcp any any eq smtp
!
end
Thank you
Solved! Go to Solution.
04-22-2009 06:49 AM
If you use a policy similar to the example shown in my prior post, you get the best. Your SMTP will effectively only obtain bandwidth not otherwise being used, but will be able to obtain all otherwise available bandwidth. I.e., almost no contention against other traffic but ablt to use full link bandwidth (if available).
04-21-2009 12:43 PM
priority =! limit
you need police.
__
Edison.
04-21-2009 12:48 PM
How ?
can you give me a simple example please?
04-21-2009 12:56 PM
Hi
In your case it will be.
policy-map limit
class smtp
priority 256
police 256000 conform-action transmit exceed-action drop
04-21-2009 02:43 PM
that means at anytime smtp got always and just 256k and all the other traffic got the rest of the bandwidth ?
is that okey ?
thank you
04-21-2009 09:56 PM
yeap!!
04-21-2009 10:11 PM
Priority 256 , is a policing in itself
"police 256000 conform-action transmit exceed-action drop" is redundant in this case
Information from Cisco website regarding "priority" command:
During congestion conditions, the traffic class is guaranteed bandwidth equal to the specified rate. (Recall that bandwidth guarantees are only an issue when an interface is congested.) In other words, the priority command provides a minimum bandwidth guarantee.
In addition, the priority command implements a maximum bandwidth guarantee. Internally, the priority queue uses a token bucket that measures the offered load and ensures that the traffic stream conforms to the configured rate. Only traffic that conforms to the token bucket is guaranteed low latency. Any excess traffic is sent if the link is not congested or is dropped if the link is congested. For more information, refer to What Is a Token Bucket?.
The purpose of the built-in policer is to ensure that the other queues are serviced by the queueing scheduler. In the original Cisco priority queueing feature, which uses the priority-group and priority-list commands, the scheduler always serviced the highest priority queue first. In extreme cases, the lower priority queues rarely were serviced and effectively were starved of bandwidth.
The real benefit of the priority command-and its major difference from the bandwidth command-is how it provides a strict de-queueing priority to provide a bound on latency. Here is how the Cisco IOS Configuration Guide describes this benefit: "A strict priority queue (PQ) allows delay-sensitive data such as voice to be de-queued and sent before packets in other queues are de-queued." Let's look at what this means.
For information check:
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080103eae.shtml#prereq
Look at comparison table between bandwidth and priority commands.
04-21-2009 10:02 PM
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
04-22-2009 03:28 AM
"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
04-22-2009 05:19 AM
thank you guys
it was very helpful
i asked the question because i m doing mass mail several times in the day and my smtp server is taking all the bandwitdth when i do that, so i just wanted it to not take more than 256k and leave the rest of the bandwitdth to other traffic.
shoul the shaping also help ? or i m good just with the bandwitdh and police command ?
04-22-2009 06:49 AM
If you use a policy similar to the example shown in my prior post, you get the best. Your SMTP will effectively only obtain bandwidth not otherwise being used, but will be able to obtain all otherwise available bandwidth. I.e., almost no contention against other traffic but ablt to use full link bandwidth (if available).
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide