Bug 1323571

Summary: failed to disable userspace IPv6LL address handling
Product: Red Hat Enterprise Linux 7 Reporter: Alexander Koksharov <akokshar>
Component: NetworkManagerAssignee: Thomas Haller <thaller>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: low Docs Contact:
Priority: medium    
Version: 7.3CC: akokshar, aloughla, aos-bugs, atragler, bgalvani, dcbw, lrintel, mleitner, ptalbert, rkhan, thaller, vbenes
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-03 19:08:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Alexander Koksharov 2016-04-04 07:04:28 UTC
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):

How reproducible:

Steps to Reproduce:

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).

Comment 1 Ben Bennett 2016-05-26 16:07:36 UTC
I think this is a NM issue, not an openshift SDN one.

Comment 2 Rashid Khan 2016-05-26 17:33:48 UTC
Luckily we have the chief architect of NM working in our team. 
sending it to him. :-)

Comment 3 Dan Williams 2016-06-02 14:45:52 UTC
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.

Comment 4 Dan Williams 2016-06-02 14:46:49 UTC
Warning comes from nm-device.c::set_nm_ipv6ll(); it's a bit hard to grep for since the 'disabled' is actually dynamically decided.

Comment 6 Thomas Haller 2016-07-05 13:18:44 UTC
branch for review: th/avoid-wrong-warnings-rh1323571

Comment 7 Beniamino Galvani 2016-07-05 17:04:52 UTC
(In reply to Thomas Haller from comment #6)
> branch for review: th/avoid-wrong-warnings-rh1323571


Comment 11 Vladimir Benes 2016-09-23 13:02:05 UTC
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.

Comment 13 errata-xmlrpc 2016-11-03 19:08:37 UTC
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.