NTP-Pool Monitoring bei IPv4 meines Server schlecht

  • Guten Abend zusammen,


    auf meinem VPS 500 G8 Plus läuft Windows Server 2016. Für die Teilnahme am NTP-Pool benutze ich die Software von Meinberg.


    Beim NTP-Pool habe ich sowohl die IPv4, als auch die IPv6 meines Servers eingetragen. Jetzt zeigt das Monitoring vom NTP-Pool aber seit dem 21.09. an, dass anscheinend mein Server sporadisch nicht per IPv4 erreichbar sei. Dies wundert mich aber, da das Monitoring von der IPv6 absolut glücklich aussieht.


    Jetzt zu meiner Frage: Liegt der Fehler auf meiner Seite (obwohl ich rein gar nichts an meiner Konfiguration geändert habe) oder sollte ich mal die Leute vom NTP-Pool kontaktieren? Oder liegt der Fehler irgendwo auf der Strecke?


    IPv4:

    IPv4.PNG


    IPv6:

    IPv6.PNG

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Ah, ab und zu ein Blick ins längste Thema lohnt anscheinend. ^^


    Ich werde mich dann mal an den Support wenden und auf die Posts verweisen. Besten Dank Steini

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Dito julian-w


    Habe Ask auch schon am Montag angeschrieben. Bisher kam noch nichts zurück.


  • Weiß zufällig jemand auf die Schnelle die IP von dem Monitoring (Newark, NJ, US)?

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Ich hab ein bisschen recherchiert und bin hierauf gestoßen: https://community.ntppool.org/…t-to-our-ntp-servers/1261

    Dort wird mehrmals von der IP 139.178.64.42 gesprochen. Außerdem schreibt Ask dort, dass er dem Beta System ein Monitoring in Amsterdam hinzugefügt hat.


    Aktuell lasse ich mal einen Test mit der o.g. IP laufen.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Ich habe auch mal die Leute vom NTP-Pool angeschrieben und diese Antwort bekommen:



    Bin erst heute Abend wieder zu Hause. Dann teste ich weiter.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Code
    5. 62.115.14.116       63.8%  2606   942 (ffm-b4-link.telia.net.)
    6. 62.115.114.90        1.8%  2606  2560 (ffm-bb2-link.telia.net.)
       62.115.114.88                         (ffm-bb3-link.telia.net.)
    7. 62.115.123.13        1.3%  2606  2571 (prs-bb3-link.telia.net.)
       62.115.122.138                        (prs-bb4-link.telia.net.)
       62.115.114.98                         (prs-bb4-link.telia.net.)
    8. 62.115.114.228       5.3%  2606  2468 (ldn-bb4-link.telia.net.)
       62.115.134.93                         (ldn-bb3-link.telia.net.)
    9. 62.115.113.20       24.8%  2606  1961 (nyk-bb4-link.telia.net.)

    Angabe Packet-Loss %, # gesendete Pakete, # Antworten.

  • Die letzte Antwort vom Support:

    Zitat von netcup Support

    Ich habe hier einmal Rücksprache mit unserem Network Operation Center gehalten. Ihre Analysen zeigen keine Auffälligkeiten. Um dies tiefer zu analysieren wären noch MTRs von der Gegenstelle in unser Netzwerk vonnöten.


    Daraufhin habe ich nochmal mit einem Admin vom NTP-Pool geschrieben und ihn gebeten ein MTR vom Monitoring aus durchzuführen:


    Ich habe den Support mal auf das MTR von customer hingewiesen. Zudem habe ich eine Seite mit Statistiken von IP-Adressen aus AS197540 im NTP-Pool erstellt, die ich so finden konnte: https://cldup.com/eMad21gfq1.html

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Neue Rückmeldungen vom Support:

    Zitat von netcup Support

    Im MTR aus dem Forum ist deutlich zu sehen, dass wohl Telia zu dem Zeitpunkt ein Routingproblem hatte.

    und

    Zitat von netcup Support

    Stand Jetzt liegt kein Problem vor. Ohne eine entsprechende Rückroute können wir hier keine Analysen anfertigen.


    Tja, jetzt bin ich mit meinem Latein so langsam am Ende...

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • Mit Ziel-IP 139.178.64.4 über Zayo gibt es ebenfalls Probleme:


  • Vielen Dank customer


    Darf ich euch bitten selber den Support mal anzuschreiben? Ich drehe mich mit denen gerade im Kreis. Vielleicht haben wir ja mehr Erfolg, wenn die mehrere Tickets zu dem Thema bekommen.


    Der Support möchte unbedingt ein MTR von NTP-Pool-Monitoring -> mein Server.

    Die Admins vom NTP-Pool können mir dieses jedoch nicht anfertigen. Ich sehe es jedoch nicht in meiner Verantwortung für meinen Hosting Provider die Fehleranalyse durchzuführen. Ich habe auf eine eindeutige Einschränkung im Peering hingewiesen. Ich finde alles weitere liegt nicht mehr in meiner Verantwortung.

  • Deine ganzen MTR-Ausgaben mit jeweils einem(!) Ping pro Hop sind überhaupt nicht aussagekräftig. Damit kann niemand etwas anfangen, weshalb netcup im Wiki auch "Hierfür bitte mindestens 500 Pings durchführen" schreibt.

    Die Verbindung sieht tendenziell aber in Ordnung aus, am letzten antwortenden Hop scheint nie ein Paket verloren gegangen zu sein. Was dazwischen passiert ist dann egal.

  • Ich habe seit Wochen das gleiche Problem, mein Server ist auf IPv6 perfekt erreichbar, IPv4 hat ständig verlorene Pakete auf der betreffenden Route. Es ist enorm ärgerlich, und ich würde es sehr begrüßen, wenn Netcup sich darum kümmern würde.