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

  • 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)?

  • 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.

  • Code
    1. 5. 62.115.14.116 63.8% 2606 942 (ffm-b4-link.telia.net.)
    2. 6. 62.115.114.90 1.8% 2606 2560 (ffm-bb2-link.telia.net.)
    3. 62.115.114.88 (ffm-bb3-link.telia.net.)
    4. 7. 62.115.123.13 1.3% 2606 2571 (prs-bb3-link.telia.net.)
    5. 62.115.122.138 (prs-bb4-link.telia.net.)
    6. 62.115.114.98 (prs-bb4-link.telia.net.)
    7. 8. 62.115.114.228 5.3% 2606 2468 (ldn-bb4-link.telia.net.)
    8. 62.115.134.93 (ldn-bb3-link.telia.net.)
    9. 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:

    netcup Support wrote:

    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

  • Neue Rückmeldungen vom Support:

    netcup Support wrote:

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

    und

    netcup Support wrote:

    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...

  • 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.