Häufige Modem-Restarts, Packetloss (und katastrophaler Support)

iSOcH · 2022-04-02T16:43:58+00:00

Sunrise Community - Kunden helfen anderen Kunden rund um die Themen Fernsehen, Internet, Telefon und Mobile. Jetzt registrieren!

iSOcH

Hier ganz frisch die Packet-Loss-Phasen in den letzten 2h.

Zoomt man zeitlich etwas raus (und begrenzt die Ranges in der Traffic-Nutzung) sieht man auch dass der Packetloss eher von der Uhrzeit (bzw. der Nachbars-Aktivität?…) abhängt als vom selber verursachen Traffic:

GrandDixence

24h/7Tage-Leitungstest einrichten und den Screenshot vom “Broadband Quality Monitor” nach einer Mindestlaufzeit von 24 Stunden hier veröffentlichen:
https://community.sunrise.ch/d/8569-gigaconnect-aussetzer/25

Gute Performance-Regel Nr. 1 bis und mit Nr. 5 strikt einhalten:
https://community.sunrise.ch/d/4397-diagnose-tool-der-connect-box-sagt-ihr-heim-netzwerk-hat-derzeit-einige-probl/27

Und zum Thema “Cable Modem Reboot - due to power reset” wünsche ich viel Glück bei der Fehlerbehebung. Siehe dazu:
https://community.sunrise.ch/d/18635-viel-zu-haufige-reboots-der-connect-box/23

Wie genau wurde der WAN- und der LAN-Anschluss des Raspberry Pi 4 realisiert, welcher mit OpenWrt als Firewall fungiert?

Und wozu wird ein Netzwerkteilnehmer mit einer privaten IPv4-Adresse an einem Kabelmodem betrieben, welches im Bridge-Modus läuft? Für was zum Kuckuck soll das gut sein?

iSOcH

GrandDixence

Danke für die Rückmeldung.

Leitungstest:
Broadband Quality Monitor ist nun eingerichtet.

Performance-Regeln:
Regeln waren eigentlich eingehalten, ausser “Firewall deaktivieren auch mit Bridge mode”. Habe ich jetzt noch angepasst (obwohl es imho eher dämlich wäre wenn das im Bridge-Mode noch Effekt hätte, man kanns ja dann gar nicht mehr konfigurieren)

Cable Modem Reboot - due to power reset:
Ich habe den Verdacht dass die beiden Probleme zusammenhängen (Kabelnetzzelle ist so überlastet oder “spinnt” derart, dass das Modem quasi als fail-safe einen Restart macht).

OpenWRT Firewall/Netzwerk:
Am Raspi hängt neben der onboard NIC noch eine USB3-NIC (empfohlenes Modell, Linksys USB3GIG. Unter linux mit r8152 Treiber bedient).

Netzwerkteilnehmer mit einer privaten IPv4-Adresse an einem Kabelmodem:
Einzig und allein zwecks Eingrenzung der Fehlerquelle. Während das Kabelmodem selbst recht Packetloss zeigt und/oder Pings stark verzögert beantwortet ist diese Komponente stets gut erreichbar. Dies hilft um die Routing-Leistung sowie die physikalische Verkabelung zwischen Firewall und Kabelmodem als Fehlerquelle auszuschliessen.

GrandDixence

Verletzung “Gute Performance”-Regel Nr. 3: Gemäss Beschreibung sind zwei Ethernet-Netzwerkkabel am EuroDOCSIS-Kabelmodem eingesteckt.

iSOcH

GrandDixence

““Gute Performance”-Regel Nr. 3”
Ja, wie gesagt hängt diese Komponente “zwecks Eingrenzung der Fehlerquelle” dort. Daraus könnte man auch schliessen dass sie als die Probleme angefangen haben noch nicht dort war. Aber ja, brauch’ ich eigentlich nicht mehr.

