From owner-freebsd-isp@FreeBSD.ORG Thu May 17 13:41:38 2007 Return-Path: X-Original-To: freebsd-isp@freebsd.org Delivered-To: freebsd-isp@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E459C16A403 for ; Thu, 17 May 2007 13:41:37 +0000 (UTC) (envelope-from info@plot.uz) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.235]) by mx1.freebsd.org (Postfix) with ESMTP id 7E79213C45E for ; Thu, 17 May 2007 13:41:35 +0000 (UTC) (envelope-from info@plot.uz) Received: by qb-out-0506.google.com with SMTP id q12so236048qba for ; Thu, 17 May 2007 06:41:34 -0700 (PDT) Received: by 10.35.39.13 with SMTP id r13mr727083pyj.1179409294251; Thu, 17 May 2007 06:41:34 -0700 (PDT) Received: from plot.uz ( [83.221.183.136]) by mx.google.com with ESMTP id a22sm4325465pye.2007.05.17.06.41.30; Thu, 17 May 2007 06:41:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.1.7 X-Spam-Report: Received: from localhost by plot.uz (MDaemon PRO v9.5.5) with DomainPOP id md50000002371.msg for ; Thu, 17 May 2007 18:40:49 +0500 Delivered-To: info@plot.uz Received: by 10.100.123.18 with SMTP id v18cs278507anc; Thu, 17 May 2007 06:37:33 -0700 (PDT) Received: by 10.70.68.11 with SMTP id q11mr700017wxa.1179409053817; Thu, 17 May 2007 06:37:33 -0700 (PDT) Received: from mta1.recol.net (mta1.recol.net [64.207.103.6]) by mx.google.com with ESMTP id h37si1002107wxd.2007.05.17.06.37.33; Thu, 17 May 2007 06:37:33 -0700 (PDT) Received-SPF: pass (google.com: domain of llt@recol.com designates 64.207.103.6 as permitted sender) Received: from TRAN (lan.recol.net [207.51.84.209]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mta1.recol.net (Postfix) with ESMTP id 8FDA13A3890; Thu, 17 May 2007 09:37:32 -0400 (EDT) Message-ID: <003601c79888$85bd0500$d101010a@recol.us> To: "Jeremy Tregunna" References: <008e01c797cf$8eecda60$d101010a@recol.us> <4A5057D3-3AF7-4E3E-8165-4B821FCB0E1A@blurgle.ca> Date: Thu, 17 May 2007 09:37:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Return-Path: llt@recol.com X-Envelope-From: llt@recol.com X-MDaemon-Deliver-To: freebsd-isp@freebsd.org X-Spam-Processed: plot.uz, Thu, 17 May 2007 18:40:50 +0500 From: Lan Tran Cc: freebsd-isp@freebsd.org Subject: Re: pf+altq for bandwidth management X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2007 13:41:38 -0000 ----- Original Message ----- From: "Jeremy Tregunna" To: "Lan Tran" Cc: Sent: Wednesday, May 16, 2007 1:21 PM Subject: Re: pf+altq for bandwidth management > On 16-May-07, at 11:33 AM, Lan Tran wrote: > >> Hello, >> >> Is pf and altq a right combo for bandwidth limiting? What I'm trying to >> do is limit each IP or block of IPs to predefined bandwidth. I'm not >> doing traffic shaping, just wanting to prevent servers from hogging all >> the bandwidth. >> >> My setup is as follow: >> LAN {test server} -> xl1 {FreeBSD} xl0 -> router -> net >> xl0 and xl1 are functioning as a bridge. kernel has pf and altq >> compiled. >> >> pf.conf: >> ext_if = "xl0" >> int_if = "xl1" >> pc = "any" >> set loginterface $ext_if >> >> # to net >> altq on $ext_if cbq bandwidth 100Mb queue { std_ext, test_ext } >> queue std_ext bandwidth 3Mb qlimit 1000 priority 5 cbq(default red ecn) >> queue test_ext bandwidth 2Mb priority 1 cbq(red ecn) >> >> pass out on $ext_if from $pc to any keep state queue test_ext >> --- >> The problem I'm having is that all outbound traffic from "test server" >> always shows around 3Mb instead of 2Mb per queue test_ext ruleset. What >> am I missing? > > I've noticed the best precision for bandwidth limiting on cheap cards > like realtek's (provided of course, the particular rl(4) card you're > using is supported). Cards like fxp(4) and xl(4) I've not had great luck > with getting them limited properly (always above or below the target)). > > -- > Jeremy Tregunna Jeremy, Thanks for the input on types of card. It seems the "default" cbq rule is getting hit instead of the expected ruleset. If I change queue test_ext bandwidth 2Mb priority 1 cbq(red ecn) to queue test_ext bandwidth 2Mb priority 1 cbq(red ecn default), I get the rate I want. But this causes every rule to be matched to 2Mb. Any ideas? LT