ALTQ/pf troubles

Brian Fundakowski Feldman green at
Fri Oct 1 08:03:40 PDT 2004

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 at                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\

More information about the freebsd-current mailing list