Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1367727 - NetworkManager would disable ra for nic
Summary: NetworkManager would disable ra for nic
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.3
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-08-17 10:26 UTC by Jianlin Shi
Modified: 2016-09-01 07:40 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-01 07:40:28 UTC


Attachments (Terms of Use)

Description Jianlin Shi 2016-08-17 10:26:51 UTC
Description of problem:
NetworkManager would disable ra for nic

Version-Release number of selected component (if applicable):
NetworkManager-1.4.0-0.5.beta1.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Install RHEL-7.3-20160811.0 and reboot
2. check accept_ra_pinfo of nic
3.

Actual results:
accept_ra_pinfo is 0

Expected results:
accept_ra_pinfo is 1

Additional info:


[root@hp-dl380pg8-12 ~]# rpm -qa | grep NetworkManager
NetworkManager-team-1.4.0-0.5.beta1.el7.x86_64
NetworkManager-config-server-1.4.0-0.5.beta1.el7.x86_64
NetworkManager-1.4.0-0.5.beta1.el7.x86_64
NetworkManager-libnm-1.4.0-0.5.beta1.el7.x86_64
NetworkManager-tui-1.4.0-0.5.beta1.el7.x86_64
[root@hp-dl380pg8-12 ~]# uname -a
Linux hp-dl380pg8-12.rhts.eng.pek2.redhat.com 3.10.0-489.el7.x86_64 #1 SMP Mon Aug 8 20:33:11 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux

[root@hp-dl380pg8-12 ~]# ip link sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000
    link/ether a0:d3:c1:fb:bb:bc brd ff:ff:ff:ff:ff:ff
3: eno2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT qlen 1000
    link/ether a0:d3:c1:fb:bb:bd brd ff:ff:ff:ff:ff:ff
4: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000
    link/ether a0:d3:c1:fb:bb:be brd ff:ff:ff:ff:ff:ff
5: ens1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000
    link/ether 7c:fe:90:bf:1e:80 brd ff:ff:ff:ff:ff:ff
6: eno4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000
    link/ether a0:d3:c1:fb:bb:bf brd ff:ff:ff:ff:ff:ff
7: ens1d1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT qlen 1000
    link/ether 7c:fe:90:bf:1e:81 brd ff:ff:ff:ff:ff:ff

[root@hp-dl380pg8-12 ~]# cat /proc/sys/net/ipv6/conf/eno3/accept_ra_pinfo 
0

[root@hp-dl380pg8-12 network-scripts]# cat ifcfg-eno3
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
PEERDNS=yes
PEERROUTES=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_PEERDNS=yes
IPV6_PEERROUTES=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eno3
UUID=2728004b-14da-4a13-8e35-5674f0d6b2b5
DEVICE=eno3
ONBOOT=no

Comment 1 Beniamino Galvani 2016-08-19 12:49:22 UTC
Hi,

this is possibly a duplicate of bug 1348216. The fact that accept_ra_pinfo=0 is expected as NM handles IPv6 autoconfiguration in userspace and thus it has to disable it in kernel. Can you please describe if you are experiencing any issues with IPv6 connectivity? Also, can you attach the output of 'nmcli connection', 'nmcli device', and 'ip addr'? Thanks!

Comment 2 Jianlin Shi 2016-08-20 13:06:04 UTC
[root@hp-dl380pg8-12 ~]# ip addr 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether a0:d3:c1:fb:bb:bc brd ff:ff:ff:ff:ff:ff
    inet 10.73.130.145/23 brd 10.73.131.255 scope global dynamic eno1
       valid_lft 43013sec preferred_lft 43013sec
    inet6 2620:52:0:4982:a2d3:c1ff:fefb:bbbc/64 scope global noprefixroute dynamic 
       valid_lft 2591890sec preferred_lft 604690sec
    inet6 fe80::a2d3:c1ff:fefb:bbbc/64 scope link 
       valid_lft forever preferred_lft forever
