Beiträge von [Anexia] Theo V.

    Hallo peterbo - danke für deine Meldung. Wir haben in den letzten Tagen leider immer wieder Probleme mit "H", Traffic wird uns auf unüblichen Wegen (via N-IX, statt über unseren PNI) zugestellt. Wir laufen dem leider im Moment reaktiv hinterher, vom H-NOC bekommen wir keine Rückmeldung. Wir haben jetzt grade noch mal etwas Traffic Engineering betrieben, kannst du bitte noch mal prüfen, ob das Problem noch besteht?

    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 ;)

    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.

    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.

    Vielleicht ein Fall für [Anexia] Theo V. ?

    tab  BlackManta hier kann euch am besten der netcup Support helfen. Mein Team und ich kann erst dann Einfluss nehmen, wenn das Verhalten Routing-bedingt ist und (in der Regel) auch auf allen Produkten/Systemen reproduzierbar ist. Die Kollegen vom Support helfen euch hier aber mit Sicherheit schnell und kompetent! :)


    Bitte Fragen zu Routing & Netzwerk gerne im dazu passenden (gepinnten) Thread stellen.


    Beste Grüße,

    Theo

    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

    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. ;)

    Gunah danke für deine Meldung, leider können wir das Routing "zu uns" nur bedingt beeinflussen. Grundsätzlich hat die DTAG (AS3320) ein sehr gutes Netz, sprich Routing über diese ist grundsätzlich kein Nachteil. Wir werden schauen, ob wir dies eingehend anpassen können mit sog. "BGP Communities".

    Hallo zusammen,


    heute wurde ein Change Request für das v4/v6-Unterschieds-Thema fertiggestellt, der beim nächsten Engineering-Meeting besprochen und dann freigegeben wird. Sobald dies erfolgt ist (und es keine Änderunge/Einwände mehr gab) rollen wir die entsprechende Änderungen Backbone-weit aus. Ich melde mich dann bei euch und gebe Bescheid. Bis dahin bitte noch um etwas Geduld. Wir haben einen mehrstufigen Deployment/QA-Prozess für solche Änderungen, um die Netzqualität nicht zu gefährden - ich hoffe, das trifft auf Verständnis! :)

    Hi all,


    the issue was caused by a complex DDoS protection filtering, which was impacting fragmented UDP packets and should now be resolved. Can you please check and provide feedback? Please also let the official support team know. We apologize for the inconvenience caused, DDoS filter tuning is always a tightrope walk.


    Best regards,

    Theo

    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.

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

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

    Code
    tvoss@dcr01.anx84.nue.de> ping 2a00:1158:3::2 rapid count 1000
    PING6(56=40+8+8 bytes) 2a00:11c0:47:3::21 --> 2a00:1158:3::2
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    --- 2a00:1158:3::2 ping6 statistics ---
    1000 packets transmitted, 1000 packets received, 0% packet loss
    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.

    tserv1.fra1.he.net has address 216.66.80.30

    tserv1.fra1.he.net has IPv6 address 2001:470:0:69::2


    mit IPv6 geht des "mit der Kirche ums Kreuz" ...

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


    Siehst du noch immer ein unterschiedliches Routing?

    Dragon danke für den Hinweis, wir haben schon einen offenen Peering-Request mit Github. Ich gebe Bescheid, sobald das Peering eingerichtet ist.

    Gerne immer Bescheid sagen, auch wir können natürlich mal ein Peering übersehen, vor allem, wenn die Traffic-Level nicht all zu hoch sind.