Unable To Get Dummy Interfaces To Persist Across Reboots In CentOS 8

Home » CentOS » Unable To Get Dummy Interfaces To Persist Across Reboots In CentOS 8
CentOS 8 Comments

Hello all, hoping someone can help me out here.

I cannot get dummy interfaces on a new Cent8 build to persist across reboots.

On Cent7 – this is the process I use:

Create Dummies:
# cat /etc/modules-load.d/dummy.conf dummy
# cat /etc/modprobe.d/dummyopts.conf options dummy numdummies=4
# ip link add dummy0 type dummy
## – repeating a/ ascending dummyN adapters for as many needed
# service network start
# dracut -f

Now this was different than even how 6 handled it, forget how I
finally dug that up (possible I even asked here). I’ve applied this same configuration to a Cent8 box I’m trying to stand up and it all appears to work fine, but unlike the Cent7 boxes, when the Cent8 box comes back up, all the dummy adapters are missing. I’ve been searching all over trying to find some documentation on this to no avail. I’m hoping someone has some suggestions here to help out.

Thanks, Frank

8 thoughts on - Unable To Get Dummy Interfaces To Persist Across Reboots In CentOS 8

  • Anyone have any ideas? It’s rather annoying that I can’t get these to persist across reboots without using some kind of helper script.

  • Have you tried to use NetworkManager ?
    After all ,anything network related should be done by it.

    [root@system ~]# nmcli connection add con-name dummy0 ifname dummy0 type dummy  
    Connection ‘dummy0’ (9fdd74fa-c143-4991-9bac-0e542704ac89) successfully added.

    [root@system ~]# reboot Shared connection to glustera closed.

    [root@system ~]# uptime
    03:23:44 up 0 min,  1 user,  load average: 1,57, 0,48, 0,17
    [root@glustera ~]# nmcli connection show  
    NAME    UUID                                  TYPE      DEVICE  
    dummy0  9fdd74fa-c143-4991-9bac-0e542704ac89  dummy     dummy0

    [root@system ~]# ip a s dummy0
    3: dummy0: mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
       link/ether ce:c9:83:97:10:ee brd ff:ff:ff:ff:ff:ff
       inet6 fe80::599:a978:9457:df10/64 scope link noprefixroute  
          valid_lft forever preferred_lft forever

    P.S.: This is the first time I hear about dummy interfaces. What are those used for ?

    Best Regards, Strahil Nikolov

    В вторник, 27 октомври 2020 г., 02:42:06 Гринуич+2, Frank Even написа:

    Anyone have any ideas?  It’s rather annoying that I can’t get these to persist across reboots without using some kind of helper script.

  • Have you tried with Network Manager , after all this is the thing that manages all networks:

    [root@system ~]# nmcli connection add con-name dummy0 ifname dummy0 type dummy  
    Connection ‘dummy0’ (9fdd74fa-c143-4991-9bac-0e542704ac89) successfully added.

    [root@system ~]# reboot Shared connection to glustera closed.

    [root@system ~]# nmcli connection show  
    NAME    UUID                                  TYPE      DEVICE  
    dummy0  9fdd74fa-c143-4991-9bac-0e542704ac89  dummy     dummy0

    [root@system ~]# ip a s dummy0
    3: dummy0: mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
       link/ether ce:c9:83:97:10:ee brd ff:ff:ff:ff:ff:ff
       inet6 fe80::599:a978:9457:df10/64 scope link noprefixroute  
          valid_lft forever preferred_lft forever

    Best Regards, Strahil Nikolov

    В вторник, 27 октомври 2020 г., 02:42:06 Гринуич+2, Frank Even написа:

    Anyone have any ideas?  It’s rather annoying that I can’t get these to persist across reboots without using some kind of helper script.

  • No. Network Manager is always disabled on our builds since at least Cent5 days. The network stack has always been able to be managed properly without relying on Network Manager. Is that now an absolute requirement? It never has been prior.

  • As far as what dummy interfaces are used for, they’re basically loopbacks that allow for some better network management/flexibility
    (by separating it from the actual system loopback).

  • IIRC the old style network scripts will go away with the next RHEL
    release. I’m afraid NetworkManager will be the way to go in future.

    Regards, Simon

  • Requirement is a very strong word , but you should consider using it and here is a short demo why:

    – By default, RHEL uses NetworkManager to configure and manage network connections, and the /usr/sbin/ifup and /usr/sbin/ifdown scripts use NetworkManager to process ifcfg files in the /etc/sysconfig/network-scripts/ directory.

    [root@system ~]# ls -l /usr/sbin/ifup lrwxrwxrwx. 1 root root 22 21 окт 21,29 /usr/sbin/ifup -> /etc/alternatives/ifup

    [root@system ~]# alternatives –list  | grep ifup ifup                    auto    /usr/libexec/nm-ifup

    [root@system ~]# rpm -qf /usr/libexec/nm-ifup NetworkManager-1.22.8-5.el8_2.x86_64

    – the old networks-scripts have been deprecated and are not the defaults anymore

    It’s about time to switch to NM, but you got some 5-8 years till next EL release.

    Best Regards, Strahil Nikolov

    В сряда, 28 октомври 2020 г., 12:47:12 Гринуич+2, Frank Even написа:

    No.  Network Manager is always disabled on our builds since at least Cent5 days.  The network stack has always been able to be managed properly without relying on Network Manager.  Is that now an absolute requirement?  It never has been prior.

  • A colleague actually figured this out.

    There is an entry in /lib/modprobe.d/systemd.conf that seems to override any other user configurations applied.

    options dummy numdummies=0

    …needs to be removed from this file (or at least modified, but since my configuration already lays that down in /etc/modprobe.d this just needs to be removed for my purposes).