Jan Engelhardt wrote:
On Thursday 2008-05-22 21:18, Patrick McHardy wrote:
Additionally it natively supports sets, bitmaps and hashes, so your
500 source IP rules can be represented as a single rule with,
depending on how the IPs are distributed, either O(1) or O(n) lookup
time.
That sounds just like what ipsets does today.
Yes, but not for arbitary data. Even verdicts (including jumps) and
argument selection for other modules like MARK, ...
Also, netlink, at least
when using the TLV infrastructure it provides, does not come without
a cost—namely encoding and decoding to/from nlmsg structures. I
suggest to test-run the current binary protocol (a concatenation of
struct ipt_entries etc.) over netlink first before changing it to
something dynamic. Also, from what I have read from the iproute2
source so far, each attribute has an index, and that's rather bad for
add-on modules which want to define arbitrary attributes.
Netlink message size is limited, but you can of course use
lists of attributes or structures.
Are the plans for that online somewhere? Is there
a envisioned time line?
The plans come mostly from multiple discussions on this list
and in private, as well as my dislikes of certains aspects
of iptables (like the insane amount of modules).
If it's just the number of source files, then that is an easy
target; these can be collapsed into one file. That would
reduce both compile time and the runtime overhead.
Concrete thoughts: combine
- xt_{CLASSIFY,CONNMARK,CONNSECMARK,MARK,SECMARK,connmark,mark}
- xt_{ah,esp,policy}
- xt_{conntrack,state}, though I'd say let's obsolete xt_state
- xt_{RATEEST,rateest}
- xt_{connbytes,connlimit,length,limit,hashlimit,quota,statistic}
- xt_{ECN,DSCP,HL,TTL,ecn,hl,dscp,ttl}
- xt_{comment,string,time,u32}
- xt_{addrtype,pkttype}
- xt_{hbh,dst,frag,eui64,ipv6header}
Roughly, there will be:
- data module: any packet data: headers, payload
- meta module: meta-data associated with packet, maybe also conntrack things
and others
- maybe conntrack module if not contained in meta module
- existing stateful modules like limit, hashlimit, ...
And whatever is still missing. The logic how to use them will
be completely in userspace. Meaning the data module doesn't
care at all what kind of data it looks at, the set lookup
doesn't care whether its a port number, an IP address or
an ifindex, ...
I'm asking because I'm thinking about whether or not
it's feasible and/or sensibly to write some kind
of target module that I'm choosing to call "jumpset" for now, that
would act as a fast (>O(log(n)) "jump diststribution point".
Thats one of the things I also want to add (halfway finished yet).
Jumps are regular verdicts in my new design and verdicts can be
gathered though lookups in sets, hashes etc. So you could do:
unnamed ... -j { 192.168.0.1:chain_1, 192.168.0.2:chain_2, ...}
This comes at the expense of ease-of-use. But you can persuade me to
agree on something à la
iptables -N 'chainx[0]'
iptables -N 'chainx[1]'
iptables -s 192.168.17.0/24 -j 'chainx[]'
Thats not any simpler. Besides such optimization also may be
performed by the userspace tool, the user doesn't necessarily
has to do them himself. Though this is not planned for an
initial version.
I also want to have the same working for mark etc:
unnamed ... -j MARK --set-mark { 192.168.0.1:1, 192.168.0.2: 2, .. }
See IPMARK.
or alternatively:
unnamed ... -j MARK --set-mark ip-dst & 0xFF
See IPMARK!
(Hint: http://dev.medozas.de/gitweb.cgi?p=xtables-addons )
Hint2:
... -j IPMARK --addr dst
... -j MARK --and-mask 0xFF
1. So?
2. You don't get it. Thats another special-casing module, exactly
the think I *don't* like. How many more of these (with slightly
differing semantic and features) should we add?
--
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
