Bug 1815060

Thank you for the logfile.



It can be seen that NetworkManager activates a connection profile on these devices. At 

  > [1584618316.9363] device (ens1f0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')

that fails, and the device goes down. That implies that NetworkManager will cleanup the IP configuration on that device.
Also, the NetworkManager logfile shouts <warn> messages about this.


You may very well configure the interface outside of NetworkManager (e.g. with a script and iproute2), but then do it in a way so that NetworkManager doesn't interfere. There are several alternatvies here.


1.) A sensible one is to mark the devices as unmanaged. You can either do that ad-hoc (`nmcli device set $IFNAME managed no`) or persistently via configuration. In the latter case, you can do that via udev rules (e.g. see `/usr/lib/udev/rules.d/85-nm-unmanaged.rules`), or via NM_CONTROLLED=no in ifcfg files, or via device.managed=0 setting in NetworkManager.conf. I'd recommend a file /etc/NetworkManager/conf.d/99-unmanage-devices.conf with

  [device-99-unmanage-devices]
  match-device=interface-name:ens1*
  managed=0

This seems the preferred thing to do here.

This file will work after reboot. But if the device is already managed at the moment, then `systemctl reload NetworkManager` will not make it unmanaged (because the runtime configuration takes precedence). Without reboot, just do `nmcli device set ens1f0 managed no` instead.

You can check that this works if the device state is "unmanaged" in `nmcli device` output.


2.) while just marking the device as unmanaged in NetworkManager is the easiest one, you can also just go ahead and configure the device without telling NetworkManager. But then preferably make sure that you don't currently have a profile active on that interface (so that `nmcli device` tells you that the device is currently in "disconnected" state). Again, if you don't configure a connection profile for a device, then the device won't be activated by NetworkManager. In the simplest case, just don't have profiles for it.

Note that depending on your configuration, NetworkManager may generate a profile automatically. Those are usually called "Wired connection 1", and you see them in your logfile (and in `nmcli connection`). If you don't want that NetworkManager generates such profiles then:

  - simply delete the profile with `nmcli connection delete "Wired connection 1"`. NetworkManager will remember to not create the profile again in the internal file /var/lib/NetworkManager/no-auto-default.state.

  - configure no-auto-default in NetworkManager.conf. See `man NetworkManager.conf` and drop a configuration snippet like in the example above.

  - install package NetworkManager-config-service, which installs a file /usr/lib/NetworkManager/conf.d/00-server.conf, which sets no-auto-default configuration option.

Again, if you edit configuration on disk, reload with `systemctl reload NetworkManager`.

Also, you may have profiles configured for a device, but you may disable autoconnect. In that case, they also won't automatically connect and not interfere either. Configure autoconnect of your profiles accordingly.

Of course, if you currently have a profile activated on a device that you don't want, you don't need to delete the profile. Just deactivate the device first (`nmcli disconnect "$IFNAME"` or `nmcli connection down "$PROFILE"`)... check the current state in `nmcli device` before starting your own thing on the device.


2b) Sidenote: if the device is not marked as unmanaged (1.)) and currently disconnect (2.)), then you are good to start to run whatever you want on the device. Hoever, note that NetworkManager will see when you configure the device, in that case it will generate an in-memory connection profile (named like "ens1f0") and it will appear active. That's OK. This generated connection profile merely means that somebody does something with the device, NetworkManager will not interfer with it. That is confusing, unfortunately.



3.) even if NetworkManager is currently actively managed a device (meaning, in `nmcli device` you see a connection profile active (except case (2b)), then you may still configure it outside of NM. NM will try not to interfere with your doing. But of course, NM will still manage the device. That means for example, if the IP configuration fails (like in your logfile), NetworkManager will pull the plug and tear down the device with everything you configured there. There are many ways to affect when a device is considered failed. For example the profile settings `ipv4.may-fail` and `ipv6.may-fail` affect this. Also, properties like ipv4.dhcp-timeout, etc. Quite possibly your profile should not configure ipv4.method=auto in the first place, if DHCP is not available on the device. Point being: configure the profile accordingly so that it doesn't fail and doesn't get teared down unexpectedly.

For example, currently NetworkManager may not support all TC or ethtool options (it supports some). In that case, it's very much intended to place a script to /etc/NetworkManager/dispatcher.d (`man NetworkManager`) and configure the device that is also managed by NetworkManager.



4) Finally, of course you are welcome to disable NetworkManager altogether and run whatever script or tool you wish.



