NetworkManager will set all devices as `ip link set $IF up` early on, even if they are logically(!) disconnected.

-- that can be avoided, by configuring the device as unmanaged (via one of various methods).

NM does so, because it cares about carrier events, and it only gets these if the device is up.

It also means, your 

> ip link set up eth1
>
> It will not enable IPv6 on this interface by default.

will not actually do anything, because the device was already up.


Anyway, as long as there is no connection profile to activate, the device is logically disconnected. Which basically means to configure not IP addresses.

NM achieves that, by setting addrgenmode none. As you see with `ip -d link`. it also sets the /proc/sys/net/ipv6/conf/*/accept_ra* sysctl values, so that no SLAAC is done.


If you want to manually configure the device, you need also to do so fully. That means at least, to add (manually) an IPv6 link local address, or to reset addrgenmode. And to configure your non-link-local IP addresses (or re-enable accept_ra).


Possibly, if you anyway don't intend NM to manage this device, then mark it as unmanaged. That can be done ad-hoc (nmcli device $DEF set managed no) or permanently via configuration files or UDEV rules.



There is RFE bug 1628900 to keep the link down. But if that's done, it will have other downsides like no carrier events and NetworkManager wouldn't know whether a cable is plugged in.



Maybe you should explain *why* you are trying to do what you do.


> and then do:
> $ /sbin/service network restart
> Restarting network (via systemctl):  

With NetworkManager don't restart the network service. Instead, it'd be better to activate he desired profiles with nmcli.


It looks like, you just want to issue a

  $ nmcli device connect eth1

or
  $ nmcli connection up "$PROFILE_NAME"

> Maybe you should explain *why* you are trying to do what you do.

sorry, I mean: could you please elaborate the bigger picture of what you are doing? Thanks.

Thx Thomas for Your reply.

Big picture:
I need this for tempest tests in OpenStack - test tries to bring eth1 interface like in: https://github.com/openstack/tempest/blob/master/tempest/scenario/test_network_v6.py#L157
and then check if proper IPv6 address is configured on it.
In upstream CI it works because Cirros image is used but in our D/S CI we have job where RHEL image is used to spawn vms and that cause issues described in https://bugzilla.redhat.com/show_bug.cgi?id=1622077

I was trying to do
nmcli device connect eth1

instead of
ip link set up dev eth1

and indeed it enables for me IPv6 on this interface but IPv6 address configured on it was different then expected, see example:

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:8e:a3:e3 brd ff:ff:ff:ff:ff:ff
    inet6 1234::efc1:d3a7:885e:15/64 scope global noprefixroute dynamic
       valid_lft 86394sec preferred_lft 14394sec
    inet6 fe80::d9ec:dd03:b2dc:bf8f/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

when expected is: 1234::f816:3eff:fe8e:a3e3/64

I was also trying to do:
sudo nmcli device set eth1 managed no
sudo ip link set up dev eth1

and that also didn't solve my problem.

(In reply to Slawek Kaplonski from comment #4)
> Thx Thomas for Your reply.
> 
> Big picture:
> I need this for tempest tests in OpenStack - test tries to bring eth1
> interface like in:
> https://github.com/openstack/tempest/blob/master/tempest/scenario/
> test_network_v6.py#L157
> and then check if proper IPv6 address is configured on it.
> In upstream CI it works because Cirros image is used but in our D/S CI we
> have job where RHEL image is used to spawn vms and that cause issues
> described in https://bugzilla.redhat.com/show_bug.cgi?id=1622077
> 
> I was trying to do
> nmcli device connect eth1
> 
> instead of
> ip link set up dev eth1
> 
> and indeed it enables for me IPv6 on this interface but IPv6 address
> configured on it was different then expected, see example:
> 
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UP group default qlen 1000
>     link/ether fa:16:3e:8e:a3:e3 brd ff:ff:ff:ff:ff:ff
>     inet6 1234::efc1:d3a7:885e:15/64 scope global noprefixroute dynamic
>        valid_lft 86394sec preferred_lft 14394sec
>     inet6 fe80::d9ec:dd03:b2dc:bf8f/64 scope link noprefixroute
>        valid_lft forever preferred_lft forever
> 
> when expected is: 1234::f816:3eff:fe8e:a3e3/64

that is likely, because the profile that was activated that was has ipv6.addr-gen-mode=stable-privacy. The interface identifier is generated number, not the MAC address. That is the default for creating profiles in NetworkManager, because it makes the user less trackable. You can change it with `nmcli connection modify "$PROFILE" ipv6.addr-gen-mode eui64`.


> I was also trying to do:
> sudo nmcli device set eth1 managed no
> sudo ip link set up dev eth1
> 
> and that also didn't solve my problem.

Yes, that marks the device as unmanaged and leaves it. It does not restore addrgenmode eui64, nor accept_ra. If you take over the device, you need to fully configure it to your needs. Setting it "unmanaged" via nmcli only means, that NetworkManager won't touch the device anymore and that might be a good idea if you plan to go ahead and configure it (with iproute2?). Possibly NetworkManager should in this case do better at restoring a define state. But unclear which. For example, resetting "addrgenmode eui64" and accept_ra might connect the user although he doesn't want that.

Alternatively, you can configure the device as unmanaged via configuration files or udev rules, so it's unmanaged from the start an NM won't touch it.

I agree with Thomas, the NM behavior seems as expected. I see only two
alternatives if a user wants to configure IPv6 with EUI64 on a device:
either fully use NetworkManager by creating a suitable connection
profile:

 nmcli connection add type ethernet ifname eth1 con-name my-ethernet ipv6.addr-gen-mode eui64 ipv4.method disabled
 nmcli connection up my-ethernet

or don't use it at all by explicitly telling NM to unmanage the
device, then manually reset IPv6 parameters:

 nmcli device set eth1 managed no
 ip l set eth1 addrgenmode eui64
 echo 1 > /proc/sys/net/ipv6/conf/eth1/accept_ra
 # flip disable_ipv6 to start RA
 echo 1 > /proc/sys/net/ipv6/conf/eth1/disable_ipv6
 echo 0 > /proc/sys/net/ipv6/conf/eth1/disable_ipv6

The following should work as well as it makes the device unmanaged by
using an ifcfg file and then uses network-scripts to bring it up:

 echo "DEVICE=eth1"       > /etc/sysconfig/network-scripts/ifcfg-eth1
 echo "NM_CONTROLLED=no" >> /etc/sysconfig/network-scripts/ifcfg-eth1
 echo "IPV6INIT=yes"     >> /etc/sysconfig/network-scripts/ifcfg-eth1
 ifup eth1

Slawek, is any of those solutions acceptable in your opinion? If so, I
propose to close this as NOTABUG or CANTFIX.

Thx for investigating this and for Your tips. I think we can close this BZ now.