those size means the hashtable size is 8192 and each incoming connection take one place, because you are hashing by srcip, that means you are tracking at most 8192 ip at same time. When hashtable is full and you will see that log and old entries will be dropped from the table to make room for new one. that will cause inaccurate tracking and all sorts of performance problem too On Sun, Nov 18, 2012 at 6:35 PM, 叶雨飞 <sunyucong@xxxxxxxxx> wrote: > those size means the hashtable size is 8192 and each incoming connection > take one place, because you are hashing by srcip, that means you are > tracking at most 8192 ip at same time. > > When hashtable is full and you will see that log and old entries will be > dropped from the table to make room for new one. > > > On Sun, Nov 18, 2012 at 8:45 AM, Marco Padovan <evcz@xxxxxxx> wrote: >> >> I'm using this ruleon iptables v1.4.7 >> >> >> iptables -A INSYNSRCLIMITER -m hashlimit --hashlimit-htable-expire 10000 >> --hashlimit-htable-size 8192 --hashlimit-htable-max 8192 >> --hashlimit-mode srcip --hashlimit-name insynlimiter --hashlimit 1/s >> --hashlimit-burst 25 -j RETURN >> >> >> while being "synflooded" and I'm seeing a lot of >> >> xt_hashlimit: max count of 8192 reached >> >> errors logged... really a lot (just to explain how many of those: got a >> bunch of "net_ratelimit: 42695 callbacks suppressed"logged too...) >> >> What does exactly that errors mean? >> >> did there was more then 8192 srcip to track and hashlimit went in >> overflow or am I using --hashlimit-htable-size and >> --hashlimit-htable-max in the wrong way? >> -- >> To unsubscribe from this list: send the line "unsubscribe netfilter" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
