Posts by benja

    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

    Ich habe genau den gleichen Fall gerade. Total nervig. Warte jetzt seit mehr als 4 Stunden auf meinen Reinstall und traue mich nicht wirklich den Notfallsupport, wegen der möglw. anfallenden Gebühren, zu kontaktieren.


    Bin seit 2017 netcup-Kunde und wirklich zufrieden, bis auf die hohen Steal-Werte in der VPS Serie (aber das ist ja ein anderes Thema).

    Gerade gesehen, dass es bei dem Anbieter mit den zwei Einsen ein Angebot für einen VPS mit 1 Core, 512MB RAM, 10GB SSD, 400Mbit/s Netzwerk, unbegrenzt Traffic für 1€ im Monat gibt. Entweder 12 Monate oder monatlich mit 10€ einmaliger Gebühr. Ist zwar nicht mehr die neueste Xeon Generation mehr, aber.... 1€. Sowas bei Netcup würde mich auch noch freuen :P VPS 10-50 lässt grüßen. Meistens brauche ich einfach den vielen RAM nicht, 2GB beim VPS 200 sind zwar schön, aber für mich Overkill. Ein RS 500 G9 wäre auch schön :)

    Na dann los. Zeit die Bestpreisgarantie zu nutzen *hust*.



    Nochmal ein Update zum Steal. So schaut's auf dem VPS 2000 G8 Plus aus, wenn der ElasticStack hochfährt:

    cpu_load_vps.PNG


    Aber das sind die 3 extremsten Minuten auf dem Server.

    Dito. Ich habe auch den VPS 2000 G8 Plus und es sieht 1:1 so aus. Immer wenn mehr Last kommt, taucht sofort der CPU-Steal dazu auf.


    Der RS 4000 G9 ist aber schon bestellt, muss nur noch eingerichtet werden.


    Grandios, da kauft man für 30€ nen Premium Zertifiziertes 7,5m HDMI Kabel uns ein normales 5m für 7€. Das Teure überträgt nicht mal ein Signal - haha. DAs Billige funktioniert bis jetzt ohne Probleme.


    Kann wer sonst ein gutes 7,5m HDMI Kabel empfehlen, vorzugsweise bei Amazon?


    Hab bisher nur gute Erfahrungen mit den von KabelDirekt auf Amazon.

    Hmm... Ich weiß nicht.

    Ich habe den speedtest von ookla jetzt mal ausprobiert, aber im Vergleich zum "normalen" speedtest-cli erwische ich da ziemliche Krücken bei den Testservern. Insbesondere der upload ist tw. mickrig. Und auch die Schwankungen innerhalb der einzelnen Servern sind sehr groß.

    Liegt nicht an meinem Server. Da habe ich vorher und nachher mit dem Standard speedtest-cli getestet. Da habe ich auch deutlich mehr Testserver zur Auswahl.


    Ich habe jetzt aber auch nicht wirklich intensiv längere Zeit durchgetestet, muss ich zugeben.

    Du kannst ja das offizielle Ookla Tool auch zur Auswahl eines bestimmten Servers zwingen. Zum empfehlen ist hierbei z.B. der Server von meerfarbig o.ä.

    Genau sowas brauche ich nur mit der 12 Kerne, 64GB RAM, 2TB SSD Konfiguration um glücklich zu werden.


    Minecraft Server und Renderaufgaben wollen seine Leistung haben.

    Meine Bestellbestätigung ist jedenfalls von 00:04, aber ich habe sie bereits in der ersten Minute in den Warenkorb gelegt.


    Vielleicht gibt es noch Rückläufer in der nächsten Stunde, wenn die nicht bestellten Warenkörbe ablaufen…

    netcup verschickt Bestellbestätigungen? Ich hab zwar angzeigt bekommen, dass meine Bestellung eingegangen ist, aber nichts per Mail

    Bitte nicht den Python speedtest-cli nutzen. Der ist für solche Geschwindigkeiten nicht ausgelegt.


    Nutzt lieber den offiziellen Speedtest CLI von Ookla, welchen ihr euch hier auf den Server herunterladen könnt:

    https://www.speedtest.net/de/apps/cli


    Der sollte dann auch Geschwindigkeiten bis 10G problemlos wegstecken, sofern eure Gegenstelle (der entsprechende Speedtest.net Server) das auch packt.

    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,

    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

    Hallo benja ,


    natürlich habe ich deinen Eintrag gesehen und wir haben uns das im Team angeschaut. Es ist leider so, dass Routing-Entscheidungen grundsätzlich auf Grund der bekannten BGP-Entscheidungskriterien getroffen werden. Dies ist leider nicht immer der aus Kundensicht beste Weg. Hinzu kommt, dass das Routing durch Zusammenschaltungen, die nur an bestimmten Punkten existieren oder auch Traffic-Engineering-Maßnahmen des anderen Providers beeinflusst wird. Wir versuchen hier regelmäßig "gegenzusteuern", müssen natürlich aber auch immer das Gesamtbild (für alle Kunden) im Blick haben. Sobald wir hier eine Lösung haben, melde ich mich bei dir.

    Danke für die Klarstellung und sorry für die fehlerhafte Verdächtigung. :)


    Außerdem danke für deine Bemühungen. 🙂


    VG

    benja

    Hallo Theo,


    hast du dir die Routing-Problematik zu den von mir, bzw. uns, genannten Zielen angeschaut? Das Problem wurde immer noch nicht besser. Wirres Routing herrscht auf IPv6 immer noch vor. Wirklich schade, dass euer Routing so "schlecht" auf IPv6 ist.

    Vor allem zu On Vous Héberge ist es ärgerlich. 22ms über den AMS-IX müssen doch wirklich nicht sein. Mein interner Wechsel zu IPv6, welcher sich auch auf Latenz verlassen muss, zieht sich daher hin. Zu einem anderen großen Hostinganbieter in Nürnberg gehts auch in 6.2ms.

    Zu den anderen Zielen scheint sich auch nichts groß am Routing geändert zu haben. Schade, dass es dies bezüglich noch keine Antwort von dir gab.


    Liebe Grüße,

    benja

    [Anexia] Theo V.


    hier die IPs:

    0VH LIM v4: lim.smokeping.0vh.net

    0VH SBG v4: sbg.smokeping.0vh.net

    bitte 0 beachten, irgendein komischer Wortfilter ist ja hier aktiv ._.

    H0stHatch Amsterdam v4: 31.220.6.30

    v6: 2a01:6f0:ffff:aa::beef

    H0stHatch Stockholm v4: 176.126.70.17

    v6: 2a00:1a28:1157:dd::beef

    H0stHatch Oslo v4: 185.175.56.60

    v6:2a0d:5600:30:40:dd::beef

    ED1S Graz v4: 151.236.30.10

    v6: 2a03:f80:ed15:151:236:30:10:1

    ED1S Sevilla v4: 37.235.53.10

    v6: 2a00:1d70:ed15::1


    benja.

    Hier hab ich noch ein paar Kanidaten für wirres IPv6 Routing.


    Komsich hoher Ping zu AS63473, HostHatch Amsterdam.

    über v4 12ms:[Blocked Image: https://img.l1.si/1e19194b-0926-4ee8-b265-e9cc747bf7e7.png]

    über v6 23ms:

    [Blocked Image: https://img.l1.si/8d2854ae-c564-4822-b4cd-0492faf16f53.png]


    Interessant geht's auch zu deren Stockholm Location. 35ms über v4, 39ms über v6. Unterwegs gehts bei IPv6 über "win-xx-link.telia.net". Vermutlich über Wien? Warum?

    v4:[Blocked Image: https://img.l1.si/52135442-b517-4cc6-bed3-415d78e4afc4.png]


    v6: [Blocked Image: https://img.l1.si/ff6a6b4d-317c-47ae-9f0e-3ec810a90773.png]



    und genauso über Wien nach Oslo, bei IPv6...

    v4: [Blocked Image: https://img.l1.si/3e964049-8027-4715-8282-654ab921d943.png]

    v6: [Blocked Image: https://img.l1.si/ad307881-6351-4ccb-9017-16e1e9826190.png]


    und wtf macht ihr bei edis Graz. Bei IPv4 gehts direkt über den VIX mit 12ms, IPv6 geht über den AMS-IX und kommt bei 72ms (!) heraus.

    v4: [Blocked Image: https://img.l1.si/38e078e2-3546-4ebf-84a3-84087260986c.png]

    v6: [Blocked Image: https://img.l1.si/f0e3d664-69a9-4d92-bb3e-11f7c811394b.png]


    Spanien sieht auch spannend aus. v4 direkt über Frankfurt - 41ms bis zum Ziel; v6 über den AMSIX - 60ms zum Ziel

    v4: [Blocked Image: https://img.l1.si/af787380-e3e1-46eb-9827-aae3b5a24ca4.png]

    v6: [Blocked Image: https://img.l1.si/c9b1822d-8eb0-4ba2-a611-69ed10cf1b81.png]


    Ich hoffe, dass du da irgendwas machen kannst. IPv6 sieht wirklich recht traurig zu einigen Destinationen aus.

    Da man ja anscheinend hier relativ schnell seine Nachrichten nicht mehr editieren kann, hier noch ein Problem.

    Das Routing zu "On vous héberge" in Limburg scheint auch kaputt zu sein. Alles geht über den AMS-IX, wenn man sich für IPv6 entscheidet.

    IPv6 zu 2001:41d0:701:1100::4

    [Blocked Image: https://img.l1.si/e126906c-3373-4860-bd35-b6acbb2b4202.png]


    Bei IPv4 scheint alles gut auszusehen:

    [Blocked Image: https://img.l1.si/a08f1fa7-a09f-4fad-b7b0-339e33020001.png]

    Obwohl beide IPs nach Limburg gerouted sind, lässt sich hierbei ein starker Unterschied feststellen. Ich hoffe, dass du da was machen kannst.


    Das gleiche Spiel findet auch zu "On vous héberge" in Strasbourg (2001:41d0:401:3200::1) so statt:

    [Blocked Image: https://img.l1.si/ab68737d-c36f-42a3-aee7-466895db5657.png]


    IPv4 wiederum völlig normal: [Blocked Image: https://img.l1.si/67454ac8-3fc8-4db9-b4e4-0fbe8ba3ff86.png]


    Viele Grüße, benja

    Ahoi Theo,

    magst du mal über das Routing zu 2a04:5b80:300:2:: ausgehend von netcup drüberschauen? Die Route scheint über Hurricane Electric in Amsterdam zu gehen, obwohl der Weg über IPv4 direkt per lwlcom in Frankfurt geht (45.87.161.1)

    v4: [Blocked Image: https://img.l1.si/a42c1b1b-514b-4c2d-8dfb-f4ee77af161f.png]

    v6: [Blocked Image: https://img.l1.si/6744d28a-46c2-4330-b17d-664af662468a.png]

    Anscheinend routelooped man am Ende, aber mir geht's eher um den Teil davor, welcher auch andere IPv6s des Bereiches betrifft.


    Ungewöhnlich gehts auch zu 2a07:59c6:ee00::220. Ping über 20ms; per IPv4 (185.133.208.220) nur 5ms.
    Plant ihr eigentlich noch mehr PTRs auch auf IPv6 zu setzen? Dann könnte man besser die Routen nachvollziehen.

    v4: [Blocked Image: https://img.l1.si/4cafba8e-bec0-4721-8ba7-2b309b7b6436.png]

    v6: [Blocked Image: https://img.l1.si/e46e9c55-42c7-4c62-afa3-a0cd63e4fe9c.png]


    Danke,

    und viele Grüße,

    benja