Error I40E promiscuous mode after update from 9.715 to 9.716

Dirk L Helmut Thomas Gibt es Neuigkeiten / Call Rückmeldungen von Sophos hierzu?

Sophos hat das Update unverändert gepusht und ich habe bei den von mir betreuten Geräten keine Probleme feststellen können.

Guten Morgen,

bei mir wurde das disable TSO Skript, welches in der

/etc/udev/rules.d/20-nic.rules

für bestimmte Karten die den i40e Treiber Nutzen tso deaktivieren soll nicht mehr beim Booten ausgeführt, was dazu führte, das LWL 10GbE Karten Intel X710 welche im lag Verbund konfiguriert sind (4 VLANs / und 3 zusätzliche IPs) unter Last  "Error I40E promiscuous mode" Fehler brachten und damit es zu Drop outs in der Verbindung kam, sogar die HW Überwachung der Server erkannte dies als Lost Link, immer nur kurz aber zum Abbruch mancher Verbindungen reichte es, sehr unerfreulich. Seitdem ich den Schalter manuell auf disable TSO gesetzt habe kam es nicht mehr zu diesem Phänomen.

Einstellungen Anzeigen mit:

ethtool -k ethNN |grep segmen # es sollte hier alles off stehen für die betreffenden Karten

Einstellung verändern mit:

/sbin/ethtool -K ethNN tso off

Ich konnte diesen Effekt der Störung leider nicht auf jedem System aktiv nachvollziehen, aber dass dieses TSO off Skript ab dem Update zu 9.716 nicht mehr funktionierte schon.

Im fallback.log stand nach dem Booten:

udevd-work[2100]: error changing netif name 'ethNN' to 'ethNN': Device or resource busy

Dies weist zwar nur auf den Fehler bei der Umbenennung hin, aber udev konnte wohl gar keine Schalter für die betreffenden eth Interfaces vornehmen, den für die andere folgte:

ethNN: TSO disabled

Es scheint hier einen parallelen Zugriff zu geben, was die Ausführung beim Booten verhindert, oder es liegt an der Gleichsetzung der MAC Adresse aufgrund des LAG Verbundes.

Im Kernel.log stand beim Ausfall dann:

bonding: lag0: link status definitely down for interface ethNN disabling it

gefolgt von:

bonding: lag0: link status definitely up for interface ethNN, 10000 Mbps full duplex.

Gruß

Dirk

Guten Morgen,

bei mir wurde das disable TSO Skript, welches in der

/etc/udev/rules.d/20-nic.rules

für bestimmte Karten die den i40e Treiber Nutzen tso deaktivieren soll nicht mehr beim Booten ausgeführt, was dazu führte, das LWL 10GbE Karten Intel X710 welche im lag Verbund konfiguriert sind (4 VLANs / und 3 zusätzliche IPs) unter Last  "Error I40E promiscuous mode" Fehler brachten und damit es zu Drop outs in der Verbindung kam, sogar die HW Überwachung der Server erkannte dies als Lost Link, immer nur kurz aber zum Abbruch mancher Verbindungen reichte es, sehr unerfreulich. Seitdem ich den Schalter manuell auf disable TSO gesetzt habe kam es nicht mehr zu diesem Phänomen.

Einstellungen Anzeigen mit:

ethtool -k ethNN |grep segmen # es sollte hier alles off stehen für die betreffenden Karten

Einstellung verändern mit:

/sbin/ethtool -K ethNN tso off

Ich konnte diesen Effekt der Störung leider nicht auf jedem System aktiv nachvollziehen, aber dass dieses TSO off Skript ab dem Update zu 9.716 nicht mehr funktionierte schon.

Im fallback.log stand nach dem Booten:

udevd-work[2100]: error changing netif name 'ethNN' to 'ethNN': Device or resource busy

Dies weist zwar nur auf den Fehler bei der Umbenennung hin, aber udev konnte wohl gar keine Schalter für die betreffenden eth Interfaces vornehmen, den für die andere folgte:

ethNN: TSO disabled

Es scheint hier einen parallelen Zugriff zu geben, was die Ausführung beim Booten verhindert, oder es liegt an der Gleichsetzung der MAC Adresse aufgrund des LAG Verbundes.

Im Kernel.log stand beim Ausfall dann:

bonding: lag0: link status definitely down for interface ethNN disabling it

gefolgt von:

bonding: lag0: link status definitely up for interface ethNN, 10000 Mbps full duplex.

Gruß

Dirk

Vielen Dank für das wertvolle Feedback. udev hätte ich jetzt nicht so auf dem Schirm gehabt.

Ich habe hier allerdings nur kleinere Systeme (zwischen 125 und 330) aber teilweise auch in HA und LAG/LACP-Trunks zu den vorgelagerten Switchen. Beim Greppen der letzten Bootlogs habe ich bisher keine udev-Fehlermeldung gefunden.

Tolle Analyse, hoffentlich sieht Sophos das!
Ist das nun also ein generelles Problem bei der Verwendung von LACP in Verbindung mit VLANs auf 10GB Interfacen oder passiert das auch auf 1GB Ports?

https://support.sophos.com/support/s/article/KB-000043856?language=en_US 

Danke Alan, aber es sind nur 4 VLANs an der eine Karte (siehe Text) und 1 VLAN an der anderen und der Fehler ist "I40E_AQ_RC_EINVAL" und nicht der in dem KB Artikel genannte.