Broadband Quality Monitor:
So, hier haben wir nun 24h davon. Die 4 (ja, vier) 100% loss spikes waren Modem reboots. Erkennbar aber auch die sonstigen Probleme (man vergleiche z.B. zwischen 12pm und 4pm mit 2am - 5am)

millernet

Ja ich befürchte temporär werde ich wohl in den Routermode müssen. Aber da warte ich mal bis mich UPC dazu auffordert…

Ich bin eigentlich der Meinung dass meine Pings auf den 192.168.100.3, welche den selben Pfad durch die Firewall nehmen wie der Internetverkehr, schon ein starkes Indiz sind dass der OpenWRT-Raspi nicht schuld ist. Wenn jetzt die ConnectBox nicht auch noch alle ~12h rebooten würde hätte ich vielleicht noch etwas mehr Zweifel am Raspi…

Ich war zunächst auch eher skeptisch bzgl. RPI und USB so im Netzwerkumfeld, aber habe da recht Gutes von dem Setup gelesen. Auch Performance-mässig ist das recht stark: https://forum.openwrt.org/t/rpi4-routing-performance-numbers/53996/6

Aber ich checke mal wie mühsam es ist die Firewall Config in einer VM laufen zu lassen. Hab noch nen Server daneben der das eigentlich mal machen kann, und OpenWRT läuft ja auch auf x86 wies aussieht.

Grafana / Monitoring:

Ist eigentlich gar nicht so viel. Grundsätzlich zieht ein Prometheus die Daten und stellt sie dann für Grafana bereit. Gezeigt habe ich hier einerseits Teile von https://grafana.com/grafana/dashboards/11147, die benötigten Exporter sind dort beschrieben, können in OpenWRT einfach installiert werden. Das Dashboard ist in anderen Bereichen nicht perfekt (NAT Zuordnung, Summen etc.), aber das trifft glaub auf fast alles zu.

Die Pings/Packet loss funktionieren gemäss https://grafana.com/grafana/dashboards/12412. Der prometheus-blackbox-exporter wird für das Sammeln der Daten verwendet. Ist gut, aber Smokeping wäre wohl noch etwas besser.

Für meinen Lag-Überblick habe ich dann einfach ein Dashboard mit Grafen aus den beiden Komponenten zusammengesetzt, so dass ich einigermassen gut Traffic mit Packetloss etc korrelieren kann.

millernet

Damit UPC Sunrise deine Probleme effektiv analysieren kann, wäre die Verwendung des Router-Modus zu empfehlen. Damit deine RPi-OpenWRT-Firewall als Fehlerquelle ausgeschlossen werden kann, wäre es notwendig, dass du die Connect Box temporär direkt als Router nutzt. Allgemein empfehle ich die Verwendung von OPNsense oder pfSense auf x86-Hardware oder als Appliance von Netgate. Von RPi’s als Firewall-Router halte ich wenig, besonders unter Verwendung von USB-Dongle’s als zweite NIC. Übrigens: Könntest du nähere Details zu deinem Grafana-Dashboard teilen? 😁 Ich finde es so sexy, dass ich es am liebsten auch gleich implementieren würde. Woher stammen die Daten resp. wie sieht deine network surveillance pipeline aus?

Daniele_Sunrise

iSOcH Die Signalqualität deines Modems ist nicht optimal und es hat zu hohe Korrekturwerte im Upstream (bis zu 149%). Wir haben diesbezüglich einen Technikerauftrag erstellt. Du wirst für eine Terminvereinbarung innerhalb 24 Stunden kontaktiert werden.

Bitte melde dich nach dem Technikerbesuch mit einem Feedback.

Liebe Grüsse
Daniele

millernet

Sieht mir nach gröberen Signalproblemen aus. Auch die Post-RS-Fehler lassen nichts Gutes vermuten. @Daniele_Sunrise soll doch bitte die Werte deines Modems eingehend prüfen und analysieren.

Daniele_Sunrise

iSOcH Herzlich Willkommen in der Community!

