This bug is missing log files that will aid in diagnosing the problem.
While running an Ubuntu kernel (not a mainline or third-party kernel)
please enter the following command in a terminal window:
apport-collect 1834213
and then change the status of the bug to 'Confirmed'.
If, due to the nature of the issue you have encountered, you are unable
to run this command, please add a comment stating that fact and change
the bug status to 'Confirmed'.
This change has been made by an automated script, maintained by the
Ubuntu Kernel Team.
** Changed in: linux (Ubuntu)
Status: New => Incomplete
--
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:
Incomplete
Status in linux package in Ubuntu:
Incomplete
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 : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