TL;DR: just mark the device as unmanaged if you don't want NeworkManager to manage it.



Yes, you are right, this is pretty much the same thing as bug 1633959. It's not clear what we could improve here.


Anything unclear? Any concerns? Thank you.

Making the bug public. Be aware.

Thank you so much for the feedback, Thomas.

Yes, the suggested solutions resolved this issue.
Will it be possible to document this somewhere (Release Notes doc?) ?
More than one customer already faced this issue, and I think more will do as well.


Also, please note that on RHEL-8, the ingress qdisc was still deleted even after installing NetworkManager-config-server; Only marking the interfaces as unmanaged (did that via config file under /etc/NetworkManager/conf.d/) resolved the issue on RHEL-8.

> Also, please note that on RHEL-8, the ingress qdisc was still deleted even after installing NetworkManager-config-server; Only marking the interfaces as unmanaged (did that via config file under /etc/NetworkManager/conf.d/) resolved the issue on RHEL-8.

NetworkManager-config-server only prevents the automatic creation of the "Wired connection 1" profiles. From what you say here, it's not entirely clear how the issue would still happen. But of course, even without the automatically generated profiles you can have the same issue. A logfile would be useful to determine what exactly happened.

> Will it be possible to document this somewhere (Release Notes doc?) ?
> More than one customer already faced this issue, and I think more will do as well.

Indeed, documentation should be improved, as there seems to be some struggle involved.

Release Notes don't seem the right place, because this is just documenting how things work in general.

Could you elaborate why you are en trying to do this? That could be helpful to determine in which part it should be documented.

Did you consult any documentation? If yes, can you point to some documentation that you looked at where you would have expected to find this documented?

Other than that, this seems like there should be a "user story" about this. But for that it would be good to understand what you were trying to do ultimately.

If we are saying this is just a configuration issue, then we need another BZ for OSP installer to handle this configuration. Right now neither OSP 13(RHEL7 based)  or OSP 16 (RHEL8 based) apply this configuration which causes breaks connectivity on openstack compute nodes.

> If we are saying this is just a configuration issue, then we need another BZ for OSP installer to handle this configuration. Right now neither OSP 13(RHEL7 based)  or OSP 16 (RHEL8 based) apply this configuration which causes breaks connectivity on openstack compute nodes.

Doesn't the report in comment 0 shows the output of a reproducer script? (which isn't attached here)

What exactly is OSP doing? How does that relate to the reproducer script?

Yes, if OSP (or any tool for that matter) configures TC on an interface in a way that interefers with NetworkManager, then that tools must prevent that by telling NetworkManager not do to that. That is of course especially the case, if that tool is shipped by Red Hat. 

But then it also doesn't really directly concern the end user, but another application. Lacking documentation is then not the issue here.

Please provide a full level=TRACE log of NetworkManager that shows the actual problem related to OSP and give details about the circumstances and the environment where this is happening.

