From owner-freebsd-pf@FreeBSD.ORG Sat Oct 22 07:42:35 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AFA416A420 for ; Sat, 22 Oct 2005 07:42:35 +0000 (GMT) (envelope-from brunomiguel@dequim.ist.utl.pt) Received: from gecea.ist.utl.pt (gecea.ist.utl.pt [193.136.140.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 172FF43D46 for ; Sat, 22 Oct 2005 07:42:34 +0000 (GMT) (envelope-from brunomiguel@dequim.ist.utl.pt) Received: from [66.30.10.101] (c-66-30-10-101.hsd1.ma.comcast.net [66.30.10.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gecea.ist.utl.pt (Postfix) with ESMTP id AFA2D40C7; Sat, 22 Oct 2005 08:42:32 +0100 (WEST) Message-ID: <4359ED5B.7010303@dequim.ist.utl.pt> Date: Sat, 22 Oct 2005 03:42:19 -0400 From: Bruno Afonso User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Josh Finlay References: <000b01c5d644$54527f20$0132a8c0@delta> In-Reply-To: <000b01c5d644$54527f20$0132a8c0@delta> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: FreeBSD + MPD + PF + ALTQ X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2005 07:42:35 -0000 Hi Josh, Let's hope I can help you somehow :> This is my experience based on a wifi pppoe server for several clients... the thing has been evolving and we're now even using freeradius and sql on a 6.0-RC box to take advantage of PF 3.7's niceties... I'm writing this from my head so the syntax may be wrong in some parts. :) Josh Finlay wrote: > Hi, > > I'm using FreeBSD 5.3-RELEASE, and PF as my firewall > > I realise that this e-mail is not *entirely* PF related, but I thought > this might be the best place to get my questions answered. > > Now I have zero experience with ALTQ > but I have read that this is the solution to my problems. > > I have an ADSL connection, 512kbps up 128kbps down. > 3 machines in total on the network. > > a freebsd router, > 2 windows machines. > > I want to allow a sort of "sharing" of the bandwidth. > Most out-of-the-box routers already do this, but I can't afford to fork > out for one of those, nor would I like to part with my FreeBSD box. > > I was wondering if anyone would be able to provide me with some PF/ALTQ > rules that would evenly distrobute my bandwidth over the 3 computers? Depends on how it's setup... where does mpd get into action here? > > I want it done in a way where: > > - if 1 pc is using the link, it can use all available bandwidth > - if 2 pcs are using the link, it gets split 50/50 > - if 3 pcs are using the link, it gets spread evenly over them, etc, etc This is fairly easy for the upload bw, honestly, the one that you should normally be concerned with. :-) 1) easier way: You simply have to setup altq on the "adsl" interface that pushes the data on the internet. A simple cbq is ok since it does fair-weight-queueing (wfq) to the best of my knowledge (this was said to me by a obsd pf developer). So, you basically setup rules that put the upload bw from those 3 pcs into the same queue. Basically, you simply need to have a rule that gets everything each client sends over to the internet to the queue. *Remember*: You can create for example a pass rule on an interface and assign those packets to a queue on another one. So, ex: tun1 - client 1 tun2 - client 2 fxp0 (assuming rj45 adsl modem?) - internet interface, where you have a queue named "client_upload" altq on fxp0 cbq bw 128Kb (client_upload) queue client_upload cbq(default) pass in on tun1 from (tun1) to any queue client_upload This is the magical part. What is getting IN on tun1 is the user's upload, what will eventually get out on fxp0 when it goes to the internet. You might want to elaborate and add more rules... :) One great way to check what's in and out on whatever interface is to use the utility ifstat, or use systat and check ifstat. Since the user's upload on tun1 is what gets IN, you can't QoS there since altq only QoSs on outgoing of interfaces. So, the only thing you can do on tun1 is to control their DOWNLOAD speed. More about this to come... 2) less trivial one but more powerful: You need to setup a parent queue that has the entire upload bw you want to share and then 3 siblings one. For this to really work you would need to use hfsc and get into account linkshares, realtime... overkill for your setup imho. :-) > This would preferable be for downstream AND upstream, to ensure that no > single computer is more lagged out than the other one.. I assume this is > possible, just a bit outside my knowledge base. The download part is the problematic one IF they're not all connected to the same network interface. Why ? Because altq only works PER interface and tun0, tun1, tun2, etc are each and single one, one interface on its own. You basically have to altq on tun0 altq on tun1, etc.. What we would need in this case would be a meta-interface that altq would work on, but that is not available. Bottom line: you can't control with PF global bw over an interface-span. This is probably necessary for a full commercial deployment. Don't know of any plans to implement this... meta_if {tun0, tun1} altq on meta_1 ... would be nice. :-) > Any hands up to write me a quick few PF rules for this? > > My Local IP addresses are as follows: > 192.168.0.101 - router > 192.168.0.6 - windows > 192.168.0.1 - windows > > (don't ask about my IP configuration, long story :P) > > my network interface (has 192.168.0.101 assigned) is de0 > my internet interface (has my internet ip assigned) is ng0 (using MPD) So, all of your clients are LAN users? altq on ng0 cbq bw 128kb {upload_bw} queue upload_bw cbq(default) clients = {...} pass in on de0 from $clients to !192.168.0.0/24 queue on upload_bw > I tried a few examples I found, no luck, found another thing I will need > to fix first: > > pfctl: ng0: driver does not support altq Isn't this solved in 5.4 or 6.0 ? Please really check that before pursuing other avenues. > > I searched for a patch for the ng_iface driver, but no luck. > > So, now i've decided to take another approach. > > I've installed a second NIC in my fbsd box > > so now I've got de0, and vr0 > > I want de0 for lan traffic > it will have an assigned ip 192.168.0.101 > and all other machines will use that as their gateway > > now I want mpd to use vr0, since the vr driver supports altq. > > How do I go about this? > and do I need to do any routing between de0 and vr0 so that client > machines using 192.168.0.101 (de0) as their gateway will be able to > access the outside world? > > And also after all that, some nice altq rules as I detailed above in > this mail. > > I hope to hear some solutions soon, this problem has been bugging me for > some time now. I'm giving you some tips, I won't do your job. :-) BA -- Bruno Afonso, Biological Engineer Dana-Farber Cancer Institute 1 Jimmy Fund Way Smith Building Boston, MA 02115 phone: (617)-632-5105 GABBA Graduate Student (http://gabba.up.pt) Homepage @ http://brunoafonso.net/