Beiträge von [netcup] Moritz F.

    Hallo zusammen,


    danke für die guten Infos, nach genauerer Analyse scheint es ein Problem auf dem Peering zwischen fonira und uns am DE-CIX zu geben, wir haben unseren Traffic am DE-CIX route server vorerst deaktiviert und schauen uns das gemeinsam an.


    Aus unerklärlichen Gründen können wir die Peer-IP von fonira im DE-CIX peering LAN nicht erreichen.

    Ich halte euch auf dem laufenden sobald ich etwas neues höre.

    bjo ECIX Ports in FRA oder DUS sind bei uns aktuell nicht geplant.


    RAD750 ich würde dich bitten solche Aussagen zu unterlassen, manche Probleme sind komplexer als nur ein kaputtes Kabel o.ä. und brauchen teilweise Wochen an komplexem Debugging mit Herstellern und co. Davor ist niemand in der IT geschützt, auch nicht wir, und niemand hat es verdient deshalb als inkompetent dargestellt zu werden.

    Wie von bjo richtig vermutet haben wir den DE-CIX aktuell deaktiviert, da es in den vergangenen Wochen zu mehreren Ausfällen gekommen ist, und der DE-CIX uns bis dato kein Root Cause nennen, oder diese gar beheben konnte. Auch heute Mittag kam es erneut zu einem Ausfall, der jedoch durch das rerouting keinen Impact hatte.

    Sobald es durch den DE-CIX eine verlässliche Agenda gibt werden wir unsere Ports wieder aktivieren.

    Danke, das Ticket kam an. Nur als kurzes Update: wir haben den Kontakt mit den KollegInnen aufgenommen und arbeiten gemeinsam an einer Lösung.

    folgende prefixe laufen wieder über den AMS-IX, es gab probleme bei der IPv6 neighbor discovery.


    Code
    inet6.0: 119391 destinations, 815307 routes (118590 active, 1 holddown, 2178 hidden)
      Prefix		  Nexthop	       MED     Lclpref    AS path
    * 2a07:59c6:ee00::/40     2001:7f8:1::a505:6382:2                 56382 I
    * 2a07:59c6:ee02::/48     2001:7f8:1::a505:6382:2                 56382 I
      2a0f:5707:ab80::/44     2001:7f8:1::a505:6382:2                 56382 I

    Moin [netcup] Moritz F. !


    Vielen Dank für deine Antwort. Ich habe nun bezugnehmend auf deine Antwort ein "normales" Ticket eröffnet inkl. MTR und Ansprechpartner bei vserver.site. Dessen NOC hatte sich am 28.05. an noc <at> anexia-it.com gewandt, ich am Tag zuvor.

    Danke, das Ticket kam an. Nur als kurzes Update: wir haben den Kontakt mit den KollegInnen aufgenommen und arbeiten gemeinsam an einer Lösung.

    [Anexia] Theo V. Ich hatte euch die Tage schonmal ans NOC gemailt, von meinem Netcup-Server kam ich nicht per IPv6 zu AS56382, da war's nach dem AMSIX tot. v4 dagegen lief problemlos. Momentan rejected AS56382 euch am AMSIX deswegen und läuft über Transit.

    Servus bjo,


    Weder wir(Anexia) noch die Kolleg*Innen von der Netcup finden etwas von dir in unseren noc-inboxen, kannst du das bitte nochmal als "gewöhnliches" support-ticket bei der netcup aufmachen, ich nehme an dort sind mehr Details zu finden, falls nicht lass uns bitte IPs und ggfs. traceroutes zum Ausfallzeitpunkt zukommen. Falls du bereits Ansprechpartner oder Tickets bei vserver.site hast wäre es super, wenn du uns diese auch mitteilst, dann können wir in den direkten Kontakt mit dem Netzbetreiber treten.

    Aktuell kann ich folgendes sagen:

    - Uns sind keine Probleme am AMS-IX bekannt und wir schieben gewohnte Trafficmengen zu anderen Peers dort

    - Wir peeren nicht direkt mit AS56382 am AMS-IX, die Verbindung muss also über die Route Server gehen

    - Die IPv6 IP vom AS56382 im AMS-IX peering LAN ist für uns via ICMP nicht erreichbar, und wir haben keinen IPv6 neighbor entry. Warum das so ist können wir nur in Zusammenarbeit mit deren NOC herausfinden.

    Weiteres dann nachdem wir mehr Details haben.

    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
    mfrenzel@bbr02.anx25.fra.de> show route protocol bgp 200.7.7.3 table inet.0 | match path
                          AS path: 262589 14259 27678 I, validation-state: valid
                          AS path: 262589 14259 27678 I, validation-state: valid
                          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
    mfrenzel@bbr02.anx25.fra.de> show route protocol bgp 2001:1398:5::6003 table inet6.0 | match path
                          AS path: 1299 174 18747 27678 I, validation-state: unverified
                          AS path: 2914 174 18747 27678 I, validation-state: unverified
                          AS path: 1299 174 18747 27678 I, validation-state: unverified
                          AS path: 1299 174 18747 27678 I, validation-state: unverified
                          AS path: 1299 174 18747 27678 I, validation-state: unverified
                          AS path: 2914 174 18747 27678 I, validation-state: unverified
                          AS path: 3320 5511 52468 18747 27678 I, validation-state: valid
                          AS path: 6939 262589 14259 27678 27678 27678 I, validation-state: valid
                          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.

    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.