Stop taking aspirin to deal with headaches from troubleshooting network availability issues.
Early in my career I was responsible for maintaining build machines for multiple software engineering teams. Those build machines not only built the actual binaries for the product but they also served up critical services leveraged by engineering teams across the company. Whenever we encountered networking issues with those machines, I distinctly remember opening my email inbox and being inundated with emails from coworkers complaining about problems connecting to those services. I had to immediately derail whatever I was working on and go into firefighting mode.
Sound familiar? Most of us probably have similar stories to this and would have preferred knowing the network was at risk before it actually went down. Sound like a pipe dream? This proactive knowledge and readiness is what Red Hat Insights is all about. To prevent you from spending the majority of your working hours firefighting network issues after they happen, Insights has released new rules to detect issues and recommend fixes before they cause network downtime.
For example, one new rule detects a bug that causes a kernel panic when a NIC with a jumbo frame joins an IPv6 multicast group. Wouldn’t you prefer knowing about this issue before your inbox explodes with complaints? Learn about this and other rules we have released that detect these types of issues before they happen.
| Rule | Description | Reference |
|---|---|---|
| FTP/TFTP service failure under high connection volume due to nf_conntrack expectations table being full | When there are huge numbers of client connections to an FTP/TFTP server, many “nf_conntrack: expectation table full” errors occur. | How to fix the 'expectation table full' error |
| Network interface with bnx2x driver intermittently drops connectivity with DCB mode errors | A network interface with the bnx2x driver intermittently drops connectivity when DCB is disabled in hardware but lldapd service is enabled. | bnx2x displaying DCBX mode errors |
| Device name contains extra whitespace after last double-quote | When the device or hardware name in the configuration file (/etc/sysconfig/network-scripts/ifcfg*) contains a space after the last double-quotation marks ("), it can cause the network interface to become inaccessible and the server to go offline. |
udev: renamed network interface eth0 to _eth0_ |
| Running ifdown on an alias interface such as eth0:1 removes all IPv4 IP addresses from the primary interface due to a known initscripts bug | When an alias interface is brought down using the ifdown command, the LABEL variable is not set due to a typo in the ifdown-eth script. Consequently, instead of removing just addresses belonging to the alias interface, all IP addresses on the device are removed. | ifdown on an alias interface removes all IP addresses |
| skb_over_panic happens on systems with jumbo frames and multiple IPv6 addresses | There is a known bug whereby generating an MLD listener report on devices with large MTUs and a high number of IPv6 addresses can trigger a skb_over_panic() event. | skb_over_panic after add_grhead |
| System crashes when “ethtool -S” is executed due to a known bug of the qlcnic driver in RHEL 7 | In some versions of the qlcnic driver, an issue exists that can cause it to drop its links and reset when ethtool -S is run against one of its managed devices. This command is executed by sosreport and various other collection or diagnostic tools, so it is possible to see a host start failing devices, returning I/O errors, or exhibiting other unexpected behavior after running such a tool. | RHEL server with qlcnic driver experiences link failures, "LOOP DOWN" messages, path failures, I/O errors, and/or crashes when running sosreport or 'ethtool' |
| ONBOOT=no setting is ignored for interface aliases | When ONBOOT=no is set on alias interfaces (ex. eth0:1), it has no effect. When the parent interface (ex. eth0) is brought up, the alias will always come up. | Setting ONBOOT=no is not valid for interfaces aliases |
| Docker containers are allowed to communicate regardless of “--icc=false” due to incorrect value of kernel bridge parameters | Docker daemon would create iptable rules to prevent containers from communicating with each other when “--icc=false”. But in Red Hat Enterprise Linux, the default value of bridge-nf-call-iptables and bridge-nf-call-ip6tables is 0 which means that iptables' rules do not affect bridge's traffic. Thus docker containers are allowed to communicate regardless of “--icc=false” option. | Why does not --icc work well? |
Register your machines now and avoid the future headaches of troubleshooting networking issues.
About The Author
Red Hat
Comments