On Tue, Mar 17, 2020 at 6:58 PM David Sommerseth
<[log in to unmask]> 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