Bitte sende uns für die Bearbeitung deine Kundennummer, Anschrift sowie das Geburtsdatum via privater Nachricht zu. Gerne prüfen wir anschliessend die Konfiguration deines Modems.

Liebe Grüsse
Daniele

iSOcH

Daniele_Sunrise

Interessant, der Techniker der im Rahmen von Ticket 14576535 hier war hatte eigentlich die Dose wie auch den Verstärker gemessen (oder sieht er da nur den Downstream?). Aber ja, bin ich mal gespannt. Danke schonmal.

iSOcH

Heute “nur” ein Modem-Reboot und vorallem am Nachmittag vergleichsweise gute Verbindung. Hat sich dann aber am Abend revanchiert…

Daniele_Sunrise: Termin wurde vereinbart.

GrandDixence

Daniele sieht offenbar die Messwerte vom CMTS. Das CMTS empfängt das Upstream-Signal (Upload-Richtung). Das CMTS steht im PoP.
https://de.wikipedia.org/wiki/Cable_Modem_Termination_System

https://de.wikipedia.org/wiki/Point_of_Presence

Der Techniker misst das im Privathaushalt vom EuroDOCSIS-Kabelmodem empfangene Downstream-Signal (Download-Richtung). Weshalb der Techniker nur die halbe Kontrollarbeit macht und nicht mit einem Fernzugriff die CMTS-Messwerte kontrolliert, ist mir schleierhaft. => Faulheit, Zeitdruck, Inkompetenz?

https://de.wikipedia.org/wiki/Kabelmodem

https://de.wikipedia.org/wiki/Data_Over_Cable_Service_Interface_Specification

https://de.wikipedia.org/wiki/Koaxialkabel

Weiter möchte ich darauf hinweisen, dass dieses EuroDOCSIS-Kabelmodem (Connect Box) auch im Bridge-Modus weiterhin als Wireless Access Point fungiert und ein WLAN-Funksignal ausstrahlt. Wenn kein Bedarf an Wi-Free vorhanden ist, sollte im UPC-Kundenzentrum (MyUPC):
https://www.upc.ch/de/konto/anmelden/anmeldedaten/
unter “Mein Profil” Wi-Free ausgeschaltet werden (Status: Deaktiviert).

Zum Thema “CCR versus CER” habe ich hier ein “Déjà-vu”:
https://community.sunrise.ch/d/16127-extrem-langsames-internet-schon-wieder/36

iSOcH

@Daniele_Sunrise Der Techniker war hier (es war derselbe Techniker der schonmal hier war).

Er meinte die CER Werte aktuell seien super, daher könne er kaum was machen. Jedoch sei die Hausinstallation teilweise nicht ganz sauber, das wird nun neu gemacht (sei für mich kostenlos). Dass das Problem erst seit relativ kurzem auftritt (die Hausinstallation ist doch schon paar Jahre alt, das Problem haben wir seit ein paar Monaten) hat er zur Kenntnis genommen.

iSOcH

Hier die neusten 24h von ThinkBroadband. Wieder recht viele Modem-Reboots, aber nicht nur:

Der Aussetzer um 19:34 (CH Zeit) war kein Modem reboot. So lange hat so eine Packetloss-Phase glaub noch nie gedauert (19:33 - 19:35). Sieht man da Kabelnetz-seitig nichts? Im Modem hats keinen Log-Eintrag.

Wenn ich diese Loss-Phasen sammeln würde, könnte man das nicht mit weiteren Daten korrelieren?

iSOcH

6 Modem Reboots in den letzten 24h. Die beiden über MIttag innerhalb von 15min, jeweils direkt davor ein “No Ranging Response received - T3 time-out;CM-MAC=54:67:51:33:3b:f3;CMTS-MAC=00:17:10:98:b7:85;CM-QOS=1.1;CM-VER=3.0;”

iSOcH

Mal ein anderes Bild, wäre echt an Erklärungen hierfür interessiert:

