Cable4 Glasfaser wird immer langsam, jemand eine Idee?

Z.B. mit der ersten aus dem Public Internet erreichbaren IPv4 aus dem Ergebnis von hier:

Testen Sie Ihre IPv6-Konnektivität.

test-ipv6.com

Zitat von frank_m

Wo ist der traceroute gemacht worden? In einem Browserfenster mit T Symbol? Ob das wirklich ein regulärer Heimzugang war ...

Wie dem auch sei, ich wiederhole die Frage: Warum löst eine Neuverbindung das Probleme? Solange niemand eine sinnvolle Erklärung liefert, die das Phänomen in der Infrastruktur sauber erklärt, glaube ich nicht, dass es in der Infrastruktur liegt. Im Heimnetz findet man dafür relativ einfach Erklärungen.

Berechtigte Frage. Wird sich zeigen, was das Problem genau war.

Ein Layer-3-"ONT" (was ich nicht kenne) ist ja noch nicht vom Tisch.

Auf den wenigen Bildern, die von den von Cable4 ONTs verfügbar sind, scheinen das marktübliche Geräte von Huawei zu sein.

Jedoch steht die Antwort von tim2110 noch aus.

Oder wir haben ihn jetzt vergrault. 😉

Mich würde es ehrlich gesagt wundern, wenn der Neustart des ONT dauerhaft Abhilfe geschaffen hat.

Vielleicht berichtet er noch mal.

krappi01

Hier mal konkret der Unterschied zwischen NAT-Loopback und einem echten Ziel. Ich habe dazu einen VDSL2-Anschluss der Telekom genommen.

# traceroute -n 87.188.103.234
traceroute to 87.188.103.234 (87.188.103.234), 30 hops max, 38 byte packets
 1  192.168.178.1  0.812 ms  0.762 ms  0.690 ms
 2  87.188.103.234  0.873 ms !A  0.800 ms !A  0.796 ms !A

Die Verarbeitung innerhalb der Fritzbox 7530 erfolgt im Sub-Millisekunden-Bereich. Da ich die eigene Adresse anspreche, erfolgt ein Loopback zur NAT-Adresse (sprich, der in der FB sichtbaren WAN-Adresse).

Und so sieht es aus, wenn man ein Ziel außerhalb der eigenen vier Wände verfolgt.

# traceroute -4 -n www.heise.de
traceroute to www.heise.de (193.99.144.85), 30 hops max, 38 byte packets
 1  192.168.178.1  0.820 ms  0.719 ms  0.699 ms
 2  62.155.242.198  4.732 ms  5.309 ms  4.806 ms
 3  217.0.192.222  11.070 ms  10.799 ms  10.972 ms
 4  62.157.251.38  11.995 ms  11.813 ms  11.756 ms

Jetzt antwortet im zweiten Hop der Router, den man nach der PtP-Verbindung erreicht. Bei VDSL2 sind da jetzt mal locker 4 ms oben drauf gekommen.

Ja das ist bekannt soweit und bestätigt auch meine Aussage dass .dip0.t-ipconnect.de die WAN IP des Kundenrouters ist:

PS nslookup 87.188.103.234

Server: pi.hole

Name: p57bc67ea.dip0.t-ipconnect.de

Address: 87.188.103.234

Bei der Telekom ist aber auch gar kein CGNAT im Spiel. Ich hatte da immer vollwertiges Dual Stack.

Nein, der zweite Hop liegt nicht am WAN-Interface des Routers.

Hast du das jetzt immer noch nicht verstanden?

Doch hab ich

Zitat von mbo77

Die Verarbeitung innerhalb der Fritzbox 7530 erfolgt im Sub-Millisekunden-Bereich. Da ich die eigene Adresse anspreche, erfolgt ein Loopback zur NAT-Adresse (sprich, der in der FB sichtbaren WAN-Adresse).

Und nein, nicht alle Adressen aus der Subdomain werden Kunden zugewiesen.

Also fassen wir mal zusammen:

