Setting bandwidth for multiple internal subnets + few more PF questions

[Max Laier]

[ Could you get your mailer to line wrap, please? ]

On Thursday 15 March 2007 11:08, Aleš Krajník wrote:
> I have a problem with PF and I would appreciate any help. I spent few
> hours googling around but found no solution.
>
> We have a FreeBSD 6.1 router with 4 internal subnets on 4 interfaces
> (em1, fxp0, fxp1, xl0), 1 connection to the Internet (em0) - 10Mbps
> both directions, full duplex. What we need is to shape traffic so em1 +
> fxp1 , fxp0 and xl0 uses equally 33% of traffic, in both incoming and
> outgoing directions from the Internet (incoming direction is more
> important for us as we don't have almost any servers inside our network
> except for HTTP for development purpose so mostly we download data from
> the Internet). Traffic between local subnets should stay unlimited.
>
> That should not be problem - we could just set 3.33Mbps on each
> interface for packets arriving from the Internet. What we cannot solve
> is how to set that each interface could borrow bandwidth from other
> interfaces (= from parent stream) if they are not fully utilised?
>
> If I set ALTQ on the external interface, I can control only outgoing
> traffic to the Internet (I made that work successfully). If I set ALTQ
> on any of the internal interfaces I cannot set it to borrow from each
> other. Setting ALTQ on multiple interfaces is not supported AFAIK. Is
> there any solution? Can that be solved with packet tagging?

Controlling *incoming* traffic is not really supported or possible for 
that matter.  You can't controll what others send you.  Of course you 
can - as you seem to be doing - limit the *outgoing* traffic on the 
internal interface(s).  Due to the way ALTQ works, however, it is not 
possible to share bandwidth over several interfaces.  ALTQ directly hooks 
into the queueing at the interface.  What you would need are two distinct 
boxes or a virtual interface through which you tunnel all traffic from 
the internet to you LANs - but I'm not sure that is (easily) possible.

You might want to look into using ipfw + dummynet, which works differently 
and might be able to solve this particular problem.  I'm also open to pf 
+ dummynet integration, but don't have time to work on that, at the 
moment.

> Another thing I do not completely understand is setting ALTQ rules on
> interfaces. I just want to make it clear to myself. If I set ALTQ on an
> interface, it means that packets are being dropped on the chosen
> interface? If I set queue on an interface, it means that packets are
> added to that queue if and only if the rule is evaluated on the chosen
> interface? For example if I would have rules "queue Q on em0 ..." and
> "pass in on em1 ... queue Q", what would that do?

Internally, queue names are resolved to a number, which is tagged to the 
packet.  If you have a queue named "foo" on em0 and em1, both these 
queues will have the same number.  It does not matter where you tag the 
packet.  On rule evaluation it is only assigned the number for the queue 
name.  As it hits an ALTQ enabled interface the queueing decides which 
queue this number corresponds to.

So in your scenario, if you call the queues on the internal interfaces the 
same - say "INET_IN" - you can assign incoming traffic to them with one 
single rule on the outside interface.

> My last question - I read TCP ACK packets prioritizing can increase
> incoming throughput. Does that make sense on fast internet connections
> like is ours or is it useful only for e.g. dial-up connections? I would
> use following ALTQ settings:
>
>     ALTQ on $lan_ex bandwidth 10Mb cbq { queue_std, queue_ack }
>               queue queue_std on $lan_ex bandwidth 99% cbq(default)
>               queue queue_ack on $lan_ex bandwidth 1%
>
>                 ... and create a TCP/ACK rule on $lan_ex with queue_ack

This doesn't prioritize ACKs.  You might want to read Daniel's excellent 
article about it: http://www.benzedrine.cx/ackpri.html  As he points out, 
it's most useful on asymmetric links when you really saturate the uplink.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20070316/588ec053/attachment.pgp