PfSense RX Error auf WAN

Mitglied: Fenris14

Fenris14 (Level 2) - Jetzt verbinden

04.03.2021, aktualisiert 13:52 Uhr, 534 Aufrufe, 14 Kommentare

Hallo,

seit ein bis zwei Wochen einem Problem auf der Spur, das noch länger zu bestehen scheint, aber ich mit meiner Fehlersuche nicht mehr weiter komme:

Die letzten Tage wurde es besonders schlimm, auf der WAN-Schnittstelle passierten immer wieder RX Errors. Es gehen also eingehend immer wieder Pakete verloren.

auswahl_054 - Klicke auf das Bild, um es zu vergrößern

Ich hatte natürlich als erstes die Schnittstellen der pfSense-Kiste im Verdacht. Es handelt sich um ein Board von Supermicro (X11SDV-4C-TP8F), die 1Gbit- Schnittstellen werden von einem Intel I350-AM4 Controller gesteuert und intern als igb erkannt. Firmware ist aktuell. pfSense Version ist 2.4.5-p1. Aber selbst ein Wechsel der NIC brachte nichts und außerdem wären dann dort nicht auch ausgehend Paket-Verlust aufgetreten?

Ich habe das bestehende Problem erst relativ spät mitbekommen, weil ansich alles ohne Probleme lief und auch die Anwender nichts meldeten, nur in den letzten Tagen häuften sich dann wohl die Paket-Verluste. Das es aber schon mehrere Wochen bestehen muss, zeigt dieses Bild:

auswahl_053 - Klicke auf das Bild, um es zu vergrößern

Das ist die Aufzeichnung der Paketverluste per SNMP. Das Problem scheint nicht immer in der gleichen Intensität vorzuliegen und stark zu variieren. In der Woche 53 von 2020 wurde dieses Logging erst gestartet. Deshalb ist davor nichts vermerkt.

Der Provider (lokaler Anbieter) sieht selbst keine Fehler auf seiner Leitung und meint die Werte wären "hervorragend". Die Box oder das Modem, in Wirklichkeit nur ein LWL-Medienconverter (Genexis Hybrid FTTH Gateway), habe ich schon neugestartet und die Patchkabel getauscht. Es sind dadurch vorerst gefühlt weniger Fehler, ob es tatsächlich so ist wird das Logging mit der Zeit zeigen.

Aber gäbe es noch eine andere Möglichkeit solch einem Problem auf die Schliche zu kommen? Um wirklich zweifelsfrei zu lokalisieren wo das Problem liegt?

Wäre sehr dankbar für paar Tipps.

Gruß
Mitglied: aqui
04.03.2021, aktualisiert um 16:56 Uhr
Das Problem scheint nicht immer in der gleichen Intensität vorzuliegen und stark zu variieren.
Riecht etwas nach einem Autonegotiation Problem, denn diese zeigen oft so ein Verhalten besonders wenn der Duplex Mode nicht richtig ausgehandelt wurde. Mit steigendem Traffic steigen dann auch die Fehler.
Bei einem Duplex Mismatch sind das in erster Linie aber immer Collisions die hier primär ja nicht zu sehen sind.
Trotzdem macht es ggf. Sinn mal einen doofen L2 Switch zw. der FW und dem Übergabepunkt zu hängen um zu sehen ob das ggf. verschwindet. Wenn ja, wäre es dann ein Indiz für ein Autonegotiation Problem.
Sinnvoll wäre es auch einmal die Genexis Hybrid FTTH Gateway Box zu tauschen. Der Fehler muss ja nicht zwingend auf deiner Seite sein...
Alternativ bei Glasfaser wäre es spannend den Provider mal zu fragen ob das durchgängig ist. Es gibt Szenarien wo Provider auf Zwischenlinks gebündelte xDSL Leitungen nutzen wenn sie eine Versorgungslücke schliessen müssen. Dann gibt es aber einen Bruch in der MTU wegen der xDSL Encapsulation und zu grosse Frames machen dann Probleme. Allerdings so das die dann gedropt werden und eher keine Error Counter hochzählen. Das wäre dann eher nicht das Problem aber könnte man mit einer Verkleinerung der MTU am WAN Port fixen.

