On Fri, Aug 05, 2005 at 06:04:08PM +0000, Karl O. Pinc wrote:

> For details see this thread:
> Proposed idiom for inbound queueing on a multi-homed host
> http://marc.theaimsgroup.com/?t=112139406900001&r=1&w=2&n=6

If I understand it correctly, you're asking whether you could use
route-to loopback and queueing on loopback to queue incoming packets (on
their way through the firewall) on one central interface (lo0).

My answer is that I simply don't know, as I've never tried it. The lack
of responses may indicate that you're simply the first person to ever
attempt this, and there is noone who can tell you in advance whether
it's going to work out exactly as you want it to. The theory doesn't
sound unreasonable to me.

So, you might have to try it and see for yourself. It might work out
just fine, and become an elegant solution in this case. It might almost
work, and work after some small fix. Or it might require larger changes,
which are never accepted.

There seem to be two unrelated issues, which can be tested seperately.

First, try the route-to lo0 scheme without any queueing. If you route
incoming packets to lo0, do they actually come back in on lo0 and cause
the normal IP forwarding procedure (i.e. lookup of the proper interface
to forward them through, arp, etc.)? Or does loopback act like a black
hole for any traffic which is not destined for a daemon running locally
and bound to 127.0.0.1?

If that works, try queueing on lo0. The loopback code uses the interface
queues like an ordinary interface. I've never tried queueing on
loopback. It might just work. Use pfctl -vvsq to see how queues are used
and filled, whether they drop excess packets, etc.

Once both of these aspects work on their own, try to combine them.

I'd try 'set skip on lo0', so pf itself won't see packets on the
loopback interface. You can assign queue tags on the real interface, and
packets will still get queued accordingly, even if pf is not filtering
them anymore on lo0.

The loopback interface is special in many ways. Basically, there's this
abstract idea of what it should do (like a phyisical cable looping back to
an interface, so anything going out comes right back in verbatim), but how
that translations to behaviour in specific aspects is not always
well-defined. If you're using loopback in an unconventional way for the
first time, there may very well be surprises. Try and see :)

Daniel

Reply via email to