F18: unpredictable 'Predictable Network Interface Names'?

Frantisek Hanzlik franta at hanzlici.cz
Tue Feb 26 03:54:15 UTC 2013


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.

"race conditions" on few static NICs?
"race conditions" which udev could serve well?
It sounds weird...

> 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.

During approx. last ten years I had only two bad network adapters
(as their single fault, I not consider situations when blow out whole
box). Then I have no problem with this.

> Maybe the OP can enlighten me *why* does he need MAC-oriented naming
> scheme so badly? Just curious... :-)

Why badly?
ethX are native kernel device, all Linux users ever know them, until
now was not problem with using them. Why should be it problem now?

And regards MAC-based naming: as before, until now has never been
problem with, why now?

And why is MAC based naming important for me? E.g:
- I often rebuild our Linux boxes and want right working with NICs in
other bus positions or even other mainboards.

- my boxes works not in vacuum but in normal or dusty environment
and must be periodically cleaned. And I want right function even
when I pull up NICs and then insert them in other order. I had
simply ethernet cable and relevant NIC marked (WAN2, DMZ, LAN3,..)
and want when I put cable to equally marked NIC right work.

> Best, :-)
> Marko



More information about the users mailing list