ALTQ/pf troubles
Brian Fundakowski Feldman
green at freebsd.org
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 FreeBSD.org \ The Power to Serve! \
Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
More information about the freebsd-current
mailing list