Interessant wäre es auch einmal die Interface Statistiken aus der Genexis Hybrid FTTH Gateway sehen zu können ob die Errors denen deiner Seite entsprechen, was sie eigentlich sollten.
Wichtig wäre auch zu wissen was genau den Error Counter triggert ob das nicht nur Ethernet Runts oder Giant Frames sind und nicht auch welche mit VLAN ID Tag z.B. die das Interface nicht lesen kann was dann wieder Fragen der Provider Konfig am Übergabepunkt aufwirft.
Bitte warten ..
Mitglied: Fenris14
05.03.2021 um 10:28 Uhr
Habe jetzt nochmal weiter gegraben:

Die Statistiken zeigen das es wirklich nur unter Last passiert. In der Nacht, wo wenig los ist, kein einziger dokumentierter Fehler. An den meisten Tagen gehen die Fehler ab etwa 16-17 Uhr zurück. Gearbeitet wird aber bis etwa 22 Uhr.

Beispiel:

auswahl_061 - Klicke auf das Bild, um es zu vergrößern

Unter "Last" ist auch relativ zu sehen. Der Traffic hält sich auf der WAN-Seite in Grenzen. Die bestellte Geschwindigkeit der LWL-Anbindung ist 100/100Mbit. Bei normalen Betrieb wird die Bandbreite über den Tag vielleicht zu 30-40% ausgenutzt.

Interessant wäre es auch einmal die Interface Statistiken aus der Genexis Hybrid FTTH Gateway sehen zu können ob die Errors denen deiner Seite entsprechen, was sie eigentlich sollten.

Da komme ich leider nicht drauf und muss mich da auf die Aussagen des Providers verlassen. Dieser sagt, das keine Fehler drauf sind.

Wichtig wäre auch zu wissen was genau den Error Counter triggert ob das nicht nur Ethernet Runts oder Giant Frames sind und nicht auch welche mit VLAN ID Tag z.B. die das Interface nicht lesen kann was dann wieder Fragen der Provider Konfig am Übergabepunkt aufwirft.

Dazu habe ich folgendes auf der pfsense per sysctl gefunden:


Es scheint sich also doch direkt um CRC-Fehler zu handeln.

Den Trick mit dem kleinen Switch (Cisco SG110) dazwischen hatte ich ebenfalls schon vor paar Wochen probiert, der war scheinbar gänzlich mit der Situation überfordert. Die Fehler nahmen zu und die LEDs an den Ports haben sich gar nicht mehr einbekommen, trotz relativ wenig Traffic. Für mich meist ein Zeichen, das hier irgendwas nicht stimmt.
Bitte warten ..
Mitglied: aqui
05.03.2021, aktualisiert um 10:49 Uhr
Dieser sagt, das keine Fehler drauf sind.
Darauf solltest du dich natürlich nie verlassen. Bitte ihn darum einen Screenshot der Port Statistiken zu schicken und zwar mit einer Laufzeit Info. Nicht das er vorher die Statistiken löscht. Kannst du aber ja auch an der Menge sehen die mit deinen Paket und Trafficzahlen korrelieren sollte.
Übliches Verhalten von Providern das sie erstmal alles abwimmeln auf die Kunden. Im Rahmen eures Vertrages haben die aber die Pflicht zur Auskunft.
CRC Fehler sind Checksummen Fehler könnte was mit der Negotiation zu tun haben. Verdächtig ist die Lastabhängigkeit was dafür sprechen würde.
Der Test mit dem Zwischenswitch ist also deshalb sehr wichtig. Das der scheinbar auch nicht richtig Auto negotiaten konnte erhärtet zudem den Verdacht.
Vielleicht hast du irgendwo noch einen ungemanagten 100Mbit China 5 Port Plasteswitch in der Schublade. Die eigenen sich ganz gut dafür. Ein managebarer wäre aber erheblich besser weil du an dem wieder sowohl den Provider Port als auch deinen FW Port in den Port Statistiken genau beobachten kannst.
Dein Verdacht ist schon richtig wenn schon bei sehr geringen Trafficraten sowas passiert. 50% Last auf dem Port sollten niemals die Fehlercounter hochzählen lassen. Eine geringe Menge ist Prinzip bedingt zwar normal im Ethernet aber niemals in der Größenordnung wie bei dir.
https://www.cisco.com/en/US/docs/internetworking/troubleshooting/guide/t ...
Bitte warten ..
Mitglied: Fenris14
05.03.2021 um 14:38 Uhr
Also der Techniker den ich am Telefon hatte, wollte nur eine mündliche Aussage machen. Er meinte: Gestern ab 14 Uhr das Protokoll gestartet und über Nacht etwas über 60000 Pakete protokolliert, von denen etwa 200 nicht durchgingen. Was sich in etwa mit meinen Werten deckt. Er sagte das sei völlig in Ordnung und unter 1%.