3: eno2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether a0:d3:c1:fb:bb:bd brd ff:ff:ff:ff:ff:ff
4: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether a0:d3:c1:fb:bb:be brd ff:ff:ff:ff:ff:ff
5: ens1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 7c:fe:90:bf:1e:80 brd ff:ff:ff:ff:ff:ff
6: ens1d1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 7c:fe:90:bf:1e:81 brd ff:ff:ff:ff:ff:ff
7: eno4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether a0:d3:c1:fb:bb:bf brd ff:ff:ff:ff:ff:ff
[root@hp-dl380pg8-12 ~]# nmcli c
NAME    UUID                                  TYPE            DEVICE 
eno1    f2a1fe06-d9a4-4935-8a56-d5a24546c0ea  802-3-ethernet  eno1   
eno2    57afcaca-3401-4e66-8cb8-a7415f2fee22  802-3-ethernet  --     
eno3    ab400b35-853f-4bbf-9163-af6925ec12a9  802-3-ethernet  --     
eno4    60d3e1e8-c9b1-4538-97f2-9419c9128647  802-3-ethernet  --     
ens1    b371c0d2-f12b-475a-9926-b92d64fba7cb  802-3-ethernet  --     
ens1d1  915cd1da-f44a-4f19-87d7-d531f8658403  802-3-ethernet  --     
[root@hp-dl380pg8-12 ~]# nmcli d
DEVICE  TYPE      STATE         CONNECTION 
eno1    ethernet  connected     eno1       
eno2    ethernet  disconnected  --         
eno3    ethernet  disconnected  --         
eno4    ethernet  disconnected  --         
ens1    ethernet  disconnected  --         
ens1d1  ethernet  disconnected  --         
lo      loopback  unmanaged     --


The issue we encountered:
we don't want some device to be controlled by NetworkManager, so we add NM_CONTROLLED=no to configuration and restart NetworkManager. After that, we want to get ipv6 through ra. but as ra is disabed, so we can't get ipv6.

