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?
Beiträge von [Anexia] Theo V.
-
-
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.
-
Hi Theo,
danke für deine Antwort.
Hier der mtr über IPv4 seitens 31.220.6.30
Code
Alles anzeigenStart: Wed Dec 2 22:05:46 2020 HOST: [x].[mitbewerber].com Loss% Snt Last Avg Best Wrst StDev 1.|-- gateway 0.0% 10 0.3 1.0 0.2 3.5 0.9 2.|-- 5.104.136.157 0.0% 10 87.3 64.3 21.8 87.3 20.7 3.|-- ae3-1337.bbr02.anx63.ams.nl.anexia-it.net 0.0% 10 1.4 7.0 1.2 56.3 17.3 4.|-- ae1-10.bbr01.anx63.ams.nl.anexia-it.net 0.0% 10 11.5 13.4 11.5 18.7 2.8 5.|-- ae10-0.bbr01.anx25.fra.de.anexia-it.net 0.0% 10 11.7 12.1 11.6 14.2 0.7 6.|-- ae0-0.bbr02.anx25.fra.de.anexia-it.net 0.0% 10 12.4 12.8 11.7 14.2 0.7 7.|-- ae1-0.bbr01.anx84.nue.de.anexia-it.net 0.0% 10 11.6 20.0 11.5 49.0 13.4 8.|-- netcup-gw.bbr01.anx84.nue.de.anexia-it.net 0.0% 10 11.6 16.9 11.3 35.8 9.0 9.|-- serv1.hostedasen.de 0.0% 10 11.3 11.8 11.3 13.3 0.5
Hier der mtr über IPv6 seitens 2a01:6f0:ffff:aa::beef
CodeStart: Wed Dec 2 22:07:14 2020 HOST: [x].[mitbewerber].com Loss% Snt Last Avg Best Wrst StDev 1.|-- gateway 20.0% 10 0.3 0.4 0.3 0.8 0.0 2.|-- 2a00:1768:4001:5::1 20.0% 10 1.8 2.0 0.5 9.2 2.9 3.|-- ae3-1337.bbr02.anx63.ams.nl.anexia-it.net 10.0% 10 1.8 2.5 1.0 9.1 2.5 4.|-- 2a00:11c0:47:1:47::213 10.0% 10 22.9 22.9 22.6 24.2 0.4 5.|-- 2a00:11c0:47:3::33 10.0% 10 17.0 17.2 16.8 18.2 0.4 6.|-- serv1.hostedasen.de 10.0% 10 17.0 17.1 16.9 17.5 0.0
Vielen Dank,
Ben
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.
-
Hi Theo,
vielen lieben Dank für deine schnelle Reaktion und die gute Lösung
Ich hoffe mal die Mühe lohnt sich und der Request wird akzeptiert.
VG
aubergine, der Request wurde akzeptiert, die Sessions sind eingerichtet. Bitte noch mal testen, danke!
-
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 Verbindung zu einem niederländischen Serveranbieter ist über IPv6 wesentlich "länger" angebunden. Der Pink ist rund 6ms höher als über IPv4.
Hi benja,
kannst du bitte mal einen Rückweg-MTR machen und hier teilen?
Danke,
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!
-
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
-
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
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.
-
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. -
[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:
Codetvoss@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:
Code
Alles anzeigen# mtr -zwc1 216.66.80.30 Start: 2020-05-04T17:58:26+0200 2. AS47147 ae3-4018.bbr01.anx84.nue.de.anexia-it.net 0.0% 1 0.8 0.8 0.8 0.8 0.0 3. AS47147 ae2-0.bbr02.anx25.fra.de.anexia-it.net 0.0% 1 3.8 3.8 3.8 3.8 0.0 4. AS??? ipv4.decix-frankfurt.core1.fra1.he.net 0.0% 1 4.2 4.2 4.2 4.2 0.0 5. AS6939 tserv1.fra1.he.net 0.0% 1 3.8 3.8 3.8 3.8 0.0 # mtr -zwc1 2001:470:0:69::2 Start: 2020-05-04T17:58:35+0200 2. AS47147 2a00:11c0:47:3::20 0.0% 1 0.7 0.7 0.7 0.7 0.0 3. AS47147 2a00:11c0:47:1:47::141 0.0% 1 3.8 3.8 3.8 3.8 0.0 4. AS??? ipv6.decix-frankfurt.core1.fra1.he.net 0.0% 1 4.0 4.0 4.0 4.0 0.0 5. AS6939 tserv1.fra1.he.net 0.0% 1 3.6 3.6 3.6 3.6 0.0
Siehst du noch immer ein unterschiedliches Routing?
-
-
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.