Interrogation regarding pf + ALTQ
Hello list,
I'm performing some tests with pf & ALTQ here but before going further
on, they are some obscure points I would like to clear up in my mind,
that's why I hope some gurus available on this list will give me some
more information.
Here is how I understand the assignation to queues when the bsd_box is
acting as a gateway with two network interfaces:
...int_if(in) ext_if(ou)---
[station_a] [bsd_box]
[station_b]
---int_if(ou)ext_if(in)
Dotted lines represent incoming traffic that can't be assigned to the
queues defined on the interface (you can't shape incoming traffic).
Dashed lines represent outgoing traffic that can be shaped trough the
queues defined on the interface (outgoing traffic).
You are already welcome to correct me if I missed something on this point!
Some more details:
bsd_box is not acting as a firewall, it is only doing routing and
traffic shaping.
int_if is the internal interface connected to a 100Mbits switch with a
bandwidth of 100Mbits.
ext_if is the external interface connected to a 100Mbits switch with a
real bandwidth of 4Mbits (2Mbits up + 2Mbits down leased line) to the
outside world.
Here is what I want to do:
Shape the traffic according to the maximum bandwidth available for
both incoming and outgoing traffic on the leased line.
What I understand:
As I can't shape the traffic coming from station_b to station_a on the
ext_if, the only way for me to rate limit incoming traffic is to
define a queue with a maximum bandwidth of 2Mbits on the int_if but
what about the outgoing traffic on the external interface ? Is it
enough to define a queue with a maximum bandwidth of 2Mbits on the
ext_if ?
Some other interrogation:
When a packet is matching a state, is it still at least evaluated for queueing ?
As the bsd_box is not acting as a firewall, shoud I use a state table
entry for each interface (set state-policy runtime option) ? Will it
speed up the lookups in the table ? Is there any risk to drop/discard
the packets even if the default behaviour is pass all and that the
rule is using the quick keyword ?
Are there documents that clearly describes the flow of packets
crossing a bsd box running pf + ALTQ ?
Are there other tools than pftop and pfctl to help in debugging pf and
traffic shaping ?
You'll find below one my pf file for one of my router box.
I hope I was clear enough with my explanation and I want to thank for
the time you may spend on my interrogation.
Best Regards,
Benjamin Constant
Here is a stripped sample of what I did (I know they are difference
compared to my previous explanation), feel free to comment it if you
see strange things in it:
# See pf.conf(5) and /usr/share/examples/pf for syntax and examples.
# Required order: options, normalization, queueing, translation, filtering.
# Macros and tables may be defined and used anywhere.
# Note that translation rules are first match while filter rules are last match.
# Macros: define common values, so they can be referenced and changed easily.
# Interfaces ##
#
# We have two interface, int_if is connected to the local lan and also to the
# firewall which is located on the local lan.
# Interface ext_if is used for vpn traffic and is connected to vpn boxes on a
# different logical network.
#
###
int_if="em0"
ext_if="em1"
# Servers
proxy="ip"
support="ip"
sla="{ ips }"
# Site bandwidth available
#
#
###
bwdth="2048Kb"
# Tables: similar to macros, but more flexible for many addresses.
table persist file "/etc/pf.iprange.tiauto"
table persist
# Options: tune the behavior of pf, default values are given.
# Normalization: reassemble fragments and resolve or reduce traffic ambiguities.
#scrub log-all on $int_if all
#scrub log-all on $int_if all reassemble tcp
#scrub log-all on $ext_if all
#scrub log-all on $ext_if all reassemble tcp
# Queueing: rule-based bandwidth control.
altq on $ext_if cbq bandwidth $bwdth queue { internet, vpn, sla, dbg }
# Main children queues
#
# We have decided to split the traffic into 3 main queues as follow:
# - Internet queue is dedicated to internet traffic
# - Vpn queue is used for traffic between sites (trough vpn).
# - Sla queue is used as a quality of service queue for specific hosts
or services.
#
###
# Internet queue
queue internet bandwidth 512Kb priority 1 cbq { i_default, i_high }
queue i_default priority 5 cbq(borrow)
queue i_high priority 6 cbq(borrow)
# Default and vpn queue
queue vpn bandwidth 1Mb priority 2 cbq(default, borrow) { v_low,
v_mon, v_normal, v_high, v_critical, v_default }
queue v_low priority 4 cbq(borrow)
queue v_mon bandwidth 128Kb priority 4 cbq(ecn)
queue v_normal priority 5 cbq(borrow)
queue v_high priority 6 cbq(borrow)
queue v_critical priority 7 cbq(borrow)
queue v_default priority 5 cbq(borrow)
# Sla queue
queue sla bandwidth 5
Re: Interrogation regarding pf + ALTQ
Benjamin Constant wrote:
Hello list,
Hi Benjamin,
...int_if(in) ext_if(ou)---
[station_a] [bsd_box]
[station_b]
---int_if(ou)ext_if(in)
Dotted lines represent incoming traffic that can't be assigned to the
queues defined on the interface (you can't shape incoming traffic).
Dashed lines represent outgoing traffic that can be shaped trough the
queues defined on the interface (outgoing traffic).
Correct.
Shape the traffic according to the maximum bandwidth available for
both incoming and outgoing traffic on the leased line.
It's unnecessary to shape the incoming traffic; let those bits flow as
fast as possible. The only thing I would recommend is prioritizing
certain traffic as needed (i.e., interactive traffic, voice, etc).
Shaping the outbound is a good idea, however. You want to avoid the ISP
dropping packets that exceed the 2Mbps limit on the line.
What I understand:
As I can't shape the traffic coming from station_b to station_a on the
ext_if, the only way for me to rate limit incoming traffic is to
define a queue with a maximum bandwidth of 2Mbits on the int_if but
That's correct, but again, it's not necessary.
what about the outgoing traffic on the external interface ? Is it
enough to define a queue with a maximum bandwidth of 2Mbits on the
ext_if ?
Correct.
When a packet is matching a state, is it still at least evaluated for queueing ?
Correct.
Are there documents that clearly describes the flow of packets
crossing a bsd box running pf + ALTQ ?
http://mniam.net/pf/pf.png
altq on $ext_if cbq bandwidth $bwdth queue { internet, vpn, sla, dbg }
# Main children queues
#
# We have decided to split the traffic into 3 main queues as follow:
# - Internet queue is dedicated to internet traffic
# - Vpn queue is used for traffic between sites (trough vpn).
# - Sla queue is used as a quality of service queue for specific hosts
or services.
#
###
# Internet queue
queue internet bandwidth 512Kb priority 1 cbq { i_default, i_high }
queue i_default priority 5 cbq(borrow)
queue i_high priority 6 cbq(borrow)
# Default and vpn queue
queue vpn bandwidth 1Mb priority 2 cbq(default, borrow) { v_low,
v_mon, v_normal, v_high, v_critical, v_default }
queue v_low priority 4 cbq(borrow)
queue v_mon bandwidth 128Kb priority 4 cbq(ecn)
queue v_normal priority 5 cbq(borrow)
queue v_high priority 6 cbq(borrow)
queue v_critical priority 7 cbq(borrow)
queue v_default priority 5 cbq(borrow)
# Sla queue
queue sla bandwidth 512Kb priority 2 cbq(borrow)
# Debugging queue
queue dbg priority 2 { d_in, d_out }
queue d_in priority 5 cbq(borrow)
queue d_out priority 5 cbq(borrow)
Every CBQ queue MUST specify 'bandwidth'; this is enforced in OpenBSD
3.7. Also, look at enabling RED on your queues that contain TCP traffic.
.joel
RE: Interrogation regarding pf + ALTQ
> It's unnecessary to shape the incoming traffic; let those > bits flow as fast as possible. The only thing I would > recommend is prioritizing certain traffic as needed (i.e., > interactive traffic, voice, etc). > Shaping the outbound is a good idea, however. You want to > avoid the ISP dropping packets that exceed the 2Mbps limit on > the line. So in my case, the main advantage I could get of setting up traffic shaping on the internal side is to give some priorities / bandwidth sla to services available from behind the router. I doubt it will be very useful as the pipe available on the interface interface is a lot bigger than the pipe available on the external interface. > > Are there documents that clearly describes the flow of packets > > crossing a bsd box running pf + ALTQ ? > > http://mniam.net/pf/pf.png > Backup done :-) > Every CBQ queue MUST specify 'bandwidth'; this is enforced in > OpenBSD 3.7. Also, look at enabling RED on your queues that > contain TCP traffic. I'm using pf on a FreeBSD box actually but I will define bandwidth for each queue to stick as close as possible to the rules. By the way, are their other tools than pftop and pfctl that could help me to debug my rules ? Regards, Benjamin Constant. The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. This communication is from TI Automotive.
Re: Interrogation regarding pf + ALTQ
Constant, Benjamin wrote: By the way, are their other tools than pftop and pfctl that could help me to debug my rules ? Nothing comes to mind, but I'm not the best person to ask about that kind of thing as I don't use them. .joel
Re: Interrogation regarding pf + ALTQ
Constant, Benjamin wrote: By the way, are their other tools than pftop and pfctl that could help me to debug my rules ? We've been using "pfctl -vvsq" for quite some time to watch the distribution of traffic on our queues, and it worked OK for a quick view. Since we wanted something similar, but for longer time stretches, I wrote a probe for Symon (http://www.xs4all.nl/~wpd/symon/), that can monitor the traffic in each queue. Willem will try to incorporate it in the next release, or I can send you the patches if you are impatient. Cheers, martin
