Re: [ANNOUNCE] ipset-5.0 released

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




OK, does that differ if I have hash:net,port set (I presume when listing with
ipset -L you will show the net ranges - 192.168.0.0-192.168.0.0,tcp:80-82), is
that right?

For net types the networks are not exploded, of course:

# ipset create test hash:net,port # ipset add test 192.168.0.0/30,tcp:80-82
# ipset list test
Name: test Type: hash:net,port Header: family inet hashsize 1024 maxelem 65536 Size in memory: 16856 References: 0 Members: 192.168.0.0/30,tcp:80 192.168.0.0/30,tcp:82 192.168.0.0/30,tcp:81
OK, it is much clearer to me now.

You are expanding the command line port ranges (80-82 in your example above) to add the underlying elements. Could you not do a similar arrangement for the protocol as well?

For example, if I execute "ipset add test 192.168.0.0/30,*:80-82" (or "all" instead of "*" if that is not possible) could you not expand that to represent the following elements:

192.168.0.0/30,tcp,80
..
192.168.0.0/30,tcp,82
192.168.0.0/30,udp,80
..
192.168.0.0/30,udp,82

It is not a perfect solution by any stretch, but at least it will save me the hassle, as with the introduction of the port ranges, of executing the statement twice each time I want to include net and port ranges without being interested in the protocol match.

As an aside note: since this is a hash set I am assuming that you use hashes to do the match as hash matching is very fast. I also presume that is the main reason you expand the port ranges so that you can calculate the hashes for that particular element and then match it with the real ip/subnet,protocol,port.

If that is the case how do you match subnets? In other words (using your example above) how do you match (the calculated hash for) 192.168.0.2,tcp:80 against (the calculated hash for) 192.168.0.0/30,tcp:80 - they, on the face of it, will differ!

However please note, the "net" types slow down linearly with the number of different network prefixes in the set.
Is this slowdown more than when I use iptreemap set for example? How does the new set (hash) performance compares against the 'old' iptreemap/treemap sets used in 4.x?

--
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


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux