Reiner Klaproth klaproth@online.de (So 04 Dez 2011 08:34:02 CET):
Hallo!
Am Samstag, 3. Dezember 2011, 18:00:53 schrieb Reiner Klaproth:
Einen Reboot später weiß ich mehr: Jetzt zählt nicht mehr der Zähler an eth3 hoch, sondern der an eth2 (Weiß der Fuchs warum...)
Auch das ist erklärbar: Die Netzwerkkarten sind Intel-Serverkarten, die mit einem Baustein zwei Netzwerk-Interfaces anbieten. Somit sind also eth2 und eth3 physisch an einen Baustein gekoppelt (und haben dieselbe MAC-Adresse!).
Gebündelt oder als Hub betrieben… wobei ich bei Serverkarten eher ersteres vermute, wiewohl ich das noch nie gesehen habe. Vielleicht kann man das in irgend einem BIOS beeinflussen. Denn intuitiv kommt mir das nicht vor. Wenn ich an einem Server zwei Ports sehe, dann würde ich auch davon ausgehen, daß ich zwei Ports (NICs habe).
Bist Du Dir sicher, daß die Dinger schon vor dem „enslaven“ in das Bond-Interface die selbe MAC haben?
Daher hatte der Kernel das Problem, die Karten zuzuordnen. Darin steckt offenbar auch das Problem: Laut lspci haben diese Karten keinen Interrupt zugeteilt bekommen. Das ACPI-Management liefert als IRQ 66 und 76.
Da sehe ich keinen Zusammenhang zur selben MAC.
Fakt ist offenbar, dass Intel die Karten selbst auch als "Bündel" betreibt. Offenbar schaltet nicht nur eth3 auf 100MBit herunter, sondern parallel auch eth2. Das erklärt die verlorenen Pakete.
Ach so, eth3 und eth2 sind ja nicht gemeinsam im Bond-Interface. Dann ist meine Frage von oben vielleicht auch Quatsch.
Das gleich der Chip beide Interfaces „runterzieht“, wenn man die Geschwindigkeit auf einem ändert, ist ja eine dolle Sache.
Erster Würg-Around: Nur noch eth0 und eth1 sind auf bond0 gebündelt, denn diese funktionieren (auch eine Intel-Dual-Port-Serverkarte). Wahrscheinlich muss der Server eine weitere Netzwerkkarte erhalten für das 100MBit-Interface. Schön, dass so etwas nirgends ordentlich dokumentiert ist...
Nun schon ☺