Hi,

If you plan to use LLQ then:

class-map ftp

match protocol ftp

policy-map ftp

class ftp

priority xx

class-default

bandwidth remaining percent 100

interface serial y

service-policy output ftp

service-policy output ftp out

You can also use PQ.

priority-list 1 protocol ip high tcp ftp

priority-list 1 protocol ip high tcp ftp-data

priority-list 1 default normal

interface serial x

priority-group 1

mheusing Fri, 06/29/2007 - 03:54

Hi,

it is worth noting, that the "priority" Queue in the example above also polices the traffic. This is most likely not what you would like to do with FTP downloads.

So for TCP based applications it is usually more appropriate to use CBWFQ. The config would then look like this:

class-map match-all ftp

match protocol ftp

!the match statement here is using NBAR, make sure your IOS supports it.

policy-map ftp

class ftp

bandwidth xx

class-default

fair-queue

random-detect

interface serial y

service-policy output ftp

I would also not recommend PQ, as it does not set upper limits to your high priority traffic. This means basically a large FTP download could prevent ANY other traffic from being forwarded.

Hope this helps!

Regards, Martin

mohammedmahmoud Fri, 06/29/2007 - 04:23

Hi,

Totally agree with Martin, the embedded policing with LLQ would impact your FTP (since its TCP), and also if you use NBAR please make sure that CEF is enabled.

HTH,

Mohammed Mahmoud.

mheusing Fri, 06/29/2007 - 12:23

Hi,

With CBWFQ IP/TCP packets will be queued and not discarded, which will happen because of the policer. Dropped packets however will lead to reduced throughput for a TCP session. Thus in general for TCP based applications it is better to delay a packet than to drop it.

Regards, Martin

mohammedmahmoud Fri, 06/29/2007 - 13:02

Hi Krisztian,

I think that Martin has supplied a nice explaination for why LLQ is not recommended with TCP application (policing -> dropping -> global synchronization --> reduce throughput), and thus CBWFQ (queuing rather than policing) is better for TCP traffic, on the other hand voice traffic (delay sensitive UDP traffic) is vice versa.

HTH,

Mohammed Mahmoud.

Hi,

Thanks for the explanation it does make sense now. That's what I forgot the LLQ is almost the same as CBWFQ but use policing in its priority queue therefore cut the exceeding traffic and does not allow to burst or shape. That's why I like this forum, because if I write something stupid thing I will be corrected by others. :) There is proverb: The smart people learn from others mistake the stupid one from own.

Krisztian

mohammedmahmoud Sun, 07/01/2007 - 23:29

Hi Krisztian,

You are very welcomed :), i think that we are all here to interact and exchange knowledge and information, we all make mistakes and we all have wrong understandings of technical issues (there is no one who knows everything perfectly), but we are all here to interact and solve any technical issues, i think that all of us including me have mistaken before, but the glory of this forum is that there is always someone to correct the conflicts in a nice and professional way, thank you Rick, Paolo, Narayan, Sundar, Jon, Martin, Edwin, and everybody else including you Krisztian for making this forum professional and useful.

BR,

Mohammed Mahmoud.

Actions

This Discussion