F18: unpredictable 'Predictable Network Interface Names'?

[Bill Davidsen]

Marko Vojinovic wrote:
> On Mon, 25 Feb 2013 22:51:15 +0100
> poma <pomidorabelisima at gmail.com> wrote:
>> On 02/25/13 21:01, Reindl Harald wrote:
>> […]
>>> so switch to anything else as ethX in your naming in
>>> /etc/udev/rules.d/70-persistent-net.rules
>>> like "lan0", "lan1", "wan0", "wan1" in ifcfg-lan1....
>>>
>>> so you would not have race-conditions in kernel/udev naming the
>>> interfaces
>
> Just a small comment --- I believe everyone following this thread is
> aware that these race conditions are the very reason for the
> introduction of biosdevname in the first place.
>
So we could have one more source of confusion? Was that needed?

> In order to avoid race conditions, one can either use biosdevname and
> have eth* be replaced by different names like em* and p*p*, or one can
> disable biosdevname, configure udev manually, and have have eth* be
> replaced by names like lan* and wan*.
>
> The actual difference between the two methods is about system
> maintenance --- when your network card burns out (these things happen,
> unfortunately), biosdevname allows you to plug a new card into the same
> pci slot and just turn the machine back on, with no extra
> configuration. If you are configuring udev manually, and tie nic names
> to MAC addresses, you are required to reconfigure udev for
> the new MAC address of the new card.
>
> The pain is greater in the latter case, while I see no gain at all,
> compared to the way of biosdevname.
>
> Maybe the OP can enlighten me *why* does he need MAC-oriented naming
> scheme so badly? Just curious... :-)
>
So that when you have to open the server and do work the NIC cards can be 
plugged in any slot and the name on the NIC socket and the label on the cable 
will still work. A system board dies and I pull the cards out of the case, slide 
a new server case into the rack, drop in the boards, plug the disk cables in the 
back, and I'm up and going again even if the new case is not identical to the 
old. As you said, it's about system maintenance.

I believe that at least 75% of the users of Fedora have a total of one NIC and 
want it called eth0 as it has been. Just my read on that.

It would be desirable for everyone if there were one and only one place where 
naming was done, and it was controlled by a set of rules, used in order, applied 
to each NIC and using "first match" logic. See example.

   # NOC control NIC - any card in the control slot
   NAME="noc0" SLOT="b5p7q91s4"
   # WAN ports
   #   current NIC
   NAME="wan0" MAC="52:54:00:12:00:02"
   #   dual port card - replace next down time
   NAME="wan0" MAC="52:54:00:12:01:40"
   NAME="wan1" MAC="52:54:00:12:01:41"
   # LAN port
   NAME="lan0" MAC="52:54:00:12:00:51"
   # the unreliable 10/100 service port on the mobo
   NAME="bad" MAC="52:54:00:12:00:66"
   # any unknown cards in the order found
   NAME="eth+" NOMATCH

Note that with only the last rule default would be eth0.

Just my take on the issue, since I have no influence on Fedora or any other 
distro, I don't expect anyone to pick up on this and allow users to use whatever 
they find fits their needs, but the current naming scheme is inflexible, and was 
probably implemented by someone used to labeling slots on servers. When I was a 
project leader for a server group at at&t we labeled the NIC, and as noted, I 
think most desktop users would be happy with eth0 rather than some random number 
based on the slot, bridge, and some unreliable guess if the NIC is built-in or 
on a card.

-- 
Bill Davidsen <davidsen at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot