Backbone / Routing Q&A

  • mainziman ich habe das grade von meiner Netcup VM getestet, da sieht alles OK aus:

    Siehst du noch immer ein unterschiedliches Routing?

    das scheint nicht bei allen Netcup VMs zu sein; ein anderer Netcup vServer von mir ebenfalls OK

    aber das eine Sorgenkind diesbezüglich, nach wie vor ;(

    Grüße / Greetings

    Walter H.


    RS 1000 SAS G8 xRAM; RS 500 SSD G8; S 1000 G7; VPS 200 G8 Akt.; Webhost. 1000 m. 75%

  • [Anexia] Theo V.  Kann es sein, dass ihr aktuell irgendein Routingproblem bei den Antwortpaketen von HE/DF habt?


    Siehe: https://forum.netcup.de/sonsti…A4ngste-thema/#post142558


    Die ICMPv6-Pakete von meinem VPS 20 (2a03:4000:2:5aa::2e26:ee4c) kommen auf der JB (innerhalb von 2a00:1158:3::/64) an und werden beantwortet. Aber die Antwortpakete verschwinden irgendwo nach 2a00:11c0:47:1:47::140. Bei anderen Zielen gibt es keine Probleme.

  • [Anexia] Theo V. Kann es sein, dass ihr aktuell irgendein Routingproblem bei den Antwortpaketen von HE/DF habt?


    Siehe: https://forum.netcup.de/sonsti…A4ngste-thema/#post142558


    Die ICMPv6-Pakete von meinem VPS 20 (2a03:4000:2:5aa::2e26:ee4c) kommen auf der JB (innerhalb von 2a00:1158:3::/64) an und werden beantwortet. Aber die Antwortpakete verschwinden irgendwo nach 2a00:11c0:47:1:47::140. Bei anderen Zielen gibt es keine Probleme.

    killerbees19 danke für deine Meldung. Von unserem Juniper-Router im Netcup-Rechenzentrum kann ich keine Probleme mit ICMPv6 feststellen zu deinem Ziel:

    Code
    1. tvoss@dcr01.anx84.nue.de> ping 2a00:1158:3::2 rapid count 1000
    2. PING6(56=40+8+8 bytes) 2a00:11c0:47:3::21 --> 2a00:1158:3::2
    3. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    4. --- 2a00:1158:3::2 ping6 statistics ---
    5. 1000 packets transmitted, 1000 packets received, 0% packet loss
    6. round-trip min/avg/max/std-dev = 6.438/8.003/77.856/6.181 ms

    Insofern würd ich dich bitten erstmal ein Ticket bei Netcup-Support zu lösen. Die Kollegen melden sich dann bei uns, wenn es ein Routing-Problem geben sollte.

  • Wie so oft verschwinden Fehler genau dann, wenn man etwas schreibt. Vorher war das mindestens eine Stunde defekt ^^


    Danke fürs rasche Prüfen! :) Irgendwo haben da einzelne Pakete wohl ein paar Ehrenrunden gedreht. Ich habe dazwischen auch noch ein paar "Time Exceeded" Pakete von 2001:7f8::5125:f1:1 mittels dem immer noch laufenden tcpdump auf meiner netcup VM aufgeschnappt.

  • 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. Ich schlage hier mal ein Peering mit einem regionalen Provider aus meiner Gegend (AS31103) vor.

    Jeglicher Traffic von Netcup dorthin verläuft scheinbar über den DE-CIX... irgendwie ungeil, bei Nürnberg <--> Erfurt über Frankfurt zu gehen. :/

    RS Rentier 2019 | VPS 200 G8 | VPS Kaneval 2020 | WH 1000 SE


    Wer im Netz Anstand und Respekt verliert, der ist auch im realen Leben für nichts zu gebrauchen! ;)

  • [Anexia] Theo V. Ich schlage hier mal ein Peering mit einem regionalen Provider aus meiner Gegend (AS31103) vor.

    Jeglicher Traffic von Netcup dorthin verläuft scheinbar über den DE-CIX... irgendwie ungeil, bei Nürnberg <--> Erfurt über Frankfurt zu gehen. :/

    Das wird schwierig, da Keyweb hauptsächlich am DE-CIX peert. In Nürnberg sind sie gar nicht vertreten: https://www.peeringdb.com/asn/31103

  • Das wird schwierig, da Keyweb hauptsächlich am DE-CIX peert. In Nürnberg sind sie gar nicht vertreten: https://www.peeringdb.com/asn/3110

    whoami0501 in der Tat, wie Dragon schreibt, hier können wir nicht viel machen. Der DE-CIX ist der "nächste" gemeinsame Austauschpunkt.
    Du kannst aber gerne mal bei AS31103 anfragen, vielleicht können die sich am N-IX in Nürnberg anschließen, dort sind wir vertreten.

  • 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.

  • 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