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.

    WH 4000 SE | VPS 1000 G8 Plus | VPS Karneval 2020

    Quote from aubergine

    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

    Quote from douzer

    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.

    Quote from [Anexia] Theo V.

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

    Quote from [Anexia] Theo V.

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

    Also ich sehe hier noch sehr viel zayo :/

    RS Brezn | VPS 500 G8 Plus | VPS Karneval 2020 | Webhosting EiWoMiSau


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

    Quote from Virinum

    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.

    Hi!

    Ich habe gerade aus Zufall gesehen, dass Traffic zu AS3209 über AS3320 geht. Besteht da nicht eine Session am DE-CIX oder habe ich da gerade nur einen Schluckauf erwischt?



    Hinzu ist es genau so:


    Bei IPv6 auf beiden ebenso (den Hinweg spare ich jetzt mal aus):


    Will man sich Transit über die DTAG wirklich antun? Die sind ja nicht die günstigsten Mitbewerber. 8o


    Beste Grüße,

    Steven

    Quote from StevenK

    Hi!

    Ich habe gerade aus Zufall gesehen, dass Traffic zu AS3209 über AS3320 geht. Besteht da nicht eine Session am DE-CIX oder habe ich da gerade nur einen Schluckauf erwischt?

    Hi StevenK - das hast du richtig bemerkt, wir haben ein Peering mit AS3209, nutzen es aber derzeit nicht, weil es vor kurzem eine Störung am DE-CIX in Frankfurt gab und damit verbunden auch Beschwerden von Kunden. Wir beobachten die Situation noch eine Weile, dann schalten wir das Peering wieder ein. AS3320 ist zwar teuer, aber gut ;)

    Hallo [Anexia] Theo V. ,


    könntet ihr euch noch mal das Routing zu OnVousHeberge in Limburg (51.68.172.1 (gateway) oder 51.195.74.98) anschauen?


    mtr von OnVousHeberge aus:

    und von netcup aus:


    Da sollte doch noch etwas möglich sein, insbesondere wenn es von einem Mitbewerber aus Falkenstein in nur 6ms geht. Da sind die 14ms schon ein größerer Unterschied.

    Vor allem, wenn es dann über IPv6 noch mal 11ms länger dauert ;)


    Vielen Dank,


    benja

    Quote from benja

    könntet ihr euch noch mal das Routing zu OnVousHeberge in Limburg (51.68.172.1 (gateway) oder 51.195.74.98) anschauen?


    [...]

    Da sollte doch noch etwas möglich sein, insbesondere wenn es von einem Mitbewerber aus Falkenstein in nur 6ms geht. Da sind die 14ms schon ein größerer Unterschied.

    Vor allem, wenn es dann über IPv6 noch mal 11ms länger dauert ;)


    Hallo benja,


    ich bin zwar nicht Theo, arbeite aber in seinem Team.

    Gestern gab es einen größeren Ausfall am DE-CIX, weshalb wir temporär andere Routen bevorzugt haben (in diesem Fall via AMS-IX). Seit ca. 7:50 heute Morgen ist der DE-CIX wieder aktiv und deine Latenz sollte nun deutlich besser sein.

    Senior Network Architect

    ANEXIA Deutschland GmbH