Ignore prior comment:
$ lsmod | grep conntrack
nf_conntrack_ipv6 20480 1
nf_conntrack_ipv4 16384 1
nf_defrag_ipv4 16384 1 nf_conntrack_ipv4
nf_defrag_ipv6 36864 2 nf_conntrack_ipv6,openvswitch
nf_conntrack 131072 6
nf_conntrack_ipv6,nf_conntrack_ipv4,nf_nat,nf_nat_ipv6,nf_nat_ipv4,openvswitch
libcrc32c 16384 5 nf_conntrack,nf_nat,openvswitch,xfs,raid456
as soon as a loaded the openvswitch kernel module the nf_conntrack_*
modules where loaded as well.
** Changed in: charm-neutron-openvswitch
Status: New => Incomplete
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
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:
New
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