Hier haben wir 4 verschiedene Last-Szenarien:

Bis 9.4. ~21:00: Die Ethereum Services sind aktiv, danach gestoppt. Hier sehen wir die bereits beschriebenen Packet-loss-Phasen. Der Anschluss ist gefühlt alle 15-30min für 30-90s unbrauchbar.
Ab 22:00: Mein NAS macht ein Backup, lastet den Upload so zu 80% aus.
10.4. 05:00-10:00: Praktisch überhaupt keine Akvitität. Packetloss ist jedoch leicht höher als in der Nacht, auch gegenüber der Phase mit recht hoher Upload-Nutzung
Seit ~14:00: NAS Backup läuft, zusätzlich noch weitere Tests um sowohl den Up- wie auch den Download voll auszulasten.

(Traffic-Shaping auf meiner Firewall ist hier immer aktiv)

Schon sehr erstaunlich, dass die viel höhere Auslastung des Anschlusses in Phase 4 zu praktisch keinem Packetloss führt. Man beachte, dass nicht nur der Durchsatz, sondern auch die Packet-rate sehr viel höher ist als in Phase 1.

Ein Unterschied ist, dass die Ethereum Services mehr TCP und UDP connections offen haben (ich hab das aber per Firewall begrenzt, Conntrack liegt so um die 2k wenn die Services laufen, jetzt ohne so um die 800). Das dürfte ein Modem im Bridge-Mode aber überhaupt nicht kümmern…

So siehts bei Thinkbroadband aus (aber halt nur 24h, oben sinds 36):

Ich habe aber schon den Eindruck dass irgendwo ausser auf meiner Firewall noch Traffic-Shaping stattfindet - sonst müssten die Pings doch wesentlich stärker ansteigen bei so hoher Auslastung. Man sieht dennoch einen kleinen Unterschied, je nachdem obs auf meiner Firewall aktiv ist oder nicht:

Im mittleren Bereich mit geringerem (nur ~60%) Upload ist das Traffic-Shaping auf meiner Raspi-Firewall deaktiviert.

Schaut die Connect-Box im Bridge-Mode trotzdem noch recht tief in die Pakete rein und kommt dann mit der (eigentlich nichtmal hohen) Anzahl Verbindungen nicht mehr klar?

GrandDixence

@iSOcH
Wieso werden die Empfehlungen nicht befolgt? Millernet hat ja bereits die Umstellung in den Router-Modus empfohlen. => EuroDOCSIS-Kabelmodem in den Router-Modus setzen und 24 Stunden später den “Broadband Quality Monitor” kontrollieren. Sehen die Messergebnisse vom “Broadband Quality Monitor” vom Router-Modus deutlich anders aus als vom Bridge-Modus, ist das Problem klar hausgemacht. Nach 24 Stunden kann man ja wieder zurück in den Bridge-Modus wechseln.

Ein Unterschied ist, dass die Ethereum Services mehr TCP und UDP connections offen haben (ich hab das aber per Firewall begrenzt, Conntrack liegt so um die 2k wenn die Services laufen, jetzt ohne so um die 800).

Wahrscheinlich wieder so ein hoffnungsloser Fall von fehlenden “Top-Linux-Kenntnisse”. Siehe dazu:
https://community.sunrise.ch/d/18807-erlaubt-nur-bis-zu-ca-300-verbindungenip
=> Wie man auf einen OpenWrt-Rechner per SSH zugreift ist bekannt?

Nebst der korrekten Konfiguration von SPI-Firewall und Traffic Shaper, wäre auch die korrekte Konfiguration vom “TCP Established Timeout” und dessen ICMP- und UDP-Pendant angebracht. Gerade Linux-Rechner haben eine “viel zu lasche” Standardkonfiguration des “TCP Established Timeout”. Siehe dazu:
https://community.sunrise.ch/d/20070-giga-connect-box-keine-oder-verspatete-eingehende-push-nachrichten

