On 2012/04/12 02:48, Andy Lemin wrote: > 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?
Yes, that thread is talking about creating multiple queues with the same name, this is good for traffic classification but it is not a single queue shared between multiple interfaces. > 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. Currently two machines is the cleanest (and maybe only) way to do this, I have a feeling you'll get better results making these route rather than bridge. altq's queues are all per-interface. Anything to change this would be major work. Plan is for the queue code to be completely replaced so working on this before that happens would get in the way. > > 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 :( lo(4) is a bit of a specialist interface to be trying this with. You might get somewhere with vether(4), the uncommitted diff "virtual crossover link with vether(4)" on t...@openbsd.org could be of interest. Another option might be to route things to a userland daemon via tun(4) that reinjects the packets then you can queue on the tun interface instead. I have some old code from kjc sitting in my inbox that might be useful here, I'll try and find time to dust it off. Higher overhead but somewhere that is going to need to 'borrow' downstream bandwidth between interfaces is likely to not be seeing super-high-speed traffic anyway so this might not be a problem.
