Bug 1331009 - after restart of NetworkManager bond interface not coming up
Summary: after restart of NetworkManager bond interface not coming up
Keywords:
Status: CLOSED DUPLICATE of bug 1333983
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.2
Hardware: x86_64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-27 12:54 UTC by Rastislav Hepner
Modified: 2019-12-16 05:42 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-21 12:18:16 UTC
Target Upstream Version:


Attachments (Terms of Use)
logs from reproducer (146.11 KB, text/plain)
2016-04-27 12:54 UTC, Rastislav Hepner
no flags Details
ip link taken before NM restart (952 bytes, text/plain)
2016-04-27 12:58 UTC, Rastislav Hepner
no flags Details
ip link after nm restart (925 bytes, text/plain)
2016-04-27 12:59 UTC, Rastislav Hepner
no flags Details
ip addr before nm restart (1.34 KB, text/plain)
2016-04-27 13:00 UTC, Rastislav Hepner
no flags Details
ip addr taken after NM restart (1.20 KB, text/plain)
2016-04-27 13:01 UTC, Rastislav Hepner
no flags Details
all NetworkManager connection profiles (13.54 KB, text/plain)
2016-04-29 06:57 UTC, Rastislav Hepner
no flags Details

Description Rastislav Hepner 2016-04-27 12:54:11 UTC
Created attachment 1151368 [details]
logs from reproducer

Description of problem:

Problematic system has following interfaces setup.

+-----------------+                +----------------+
|                 |                |                |
|     eth0        |                |       eth1     |
+-------+---------+                +---------+------+
        |                                    |
        |                                    |
        +----+---------------------------+---+
             |                           |
             |                           |
             |            bond1          |
             +-------------+-------------+
                           |
                           |
                           |
             +-------------+-------------+
             |                           |
             |                           |
             |             Vlan0         |
             +-------------+-------------+
                           |
                           |
             +-------------+-------------+
             |                           |
             |       10.10.10.2/24       |
             |            br1            |
             +---------------------------+

After system boot everything seems to be fine and all devices come UP as expected. However once NetworkManager is restarted (systemctl restart NetworkManager) vlan0 device and bond1 will not come back up. 


Version-Release number of selected component (if applicable):
I've tried this on 2 versions symptoms seems to be identical:

NetworkManager-1.0.6-29.el7_2.x86_64
NetworkManager-1.0.6-27.el7_2.x86_64 

data are aquired while running 1.0.6-27

How reproducible:
It happens every time on configuration mentioned in description

Steps to Reproduce:
1. Setup network devices in configuration as shown in description. I've used nmtui.
2. Restart NetworkManager.
systemctl restart NetworkManager


Actual results: bond1 and vlan0 devices are down after restart.


Expected results: bond1 and vlan0 should come up after restart.


Additional info:

I'm attaching messages file containing logs generated while I was reproducing issue. I cut the file so it starts with system bootup (with problematic configuration already at place) Then after 5 min I've restarted NetworkManager.

I've attached also ip addr & ip link ... before/after NM restart.

If sosreport will be needed I can provide it.

Comment 1 Rastislav Hepner 2016-04-27 12:58:54 UTC
Created attachment 1151382 [details]
ip link taken before NM restart

Comment 2 Rastislav Hepner 2016-04-27 12:59:55 UTC
Created attachment 1151383 [details]
ip link after nm restart

Comment 3 Rastislav Hepner 2016-04-27 13:00:27 UTC
Created attachment 1151384 [details]
ip addr before nm restart

Comment 4 Rastislav Hepner 2016-04-27 13:01:19 UTC
Created attachment 1151385 [details]
ip addr taken after NM restart

Comment 7 Beniamino Galvani 2016-04-28 15:21:42 UTC
I can reproduce this. There are some messages in logs suggesting that the connection matching logic isn't picking up the existing connections for vlan and bond:

 Connection 'bond1' differs from candidate 'bond-bond1' in 802-3-ethernet.s390-options, 802-3-ethernet.s390-subchannels, 802-3-ethernet.s390-nettype
 Connection 'vlan0' differs from candidate 'vlan-vlan0' in 802-3-ethernet.s390-options, 802-3-ethernet.s390-subchannels, 802-3-ethernet.s390-nettype

I'm investigating the issue.

Comment 9 Beniamino Galvani 2016-04-28 19:29:15 UTC
The main issue in my tests is that when the bond is configured without
IP addresses, the interface is brought down after NM is stopped and not
activated on restart.

After assigning a static IP to the bond (nmcli con mod <con-name>
ipv4.method manual ipv4.address 172.31.255.255/32) the bond stays
up.

Which IP method did you set for the bond connection? Can you please
show the output of 'nmcli con show <con-name>'?

I tested this also with upstream git master of NM and the issue is
still reproducible there; probably we should improve how software
devices without IP configuration are handled upon restart.

Comment 10 Rastislav Hepner 2016-04-29 06:57:13 UTC
Created attachment 1152145 [details]
all NetworkManager connection profiles

Comment 11 Rastislav Hepner 2016-04-29 07:00:29 UTC
Hi,

I've tried simulate customers setting so I've set following on bond connection:

IPv4 disabled
IPv6 ignore


I've attached contents all connection profiles from my reproducer

Comment 13 Beniamino Galvani 2016-07-21 12:18:16 UTC
The scenario is similar to the one of bug 1333983 (vlan over bond/team
that is lost on restart) and there is already a patch there, so I'm
setting this a duplicate.

*** This bug has been marked as a duplicate of bug 1333983 ***


Note You need to log in before you can comment on or make changes to this bug.