On Tue, Mar 17, 2020 at 6:58 PM David Sommerseth <sl+us...@lists.topphemmelig.net> wrote: > > On 17/03/2020 19:51, James M. Pulver wrote: > > I mostly hate the new network names, and I generally find that they're > > fixing something that was never broken for us, but I imagine there was some > > way you could get your eth* interfaces confused on reboot I guess. Strange > > that the latest vyos which is a router distro designed for lots of > > different interfaces that need to stay consistent through reboots still > > uses eth*. > The need for this might not be clear. But the old eth* scheme was tied to the > MAC address of the interface. This new scheme allows hardware to more clearly > define the interface name based on the hardware location and not the interface > itself.
Except when it wasn't. It was a fascinating, stateful ording of checking the /etc/udev/rules.d/ for entries that would associate a specific MAC address with a specific device, then /etc/sysconfig/networ-scripts/ifcfg-[whatever] for HWADDR, Then all that arcane scripting got fed to the "ifconfig" command and the "route" command. Fascinating stuff if you want to trace the history of scripting configurations. > The use case is: A server needs to replace a NIC for some reason. The process > is to shutdown the server, remove the old interface and insert the new one and > boot it up again. And everything should work as before. > > Using the old eth* schema would require modifying configuration files to > configure the replaced interface to use the old configuration. While the new > approach fixes this, as the configuration is tied to the mainboard slot the > interface is inserted into, not the interface MAC address. Except..... if you had two NIC's, one for the front end and one for the back end. Then you really needed to lock them in to specific devices, because device ordering was dependentn on kernel, power up behavior, and sometimes even MAC addresses on the same network card. That.... wa whay an employer from way back used to insist on one model of NIC on the motherboard, and different model on an add-on network card, didn't tell me they'd installed the motherboard NIC as a static kernel module to force ordering, and hilarity ensued when we upgraded to hardware that had two NIC's on the motherboard. Went *nuts* making that consistent and preserving the ordering for network based operating system installations. > This might or might not be useful, depending on your needs. The old eth* > approach was easy, because it was short and swift and used since the early > days. But I do see the old approach could be a burden to larger data centers. The older approach is why they use DHCP with static reservations to configure IP's to specific devices. (Did that for *years* for cluster deployments. which also helped me audit the hardware in case someone replaced an operating system or installed devices and didn't tell anyone.) These days.... those are options. Many peopole also now allow dynamic DNS, which brings its own hazards for just such situations, and switches that are smart enough to disable any NIC that hasn't been specifically authorized. Fascinating stuff for semi-secure environments. It's not perfect, but it's a *start*. > kind regards, > > David Sommerseth