(In reply to Thomas Haller from comment #7)
> > Also, please note that on RHEL-8, the ingress qdisc was still deleted even after installing NetworkManager-config-server; Only marking the interfaces as unmanaged (did that via config file under /etc/NetworkManager/conf.d/) resolved the issue on RHEL-8.
> 
> NetworkManager-config-server only prevents the automatic creation of the
> "Wired connection 1" profiles. From what you say here, it's not entirely
> clear how the issue would still happen. But of course, even without the
> automatically generated profiles you can have the same issue. A logfile
> would be useful to determine what exactly happened.

Sure, I will attach the log file for RHEL-8 and the scripts that I've used.

> 
> > Will it be possible to document this somewhere (Release Notes doc?) ?
> > More than one customer already faced this issue, and I think more will do as well.
> 
> Indeed, documentation should be improved, as there seems to be some struggle
> involved.
> 
> Release Notes don't seem the right place, because this is just documenting
> how things work in general.
> 
> Could you elaborate why you are en trying to do this? That could be helpful
> to determine in which part it should be documented.
> 

As Harsh mentioned, the original issue was seen with OSP. The script that I'm using is a slightly modified version
of the reproducer from BZ #1633959. The purpose of this script is to demonstrate the qdisc deletion issue using
the simplest setup possible.

Created attachment 1672299 [details]
logs over RHEL-8 + NetworkManager-config-server installed

from the attached log:

We see that the qdisc was deleted at here (from tc monitor):
[2020-03-22T10:27:02.305692] deleted qdisc ingress ffff: dev ens1f0 parent ffff:fff1 ----------------

And from NM log at that time:
$ grep 10:27:02.305 RHEL-8-logs/NM.log
Mar 22 10:27:02.305003 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3049] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent e info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305011 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3050] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent d info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305019 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3050] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent c info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305027 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3050] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent b info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305035 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3050] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent a info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305043 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3050] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent 9 info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305051 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3050] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent 8 info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305059 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3050] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent 7 info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305067 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3050] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent 6 info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305075 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3050] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent 5 info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305083 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3050] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent 4 info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305097 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3050] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent 3 info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305105 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3051] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent 2 info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305113 dev-h-vrt-013 NetworkManager[11102]: <trace> [1584865622.3051] platform-linux: event-notification: RTM_NEWQDISC, flags multi, seq 604746, in-dump: fq_codel dev 872 family 0
handle 0 parent 1 info 1 limit 10240 flows 1024 target 4999 interval 99999 quantum 1514 memory_limit 33554432 ecn
Mar 22 10:27:02.305133 dev-h-vrt-013 NetworkManager[11102]: <debug> [1584865622.3051] platform: (ens1f0) qdisc: delete ingress dev 865 family 0 handle ffff0000 parent fffffff1 info 1
Mar 22 10:27:02.305721 dev-h-vrt-013 NetworkManager[11102]: <debug> [1584865622.3057] platform-linux: do-delete-qdisc[865: -15]: success
[alaa@dev-h-vrt-013:pts/1 +2] /tmp
$

Created attachment 1672300 [details]
scripts used to demonstrate the issue over mlx5 device

