2
Internetanschluss Monitoren
Hallo Leute,
wollte auf diesem Wege kurz nochmal um Rat bitten.
Hintergrund ist, dass mir vereinzelnd aufgefallen ist, das ich in den Abendstunden kurze Internetausfälle habe. (Die automatische Trennung habe ich auf 0:00 Uhr eingestellt)
Hardware ist:
Modem: Draytek Vigor 130 (aktuell mit Modem8) (vorher hatte ich eins von Zyxel, komme aber leider nicht auf den Namen)
Gateway: APU2D4 mit Pfsense
-> Interne Netzwerke (VLANS)
Bei der Sense habe ich als Monitoring IP die 1.1.1.1 (Ipv6 in den Logs, war nur mal nen Test).
Dieser Log bestätigt das Gefühl mit den Internetausfällen, jedoch konnte Seitens meines ISP bislang nichts festgestellt werden. Hier kam lediglich die Aussage, dass es ein Fehler vom Modem sein könnte und ich doch bitte wieder auf die "Fritzboxen" zurückgreifen sollte. Jedoch kann ich mir nicht vorstellen, dass der Fehler vom meinem Modem kommt.
Nun meine Frage an euch, kann man als Monitoring IP die 1.1.1.1 nehmen, oder ist diese als Referenz unbrauchbar?
Oder habt ihr vielleicht noch einen Hinweis, wie ich die "Qualitiät" der Anbindung parallel noch Monitoren kann?
Danke schon einmal im Voraus
Gruß Mario
wollte auf diesem Wege kurz nochmal um Rat bitten.
Hintergrund ist, dass mir vereinzelnd aufgefallen ist, das ich in den Abendstunden kurze Internetausfälle habe. (Die automatische Trennung habe ich auf 0:00 Uhr eingestellt)
Hardware ist:
Modem: Draytek Vigor 130 (aktuell mit Modem8) (vorher hatte ich eins von Zyxel, komme aber leider nicht auf den Namen)
Gateway: APU2D4 mit Pfsense
-> Interne Netzwerke (VLANS)
Bei der Sense habe ich als Monitoring IP die 1.1.1.1 (Ipv6 in den Logs, war nur mal nen Test).
Dieser Log bestätigt das Gefühl mit den Internetausfällen, jedoch konnte Seitens meines ISP bislang nichts festgestellt werden. Hier kam lediglich die Aussage, dass es ein Fehler vom Modem sein könnte und ich doch bitte wieder auf die "Fritzboxen" zurückgreifen sollte. Jedoch kann ich mir nicht vorstellen, dass der Fehler vom meinem Modem kommt.
Nun meine Frage an euch, kann man als Monitoring IP die 1.1.1.1 nehmen, oder ist diese als Referenz unbrauchbar?
Oder habt ihr vielleicht noch einen Hinweis, wie ich die "Qualitiät" der Anbindung parallel noch Monitoren kann?
Danke schon einmal im Voraus
Gruß Mario
Jul 7 00:00:09 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 12299us stddev 234us loss 11%
Jul 7 00:00:10 SpPfsense dpinger: WAN_DHCP6 2003:180:2:5000:0:1:0:53: Alarm latency 11098us stddev 2599us loss 12%
Jul 7 00:00:25 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 11470us stddev 32us loss 33%
Jul 7 00:00:27 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 1663432us stddev 2553247us loss 0%
Jul 7 00:00:42 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 312507us stddev 1261290us loss 4%
Jul 8 00:00:09 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 11086us stddev 282us loss 11%
Jul 8 00:00:09 SpPfsense dpinger: WAN_DHCP6 2003:180:2:5000:0:1:0:53: Alarm latency 9850us stddev 165us loss 11%
Jul 8 00:00:19 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 12075us stddev 145us loss 20%
Jul 8 00:00:29 SpPfsense dpinger: WAN_DHCP6 2003:180:2:5000:0:1:0:53: Alarm latency 506438us stddev 1642863us loss 0%
Jul 9 00:00:09 SpPfsense dpinger: WAN_DHCP6 2003:180:2:5000:0:1:0:53: Alarm latency 10703us stddev 2307us loss 11%
Jul 9 00:00:10 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 12865us stddev 2304us loss 12%
Jul 10 00:00:09 SpPfsense dpinger: WAN_DHCP6 2003:180:2:5000:0:1:0:53: Alarm latency 9609us stddev 552us loss 11%
Jul 10 00:00:10 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 11499us stddev 247us loss 12%
Jul 10 18:37:34 SpPfsense dpinger: WAN_DHCP6 2003:180:2:5000:0:1:0:53: Alarm latency 49909us stddev 15496us loss 11%
Jul 10 18:41:58 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 43189us stddev 18686us loss 11%
Jul 11 00:00:10 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 10720us stddev 237us loss 12%
Jul 11 00:00:10 SpPfsense dpinger: WAN_DHCP6 2003:180:2:5000:0:1:0:53: Alarm latency 10486us stddev 331us loss 12%
Jul 11 12:21:09 SpPfsense dpinger: WAN_DHCP6 2003:180:2:5000:0:1:0:53: Alarm latency 48922us stddev 12619us loss 11%
Jul 12 00:00:09 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 14552us stddev 8499us loss 11%
Jul 12 00:00:09 SpPfsense dpinger: WAN_DHCP6 2003:180:2:5000:0:1:0:53: Alarm latency 13985us stddev 7959us loss 11%
Jul 13 00:00:09 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 11716us stddev 246us loss 11%
Jul 13 00:00:10 SpPfsense dpinger: WAN_DHCP6 2003:180:2:5000:0:1:0:53: Alarm latency 10500us stddev 244us loss 12%
Jul 14 00:00:09 SpPfsense dpinger: WAN_DHCP6 2003:180:2:5000:0:1:0:53: Alarm latency 10580us stddev 4509us loss 11%
Jul 14 00:00:10 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 11560us stddev 2920us loss 12%
Jul 14 03:01:25 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 33314us stddev 9722us loss 11%
Jul 14 05:29:17 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 11510us stddev 225us loss 12%
Jul 14 15:24:06 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 16968us stddev 3651us loss 11%
Jul 14 15:24:49 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 135883us stddev 818174us loss 11%
Jul 14 15:25:22 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 199449us stddev 993050us loss 11%
Jul 14 15:34:02 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 76950us stddev 592476us loss 11%
Jul 14 16:31:37 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 23431us stddev 16662us loss 11%
Jul 14 16:46:55 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 11706us stddev 3603us loss 12%
Jul 14 16:46:56 SpPfsense dpinger: WAN_DHCP6 2003:180:2:5000:0:1:0:53: Alarm latency 8846us stddev 989us loss 12%
Jul 14 18:51:36 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 10356us stddev 4055us loss 12%
Jul 14 20:36:29 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 19694us stddev 2873us loss 11%
Jul 14 20:39:08 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 132634us stddev 791024us loss 11%
Jul 14 20:41:27 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 19132us stddev 863us loss 11%
Jul 14 20:42:42 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 199611us stddev 1017156us loss 11%
Jul 23 01:44:42 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 10685us stddev 246us loss 12%
Jul 23 21:00:00 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 34960us stddev 14848us loss 11%
Jul 26 14:15:47 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 115390us stddev 132959us loss 11%
Jul 26 17:29:42 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 170682us stddev 37590us loss 11%
Jul 26 18:23:01 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 163733us stddev 55622us loss 11%
Jul 26 18:23:34 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 180130us stddev 126808us loss 11%
Jul 26 19:16:06 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 177685us stddev 74697us loss 11%
Jul 26 20:00:42 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 134517us stddev 48902us loss 11%
Jul 27 11:04:27 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 126526us stddev 135127us loss 11%
Jul 28 21:43:34 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 20366us stddev 4606us loss 11%
Jul 28 21:49:17 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 27726us stddev 45975us loss 11%
Jul 28 21:51:10 SpPfsense dpinger: WAN_PPPOE 1.1.1.1: Alarm latency 29792us stddev 59071us loss 11%
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 591693
Url: https://administrator.de/contentid/591693
Printed on: April 19, 2024 at 21:04 o'clock
2 Comments
Latest comment
Hast du die Möglichkeit, Leitungswerte aus dem Modem auszulesen - eventuell sogar per SNMP?
Dann könntest du monitoren, ob sich die Leitungswerte des Modems verändern (im Speziellen auch die Showtime, also die Dauer, wie lange Sync besteht) und schauen, ob sich diese in zeitlichen Zusammenhang mit dem Packetloss setzen lassen. Interessante Werte sind ansonsten CRC- bzw. FEC-Counter.
Zusätzlich solltest du auch die Verbindung zwischen APU und Modem auf beiden Seiten prüfen und hier besonders auf CRC-Fehler auf der Netzwerkkarte überwachen. Falls es Switchports zwischen APU und Modem gibt, gilt das für die involvierten Switches ebenfalls.
Ansonsten bietet sich ein MTR an, welcher regelmäßig Reports generiert und so zeigt, ab welchem Hop der Packetloss auftritt. Sollte der Packetloss erst nach dem ersten Hop des Providers auftreten, so ist das Modem als Fehlerursache ausgeschlossen.
Zusätzlich solltest du am Besten auch weitere Ziele in dein Monitoring aufnehmen, sofern das geht. Hier bietet sich "k.root-servers.net" an, um argumentieren zu können, dass es keine Störung bei Cloudflare ist.
Was die automatische Trennung angeht: Bei den meisten Providern ist diese überhaupt nicht mehr nötig, so dass man diese auch abschalten kann.
Dann könntest du monitoren, ob sich die Leitungswerte des Modems verändern (im Speziellen auch die Showtime, also die Dauer, wie lange Sync besteht) und schauen, ob sich diese in zeitlichen Zusammenhang mit dem Packetloss setzen lassen. Interessante Werte sind ansonsten CRC- bzw. FEC-Counter.
Zusätzlich solltest du auch die Verbindung zwischen APU und Modem auf beiden Seiten prüfen und hier besonders auf CRC-Fehler auf der Netzwerkkarte überwachen. Falls es Switchports zwischen APU und Modem gibt, gilt das für die involvierten Switches ebenfalls.
Ansonsten bietet sich ein MTR an, welcher regelmäßig Reports generiert und so zeigt, ab welchem Hop der Packetloss auftritt. Sollte der Packetloss erst nach dem ersten Hop des Providers auftreten, so ist das Modem als Fehlerursache ausgeschlossen.
Zusätzlich solltest du am Besten auch weitere Ziele in dein Monitoring aufnehmen, sofern das geht. Hier bietet sich "k.root-servers.net" an, um argumentieren zu können, dass es keine Störung bei Cloudflare ist.
Was die automatische Trennung angeht: Bei den meisten Providern ist diese überhaupt nicht mehr nötig, so dass man diese auch abschalten kann.
na 312 Sekunden für nen Ping, das ist mal ne Hausnummer. 1.1.1.1 geht bei mir kontant mit 11 ms (Vodaphone Cablemax 1000, Endgerät per LAN)
Ich hab das mit den langen Pings aber auch schon gehabt... um herauszufinden, ob es nur bei einem selbst klemmt oder bei anderen Kunden desselben Providers oder für bestimmte Zielen, gibts Webseiten die Internetstörungen sammeln. Wenn du da deinen Provider wiederfindest, dann bist du nicht alleine, und eine Meldung der Störung wäre wohl eher sinnlos.
In meinem Falle hatte ein Bagger ein Vodaphone Kabel in Kölle erwischt, woraufhin in gesamt NRW das Netz gestört war und immer wieder ne halbe Stunde ausgefallen ist. Sowas kann man wunderbar dort nachlesen.
Und bei allen Privatanschlüssen werden die IP-Addressen einmal am Tag neu vergeben. Das ist gewollt, geht mit einer kurznen Unterrechung einher und kurz nach dem Reconnect hat man verlängerte Pings... aber nur 2-3 Sekunden lang. DAs Modem wird ja schließlich nicht vom Signal entkoppelt, sondern meldet sich nur neu an bei bestehendem Signal.
Ich hab das mit den langen Pings aber auch schon gehabt... um herauszufinden, ob es nur bei einem selbst klemmt oder bei anderen Kunden desselben Providers oder für bestimmte Zielen, gibts Webseiten die Internetstörungen sammeln. Wenn du da deinen Provider wiederfindest, dann bist du nicht alleine, und eine Meldung der Störung wäre wohl eher sinnlos.
In meinem Falle hatte ein Bagger ein Vodaphone Kabel in Kölle erwischt, woraufhin in gesamt NRW das Netz gestört war und immer wieder ne halbe Stunde ausgefallen ist. Sowas kann man wunderbar dort nachlesen.
Und bei allen Privatanschlüssen werden die IP-Addressen einmal am Tag neu vergeben. Das ist gewollt, geht mit einer kurznen Unterrechung einher und kurz nach dem Reconnect hat man verlängerte Pings... aber nur 2-3 Sekunden lang. DAs Modem wird ja schließlich nicht vom Signal entkoppelt, sondern meldet sich nur neu an bei bestehendem Signal.
