Bond mit altem? Problem.

[TErxleben]

Im Zuge des e1000-Generves habe ich einem Kandidaten mal eine zusätzlicheM2- 2.5GB-Realtek (8125) verpasst. Diese ist als Pimary definiert. Dann habe ich ein Bond (active-backup) erstellt. Ziehe ich nun das Kabel, übernimmt die e1000 auch brav ihren Stellvertreterdienst. Stelle ich die Verbindung der Realtek wieder her, zeigt journalctl auch brav, dass sie wieder verfügbar ist (KVM sei Dank). Allerdings ist die Kiste erst wieder erreichbar, wenn ich das Kabel des Failovers ziehe. Es bleibt auch erreichbar, wenn ich danach die Failoververbindung wieder herstelle
Kann ja wohl nicht im Sinne des Erfinders sein.
Hier meine Konfiguration:

root@pve4:~# cat /etc/network/interfaces

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto enp2s0
iface enp2s0 inet manual

iface bond0 inet manual
        bond-slaves eno1 enp2s0
        bond-miimon 100
        bond-mode active-backup
        bond-primary enp2s0

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.234/24
        gateway 192.168.1.254
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0



und

root@pve4:~# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.14.11-1-pve

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: enp2s0 (primary_reselect always)
Currently Active Slave: enp2s0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0

Slave Interface: eno1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 7
Permanent HW addr: b8:85:84:a1:be:53
Slave queue ID: 0

Slave Interface: enp2s0
MII Status: up
Speed: 2500 Mbps
Duplex: full
Link Failure Count: 9
Permanent HW addr: 00:e0:4c:68:0a:15
Slave queue ID: 0

 

[waltar]

Du findest aber auch immer komische Probleme ..., aber vielleicht hat sich der Erfinder gedacht, wenn schon 1 Leitung mal wegbricht, dann stimmt da eh was nicht und "ich wechsele mal nicht gleich wieder zurück" und der Admin soll das erst mal überprüfen, was da überhaupt passiert ist und wenn dann iO soll/kann er dann auch den Traffic wieder auf's ursprüngliche Device umstellen ... weiß man's, man steckt ja nicht im Developer drin ...

PS: Aber gut das du die Funktion auch wirklich getestet hast, anstatt sich auf blind auf eingestellte configs (per cli oder gui) zu verlassen !

 

[noPa$$word]

Probier mal einen der zusätzlichen Werte

bond-primary-reselect always / better / failure = kein automatischer Fallback

 

[Falk R.]

Da hast du tatsächlich mal wieder ein Problem gefunden, was sonst keiner hat.
Ich habe bei mir mal den 10G Link im A/B Bond gezogen und wieder gesteckt. Bei meinem Setup geht der Traffic auch direkt wieder über die 10G Nic. (Zumindest sagt das der Switch)
Wie lange war die erste NIC offline?
Manche nachgerüsteten NICs erkennen Kabelfehler erst sehr spät und wenn du dann zu schnell wieder steckst, informiert die NIC nicht korrekt das OS, dass die Verbindung wieder da ist.
Kann man gut checken, indem man den Status der Nic mal checkt wenn das Kabel raus ist.

 

[TErxleben]

Was meinst du denn mit sehr spät? Der eigentliche failover geht praktisch unterbrechungsfrei. Nur die Wiederherstellung funktioniert die Schnittstelle erst, nachdem die Failover-Strippe kurz gezogen wird. Dann aber auch blitzschnell.

Für die Zeiten mal ein entsprechendes Log:

Sep 10 15:03:13 pve1 kernel: r8169 0000:01:00.0 enp1s0: Link is Up - 1Gbps/Full - flow control rx/tx
Sep 10 15:03:13 pve1 kernel: bond0: (slave enp1s0): link status definitely up, 1000 Mbps full duplex
Sep 10 15:04:25 pve1 kernel: r8169 0000:02:00.0 enp2s0: Link is Down
Sep 10 15:04:25 pve1 kernel: bond0: (slave enp2s0): link status definitely down, disabling slave
Sep 10 15:04:25 pve1 kernel: bond0: (slave enp1s0): making interface the new active one
Sep 10 15:04:25 pve1 kernel: r8169 0000:02:00.0 enp2s0: left promiscuous mode
Sep 10 15:04:25 pve1 kernel: r8169 0000:02:00.0 enp2s0: left allmulticast mode
Sep 10 15:04:25 pve1 kernel: r8169 0000:01:00.0 enp1s0: entered promiscuous mode
Sep 10 15:04:25 pve1 kernel: r8169 0000:01:00.0 enp1s0: entered allmulticast mode
Sep 10 15:05:04 pve1 kernel: r8169 0000:02:00.0 enp2s0: Link is Up - 2.5Gbps/Full - flow control rx/tx
Sep 10 15:05:04 pve1 kernel: bond0: (slave enp2s0): link status definitely up, 2500 Mbps full duplex
Sep 10 15:05:04 pve1 kernel: bond0: (slave enp2s0): making interface the new active one
Sep 10 15:05:04 pve1 kernel: r8169 0000:01:00.0 enp1s0: left promiscuous mode
Sep 10 15:05:04 pve1 kernel: r8169 0000:01:00.0 enp1s0: left allmulticast mode
Sep 10 15:05:04 pve1 kernel: r8169 0000:02:00.0 enp2s0: entered promiscuous mode
Sep 10 15:05:04 pve1 kernel: r8169 0000:02:00.0 enp2s0: entered allmulticast mode
Sep 10 15:16:58 pve1 kernel: r8169 0000:02:00.0 enp2s0: Link is Down
Sep 10 15:16:58 pve1 kernel: bond0: (slave enp2s0): link status definitely down, disabling slave
Sep 10 15:16:58 pve1 kernel: bond0: (slave enp1s0): making interface the new active one
Sep 10 15:16:58 pve1 kernel: r8169 0000:02:00.0 enp2s0: left promiscuous mode
Sep 10 15:16:58 pve1 kernel: r8169 0000:02:00.0 enp2s0: left allmulticast mode
Sep 10 15:16:58 pve1 kernel: r8169 0000:01:00.0 enp1s0: entered promiscuous mode
Sep 10 15:16:58 pve1 kernel: r8169 0000:01:00.0 enp1s0: entered allmulticast mode
Sep 10 15:17:39 pve1 kernel: r8169 0000:02:00.0 enp2s0: Link is Up - 2.5Gbps/Full - flow control rx/tx
Sep 10 15:17:39 pve1 kernel: bond0: (slave enp2s0): link status definitely up, 2500 Mbps full duplex
Sep 10 15:17:39 pve1 kernel: bond0: (slave enp2s0): making interface the new active one
Sep 10 15:17:39 pve1 kernel: r8169 0000:01:00.0 enp1s0: left promiscuous mode
Sep 10 15:17:39 pve1 kernel: r8169 0000:01:00.0 enp1s0: left allmulticast mode
Sep 10 15:17:39 pve1 kernel: r8169 0000:02:00.0 enp2s0: entered promiscuous mode
Sep 10 15:17:39 pve1 kernel: r8169 0000:02:00.0 enp2s0: entered allmulticast mode

 

[Falk R.]

Ja der Failover im PVE geht schnell. Die NIC intern merkt das aber manchmal nicht so schnell. Gerade bei USB NICs ist das bekannt und bei den m.2 Nachrüstkarten bin ich mir da auch nicht so sicher. Da dauert es auch manchmal bis zu 10 Sekunden bis die LED endlich aus ist, obwohl der Failover schon lange durch ist.
Einfach mal zum testen das Kabel eine Minute draußen lassen und schauen was dann passiert, wenn du neu steckst.
Meine 5x2,5g und 4x10G sind alle intern verbaut, da ist die LED auch schon nach 1-2 Sekunden aus. Danach funktioniert der Failback problemlos.

 

[TErxleben]

Vieeel Geduld hilft.
Obwohl sowohl journalctl als auch LEDs der Karte und am Switch unverzüglich Erfolg nach Wiederherstellung der Primärverbindung melden, ist der Host danach ca. 5-10min gar nicht erreichbar. Dieser Lag ist schon unschön und verwirrend.
Vor allem wenn es andersherum blitzschnell und reibungslos funktioniert.
Wie von @waltar schon angedacht, gibt es womöglich tatsächlich einen Delay-Parameter, der "Leitungsgeflatter" verhindern soll.
Warum der Host dieses Delay nicht einfach auf der Failoverstrippe aussitzt, sondern stattdessen lieber den Host offline stellt, verstehe ich nicht.

 

[TErxleben]

Probier mal einen der zusätzlichen Werte

bond-primary-reselect always / better / failure = kein automatischer Fallback

Änderte nichts. Zumal always ja Default ist.

 

[TErxleben]

Anekdote am Rande: Eine der gelieferten M.2-Karten war tatsächlich DOA und hat sich nur mit 10MB/s verbunden. Das war auch schon ein Spaß für die ganze Familie.
Im Funktionsfall schieben die Dinger aber knapp 300MB/s über die Leitung ohne messbar mehr Strom zu verbrauchen oder warm zu werden.

 

