Red Hat Bugzilla – Bug 1323571
failed to disable userspace IPv6LL address handling
Last modified: 2018-10-23 04:10:38 EDT
Description of problem: In the message logs of the application node I can see the following messages: Mar 24 12:46:17 node04 NetworkManager[607]: <warn> (lbr0): failed to detach bridge port veth849200e Mar 24 12:46:17 node04 ovs-vsctl: ovs|00001|vsctl|INFO|Called as ovs-vsctl add-port br0 veth849200e Mar 24 12:46:17 node04 NetworkManager[607]: <warn> (veth849200e): failed to disable userspace IPv6LL address handling Mar 24 12:46:17 node04 nm-dispatcher: Dispatching action 'down' for veth849200e Mar 24 12:46:17 node04 kernel: device veth849200e entered promiscuous mode Are the warnings visible there something to be concerned about? Version-Release number of selected component (if applicable): 3.1.1 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: From the SME thread this seems to be an issue with the RHEL 7.2 NM code, and would be a bug (in that these warning should have been suppressed).
I think this is a NM issue, not an openshift SDN one.
Luckily we have the chief architect of NM working in our team. sending it to him. :-)
The warning doesn't actually indicate a problem, and it should probably be suppressed. NM is reporting events that already occurred as it catches up with what openshift-node is doing. Reassigning to NM team for more analysis. NM should probably handle ENODEV better here by not warning, if we can detect those cases accurately.
Warning comes from nm-device.c::set_nm_ipv6ll(); it's a bit hard to grep for since the 'disabled' is actually dynamically decided.
branch for review: th/avoid-wrong-warnings-rh1323571
(In reply to Thomas Haller from comment #6) > branch for review: th/avoid-wrong-warnings-rh1323571 LGTM
merged to upstream master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=6f31f878713eb0c23f19bd342c35f05841399b1d
harmless bug, moving to verified sanity only as the code is in and I haven't seen any errors like this and obviously customer is OK with it as well as the ticket was closed a long time ago.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2581.html