Da war ich gegenteiliger Meinung: Wenn das ein Wert von einer Woche gewesen wäre, dann hätte ich gesagt OK. Aber nicht bei weniger als 20 Stunden. Auf eine Woche hoch gerechnet sind das immerhin 1680 Pakete, eher weit über 2000 wenn ich die hohe Varianz mit einbeziehe. die hier scheinbar spurlos verschwinden. Da reichen schon paar wenige verlorene Fehler, das eine VPN-Verbindung abreißt und sich der User zu Recht beschwert.

Aber, ich glaube einen schuldigen gefunden zu haben: EEE oder auch "Green Ethernet".

Was auch sonst. Durch Zufall drauf gestoßen. Man kann es direkt auf der CLI pro NIC deaktivieren:


Das von allen beteiligten Netzwerkschnittstellen unterstützt werden muss. Da ich bei der Genexis Brotdose nicht damit rechne, sollte ich das vielleicht deaktivieren.

Will man es Reboot-fest haben, dann unter "System > Advanced > System Tunables" einen neuen Eintrag erzeugen. Seit etwa drei Stunden kein Fehler. Gestern im selben Zeitraum hatte ich schon mindestens 80 verlorene Pakete. Ich freue mich mal noch nicht zu früh, aber vorerst sieht es gut aus, gefühlt auch Performance besser geworden.

Aber die Zeit wird es zeigen.
Bitte warten ..
Mitglied: aqui
05.03.2021 um 19:48 Uhr
👍 Hört sich gut an !
Das wäre mal spannend wie der Counter nach einer Woche aussieht ! Feedback wäre mal interessant.
Was sehr verwunderlich ist ist die Tatsache das diese Feature auf einer Firewall aktiviert ist ?! Eigentlich völliger Unsinn bei einem Device was always on sein muss. EEE für Router oder Firewall ist generell eigentlich netztechnischer Unsinn.
Bitte warten ..
Mitglied: Fenris14
05.03.2021 um 23:21 Uhr
Das musste mal Netgate/pfSense-Leute fragen: Die haben es in über zwei Jahren nicht hinbekommen aktuelle Treiber z.B. für ixl (X710/Intel Xeon D-2100) zu implementieren. Die meisten 10Gbit-Schnittstellen die man zum Beispiel im LAGG laufen lassen wöllte, würden nicht funktioneren. Im normalen Betrieb kann es zu einer Kernel Panic kommen. Die darf man sich dann selbst kompilieren.

Ich weiß nicht ob die es mal hinbekommen haben, das in in 2.5 zu fixen. Bin da noch skeptisch. Privat habe ich jedenfalls schon mal festgestellt, das in 2.5 die Registrierung von DHCP im DNS Resolver nicht funktioniert. Bin mal gespannt wie das in Zuknuft mit dem neuen Pfsense Plus und Community laufen wird. Wird wohl so werden, das ich zu OPNsense wechsel. Schade drum.

Warum soetwas standardmäßig aktiviert ist und man sich erst durch diverse pfSense-Foren/Intel-Dokus schlängeln darf, ist mir darüber hinaus auch völlig schleierhaft.
Bitte warten ..
Mitglied: Fenris14
09.03.2021 um 10:02 Uhr
Für mich hat es sich bestätigt. Es ist definitiv so das hier EEE oder 802.3az Probleme gemacht hat. Entweder ist es am FTTH Gateway deaktiviert, fehlerhaft oder nicht implementiert. Seit fast 4 Tagen kein einziger Fehler. Im gleichen Zeitraum eine Woche vorher, sah es schon sehr düster aus.

Nun erklärt sich auch warum mein SG110 solche Probleme gemacht hat: Bei dem ist dauerhaft standardmäßig EEE aktiv. Der ist unmanaged, da kann man auch nichts konfigurieren.

pfSense kann man eigentlich nur vorwerfen, das diese veraltete Treiber verwenden und für Optimierung von NIC nur wenig dokumentiert haben. Ein Button oder ein Profil mit der Einstellung oder irgendeinen Hinweis das man das deaktivieren kann oder es zu Problemen führen könnte, hätte ich mir schon gewünscht. Ob man es dann aktiviert ist dann die Sache des Anwenders. Ansich ist das EEE ja im Inter-Treiber implementiert.

Lustigerweise ist mir bei anderen Standorten solche Probleme nie untergekommen, da verwende ich unter anderem Debian mit iptables als Firewall und da sind teilweise die selben Treiber im Einsatz. Da sind dann meist auch etwas bessere Modems oder Router vorgeschalten, aber wenn es dort ebenfalls EEE inaktiv ist, müsste es ja zu ähnlichen Problemen kommen. Bisher aber nichts.
Bitte warten ..
Mitglied: aqui
09.03.2021, aktualisiert um 10:14 Uhr
Sehr interessantes Feedback !
Ich habe gerade mal mehrere APUs gecheckt mit der 2.5er. Dort scheint das kein Problem zu sein
stat - Klicke auf das Bild, um es zu vergrößern
Die stecken meist direkt an einem LWL Switch eines Providers der der Übergabepunkt ist. Diverse Hersteller Alcatel, Cisco usw. Keiner der APUs zeigt irgendwelche Errors auf dem WAN. Wie gesagt...nur APU Hardware.
Eine Frage noch zum Kommando sysctl dev.igb.0.eee_disabled:1. In den Advanced Settings unter "System Tunables" taucht der Parameter nicht auf. Er kann dann vermutlich nur über den Shell Zugang konfiguriert werden, richtig ?
Bei APUs z.B. deren Interfaces "re0" usw. heissen müsste das dann entsprechend vermutlich sysctl dev.re.0.eee_disabled:1 lauten wenn man das deaktivieren möchte. Bzw. man sollte vorher in die Interface Statistiken sehen um die Systembezeichnung seiner Interfaces zu verifizieren.
Bitte warten ..
Mitglied: Fenris14
09.03.2021, aktualisiert um 10:40 Uhr
Also, erstmal: Die Option muss im Treiber sein, bei re0 Schnittstellen weiß ich nicht wie das ist.

Prüfen kann man es auf der CLI mit:


Wenn da nichts auftaucht, kannst du den Wert auch nicht setzen. Kann auch sein das er anders heißt bei anderen Treibern von anderen Herstellern. Bei mir ist das ja explizit Intel igb, also alle NIC vom Typ 82575/6, 82580, i350, I354 und Interstate 210/I211.

Auf der CLI kann man den Wert akut setzen mit:


Einfach so reindonnern. Dann quittiert dir das Interface sogar was der vorherige Wert war. Das ist aber nicht rebootfest. Normalerweise würde man in der /boot/loader.conf entsprechend etwas hinterlegen. Aber dort hat die Option nach reboot keinen Effekt. Keine Ahnung warum.

Stattdessen muss man unter "System > Advanced > System Tunables" wie folgt einen neuen Eintrag erzeugen:

auswahl_062 - Klicke auf das Bild, um es zu vergrößern

Wenn du den Eintrag nicht erzeugst, kannst du da auch keinen finden. ;)

Grüße
Bitte warten ..
Mitglied: aqui
09.03.2021, aktualisiert um 12:10 Uhr
Nope, der Realtek Treiber kann das (vermutlich) nicht. Bestätigt dann auch indirekt warum die Error Counter dort vermutlich alle auf 0 sind ! ;-) face-wink
[2.5.0-RELEASE][admin@firewall.de]/root: sysctl dev.re.0
dev.re.0.int_rx_mod: 65
dev.re.0.stats: -1
dev.re.0.%parent: pci1
dev.re.0.%pnpinfo: vendor=0x10ec device=0x8168 subvendor=0x10ec subdevice=0x0123 class=0x020000
dev.re.0.%location: slot=0 function=0 dbsf=pci0:1:0:0
dev.re.0.%driver: re
dev.re.0.%desc: RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet
[2.5.0-RELEASE][admin@firewall.de]/root:

Dann besteht zumindestens bei den APUs wohl kein Handlungsbedarf in Sachen EEE.
Bitte warten ..
Mitglied: Fenris14
09.03.2021 um 12:26 Uhr
Offensichtlich nicht. Mich würde aber dennoch stark interessieren ob es dann bei Realtek überhaupt EEE gibt oder ob die darauf komplett von vorne herein verzichtet haben. Scheint wieder so ein Intel-Ding zu sein.

Habe hier auch eine APU4 in einer kleiner Inhouse-Lösung, an einem Zyxel Modem dran, dort ebenfalls keine Probleme.
Bitte warten ..
Mitglied: Fenris14
09.03.2021 um 13:21 Uhr
Dann scheint es besser implementiert zu sein, auch schon in älteren Treibern, als bei Intel. Nicht zum ersten Mal das man von Intel enttäuscht wird.
Bitte warten ..
Mitglied: aqui
09.03.2021 um 15:32 Uhr
Obwohl Intel LAN Chipsätze oder die von Broadcom ja durch die Bank einen sehr guten Ruf haben. Ebenso die Linux oder FreeBSD Treiber Unterstützung an der Intel ja aktiv mitarbeitet.
Bitte warten ..
Heiß diskutierte Inhalte
Festplatten, SSD, Raid
Festplatte aus defekten Notebook ausgebaut - wird nicht erkannt - Wie gelange ich an meine Daten?
gelöst 1nCoreVor 1 TagFrageFestplatten, SSD, Raid15 Kommentare

Hallo liebe Community, nach 7 Jahren hat mein XMG Notebook seinen Geist aufgegeben In dem Notebook waren zwei Festplatten verbaut (eine für System und ...

Erkennung und -Abwehr
Wie geschickt sich Malware verstecken kann - Ein Beispiel aus der Praxis eines Security Experts
colinardoVor 18 StundenTippErkennung und -Abwehr3 Kommentare

Servus Kollegen und Mitstreiter, da ja in letzter Zeit die Exchange-Lücken die Admin-Landschaft ziemlich aufgewirbelt haben und dabei auch immer mal wieder "sogenannte" Admins ...

Internet
Woher holt sich Android die Kontaktdaten von unbekannten Rufnummern?
gelöst anteNopeVor 1 TagFrageInternet8 Kommentare

Hallo zusammen, seit einiger Zeit merke ich, dass mir mein Android Gerät Namen und Informationen zu mir unbekannten Teilnehmern präsentiert. Soll heißen eine nicht ...

Windows Netzwerk
MS Lizenzierung - externe Scandienstleistung
monstermaniaVor 1 TagFrageWindows Netzwerk9 Kommentare

Hallo Allerseits, ich habe da mal eine Frage an die MS Lizenzspeziallisten. Eine externe Firma soll Scandienstleistungen für uns erledigen. Dazu ist angedacht, dass ...

Exchange Server
Exchange Update CU19 auf CU20 Fehler - Eine weitere Version dieses Produkts ist bereits installiert
gelöst StefanKittelVor 1 TagFrageExchange Server6 Kommentare

Hallo, ich habe hier einen Exchange 2016 mit CU19 (15.1.2176.2). Darauf wollte ich nun CU20 installiert. Download Es erscheint Eine weitere Version dieses Produkts ...

Exchange Server
April 2021 Microsoft Exchange Server Security Updates
FrankVor 1 TagInformationExchange Server2 Kommentare

Microsoft has released security updates for vulnerabilities found in: Exchange Server 2013 Exchange Server 2016 Exchange Server 2019 These updates are available for the ...

Drucker und Scanner
Epson WF-6590 druckt nur cyan und gelb
gelöst ITCrowdSupporterVor 1 TagFrageDrucker und Scanner15 Kommentare

Guten Tag :-) Es geht um einen Epson Workforce Pro WF-6590. Er druckt nur cyan und gelb obwohl neue Originalpatronen für schwarz und magenta ...

Windows 10
Windows 10 Updates im Abgesicherten Modus nicht möglich!
gelöst Yuuto.LucasVor 1 TagFrageWindows 1016 Kommentare

Hallo, ich habe aktuell ein Problem bei einem Kunden Rechner. Bei diesem gibt es Probleme mit dem Soundkarten Treiber hdaudio.inf wegen dem der PC ...