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!

henkpls glad to hear, please apologize the inconvenience caused!

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

benja wrote:

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

Display More

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.

Dragon wrote:

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.

killerbees19 wrote:

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

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.

mainziman wrote:

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?

benja   mainziman könnt ihr mir mal die vollständigen v4 und v6 Adressen zu den Zielen schicken? Aus euren MTRs gehen v.a. die v4 Ziele nicht hervor zum Vergleich. Ich schaue mir das dann bei uns am Router mal an und melde mich.

Dragon Peering läuft, happy Githubbing

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.

poly01 wrote:

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

H6G wrote:

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.

H6G wrote:

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.

mainziman darf ich dich bitte hierfür ein Support-Ticket zu öffnen? Vielen Dank!

Ich hab deinen IPv6-Endpunkt in Frankfurt sowie deine Netcup-VM im v6-Monitoring, ohne Paketverlust.

Steini wrote:

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.

mainziman kannst du mir bitte die IP deines Tunnelendpunktes per PN schicken? Danke!

mainziman wrote:

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.

twiddern wrote:

Ich meinte die Differenz zwischen v4 und v6 in diesem Fall, mit den unterschiedlichen Wegen. Dies hast du bereits beantwortet

twiddern Wir forwarden v6 "plain", v4 via MPLS - daher hier die unterschiedlichen Wege