(In reply to Alaa Hleihel (Mellanox) from comment #12)
> Created attachment 1672299 [details]
> logs over RHEL-8 + NetworkManager-config-server installed

this isn't the full log, so it cannot be seen what the configuration is, nor why the configuration is present.

Anyway, you see:

> Mar 22 10:26:17.302522 dev-h-vrt-013 NetworkManager[11102]: <info>  [1584865577.3025] device (ens1f0): Activation: starting connection 'Wired connection 1' (f592c12f-af16-31f2-a96f-8b5b247d
d8cd)

which then later fails:

> Mar 22 10:27:02.288519 dev-h-vrt-013 NetworkManager[11102]: <info>  [1584865622.2885] device (ens1f0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')

and deconfigures the device.

It seems NM is doing what it is being told.


Note that "no-auto-default" setting (as provided by NetworkManager-config-server package), only prevents the creation of the "Wired connection 1" in-memory profile. And note, that if you have this in-memory profile, and you modify it (e.g. `nmcli connection modify "Wired connection 1" ...`), then it gets persisted to disk, and becomes a regular profile that will be around until you delete it. 

Anyway, from the partial logs it's not clear hwere the "Wired connection 1" profile comes from... do you have the first part too?

also, what does the "reproducer" script try to proof? As discussed, if you have NetworkManager managing a device, and the activation fails, that NM will tear down the device and clear certain settings.

If you are in a situation where you run your own scripts, then you (as user, admin, customer) are responsible for avoiding this situation (via one of several possibilities). You are even welcome to do `systemctl mask --now NetworkManager.service` if that is what you wish. If you wonder how to avoid this problem (as a user, when writing your own scripts), then I hope comment 4 helps. We should also improve documentation here.

It seems most interesting whether there is a problem for OSP itself (or any tools provided by Red Hat). I am not at all familiar with OSP. But clearly also tools provided by Red Hat need to avoid such a problem as well. But that requires understanding what tool we are even talking about here. What it does and why. That is not clear to me from comment 11.

Sidenote: from the log in comment 12 we see an unrelated issue that I reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1815875

(In reply to Thomas Haller from comment #14)
> (In reply to Alaa Hleihel (Mellanox) from comment #12)
> > Created attachment 1672299 [details]
> > logs over RHEL-8 + NetworkManager-config-server installed
> 
> this isn't the full log, so it cannot be seen what the configuration is, nor
> why the configuration is present.
> 
> Anyway, you see:
> 
> > Mar 22 10:26:17.302522 dev-h-vrt-013 NetworkManager[11102]: <info>  [1584865577.3025] device (ens1f0): Activation: starting connection 'Wired connection 1' (f592c12f-af16-31f2-a96f-8b5b247d
> d8cd)
> 
> which then later fails:
> 
> > Mar 22 10:27:02.288519 dev-h-vrt-013 NetworkManager[11102]: <info>  [1584865622.2885] device (ens1f0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
> 
> and deconfigures the device.
> 
> It seems NM is doing what it is being told.
> 
> 
> Note that "no-auto-default" setting (as provided by
> NetworkManager-config-server package), only prevents the creation of the
> "Wired connection 1" in-memory profile. And note, that if you have this
> in-memory profile, and you modify it (e.g. `nmcli connection modify "Wired
> connection 1" ...`), then it gets persisted to disk, and becomes a regular
> profile that will be around until you delete it. 
> 
> Anyway, from the partial logs it's not clear hwere the "Wired connection 1"
> profile comes from... do you have the first part too?

You are right, the "Wired connection 1" was a left-over from my previous test on the same setup when the package NetworkManager-config-server was not installed yet.
Cleaning up the files from "/run/NetworkManager/system-connections/" directory, resolved the issue.
Wired connection X were not created anymore, and the test passed.

(In reply to Alaa Hleihel (Mellanox) from comment #17)

> You are right, the "Wired connection 1" was a left-over from my previous
> test on the same setup when the package NetworkManager-config-server was not
> installed yet.
> Cleaning up the files from "/run/NetworkManager/system-connections/"
> directory, resolved the issue.
> Wired connection X were not created anymore, and the test passed.

Thank you Alaa, for your feedback. What is missing from your point of view to close this bug?

(In reply to Till Maas from comment #18)
> (In reply to Alaa Hleihel (Mellanox) from comment #17)
> 
> > You are right, the "Wired connection 1" was a left-over from my previous
> > test on the same setup when the package NetworkManager-config-server was not
> > installed yet.
> > Cleaning up the files from "/run/NetworkManager/system-connections/"
> > directory, resolved the issue.
> > Wired connection X were not created anymore, and the test passed.
> 
> Thank you Alaa, for your feedback. What is missing from your point of view
> to close this bug?

Hi Till,

As requested before, we're asking for documenting this issue in RHEL Release Note (Networking section) or Errata or KB article.

I understand that this is basically a configuration issue, but it's not trivial, and customers can waste their time and customer support time debugging it over and over...

(In reply to Alaa Hleihel (Mellanox) from comment #19)

> As requested before, we're asking for documenting this issue in RHEL Release
> Note (Networking section) or Errata or KB article.

Thank you Alaa for clarifying this. The need to improve the documentation was my takeaway, too.

To identify the best place for this documentation, it would be great if you could answer the following questions to help us make the best decision:

(In reply to Thomas Haller from comment #7)

> Could you elaborate why you are en trying to do this? That could be helpful
> to determine in which part it should be documented.
> 
> Did you consult any documentation? If yes, can you point to some
> documentation that you looked at where you would have expected to find this
> documented?
> 
> Other than that, this seems like there should be a "user story" about this.
> But for that it would be good to understand what you were trying to do
> ultimately.


(In reply to Alaa Hleihel (Mellanox) from comment #19)

> I understand that this is basically a configuration issue, but it's not
> trivial, and customers can waste their time and customer support time
> debugging it over and over...

Agreed.

(In reply to Till Maas from comment #20)
> (In reply to Alaa Hleihel (Mellanox) from comment #19)
> 
> > As requested before, we're asking for documenting this issue in RHEL Release
> > Note (Networking section) or Errata or KB article.
> 
> Thank you Alaa for clarifying this. The need to improve the documentation
> was my takeaway, too.
> 
> To identify the best place for this documentation, it would be great if you
> could answer the following questions to help us make the best decision:
> 
> (In reply to Thomas Haller from comment #7)
> 
> > Could you elaborate why you are en trying to do this? That could be helpful
> > to determine in which part it should be documented.
> > 
> > Did you consult any documentation? If yes, can you point to some
> > documentation that you looked at where you would have expected to find this
> > documented?
> > 
> > Other than that, this seems like there should be a "user story" about this.
> > But for that it would be good to understand what you were trying to do
> > ultimately.
> 

My goal was to demonstrate the issue with the simplest setup and steps possible.

The motivation was a customer complaint where we saw that qdiscs are getting deleted
and we suspected NM since we already had similar issues in the past that were fixed by disabling NM.
However, recent debug showed that they were able to reproduce the issue even after disabling
NM, so there is something else to blame :)

They were using OSP, and unfortunately, I don't have links to relevant documentation...

I suggest to simply document this in the RHEL Release Notes 8.6. Networking section: 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.7_release_notes/known_issues#known-issue_networking


> 
> (In reply to Alaa Hleihel (Mellanox) from comment #19)
> 
> > I understand that this is basically a configuration issue, but it's not
> > trivial, and customers can waste their time and customer support time
> > debugging it over and over...
> 
> Agreed.

> My goal was to demonstrate the issue with the simplest setup and steps possible.

Thanks!!


Release-notes highlight changes of a new release (such as prominent new features). Also, they are specific to the new release. This doesn't seem a new known-issue nor specific to any release. This issue is how NetworkManager works: NetworkManager manages the network, according to configuration. Don't configure NetworkManager in a way that conflicts with what you want to do.

This possibly should be better added to the RHEL documentation or as a user story.

But documentation team surely knows better what are the best places. Reassigning to Marc.

Hi Marc,

can you please update on this BZ?

"Configuring devices as unmanaged in NetworkManager" is a high-priority user story on the RHEL 8.3 doc plan. I will backport the section once it is done.

(In reply to Marc Muehlfeld from comment #25)
> "Configuring devices as unmanaged in NetworkManager" is a high-priority user
> story on the RHEL 8.3 doc plan. I will backport the section once it is done.

Hi Marc,

Just to clarify things; this is going to be published as a user story, therefore we don't need to open another BZ for RHEL-8 (this one is open for RHEL-7), right?

Thanks,
Alaa

(In reply to Alaa Hleihel (Mellanox) from comment #26)
> Just to clarify things; this is going to be published as a user story,
> therefore we don't need to open another BZ for RHEL-8 (this one is open for
> RHEL-7), right?

Right. I will document this for RHEL 8 (Configuring and managing networking) and then backport the docs to RHEL 7 (Networking Guide).
No extra ticket is needed.

(In reply to Marc Muehlfeld from comment #27)
> (In reply to Alaa Hleihel (Mellanox) from comment #26)
> > Just to clarify things; this is going to be published as a user story,
> > therefore we don't need to open another BZ for RHEL-8 (this one is open for
> > RHEL-7), right?
> 
> Right. I will document this for RHEL 8 (Configuring and managing networking)
> and then backport the docs to RHEL 7 (Networking Guide).
> No extra ticket is needed.

Great, thanks a lot

The new content about configuring devices as "unmanaged" in NetworkManager is now available on the Customer Portal:

* RHEL 8:
  https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/configuring-networkmanager-to-ignore-certain-devices_configuring-and-managing-networking

* RHEL 7:
  https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-configuring_ip_networking_with_nmcli#configuring-networkmanager-to-ignore-certain-devices