In deiner Welt ist p3e9bf2c3.dip0.t-ipconnect.de mal eine Netzwerkkomponente der Telekom aber p57bc67ea.dip0.t-ipconnect.de ein RDNS Name für eine Kunden IP. (#71 und #85)

Und eben jene Adresse (denn die hatte ich eben im NSLookup geprüft) liegt laut deiner Aussage nicht am WAN Interface des Routers, auch wenn die <1ms antwortet. (#87)

Ja, das lässt sich ja wunderbar an den Ausgaben der traceroutes ablesen.

Oder wie möchtest du das erklären?

$ traceroute 87.188.103.234
traceroute to 87.188.103.234 (87.188.103.234), 30 hops max, 60 byte packets
 1  _gateway (10.99.66.6)  0.681 ms  0.702 ms  0.799 ms
 2  p3e9bf2c3.dip0.t-ipconnect.de (62.155.242.195)  21.674 ms  21.664 ms  21.765 ms
 3  p509297a1.dip0.t-ipconnect.de (80.146.151.161)  21.757 ms  21.784 ms  28.881 ms
 4  p57bc67ea.dip0.t-ipconnect.de (87.188.103.234)  28.870 ms !X  28.977 ms !X  34.694 ms !X

Hauptsache eindeutig, der Rest ist egal.

Aber sollte man sich trotzdem nicht abschauen, wenn man ein Netzwerk plant

Egal, wovon du jetzt ablenken willst.

Du hast jetzt aber schon verstanden, dass der 2. Hop nicht beim Kunden steht, oder?

Das kann man so pauschal nicht sagen. Siehe #85 1. Beispiel

Dein Ernst?

Du meinst das Beispiel, wo ich dir die Funktion des NAT-Loopbacks gezeigt habe? Wo es gar keinen dritten Hop mehr gibt?

Wie wäre es damit, einfach mal zu sagen, dass du es falsch verstanden hast und hier etwas zu laut gepoltert hast?

Ich hatte sie dir davor aber schon in #78 gezeigt

Und außerdem gibt es noch weitere Beispiele aktiver LAN Komponenten auf Kundenseite die routen. Und dein Beispiel war auch nicht GPON bzw. CGNAT.

Ich hatte dir in #92 Recht gegeben mit den Telekom DNS-Namen und nicht von irgendwas ablenken wollen. Und wenn wir einmal dabei sind, vielleicht solltest DU auch einfach mal zugeben, dass du nicht gemerkt hast dass ich in #86 die WAN IP des Routers aus deinem eigenen Beispiel aufeglöst hatte.

Naja, ich habe deinen Quatsch aus #78 mal vernünftig gegenüber gestellt. Unterschied traceroute zum NAT-Loopback vs echtes Ziel.

Mit dem NAT-Loopback wolltest du ja mal den Beweis antreten, dass der 2. Hop auf der FB liegt.

Der Unterschied ist aus Sicht der Netzwerktechnik unbedeutend zwischen PtP und der CG-Konstruktion. In beiden Fällen antwortet im zweiten Hop die Gegenseite beim Provider.

Nur um es noch mal in Erinnerung zu rufen: Wir reden hier von einem Problemfall, dessen Ursache nach wie vor ungeklärt ist. Der 2. Hop kann aufgrund dieser Fehlerbedingungen dort auftauchen, und deshalb durchaus beim Kunden sein, obwohl er normalerweise nicht im Trace auftauchen würde.

Ich denke auch immer noch, dass der Hop beim Kunden ist, entweder in der Fritzbox oder im ONT. Was dazu führt, dass er im Trace auftaucht, weiß ich aber auch noch nicht, ob es am ONT oder an der Box liegt. Weitere Analysen gehen ja im Moment auch nicht, da der TE sich nicht zurückmeldet.

Zitat von frank_m

Nur um es noch mal in Erinnerung zu rufen: Wir reden hier von einem Problemfall, dessen Ursache nach wie vor ungeklärt ist. Der 2. Hop kann aufgrund dieser Fehlerbedingungen dort auftauchen, und deshalb durchaus beim Kunden sein, obwohl er normalerweise nicht im Trace auftauchen würde.

Ich denke auch immer noch, dass der Hop beim Kunden ist, entweder in der Fritzbox oder im ONT. Was dazu führt, dass er im Trace auftaucht, weiß ich aber auch noch nicht, ob es am ONT oder an der Box liegt. Weitere Analysen gehen ja im Moment auch nicht, da der TE sich nicht zurückmeldet.

Wie soll das gehen? Dazu fehlt mir die technische Fantasie.

Da müsste das WAN-Interface ja mehrfache Adressen haben. Und selbst dann sehe ich nicht, wie das zum beschriebenen Problem passt.

Zudem haben wir vom OP eine sehr ungenaue Messung, weil teilweise via WLAN. Das kann man getrost ignorieren.

Ich könnte mir vorstellen, dass im System eine Art QoS oder Shaping stattfindet. Durch die Neuverbindung wird die Session zurückgesetzt oder Ähnliches.

Es wird möglicherweise für immer ein Rätsel bleiben, wenn sich OP nicht mehr meldet.

Zitat von mbo77

Wie soll das gehen? Dazu fehlt mir die technische Fantasie.

Kann jedes beliebige Gerät sein was routet. Auch auf Seiten des Kunden. Wie z.B. eine Router-Kaskade. Aber du denkst ja immer noch der 2. HOP liegt immer beim Provider...