Error I40E promiscuous mode after update from 9.715 to 9.716

Welche Hardware?

Ich habe hier sowohl auf einer SG230 mit 10G-FlexiPort-Modul als auch einer SG330 mit integrierten 10G-Interfaces nachgesehen und keine derartigen Meldungen gefunden. Allerdings wird die 10G-Hardware mit Intel 82599ES und nicht i40E (ist das das 4-Port-Modul?) angegeben.

Richtig, bei mir ist das 4-Port Modul (4x 10 GbE SFP+ FleXi Portmodul -SGIZTCHF4) an einem SG430-Cluster im Einsatz.

Noch als Ergänzung: Wir nutzen Cisco ASF-10G-T SFP-Module.

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

@ DirkL: Ich kann dir nicht privat antworten, vermutlich in deinen Einstellungen nicht erlaubt. Call ist bei Sophos direkt gemacht.

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

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.

Hey Helmut Thomas ,

Vielen Dank, dass Sie sich an die Community gewandt haben. Können Sie bitte die folgende Ausgabe der Schnittstelle teilen: ethtool -k <interface><Portno>
Beispiel: ethtool -k eth0