Reviewed: https://review.opendev.org/678956
Committed:
https://git.openstack.org/cgit/openstack/charm-neutron-openvswitch/commit/?id=b76a59299794700fae1878af513c90ca5182a9f6
Submitter: Zuul
Branch: master
commit b76a59299794700fae1878af513c90ca5182a9f6
Author: tpsilva <tiago.pasqual...@canonical.com>
Date: Tue Aug 27 17:41:24 2019 -0300
Explicitly load nf_conntrack_ipv4 module
When neutron-openvswitch-agent is using the openvswitch firewall,
it needs the nf_conntrack_ipv4 module to be loaded. Usually, this
module gets loaded by some other external tool, but in case this
does not happen, neither the charm nor neutron will load it, so
all traffic to the instances in this host will fail. This patch
fixes that by explicitly loading the module.
Change-Id: Ia788e870c124de7da17961c02259cfe80938e5d2
Closes-bug: #1834213
** Changed in: charm-neutron-openvswitch
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1834213
Title:
After kernel upgrade, nf_conntrack_ipv4 module unloaded, no IP traffic
to instances
Status in OpenStack neutron-openvswitch charm:
Fix Committed
Status in linux package in Ubuntu:
Confirmed
Bug description:
With an environment running Xenial-Queens, and having just upgraded
the linux-image-generic kernel for MDS patching, a few of our
hypervisor hosts that were rebooted (3 out of 100) ended up dropping
IP (tcp/udp) ingress traffic.
It turns out that nf_conntrack module was loaded, but
nf_conntrack_ipv4 was not loading, and the traffic was being dropped
by this rule:
table=72, n_packets=214989, priority=50,ct_state=+inv+trk
actions=resubmit(,93)
The ct_state "inv" means invalid conntrack state, which the manpage
describes as:
The state is invalid, meaning that the connection tracker
couldn’t identify the connection. This flag is a catch-
all for problems in the connection or the connection
tracker, such as:
• L3/L4 protocol handler is not loaded/unavailable.
With the Linux kernel datapath, this may mean that
the nf_conntrack_ipv4 or nf_conntrack_ipv6 modules
are not loaded.
• L3/L4 protocol handler determines that the packet
is malformed.
• Packets are unexpected length for protocol.
It appears that there may be an issue when patching the OS of a
hypervisor not running instances may fail to update initrd to load
nf_conntrack_ipv4 (and/or _ipv6).
I couldn't find anywhere in the charm code that this would be loaded
unless the charm's "harden" option is used on nova-compute charm (see
charmhelpers contrib/host templates). It is unset in our environment,
so we are not using any special module probing.
Did nf_conntrack_ipv4 get split out from nf_conntrack in recent kernel
upgrades or is it possible that the charm should define a modprobe
file if we have the OVS firewall driver configured?
To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1834213/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
