[Eisfair] [e1] Netzwerk Interface-Name

Marcus Roeckrath marcus.roeckrath at gmx.de
Mo Jan 23 17:24:16 CET 2017


Hallo Detlef,

Detlef Paschke wrote:

>> BFB habe ich bislang nicht auf meiner Liste, finde im aktuellen Paket
>> auch keinen Hinweis auf ein zu konfigurierendes Netzwerk.
>> 
>> Kannst Du mir die Variable nennen, die mit einem Netzwerkdevice zu füllen
>> wäre.
> 
> BFB steht doch gleich als erstes in deiner Liste.

Ich stehe wegen meiner hartnäckigen Erkältung immer noch etwas neben der
Spur; danke für die Klarstellung.

>> udev versucht anhand gewisser Regeln, den Karten eindeutige Namen zu
>> geben.
> 
> Ich habe mir die ganze udev-Geschichte noch einmal durchgelesen und
> glaube den Grund für die Umbenennung nun begriffen zu haben. Korrigiere
> mich wenn ich falsch liege.
> 
> Der Devicename der Netzwerkkarten ist im Grunde nach wie vor immer noch
> eth0 für die zuerst geladene, eth1 für die 2te usw. _aber_ mit udev ist
> nicht sichergestellt welche Karte zuerst geladen wird und somit kann im
> dümmsten Fall eth0 und eth1 bei jedem Start vertauscht sein.

Das ist eine Möglichkeit, der andere die "Race Condition", wenn systemseitig
wieder ethX Devices gewünscht sind, aber die wegen derzeitiger Belegung
durch eine andere Karte nicht die weitere Karte zur Verfügung stehen.

Ich versuche das nochmal im Vergleich vor udev und mit udev, sowie ich es im
Rahmen der Untersuchungen verstanden habe, mal darzustellen.

Vor udev musste man die notwendigen Netzwerkkartenmodule explizit angeben,
es fand keine automatische Erkennung der Hardware statt.

Ich bleibe zunächst mal beim Fall, dass es zwei Netzwerkkarten mit
verschiedenen treibern (Modul X und Y) sind.

Mit der Reihenfolge, mit der man nun in der Netzwerkmodul-Sektion der
Base-Konfiguration die Module X und Y angab, war festgelegt, welche Karte
nun eth0 und welche eth1 war. Geladen wurden die Module über ein
Initskript.

Mit udev ist das entfallen, da der Kernel über seine Hardwareerkennung für
das Laden der notwendigen Treiber sorgt, das Laden per Initskript erst viel
später käme.

Erkennt der Kernel nur eine Netzwerkkartenhardware wird nun der zugehörige
Treiber geladen und diesem zunächst eth0 zugeordnet.

Welche Netzwerkkarte von zweien als erste gefunden und initialisiert wird,
ist möglicherweise nicht vorhersehbar; wenn dann die zweite Karte gefunden
wird, wird auch deren Treiber geladen und - ja welches Devices zugewiesen?

Es wird neue Netzwerk-Hardware eingesteckt (z. B. auch per USB-Stick oder
ähnlichem), dann kann sich durch die Hardwareerkennung des Kernels schon
die Reihenfolge ändern.

Hier fängt also die Ungewissheit an.

udev hat zum Ziel, der Ungewissheit ein Ende zu machen und "predictable"
Devicenamen zuzuordnen, egal, was vorher passiert. Diese vorhersehbaren
sind keine ethX Namen, sondern enp (von der BusID abgeleitet), enx (von der
Macadresse abgeleitet.

Nehmen wir also mal an, es wird im System mit diesen vorhersehbaren Namen
gearbeitet, läuft der Bootprozess etwas so ab:

1. Karte wird mit eth0 an udev gemeldet und von diesem nach enp<busid1>
umbenannt; eth0 wird wieder freigegeben.

2. Karte wird eth0 (falls zu diesem Zeitpunkt schon wieder freigegeben) oder
eth1 an udev gemeldet und dann nach enp<busid2> umbenannt.

Wie wir inzwischen erkannt haben, ist enp<busid> nicht stabil gegenüber
Hardwareänderungen (auch wenn andere Distris auf diesen namensraum setzen),
weshalb wir mit dem nächsten Base-Update auf enx<macadr> umschwenken
werden.

Du möchtest nun ausgangsseitig wieder ethX verwenden, also wird Ein- und
Ausgangsseitig der gleiche Namensraum verwendet.

1. Karte wird zunächst mit eth0 an udev gemeldet, dann nach enp<busid1>
umbenannt (hier wird dann im Anschluss eth0 wieder freigegeben) und dann
per individueller Rule nach eth1, falls eth1 frei ist.

2. Karte wird mit eth0 (falls der schon weider frei ist oder eth1 an udev
gemeldet, dann nach enp<busid2> und abschliessend nach eth0 umbenannt
(falls verfügbar).

Da diese Prozesse teilweise parallel ablaufen, kommt es hier schnell zu
gegenseitigen Blockaden (Race Conditions), z. B. wird die 2. Karte initial
zu eth1 kann das die Umbennung der 1. Karte blockieren.

Das ist nicht kontrollierbar und viel vom Timing während des Boots abhängig.

Vermeidbar nur, wenn ausgangsseitig nie ethX-Devicenamen verwendet werden
und diese rein der Erstinitialisierung vorbehalten bleiben.

In Deinem Fall liegt es noch etwas anders:

Der Kernel erkennt eine Netzwerkkarte und lädt den e1000 mit eth0 für die
erste Karte. Der Treiber bemerkt nun aber, dass eine zweite Karte für den
Treiber im System steckt und initialisiert also nun beide gleichzeitig.

Wie, in welcher Reihenfolge liegt nun im "Ermessen" des Treibers.

Vor udev hattest Du in der Base-Konfiguration auch nur einen Treiber stehen,
der beim Laden beide Karten initialisiert hat. Die vom Treiber zuerst
initialisiert bekam eth0, ... Dann hast Du überlegt, welches Netz welcher
ethX-Karte behandeln soll und die Kabel passend gesteckt. Das die f0-Karte
zu eth0 und die f1-Karte zu eth1 wurde ist IMHO Zufall, oder ist das eine
Netzwerkkarte/chip mit eideutiger Reihenfolge.

Mit udev wird nun vom Treiber eine Karte mit eth0 und die andere mit eth1
initialisiert und dann setzt der Umbenennungsprozess ein, der wie oben
scheitern kann, wenn das gewünschte Zieldevice noch in Verwendung durch die
andere Karte ist.

Aber es führt an udev kein Weg vorbei:

- neuerer Kernel
- neuerer gcc
- Software, die einen neueren gcc voraussetzt
- kein unnötig rieges mitzulieferndes dev-Verzeichnis; dynamische Devices

Ohne udev kann man eisfair IMHO begraben, weil wir dann nicht dauerhaft ein
sicheres System garantieren können.

Was es noch so an Sonderfällen mit udev zu beachten gilt, mag man gerne mal
in meinem Wikibeitrag nachlesen.

Ich hoffe, ich habe die Problematik halbwegs richtig darstellen können; wir
sind im Team schon einige Zeit an dem Thema dran.

> Alte Leute und Veränderungen... ;-)

Wir können ja hier mal eine Altersrangliste aufstellen.

Hint: In meiner Schulzeit gab es noch keine Taschenrechner sondern
Logarithmustabellen.

-- 
Gruss Marcus


Mehr Informationen über die Mailingliste Eisfair