Hello! There was a plan to write ipset+iptables config with many ipsets(combination of hash:net + bitmap:port). To test how many sets can I add - I have written little script to create and populate ipset rules in a loop. When executing script I hit the error:"ipset v6.11: Kernel error received:maximal number of sets reached, cannot create more." I was really surprised that this error hit already on 254 set limit with type hash:net sets(last lines of "ipset save" follows) create NET-254 hash:net family inet hashsize 1024 maxelem 65536 add NET-254 10.1.1.0/24 If I added type bitmap:port set creation in loop - I got exactly half count of every type(last lines of "ipset save" follows): create NETs-127 hash:net family inet hashsize 1024 maxelem 65536 add NETs-127 10.1.1.0/24 create PORTs-127 bitmap:port range 1-35635 add PORTs-127 80 Questions: 1)what parameters can I tune to get more ipsets(couple thousands I guess)? sysctl? RAM size?. Recompiling kernel is not an option this time. 2)statistically there would be sets of type hash:net(1-3 members each) + bitmap:port sets(1-5 members each) and lots of iptables rules with combinations of those as src,dst + protocol match. Probably count of iptables rules can grow over 1-2 thousand. What would be less harm to packet latency(assuming match on last iptables rule) - less iptables rules+ipsets(let's say 1K iptables rules + 2K ipsets(if possible) ) OR no ipsets at all and lots of iptables rules(let's say 5K iptables rules)? 3)Anybody seen any benchmarks iptables rule count vs packet latency - what is the reasonable limit for iptables, ipset rule count after all? Any CPU core must scan all ipset rules anyway(I guess), so more cores would just multiply packets being processed paralelly, but not speed up single packet latency, right? Linux: 3.2.0-29-generic x86_64 Mem: 1994316k total OS=Ubuntu 12.04.1 LTS Thanks for clarification in advance! Ugis -- 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
