I have a host recently updated to f20, with virtual machines using bridged networking. When I switch to NetworkManager controlled networking, the virtual machines' DHCP requests failed.
After much messing around, I have found that when NM is on, by the time the system has booted, bridge-nf-call-iptables, bridge-nf-call-ip6-tables and bridge-nf-call-arptables have all been set to 1, so something has overriden the setting from /usr/lib/sysctl.d/00-system.conf.
Is there some setting I am missing here?
Thanks Paul
NOTICE & DISCLAIMER This email including attachments (this "Document") is confidential and may contain legally privileged information. If you have received this Document in error please notify the sender immediately and delete this Document from your system without using, copying, disclosing or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of this Document.
The information contained in this Document is provided solely for information purposes on an "as is" basis without warranty of any kind, either express or implied, including without limitation any implied warranty of satisfactory or merchantable quality, fitness for a particular purpose or freedom from error or infringement. The user relies on the information contained herein, and its accuracy or otherwise, entirely at their own risk.
Any opinions expressed in this Document are those of the author and do not necessarily reflect the opinions of Telsis. We will not accept responsibility for any commitments made by our employees outside the scope of our business.
On 23.10.2013 10:44, Paul Knox-Kennedy wrote:
I have a host recently updated to f20, with virtual machines using bridged networking. When I switch to NetworkManager controlled networking, the virtual machines' DHCP requests failed.
After much messing around, I have found that when NM is on, by the time the system has booted, bridge-nf-call-iptables, bridge-nf-call-ip6-tables and bridge-nf-call-arptables have all been set to 1, so something has overriden the setting from /usr/lib/sysctl.d/00-system.conf.
Is there some setting I am missing here?
You're not missing anything. It is a BUG not resolved to this day. There is a workaround that works perfectly for me and maybe others. Create file /etc/NetworkManager/dispatcher.d/00-sysctl with following content:
#!/bin/sh
/usr/lib/systemd/systemd-sysctl
exit 0
Mateusz Marzantowicz
-----Original Message----- From: test-bounces@lists.fedoraproject.org [mailto:test-bounces@lists.fedoraproject.org] On Behalf Of Mateusz Marzantowicz Sent: 23 October 2013 10:25 To: test@lists.fedoraproject.org Subject: Re: NM controlled bridge turns on netfilter
On 23.10.2013 10:44, Paul Knox-Kennedy wrote:
I have a host recently updated to f20, with virtual machines using bridged networking. When I switch to NetworkManager controlled networking, the virtual machines' DHCP requests failed.
After much messing around, I have found that when NM is on, by the time the system has booted, bridge-nf-call-iptables, bridge-nf-call-ip6-tables and bridge-nf-call-arptables have
all been
set to 1, so something has overriden the setting from /usr/lib/sysctl.d/00-system.conf.
Is there some setting I am missing here?
You're not missing anything. It is a BUG not resolved to this day. There is a workaround that works perfectly for me and maybe others. Create file /etc/NetworkManager/dispatcher.d/00-sysctl with following content:
#!/bin/sh
/usr/lib/systemd/systemd-sysctl
exit 0
Mateusz Marzantowicz
test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Many thanks for that, your workaround resolved my issues. Is there a bugzilla entry for this? I couldn't find anything in redhat or gnome bugzilla that seemed to apply.
Cheers Paul
NOTICE & DISCLAIMER This email including attachments (this "Document") is confidential and may contain legally privileged information. If you have received this Document in error please notify the sender immediately and delete this Document from your system without using, copying, disclosing or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of this Document.
The information contained in this Document is provided solely for information purposes on an "as is" basis without warranty of any kind, either express or implied, including without limitation any implied warranty of satisfactory or merchantable quality, fitness for a particular purpose or freedom from error or infringement. The user relies on the information contained herein, and its accuracy or otherwise, entirely at their own risk.
Any opinions expressed in this Document are those of the author and do not necessarily reflect the opinions of Telsis. We will not accept responsibility for any commitments made by our employees outside the scope of our business.
On 23.10.2013 12:41, Paul Knox-Kennedy wrote:
Many thanks for that, your workaround resolved my issues. Is there a bugzilla entry for this? I couldn't find anything in redhat or gnome bugzilla that seemed to apply.
Cheers Paul
Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=512206
Searching for "net.bridge.bridge-nf-call-iptables" should give you more holistic view about this issue.
I'm not convinced anyone is working on this bug because it has CLOSED status, maybe someone kowledgeable from RH or Fedora community could drop some info about it.
Mateusz Marzantowicz
On 23.10.2013 14:30, Mateusz Marzantowicz wrote:
On 23.10.2013 12:41, Paul Knox-Kennedy wrote:
Many thanks for that, your workaround resolved my issues. Is there a bugzilla entry for this? I couldn't find anything in redhat or gnome bugzilla that seemed to apply.
Cheers Paul
Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=512206
Searching for "net.bridge.bridge-nf-call-iptables" should give you more holistic view about this issue.
I'm not convinced anyone is working on this bug because it has CLOSED status, maybe someone kowledgeable from RH or Fedora community could drop some info about it.
That bug only deals with the default situation but doesn't really address what happens when try to override this in sysctl.d so I'd suggest filing a new bug for that.
Regards, Dennis
[mailto:test-bounces@lists.fedoraproject.org] On Behalf Of Dennis Jacobfeuerborn Sent: 24 October 2013 11:38
That bug only deals with the default situation but doesn't really address what happens when try to override this in sysctl.d so I'd suggest filing a new bug for that.
Regards, Dennis
Raised https://bugzilla.redhat.com/show_bug.cgi?id=1022977. Do Fedora maintainers raise upstream issues, or am I expected to do that?
NOTICE & DISCLAIMER This email including attachments (this "Document") is confidential and may contain legally privileged information. If you have received this Document in error please notify the sender immediately and delete this Document from your system without using, copying, disclosing or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of this Document.
The information contained in this Document is provided solely for information purposes on an "as is" basis without warranty of any kind, either express or implied, including without limitation any implied warranty of satisfactory or merchantable quality, fitness for a particular purpose or freedom from error or infringement. The user relies on the information contained herein, and its accuracy or otherwise, entirely at their own risk.
Any opinions expressed in this Document are those of the author and do not necessarily reflect the opinions of Telsis. We will not accept responsibility for any commitments made by our employees outside the scope of our business.
On 10/24/2013 01:57 PM, Paul Knox-Kennedy wrote:
[mailto:test-bounces@lists.fedoraproject.org] On Behalf Of Dennis Jacobfeuerborn Sent: 24 October 2013 11:38
That bug only deals with the default situation but doesn't really address what happens when try to override this in sysctl.d so I'd suggest filing a new bug for that.
Regards, Dennis
Raised https://bugzilla.redhat.com/show_bug.cgi?id=1022977. Do Fedora maintainers raise upstream issues, or am I expected to do that?
I have seen Fedora maintainers raise an issue upstream on several ocassions. However, it can never hurt to file a bug upstream and reference it in BZ 1022977 and vice versa. It might even speed up things depending on how busy the Fedora maintainer is.
Regards, Patrick
I have just faced this problem, on a Fedora 20 fresh install. All Fedora 19 works out of the box with the same setup. It seems a regression to me.
Raised https://bugzilla.redhat.com/show_bug.cgi?id=1022977.
Do Fedora maintainers raise upstream issues, or am I expected to do that?
AFAICS the "fix" for this bug is only a documentation change on sysctl.d, no actual fix was applied. The only related bug still open is https://bugzilla.gnome.org/show_bug.cgi?id=710858, but it seems abandoned.
The fact is that if you follow http://wiki.libvirt.org/page/Networking#Fedora.2FRHEL_Bridging but keep NetworkManager instead of network to manage your bridges, it works perfectly on F19, but not on Fedora 20.
Based on this, I think that we should have at least an open bug addresing this problem. What do you think?
Regards,
On Fri, 2014-10-03 at 14:07 -0300, Bruno Medeiros wrote:
I have just faced this problem, on a Fedora 20 fresh install. All Fedora 19 works out of the box with the same setup. It seems a regression to me.
Raised https://bugzilla.redhat.com/show_bug.cgi?id=1022977.
Do Fedora maintainers raise upstream issues, or am I expected to do that?
AFAICS the "fix" for this bug is only a documentation change on sysctl.d, no actual fix was applied. The only related bug still open is https://bugzilla.gnome.org/show_bug.cgi?id=710858, but it seems abandoned.
The fact is that if you follow http://wiki.libvirt.org/page/Networking#Fedora.2FRHEL_Bridging but keep NetworkManager instead of network to manage your bridges, it works perfectly on F19, but not on Fedora 20.
Based on this, I think that we should have at least an open bug addresing this problem. What do you think?
I don't know why you see it as an F19 to F20 regression, because I'm fairly sure it's been broken the whole time. I've been trying to get it fixed for a while. The originator bug is https://bugzilla.redhat.com/show_bug.cgi?id=634736 . I have a write-up at https://www.happyassassin.net/2014/07/23/bridged-networking-for-libvirt-with... which has the current 'recommended' workaround. It's been broken basically forever, NM has never worked around this problem as network.service does.
On Fri, Oct 3, 2014 at 2:36 PM, Adam Williamson adamwill@fedoraproject.org wrote:
I don't know why you see it as an F19 to F20 regression, because I'm fairly sure it's been broken the whole time.
I have two servers now running libvirtd + firewalld + NM, one is F19 and the other (the newest) one is F20. I just checked here and the F19 server has neither /etc/modules-load.d nor /etc/udev/rules.d files regarding the workaround. So, for some reason, it works on F19! Maybe the order systemd runs something.. I don't know. I just know that I followed the same procedure I used to setup libvirt on F19 to setup F20 and it didn't work (at least without the workaround).
I've been trying to get it fixed for a while. The originator bug is https://bugzilla.redhat.com/show_bug.cgi?id=634736 . I have a write-up at
https://www.happyassassin.net/2014/07/23/bridged-networking-for-libvirt-with... which has the current 'recommended' workaround. It's been broken basically forever, NM has never worked around this problem as network.service does.
Thank you for pointing the current bug, I think it should be linked to the original one (https://bugzilla.redhat.com/show_bug.cgi?id=512206) because it can drive someone crazy! ;)
I also think that there should be a warning on libvirt doc pointing to your write-up (or the bug) in case someone decides to use NM instead of network.
If you need some help testing, please let me know.
-- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net
-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
On Fri, 2014-10-03 at 18:04 -0300, Bruno Medeiros wrote:
On Fri, Oct 3, 2014 at 2:36 PM, Adam Williamson adamwill@fedoraproject.org wrote:
I don't know why you see it as an F19 to F20 regression, because I'm fairly sure it's been broken the whole time.
I have two servers now running libvirtd + firewalld + NM, one is F19 and the other (the newest) one is F20. I just checked here and the F19 server has neither /etc/modules-load.d nor /etc/udev/rules.d files regarding the workaround. So, for some reason, it works on F19! Maybe the order systemd runs something.. I don't know. I just know that I followed the same procedure I used to setup libvirt on F19 to setup F20 and it didn't work (at least without the workaround).
There's about a dozen other ways you could possibly work around it - there may be a script in rc.local or something? I'm fairly sure there's nothing in any Fedora release to 'fix' it.
Thank you for pointing the current bug, I think it should be linked to the original one (https://bugzilla.redhat.com/show_bug.cgi?id=512206) because it can drive someone crazy! ;)
Sure, throw a comment in or something!
I also think that there should be a warning on libvirt doc pointing to your write-up (or the bug) in case someone decides to use NM instead of network.
The problem with adding docs to *everything* is you have to remember to take them out again when the bug is actually fixed...I'd probably rather just get the damn thing fixed, it really shouldn't be much trouble but it keeps winding up stuck between teams.
On 10/04/2014 01:35 PM, Adam Williamson wrote:
On Fri, 2014-10-03 at 18:04 -0300, Bruno Medeiros wrote:
On Fri, Oct 3, 2014 at 2:36 PM, Adam Williamson adamwill@fedoraproject.org wrote:
I don't know why you see it as an F19 to F20 regression, because I'm fairly sure it's been broken the whole time.
I have two servers now running libvirtd + firewalld + NM, one is F19 and the other (the newest) one is F20. I just checked here and the F19 server has neither /etc/modules-load.d nor /etc/udev/rules.d files regarding the workaround. So, for some reason, it works on F19! Maybe the order systemd runs something.. I don't know. I just know that I followed the same procedure I used to setup libvirt on F19 to setup F20 and it didn't work (at least without the workaround).
There's about a dozen other ways you could possibly work around it - there may be a script in rc.local or something? I'm fairly sure there's nothing in any Fedora release to 'fix' it.
Thank you for pointing the current bug, I think it should be linked to the original one (https://bugzilla.redhat.com/show_bug.cgi?id=512206) because it can drive someone crazy! ;)
Sure, throw a comment in or something!
I also think that there should be a warning on libvirt doc pointing to your write-up (or the bug) in case someone decides to use NM instead of network.
The problem with adding docs to *everything* is you have to remember to take them out again when the bug is actually fixed...I'd probably rather just get the damn thing fixed, it really shouldn't be much trouble but it keeps winding up stuck between teams.
OK, I posted my suggested "temporary" solution to the BZ report: https://bugzilla.redhat.com/show_bug.cgi?id=634736
Someone suggested a reasonable solution to the problem would be to simply add the bridge module to the basic kernel. As a quick, simple fix (and not really a horrible hack) I add to file to /etc/modules-load.d/ for bridge. Tested and works on Fedora 20 and Fedora 21 on all of my systems. Without the early load some systems worked and some did not (reliably and repeatable).
Adam, I suggest that you add this to your writeup on bridging.
BTW, a great big THANK YOU for working out how to do bridging when running NetworkManager.
Gene
-
Adam Williamson -
Bruno Medeiros -
Dennis Jacobfeuerborn -
Gene Czarcinski -
Mateusz Marzantowicz -
Patrick Lists -
Paul Knox-Kennedy