Date: Thu, 30 Sep 2004 01:06:57 +0300 From: Niki Denev <nike_d@cytexbg.com> To: ipfw@freebsd.org Subject: Re: ALTQ with IPFW Message-ID: <cone.1096495617.888686.641.1001@phobos.totalterror.net> References: <20040929195920.GC1807@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
--=_mimegpg-phobos.totalterror.net-641-1096495617-0001
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
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@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
--=_mimegpg-phobos.totalterror.net-641-1096495617-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (FreeBSD)
iD8DBQBBWzIBHNAJ/fLbfrkRAnq5AJ4m2G9p4IVaZavtkbz7/1SB98BkigCbBm79
FXqlAm4iS7N850RndiCovYo=
=7l+n
-----END PGP SIGNATURE-----
--=_mimegpg-phobos.totalterror.net-641-1096495617-0001--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cone.1096495617.888686.641.1001>