On 05/14/2012 09:00 PM, Stefan Berger wrote: > This patch adds support for the recent ipset iptables extension > to libvirt's nwfilter subsystem. Ipset allows to maintain 'sets' > of IP addresses, ports and other packet parameters and allows for > faster lookup (in the order of O(1) vs. O(n)) and rule evaluation > to achieve higher throughput than what can be achieved with > individual iptables rules. > > On the command line iptables supports ipset using > > iptables ... -m set --match-set <ipset name> <flags> -j ... > > where 'ipset name' is the name of a previously created ipset and > flags is a comma-separated list of up to 6 flags. Flags use 'src' and > 'dst' > for selecting IP addresses, ports etc. from the source or > destination part of a packet. So a concrete example may look like this: > > iptables -A INPUT -m set --match-set test src,src -j ACCEPT > > Since ipset management is quite complex, the idea was to leave ipset > management outside of libvirt but still allow users to reference an > ipset. > The user would have to make sure the ipset is available once the VM is > started so that the iptables rule(s) referencing the ipset can be > created. I think that at least a subset of it needs to be in libvirt, if only so that the use of ipset makes sense when it isn't available natively on a host. On that topic - could the new XML you're proposing be made useful/applicable with a packet filtering system other than iptables (or, for that matter, on a system with iptables but no ipset?). Or is it specific to ipset? (I haven't thought about it enough to come up with my own answer; I'm just at the stage of questions). I'm concerned that we might add something by definition iptables-specific, and even within that requiring a particular version of iptables, which would then be difficult/impossible to translate to some other filtering system. If there are too many features like that, we can be guaranteed that we'll never see any support other than iptables. (Yes, I know we currently only have a driver for iptables, but it seems like a good idea to not lock us into that. I've got this thought in the back of my head that maybe someday firewalld could (should?) be supported as a separate driver, rather than just using its passthrough mode (which bypasses some of the automatic management it's trying to provide, for better or for worse)) (It's really too bad nobody has written an ipf (or whatever) filter driver for libvirt - that would help keep us honest when adding new features :-) I may be worrying about nothing, as it does seem like a simple addition, but thought I should bring it up anyway, to make sure we go through due diligence. > > Using XML to describe an ipset in an nwfilter rule would then look as > follows: > > <rule action='accept' direction='in'> > <all ipset='test' ipsetflags='src,src'/> > </rule> > > The two parameters on the command line are also the two distinct XML > attributes > 'ipset' and 'ipsetflags'. > > FYI: Here is the man page for ipset: > > https://ipset.netfilter.org/ipset.man.html (That link fails for me unless I change https to http) -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list