[Falk R.]

Da ich solche Probleme noch nie gehabt habe, wäre ich bei so einer Netzwerkkarte vorsichtig.
Active Backup Bond nutze ich bei Linux seit 25 Jahren ohne solche Probleme.
Daher gehe ich davon aus, das es nicht an der Software liegt.

 

[TErxleben]

Den LEDs der Karte und des Switches traue ich mehr als SW.
Zumal ein kurzes trennen der Failoverleitung auch zu sofortiger Wiederherstellung führt.
Den physischen Defekt der erwähnten Karte konnte man auch anhand der LEDs feststellen.
Meiner Erfahrung nach sind 95% der Fehlerursachen SW-bedingt.

 

[Falk R.]

Den LEDs der Karte und des Switches traue ich mehr als SW.
Zumal ein kurzes trennen der Failoverleitung auch zu sofortiger Wiederherstellung führt.
Den physischen Defekt der erwähnten Karte konnte man auch anhand der LEDs feststellen.
Meiner Erfahrung nach sind 95% der Fehlerursachen SW-bedingt.

Komisch das die Software nur bei dir den Fehler hat.
Du willst nicht wissen, wie viele Softwarefehler von der Hardware verursacht werden. 99% aller BSOD bei Windows haben einen Hardwarehintergrund. Entweder Treiber, Firmware oder die HW selbst.
Das Bonding ist nix was Debian oder Proxmox neu erfunden hat. Das steckt in jeder Linux Distro seit Jahrzehnten. Wenn Features wie LACP mal probleme machen, dann ist da ja noch ein Protokoll dahinter, was mit anderen Geräten interagiert. Das Active-Backup Bonding funktioniert Millionenfach sauber auf der Welt. Das ist der Grund warum ich einen generellen Fehler in der SW für extremst unwahrscheinlich halte.
Kann natürlich auch am Treiber der NIC liegen, was zwar ein Stück Software ist, aber Hardwarerelevant.

 

[TErxleben]

Komisch das die Software nur bei dir den Fehler hat.

Wer sagt denn das? Vielleicht ist es nur wenigen aufgefallen und noch wenigere haben es zu Sprache gebracht.

Du willst nicht wissen, wie viele Softwarefehler von der Hardware verursacht werden. 99% aller BSOD bei Windows haben einen Hardwarehintergrund. Entweder Treiber, Firmware oder die HW selbst.

Ist das ein Scherz?
Linux war schon immer pingeliger bzgl. HW, weshalb dusselig programmierte SW schon immer eher auffällt. 99% aller Probleme seitens Windows liegen aber an SW aus dem gleichen Hause.

Genau darum bin ich über das Failovererhalten gestolpert. Ich bin einfach gewohnt, dass Logausgaben Probleme sehr zeitnah melden. Noch schneller und exakter sind nur HW-LEDs.
Hier haben Protokolle immer gleichzeitig zur LED gemeldet es sei alles i.O. TROTZDEM braucht die Bonding-Schnittstelle 10min um sich zu berappeln.

Das Bonding ist nix was Debian oder Proxmox neu erfunden hat.

GENAU deshalb sollte es keine derart eklatante zeitliche Differenzen geben!

Es schmerzt mich, dass Tipps wie "geduld" "gegentreten" und weitere "1000 Tipps&Tricks die sie noch nie geahnt haben" aus der WinWelt hier nun gruseligerweise auch Einzug halten und noch perfider sogar zum Erfolg führen.
Der Weg MUSS i.m.A sein: LED meldet ok=>Protokoll meldet ok=>Dienst muss funktionieren.
Wenn das nicht mehr geht, mache ich im hohen Alter noch einen MSCE oder setze eine WinVM einfach zurück und warte aufs nächste Update und lege mich auf den Rücken.

 

[Falk R.]

Also das Active Backup Bond habe ich schon vor 20 jahren bei den Linux Oracle Clustern Regelmäßig testen müssen und auch jetzt wenn ich bei Kunden solche Bonds einsetze, wenn die Hardware z.B. kein MLAG kann, dann machen wir natürlich auch Funktionstests.
Bei Enterprise Hardware kann ich guten Gewissens unterschreiben das ein A-B Bond immer korrekt arbeitet. So viele Hunderte male wo ich es Kunden gezeigt habe und es nie ein anderes verhalten gab, spricht für mich eine Sprache.
Teste das doch mal mit anderer Hardware, ob du da das Verhalten auch hinbekommst.
Alles was nicht reproduzierbar ist, liegt zu 99% nicht an der Software. Ist es Reproduzierbar, muss man dann auf die Suche des gemeinsamen Nenners gehen um den Fehler zu finden.
Ich kann es bei mir mit Consumer Hardware auch nicht nachstellen.

 

