From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 14:16:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B64516A4CE; Fri, 1 Oct 2004 14:16:09 +0000 (GMT) Received: from smtpq3.home.nl (smtpq3.home.nl [213.51.128.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id E11C143D4C; Fri, 1 Oct 2004 14:16:08 +0000 (GMT) (envelope-from dodell@sitetronics.com) Received: from [213.51.128.135] (port=45373 helo=smtp4.home.nl) by smtpq3.home.nl with esmtp (Exim 4.30) id 1CDOCe-0007j4-2k; Fri, 01 Oct 2004 16:16:08 +0200 Received: from cc740438-a.deven1.ov.home.nl ([82.75.136.183]:4353) by smtp4.home.nl with esmtp (Exim 4.30) id 1CDOCZ-0000nY-FL; Fri, 01 Oct 2004 16:16:03 +0200 Message-ID: <415D66A3.4070805@sitetronics.com> Date: Fri, 01 Oct 2004 16:16:03 +0200 From: "Devon H. O'Dell" User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexander S. Usov" References: <200409272240.00356.A.S.Usov@kvi.nl> <20041001132843.GG997@green.homeunix.org> <200410011555.00828.A.S.Usov@kvi.nl> In-Reply-To: <200410011555.00828.A.S.Usov@kvi.nl> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-AtHome-MailScanner-Information: Neem contact op met support@home.nl voor meer informatie X-AtHome-MailScanner: Found to be clean cc: current@freebsd.org Subject: Re: ALTQ/pf troubles X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2004 14:16:09 -0000 Alexander S. Usov wrote: > On Friday 01 October 2004 15:28, Brian Fundakowski Feldman wrote: > >>On Mon, Sep 27, 2004 at 10:40:00PM +0200, Alexander S. Usov wrote: >> >>>Hello !! >>>Just enabling the queueing on the interface with bandwidth == DSL >>>bandwidth results in the appox. factor of 2 drop in the speed of the >>>outgoing transfers. >>> >>>>From my experiments I got an impression that to make this slow-down >>> >>>away I have to specify the bandwith around 700Kb, which is twice bigger >>>than real. >> >>Are you telling ALTQ to process _incoming_ packets? > > > According to the pf manuals it should process only outgoing packets. > And I believe it's the case as the incoming rate doesn't depends on queieing > state. I know you guys are experienced with this, but this is just for those who are reading and aren't :). You can easily limit incoming packets by treating the outgoing packets on the ``internal'' interface. If a machine, for instance has interfaces fxp0 and fxp1; fxp0 being an interface with an external connection and fxp1 connecting to an internal network: /----------\ incoming fxp0 /----------\ outgoing fxp1 (altq) /-----\ | the | -------------> | firewall | --------------------> | the | | Internet | <------------- | pf/altq | <-------------------- | xAN | \----------/ outgoing fxp0 \----------/ incoming fxp1 \-----/ (altq) fig 1.1 Ugly ASCII art by me. Packets coming in via fxp0 are not ``processed'' by ALTQ; however, these packets are probably destined for the xAN (WAN / LAN / whatever -- certainly so if this is a bridged configuration) and the ``incoming'' packets can thus be treated when they're outgoing -- to the destined network. Likewise, packets exiting the firewall destined for the Internet can be ``processed'' as well. This, of course, assumes a certain network layout that not all people are using (for instance when the firewall is the system with the services). There's no real solution for this, except perhaps to create a loopback NAT of some kind, which is an ugly hack. If this (previous description) is your network layout and you're really needing this, I'd suggest that you just rethink your network layout and buy a cheap box to act as a firewall, configuring it as in the diagram above. Note as well that the above diagram should also work if the pf machine is running as a transparent bridge, although I'm not sure if pf is able to act as a bridge under pfil(9). This should be possible in the future. So, in conclusion, it _is_ possible to queue incoming packets, because on a firewall, they're usually destined to exit another interface (thus being outgoing packets) to reach machines on another network / on the other side of the bridge. Hope this is useful. --Devon