Einfacher Netzwerk Bond (active backup) verursacht bis zu 30% Paketverlust

[fireon]

Hallo Leute,

mir ist hier bei meinem Cluster in den letzten zwei Wochen ein recht seltsames Verhalten aufgefallen. Hier mal Details zur Node die das verursacht:

• HP ML350G10
• 4x Nic Gigabit on Board (Intel X722 / 369i)
• 1x 10Gbit PCIe (Intel X540)
• pve-manager/8.2.7/3e0176e6bb2ade3b (running kernel: 6.8.12-2-pve)

Fakt ist wenn man einen "active backup" bond erstellt, egal mit welchen Interfaces, bekommt man einen durchschnittlichen Paketverlust von 30% innerhalb von ca. 15 Minuten. Diesen Verlust bekommt man aber ausschließlich wenn man direkt auf dem Host zugreift. Z.B. auf der Konsole über SSH (friert immer wieder ein), oder auch wenn man dem Server über das Webinterfaces auswählt und VM Konfigurationen bearbeitet. Was meiner Meinung nach völlig strange ist das die VM's davon nicht betroffen sind.

Ethtool spuckt das über die NIC aus:

driver: i40e
version: 6.8.12-2-pve
firmware-version: 4.11 0x8000218f 1.3612.0
expansion-rom-version:
bus-info: 0000:3a:00.2
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes

Dies ist die aktuelle Firmware für den Adapter von HP. Hier ist diese Nummer 1.3612.0 gültig. Was neueres gibt es da nicht. Ansonsten wurde auch die gesamte Firmware des Server aktualisiert. Ältere Kernel wurde auch getestet.

Jedes NIC für sich alleine funktioniert auch. Aber sobald ein Bond erstellt wird, hat man Paketverluste. Ich hab noch 3 andere Server in dem Cluster. 2 davon sind vom Hersteller Supermicro und sind grundsätzlich gleich konfiguriert wie die HP-Maschine. Haben aber on board andere Intel NICs (I210). Dort funktioniert es schon seit Monaten ganz normal.

Bei der HP-Maschine habe ich durch Kabeltausch nun auch ein zweites NIC angeschlossen, einfach zur Ausfallsicherheit. Sonst wär mir das nicht aufgefallen.
Ich habe zum Test noch einen zweiten anderen HP ML350 G10 getestet. Auch diese Maschine legt das exakt gleiche Verhalten an den Tag.

Außer eine andere Gigabitkarte verbauen fällt mir ehrlich gesagt keine Lösung mehr ein. Konnte denn außer mir sonst noch jemand so ein Verhalten beobachten?
Vielen Dank

 

[Christian D.]

Dieses Verhalten klingt eher nach Switch. Ist dieser den auch korrekt konfiguriert?

 

[fireon]

Dieses Verhalten klingt eher nach Switch. Ist dieser den auch korrekt konfiguriert?

Hab ich mir auch schon gedacht. Die Ports sind für alle Server gleich konfiguriert, hatte auch schon Ports gewechselt. Sind nur VLAN's drauf konfiguriert. Ein Bond ist am Switch nicht konfiguriert, da den Bond ja das "active-backup" am Server macht.

 

[Falk R.]

HI, mit den Intel 7xx Netzwerkkarten hatte ich unter ESXi auch schon extreme Probleme. z.B. bei iSCSI ständige reconnects, also kein arbeiten möglich.
Für VMware gibts auch einen KB Artikel. Eventuell versuchst du auch mal die Features der NIC wie da beschrieben zu deaktivieren.
https://knowledge.broadcom.com/external/article?legacyId=2126909

 

[cwt]

Falls Du VLANs im bond nutzt, probier testweise das offloading zu deaktivieren:

/sbin/ethtool -K bond0 rxvlan off
/sbin/ethtool -K bond0 rx-vlan-offload off

Sollte das den Fehler beseitigen, kannst Du den Eintrag in /etc/network/interfaces als post-up für den bond permanent setzen.

 

[fireon]

@Falk R. und @cwt

Danke euch beiden für eure Antworten, brachte hier leider keine Veränderung. Mir ist dann nochmal der Part in der Anleitung Proxmox Upgrade von 6 auf 7 eingefallen wo die Macadresse bei der Bridge manuell gesetzt werden konnte. Das hab ich also gemacht und die MAC des primären Interfaces dort eingetragen.

...
iface vmbr0 inet static
        address 192.168.1.77/24
        gateway 192.168.1.1
        hwaddress 9A:B6:85:00:AC:CF
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
...

Und damit sind die Paketverluste weg. Ich hab dann die MAC zum Test auch wieder gelöscht und schon waren wieder jede Menge packetloss am Interface. Auch das Verhalten des Bond ist normal (Kabel abziehen/prüfen...).
Ich find das Verhalten schon sehr seltsam. Hatte ich noch nie.

 

[Falk R.]

Was passiert denn wenn du eine eigene MAC generierst und die der Bridge gibst? Das Phänomen klingt ja nach den Problemen die ich bei Windows Clustern habe. Da bekommt bei mir das Teaming Interface immer eine eigene MAC.

 

[fireon]

Was passiert denn wenn du eine eigene MAC generierst und die der Bridge gibst? Das Phänomen klingt ja nach den Problemen die ich bei Windows Clustern habe. Da bekommt bei mir das Teaming Interface immer eine eigene MAC.

Auch mit einer zufällig generierten MAC funktioniert es. Anscheinend muss nur eine vorhanden sein in der Config. Seltsamerweise wird (wenn man keine MAC einträgt) immer die MAC vom sekundären Interfaces verwendet. Bei allen anderen Servern ist das nicht so, da wird immer die vom primären Interface verwendet. Ist ja auch strange.