Posts by [Anexia] Theo V.

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

    Ich würde sagen der ignoriert dich.

    mainziman genau das tut er. Und das machen viele "Hops", entscheidend im MTR ist ausschließlich der Loss am letzten Hop, dem Ziel, sofern ICMP auch aktiv ist und hier kein Rate-Limit aktiv ist. ICMP (ping) Tests auf google.* bspw. sind alle nicht aussagekräftig, weil Google ein ICMP-Rate-Limit aktiv hat und damit öfters Loss zu sehen ist, obwohl der Service einwandfrei läuft.

    Gerade einen interessanten Kommentar auf Reddit gefunden, für diejenigen, die sich für das Thema interessieren:


    https://www.reddit.com/r/netwo…fvo4ed/bgp_peers/fmkg3z4/

    Ja, so ist leider die Realität. Beispielsweise ein Kabel in New York umstecken lassen in einem Gebäude, das mehrere Rechenzentren beherbergt, aber einer Immobilienfirma gehört, das kann gerne mal einen Tag dauern. Gleiches aber auf der anderen Seite, viele "NOCs" antworten uns bspw. nie auf unsere Mails.

    dot0x danke, das ist bekannt und wir arbeiten zumindest für unsere Seite am Traffic Engineering. In einer bestimmten Kombination aus Netcup-Router und Backbone-Router bei uns, ist der Weg nach Wien zu unserer LibertyGlobal-Übergabe einen "Hauch" kürzer. Ich melde mich, wenn das erledigt ist.

    Wie sieht das eigentlich mit der Anbindung nach Übersee aus? Bin gerade beruflich in Chicago und die Verbindung ist teilweise echt miserabel (nicht unbedingt vom Ping, aber vom Durchsatz). Ich schätze aber dass die Probleme hier eher bei AT&T zu verorten sind (gut für Netcup, blöd für mich weil ich da nichts machen kann). Speedtest.net in die Umgebung hier zeigt wie bestellt 100/20 MBit, in die Heimat (ein Server bei Frankfurt) kommt oft (abends) nicht über 2 MBit (während die Verbindung hier in der Nähe gut bleibt). Das reicht leider nicht für HD-Fernsehen und VPN fühlt sich auch eher nach letztem Jahrtausend an. Werde wohl meine Backupzeiten anpassen müssen ;)

    Hi Steini , wir übergeben deine Datenpakete "sauber" an TeliaCarrier (AS1299). Paketverlust 0%. Hier ist alles so, wie es sein soll. Ich empfehle dir zur Eingrenzung des Problems verschieden "iperf3"-Messungen zu unterschiedlichen Endpunkten in gleicher geografischer Lage zu machen.

    was ist da bloß los?:/

    ist es logisch dass Hop 6 lt. dem hier sich in AT befindet?

    mainziman gerne Antworte ich dir:


    1. Frage: Das kann ich dir hier aus dem Stehgreif natürlich nicht beantworten. Kannst du uns bitte mal einen Trace für den Rückweg zukommen lassen? Gerne auch statt traceroute das Tool "mtr" verwenden, vielen Dank.


    2. Frage: Du schaust hier auf die sog. "Geolocation", eine Ortsangabe, die von Dritten (privaten Anbietern) berechnet wird. In diesem Fall ist dies nicht korrekt, der Hop befindet sich natürlich in Deutschland. Insofern hier bitte nicht auf die Geolocation verlassen. Und ganz speziell bei sog. "Link-Netzen", also Verbindungen zwischen Routern, auch nicht auf Einträge in RIR-Datenbank (bspw. RIPE), da hier ein Netz, bspw. ein /48, weltweit verwendet wird in einem Backbone.