Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

limiting bandwidth for protocol smtp

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

1 ACCEPTED SOLUTION

Accepted Solutions
Super Bronze

Re: limiting bandwidth for protocol smtp

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).

10 REPLIES
Hall of Fame Super Bronze

Re: limiting bandwidth for protocol smtp

priority =! limit

you need police.

__

Edison.

Community Member

Re: limiting bandwidth for protocol smtp

How ?

can you give me a simple example please?

Community Member

Re: limiting bandwidth for protocol smtp

Hi

In your case it will be.

policy-map limit

class smtp

priority 256

police 256000 conform-action transmit exceed-action drop

Community Member

Re: limiting bandwidth for protocol smtp

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

Community Member

Re: limiting bandwidth for protocol smtp

yeap!!

Community Member

Re: limiting bandwidth for protocol smtp

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.

Community Member

Re: limiting bandwidth for protocol smtp

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

Super Bronze

Re: limiting bandwidth for protocol smtp

"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

Community Member

Re: limiting bandwidth for protocol smtp

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 ?

Super Bronze

Re: limiting bandwidth for protocol smtp

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).

573
Views
4
Helpful
10
Replies
CreatePlease to create content