From: jan@aims.ac.za (Jan Groenewald)
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Strategy for penalising IPs with too many simultaneous
Date: Sat, 11 Nov 2006 18:01:00 +0000 [thread overview]
Message-ID: <20061111180100.GJ5850@aims.ac.za> (raw)
In-Reply-To: <454BDA1F.2010301@sharp.fm>
Hi
On Sat, Nov 04, 2006 at 07:08:04AM +0530, Mohan Sundaram wrote:
> What you are doing makes sense only if the number of connections is a
> constrained resource. If bandwidth is the constraint, then shaping by
> source IP irrespective of number of connections will do the job. As far
> as I've seen, routers can support 200k connections and this is
> sufficient for many large LANs - say 500 node LAN with 400 connections
> per node.
I have this situation where the source IPs change on a wireless mesh.
I want fair nat. I found the fairnat script and have been reading the
lartc howto, but am not sure how to proceed.
(fairnat at http://www.metamorpher.de/fairnat/)
I want everyone to burst to (almost, a specified percentage like 90%)
full, but when all IPs are on, to share fairly irrespective of number of
connections. The IPs change dynamically. If the user doesn't know why
their P2P or download manager is slowing them down, their problem. They can
run whatever they want. I just don't want one user to flood out the rest,
and there should be a little spare so it doesn't take time to correct
for light users.
Oh, and upload limiting (also fairly) for the lot would be good, as this
rate is limited, e.g. 512 down and 128 up.
And it is running on freifunk on a Linksys WRT 54 GL, so performance
might be an issue on the 200Mhz processor. At the moment freifunk comes
with ingress (by internal destination IP) limiting quite nicely. The
number of clients is expected to be 0 to 64. I can deal with large
numbers of clients later, if it ever happens.
cheers,
Jan
--
.~.
/V\ Jan Groenewald
/( )\ www.aims.ac.za
^^-^^
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
prev parent reply other threads:[~2006-11-11 18:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-04 0:09 [LARTC] Strategy for penalising IPs with too many simultaneous Graham Leggett
2006-11-04 0:17 ` Stephen Hemminger
2006-11-04 1:50 ` Mohan Sundaram
2006-11-04 11:14 ` Graham Leggett
2006-11-04 15:40 ` Peter Surda
2006-11-05 21:47 ` Andrew Beverley
2006-11-11 12:54 ` Andy Furniss
2006-11-11 13:42 ` Oscar Mechanic
2006-11-11 18:01 ` Jan Groenewald [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061111180100.GJ5850@aims.ac.za \
--to=jan@aims.ac.za \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.