From owner-freebsd-current@FreeBSD.ORG Fri Oct 1 15:03:40 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 6130016A4CF for ; Fri, 1 Oct 2004 15:03:40 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8DE643D31 for ; Fri, 1 Oct 2004 15:03:34 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i91F3UF5005830; Fri, 1 Oct 2004 11:03:30 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i91F3UBw005829; Fri, 1 Oct 2004 11:03:30 -0400 (EDT) (envelope-from green) Date: Fri, 1 Oct 2004 11:03:29 -0400 From: Brian Fundakowski Feldman To: "Devon H. O'Dell" Message-ID: <20041001150329.GI997@green.homeunix.org> References: <200409272240.00356.A.S.Usov@kvi.nl> <20041001132843.GG997@green.homeunix.org> <200410011555.00828.A.S.Usov@kvi.nl> <415D66A3.4070805@sitetronics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <415D66A3.4070805@sitetronics.com> User-Agent: Mutt/1.5.6i cc: "Alexander S. Usov" 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 15:03:40 -0000 On Fri, Oct 01, 2004 at 04:16:03PM +0200, Devon H. O'Dell wrote: > 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. I don't understand what you're saying. You still don't put ALTQ classification on incoming packets, you do it when they're going out of whatever the final interface they're destined for. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\