On 2007/02/27 12:31, Albert Chin wrote:
> I created a queue to limit traffic on the internal interface
> connecting 'EXTERNAL FIREWALL' to 'WWW/FTP SERVER':
> altq on fxp1 cbq bandwidth 1.5Mb queue \
> { queue_std, queue_ftp, queue_http }
>
> queue queue_std bandwidth 1.48Mb cbq(default)
> queue queue_ftp bandwidth 10Kb
> queue queue_http bandwidth 10Kb cbq(red)
>
> And, the rules allowing traffic to 'WWW/FTP SERVER':
> pass in log on fxp1 proto { tcp, udp } from any to any \
> port = domain keep state
> pass out log on fxp1 proto tcp from any to any \
> port = http keep state queue queue_http
> pass out log on fxp1 proto tcp from any to any \
> port = ftp keep state queue queue_ftp
> pass out log on fxp1 inet proto icmp all \
> icmp-type $icmp_types keep state queue queue_std
>
> From an external server, I attempted to download a file with curl
> using ftp and www from 'WWW/FTP SERVER' server. Curl reports that
> downloading via ftp shows no bandwidth limiting. As for www, the
> bandwidth seems limited to ~30Kb/s. Why isn't my 10Kb bandwidth being
> honoured?
You're queueing on the wrong interface to restrict outgoing
traffic. This is throttling _incoming_ traffic e.g. in your example
it's throttling requests and mainly ACKs; due to RED dropping these
ACKs you're probably triggering TCP congestion-avoidance.
You can assign traffic to queues based on _state created by rules
on fxp1_ (the state table entry includes the name of the queue to
place the associated packets in). But the actual queues are for
_outgoing_ traffic so they need to be on the interface applicable
for that (in your case fxp4).
For ftp, you are only assigning ftp _control_ traffic to a
queue, not the data connections. Since you're using ftp-proxy,
see the -q option.
