From owner-freebsd-pf@FreeBSD.ORG Wed Feb 22 23:18:54 2006 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 C398216A420 for ; Wed, 22 Feb 2006 23:18:54 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7564B43D68 for ; Wed, 22 Feb 2006 23:18:43 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: by uproxy.gmail.com with SMTP id m2so840467ugc for ; Wed, 22 Feb 2006 15:18:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UJUXGNUuqKbeoW/eEQZPb35/Jb1czxcCelB/JND9r/REM5IwyioJlR8Z+AMJQzYwA0DZouDOpJ7zSkiYmLi9+De/O4r/AxyVLLW+3isLPoPJHIraEH6ouIufwprxAOfr3wZDkuQt+1RmM6xIWU3jLPMJVvFi+EHrib5YUQy+M/c= Received: by 10.66.250.9 with SMTP id x9mr3470723ugh; Wed, 22 Feb 2006 15:18:41 -0800 (PST) Received: by 10.66.223.20 with HTTP; Wed, 22 Feb 2006 15:18:41 -0800 (PST) Message-ID: <8eea04080602221518x34da8bds88b713282ba52c74@mail.gmail.com> Date: Wed, 22 Feb 2006 15:18:41 -0800 From: "Jon Simola" Sender: jsimola@gmail.com To: "Christopher McGee" In-Reply-To: <43FCDEE7.2010802@xecu.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43FC9F63.5070009@xecu.net> <8eea04080602220957v46f9d11ev2544e8cbe893365d@mail.gmail.com> <43FCA7B8.3090300@xecu.net> <55e8a96c0602221042re25f819g1e3815384c022590@mail.gmail.com> <43FCB645.5000508@xecu.net> <8eea04080602221157h18555b9bxc2719b5a12f7362a@mail.gmail.com> <43FCDEE7.2010802@xecu.net> Cc: freebsd-pf@freebsd.org Subject: Re: Hfsc configuration problems 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: Wed, 22 Feb 2006 23:18:54 -0000 On 2/22/06, Christopher McGee wrote: > Jon Simola wrote: > > >On 2/22/06, Christopher McGee wrote: > > > > > > > >>I might be going about this the wrong way, but, this is ultimately what > >>I'm trying to do. One queue has guaranteed 3Mb, another has a > >>guaranteed 4Mb, another has 3Mb guarantee, which leaves about 90Mb as a > >>pool for all of them. If they are backlogged, I want the first 2 queue= s > >>to be able to utilize the entire 90Mb, and the 3rd queue should be able > >>to utilize about 25Mb of it. This is a simplified example of what I > >>sent earlier. But if I can do this, I can accomplish what I'm trying t= o > >>and build off it later. > >> > >> > > > >If you're guaranteeing bandwidth allocation, then you want realtime, > >and probably avoid the bandwidth declarations which are not quite the > >same. HFSC is not trivial to get your head wrapped around and is > >poorly documented because of that. It took me reading the man pages > >and the PF guide several times over a couple months to get it > >together. > > > >Another example for you to peruse: > > > >queue q_dmz hfsc(ecn realtime 50Mb upperlimit 90Mb) \ > > { q_dmz_h, q_dmz_hb, q_dmz_l, q_dmz_lb } > >queue q_dmz_h hfsc(realtime 10% upperlimit 90%) priority 7 > >queue q_dmz_hb hfsc(realtime 20% upperlimit 90%) priority 4 > >queue q_dmz_l hfsc(realtime 5% upperlimit 90%) priority 3 > >queue q_dmz_lb hfsc(realtime 10% upperlimit 90%) priority 0 > > > >Leave out the linkshare and bandwidth, just use realtime and > >upperlimit. And the priority of the queues matters, in the above each > >of the queues can go as high as 81Mb (90% of 90Mb) but if more than > >one tries to go above 45Mb, the one with the higher priority gets > >first chance at available bandwidth. Linkshare is another override; in > >the above it is easily possible that the q_dmz_lb queue will get quite > >backlogged as it gets last chance, adding linkshare would allow it to > >bypass the priorities of the other queues. You may not want to even > >use priorities, using just realtime and upperlimit is probably a lot > >easier for your simplified example. > > > >Using the service curves is even more complex. This is all based on my > >experience and research, so it may not be correct, but it's the > >explanation that I use. > > > >-- > >Jon Simola > >Systems Administrator > >ABC Communications > > > > > This information is very helpful. Here is my modified configuration, > unfortunately it still gets the same errors: > > altq on $ext_if bandwidth 100Mb hfsc queue { high_pri, med_pri, junk } > queue high_pri hfsc(realtime 128Kb upperlimit 500Kb red) priority 7 > queue med_pri hfsc(realtime 5Mb upperlimit 99% default ecn red) priority = 5 > queue junk hfsc(upperlimit 95% red) Yet this compiles fine on my 5.3-STABLE box: # pfctl -vvnAf test.pf altq on em0 hfsc bandwidth 100Mb tbrsize 12000 queue { high_pri med_pri jun= k } queue high_pri bandwidth 1% priority 7 hfsc( red realtime 128Kb upperlimit 500Kb ) queue med_pri bandwidth 1% priority 5 hfsc( red ecn default realtime 5Mb upperlimit 99% ) queue junk bandwidth 1% hfsc( red upperlimit 95% ) And a related sillier config on an OpenBSD 3.8 box (bandwidth 0%): # pfctl -vvnAf test.pf altq on em0 hfsc bandwidth 100Mb tbrsize 12000 queue { high_pri med_pri jun= k } queue high_pri bandwidth 0 b priority 7 hfsc( red realtime 128Kb upperlimit 500Kb ) queue med_pri bandwidth 0 b priority 5 hfsc( red ecn default realtime 5Mb upperlimit 99% ) queue junk bandwidth 0 b hfsc( red upperlimit 95% ) > Just to clarify what I'm trying to do... I'm trying to guarantee 128K > for high_pri stuff(ssh, carp, etc..) and allow up to 500Kfor it. Other > services, like web traffic etc.. falls in med_pri, which gets 5Mb all > the time but can use up to 99Mb. All other traffic, like cvsup, ftp, > etc... will get no guarantees, but can use up to 95Mb if it's > available. From all my reading, this seems correct but I still get the > parent sc errors. For some reason adding bandwidth lets it compile. I've got no idea what that actually will do (non-sensical numbers). If you use some sensible numbers for bandwidth and specify the realtime/upperlimit for hfsc, I'd certainly be interested to hear how it goes for you. -- Jon Simola Systems Administrator ABC Communications