Comment 3 Beniamino Galvani 2016-08-22 08:56:40 UTC
(In reply to Jianlin Shi from comment #2)
> [root@hp-dl380pg8-12 ~]# nmcli d
> DEVICE  TYPE      STATE         CONNECTION
> eno1    ethernet  connected     eno1

I assume this is the output before the NM restart (because eno1 state
should be 'unmanaged' after NM_CONTROLLED=no is added), right?

> The issue we encountered:
> we don't want some device to be controlled by NetworkManager, so we add
> NM_CONTROLLED=no to configuration and restart NetworkManager. After that, we
> want to get ipv6 through ra. but as ra is disabed, so we can't get ipv6.

After the configuration change you don't have to restart
NetworkManager, but you should issue a "nmcli connection reload",
which tells NM to read again the ifcfg files and unmanaged the
interface. When unmanaging an active device NM will restore the
value of accept_ra_* flags.

Instead if you restart NM, when the service is stopped it will leave
the flags set to 0 and when it starts again it won't touch the flags
because the interface is unmanaged.

Can you please try to replace the service restart with a "nmcli
connection reload"?

Comment 4 Jianlin Shi 2016-08-23 02:18:39 UTC
(In reply to Beniamino Galvani from comment #3)
> (In reply to Jianlin Shi from comment #2)
> > [root@hp-dl380pg8-12 ~]# nmcli d
> > DEVICE  TYPE      STATE         CONNECTION
> > eno1    ethernet  connected     eno1
> 
> I assume this is the output before the NM restart (because eno1 state
> should be 'unmanaged' after NM_CONTROLLED=no is added), right?

Yes

> 
> > The issue we encountered:
> > we don't want some device to be controlled by NetworkManager, so we add
> > NM_CONTROLLED=no to configuration and restart NetworkManager. After that, we
> > want to get ipv6 through ra. but as ra is disabed, so we can't get ipv6.
> 
> After the configuration change you don't have to restart
> NetworkManager, but you should issue a "nmcli connection reload",
> which tells NM to read again the ifcfg files and unmanaged the
> interface. When unmanaging an active device NM will restore the
> value of accept_ra_* flags.
> 
> Instead if you restart NM, when the service is stopped it will leave
> the flags set to 0 and when it starts again it won't touch the flags
> because the interface is unmanaged.
> 
> Can you please try to replace the service restart with a "nmcli
> connection reload"?

I tried to use "nmcli c reload".
and accept_ra_pinfo was restored to 1.

Another question, I found that "systemctl restart NetworkManager" in RHEL-7.2 would restore accept_ra_pinfo to 1. Which is the right,7.2 or 7.3?

Comment 5 Beniamino Galvani 2016-08-25 09:07:58 UTC
(In reply to Jianlin Shi from comment #4)
> 
> Another question, I found that "systemctl restart NetworkManager" in
> RHEL-7.2 would restore accept_ra_pinfo to 1. Which is the right,7.2 or 7.3?

Hmm, I see the same behavior on RHEL 7.2:

  # nmcli --version
  nmcli tool, version 1.0.6-30.el7_2

  # nmcli device
  DEVICE      TYPE      STATE         CONNECTION
  ens8        ethernet  connected     ens8+

  # cat /proc/sys/net/ipv6/conf/ens8/accept_ra_pinfo
  0

  (set NM_CONTROLLED=no in ifcfg file)

  # systemctl restart NetworkManager

  # nmcli device
  DEVICE      TYPE      STATE         CONNECTION
  ens8        ethernet  unmanaged     --

  # cat /proc/sys/net/ipv6/conf/ens8/accept_ra_pinfo
  0

I believe this is correct according to considerations in comment 3.

Comment 6 Jianlin Shi 2016-08-26 01:20:31 UTC
Here is the result I get on RHEL-7.2:

1. After install RHEL-7.2 and boot up:
[root@ibm-x3650m5-03 ~]# uname -a
Linux ibm-x3650m5-03.rhts.eng.pek2.redhat.com 3.10.0-327.el7.x86_64 #1 SMP Thu Oct 29 17:29:29 EDT 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@ibm-x3650m5-03 ~]# nmcli d
DEVICE       TYPE      STATE         CONNECTION 
eno1         ethernet  connected     eno1       
eno2         ethernet  disconnected  --         
eno3         ethernet  disconnected  --         
eno4         ethernet  disconnected  --         
enp0s20u1u5  ethernet  disconnected  --         
lo           loopback  unmanaged     --

[root@ibm-x3650m5-03 ~]# cat /proc/sys/net/ipv6/conf/eno3/accept_ra_pinfo 
0

2. add NM_CONTROLLED=no to ifcfg-eno3
3. restart NetworkManager

[root@ibm-x3650m5-03 network-scripts]# systemctl restart NetworkManager
[root@ibm-x3650m5-03 network-scripts]# cat /proc/sys/net/ipv6/conf/eno3/accept_ra_pinfo 
1
[root@ibm-x3650m5-03 network-scripts]# nmcli d
DEVICE       TYPE      STATE         CONNECTION 
eno1         ethernet  connected     eno1       
eno2         ethernet  disconnected  --         
eno4         ethernet  disconnected  --         
enp0s20u1u5  ethernet  disconnected  --         
eno3         ethernet  unmanaged     --         
lo           loopback  unmanaged     --

The difference between mine and yours is that eno3 is disconnected before restart NetworkManager. I don't know if that is the cause.

Comment 7 Beniamino Galvani 2016-08-29 13:20:35 UTC
The topic of how NM should leave interfaces after the stop of the
service is quite complex and there are different conflicting
requirements. On RHEL 7.2 a device in disconnected or unamanaged state
would be taken down upon termination, restoring the previous IPv6 RA
flags.

We changed that behavior according to bug [1] and now we avoid
touching them, and leave them up; this also means that NM will keep
the current state of the interface, including IPv6 RA flags.

Consider that the behavior of NM upon stop/restart is different from
initscripts because NM tries to leave interfaces configured as much as
possible so that it can identify after a restart which connections
were active. But we offer ways to reload changes without restarting
the service and those ways should be preferred to a restart.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1311988 from comment 9 on

Comment 8 Jianlin Shi 2016-08-30 01:20:32 UTC
Got it, so "nmcli c cli" is the proper way to use after -cfg file is changed.

Comment 9 Beniamino Galvani 2016-09-01 07:40:28 UTC
(In reply to Jianlin Shi from comment #8)
> Got it, so "nmcli c cli" is the proper way to use after -cfg file is changed.

Correct. Thanks for reporting and debugging this anyway.

I'm closing this bug, please reopen if needed.


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