Date: Tue, 2 Dec 2008 20:22:04 +1100 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Andrei Kolu <antik@bsd.ee> Cc: freebsd-isp@freebsd.org, freebsd-pf@freebsd.org Subject: Re: PF + ALTQ - Bandwidth per customer Message-ID: <20081202092204.GU51761@server.vk2pj.dyndns.org> In-Reply-To: <4934F4F3.1030808@bsd.ee> References: <20081124180411.0b065be5@wolwerine> <705757.42117.qm@web38504.mail.mud.yahoo.com> <11167f520812011508u46b04e7dmb1d5d22675dc778d@mail.gmail.com> <20081202075634.GT51761@server.vk2pj.dyndns.org> <4934F4F3.1030808@bsd.ee>
next in thread | previous in thread | raw e-mail | index | archive | help
--lYjFa3qL1bvncypl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Dec-02 10:42:27 +0200, Andrei Kolu <antik@bsd.ee> wrote: >> That description sounds like it simplifies to "limit bandwidth based on >> IP address" - which is fairly trivial for ipfw+dummynet or pf+altq. >> =20 >ipfw+dummynet is really ugly traffic "shaper" (let's face it there is no= =20 >shaping going on), because instead of limiting bandwidth it will drop=20 >packets to simulate bad connection. I've been using ipfw+dummynet for traffic shaping for 7 or 8 years without problems (and have recently moved to pf+dummynet). I don't understand your comment about limiting bandwidth: An incoming packet is put on a queue that is emptied at no more than the (simulated) available outbound bandwidth. If the queue is full then incoming packets will be dropped. This is the same behaviour as any other router (or switch). What do you want/expect? > I hear many years about "trivial"=20 >configuration per user bandwidth limit with pf+altq but never saw ANY=20 >code... Note that I never mentioned per-user bandwidth with pf+altq - though it looks possible. There are some trivial traffic-shaping examples in pf.conf(5) but I will admit that I've never tried to actually use altq - I use dummynet because I need functionality that isn't present in altq. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --lYjFa3qL1bvncypl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk0/jwACgkQ/opHv/APuIcOugCgo8LM3HE/0oSzFy0HbcffjFm+ jaYAoJ3GQW98vGR9Szi2XyiM0dJoG1ek =xp16 -----END PGP SIGNATURE----- --lYjFa3qL1bvncypl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081202092204.GU51761>