Re: inbound queueing on external interface due to multiple internal interfaces

Hi, thanks very much for your suggestion.

> You will want to see this thread:
> Working example of bi-directional asymmetric ALTQ + NAT ruleset?
> http://marc.info/?t=3D129472965800001&r=3D1&w=3D2
>=20
> It talks about being able to have a single queue
> on more than one interface, so you'd use a single
> outbound queue on all your internal interfaces to
> effectively rate-limit your inbound wan traffic.

I read through that archive but the problem it seems to be discussing seems=
 pretty trivial as its discussing semantics of queuing downstream traffic w=
hich you just do by queuing on the internal interface (which works perfectl=
y if you only have one internal interface).

It does suggest creating a queue structure without assigning a specific int=
erface as you suggest, however when you do this I believe PF simply creates=
 copy's of the queue structure and creates instances per interfaces? I.e. t=
he different interfaces are not sharing the same physical queue in memory. =
Is this true?

I need to be able to perform downstream queuing pre-routing effectively so =
that all the downstream traffic (regardless of the internal zone) is all qu=
eued equally as one, allowing all internal interfaces to share the total do=
wnstream bandwidth.


> If sharing a queue on your internal=20
> interfaces does not do it you could get ugly and
> use an extra 2 real interfaces (instead of the loopback interface
> as you suggest) and a separate routing table and physically
> loop the traffic back.  This is less ugly than having another box.

Sadly we don't have enough ports/slots on our firewall to add a physical lo=
op back and so it has to be a virtual interface :(


> I suspect the loopback interface approach won't work, but that's
> a total guess.  If it does work I'm not sure I'd want
> to count on such a kludge continuing to work long-term.

Can you tell me why you feel it's a hack to do it using a virtual interface=
 (assuming it works)?
It seems like a legitimate solution for queuing downstream traffic pre-rout=
ing (altq processing is done during the last stage of egress processing) as=
 this would allow you to define unique downstream queues on any/multiple so=
urces (WAN or VPN) etc.

Or do you think it would be better to allow multiple internal interfaces to=
 share the same physical queue in memory?

Whilst its an ALTQ thing, I would assume both solutions would be best imple=
mented in PF?

I'm just looking for ideas to try as I'm genuinely surprised BSD can't do t=
his :(


> I'm very interested in what works and what doesn't so
> it would be good to hear back from you.

Yes I'll keep my progress posted, as I know their are a lot of other people=
 out there who also want this functionality considering the number of threa=
ds I have come across on this, some dating back years.


> Don't forget the "empty" ack packets.

Indeed ;)


> > If we had to bounty this, how much? I might be able to get =3DA3100 for
> > a
> > bounty?
>=20
> I heard the number $20,000 (US) thrown around.  I have no idea if
> that's a realistic number.
>=20

That's a little out of my budget of a few hundred dollars! :(

Cheers for your time, Andy.