Hello Mihai,
: Can you post a real script using esfq, that splits the bandwidth
: equally per IP?
I wish I had an example script to lend you....
To my recollection your issue was an obnoxious piece of software which was
generating many outbound flows. This sort of a technique should prevent
any single IP from dominating your bandwidth (without your allowing that
domination):
tc qdisc add dev $LAN_DEV parent $HTB_CLASS handle $ESFQ_HANDLE \
esfq perturb 10 depth $UNIQUE_CLIENTS hash dst
This attaches an esfq qdisc to the class which contains competing
workstations/users for download bandwidth (in your environment).
Reminder! We have already deNATted (is that a word) the inbound packets,
so the destination is the real workstation IP, and the
Here's the help string [from the README]....
Usage: ... esfq [ perturb SECS ] [ quantum BYTES ] [ depth FLOWS ]
[ divisor HASHBITS ] [ limit PKTS ] [ hash HASHTYPE]
Where:
HASHTYPE := { classic | src | dst }
I'd agree that the easily available documentation for ESFQ is minimal....I
would love to remedy that, so let me know how your experimentation with
the qdisc goes. In your case, I'd suggest starting with a "hash dst".
When I cautioned about Jon Zeeff's patch [0], I didn't necessarily mean to
scare you away from it. It may be a very good patch--I simply wanted to
point out that there already exists a tool to solve the problem you
appeared to need to solve. Note also the recent list activity (by
Chijioke Kalu) with regard to kernel-2.6 and ESFQ [1].
Also, the section of my text (from tldp.org) you quoted was specifically
about the very same download accelerators which were giving you fits.
These tools simultaneously create a large number of TCP connections for a
single application-layer function (usually fetching a large file) in order
to (attempt to) defeat per-connection byte-rate limits. The design of SFQ
did not anticipate this deliberate flooding attempt. ESFQ takes a step
toward correcting this.
Again, I don't know if ESFQ will solve your problem--I hope it does, and I
hope to hear a report from you that this was the tool you needed.
Best of luck,
-Martin
[0] http://mailman.ds9a.nl/pipermail/lartc/2003q4/010919.html
[1] http://mailman.ds9a.nl/pipermail/lartc/2003q4/010939.html
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
