Description of problem: Recently customers have been encountering a situation where nf_conntrack modules were loading and causing packets to drop with: nf_conntrack: table full, dropping packet visible in logs. How reproducible: Somewhat Actual results: Documentation does not suggest blacklisting nf_conntrack modules to prevent this behavior which can result in the above behavior and networking problems down the road for a cluster. Expected results: Documentation should suggest blacklisting the conntrack modules in the Pre-Installation portion of the Installation guide documentation: Additional info: Creating a file named /etc/modprobe.d/conntrack.conf and adding the following lines: blacklist nf_conntrack blacklist nf_conntrack_ipv6 blacklist xt_conntrack blacklist nf_conntrack_ftp blacklist xt_state blacklist iptable_nat blacklist ipt_REDIRECT blacklist nf_nat blacklist nf_conntrack_ipv4 should do the trick, but a reboot will be required. Also, note that running any form of iptables rules may re-enable the conntrack modules.
Hi Bara, Can you please respond to the query asked in Comment 6 and Comment 7. Also in Redhat Installation guide: https://gitlab.cee.redhat.com/red-hat-ceph-storage-documentation/doc-Red_Hat_Ceph_Storage_1.3-Installation_Guide_for_Red_Hat_Enterprise_Linux/commit/2f0c61fa9e54c7444e9099922358b67c09f6d995 I don't see the Note Section: +NOTE: Running any form of the `iptables` rules can enable the `nf-conntrack` +modules again. Make sure to blacklist the modules before changing the +`iptables` rules. But in Ubuntu its present.
Marking this as verified.
We might need to change this recommendation; discussion in bug 1304004
What does the Ceph traffic look like which triggers this? Maybe there is a better way to avoid state table exhaustion rather than disabling the stateful firewall completely.
*** Bug 1304004 has been marked as a duplicate of this bug. ***