Und vielleicht macht es auch mal Sinn die Hinweise und Empfehlungen zum Betrieb eines Raspberry Pi unter:
https://www.lancom-forum.de/aktuelle-lancom-router-serie-f41/vdsl-umzug-glasfaser-neuer-router-t17926.html#p101750

https://forums.opensuse.org/showthread.php/564736-snapper-ein-verzeichnis-ausschliessen?p=3114383#post3114383

https://forums.opensuse.org/showthread.php/568621-GRUB-reagiert(e)-extrem-tr%C3%A4ge?p=3120211#post3120211

https://forums.opensuse.org/showthread.php/569221-Flatpaks-werden-nicht-im-Startmen%C3%BC-angezeigt-auch-nach-Neustart?p=3123388#post3123388

https://forums.opensuse.org/showthread.php/569221-Flatpaks-werden-nicht-im-Startmen%C3%BC-angezeigt-auch-nach-Neustart?p=3123391#post3123391

https://curius.de/2021/09/flatpak-snap-vs-paketverwaltung-alles-was-dazu-gesagt-werden-muss/

zu beachten (z.B. Kühlung, LTS Linuxdistribution).

Nach Möglichkeit sollte eine LTS-Linuxdistribution eingesetzt werden. Generell ist der Einsatz einer LTS-LInuxdistribution mit (jährlichen) “Minor Upgrades”, wie:

Red Hat Enterprise Linux und deren kostenlose Ablegern AlmaLinux und Rocky Linux
SUSE Linux Enterprise

die bessere Wahl als der Einsatz einer LTS-Linuxdistribution ohne “Minor Upgrades”, wie:

Ubuntu Server

Jährliche “Minor Upgrades” ermöglichen eine sanfte Software- und Betriebssystempflege. Was das Erstellen und Verteilen von Sicherheitsupdates in Patch-Form vereinfacht.

OpenWrt erachte ich als eine (gute) Notlösung für Linux-Minisysteme, deren Speicherplatz (RAM, Flash) so arg begrenzt ist, dass keine LTS-Linuxdistribution eingesetzt werden kann. Beim Raspberry Pi 4 Model B ist aber (mehr als) genug RAM und Flash-Speicher vorhanden (microSDHC-Speicherkarten sei Dank)! Somit ein Einsatz von OpenWrt auf einem Raspberry Pi 4 Model B nicht zu gerechtfertigten.

Gleiche Aussage gilt für weitere Linux-Distributionen, die extra auf den ressourensparenden Einsatz getrimmt wurde. Zum Beispiel:

Alpine LInux => https://de.wikipedia.org/wiki/Alpine_Linux

Habe selber auf einigen Geräten (notgedrungen) OpenWrt im Einsatz. Aber auf die Idee OpenWrt auf dem Raspberry Pi 4 Model B einzusetzen, die war mir (aus guten Gründen) noch gar nie in den Sinn gekommen!

Mit Ubuntu Server 20.04 habe ich auf mehreren Raspberry Pi 4 Model B so gute Erfahrungen gesammelt, dass ich bis heute noch gar keine andere LTS-Linuxdistribution auf dem Raspberry Pi 4 Model B ausprobiert habe…

iSOcH

Aber grundsätzlich: Ist das nicht ein überraschendes Verhalten? Der Anschluss samt Modem & Firewall können stundenlang kumuliert ~40k Packets/s und 43 MByte/s routen/shapen aber bei einem Bruchteil des Durchsatzes kommts zu Problemen?

GrandDixence Wieso werden die Empfehlungen nicht befolgt? Millernet hat ja bereits die Umstellung in den Router-Modus empfohlen.

Wenn eine der Komponenten alle paar Stunden rebootet und die andere absolut stabil läuft, wo sucht man dann wohl eher den Fehler?

@millernet hat das empfohlen, “Damit UPC Sunrise deine Probleme effektiv analysieren kann”. Aber ja, mache ich jetzt mal.

