On 27/11/17 10:11, Stuart Henderson wrote:
The state entry is "tagged" with the queue name. If a packet matches
the state, when it's transmitted, if a queue with that name exists on
the outgoing interface, it's used to restrict the traffic.
So you can simply setup queues like "queue mail on em1 ..." and assign
traffic with "match to port 25 queue mail".
So if i understand you correctly, this no state business is not needed?
So with $webserver living behind $dmzIf and the internet being behind $extIf
which of the following would achieve bandwidth shaping of both requests
and responses.
Version 1, Version 2, either one or neither?
# inbound
queue qIn on $dmzIf bandwidth 12M
[...]
queue qiWeb parent qIn bandwidth 499K min 100K max 1M
queue qiPri parent qIn bandwidth 500K min 100K burst 1M for 1000ms
# outbound
queue qOut on $extIf bandwidth 1M
[...]
queue qoWeb parent qOut bandwidth 300K min 30K
queue qoPri parent qOut bandwidth 150K min 30K burst 300K for 1000ms
# Version 1
pass in quick on $extIf proto tcp from any to $webserver port 80
# requests
pass out quick on $dmzIf proto tcp to $webserver port 80 \
set queue (qiWeb, qiPri) set prio (4,5)
# responses
pass out log quick on $extIf proto tcp from $webserver port 80 \
set queue (qoWeb, qoPri) set prio (4, 5)
# Version 2
# requests
match out on $dmzIf proto tcp to $webserver port 80 \
set queue (qiWeb, qiPri) set prio (4,5)
# responses
match out on $extIf proto tcp from $webserver port 80 \
set queue (qoWeb, qoPri) set prio (4, 5)
pass in quick on $extIf proto tcp from any to $webserver port 80
--
Mit freundlichen Grüßen/Best Regards
Mario Theodoridis
