It's more helpful to look separate ifcfg-rh questions from questions how NetworkManager handles IP configuration.

That means, ifcfg-rh is merely used as a file-format to load/store connection profiles.


If you have a problem with ifcfg-rh, then provide the exact ifcfg file in question (/etc/sysconfig/network-scripts/ifcfg-eth0 ) and also the output of how this profile looked after loading it in NetworkManager: `nmcli connection show "$NAME"`. If you think that NetworkManager interpreted the ifcfg file wrongly, then that is a bug. No need to concern yourself with sysctl.


Another question regards the IPv6 configuration that NetworkManager does.
E.g. what is the ipv6.method in question? What sysctls were set, etc.
For that, if possibly always provide a level=TRACE logfile of NetworkManager showing the issue. And again, the settings of the NetworkManager profile (`nmcli connection show "$NAME"`).



Note that the IPv6 settings depend on a combination of variables in ifcfg-rh (https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c?id=da100581188f71f60f1a59f4af368c431d860298#n1995). Just setting one variable may not have the desired effect, and depends what else is configured in the ifcfg file.



At the least, please provide the ifcfg file and how the profile looks to NM after `nmcli connection reload`. Thanks

Created attachment 1539138 [details]
more detailed log

(In reply to Thomas Haller from comment #2)
> It's more helpful to look separate ifcfg-rh questions from questions how
> NetworkManager handles IP configuration.
> 
> That means, ifcfg-rh is merely used as a file-format to load/store
> connection profiles.
> 
> 
> If you have a problem with ifcfg-rh, then provide the exact ifcfg file in
> question (/etc/sysconfig/network-scripts/ifcfg-eth0 ) and also the output of
> how this profile looked after loading it in NetworkManager: `nmcli
> connection show "$NAME"`. If you think that NetworkManager interpreted the
> ifcfg file wrongly, then that is a bug. 


This is what I like to discuss here, currently NetworkManger and VDSM are not
in sync about this.

>
> No need to concern yourself with sysctl.
> 

oVirt/VDSM uses this to detect the current state of IPv6 autoconf.

> 
> Another question regards the IPv6 configuration that NetworkManager does.
> E.g. what is the ipv6.method in question? What sysctls were set, etc.
> For that, if possibly always provide a level=TRACE logfile of NetworkManager
> showing the issue. And again, the settings of the NetworkManager profile
> (`nmcli connection show "$NAME"`).
> 
> 

Done in  attachment 1539138 [details]

> 
> Note that the IPv6 settings depend on a combination of variables in ifcfg-rh
> (https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/
> settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.
> c?id=da100581188f71f60f1a59f4af368c431d860298#n1995). Just setting one
> variable may not have the desired effect, and depends what else is
> configured in the ifcfg file.
> 
> 
> 
> At the least, please provide the ifcfg file and how the profile looks to NM
> after `nmcli connection reload`. Thanks

the ifcfg file in question is:

# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
BOOTPROTO="dhcp"
BOOTPROTOv6="dhcp"
ONBOOT="yes"
TYPE="Ethernet"
USERCTL="yes"
PEERDNS="yes"
IPV6INIT="yes"
PERSISTENT_DHCLIENT="1"
IPV6_AUTOCONF=no


First of all, the log file from comment 3 does not indicate that you reloaded the profile after editing the ifcfg file.
Editing a file on disk is only picked up by NetworkManager

   - after restart of NetworkManager (this is not the preferred way!!)

   - after `nmcli connection reload`

   - after `nmcli connection load $FILENAME`

   - with "monitor-connection-files" enabled (`man NetworkManager.conf`) (but this is strongly discouraged!!)

   - `ifup/ifupdown eth0` also issues a `nmcli connection load`, followed by `nmcli connection up`.

That means, you edited the file on disk but that had no effect to NetworkManager.



Now, with the provided file ifcfg-eth0 file, after  `nmcli connection reload`, you would get:

$ nmcli -o connection show "System eth0"
connection.id:                          System eth0
connection.uuid:                        5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
connection.type:                        802-3-ethernet
connection.interface-name:              eth0
ipv4.method:                            auto
ipv6.method:                            link-local
ipv6.addr-gen-mode:                     eui64

note, ipv6.method=link-local.

If you look at [1], you'll see that that is because of IPV6INIT="yes" and expected.

It seems fragile to just "IPV6_AUTOCONF=no >> /etc/sysconfig/network-scripts/ifcfg", but OK, that can be made to work.


[1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c?id=da100581188f71f60f1a59f4af368c431d860298#n1995





Also note that NetworkManager may not set /proc/sys/net/ipv6/conf/eth0/accept_ra as you expect it. NetworkManager sets certain sysctl according to what it thinks it is right. In several cases, it won't set accept_ra=0 although autoconf is not enabled. There are various reasons for that. But the bug just claims that the sysctl values are not as you expect. But it doesn't say on which basis you think that is wrong, or why you expect them to be in a certain way. You say "oVirt/VDSM uses this to detect the current state of IPv6 autoconf.", but what exactly does this mean? What does VDSM want to know?

Created attachment 1539177 [details]
fixed flow

(In reply to Thomas Haller from comment #5)
> the ifcfg file in question is:
> 
> # cat /etc/sysconfig/network-scripts/ifcfg-eth0
> DEVICE="eth0"
> BOOTPROTO="dhcp"
> BOOTPROTOv6="dhcp"
> ONBOOT="yes"
> TYPE="Ethernet"
> USERCTL="yes"
> PEERDNS="yes"
> IPV6INIT="yes"
> PERSISTENT_DHCLIENT="1"
> IPV6_AUTOCONF=no
> 
> 
> First of all, the log file from comment 3 does not indicate that you
> reloaded the profile after editing the ifcfg file.
> Editing a file on disk is only picked up by NetworkManager
> 
>    - after restart of NetworkManager (this is not the preferred way!!)
> 
>    - after `nmcli connection reload`
> 
>    - after `nmcli connection load $FILENAME`
> 
>    - with "monitor-connection-files" enabled (`man NetworkManager.conf`)
> (but this is strongly discouraged!!)
> 
>    - `ifup/ifupdown eth0` also issues a `nmcli connection load`, followed by
> `nmcli connection up`.
> 
> That means, you edited the file on disk but that had no effect to
> NetworkManager.
> 
> 

Thanks, I repeated the updated flow.

> 
> Now, with the provided file ifcfg-eth0 file, after  `nmcli connection
> reload`, you would get:
> 
> $ nmcli -o connection show "System eth0"
> connection.id:                          System eth0
> connection.uuid:                        5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03
> connection.type:                        802-3-ethernet
> connection.interface-name:              eth0
> ipv4.method:                            auto
> ipv6.method:                            link-local
> ipv6.addr-gen-mode:                     eui64
> 
> note, ipv6.method=link-local.
> 

ack

> If you look at [1], you'll see that that is because of IPV6INIT="yes" and
> expected.
> 

ack

> It seems fragile to just "IPV6_AUTOCONF=no >>
> /etc/sysconfig/network-scripts/ifcfg", but OK, that can be made to work.
> 

Why?
How would you expect a static IPv6 configuration would look be created by
editing ifcfg files?
Is there a simpler way to configure only static IPv6 address?

> 
> [1]
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/
> plugins/ifcfg-rh/nms-ifcfg-rh-reader.
> c?id=da100581188f71f60f1a59f4af368c431d860298#n1995
> 
> 
> 
> 
> 
> Also note that NetworkManager may not set
> /proc/sys/net/ipv6/conf/eth0/accept_ra as you expect it. NetworkManager sets
> certain sysctl according to what it thinks it is right.

Maybe we have to go the stony path to discuss this.

> In several cases, it
> won't set accept_ra=0 although autoconf is not enabled.

Interesting, can you provide an example?

> There are various
> reasons for that. But the bug just claims that the sysctl values are not as
> you expect. But it doesn't say on which basis you think that is wrong, or
> why you expect them to be in a certain way. You say "oVirt/VDSM uses this to
> detect the current state of IPv6 autoconf.", but what exactly does this
> mean? What does VDSM want to know?

Basically VDSM uses (autoconf && accept_ra && accept_redirects) as value for
autoconf in
https://github.com/oVirt/vdsm/blob/4d157eb23b0cc72b820636625252c5d4128b2652/lib/vdsm/network/sysctl.py#L70

maybe this is not optimal and should be improved. Do you have suggestion how
VDSM should detect if autoconf is enabled?

Thomas, please note the lines 1748 and 1770 in the attachment, too.

> > It seems fragile to just "IPV6_AUTOCONF=no >>
> > /etc/sysconfig/network-scripts/ifcfg", but OK, that can be made to work.
> > 
>
> Why?
> How would you expect a static IPv6 configuration would look be created by
> editing ifcfg files?

The IP configuration in a ifcfg is composed from multiple variables. Only appending
IPV6_AUTOCONF=no at the end may result in a profile with "ipv6.method=ignore", or
"ipv6.method=link-local", or "ipv6.method=manual". It seems fragile to blindly
append to the ifcfg file and make assumptions. But sure, whatever works for you.

> Is there a simpler way to configure only static IPv6 address?

That depends what you want exactly.

  $ nmcli connection modify filename /etc/sysconfig/network-scripts/ifcfg-eth0 ipv6.method link-local


> Thomas, please note the lines 1748 and 1770 in the attachment, too.

   1746 [root@ifcgtest ~]# cat /proc/sys/net/ipv6/conf/eth0/{autoconf,accept_ra,accept_redirects}
   1747 1
   1748 0
   1749 1

NetworkManager does not touch "autoconfg" nor "accept_redirects" sysctl. I don't know what you expect
it to be (or why).

Yes, NetworkManager sets accept_ra=0 with ipv6.method=link-local.


> > In several cases, it
> > won't set accept_ra=0 although autoconf is not enabled.
>
> Interesting, can you provide an example?

No, I was wrong about "accept_ra". NetworkManager sets that to 0 in most cases.

Note that even when doing ipv6.method=auto, it will leave accept_ra at 0. That is, because NetworkManager
does NDP in userspace, not letting kernel do it.

So, while NM most of the time sets accept_ra to 0, it does so also when doing AUTOCONF.

Hence, the check that VDSM performs certainly does not look right with NetworkManager.


> maybe this is not optimal and should be improved. Do you have suggestion how
> VDSM should detect if autoconf is enabled?

Why does VDMS want to check this? If the device is managed by NetworkManager, what does VDSM want
to know?

(In reply to Thomas Haller from comment #7)

> Why does VDMS want to check this? If the device is managed by
> NetworkManager, what does VDSM want
> to know?

VDSM reports back to the manager the state of the dynamic/static config.
Then the manager can create the correct command to send back to VDSM and define the needed configuration, tacking ownership of the relevant devices.

So we just need to report if dhcpv6 is enabled and/or autoconf/ra is enabled.
If we do not need to contact NM api, it will be simpler for VDSM at the moment (until we have nmstate) but we can query NM as we do today when acquiring NM devices.

in this issue there seem to be different problems.

1) one issue was that after editing profiles in disk, the changes must be reloaded (e.g with `nmcli con reload`). That seems fixed/addressed now.

2) another question was how exactly NetworkManager interprets ifcfg files and how VDMS should edit the files for them to be correct. The ifcfg file format is not exactly beautiful, but the high level solution is that your ifcfg reader/writer has sufficient logic to support the cases that it cares about. The details here are omitted, I'd recommend to write tests for the code to cover all the relevant cases. What matters from NetworkManager's point of view, is how the profile looks after loading the ifcfg file (`nmcli -o connection show filename /etc/sysconfig/network-manager/ifcfg-$NAME`). So, when writing tests, a useful approach may be to double check with how NetworkManager interprets the file.

3) the most relevant aspect here is how a tool (VDSM) can detect whether DHCPv6/autoconf is enabled on the system. Looking at sysfs values isn't going to work. That's because for DHCPv6 it's entirely in user-space and for autoconf it's also done by NetworkManager in user-space (while there are sysfs values like "accept_ra", but those control kernel -- and are disabled). Currently the only way is to ask NetworkManager via it's D-Bus API (or any tools which uses that API, like nmcli). Possibly, if the current approach is too cumbersome, we could extend the API to make that simpler. Either we could add new D-Bus API to get the information in a simpler manner, or we could even write state files to /run/NetworkManager, that indicates what is happening. Anyway, designing such an API is out of scope for this rhbz nor is it clear how that exactly should look. Also check with nmstate -- which has this very same problem and the same solution applies for VDSM as well.


Finally, rhel-7 is at the end of active development, so we are unlikely adding new API (for point 3). I am thus closing this bug as WONTFIX. If you disagree or have anything to add, please comment or reopen.

Thank you!