As Andy muted there are commercial products that will attempt to do this
for you like Allot/Elacoya/DBAM the implementation and testing is where
this scenarios fail.
It sounds good in theory until you do it then all these odd network
errors start occurring. Cause you are now in the debate as what defines
an open or closed connection.
But here is what I know.
Look at simplest:
dstlimit
This module allows you to limit the packet per second (pps) rate
on a per destination IP or per destination port base. As opposed
to the ‘limit’ match, every destination ip / destination port has
it’s own limit.
Performance is a problem with the above
another iptables target is connrate you can use this to limit
connections from a set of IP addresses. So what you need to do is build
up a list of IP in a timer set and limit them however.
recent
Allows you to dynamically create a list of IP addresses and then
match against that list in a few different ways.
Here is a hack method of doing it imagining you are using layer7 patch.
Note you could do this using a span port if you dont want to be inline.
Every 10 minutes cat /proc/net/ip_conntrack put the output into a
database. Then use SQL group by statements to count the number of
connections per IP address src and say limit it to the TOP x%. Put this
x% into a ipset and ratelimit the connections OR stop them creating new
connections for 10 minutes use the ctstate to stop it. Or you can be
fancy and redirect them to a webpage and until they click OK they are
still in the ipset.
Enjoy reading about /proc/sys/.../*conntrack* params.
1 Huge double sided warning don't deploy this until you have really
tested it. The definition of what a connection is when it is defined as
open or closed is a complex subject e.g. each ping is that a connection?
Or are you only going to limit UDP/TCP in which case what about
tunnelling. Remember if someone has a virus that creates connections
this is another problem.
On Sat, 2006-11-11 at 12:54 +0000, Andy Furniss wrote:
> Graham Leggett wrote:
> > Mohan Sundaram wrote:
> >
> >> I've my misgivings with this scheme.
> >>
> >> 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.
> >>
> >> In many cases, the user may not know how many connections he is
> >> opening or which app is consuming connections. Thus, the user may not
> >> be in a position to take remedial action and hence will be at a
> >> disadvantage.
> >
> >
> > In the network in question, bandwidth is minimal (many many users
> > sharing 512kbps). As a result, unlike in typical networks where
> > simultaneous connections are statistically insignificant, in this case
> > one user running many bittorrents can pretty much wipe out network
> > performance to a ratio of 20 to 1 or more.
> >
> > The typical response I have seen to this scenario is to try and
> > prioritise certain protocols over others, but this strategy has the
> > disadvantage of dictating to the user that they can only use those
> > certain protocols.
> >
> > What I would like to do instead is allow the user to use any protocol
> > they like, with the caveat that attempting to open many connections
> > simultaneously will result in a steadily decreasing share of the pipe,
> > rather than a steadily increasing one.
>
> Your aims are admirable - I left my last ISP because they implemented
> app discrimination. Maybe they couldn't set their ellacoyas to do it
> fairly - whatever.
>
> Your situation is different - many many on 512kbs (512kbit or 4mbit?)
> either way the problem is that you are trying to shape ingress from the
> wrong end of the bottleneck which just isn't easy or totally doable.
> Egress shouldn't be affected by number of connections.
>
> As you have found the more connections the harder ingress shaping
> becomes - and you may need to sacrifice 50% of your bandwidth to keep
> control.
>
> There are things that can be tweaked regarding your setup - queue
> lengths being the main one. If you give users their own queues then you
> have to compromise - either the total is too long for your link or you
> have too short a queue for each user. ESFQ is the only thing (need to
> patch) that will do user fairness and maintain a queue len setting for
> the link (would be nice if hfsc etc could do this - may be possible to
> hack it as I see there is a drop function on leaf queues IIRC).
>
> Another hack is to make the esfq head drop (assumes you only send
> bulk/established connections to it).
>
> Without patching/hacking the think to do is use short queues to make
> sure you drop packets often so the tcp senders don't flood your
> ISP/teleco buffer. On 512kbit I also used to send new connections to an
> even shorter queue (new marked using iptables connbytes), this gets them
> out of tcp slowstart quicker.
>
> Bittorrent is slightly harder as it uses tcp full duplex for bulk - so
> acks tend to get piggybacked and stuck in egress queues meaning that non
> piggybacked acks overtake them (assuming your egress is set this way)
> and ack big chunks of a window at once causing burstiness - using short
> queues for egress bt helps this.
>
> You are always goinng to be somewhat screwed when ingress shaping as
> nothing happens to your shaping untill it's too late - maybe someone
> will make an ingress shaper one day that can be a bit predictive and
> back off other traffic for new connections sooner rather than later.
>
> Andy.
>
>
>
> _______________________________________________
> LARTC mailing list
> LARTC@xxxxxxxxxxxxxxxxxxx://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
