06-29-2007 02:04 AM - edited 03-03-2019 05:39 PM
how can i arreange proirity bandwith for ftp uses over wan?
06-29-2007 03:39 AM
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
06-29-2007 03:54 AM
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
06-29-2007 04:23 AM
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.
06-29-2007 05:08 AM
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
06-29-2007 12:23 PM
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
06-29-2007 01:02 PM
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.
07-01-2007 09:51 PM
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
07-01-2007 11:29 PM
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.
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: