Bond mit altem? Problem.

[Falk R.]

Wenn dein Windows aus heiterem Himmel beim Zugriff auf eine schnöde Freigabe plötzlich behauptet, deine Zugangsdaten seien falsch, liegt das an HW? Es funktioniert ja schließlich tausendfach?

Dann ist die Freigabe wohl OK, aber die Credentials nicht. So einfach ist das manchmal.

Schon das Umstellen in der GUI erzeugt den 10min-Schluckauf. Die Verhalten bei Wiederherstellung des Primary ändern sich nicht.

Da scheinst du irgendein Problem allgemein mit der NIC zu haben.
Normalerweise gibt es kein Schluckauf, wenn man in der GUI was ändert.

Kann es sein, dass du Bonding nur innerhalb einer Multiport-Karte betreibst?
Ich habe das Problem nämlich mit zwei physisch getrennten Karten.

Natürlich nicht, einmal Intel 10G und einmal Realtek 2,5G.
Bei Kunden auch oft Mellanox mit Broadcom gemischt.

Habe ich ja gemacht. Siehe mein gepostetes Log. Hast du es denn wenigstens überflogen und womöglich Unregelmäßigkeiten gesehen?

Mir ist da nix aufgefallen, aber wenn der Treiber zicken macht, würde ich das vermutlich auch nicht im Log erkennen.

Ich bin dann jemand, der hinterfragt und testet, warum Failover wie erwartet sehr gut funktioniert und die schnöde Wiederherstellung der primary-Leitung durch schnödes Anstöpseln 10min in Anspruch nimmt.
Glaube mir, ich habe es mit unterschiedlichen HW-Konstellationen probiert. Haben die alle ein und dasselbe HW-Problem?

Welchen Kernel nutzt du? Ich habe festgestellt, das ganz viele Netzwerkproblemchen gefixt wurden zwischen dem 6.8 und dem 6.14er Kernel.

Seltsam ist, dass die Karte mit 8125-Chip, für den es sogar einen eigenen Treiber gibt, mittels r8169-Treiber betrieben wird.
Wer bin ich aber, um den Debian->Ubuntu->Proxmox-Entwicklern mit vermeintlich meinerseits besseren Treibern in die Parade zu fahren?
Das wäre Rumstochern, wie es bei einem speziellen Anbieter leider nur zu üblich ist.

Hast du mal testweise versucht den 8125er Treiber zu nutzen. Mich würde es nicht wundern wenn es genau daran liegt.

Schön wäre es, wenn jemand sich 30min Zeit nimmt und es auf einem Testsystem ausprobiert.

Den extrem unwahrscheinliche Fall, dass die Netzwerkinfrastruktur das Problem verursacht, habe ich noch nicht vollständig durchdekliniert aber auf der ToDo-Liste.

Noch habe ich nicht kapituliert und 10 dusselige Minuten akzeptiert.

 

[meyergru]

Kleiner Nachtrag zu meiner Idee mit fail_over_mac=follow: Ich habe das testweise mal auf einer VM eingetragen mit /etc/modprobe.d/bonding.conf als

options bonding fail_over_mac=2

Das kann man übrigens so überprüfen:

root@test:~# cat /sys/class/net/bond0/bonding/fail_over_mac

Wenn man dann zwei Interfaces (ens19 und ens20) als Slaves einträgt, sieht das bei Verbindung von beiden Interfaces so aus:

root@test:~# ip a s
3: ens19: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether 32:83:dc:8b:e9:03 brd ff:ff:ff:ff:ff:ff permaddr bc:24:11:52:82:a3
    altname enp0s19
    altname enxbc24115282a3
4: ens20: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether bc:24:11:da:49:de brd ff:ff:ff:ff:ff:ff
    altname enp0s20
    altname enxbc2411da49de
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 32:83:dc:8b:e9:03 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.200/24 scope global bond0
       valid_lft forever preferred_lft forever

Wenn man ens19 disconnected, dann so:

root@test:~# ip a s
3: ens19: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master bond0 state DOWN group default qlen 1000
    link/ether bc:24:11:da:49:de brd ff:ff:ff:ff:ff:ff permaddr bc:24:11:52:82:a3
    altname enp0s19
    altname enxbc24115282a3
4: ens20: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether 32:83:dc:8b:e9:03 brd ff:ff:ff:ff:ff:ff permaddr bc:24:11:da:49:de
    altname enp0s20
    altname enxbc2411da49de
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 32:83:dc:8b:e9:03 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.200/24 scope global bond0
       valid_lft forever preferred_lft forever

Wie man sieht, "wandert" die bond0-MAC 32:83:dc:8b:e9:03 somit auf das jeweils richtige Interface ens19 oder ens20.

Wiederholt man den Test ohne den Modulparameter, ist es so (die zufällige bond0-MAC ist jetzt 6e:00:6e:13:8c:af) :

root@test:~# ip a s
3: ens19: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether 6e:00:6e:13:8c:af brd ff:ff:ff:ff:ff:ff permaddr bc:24:11:52:82:a3
    altname enp0s19
    altname enxbc24115282a3
4: ens20: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether 6e:00:6e:13:8c:af brd ff:ff:ff:ff:ff:ff permaddr bc:24:11:da:49:de
    altname enp0s20
    altname enxbc2411da49de
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 6e:00:6e:13:8c:af brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.200/24 scope global bond0
       valid_lft forever preferred_lft forever

Und mit ens19 disconnected:

root@test:~# ip a s
3: ens19: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master bond0 state DOWN group default qlen 1000
    link/ether 6e:00:6e:13:8c:af brd ff:ff:ff:ff:ff:ff permaddr bc:24:11:52:82:a3
    altname enp0s19
    altname enxbc24115282a3
4: ens20: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
    link/ether 6e:00:6e:13:8c:af brd ff:ff:ff:ff:ff:ff permaddr bc:24:11:da:49:de
    altname enp0s20
    altname enxbc2411da49de
5: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 6e:00:6e:13:8c:af brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.200/24 scope global bond0
       valid_lft forever preferred_lft forever

Also: beide Interfaces haben immer die selbe MAC. Das wird oft nicht funktionieren, zumindest, wenn Ethernet-Frames abseits des TCP-IP-Stacks gesendet werden und somit der Switch den richtigen Port nicht findet.

Q.E.D.

 

[TErxleben]

Also: beide Interfaces haben immer die selbe MAC.

Klingt schon logisch. Über die MACs habe ich mich auch schon gewundert.

Du hast also einen PVE-Host als VM mit active-backup angelegt?
Diesem dann eine eine

/etc/modprobe.d/bonding.conf mit Inhalt
options bonding fail_over_mac=2

verpasst?

Richtig?

 

[meyergru]

Nein, wie ich schrieb: Ich habe es mit einer Ubuntu-VM getestet, dort allerdings auch netplan durch ifupdown2 ersetzt, genau wie in Proxmox.

Im Wesentlichen läuft es für Dich aber genau auf die eine Datei hinaus. Einfach reinschreiben, rebooten und hinterher checken, dass cat /sys/class/net/bond0/bonding/fail_over_mac den richtigen Wert anzeigt und dann Dein Szenario durchspielen.

 

[TErxleben]

Gesagt getan. Ich habe eine

/etc/modprobe.d/bonding.conf mit Inhalt
options bonding fail_over_mac=2

angelegt und kontrolliert.

Wo und wie trägst du denn die slaves ein?

 

[meyergru]

So wie Du, in der /etc/network/interfaces. Der Module-Parameter setzt nur den Default für den spezifischen Interface-Wert, den man weder mit sysfs noch mit ifupdown2 setzen kann. Also würden ggf. alle Bond-Interfaces diesen Modus verwenden - was ja sinnvoll ist.

 

[TErxleben]

Dann klappt das leider nicht. Kiste hängt. Ziehen und stecken der Failoverleitung führt umgehend zu korrektem reconnect.

 

[TErxleben]

Wie verhält sich denn deine Ubuntu-VM, wenn du ihr die Hauptleitung unter dem Arsch weglöschst und kurze Zeit wieder zuweist?

 

[meyergru]

Wie erwartet: Die Verbindung läuft weiter ohne sichtbare Auswirkungen. Mir sieht das bei Dir danach aus, als würde der Treiber der primären Verbindung zwar dem Kernel signalisieren, dass die Verbindung wieder da ist, aber sie funktioniert eben nicht.

Das kann entweder der Switch sein, der die Verbindung nicht nutzt (das war mein Verdacht), weil er aufgrund der MACs nicht den richtigen Weg nimmt oder der Treiber, der eventuell die Karte nicht wieder richtig initialisiert, wenn das Kabel gesteckt wird.

Mein Test lief ja mit emulierten Adaptern (vtnet).

Ich würde andere Hardware testen, wenn möglich, z.B. könnten Billig-Switche in diesem Bereich Probleme haben. Es gibt auch einen nativen r8125-Treiber von Realtek. Um den zu installieren, muss man den In-Kernel-Treiber r8169 blacklisten.

 

[meyergru]

Du hast auch einen Reboot ausgeführt nach Anlage der Modul-Parameter-Datei?

 

[TErxleben]

Habe ich.
Ich bin mir allerdings unsicher, ob man das Problem in einer VM behandeln kann oder hast du Netzwerkkarten an die VM durchgereicht?

 

[meyergru]

Nein, virtio, ich wollte nur meine MAC-Theorie verifizieren - und das hat ja geklappt.

Die Ethernet-Frames gehen dann an einen echten Switch (Unifi), von dem aus ich die Verbindung getestet habe. Insofern ist bei virtio die "Hardware" und der Linux-Treiber "unverdächtig", der Switch wohl auch.

Es ist allerdings richtig, dass der physische Port bei diesem Szenario auch immer der gleiche bleibt, so dass ein etwaiges Problem am Switch ohnehin nicht auftreten würde.

Ich habe aber auch keine Realtek-Hardware, die ich durchreichen könnte. Wie gesagt, wenn die korrekte MAC-Behandlung das Problem bei Dir nicht fixt, kommen aus meiner Sicht nur NIC-Hardware, - Treiber oder Switch als Ursache in Frage. Rein theoretisch könnte es natürlich auf ein defekter Kernel sein (ich hatte ja nicht den Proxmox-, sondern den Ubuntu-Kernel).

 

[TErxleben]

In meiner Welt melden sich die active-backup Bondmitglieder alle mit ihrer eigenen MAC an Switchen an. Die Technik funktioniert, da ein "Proxy" auf dem Bondinghost sämtlichen Netzwerkverkehr auf den "inaktiven" aber physisch aktiven Slaves unterdrückt.
Da kann ein Switch gar nicht in die Irre geführt werden. Der Bondingdienst des Hosts entscheidet.
Oder liege ich damit inzwischen gedanklich womöglich falsch?

 

[meyergru]

Ja, tust Du. Weil dann der ARP für die IPv4 neu ausgehandelt werden müsste und die EUI-64 für IPv6 dann gar nicht mehr funktioniert, weil die aus der MAC abgeleitet wird. Sogar bei der Normal-Variante ohne das Setting würde der aktive Slave die richtige MAC verwenden. Es ist nur die Frage, was der "angeblich" inaktive dann tut, bzw. ob sich bestimmte Service im inaktiven Slave schon an die spezifische Interface-MAC binden.

An sich funktioniert die Default-Variante für Fail-Over-MAC auch bei TCP/IP, aber nicht bei bestimmen anderen Ethernet-Protokollen (z.B. LLDP) - ich hatte die Links auf die Erklärungen dazu eingangs gepostet.

Für die exotischen Fälle ist das "Follow"-Setting jedenfalls niemals schlechter.