Posts by [Anexia] Theo V.

    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.

    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.

    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.

    Track1991 lass mir bitte mal deine Source-IP per PN zukommen, dann schaue ich mir das an. Wir haben ein direktes Peering mit 1&1 in Frankfurt, in Amsterdam sehen wir die Prefixe von 1&1 lediglich via Route-Server, wobei die Routen in Frankfurt bevorzugt werden. Insofern wird Traffic von uns zu 1&1 über Frankfurt geroutet.


    Wir peeren am DE-CIX Hamburg technisch-bedingt nur mit sehr kleinen ISPs.

    Ich bin Kunde der deutschen Glasfaser (ASN 60294). IPv4 läuft leider über CGNAT aber ohne Probleme. Der Ping via IPv4 liegt bei ca. 12-15ms.

    Anders verhält es sich bei IPv6. Dort habe ich ab einem bestimmten Hop eine höhere Latzenz. Hier zwei Auszuge:


    Es wäre klasse wenn überprüft wird, ob das so stimmt. Vielen Dank!

    poly01 vielen Dank, ich habe der Deutschen Glasfaser eine Anfrage für ein direktes Peering geschickt.
    Bzgl. H3tzner, das ist korrekt, wir haben eine Direktverbindung (sog. PNI).