Hi Patrick,
Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>> So we can still do this adding rules with the iptables interface. But
>> still having the /proc looks like a simple interface for this.
>
> I'm sure someone would argue that changing TCP port numbers of
> the tcp match through proc would be a nice and simple interface.
> The fact though is that we have an interface for handing a
> configuration to the kernel and this is clearly a configuration
> parameter. We're missing a proper way to use it in userspace
> from within programs (well, hopefully not for long anymore),
> but that needs to be fixed in userspace.
While reworking this, I think that I have found one argument to support
the /proc interface that looks interesting in terms of resource
consumption. Assume that we have three nodes, where two of them are
down, thus, the only one active would have the following rule-set:
iptables -A PREROUTING -t mangle -i eth0 -m cluster \
--cluster-total-nodes 3 --cluster-local-node 1 \
-j MARK --set-mark 0xffff
iptables -A PREROUTING -t mangle -i eth0 -m cluster \
--cluster-total-nodes 3 --cluster-local-node 2 \
-j MARK --set-mark 0xffff
iptables -A PREROUTING -t mangle -i eth0 -m cluster \
--cluster-total-nodes 3 --cluster-local-node 3 \
-j MARK --set-mark 0xffff
iptables -A PREROUTING -t mangle -i eth0 \
-m mark ! --mark 0xffff -j DROP
Look at the worst case: if the packet goes to node 3, the hashing must
be done to check if the packet belongs to node 1 and node 2. Thus, the
hashing is done three times. This makes the cluster hashing O(n) where n
is the number of cluster nodes.
A possible solution (that thinking it well, I don't like too much yet)
would be to convert this to a HASHMARK target that will store the result
of the hash in the skbuff mark, but the problem is that it would require
a reserved space for hashmarks since they may clash with other
user-defined marks.
--
"Los honestos son inadaptados sociales" -- Les Luthiers
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
