Re: Fair distribution of borrowed bandwidth with a lot of users
Attached you can find a snapshot of the queue view of pftop (only part of the queue is shown). As you can see, even if all queue have similar assigned bandwidths (6400 and 2000 bps), there is a single queue with a GREAT amount of traffic (wh10_i) that monopolize ALL the bandwidth! There are 10 other queues with bytes to flow (QLEN != 0) but all the packets are dropped (B/S = 0 and DROP_P keeps increasing). To me this is a bug, or at least a bad behavior. Am I wrong? How can I make a single queue don't borrow ALL the traffic? Thanks. Federico Giannici wrote: Bob DeBolt wrote: Hi Federico Giannici Posting you pf.conf will be of considerable benefit when attempting to seek help for something that has the complexity you are currently dealing with. Additionally, the type connection you have, i.e. DSL, cable etc. as the variations each of these has throughout the day will skew the appearance of your results etc. We have a 6Mb connection (made with 3 2Mb ATM connections in IMA). Supplying your complete pf.conf correctly commented with what you are wanting each rule and queue to accomplish is a good place to start. Our pf.conf file is quite long and complex (actually it is made of 3 different files included with anchors). Anyway, at this point, I'm only making a THEORETICAL question, to see if it can explain the bad behaviour I'm seeing. It's better explined with and example: Both users A and B have an assigned bandwidth of 1 bps. User A currently requires 4 bps. User B currently requires 100 bps. There are currently available 10 bps. I'd like that the 10 bps would be equally distributed to both users (as they have the same assigned bandwidth), so both had 5 bps. User A uses 4 bps and leaves 1 bps to user B that so uses 6 bps. Indeed it seems that, as user B requires 25 times more bandwidth of user A, then it is assigned almost ALL bandwidth, and user A is not able to use more then it's committed 1 bps, and so 3 out of 4 bits are dropped! Is this true? Thanks. -- ___ __ |- [EMAIL PROTECTED] |ederico Giannici http://www.neomedia.it ___ QUEUE BW SCH PRIO PKTSBYTES DROP_P DROP_B QLEN BORROW SUSPEN P/S B/S wdsl_i1650K hfsc 000 00 0 0 wdsl_hi_i1633K hfsc 000 00 0 0 wh1_i6400 hfsc 6715 18643310 00 0 0 wh2_i6400 hfsc397422 243653K33018 1870274 50 0 0 wh3_i6400 hfsc 1890986 722889K 112854 64732960 0 0 wh4_i2000 hfsc116512 98728K 275 616704 1 106 wh5_i2000 hfsc 1033715 6029800417576 9864980 0 0 wh6_i2000 hfsc119974 62863556 2953 2045623 1.0 53 wh7_i2000 hfsc 174129850 00 0 0 wh8_i2000 hfsc 1913030 130063K81439 46565320 0 0 wh9_i2000 hfsc 82929 89439226 11 6500 0 0 wh10_i 6400 hfsc 10806525 15417M 158664 229242K 35 348 527600 wh11_i 6400 hfsc 2207 14260260 00 0 0 wh12_i 2000 hfsc 49798 620441970 00 0 0 wh13_i 2000 hfsc219271 239251K 1380 981860 0 0 wh14_i 2000 hfsc 1152602 85891883 113484 6294012 28 0 0 wh15_i 6400 hfsc 3879133 407778K 372882 22772260 50 0 0 wh16_i 2000 hfsc157744 19172673 2573 1516180 0 0 wh17_i 2000 hfsc 34590 34553732 106 65980 0 0 wh18_i 6400 hfsc133850 172387K0 00 0 0 wh19_i 6400 hfsc 39296 38332321 78 78080 0 0 wh20_i 2000 hfsc 98808 73759318 770 1642540 0 0 wh21_i
Re: NAT-T support of PF
John Mok wrote: I hope someone to tell me if NAT-T support is available in PF, Yes it is, since 3.7. or 3.8 me thinks. Bob signature.asc Description: OpenPGP digital signature
Re: NAT-T support of PF
On Mon, Apr 23, 2007 at 07:11:05PM +0200, Daniel Hartmeier wrote:
On Mon, Apr 23, 2007 at 11:58:19PM +0800, John Mok wrote:
I am new to PF, and I would like to build a firewall + NAT using PF
on OpenBSD or FreeBSD. However, I hope someone to tell me if NAT-T
support is available in PF, such that the IPSec client connections
passing through the NAT box to Internet IPSec gateway will not
break.
NAT-T, as defined by RFC3947 [1], is not something a firewall has to
support, but something the IKE (IPSec client) can support.
It means that the IPSec peers will notice that there is a NAT device
in their path and will collaborate to traverse it, by encapsulating
their packets in UDP.
OpenBSD's isakmpd(8) supports this, and pf will work fine with it. The
question is whether another third-party IKE supports it and is
compatible. But there is nothing pf can do if it doesn't or isn't ;)
Daniel
[1] http://www.faqs.org/rfcs/rfc3947.html
I've had to add the following rule to make my users happy:
pass in on $lan_if inet proto { ah gre esp } from lan_clients to
!bad_destinations keep state
Otherwise some of them reported that they couldn't establish VPN
connections using the Cisco VPN client (for Windows). OpenVPN had no
problems as it immediately used UDP-encapsulation. Needless to say, I'm
not really satisfied with this voodoo solution, and comments are more
than welcome. Sorry if this breaks away from the original subject.
Martin
signature.asc
Description: Digital signature
