On Tue, Jun 25, 2019 at 01:59:27PM -0000, Dan Purgert wrote:
Michael Stone wrote:
weren't constant, but people didn't seem to care as much about the
nuances because "that's the way it's always been". (Sometimes it was an
eth, sometimes it was a wlan, etc.) Why were those differences ok but
these differences aren't? Familiarity.
The old names were constant across systems with the same interface(s) --
i.e. an ethernet or a wifi (or both).
Unless you were born with that knowledge (unlikely) someone needed to
explain why some interfaces had different names than others. Now there's
just more to explain. (Actually, it's about the same, because other
things we used to have to know have faded away entirely.) Or, in the
common case, you just don't worry about it. Only if you're in the
awkward spot of really wanting to do something with a named interface
based on old knowledge, and aren't willing to learn the new rules, is
this an issue.
The "problem" with them was that they apparently weren't consistent
across boots if you had multiples of the same "type" -- although I can't
remember that ever happenening, even on crazy frankenboxes that had 3
and 4 PCI NICs in them (barring moving things around, but these
"predictable names" change too).
The problem got increasingly bad as intialization was parallellized, to
the point that it was *quite noticible* given a large sample set of
servers. The "solution" was to lock a name to a mac via udev, but that
just made the system stable as far as which random name was assigned at
install time. So, for example, on a large set of servers with both
internal NICs and external NICs, sometimes eth0 would be an internal 1G
copper interface, and sometimes eth0 would be an external 10G fiber
interface. This sucked. The "solution" of locking the name to a MAC made
things even worse, because if you replaced a failed NIC it was
guaranteed to *not* have the same name on boot unless you went in and
manually changed the udev config. (And--DANGER WILL ROBINSON--if you
simply nuked the udev config entirely you were back to a coin flip as to
which interfaces would have which names and the machine might or might
not have a working network configuration on startup. This sucked.) Now
with a large population of servers your built-in NIC will come up as
something like eno1 and your add-in NIC will be something like ens1f0
and its second interface will be ens1f1 and even if that looks "weird"
to some, it's one hell of a lot better than flipping a coin at boot. If
hardware is replaced (literally swapped) it will come back the same way.
That's very, very good. And, again, if you're not in a position where
you want to learn what names will be used in a given situation because
you're not managing a bunch of servers, then just ignore the interface
names because they don't matter for simpler systems.
While the new naming has forced "predictability" of some regard, it
comes at the cost of having removed the "predictability" of naming when
communicating about disparate systems. That is, before these names a
"network problem" could be resolved with an interaction along the lines
of:
(0) (problem description)
(1) OK, run 'ip a list eth0 | nc termbin.com 9999' and share the link
(2) (get the output)
(3) Ah, there you go - it's only getting an APIPA address, check on
your DHCP server...
Nowadays, with these "predictable" names, if we tell the other party the
"wrong" name, all we get is an error message that "Device 'en###'
doesn't exist".
That's a good example of "the interface doesn't matter". Just run "ip a"
instead. If there's only one interface it's simple enough to ignore the
lo entry and if there's more than one interface *you needed to know that
anyway* because that could be the source of the problem.
