Bug 1367727

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!

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

(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"?

(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?

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

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.

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

Got it, so "nmcli c cli" is the proper way to use after -cfg file is changed.

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