Show Posts
1
German - Deutsch / Hohe Anzahl Interface Received Errors bei Broadcom-Karten
« on: November 12, 2021, 03:43:18 pm »
Hallo zusammen,
ich habe einige Firewalls von OpenBSD zu OPNsense 21.7 migriert, und habe seitdem das Problem, dass ich auf einigen Interfaces eine hohe Anzahl an received-errors und dropped packets habe. Die received-errors liegen regelmässig über 0.01%, und gehen bis auf 0.8% hoch.
OPNsense läuft bare-metal auf folgender Hardware:
HPE ProLiant DL380 Gen9
Intel Xeon E5-2623 v3 @ 3.00 GHz (4 physische kerne)
16 GB RAM
Netzwerkkarten: 2x Intel 10 GbE-Karten (ix-Treiber) und insgesamt 4x 4-Port GbE Broadcom-Karten (bge-Treiber), davon 10 Interfaces in Benutzung, inklusive VLAN-Trunks.
Das Problem tritt bisher ausschliesslich auf den Broadcom-Karten auf. Der Traffic je Karte kommt nicht einmal annähernd an 1 Gbit/s ran -- die Fehler treten bereits bei rund 100 Mbit/s auf.
Die Firewalls werden via SNMP über Check_MK gemonitored, und man sieht deutlich dass auch die Laufzeiten der restlichen ICMP-Monitor-Pings an andere Hosts, die hinter der Firewall hängen, ebenfalls verlangsamt sind und teils gänzlich verloren gehen.
Die CPU-Auslastung liegt konstant bei um die 50%, teilweise auf bis zu 70%.
Ich habe bereits versucht, CRC Offloading zu aktivieren, was jedoch keinen (spürbaren) Effekt gebracht hat.
Sind euch Probleme mit dem bge-Treiber bekannt? Mir erscheint die CPU-Auslastung zu hoch -- könnte das mit ein Grund für dieses Phänomen sein?
Einen Defekt an den Karten selbst schliesse ich aus, da sie vorher reibungslos funktioniert haben, und das Problem nicht auf eine bestimmte Karte beschränkt ist.
Das Ruleset ist minimal; aktuell nur 9 Floating-Rules im Einsatz. IPv6 ist global deaktiviert.
Mbufs total liegt bei 25k, also weit unterhalb der maximalen 1M, daran sollte es also auch nicht liegen.
Unter System > Diagnostics > Activity fällt mir auch auf, dass ein "[kernel{bgeX taskq}]"-Prozess auf bis zu 100% hoch geht, und bei entsprechendem Traffic auch dort verharrt. Ist das die Last, die der Netzwerkstack bei der Verarbeitung der Pakete verursacht?
Hat jemand eine Idee, wie ich mich dem Problem nähern könnte?
Hier ein Interface als Beispiel:
Herzlichen Dank im Voraus für eure Hilfe
Gruss Alex
ich habe einige Firewalls von OpenBSD zu OPNsense 21.7 migriert, und habe seitdem das Problem, dass ich auf einigen Interfaces eine hohe Anzahl an received-errors und dropped packets habe. Die received-errors liegen regelmässig über 0.01%, und gehen bis auf 0.8% hoch.
OPNsense läuft bare-metal auf folgender Hardware:
HPE ProLiant DL380 Gen9
Intel Xeon E5-2623 v3 @ 3.00 GHz (4 physische kerne)
16 GB RAM
Netzwerkkarten: 2x Intel 10 GbE-Karten (ix-Treiber) und insgesamt 4x 4-Port GbE Broadcom-Karten (bge-Treiber), davon 10 Interfaces in Benutzung, inklusive VLAN-Trunks.
Das Problem tritt bisher ausschliesslich auf den Broadcom-Karten auf. Der Traffic je Karte kommt nicht einmal annähernd an 1 Gbit/s ran -- die Fehler treten bereits bei rund 100 Mbit/s auf.
Die Firewalls werden via SNMP über Check_MK gemonitored, und man sieht deutlich dass auch die Laufzeiten der restlichen ICMP-Monitor-Pings an andere Hosts, die hinter der Firewall hängen, ebenfalls verlangsamt sind und teils gänzlich verloren gehen.
Die CPU-Auslastung liegt konstant bei um die 50%, teilweise auf bis zu 70%.
Ich habe bereits versucht, CRC Offloading zu aktivieren, was jedoch keinen (spürbaren) Effekt gebracht hat.
Sind euch Probleme mit dem bge-Treiber bekannt? Mir erscheint die CPU-Auslastung zu hoch -- könnte das mit ein Grund für dieses Phänomen sein?
Einen Defekt an den Karten selbst schliesse ich aus, da sie vorher reibungslos funktioniert haben, und das Problem nicht auf eine bestimmte Karte beschränkt ist.
Das Ruleset ist minimal; aktuell nur 9 Floating-Rules im Einsatz. IPv6 ist global deaktiviert.
Mbufs total liegt bei 25k, also weit unterhalb der maximalen 1M, daran sollte es also auch nicht liegen.
Unter System > Diagnostics > Activity fällt mir auch auf, dass ein "[kernel{bgeX taskq}]"-Prozess auf bis zu 100% hoch geht, und bei entsprechendem Traffic auch dort verharrt. Ist das die Last, die der Netzwerkstack bei der Verarbeitung der Pakete verursacht?
Hat jemand eine Idee, wie ich mich dem Problem nähern könnte?
Hier ein Interface als Beispiel:
Code: [Select]
[bge8] / 28:80:23:b8:ea:d4
• name : bge8
• flags : 0x8943
• mtu : 1500
• network : <Link#11>
• address : 28:80:23:b8:ea:d4
• received-packets : 522738313
• received-errors : 148022
• dropped-packets : 312
• received-bytes : 193952218025
• sent-packets : 487823124
• send-errors : 0
• sent-bytes : 75553400926
• collisions : 0
Herzlichen Dank im Voraus für eure Hilfe
Gruss Alex
