Re: ALTQ/pf troubles

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