Re: ALTQ/pf troubles

From: Devon H. O'Dell <dodell_at_sitetronics.com>
Date: Fri, 01 Oct 2004 16:16:03 +0200
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
Received on Fri Oct 01 2004 - 12:16:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:15 UTC