[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Ethernet interface numbering in etch

After writing a very long message, I realize that there was a much simpler 
solution, so if you want to cut to the chase, skip to the end!

Steve Langasek wrote:
>Which do you think is the common case -- a system with more than one network
>interface where it's necessary to preserve interface ordering across
>reboots, or a system where the admin will frequently change out the network
>hardware and need to reuse the same interface names?

I would guess the second, or more specifically I would guess that in any given 
 - (the total number of instances of admins swapping out network hardware and 
    needing to reuse the same interface names)
is greater than
 - (the total number of instances of admins setting up new systems with more than 
    one interface where it's necessary to preserve interface ordering across 

Specifically because:
* Most machines have only one interface (If Debian is running on more routers 
than workstations, obviously this would be wrong, but I doubt that's the case.)
* Lots of hardware is crummy and needs to be replaced at least once in a box's 

Also, there's another argument for defaulting to case two.
* Setup for case one needs only needs to be done (worst case) at the 
first reboot, and can be documented in installation notes which users with two 
network cards will probably read; setup for case two must be done (usually)
at the time of hardware malfunction and replacement, which is generally already
a stressful time, and the admin will have no hint as to where to look for the 

>In the absence of kernel guarantees about device ordering (as is the case
>with 2.6), the current udev implementation gives you the first at the
>expense of the second.  I believe this correctly optimizes for the common

I suspect that it incorrectly optimizes for the less common case.

Of course, it would be ideal if a compromise which handles both cases could be 
found.  The proposed solution at the top of thread is pretty good:

(1) Hardware which exists is assigned a static name, and keeps it;
(2) When the hardware stops existing, the name is released for reuse;
(3) A new piece of hardware will reuse the first released name.

This optimizes both the one-interface-replaced case (it's always eth0), and 
the typical multiple-interfaces-at-once case (they're stably named).

It wouldn't handle cases with two or more interfaces genuinely, physically 
hotplugged after boot *and* requiring stable names, but that's a genuinely rare 
case and anyone with that complicated a system should be writing custom rules.
(Most systems with large numbers of interfaces are routers, which either don't 
have swappable interfaces or have ones which are essentially "case two", 
hardware replacement.  Most other systems with two interfaces have at most one of 
them on a PCMCIA card or similar swappable device, and I've never heard of one with two 
different PCMCIA cards which need to retain consistent names distinct from 
each other.)

To be more specific about how this would work, network interface naming would
be a two-stage process, with all "new" interfaces delayed until after all "old" 
interfaces were believed to be up.
(1) When a "new" interface shows up which doesn't have a static name assigned yet,
    delay naming it until you believe all the "old" interfaces which do have 
    a static name assigned are up.
(2) When all the interfaces with static names assigned are believed to be up 
    (enough time has passed), assign static names to the "new" interfaces, 
    starting with the first unused one, even if it was previously assigned to 
    some interface which no longer exists (didn't come up).

Essentially udev would start with a list of "old" interfaces "known before this 
boot"; it would delay dealing with "new" interfaces until either all "old" 
interfaces were up, or a predefined time delay had passed.  No interface would be 
"new" more than once.  After a while multiple interfaces might end up with the 
same "stable" name assigned, but it would be very unlikely that they were 
interfaces which were actually used at the same time; generally one would be 
'active' and the others would be obsolete; alternatively, in the case of a system 
with several alternate PCMCIA cards, each one would have the same name but only 
one would be used at any given time.

The proposed solution above is pretty complicated (if straightforward) to 
implement, requiring some convoluted code in z45_persistent_net_generator and 
write_net_rules to test whether the interfaces with the persistent names were 
actually found and used (rather than merely whether a rule was written), and a 
delay, loop, and timeout if they weren't all found, and a fancier implementation 
of find_next_available to reuse abandoned rules.

Perhaps one could call it "semi_persistent_net_generator" -- the algorithm would 
mean that a name is persistent until you remove that hardware *and* insert new 

Marco D'Itri wrote "Think harder about it and you will understand why this cannot 
be tested in practice," but of course that's bullshit.  It's perfectly 
implementable and testable -- for testing, the delay and timeout could be set 
quite long.  It's not perfectly *reliable*, but it's just as
reliable as anything which depends on udev "finishing" setting up /dev, and 
we've been able to handle that (gobs and gobs of stuff depends on that, and 
we've managed to live with it).

Implementation is complicated enough that I wouldn't ask anyone else to do it.
(And it's easier to just work around it than to implement it myself.)
However, if someone *does* implement semi_persistent_net_generator, it would 
probably be a better default than the current scripts.


But perhaps the best "solution" is to document prominently that if you replace 
your network hardware, you should delete the line associated with the removed 
hardware from /etc/udev/rules.d/z25_persistent-net.rules before inserting the new 
hardware.  This would almost always give exactly the desired result, that the new
hardware would assume the name of the old hardware.

Actually, the same caveat should be documented with regard to 
z25_persistent-cd.rules.  I've had to swap out CD drives disturbingly often 
(dust, I think....), and thankfully I haven't yet had to do it with a machine 
running udev, because this would have bitten me as I wondered why the CD numbers 
kept going up and up and up.

Nathanael Nerode  <neroden@fastmail.fm>

"(Instead, we front-load the flamewars and grudges in
the interest of efficiency.)" --Steve Lanagasek,

Reply to: