On Thu, Sep 23, 2010 at 10:31:38AM -0400, Stefan Berger wrote:
On 09/23/2010 09:09 AM, Daniel P. Berrange wrote:
On 09/23/2010 07:33 AM, Daniel P. Berrange wrote:
On Wed, Sep 22, 2010 at 02:19:31PM -0400, Stefan Berger wrote:
On a recent installation of FC13, the filtering of IP/IPv6 using iptables/ip6tables traffic did not work since the proc filesystem entries /proc/sys/net/bridge/bridge-nf-call-iptables and /proc/sys/net/bridge/bridge-nf-call-ip6tables contained a zero each and no traffic went into the FORWARD chain. The patch below makes sure that if iptables or ip6tables are being used by the nwfilter driver that a '1' is written into the relevant proc filesystem entry so that the traffic goes into the FORWARD chain. What parts of the nwfilter functionality gets affected by this ?
IIUC, the higher level protocols, TCP, UDP, SCTP, ICMP, IGMP, ESP, AH, UDPLITE& 'ALL' get implemented via iptables ? Alot of the matches you can define using these higher level protocols, can also be defined using the generic IPv4/IPv6 rules. For example everything you can do with TCP protocol can be done with the IPv4/IPv6 protocol, with exception of ip address ranges.
Could we either
1. Document that if you want to make use of the higher level protocols, that you need to enable bridge-nf-call-iptables and explain the tradeoffs in that setting.[1][2]
2. Provide an alternative impl of 90% of the higher level protocols, using ebtables instead of iptables. And make choice of iptables vs ebtables a config param for libvirtd. eg, for most people an ebtables based impl will be sufficient but if they need the full funtionality,then switch to the iptables impl& enable bridge-nf-call-iptables=1 Actally I guess 2. is rather pointless given that you can already just use the IPv4/6 generic rules to do 90% of that stuff. I think this just comes down to a documentation issue, explaining the pros&cons of each
On Thu, Sep 23, 2010 at 11:36:11AM +0100, Daniel P. Berrange wrote: possible bridge-nf-call-* setting. Yes, it should work and would be a matter of writing the rules differently so that they get enforced on ebtables layer rather than iptables.
I still think that if the user writes filtering rules that end up creating iptables rules that in that case the bridge-nf-call-* should automatically be enabled by libvirt so that the filtering works as expected -- assuming the user would end up doing the same anyway (after looking for the reason why it does not work as expected). The problem is that changing bridge-nf-call-* may make libvirt's functionality behave 'as expected', but since this is a system wide setting, it will change the behaviour of other non-libvirt apps in ways that may not be expected. For example, it may cause
On Thu, Sep 23, 2010 at 08:45:41AM -0400, Stefan Berger wrote: packet loss with UDP, because it means that TUNSETSNDBUF will no longer throttle guest UDP packets from QEMU. http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=0df0ff6de7
This is the patch and posting on the qemu mailing list. It's interesting to see how things are tied together... I wonder whether ebtables rules are also going to orphan the packets due to it also using (bridge-)netfilter?
That's a good question....
In this case the admin may well prefer to rewrite their nwfilter rule to use the 'ipv4' match, rather than have libvirt silently change the bridge-nf-call-* settings.
Perhaps we should log a warning if a rule is activated for a guest, that we know will have no effect, due to bridge-nf-call-* settings.
I guess we can do that. Should we log it into libvirt log or into the system log ?
libvirtd configures anything at WARN/ERROR level to go to syslog by default, so just logging to libvirt is sufficient Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|