Backbone / Routing Q&A

  • Kann es sein, dass Ihr momentan im Kreis routet?

    Meine IP ist in Bayern, dynamisches Kabel Vodafone. Die zwei Hops davor sowie der letzte Hop zu meinem Server sind entfernt (XXXXXX).

    Von mir aus nach Frankfurt, dann Wien, dann Nürnberg, dann Netcup macht ja wohl gar keinen Sinn.


    Vergleiche auch https://forum.netcup.de/admini…ungsprobleme-mit-vserver/

    Privat: VPS 1000 G8 Plus | RS Fast Rabbit OST21 (~RS 8000 G9), VPS Funny Bunny OST21 (~VPS "2500" G9), beruflich noch einige mehr

  • mainziman   femur   TBT


    Das ist korrekt derzeit, leider. Unsere Verbindung zwischen Nürnberg und Frankfurt ist derzeit bedingt durch einen Faserschaden (hunderte Glasfaserpaare durchtrennt durch Bauarbeiten) unterbrochen. Wir routen den Traffic aus Nürnberg derzeit über Wien und Amsterdam. Daher die höheren Latenzen und die längeren Wege. Wir haben noch keine garantiere ETR, aber wir erwarten die Behebung bis spätestens morgen am Vormittag. Ihr seht dies dann sofort in MTRs und euren Stats! :)

  • Passt anscheinend wieder. Zumindest bei mir:

    Code
    1. 4 9 ms 10 ms 10 ms ip5886c12c.static.kabel-deutschland.de [88.134.193.44]
    2. 5 10 ms 9 ms 12 ms 145.254.3.86
    3. 6 * * * Zeitüberschreitung der Anforderung.
    4. 7 * 61 ms 13 ms 145.254.2.195
    5. 8 19 ms 18 ms 12 ms ae3-1337.bbr02.anx25.fra.de.anexia-it.net [80.81.195.166]
    6. 9 17 ms 17 ms 15 ms ae1-0.bbr01.anx84.nue.de.anexia-it.net [144.208.208.140]
    7. 10 15 ms 82 ms 75 ms netcup-gw.bbr01.anx84.nue.de.anexia-it.net [144.208.211.31]

    Danke für Euere Arbeit, auch am Wochenende!

    Privat: VPS 1000 G8 Plus | RS Fast Rabbit OST21 (~RS 8000 G9), VPS Funny Bunny OST21 (~VPS "2500" G9), beruflich noch einige mehr

  • Nachdem das Ganze ja hier dankenswerterweise von einem Kollegen mal gepostet wurde, werde ich mich jetzt hier doch auch gerne mal verewigen, vielleicht hat die Swarmintelligenz ja eine Idee.

    Der Support ist zwar schon dran seit 10 Tagen, aber evtl. bringts ja trotzdem was.


    Offenbar gibt es seit einiger Zeit (wie ich hörte seit knapp 3 Monaten), aber seit knapp 2 Wochen massiv, starke Probleme im Peering zwischen Netcup/Anexia und Telia.


    Ich habe auf meinen Servern, neben dem großen Kundenstamm aus der EU, auch ähnliche viele Kunden aus den USA.

    Das Peering zwischen Großteilen da drüben und Netcup läuft über Telia.


    Hier dann das Problem:

    Auf all unseren Servern, RS und VPS, beide sowohl alter Generation als auch latest, gibt es sporadisch massive Einbrüche der Download-Geschwindigkeit, ausschließlich in Richtung Netcup. Und wir reden hier nicht von einer Halbierung, sondern von Downloadeinbrüchen auf bis zu 12 kb/s.

    Das betrifft übrigens, fast schon lustigerweise, sogar die netcup.de/eu Website. Interessanterweise kann man ab und zu mal eine schnelle Verbindung "bruteforcen", in dem man den Download ständig abbricht und neustartet, bis mal eine schnelle Verbindung dabei ist. Die Erfolgsrate liegt da inzwischen aber vielleicht noch bei 10%.


    An den Konfigurationen oder ipv4/ipv6 Themen liegts in der Tat nich.. Auch liegt es nicht partout an Telia, die zwar immer mal wieder etwas Package Loss haben, aber dennoch zu anderen Servern hier in Deutschland großartige Performance über den Teich bringen.

    Nach Rücksprache mit Kunden, die ich, fast schon peinlich, kürzlich erst geworben hatte, tritt das Ganze wohl auch auf verschiedenen Konfigurationen, Nodes, und Betriebsystemen auf, und bei 1G Interfaces wie bei 2,5G.

    Betroffen sind demnach Clients aus den USA, Skandinavien, und teilweise sogar Deutschland (siehe Forenticket oben)


    Offenbar gibts seit gestern einen Server zum Aufzeichnen von Telemetriedaten bei euch, aber wer weiß - womöglich finden wir ja hier die zündende Idee?



    Anbei mal ein beispielhafter Traceroute aus Chicago, und ein MTR von AWS-EC2 US-West:




    Da der Support dran ist, findet sich eventuell auch schon bald eine Lösung, aber zur Not dient das Ganze hier auch schon als Information für andere Kunden mit Problemen.


    LG

    DevOps Engineer, Musiker, Enthusiast


    1x VPS2000 G8

    1x RS 500 SSD G8

    1x VPS Ostern L OST20

    1x RS Fast Rabbit OST21

  • Hallo zusammen, danke für eure Meldungen diesbezüglich. Wir stimmen uns mit dem netcup Support ab und sind hier gemeinsam auf der Suche nach dem kleinsten gemeinsamen Nenner. Ich kann zumindest zu unserer Telia-Anbindung sagen, dass wir hier über 500 Gbit/s Kapazität vorhalten in Frankfurt, Wien und Amsterdam, die bei weitem nicht ausgelastet sind. Auch sehen wir auf diesen Verbindungen keine Fehler auf Ports oder Unregelmäßigkeiten auf den BGP-Sessions.


    Der netcup Support wird euch in den jew. Support-Tickets umgehend informieren, wenn die Ursache eingegrenzt bzw. behoben ist.

    Fragen könnt zum Routing könnt ihr mir gerne hier im Thread stellen, ich schaue so oft wie möglich rein - danke!

  • Sehr gut zu hören Theo. Da fasst man wieder etwas Mut. Habe mal testweise meine Webseite auf einen VPS der deutschen Konkurrenz umgezogen und tatsächlich wird berichtet das der Seitenaufbau schon gefühlt seit ewig nicht mehr so schnell war. Und es handelt sich halt um 5 Sekunden statt 100, daher ist das nicht gerade eine kleine Optimierung.


    Netcup ist absolut ungeschlagen bei der CPU Performance, daher will ich das keinesfalls dabei belassen. Wenn der Fehler bald eingegrenzt ist, freu ich mich drauf sofort wieder mit meinem bestehendem Setup weiter zu machen. Ärgere mich das ich die Reports nicht früher ernst genommen habe, weil natürlich kein Fehler zu erkennen war, insbesondere nicht aus Deutschland heraus.


    Hier noch ein paar interessante Observationen:

    1. Wie der Kunde oben erwähnt hat, selbst ein JPEG von der offiziellen Netcup.eu/de Webseite herunterladen welches embedded ist, ist von dieser Störung betroffen und wird oftmals auf 12 kb/s gebremst. Genauso wie bei meinem Server. Natürlich nur bei Telia Verbindungen und rein zufällig

    2. Wenn ich allerdings was von hier herunterlade (https://anexia.com/de) ist die Geschwindigkeit 100% immer ausgezeichnet ohne Ausnahme, selbst in 50 Tests was die Statistik nicht hergibt für Netcup. Der MTR hat ergeben das anexia.com und mein Netcup Server genau gleich geroutet wird aus den USA, mit Ausnahme des finalen "netcup-gw.bbr01.anx84.nue.de.anexia-it.net" Sprungs natürlich

    3. Das Problem tritt wirklich nur bei Verbindungen auf die über Telia gehen. Selbst das weit entfernte Japan kriegt ne deutlich bessere Verbindung zustande als Schweden, solange Telia nicht von der Partie ist


    Zusammengefasst: Es scheint mit Telia zusammenzuhängen, betrifft allerdings nicht Anexia komplett, sondern speziell den Netcup Bereich von Anexia.

  • Hallo,

    ich habe der Neugier wegen - weil der gewaltig lange traceroute 2 Posts weiter oben mir nicht ganz sauber erscheint - von

    2 meiner RS bei netcup jeweils einen traceroute zu 34.221.151.253 gemacht

    einmal

    pasted-from-clipboard.png

    und einmal

    pasted-from-clipboard.png

    und wenn man diese beiden vergleicht fällt einem auf, dass beim oberen der Hop 6 und beim unteren der Hop 5 ident sind

    danach aber nicht mehr, und das bei mehreren Versuchen ...

    verursacht Telia selbst das Problem?

  • Die Traceroutes von/zu AWS sind oftmals eher ungewöhnlich, das hab ich auch schon mal festgestellt. Sorgt allerdings dafür das mein Japan VPS keine Probleme hat, da das Peering exklusiv über AWS Nodes bis nach Frankfurt erfolgt. Kein Telia, kein Problem.


    Das ganze betrifft halt auch nur den Upload bei Netcup. Bei Download ist der Netcup Server blitzschnell wie eh und je Dateien von US Servern herunterzuladen. Telia hin oder her. Problematisch wird es nur wenn Daten von Netcup rausgehen. MTR von Netcup zu meinem US VPS ist praktisch identisch wie der umgekehrte MTR, beides Telia. Aber nur wenn der US VPS was von Netcup runterladen will tritt das Problem auf.


    Alles schon extrem merkwürdig. Besonders das die Anexia Homepage mit identischer MTR nicht betroffen ist, die Netcup Homepage allerdings schon obwohl das ja relativ identisch intern ablaufen müsste bei Anexia.

  • Danke für die Beobachtung und Tests, aber ja, da scheint AWS einfach zu routen, wie sie gerade Spaß dran haben. Der Traceroute sieht da in 4 Versuchen jedes Mal anders aus. Der AWS Server ist auch ein reiner Test-Case, das Problem lässt sich von 2 VPS in zwei Datacenters an zwei verschiedenen Standorten (Chicago / LA) nachstellen und wird mir, wie eingangs erwähnt, vor allem von Kunden unterschiedlichster Provider beschrieben...halt alle die, die übersee per Telia mit Anexia peeren. Das Problem tritt aber halt nur hinter dem Anexia Backbone auf, nicht bei einem Server bei, in meinem Fall, Netcologne - trotz Telia Peering.


    Angesichts der Tatsache, dass der BGP-Peer zu Telia für Netcup und Anexia wohl gleich ist, und der Aussage von Theo (danke!), dass der Link zu Telia sauber scheint und nicht ausgelastet ist, kann der Fehler eigentlich nur in genau einer Strecke liegen:

    Der Weg zwischen dem Telia-Peering-Stack bei Anexia und den Netcup Nodes. Da es auch auf der Netcup Website passiert, ist es auch keine individuelle Node.
    Es ist also entweder das Netcup Gateway (netcup-gw.bbr01.anx84.nue.de.anexia-it.net?), oder das Interface im Anexia Stack, welches den Netcup Traffic weiter routet, weg vom Anexia-Backbone.


    Eine andere Erklärung bietet sich, meiner Meinung nach, gar nicht an.

    DevOps Engineer, Musiker, Enthusiast


    1x VPS2000 G8

    1x RS 500 SSD G8

    1x VPS Ostern L OST20

    1x RS Fast Rabbit OST21

  • Hallo zusammen.


    Gemeinsam mit dem netcup Support bzw. Operations Teams werden wir im laufe der nächsten Stunden einige A/B-Tests bzw. Tests zur Eingrenzung möglicher Ursache durchführen. Wir bitten noch um etwas Geduld, danke für euer Feedback und vielen Traceroutes. Ein Update erfolgt abschließend über eure jew. Support-Tickets.


    Beste Grüße,

    Theo

  • ich bin unheimlich neugierig, hier 2 traceroutes, dass sich diese unterscheiden ist klar,

    da ich ja nur IPv4 zu Hause habe, geht der IPv6-Datenverkehr durch einen vServer hier bei netcup - personal/private 6in4 gateway :)


    hier der traceroute mit IPv4 (Hops mit RFC1918 Adressen unkenntlich gemacht)


    pasted-from-clipboard.png


    und hier der traceroute mit IPv6 (lokaler /64-Prefix sowie Tunnel unkenntlich gemacht)


    pasted-from-clipboard.png


    des eiert aber schon gewaltig durch die Weltgeschichte mit IPv6 ..., ist hier Telia an beiden Enden der Verursacher?

  • Hi mainziman ,


    wie schon angemerkt sind die v4 und v6 routen deutlich anders, da du dafür ja ein Interesse hast versuch ich das mal aufzubereiten, ich kann gerade eh nicht schlafen.

    die v4 ip liegt in 200.7.7.0/24, diese route lernen wir über 3 Pfade:

    Code
    1. mfrenzel@bbr02.anx25.fra.de> show route protocol bgp 200.7.7.3 table inet.0 | match path
    2. AS path: 262589 14259 27678 I, validation-state: valid
    3. AS path: 262589 14259 27678 I, validation-state: valid
    4. AS path: 3320 6762 14259 27678 I, validation-state: valid

    AS262589 = Internexa ist hierbei der kürzeste pfad, wir lernen diese über den DE-CIX Frankfurt Route Server.

    Konkret also Internexa -> GTD -> NIC.cl


    die v6 IP liegt in 2001:1398:5::/48, diese route lernen wir über 9 Pfade:

    Code
    1. mfrenzel@bbr02.anx25.fra.de> show route protocol bgp 2001:1398:5::6003 table inet6.0 | match path
    2. AS path: 1299 174 18747 27678 I, validation-state: unverified
    3. AS path: 2914 174 18747 27678 I, validation-state: unverified
    4. AS path: 1299 174 18747 27678 I, validation-state: unverified
    5. AS path: 1299 174 18747 27678 I, validation-state: unverified
    6. AS path: 1299 174 18747 27678 I, validation-state: unverified
    7. AS path: 2914 174 18747 27678 I, validation-state: unverified
    8. AS path: 3320 5511 52468 18747 27678 I, validation-state: valid
    9. AS path: 6939 262589 14259 27678 27678 27678 I, validation-state: valid
    10. AS path: 6939 262589 14259 27678 27678 27678 I, validation-state: valid


    Wir nehmen hier Telia.

    Was dabei auffällt ist, dass wir diese route nicht von AS262589 über den DE-CIX Routeserver lernen, AS262589 taucht nur hinter Hurricane Electric AS6939 auf.

    Ein kurzer blick ins DE-CIX LookingGlass verrät auch warum: https://lg.de-cix.net/routeser…v6?s=asn&o=asc&q=AS262589

    Die IPv6 Session ist seit einem Jahr down. Warum weiß nur Internexa selbst.

    Unabhängig davon fällt auch auf, dass AS27678(nic.cl) hier 3 mal am ende vorkommt, also prependet ist. Warum das so ist, weiß nur nic.cl. AS-Path prepending verwendet man um das routing zu beeinflussen, BGP nimmt meist den kürzesten Pfad, man könnte das also als versuch der nic.cl werten diesen Pfad schlechter zu machen.


    Das ist also die Erklärung warum unterschiedliche Pfade für v4 und v6 verwendet werden.


    Schauen wir uns mal den v4 Pfad an:



    Auffällig ist, dass zwischen Hop 4 und 5 ca. 110ms liegen, Internexa Peert also relativ sicher nicht in Frankfurt sondern kommt über ein Remote Peering rein.

    Kurzer blick auf das DE-CIX LG bestätigt auch das, Internexas router steht irgendwo in New York (https://lg.de-cix.net/routeser…/protocols/R194_15/routes -> klick auf eine route und blick auf die communities). Da diese ganze DE-CIX remote peering Geschichte reines Layer2 ist sehen wir leider nichts vom tatsächlichen Pfad, das Paket kommt in Frankfurt rein und landet irgendwann in NYC.

    Danach kann man eigentlich nur noch Hops Raten, das sind ca. 8500km Luftlinie, also vmtl. das 1.5-fache an Faserweg, was mit ca. 130ms auch ganz gut hinkommt (Faustformel: 100km = 1ms RTT). Die geringe Anzahl an Hops könnte darauf hinweisen, dass internexa hier Seerouten nimmt, und nicht über den Landweg nach Chile kommt.


    Der v6 Pfad sieht so aus:


    Wir geben es also von Nürnberg nach Wien, dort an Telia, die geben es in wien an cogent und von dort geht es

    VIENNA -> MUNICH -> FRANKFURT -> PARIS -> BINGHAMTON(also new york) -> WASHINGTON -> ATLANTA -> MIAMI

    Dort wird es an IXFNETWORKS übergeben (hop 16), und die latenz steig, vmtl. geht es auch hier über ein seekabel, und landet dann auf relativ direktem wege in chile.


    In Summe geben sich v4 und v6 von der Latenz auch nicht viel, ca 19ms. was sich relativ einfach erklären lässt: Wir geben das Paket von NUE nach Wien an Telia, die geben es an cogent, die wiederum bringen es über Frankfurt nach Paris.

    Warum ist das so?

    BGP weiß von der Entfernung natürlich nichts, sondern sieht nur den AS-Pfad, im BGP output von vorhin ist der 1. unser Telia Transit in Wien, der 3. unser Telia Transit in Frankfurt. Die AS-Pfade sind exakt gleich und am Ende vom Tag gewinnt die ältere Route (weil diese als stabiler angesehen wird), und das ist "leider" die in Wien, die grandiose 35min älter ist.


    Konkret heißt das, dass wir hier noch etwas optimieren können, was wir am Montag auch tun werden, insofern Danke für den Hinweis.

    Die Anzahl der Hops ist allerdings nicht wirklich ein Indiz, weil das durch die Layer2 Remote Peering Geschichte verdeckt wird.


    Ich hoffe das ganze war etwas interessant, ich zumindest kann jetzt ruhig schlafen ;)


    Noch eine Bitte an alle hier: bitte nutzt mtr unter linux oder winMTR auf windows statt traceroutes. postet bitte auch keine screenshots sondern kopiert den output in ein code feld, sonst müssen wir beim debuggen alles von hand abtippen.

  • Habe gerade ein "merkwürdiges" Routing in Richtung Telekom -> Nürnberg:

    Frankfurt -> Wien -> Nürnberg? Latenz ist normal bei ca. 9-12ms damit jetzt bei ca. 30ms


    Komischerweise ist das ganze aus dem in Interxion Madrid "direkt" aus Frankfurt -> Nürnberg (man beachte den "Umweg" über Amsterdam):

    Code
    1. traceroute to YYY.YYY.YYY.YYY (YYY.YYY.YYY.YYY), 30 hops max, 60 byte packets
    2. 1 10.77.13.1 (10.77.13.1) 1.372 ms
    3. 2 10.60.44.5 (10.60.44.5) 1.725 ms
    4. 3 10.50.110.67 (10.50.110.67) 31.419 ms
    5. 4 ae3-1337.bbr02.anx63.ams.nl.anexia-it.net (80.249.213.102) 32.219 ms
    6. 5 ae2-0.bbr02.anx84.nue.de.anexia-it.net (144.208.208.213) 53.839 ms
    7. 6 netcup-gw.bbr02.anx84.nue.de.anexia-it.net (144.208.211.11) 53.453 ms
    8. 7 YYYYYYYYYYYY (91.204.45.100) 53.775 ms
  • Geht auch über Österreich: