ALTQ with IPFW

[Niki Denev]

Brian Fundakowski Feldman writes:

> Since I've seen some desire for ALTQ support for IPFW, and I've personally 
> been interested in using the more complex traffic shaping topology that it
> provides, I decided to go ahead and get it working.  I had to use mlaier's
> un-committed dc(4) ALTQ support, too, which seems to work.  The ipfw(8)
> program now queries pf(4) for ALTQ queue id <-> queue name translation,
> so you would first use pfctl(8) to set up the queues before adding IPFW
> "altq" rules.
>    The "altq" rule action acts much the same way as "count," but it
> additionally adds the queue identification to the packet before it
> lets it go on to the next rule.  This is all that is necessary for
> using IPFW for traffic classification, but complications arise with
> natd (IP divert sockets), so I decided it would be helpful to be
> able to identify traffic that natd has emitted.
>    In order to do this, new match options are added so you can match
> all diverted packets, diverted packets destined to egress, or diverted
> packets destined to ingress.  This adds an additional mbuf tag
> allocation to the divert input operations which did not have it already
> but is otherwise not very invasive.  It's still not easy to understand
> at a glance how the interaction of ALTQ/IPFW/natd goes, so I hope I can
> come up with some clear documentation soon.
>    Here is an example firewall ruleset (the one I'm using at home to
> start with), and ALTQ ruleset, that I use in the order: kldload pf,
> pfctl -f pf.conf, ipfw ipfw.conf.  The ALTQ system can be turned on
> without turning pf on, so there is not as much overhead as using
> both firewalls at once.  It is also worth noting the kernel patch
> includes some unrelated new TCP sockopts.
> 
> pf.conf:
> altq on dc0 cbq bandwidth 128Kb qlimit 10 queue { default_local, natted }
> queue default_local bandwidth 50% qlimit 5 priority 3 cbq(default ecn borrow)
> queue natted bandwidth 50% qlimit 5 priority 2 cbq(borrow)
> 
> ipfw.conf:
> # Enable one_pass optimization (no dummynet used).
> enable one_pass
> # Turn on ALTQ.
> enable altq
> # Make all traffic natd reinserts start after the divert section.
> add 10 skipto 500 ip from any to any diverted
> # Set up ALTQ classification for locally-generated egress traffic.
> add 100 altq default_local ip from me to not 10.0/8 out via dc0
> # Divert non-locally-generated egress and all ingress traffic to natd.
> add 200 divert natd ip from not me to not 10.0/8 out via dc0
> add 200 divert natd ip from not 10.0/8 to me in via dc0
> # Set up ALTQ classification for nat'd egress traffic.
> add 500 altq natted ip from any to any diverted-output via dc0
> # Excplicitly deny private addresses to/from the world.
> add 1000 deny log ip from any to 10.0/8 in via dc0 not diverted-loopback
> add 1001 deny log ip from 10.0/8 to any out via dc0
> # Respect the loopback net.
> add 2000 allow ip from any to any via lo0
> add 2001 deny log ip from any to 127.0.0.0/8
> add 2002 deny log ip from 127.0.0.0/8 to any
> # Deny interesting local services to the outside world.
> add 10000 deny log tcp from any to any 25,111,11111,137,138,139,11025 in via dc0
> add 15000 deny log udp from any to any 53,111,11111,137,138,139 in via dc0
> add 65000 allow ip from any to any
> 
> -- 
> Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
>   <> green at FreeBSD.org                               \  The Power to Serve! \
>  Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\

This sounds pretty cool! :)

/offtopic
This reminds me that i was thinking from some time that
it will be really nice if pf could be used as a packet
 classifier for DUMMYNET.
What do you think about that?

And since we are here, i want to ask one more thing,
that bothers me from some time.
I'm using pf on FreeBSD and on pf+altq on OpenBSD machines.
But on OpenBSD altq has limitation on the smallest bandwidth that i can
shape, it was 5.6Kbits as far as i remember. 
This limitation was explained by the timer resolution.
So what is the situation in FreeBSD, as it can be compiled with higher 
resolution, i.e. HZ=1000 or more? (or i'm mistaking something here)

--niki


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20040930/5c2e62f7/attachment.bin