Thread Info
  • State Not Answered
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 27 replies
  • Subscribers 9 subscribers
  • Views 5721 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Error I40E promiscuous mode after update from 9.715 to 9.716

Helmut Thomas

Nach dem Update von 9.715 auf die 9.716 erhalten wir diese Fehlermeldung im kernel.log:

i40e 0000:08:00.2: Error I40E_AQ_RC_EINVAL adding RX filters on PF, promiscuous mode forced on

Nach kurzer Zeit bricht dann irgendwann die komplette Verbindung der 10G Interfaces zusammen.

Abhilfe brachte bisher nur das Downgrade auf die 9.715.

Sonst noch jemand mit dem gleichen Fehler?



This thread was automatically locked due to age.
Parents
  • 0

      Gibt es Neuigkeiten / Call Rückmeldungen von Sophos hierzu?

  • 0 in reply to Albeck

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

  • 0 in reply to Alan Brand

    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

  • 0 in reply to Dirk L

    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.

  • 0 in reply to Dirk L

    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?

  • 0 in reply to Alan Brand

    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.

Reply Children
No Data
Unfiltered HTML