Quoting Steve Litt (slitt@???):

> As a wee lad, my mentors told me never to put two of the same model
> NICs in a computer, because which one became eth0 and which became eth1
> would be indeterminate from boot to boot.

It's funny you'll say that, and not just because we're both old enough
that advice we got as 'wee lads' would probably have to involve
sliderules. I'll get back to that, later.

> That's horrible, and that *is* solved by the systemd naming scheme.

I find myself in the position of being a little unconvinced about the
extent and seriousness of the problem, even though I don't have
exhaustive data, only a few decades of *ix experience to draw on.
Let me try to draw a distinction with some nuance, here: To the best of
my knowledge -- and my knowledge might be incomplete or unaware of some
new developments -- 'spontaneous' network device renaming, just like
spontaneous mass storage device renaming, happens _only_ following
admin-initiated hardware reshuffles.

If you read the Freedesktop.org/systemd article on 'Predictable Network
Interface Names'
(https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/),
you will get the impression that, without systemd's scheme, Linux
systems are threatened by network interfaces suddenly coming up with
new device node assignments in a totally unpredictable fashion,
necessitating systemd/udev's baroque workaround to save us from chaos.
And this brings to mind two immediate reservations I have: (1)
If this were common, I'd expect to have encountered it fairly
frequently, and I've not encountered it at all (except for reshuffles
upon adding or removing relevant hardware). (2) The
Freedesktop.org/systemd kiddies have a long track record of overselling
the alleged problems their baroquely overengineered software supposedly
fixes.

I've worked with very large numbers of Linux servers over three decades.
Most of those have each sported multiple ethernet NICs of the same
manufacturer, model, and driver. e1000, tg3, e100, 3c905, 3c509, ne2000
{shudder}, etc. In all of those many hundreds of machines each with
multiples of the same NIC/driver, over a long time, I cannot recall even
a single case when, upon reboot, eth0 and eth1 suddenly swapped.

Which is why I find your mentors' advice odd.

I understood that, if you had a motherboard with dual e1000 NICs and
suddenly added (or removed) a third ethernet port on a PCI-E card,
whether it was also an e1000 NIC or not, you might expect to get a
device assignment reshuffle. Therefore, if you were changing such
hardware, you simply accepted that a one-time need to re-edit
/etc/network/interfaces before redeployment was an implied part of the
task. In exactly the same way, if you decided to throw in (or remove) a
PCI-E (PCI-X, PCI, ISA, whatever) SATA/PATA/SCSI card into a system, or
remove one, you would simply accept that a one-time need to re-edit
/etc/fstab before redeployment was an implied part of the task.

It's always been at least _possible_ that major kernel version jumps,
such as 2.4.x to 2.6.x, might cause a one-time device reshuffle, and
I've always been on-guard for it if conducting such an upgrade. I've
not yet seen that happen (though it might). But, again, this is just a
predictable part of the major-disro-upgrade task, and not an
unpredictable catastrophe requiring layers of protective software to
avert.

When USB came along and people started using it (overusing it) as if it
were reliable infrastructure, those of us who were paying attention saw
immediately that it would add more of that kind of chaos, and indeed
worsten it. _However_, even given that, in my experience any reshuffle
USB would add to the _existing_ devices' node assignments would occur
only at reboot time _if_ you left the USB device plugged in. The
obvious takeaway lesson was Don't Do That, Then (to quote the old tech.
support joke's punchline). Unplug the friggin' USB external hard or
SSE or the USB network device before reboot, and the preexisting devices
would come up exactly as planned and not render your
/etc/network/interfaces and /etc/fstab contents inaccurate.

I find it very telling that, when horror stories pop up about allegedly
spontaneous Linux device node reshuffles, USB seems to be a recurring
element: It suggests to me that the main problem isn't Linux device
assignment instability at all; it's inattentive reliance on a
known-problematic technology (USB) to do what it's not good for
(long-term main infrastructure) instead of what it is good for
(causal and light-duty device use).

When I was designing my next-generation server to use a tiny, fanless
Celeron box (CompuLab IntensePC) with only external RAID1-mirror
storage, I went out of my way to ensure that the pair of external SSDs
would be connected via eSATA rather than following the path of least
resistance and using USB. Why? Because I don't trust USB for
persistent infrastructure. Nor, IMO, should anyone.

However, with all of the above having been said, I will be the first to
admit that I might be missing something, and/or my information might be
out of date. Since I'm disinclined to trust the Freedesktop.org/systemd
kiddies' alleged documentation about network device naming, I looked
around for something credible and relatively recent. What I found was
this 2009 Dell Computer whitepaper:
https://linux.dell.com/files/whitepapers/nic-enum-whitepaper.pdf

Please do have a look. I'm not 100% confident of my reading of that
whitepaper, but it _seems_ to support my recollection -- mostly. The
bit near the end about where it says SLES 10/11 require udev rules to
associate MAC addresses persistently with device node names is a bit
troubling. Notice, however that the whitepaper says that RHEL even
through RHEL5's accomplishment of that association via citation of MAC
addresses ('HWADDR') within /etc/sysconfig/network-
scripts/ifcfg-<network interface name> files suffices without udev
tricks. (The whitepaper doesn't address RHEL revisions after RHEL5.)

So, rather than arrogantly assert that my old-school rules of thumb
still suffice in 2017, I'll ask: What new thing am I missing, that is
not just a matter of expected reshuffles immediately following hardware
addition/removal or (in theory) major kernel revision jumps?