Ich nehme mal an das ““TCP Established Timeout” und dessen ICMP- und UDP-Pendant” lassen sich auf der Connect-Box nicht konfigurieren?

GrandDixence Wahrscheinlich wieder so ein hoffnungsloser Fall von fehlenden “Top-Linux-Kenntnisse”.

Ja, ist wohl hoffnungslos. Gehts auch anständig?

GrandDixence => Wie man auf einen OpenWrt-Rechner per SSH zugreift ist bekannt?

Ja. Was willst Du denn von dort wissen?

GrandDixence Kühlung

Nun, während dem 18h langen durchrouten/shapen der gesamten Bandbreite lag der CPU Load auf dem Raspi einiges höher als in den Phasen mit erhöhtem Packetloss. Wäre naheliegend, dass dabei auch die Anforderungen an die Kühlung höher sind, und da es dabei keine Probleme dabei gibt…

(links: Mehr TCP/UDP states, rechts: viel mehr packets & bytes)

GrandDixence LTS Linuxdistribution

Was für Software empfiehlst Du denn dort für den Routereinsatz?

Oder soll man dort dann das Routing, Firewall, Shaping, DNS, DHCP alles manuell konfigurieren? Zusätzlich noch Softwarepakete die eine Firewall gar nicht braucht alle paar Wochen aktualisieren? Ist das wirklich besser bei “hoffnungsloser Fall von fehlenden “Top-Linux-Kenntnisse””?

iSOcH

GrandDixence Wieso werden die Empfehlungen nicht befolgt? Millernet hat ja bereits die Umstellung in den Router-Modus empfohlen. => EuroDOCSIS-Kabelmodem in den Router-Modus setzen und 24 Stunden später den “Broadband Quality Monitor” kontrollieren. Sehen die Messergebnisse vom “Broadband Quality Monitor” vom Router-Modus deutlich anders aus als vom Bridge-Modus, ist das Problem klar hausgemacht.

Ich würde sagen die Messungen sehen wirklich deutlich anders aus, aber deutet eher weniger auf die Firewall als Problemquelle…

Erläuterung:

Bis um ~08:45 (CH Zeit): Ein Teil der Ethereum Services läuft, dazu die Bandbreiten-Vollauslastung.
08:45: Wechsel zum Router-Modus, meine Firewall hängt jetzt nicht mehr im Netz.
Ab 11:30: Ethereum services gestoppt, weiterhin volle Bandbreitennutzung.
Zeitweise Abbrüche einzelner TCP streams
17:45: Bandbreiten-Tests beendet
Um 18:00 kurz alle Ethereum Services gestartet, musste wieder stoppen da auf interaktive Anwendungen angewiesen.
Ab 21:00: Wieder alle Ethereum services gestartet

Hier auch noch vom anderen Monitoring - “openwrt” und “192.168.100.1” haben natürlich keine Aussagekraft. Der Traffic Graph natürlich auch nicht (versucht das OpenWRT abzufragen)

millernet

Wir drehen uns hier ewig im Kreis. Aus meiner Sicht ist es offensichtlich, dass das Problem bei Sunrise UPC resp. im Kabelnetz liegt und nicht bei iSOcH . Warum sind die Messwerte beim CMTS so grausig schlecht, aber der Techniker kann vor Ort nichts Auffälliges feststellen, ist mir ein Rätsel. Gemäss meinen Infos müssten moderne Kabelmodems als eine Art Signal-Analyzer funktionieren und direkt Messwerte und Spektren liefern, so war es jedenfalls bei meinen letzten Techniker-Besuchen. Die Spektren kamen per Notebook und Internet direkt vom Node und vom Modem. Die Spezifikation nennt sich DOCSIS PNM (Proactive Network Maintenance) und ist schon recht “alt” (https://www.cablelabs.com/blog/the-evolution-of-docsis-proactive-network-maintenance-pnm).

Nächste Seite »