Hier ist ja mal wieder die geballte Inkompetenz versammelt.
Die 100.127.223.252 ist eine bogon ip aus der CGNAT Range.
Also die NAT Adresse der Fritz!Box. Die wird nicht im Internet geroutet.
Also die FB hat selbst die .213.214 zugewiesen bekommen.
Die .223.252 ist die Adresse des Routers beim Provider, siehe Bild in deinem Link. Daher sieht man die Adresse im traceroute auch im 2. Hop.
Und 1ms Latenz in GPON halte ich für realistisch.
War wohl eher Zufall das die Fritze mit 13ms geantwortet hat oder WLAN geschuldet.
Der Shared Address Space kann durchaus für Router Interfaces genutzt werden abseits der Nutzung von CGNAT
Example:
1 192.168.179.1 (192.168.179.1) [AS???] 1.619 ms 1.318 ms 1.526 ms
2 100.124.1.10 (100.124.1.10) [AS???] 4.32 ms 3.696 ms 3.06 ms
3 100.127.1.149 (100.127.1.149) [AS???] 3.289 ms 2.683 ms 2.788 ms
4 100.127.1.148 (100.127.1.148) [AS???] 3.748 ms 3.075 ms 3.194 ms
5 185.22.46.177 (185.22.46.177) [AS60294] 4.954 ms 3.969 ms 4.406 ms
6 185.22.45.13 (185.22.45.13) [AS60294] 4.363 ms 3.753 ms 3.919 ms
7 209.85.142.69 (209.85.142.69) [AS15169] 4.678 ms 3.922 ms 3.745 ms
8 142.250.234.17 (142.250.234.17) [AS15169] 5.232 ms 5.261 ms 4.294 ms
9 dns.google (8.8.8.8) [AS15169] 4.977 ms 3.182 ms 3.292 msJa, auch ein schönes Beispiel.
Die Adresse im 2. Hop 100.124.1.10 ist nicht die Adresse, die der FB zugeordnet ist.
Das ist die Adresse des Routers, der beim Provider im gleichen Netz stehen muss. Es ist ja kein PtP-Interface.
Ja, auch ein schönes Beispiel.
Die Adresse im 2. Hop 100.124.1.10 ist nicht die Adresse, die der FB zugeordnet ist.
Das ist die Adresse des Routers, der beim Provider im gleichen Netz stehen muss. Es ist ja kein PtP-Interface.
Was aber zu der Erkenntnis führt, dass die WAN Adresse des eigenen Routers ja im 100.124er Netz liegen muss.
Was aber zu der Erkenntnis führt, dass die WAN Adresse des eigenen Routers ja im 100.124er Netz liegen muss.
Das wird von der Subnetzmaske abhängen.
Grundsätzlich steht /10 zur Verfügung. Keine Idee, wie die das schnitzen.
Anbei übrigens mal ein Screenshot eines Telekom-GPON-Anschlusses.
Gut zu sehen ist die geringe Latenz zum ersten Hop außerhalb der eigenen vier Wände.
Natürlich können auch Infrastrukturkomponenten im 100er CGNAT Adressbereich liegen. Ist hier bei der DG auch so. Was anderes hab ich auch nie behauptet. Ist für das Problem aber auch völlig irrelevant.
Denn genauso sicher ist, dass der Hop 2 aus dem Traceroute lokal beim Kunden ist. 1 ms mit GPON und einigen Switches dazwischen: Never. Im Leben nicht. Nicht mal bei AON. Die 1 ms sind im ersten Switch im PoP schon Geschichte, und da bin ich noch längst nicht beim ersten Router. Im Trace von Edding sind es auch 4 ms, und das klingt schon eher machbar. So ist es in allen anderen Traces auch.
Wenn die Adresse nicht die WAN Adresse der Fritzbox ist, dann ist der ONT bei ihm ein Router. Das ist so sicher, wie das Amen in der Kirche. Die Probleme fangen vor dem ersten Infrastrukturhop an.
Um die Frage Router oder ONT beantworten zu können, wäre es nett, wenn tim2110 ein Foto und/oder Typbezeichnung der Box mit uns teilen würde...
Natürlich können auch Infrastrukturkomponenten im 100er CGNAT Adressbereich liegen. Ist hier bei der DG auch so. Was anderes hab ich auch nie behauptet. Ist für das Problem aber auch völlig irrelevant.
Denn genauso sicher ist, dass der Hop 2 aus dem Traceroute lokal beim Kunden ist. 1 ms mit GPON und einigen Switches dazwischen: Never. Im Leben nicht. Nicht mal bei AON. Die 1 ms sind im ersten Switch im PoP schon Geschichte, und da bin ich noch längst nicht beim ersten Router. Im Trace von Edding sind es auch 4 ms, und das klingt schon eher machbar. So ist es in allen anderen Traces auch.
Wenn die Adresse nicht die WAN Adresse der Fritzbox ist, dann ist der ONT bei ihm ein Router. Das ist so sicher, wie das Amen in der Kirche. Die Probleme fangen vor dem ersten Infrastrukturhop an.
Siehe GPON-Screenshot Telekom.
Absolut im grünen Bereich.
Siehe GPON-Screenshot Telekom.
Absolut im grünen Bereich.
Nee, dip0.t-ipconnect.de ist die WAN Adresse des Kundenrouters. Das war bei mir auch so bei der Telekom als ich noch V-DSL hatte 
Nein,
Nee, dip0.t-ipconnect.de ist die WAN Adresse des Kundenrouters. Das war bei mir auch so bei der Telekom als ich noch V-DSL hatte
Nein, ist sie nicht.
Bei einem traceroute ist die src Adresse der ICMP Time Exceeded Messages die einkommenden Interfaces.
Die WAN-Addresse des CPE sieht man in einem ausgehenden traceroute dementsprechend nicht, da es in diesem falle ein ausgehendes Interface darstellt.
Man müsste ein traceroute zu dem CPE(öffentliche Adresse vorausgesetzt) oder auch Host dahinter(bei IPV6/öffentliches v4 Subnet) machen womit es zu einem einkommenden Interface wird um sie zu sehen.(Vorraussetzung die Firewall blockiert nicht)
Das ist im vorliegen Fall etwas schwierig durchzuführen: CGN ohne IPv6
Bei einem traceroute ist die src Adresse der ICMP Time Exceeded Messages die einkommenden Interfaces.
Die WAN-Addresse des CPE sieht man in einem ausgehenden traceroute dementsprechend nicht, da es in diesem falle ein ausgehendes Interface darstellt.
Man müsste ein traceroute zu dem CPE(öffentliche Adresse vorausgesetzt) oder auch Host dahinter(bei IPV6/öffentliches v4 Subnet) machen womit es zu einem einkommenden Interface wird um sie zu sehen.(Vorraussetzung die Firewall blockiert nicht)
Eben dies.
Das ist auch einfach selbst festzustellen. Die FB zeigt die Adresse auf dem WAN-Interface an. Diese passt nicht zur Adresse im zweiten Hop.
Die Laufzeiten ohnehin nicht. Bei VDSL liegt der Hop rund 5 ms entfernt. Was soll die FB die ganze Zeit damit machen und warum sollte sie zweimal antworten?
Nee, dip0.t-ipconnect.de ist die WAN Adresse des Kundenrouters. Das war bei mir auch so bei der Telekom als ich noch V-DSL hatte
Schau doch bitte mal selbst in einen traceroute:
2 p3e9bf2c3.dip0.t-ipconnect.de (62.155.242.195) 5.004 ms 4.996 ms 4.968 ms
3 p509297a1.dip0.t-ipconnect.de (80.146.151.161) 8.988 ms 8.981 ms 9.111 msDie Telekom hat die Angewohnheit, ihren IPs Namen zu geben. Andere machen das sehr ähnlich.
Ohne dem Link gefolgt zu sein kann ich dir sagen, dass das alles Adressen im eigenen Transportnetz sind.
Der zweite Hop ist nicht die FB.
Vielleicht wäre es denkbar, dass der ONT nicht nur ein Medienwandler ist. Dann wäre aber die Latenz beschissen. Und das glaube ich erst bei einem entsprechenden Nachweis durch den OP.
Ich glaube auch noch nicht, dass sich die IP in der Infrastruktur befindet. Wir reden hier über einen Problemfall, nicht über den Normalfall. Wer weiß, welche abstruse Konfiguration zu diesem Verhalten führt.
Aber wie dem auch sei. Eine entscheidende Frage hat noch niemand beantwortet:
Warum hilft ein Reconnect bzw. ein ONT Neustart gegen die Probleme immer für 60 Minuten? Gegen Engpässe in der Infrastruktur hilft das mit Sicherheit nicht, vor allem nicht gegen zeitlich begrenzte. Der Neustart hilft garantiert nur bei den Geräten, die in das Problem involviert sind.
Nein es ist wie gesagt eine NAT Adresse der Fritz!Box.
Hier ist der zweite Hop auch die Fritze:
Du hast den NAT Loopback erreicht.
Vergleiche es mit einem traceroute zu einem echten Ziel.
Anbei übrigens mal ein Screenshot eines Telekom-GPON-Anschlusses.
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.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum