Reproduzierbarer TCP-Paketverlust von AS3320 zu 160.79.104.10:443, Präfix 160.79.104.0/23, Ziel-AS399358 Anthropic. Der Pfad läuft über AS3356 Lumen. TCP-MTR zeigt Verlust am Endziel; parallele LAN-/WAN-Captures auf der pfSense bestätigen, dass die
Firewall keine Pakete verwirft. SYNs, SYN-ACKs und TLS-Segmente gehen außerhalb der Firewall verloren. Aus einem IONOS-Netz ist
dasselbe Ziel stabil erreichbar. Bitte Routing/ Peering und Rückweg zu AS399358 prüfen.
Auch wenn ich von hier per VPN über andere Peerings rausgehe, läuft es super. Nur vom DTAG Anschluss aus direkt nicht. Sieht mir nach einem Peering -Problem aus. Wie kann das wer bei der Telekom melden?
vor 17 Stunden
Wie kann das wer bei der Telekom melden?
Reproduzierbarer TCP-Paketverlust von AS3320 zu 160.79.104.10:443, Präfix 160.79.104.0/23, Ziel-AS399358 Anthropic. Der Pfad läuft über AS3356 Lumen. TCP-MTR zeigt Verlust am Endziel; parallele LAN-/WAN-Captures auf der pfSense bestätigen, dass die
Firewall keine Pakete verwirft. SYNs, SYN-ACKs und TLS-Segmente gehen außerhalb der Firewall verloren. Aus einem IONOS-Netz ist
dasselbe Ziel stabil erreichbar. Bitte Routing/ Peering und Rückweg zu AS399358 prüfen.
Auch wenn ich von hier per VPN über andere Peerings rausgehe, läuft es super. Nur vom DTAG Anschluss aus direkt nicht. Sieht mir nach einem Peering -Problem aus. Wie kann das wer bei der Telekom melden?
Garnicht .. die Telekom interessiert sich nicht dafür, was außerhalb ihres Netzes passiert.
Ist ja auch logo .. warum sollte sie den anderen reinreden?
3
von
vor 17 Stunden
Weil sie ein Interesse daran haben "sollte"/könnte, das die Verbindungen ihrer Kunden zu den Hauptzielen sauber und störungsfrei ist. Denn ein normaler Kunde, der nicht mal weiß, wie die Pakete von A nach B laufen, gibt der Telekom die Schuld.
Ob nun das Peering zwischen Telekom/Lumen oder Lumen/whoever das Problem ist, kann ich nicht sagen. Das Backbone Team der Telekom sehr wohl und es könnte Einfluss nehmen und es ggf. weiteren Upstreams melden.
Wenn es die Probleme über andere Pfade nicht gibt, wirkt sich das auf die Kundenzufriedenheit aus. Ich sage ja nicht, dass die "böse" Telekom schuld ist. Aber ICH kann es schwerlich Lumen/Anthropic melden. :-)
0
von
vor 17 Stunden
Aber ICH kann es schwerlich Lumen/Anthropic melden. :-)
Weil sie ein Interesse daran haben "sollte"/könnte, das die Verbindungen ihrer Kunden zu den Hauptzielen sauber und störungsfrei ist. Denn ein normaler Kunde, der nicht mal weiß, wie die Pakete von A nach B laufen, gibt der Telekom die Schuld.
Ob nun das Peering zwischen Telekom/Lumen oder Lumen/whoever das Problem ist, kann ich nicht sagen. Das Backbone Team der Telekom sehr wohl und es könnte Einfluss nehmen und es ggf. weiteren Upstreams melden.
Wenn es die Probleme über andere Pfade nicht gibt, wirkt sich das auf die Kundenzufriedenheit aus. Ich sage ja nicht, dass die "böse" Telekom schuld ist. Aber ICH kann es schwerlich Lumen/Anthropic melden. :-)
Warum nicht?
Ob nun das Peering zwischen Telekom/Lumen oder Lumen/whoever das Problem ist, kann ich nicht sagen. Das Backbone Team der Telekom sehr wohl und es könnte Einfluss nehmen und es ggf. weiteren Upstreams melden.
Weil sie ein Interesse daran haben "sollte"/könnte, das die Verbindungen ihrer Kunden zu den Hauptzielen sauber und störungsfrei ist. Denn ein normaler Kunde, der nicht mal weiß, wie die Pakete von A nach B laufen, gibt der Telekom die Schuld.
Ob nun das Peering zwischen Telekom/Lumen oder Lumen/whoever das Problem ist, kann ich nicht sagen. Das Backbone Team der Telekom sehr wohl und es könnte Einfluss nehmen und es ggf. weiteren Upstreams melden.
Wenn es die Probleme über andere Pfade nicht gibt, wirkt sich das auf die Kundenzufriedenheit aus. Ich sage ja nicht, dass die "böse" Telekom schuld ist. Aber ICH kann es schwerlich Lumen/Anthropic melden. :-)
Das macht die Netzssteurung bei Bedarf und nach sehr zähen Verhandlungen schon eigenständig wenn sie Bedarf oder Nutzen für sich daraun sehen. Aber dazu gehören halt zwei Seiten. Schau dir doch die ganzen Threads zum Thema Cloudflare an.
0
von
vor 15 Stunden
Hallo @jpk72,
wie ich sehe, gab es hier bereits einige viele Infos zum Thema Peering , dass ich nicht wirklich noch etwas hinzufügen muss. Tut mir leid.
Beste Grüße
Julia
0
Uneingeloggter Nutzer
von
vor 17 Stunden
Der Pfad läuft über AS3356 Lumen. TCP-MTR zeigt Verlust am Endziel;
Reproduzierbarer TCP-Paketverlust von AS3320 zu 160.79.104.10:443, Präfix 160.79.104.0/23, Ziel-AS399358 Anthropic. Der Pfad läuft über AS3356 Lumen. TCP-MTR zeigt Verlust am Endziel; parallele LAN-/WAN-Captures auf der pfSense bestätigen, dass die
Firewall keine Pakete verwirft. SYNs, SYN-ACKs und TLS-Segmente gehen außerhalb der Firewall verloren. Aus einem IONOS-Netz ist
dasselbe Ziel stabil erreichbar. Bitte Routing/ Peering und Rückweg zu AS399358 prüfen.
Auch wenn ich von hier per VPN über andere Peerings rausgehe, läuft es super. Nur vom DTAG Anschluss aus direkt nicht. Sieht mir nach einem Peering -Problem aus. Wie kann das wer bei der Telekom melden?
Und damit hat die Telekom nüscht zu tun.
0
0
vor 17 Stunden
Wie kann das wer bei der Telekom melden?
Reproduzierbarer TCP-Paketverlust von AS3320 zu 160.79.104.10:443, Präfix 160.79.104.0/23, Ziel-AS399358 Anthropic. Der Pfad läuft über AS3356 Lumen. TCP-MTR zeigt Verlust am Endziel; parallele LAN-/WAN-Captures auf der pfSense bestätigen, dass die
Firewall keine Pakete verwirft. SYNs, SYN-ACKs und TLS-Segmente gehen außerhalb der Firewall verloren. Aus einem IONOS-Netz ist
dasselbe Ziel stabil erreichbar. Bitte Routing/ Peering und Rückweg zu AS399358 prüfen.
Auch wenn ich von hier per VPN über andere Peerings rausgehe, läuft es super. Nur vom DTAG Anschluss aus direkt nicht. Sieht mir nach einem Peering -Problem aus. Wie kann das wer bei der Telekom melden?
Überhaupt nicht.
0
0
vor 17 Stunden
@jpk72
Ich teile trotzdem gerne die peering Lektüre mit 😅
-Klick-
0
0
vor 17 Stunden
Ich hab mir mal den Spaß gegönnt und habe Claude (Opus 5.0) den Link geschickt mit der Frage was er empfehlen würde, hier die Antwort:
Kurz gesagt: In dem Thread wird er keine Lösung bekommen — die richtige Adresse ist nicht die Community, und schon gar nicht über einen Forenpost an “die Telekom”. Was ich empfehlen würde:
1. Erst lokale Ursachen sauber ausschließen Verlorene TLS-Segmente riechen stark nach PMTUD-Blackhole. Bei PPPoE (MTU 1492) bzw. DS-Lite lohnt ein Test mit MSS-Clamping auf 1452/1412 und ein Gegentest mit erzwungenem IPv4 vs. IPv6. Verlust “am letzten Hop” im MTR ist außerdem oft nur ICMP-Rate-Limiting des Ziels, kein echter Loss — das entwertet die Beweislage.
2. Messungen liefern, die ein NOC ernst nimmt RIPE Atlas Measurements von mehreren DTAG -Probes auf 160.79.104.10:443, plus Gegenrichtung über NLNOG RING oder Looking Glasses. Erst damit lässt sich Hin- vs. Rückweg trennen — genau das, was die Telekom sonst als “liegt nicht bei uns” abbügelt.
3. Auf beiden Seiten melden, nicht nur bei der Telekom
4. Parallel den pragmatischen Weg gehen Da es über VPN sauber läuft: Policy-Routing nur für 160.79.104.0/23 über den Tunnel (z. B. WireGuard zum IONOS-Netz). Löst das Problem heute, statt auf Peering -Verhandlungen zu warten.
Realistisch: Die DTAG - Peering -Threads laufen seit Jahren nach exakt diesem Muster (siehe die endlose Cloudflare-Serie). Der Workaround ist die eigentliche Lösung, die Meldung ist Fleißarbeit mit geringer Trefferquote.
0
2
von
vor 16 Stunden
Ist ja immer eine Kette.
Wenn etwas "auffällig" in einem Traceroute scheint, dann ist es immer gleich ein "Beweis", obwohl es gar nicht im Bereich der Telekom mehr ist. Fällt nichts groß auf, dann kommt immer das Argument, ja das zeigt ja nur den Hinweg. Aber da wird dann aber nichts weiter belegt zu.
"Ich mache mir die Welt, wie sie MIR gefällt!"
von
vor 15 Stunden
Danke für den Hilfsversuch.
ZU (1): Bevor ich das geposted habe bin ich alle diese Bereiche durch. MTU etc. scheiden aus (aus sehr vielen verschiedenen Gründen).
Zu (2): Ja durchaus möglich, dass dies ein paar Erkenntnisse liefert.
zu (3): Ich schaue mir gerne an, was ich finden kann. Wenn es aber ein typisches DTAG <--> Cloudflare Thema ist, wird da auch Anthropic wenig tun können/wollen.
zu (4): Genau darüber arbeite ich. Es ging nicht um "lös mir das konkrete Symptom" sondern das eigentliche Problem zu benennen und auf eine Problemlösung hinzuwirken.
0
Uneingeloggter Nutzer
von
vor 17 Stunden
Nur vom DTAG Anschluss aus direkt nicht. Sieht mir nach einem Peering -Problem aus
Reproduzierbarer TCP-Paketverlust von AS3320 zu 160.79.104.10:443, Präfix 160.79.104.0/23, Ziel-AS399358 Anthropic. Der Pfad läuft über AS3356 Lumen. TCP-MTR zeigt Verlust am Endziel; parallele LAN-/WAN-Captures auf der pfSense bestätigen, dass die
Firewall keine Pakete verwirft. SYNs, SYN-ACKs und TLS-Segmente gehen außerhalb der Firewall verloren. Aus einem IONOS-Netz ist
dasselbe Ziel stabil erreichbar. Bitte Routing/ Peering und Rückweg zu AS399358 prüfen.
Auch wenn ich von hier per VPN über andere Peerings rausgehe, läuft es super. Nur vom DTAG Anschluss aus direkt nicht. Sieht mir nach einem Peering -Problem aus. Wie kann das wer bei der Telekom melden?
Und dazu braucht es jeden Tag einen Jammerthread?
Lest doch zuerst, was es zum Thema gibt und zieht euere Schlüsse.
Dazu ist doch von alles Seiten schon vielmals alles gesagt und wenn es Neues gibt, merkt ihr sicher am Schnellsten.
0
0
vor 16 Stunden
@jpk72
Ist doch alles seit Jahren bekannt, siehe https://www.netzbremse.de
0
2
von
vor 16 Stunden
Wieso verlinkst du hier immer nur die "Meinungsmache" der einen Seite? Ist die nicht klar, dass das ein vielschichtigeres Problem ist und nicht nur das der Telekom?
Oder bist du ein Fanboy von Cloudflare? Ein Vorwurf der in anderer Richtung auch immer gemacht wird, besonders wenn die Argumente ausgehen.
von
vor 16 Stunden
Ist doch alles seit Jahren bekannt, siehe
@jpk72
Ist doch alles seit Jahren bekannt, siehe https://www.netzbremse.de
Du ilkige Nudel... ein Verein aus dem Schluchtenland Ösistan. Man man man...schenk dir das doch endich. Eigentlich fällst du mit guten Beiträgen auf, aber mit dem Quatsch machste alles wieder kaputt.
Uneingeloggter Nutzer
von
Uneingeloggter Nutzer
von