From owner-freebsd-pf@FreeBSD.ORG Wed Feb 22 19:57:34 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 C535616A420 for ; Wed, 22 Feb 2006 19:57:34 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AD4F43D49 for ; Wed, 22 Feb 2006 19:57:33 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: by uproxy.gmail.com with SMTP id y2so813464uge for ; Wed, 22 Feb 2006 11:57:32 -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=Jb6pnCRI0CMmI0H5ft+5H5491P/h12X5WMCsy35rt6Gyjeyv6sRghvGZ4/g+UA5Hiq5svqVG33MGYAzToWtVVIGKHwEop11Dqz+TW1A2m1muEDmBEg1pmUG6aNU6i5k7M6qg80tO+bBFVHzGkNnDcWlExG81kHaTzQa2Ob/sZUc= Received: by 10.66.164.4 with SMTP id m4mr3385178uge; Wed, 22 Feb 2006 11:57:30 -0800 (PST) Received: by 10.66.223.20 with HTTP; Wed, 22 Feb 2006 11:57:29 -0800 (PST) Message-ID: <8eea04080602221157h18555b9bxc2719b5a12f7362a@mail.gmail.com> Date: Wed, 22 Feb 2006 11:57:29 -0800 From: "Jon Simola" Sender: jsimola@gmail.com To: "Christopher McGee" In-Reply-To: <43FCB645.5000508@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> 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 19:57:34 -0000 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 queues > 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 to > 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