5
PfSense igb Hohe Latenz Paketverlust
Hallo,
seitdem ich gestern nun auf pfSense 2.5.1 geupgraded habe, überhäufen mich hier Probleme die ich noch nie hatte. Mit dieser Version hat mit Netgate definitiv keinen gefallen getan.
Folgendes Problem: Über mehrere Stunden habe ich keine Probleme feststellen können. Aus heiterem Himmel brach heute die WAN-Schnittstelle zusammen. Dann wollte ich an den Schnittstellen, wegen aufkommenden Paketloss, das EEE deaktiveren. Da dies in Vergangenheit zu Problemen geführt hat und hier wieder das selbe Fehlerbild auftrat.
Also:
konfiguriert.
Es lief erstmal für eine halbe Stunde weiter. Danach plötzlich Disconnect. Nach mehrmaligen Neustarts der Schnittstellen, konnte ich wieder rauspingen, aber mit grottigen Latenzen (teilweise mit über 500ms) und Paketloss von 40%.
Beim pingen kam auf der VGA-Ausgabe der pfSense folgende Fehler:
Wie dieser zustande kommt, ist mir schleierhaft. Die Info dieser Meldung mehr als mager... ich kann hier nur mutmaßen da es sich um die angepingte Gegenstelle gehandelt haben muss. Mit diesen Werten konnte man nicht mehr arbeiten, also einen kompletten Reboot gemacht. Danach performt diese wieder normal.
Aber wo liegt jetzt das Problem? Woher kommt dieses Verhalten? Hat jemand sowas ähnliches gehabt?
Zu meinen Tweaks für die Netzwerkkarten, die ich schon ewig verwende:
In der loader.conf gesetzt...
Hardware TCP Sementation und Hardware Large Receive Offloading deaktiviert. Netzwerkkarten Geschwindigkeit auf default. Ansonsten nichts weiter.
Upgrade verlief folgendermaßen:
Was mir auffällt, aber nicht glaube das es das Problem ist, seit dem Upgrade ist unter System > Advanced > Networking der "hn ALTQ support" aktiviert. Aber wenn ich das richtig verstehe ist das nur für hn-Interfaces relevant.
Es läuft zwar jetzt, aber ich glaube das hier noch irgendwo ein Problem gibt und es nur eine Frage der Zeit ist bis das oben beschriebene Verhalten wieder auftritt. Hat irgendjemand eine Idee wo hier das Problem liegt?
Gruß
seitdem ich gestern nun auf pfSense 2.5.1 geupgraded habe, überhäufen mich hier Probleme die ich noch nie hatte. Mit dieser Version hat mit Netgate definitiv keinen gefallen getan.
Folgendes Problem: Über mehrere Stunden habe ich keine Probleme feststellen können. Aus heiterem Himmel brach heute die WAN-Schnittstelle zusammen. Dann wollte ich an den Schnittstellen, wegen aufkommenden Paketloss, das EEE deaktiveren. Da dies in Vergangenheit zu Problemen geführt hat und hier wieder das selbe Fehlerbild auftrat.
Also:
sysctl dev.igb.0.eee_control=0konfiguriert.
Es lief erstmal für eine halbe Stunde weiter. Danach plötzlich Disconnect. Nach mehrmaligen Neustarts der Schnittstellen, konnte ich wieder rauspingen, aber mit grottigen Latenzen (teilweise mit über 500ms) und Paketloss von 40%.
Beim pingen kam auf der VGA-Ausgabe der pfSense folgende Fehler:
arprequest: cannot find matching addressWie dieser zustande kommt, ist mir schleierhaft. Die Info dieser Meldung mehr als mager... ich kann hier nur mutmaßen da es sich um die angepingte Gegenstelle gehandelt haben muss. Mit diesen Werten konnte man nicht mehr arbeiten, also einen kompletten Reboot gemacht. Danach performt diese wieder normal.
Aber wo liegt jetzt das Problem? Woher kommt dieses Verhalten? Hat jemand sowas ähnliches gehabt?
Zu meinen Tweaks für die Netzwerkkarten, die ich schon ewig verwende:
In der loader.conf gesetzt...
kern.ipc.nmbclusters="1000000" Hardware TCP Sementation und Hardware Large Receive Offloading deaktiviert. Netzwerkkarten Geschwindigkeit auf default. Ansonsten nichts weiter.
Upgrade verlief folgendermaßen:
- Festplatte formartiert
- pfSense installiert
- dann gesicherte Config.XML eingespielt
- Reboot
Was mir auffällt, aber nicht glaube das es das Problem ist, seit dem Upgrade ist unter System > Advanced > Networking der "hn ALTQ support" aktiviert. Aber wenn ich das richtig verstehe ist das nur für hn-Interfaces relevant.
Es läuft zwar jetzt, aber ich glaube das hier noch irgendwo ein Problem gibt und es nur eine Frage der Zeit ist bis das oben beschriebene Verhalten wieder auftritt. Hat irgendjemand eine Idee wo hier das Problem liegt?
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 806343718
Url: https://administrator.de/contentid/806343718
Ausgedruckt am: 24.11.2024 um 04:11 Uhr
5 Kommentare
Neuester Kommentar
Ok. Es gibt definitiv ein Treiber-Problem.
Wenn ich in den Tunables oder per Sysctl "eee_disabled" für ein igb-Interface mache, dann fallen die Schnittstellen nach paar Minuten aus. Im syslog steht dann:
Danach geht alles den Bach runter. Nur...
konnte helfen. Danach funktioniert alles wieder wie gewohnt.
"Monitor Gateway Action" habe ich jetzt mal im Routing > Gateways deaktiviert. Das startet mir zuviele Prozesse neu und verhindert das diese sauber geladen werden.
Aber jetzt kommt der dicke Hammer: Ich habe dann mal pauschal nur an einer von beiden NIC das EEE deaktiviert, es wirkt sich aber dennoch auf die zweite Schnittstelle ebenfalls aus. Wenn ich nun beide wieder deaktiviere und aktiviere, funktionieren sie wieder sauber und haben sogar die Option "eee_control=0" übernommen. Somit muss man tatsächlich die Tunables eintragen und pauschal alle Schnittstellen des Controllers neustarten.
Bei pfSense 2.4.5p1 mit FreeBSD11 gab es solch ein fatales Verhalten nicht, beim setzen einer Schnittstellen-Option. Unglaublich.
pfSense fällt mir dieser Tage sehr negativ auf. Seitdem da ein harter Kommerz-Kurs gefahren wird, scheint es den Bach herunter zu gehen. Wird wohl Zeit das ich mich intensiver mit den Unterschieden zu OPNsense befasse und ggf. wechsele.
Wenn ich in den Tunables oder per Sysctl "eee_disabled" für ein igb-Interface mache, dann fallen die Schnittstellen nach paar Minuten aus. Im syslog steht dann:
pfSense kernel: arpresolve: can't allocate llinfo for 136.20.110.22 on igb0 Danach geht alles den Bach runter. Nur...
ifconfig igb0 down
ifconfig igb0 upkonnte helfen. Danach funktioniert alles wieder wie gewohnt.
"Monitor Gateway Action" habe ich jetzt mal im Routing > Gateways deaktiviert. Das startet mir zuviele Prozesse neu und verhindert das diese sauber geladen werden.
Aber jetzt kommt der dicke Hammer: Ich habe dann mal pauschal nur an einer von beiden NIC das EEE deaktiviert, es wirkt sich aber dennoch auf die zweite Schnittstelle ebenfalls aus. Wenn ich nun beide wieder deaktiviere und aktiviere, funktionieren sie wieder sauber und haben sogar die Option "eee_control=0" übernommen. Somit muss man tatsächlich die Tunables eintragen und pauschal alle Schnittstellen des Controllers neustarten.
Bei pfSense 2.4.5p1 mit FreeBSD11 gab es solch ein fatales Verhalten nicht, beim setzen einer Schnittstellen-Option. Unglaublich.
pfSense fällt mir dieser Tage sehr negativ auf. Seitdem da ein harter Kommerz-Kurs gefahren wird, scheint es den Bach herunter zu gehen. Wird wohl Zeit das ich mich intensiver mit den Unterschieden zu OPNsense befasse und ggf. wechsele.
Zitat von @Fenris14:
Upgrade verlief folgendermaßen:
Upgrade verlief folgendermaßen:
- Festplatte formartiert
- pfSense installiert
- dann gesicherte Config.XML eingespielt
- Reboot
Hallo.
Die gesicherte Config stammt aus ebenfalls einer 2.5.x Version oder aus einer 2.4.x Version?
Es kann durchaus sein, dass die Config Inhalte mit der neueren Version nicht ganz kompatibel sind.
Besser die Config neu machen, wenn du mit einem frisch installierten System arbeitest.
Sonst installiere die Version, die auch der gesicherten Config entspricht. Dann kannst du ein Inplace-Upgrade durchführen.
Bei mir hat das Upgrade ein paar IPSec Tunnel defekt hinterlassen.
Gruß
Marc
Die Config war von 2.4.5p1. Die frische Installation hatte ich nach einem vorherigen Downgrade gemacht. Ich bin erst ganz normal per Update auf 2.5.1... dann als ich gesehen habe, das es nur Probleme gibt, wieder zurück auf 2.4.5p1. Das Downgrade hatte dann aber ebenfalls nur noch Probleme gemacht, obwohl passende Config. Dann alles frisch installiert, nachdem ich ein Workaround gefunden hatte um zumindest meine OpenVPN-Problematik zu beheben.
Nicht nur das. Auch gehen derzeit keine PortForwards bei Multi-Wan, die gehen nur bei der Schnittstelle mit dem default-Gateway. Wohlgemerkt bei einem "stable"-Release. Da ist gar nichts "stable". So eine einfach Sache, die schon seit Jahren funktioniert, geht plötzlich nicht mehr. Deshalb setze ich gerade eine zweite Firewall, diesmal OPNsense auf, um dort dran meine PBX zu betreiben. Bisher entpuppt sich 2.5.1 als reinste Katastrophe. Keine Ahnung was sich Netgate da gedacht hat. Vermutlich will man damit den Verkauf von Plus ankurbeln.
Traurige Entwicklung.
Nicht nur das. Auch gehen derzeit keine PortForwards bei Multi-Wan, die gehen nur bei der Schnittstelle mit dem default-Gateway. Wohlgemerkt bei einem "stable"-Release. Da ist gar nichts "stable". So eine einfach Sache, die schon seit Jahren funktioniert, geht plötzlich nicht mehr. Deshalb setze ich gerade eine zweite Firewall, diesmal OPNsense auf, um dort dran meine PBX zu betreiben. Bisher entpuppt sich 2.5.1 als reinste Katastrophe. Keine Ahnung was sich Netgate da gedacht hat. Vermutlich will man damit den Verkauf von Plus ankurbeln.
Traurige Entwicklung.
Auf welcher Hardware läuft die pfSense? Ich hatte ähnliche Probleme mit einer APU2 nach einem Upgrade von 2.4.5 auf 2.5.0.
In meinem Fall wurde der Paketverlust durch die Einstellung net.isr.dispatch=deferred verursacht. Solltest du weitere Tweaks verwenden, würde ich empfehlen sie erstmal zu entfernen und zu beobachten, ob eine Besserung auftritt.
Unabhängig davon soll bald Version 2.5.2 veröffentlicht werden. An deiner Stelle würde ich 2.5.1 überspringen.
In meinem Fall wurde der Paketverlust durch die Einstellung net.isr.dispatch=deferred verursacht. Solltest du weitere Tweaks verwenden, würde ich empfehlen sie erstmal zu entfernen und zu beobachten, ob eine Besserung auftritt.
Unabhängig davon soll bald Version 2.5.2 veröffentlicht werden. An deiner Stelle würde ich 2.5.1 überspringen.
Bin schon auf 2.5.1... läuft alles auf einem Supermicro X11SDV-4C-TP8F. Ich warte jetzt auf 2.5.2 und schaue mir das dann erstmal an.
2.5.0 wollte ich auch nicht mehr einsetzen, wegen OpenSSL-Bug. Dieser ist widerum in 2.5.1 behoben. Für den zweiten WAN-Anschluss über den unsere PBX läuft, hält nun eine OPNsense auf einem alten Atom-Board her. EInrichtung in unter 5 Minuten, läuft ohne Probleme.
Aber ehrlich gesagt: Keine Ahnung ob die den Job generell besser macht, oder ob es da andere oder ähnlich schwerwiegende Probleme gibt. In diesem Minimal-Einsatz kann sich OPNsense jetzt mal zumindest bewähren.
2.5.0 wollte ich auch nicht mehr einsetzen, wegen OpenSSL-Bug. Dieser ist widerum in 2.5.1 behoben. Für den zweiten WAN-Anschluss über den unsere PBX läuft, hält nun eine OPNsense auf einem alten Atom-Board her. EInrichtung in unter 5 Minuten, läuft ohne Probleme.
Aber ehrlich gesagt: Keine Ahnung ob die den Job generell besser macht, oder ob es da andere oder ähnlich schwerwiegende Probleme gibt. In diesem Minimal-Einsatz kann sich OPNsense jetzt mal zumindest bewähren.
