iptables: fail to start ovs/linuxbridge agents on missing sysctl knobs
For new kernels (3.18+), bridge module is split into two pieces: bridge
and br_netfilter. The latter provides firewall support for bridged
traffic, as well as the following sysctl knobs:
Before kernel 3.18, any brctl command was loading the 'bridge' module
with the knobs, so at the moment where we reached iptables setup, they
were always available.
With new 3.18+ kernels, brctl still loads 'bridge' module, but not
br_netfilter. So bridge existance no longer guarantees us knobs'
presence. If we reach _enable_netfilter_for_bridges before the new
module is loaded, then the code will fail, triggering agent resync. It
will also fail to enable bridge firewalling on systems where it's
disabled by default (examples of those systems are most if not all Red
Hat/Fedora based systems), making security groups completely
ineffective.
Systems that don't override default settings for those knobs would work
fine except for this exception in the log file and agent resync. This is
because the first attempt to add a iptables rule using 'physdev' module
(-m physdev) will trigger the kernel module loading. In theory, we could
silently swallow missing knobs, and still operate correctly. But on
second thought, it's quite fragile to rely on that implicit module
loading. In the case where we can't detect whether firewall is enabled,
it's better to fail than hope for the best.
An alternative to the proposed path could be trying
to fix broken deployment, meaning we would need to load the missing
kernel module on agent startup. It's not even clear whether we can
assume the operation would be available to us. Even with that, adding a
rootwrap filter to allow loading code in the kernel sounds quite scary.
If we would follow the path, we would also hit an issue of
distinguishing between cases of built-in kernel module vs. modular one.
A complexity that is probably beyond what Neutron should fix.
The patch introduces a sanity check that would fail on missing
configuration knobs.
DocImpact: document the new deployment requirement in operations guide
UpgradeImpact: deployers relying on agents fixing wrong sysctl defaults will need to make sure bridge firewalling is enabled. Also, the kernel module providing sysctl knobs must be loaded before starting the agent, otherwise it will fail to start.
Changes made to this backport: neutron/agent/linux/iptables_firewall.py
- removed deprecation warning when setting sysctl values to 1 as
they are planned to be removed in Ocata neutron/cmd/sanity/checks.py
- Re-implemented the flow to check only for presence of sysctl options instead of checking the values. Kernel options are set
in runtime thus the values don't matter.
Reviewed: https:/ /review. openstack. org/398817 /git.openstack. org/cgit/ openstack/ neutron/ commit/ ?id=4371a4f5cdc 6559955af9158c4 c28851e77914da
Committed: https:/
Submitter: Jenkins
Branch: stable/newton
commit 4371a4f5cdc6559 955af9158c4c288 51e77914da
Author: Ihar Hrachyshka <email address hidden>
Date: Thu Sep 15 21:48:10 2016 +0000
iptables: fail to start ovs/linuxbridge agents on missing sysctl knobs
For new kernels (3.18+), bridge module is split into two pieces: bridge
and br_netfilter. The latter provides firewall support for bridged
traffic, as well as the following sysctl knobs:
* net.bridge. bridge- nf-call- arptables bridge- nf-call- ip6tables bridge- nf-call- iptables
* net.bridge.
* net.bridge.
Before kernel 3.18, any brctl command was loading the 'bridge' module
with the knobs, so at the moment where we reached iptables setup, they
were always available.
With new 3.18+ kernels, brctl still loads 'bridge' module, but not netfilter_ for_bridges before the new
br_netfilter. So bridge existance no longer guarantees us knobs'
presence. If we reach _enable_
module is loaded, then the code will fail, triggering agent resync. It
will also fail to enable bridge firewalling on systems where it's
disabled by default (examples of those systems are most if not all Red
Hat/Fedora based systems), making security groups completely
ineffective.
Systems that don't override default settings for those knobs would work
fine except for this exception in the log file and agent resync. This is
because the first attempt to add a iptables rule using 'physdev' module
(-m physdev) will trigger the kernel module loading. In theory, we could
silently swallow missing knobs, and still operate correctly. But on
second thought, it's quite fragile to rely on that implicit module
loading. In the case where we can't detect whether firewall is enabled,
it's better to fail than hope for the best.
An alternative to the proposed path could be trying
to fix broken deployment, meaning we would need to load the missing
kernel module on agent startup. It's not even clear whether we can
assume the operation would be available to us. Even with that, adding a
rootwrap filter to allow loading code in the kernel sounds quite scary.
If we would follow the path, we would also hit an issue of
distinguishing between cases of built-in kernel module vs. modular one.
A complexity that is probably beyond what Neutron should fix.
The patch introduces a sanity check that would fail on missing
configuration knobs.
DocImpact: document the new deployment requirement in operations guide
will need to make sure bridge firewalling is enabled.
Also, the kernel module providing sysctl knobs must be
loaded before starting the agent, otherwise it will fail
to start.
UpgradeImpact: deployers relying on agents fixing wrong sysctl defaults
Changes made to this backport:
neutron/ agent/linux/ iptables_ firewall. py
neutron/ cmd/sanity/ checks. py
options instead of checking the values. Kernel options are set
- removed deprecation warning when setting sysctl values to 1 as
they are planned to be removed in Ocata
- Re-implemented the flow to check only for presence of sysctl
in runtime thus the values don't matter.
Depends-On: Id6bfd9595f0772 a63d1096ef83ebb b6cd630fafd 92a05f73863b77f 9ee4681bbe7 81b7cc684ac9048 6b283a3507)
Change-Id: I9137ea017624ac
Related-Bug: #1622914
(cherry picked from commit e83a44b96a8e3cd