[TErxleben]

MLAG? Das ist kommt bei Active-backup doch gar nicht zum Tragen.
Es geht hier um die allereinfachste Form der Redundanz IN einem host.

Ich habe hier nur mit allem Drum und Dran beschrieben, dass eben A-B gerade nicht wie erwartet funktioniert. Nichts mehr und nichts weniger.

Ich muss 10min Warten, bis eine Kiste wieder online ist nachdem die primäre Leitung wieder aktiv ist.

Du erzählst mir, ich würde mein iPhone falsch halten.

 

[Falk R.]

MLAG? Das ist kommt bei Active-backup doch gar nicht zum Tragen.

Nein, wenn es kein MLAG gibt, nimmt man dann gern als einfachste Alternative Active-Backup

Dann check doch mal warum die NIC erst nach 10 Minuten wieder richtig funktioniert. Eventuell Treiber/Firmware Missmatch?
Du kannst dein iPhone auch gern anders herum halten, aber vermutlich interessiert das deine NIC auch nicht,

Also wenn etwas mit deiner Hardware nicht wie erwartet funktioniert, aber mit anderer Hardware tausendfach erwartbar reagiert, ist trotzdem das Bonding schuld? Diesen Gedankengang kann ich nicht wirklich nachvollziehen.
Ich bin dann jemand der einfach akzeptiert, dass an dem Setup irgend etwas anders sein muss und teste die Komponenten einzeln und in verschiedenen Kombinationen. Passiert das auch wenn du die andere NIC als Primary machst?

 

[waltar]

Ich bin für das iPhone anders herum halten, funktioniert zudem auch mit jedem Handy anderen Herstellers

 

[TErxleben]

Also wenn etwas mit deiner Hardware nicht wie erwartet funktioniert, aber mit anderer Hardware tausendfach erwartbar reagiert, ist trotzdem das Bonding schuld?

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?

Passiert das auch wenn du die andere NIC als Primary machst?

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

Dann check doch mal warum die NIC erst nach 10 Minuten wieder richtig funktioniert. Eventuell Treiber/Firmware Missmatch?

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

Dann check doch mal warum die NIC erst nach 10 Minuten wieder richtig funktioniert.

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

Ich bin dann jemand der einfach akzeptiert, dass an dem Setup irgend etwas anders sein muss und teste die Komponenten einzeln und in verschiedenen Kombinationen-

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?

Eventuell Treiber/Firmware Missmatch?

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.

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.

 

[TErxleben]

Nun habe ich Hausaufgaben bzgl. der Netzwerkinfrastruktur gemacht. Wie erwartet bleibt das Verhalten auch auf einem einzelnen Miniswitch gleich. Kurzes ziehen der Failoverleitung schaltet sofort wieder auf die Hauptleitung um. Sonst gönnt sich das Bonding bei der Reaktivierung 5-10min Nichterreichbarkeit.

 

[meyergru]

Ich nehme an, dass entweder LLDP im Spiel ist oder die eingesetzten Switches nicht damit klarkommen, wenn die MAC den Port wechselt, ohne dass sich der Link-Status ändert. Es gibt verschiedene Berichte dazu, siehe:

https://packetpushers.net/blog/linux-bonding-lldp-and-mac-flapping/

Es könnte sein, dass "fail_over_mac=follow" hilft. Das geht aber nicht in der /etc/network/interfaces, siehe:

S

Thread 'bonding Fail-over-mac is not passed in the configuration'

Apr 27, 2025

When configuring bonding active-backup via /etc/network/interfaces, the additional parameter bond-fail-over-mac is not applied on the interface. Can you tell me ifupdown2 supports this additional parameter? If not, should we expect an implementation in the future?

pve-manager/8.3.0/c1689ccb1065a83b (running kernel: 6.8.12-4-pve)

auto enp2s0f2
iface enp2s0f2 inet manual

auto enxf8e43b7a6b88
iface enxf8e43b7a6b88 inet manual

auto bond0
iface bond0 inet manual
        bond-slaves enp2s0f2 enxf8e43b7a6b88
        bond-miimon 100
        bond-mode active-backup
        bond-fail-over-mac...

• Sperhead
• bonding pve
• Replies: 1
• Forum: Proxmox VE: Networking and Firewall

So wie es aussieht, müsste man das über Modul-Parameter oder sysfs machen, weil das "pre-up" Kommando erst nach der Anlage des bonds ausgeführt wird und dann kann man es nicht mehr ändern. Ich würde es global im Modul-Parameter setzen.