3

recently I do this on my iptables :

-A INPUT -p tcp --dst 192.168.0.0/16 -m hashlimit --hashlimit-above 32/sec --hashlimit-mode dstip --hashlimit-name hosts -j DROP

it seems that if my client receiving packet from net at the rate of above 32 pkt/s, iptables really drop it, my question is does the dropped packets is wasted? or the TCP protocol will adapt to it so it will request fewer packet?

uray
  • 245
  • 4
  • 7
  • 2
    Whilst you /can/ use iptables for connection limiting, I would argue that you should really be configuring a qdisc with `tc` and using a proper packet scheduling algorithm to throttle connections - you can then use `CLASSIFY` within iptables to use packet criteria for your throttling. – Olipro Dec 23 '11 at 20:50
  • the problem with tc is we only allowed to limit outgoing packet ( to the internet), for the incoming packet AFAIK the method is still dropping the packets that already arrive on receiving interface – uray Dec 24 '11 at 07:31
  • no, you can police incoming traffic with tc by passing it to an ifb (Intermediate Functional Block device) – Olipro Dec 27 '11 at 12:34

1 Answers1

3

Just because your server is not answering the traffic doesn't negate its existence: iptables (or any other "local" firewall) "dropping" a packet is the technological equivalent of having someone shouting at you and just not answering.

TCP will see the "dropped" packets as lost, and the other end of the connection should throttle itself automatically (the dropped packets will be retried, and the sending system will back off its transmit rate until it doesn't see packet loss anymore), but this may take a little while for the send rate to stabilize.
(Think of this as the technological equivalent of answering the shouting person every third of fourth time they try to get your attention -- eventually they'll get the hint and start only asking once. Hopefully.).

voretaq7
  • 79,879
  • 17
  • 130
  • 214