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

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
  • Hallo zusammen,

    ja, wir haben genau dasselbe Phänomen. Wir haben zwei lag Verbindungen a 2 Ports konfiguriert und diese sind auf jeweils 2 verschiedenen Intel X710 10GbE Karten (rev01 / rev02) konfiguriert, welche an verschiedenen Switchen von Cisco terminiert sind und erhalten ab ca. 5 Stunden nachdem Update auch folgende Meldungen:

    Error I40E_AQ_RC_EINVAL adding RX filters on PF, promiscuous mode forced on

    Dies führt manchmal dazu, dass völlig sporadisch die Verbindung komplett abbricht, da keiner der lag Ports mehr als on gilt. Dies wird dann sogar von den Server Manage Karte der Hardware (nicht Sophos) gemeldet.

    Ich vermute sogar, dass es am WE dazu führte, dass mein SG550 HA Cluster kaputtging, da diese denselben NIC Chip haben, denn irrtümlicherweise wurde die noch nicht aktualisierte Node zur Primary gemacht, weil die UTM wohl dachte es stehe keine Verbindung an einer NIC zur Verfügung, leider kann ich das in den Logfiles nicht genau so nachvollziehen wie auf den Software UTM Installationen.

    Vor dem Update gab es keine derartigen Meldungen/Abbrüche, was mich nur verwundert, es wurde weder der Kernel, also somit auch nicht der Treiber der NICs getauscht, es muss also eine andere Funktion sein, die die Intel Karten stört.

    Gruß Dirk

  • Hallo Dirk,

    so ist es. Die NICs schalten in promiscuous mode und sind dann irgendwann überlastet und quasi nicht mehr betriebsbereit. Der Effekt ist bei uns erst 3 Stunden nach dem Update das erste Mal aufgetreten. Daher ist es mir auch zu spät aufgefallen und am Montag ist bei uns alles zusammengebrochen, da der SG Cluster auch unser primärer Router ist. Ich musste auf die 9.715 zurück wechseln. Seit Mittwoch habe ich einen Case bei Sophos offen. Ich habe die ganze Historie und die Logfiles hochgeladen. Nun ist alles  "under investigation". Ich warte auf Rückmeldung von Sophos in spätestens 2 Tagen.
    Danke für die Rückmeldung. Es ist etwas beruhigend, dass ich nicht der Einzige bin der noch UTM einsetzt und das Problem hat ;-)

    Gruß

    Helmut

  • Hallo,

    gibt es hier ein Update zu dem Problem? Auf kleineren Umgebungen (ohne 10G-Ports) konnte ich bisher keine Fehler fest stellen...

    Bei größeren Umgebungen mit 10GB-Flexi-Ports möchte ich ungern zurück flashen müssen...

    Gruß Steve

Reply Children
No Data