Hallo miteinander,
Kurz zusammengefasst die Erkenntnisse, die letztlich mein Problem gelöst haben. 1. Status jetzt: bond0 Link encap:Ethernet Hardware Adresse 00:15:17:DD:DE:22 inet Adresse:172.16.0.20 Bcast:172.16.255.255 Maske:255.255.0.0 inet6 Adresse: fe80::215:17ff:fedd:de22/64 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:193552957 errors:0 dropped:10 overruns:0 frame:0 TX packets:85113290 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:0 RX bytes:209304300835 (199608.1 Mb) TX bytes:6416975258 (6119.7 Mb)
Die 10 dropped packets stammen vermutlich aus der Initialisierungphase am Switch, denn die verteilen sich gleichmäßig auf eth0-eth3 (wobei eth1 keine Pakete gedropt hat, denn dieses Interface wird vom Treiber als erstes initialisiert, die Nummerierung ändert UDEV).
Das Problem bestand am Switch selbst, den die Netzwerkfirma eingerichtet hat. Der Switch muss natürlich die Bündelung der Netzwerkkarten seinerseits richtig unterstützen. Dazu dient LACP, um per 802.3ad zu bündeln.
Nun begab es sich, dass jene Firma zwar einen wilden Wuchs an Kabeln in den Switch führte, jedoch nirgends etwas dokumentierte. So war weder an den Kabeln, noch an Farben o.ä. ersichtlich, was wohin führte. Als ordnungsliebender Mensch davon gefrustet, entschied ich mich, die Kabel neu zu stecken, mit Aufklebern zu versehen und die Portbelegung des Switch sauber zu dokumentieren (OO-Tabelle). Laut der Beschreibung von HP ist LACP normalerweise bei "Server-Einschüben" (VL-Modul mit LWL-Anschlüssen) per AUTO aktiviert. Bündelung wird damit automatisch erkannt und vom Switch unterstützt. An anderen Anschlüssen kann es zudem aktiviert werden. Nun hatte jene Firma an einigen Ports dieses LACP aber deaktiviert. Eth2 und eth3 steckten also auf Ports, die somit nicht mehr automatisch gebündelt wurden. Da sie aber von UDEV und dem Bonding-Kerneltreiber gebündelt wurden, sendete der Switch die an anderen Port gesendeten Pakete wieder zurück - und wurden korrekt abgewiesen (also dropped).
Dummerweise kommt man an diese Einstellungen nicht per Web-Interface heran, nur per Telnet oder serieller Konsole. Dadurch ist der Fehler erst so spät aufgefallen.
Bist Du sicher, dass Dir da so etwas wie UDEV nicht reinfunkt? Ich habe mich gerade auf mehreren Systemen mit Intel Multiportkarten umgesehen, dort haben alle Schnittstellen immer eigene MAC.
Auch dass kann ich erklären: Wiederum mit dem Switch. Die Netzwerkkarten, die jetzt ohne Aktivierung in das Bonding mit einer IP versehen wurden, steckten auf Ports, die LACP nicht auf Auto, sondern auch AKTIV stehen hatten. Damit bündelte der Switch irgendwie diese Karten und entweder Kernel-Treiber oder UDEV (oder beide?) erkannten offenbar diese erzwungene Bündelung. Nachdem ich einen Port umgesteckt hatte, bekamen die beiden Interfaces korrekt verschiedene MAC-Adressen verpasst (die natürlich aufeinander folgten).
Fazit: Trau keiner Netzwerkfirma, die nicht einen Ordner mit Dokumentation übergeben hat. Hinterher sucht man sich dumm und dämlich...
Gruss Reiner