cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
499
Views
12
Helpful
8
Replies

proirity bandwith for ftp uses over wan

samnil584
Level 1
Level 1

how can i arreange proirity bandwith for ftp uses over wan?

8 Replies 8

kerek
Level 4
Level 4

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

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

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.

Guys,

It is okay that PQ and LLQ are not the best choice, but I don't understand the " LLQ would impact your FTP (since its TCP)". How it could impact TCP?

Thanks,

Krisztian

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

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

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco