PfSense RX Error auf WAN
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.
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:
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ß
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.
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:
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ß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 658827
Url: https://administrator.de/contentid/658827
Ausgedruckt am: 04.11.2024 um 22:11 Uhr
14 Kommentare
Neuester Kommentar
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.
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 ...
👍 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.
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.
Sehr interessantes Feedback !
Ich habe gerade mal mehrere APUs gecheckt mit der 2.5er. Dort scheint das kein Problem zu sein
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.
Ich habe gerade mal mehrere APUs gecheckt mit der 2.5er. Dort scheint das kein Problem zu sein
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.
Nope, der Realtek Treiber kann das (vermutlich) nicht. Bestätigt dann auch indirekt warum die Error Counter dort vermutlich alle auf 0 sind !
[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.
[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.
Laut Realtek Datenblatt kann er (der RTL8168 Chip) das:
https://www.realtek.com/en/products/communications-network-ics/item/rtl8 ...
https://www.realtek.com/en/products/communications-network-ics/item/rtl8 ...