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
_______________________________________________
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
