Backbone / Routing Q&A

  • douzer es gibt hier leider noch viel mehr Faktoren, die beim Routing eine Rolle spielen. Bspw. sog. Local Preference oder sog. MED. Nur weil wir den Traffic zu EWE über den DE-CIX routen, muss dies für den Traffic von EWE zu uns noch lange nicht so sein. Hier spielen bspw. auch kommerzielle Interesse oft eine Rolle. Oft hilft es, sofern du EWE Kunde bist, eine Mail an deren Support/NOC zu schicken. Routing über die DTAG kann auch ungewollt (und teuer) sein. ;-)

  • Hallo Theo,


    ich möchte das Forum einmal nutzen um ein etwas diffuses Problem zu beschreiben. Eventuell schafft man es hierfür gemeinsam eine Lösung zu finden, insofern das liegt auch in eurem Interesse.


    Einige eurer Kunden (u.A. ich) verwenden den Netcup Server als NTP Server und stellen diesen über pool.ntp.org auch kostenfrei der Allgemeinheit zur Verfügung. Dass ich nicht alleine bin, habe ich über das NTP-Pool Forum herausgefunden :)


    Der Pool wird von Ehrenamtlichen betrieben und im Jahr 2019 wurde die Server-Infrastruktur umgezogen/modernisiert. Hier beginnt das Problem. Ich (und auch die anderen User) bekommen regelmäßig false-positive Monitoring Alarme und auch der .de Gesamtpool flapped erheblich. Ich denke ihr stellt hierfür insgesamt einen nicht unerheblichen Teil der Server bereit. Das Flapping kann man hier schön sehen: https://www.ntppool.org/zone/de


    Der neue Monitoring Server steht in New York und verwendet ein Netzwerk, dass Zayo als einer der stärksten Peers verwendet. Zayo ist dafür bekannt NTP Pakete zu droppen, sollten diverse Schwellwerte überschritten sein. Laut den NTP-Pool Admins (mit denen das Problem soweit möglich debugged wurde) der Root-Cause dieses Problems.

    Die IP des Monitoring Systems ist 139.178.64.42


    Die Hinroute läuft von New York über Telia zu euch und ist soweit unauffällig. https://trace.ntppool.org/traceroute/46.38.224.30?json=0

    Die Rückroute allerdings läuft von euch zu Above.net und anschließend zu Zayo. Dadurch kommt es wohl zu NTP Paketverlusten, konkret der fehlenden NTP Antwort.


    Jetzt ist es so, dass die Situation durch den Pool dahingehend verbessert wird, indem ein 3-Node Monitoring System eingeführt wird. Allerdings löst dies das Problem nicht komplett, da der New York Monitor erhalten bleibt und ebenfalls eine 33% Gewichtung hat. Ebenso gibt es hierfür keinen Termin.


    Eventuell habt ihr ja Lust dem Pool (und mir) zu helfen und euch einmal anzuschauen ob ihr das Routing zu diesem Monitoring Netzwerk so umstellen könnt, dass zumindest Zayo vermieden wird. Zayo ist nicht der einzige ISP der NTP filtert, aber vielleicht hat man mit einem anderen ISP mehr Glück. Einer der NTP-Pool Admins hat hierzu auch interessante Beiträge geschrieben bzw. versucht das auf ISP Seite zu lösen, bisher kein Erfolg, die Filter bleiben bestehen. Siehe hierzu u.A. https://weberblog.net/ntp-filt…blockage-in-the-internet/


    Danke vorab.

  • Den Willen ntp.org zu unterstützen, finde ich lobenswert, aber ...

    Dass der Pool für DE aber nur von ehrenamtlichen betrieben wird, sehe ich jedoch nicht ganz so - der relevante Teil, welche von NTPs beim Pool verwendet werden, sind Server von Service Providern, welches alle dedicated Server sind - was ein NTP auch sein sollte.

    Auch sehe ich den Nutzen nicht darin, Unmengen von virtuellen Servern, dem Pool hinzuzufügen, sondern die physikalischen Ressourcen der ISPs eine genauere Zeit liefern zu lassen.


    Erkläre das "flappging" hier mal bitte genauer - https://www.ntppool.org/zone/de

    Die Genauigkeit erhöht sich, durch die Anzahl von Servern nämlich nicht zwingend.

  • Die IP des Monitoring Systems ist 139.178.64.42


    Die Hinroute läuft von New York über Telia zu euch und ist soweit unauffällig. https://trace.ntppool.org/traceroute/46.38.224.30?json=0

    Die Rückroute allerdings läuft von euch zu Above.net und anschließend zu Zayo. Dadurch kommt es wohl zu NTP Paketverlusten, konkret der fehlenden NTP Antwort.

    Hi aubergine ,


    danke für deine Nachricht. Ich habe mir das kurz angeschaut. Wir schicken den Traffic zu Zayo, da wir mit diesen ein direktes Peering am DE-CIX in Frankfurt haben. Das Zielnetz (139.178.64.42) gehört zu AS54825 (https://peeringdb.com/net/5230), welche ebenfalls am DE-CIX angeschlossen sind, aber derzeit nicht mit uns peeren. Wir werden AS54825 einen Peering-Request schicken und versuchen Zayo hiermit aus dem Pfad zu holen, vielleicht hilft uns das in deinem Fall schon weiter!


    Beste Grüße,

    Theo

  • Hi Theo,

    erst einmal: euer Routing hat sich im IPv6-Bereich in der letzten Zeit wirklich verbessert. Leider habe ich dennoch heute eine neue "Problem"-Destination entdeckt.


    Die Verbindung zu einem niederländischen Serveranbieter ist über IPv6 wesentlich "länger" angebunden. Der Pink ist rund 6ms höher als über IPv4.


    Um folgende IPs handelt es sich:

    Test IPv4: 31.220.6.30

    Test IPv6: 2a01:6f0:ffff:aa::beef


    v4: [Blocked Image: https://img.l1.si/04901b0c-53f3-41b9-94f5-ca24622573b2.png]

    v6: [Blocked Image: https://img.l1.si/e3793090-89ed-4c57-b4a3-8bebfd0eead9.png]


    Könnt ihr da etwas machen?


    Vielen Dank,


    Ben

  • Dass der Pool für DE aber nur von ehrenamtlichen betrieben wird, sehe ich jedoch nicht ganz so - der relevante Teil, welche von NTPs beim Pool verwendet werden, sind Server von Service Providern, welches alle dedicated Server sind - was ein NTP auch sein sollte.

    Auch sehe ich den Nutzen nicht darin, Unmengen von virtuellen Servern, dem Pool hinzuzufügen, sondern die physikalischen Ressourcen der ISPs eine genauere Zeit liefern zu lassen.

    Sehe ich auch so. Von gewissen Dingen sollte man als kleiner VPS-Kunde einfach Abstand nehmen. Dazu gehört das Betreiben öffentlicher NTP-Nodes ebenso wie der Betrieb öffentlicher DNS-Resolver, 6to4-Gateways und ähnlicher Infrastruktur. Netcup wird sicher selbst mit der einen oder anderen Maschine daran teilnehmen, und das reicht dann auch.

  • kannst du bitte mal einen Rückweg-MTR machen und hier teilen?


    Hi Theo,


    danke für deine Antwort.


    Hier der mtr über IPv4 seitens 31.220.6.30

    Hier der mtr über IPv6 seitens 2a01:6f0:ffff:aa::beef

    Code
    1. Start: Wed Dec 2 22:07:14 2020
    2. HOST: [x].[mitbewerber].com Loss% Snt Last Avg Best Wrst StDev
    3. 1.|-- gateway 20.0% 10 0.3 0.4 0.3 0.8 0.0
    4. 2.|-- 2a00:1768:4001:5::1 20.0% 10 1.8 2.0 0.5 9.2 2.9
    5. 3.|-- ae3-1337.bbr02.anx63.ams.nl.anexia-it.net 10.0% 10 1.8 2.5 1.0 9.1 2.5
    6. 4.|-- 2a00:11c0:47:1:47::213 10.0% 10 22.9 22.9 22.6 24.2 0.4
    7. 5.|-- 2a00:11c0:47:3::33 10.0% 10 17.0 17.2 16.8 18.2 0.4
    8. 6.|-- serv1.hostedasen.de 10.0% 10 17.0 17.1 16.9 17.5 0.0



    Vielen Dank,


    Ben

  • Hi Theo,


    vielen lieben Dank für deine schnelle Reaktion und die gute Lösung :-)

    Ich hoffe mal die Mühe lohnt sich und der Request wird akzeptiert.


    VG

  • benja danke, das ist so korrekt. Wir routen hier in diesem Fall auf Grund einer technisch/wirtschaftlichen Entscheidung unterschiedlich. IPv4 läuft in diesem speziellen Fall von Amsterdam über Frankfurt nach Nuremberg, IPv6 läuft von Amsterdam über Hamburg und Berlin nach Nüremberg. Die 5ms sollten hier aber keine Relevanz haben.

  • der Request wurde akzeptiert, die Sessions sind eingerichtet. Bitte noch mal testen, danke!

    Also ich sehe hier noch sehr viel zayo :/

    VPS 500 G8 Plus | VPS Karneval 2020 | Webhosting EiWoMiSau


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

  • Also ich sehe hier noch sehr viel zayo :/

    Leider, ja. Ursache ist, dass uns AS54825 den relevanten Prefix nicht schickt über die Peering-Session. Auf Nachfrage bei Packet wurde uns mitgeteilt, dass dies auch nicht möglich ist, da der Prefix zur US-Region gehört und in Europe nicht über Peering erreichbar ist. Insofern kommen wir hier um Zayo nicht drumherum, da Packet diese zum "primären" Upstream auserkoren hat. Ich kann euch nur Empfehlen mit dem Betreiber der Node bei Packet Kontakt aufzunehmen, sorry, wir haben hier keine weiteren Möglichkeiten. Routing-Entscheidungen werden leider technisch und wirtschaftlich und vor allem beidseitig beeinflusst.