Ob es so einfach ist? Man zahlt ja auch erst ab Portierungsdatum dafür.
Beiträge von frank_m
-
-
Die Fritzbox lief ein paar Tage mit 100 Mbit mit Netcologne, da hatte ich soweit nichts verändert.
Aber jetzt läuft sie hinter einem anderen Modem, das ist was ganz anderes => Werksreset!
-
Auf Basis einiger Erfahrungen im Netz habe ich bereits DS-Lite abschalten lassen und im Vigor selbst den VLAN-Tag auf 10 gesetzt.
Das halte ich für gefährlich, da das Modem nur ein VLAN Tag unterstützt. Ich würde das Modem transparent arbeiten lassen und VLANs im Router abhandeln. Meines Wissens braucht Netcologne VLAN 20 für Telefonie.
Ich habe den Vigor 166 über Port 1 mit dem WAN-Anschluss der Fritzbox verbunden und dort unter Internet-Verbindungen angegeben, dass sie an einem Modem hängt.
Die Box war auf Werkseinstellungen? Du hast die Zugangsdaten manuell eingegeben oder per Assistent? Port 1 ist auch richtig? Es gibt Modems, die über Port 1 die Management Schnittstelle anbieten und über die anderen Ports Internet zur Verfügung stellen.
Es könnte sein, dass die Fritzbox selber versucht, VLAN 10 anzuwenden, was nicht mehr klappt, weil du das im Modem eingegeben hast.
-
Habe es so verstanden, dass bis zur Rufnummernportierung eine Übergangsnummer von DG zur Verfügung gestellt wird.
Die kann man aber üblicherweise nicht nutzen. Telefonie ist erst mit der Portierung verfügbar. Schau noch mal in deinen Vertrag.
-
Hier mal die Ergebnisse:
Code
Alles anzeigenpi@raspi:~ $ ping -c 20 1.1.1.1 (Cloudflare) PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=6.67 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=5.48 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=5.34 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=5.55 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=5.62 ms 64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=5.07 ms 64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=5.25 ms 64 bytes from 1.1.1.1: icmp_seq=8 ttl=58 time=5.55 ms 64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=5.28 ms 64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=5.21 ms 64 bytes from 1.1.1.1: icmp_seq=11 ttl=58 time=5.24 ms 64 bytes from 1.1.1.1: icmp_seq=12 ttl=58 time=5.40 ms 64 bytes from 1.1.1.1: icmp_seq=13 ttl=58 time=5.47 ms 64 bytes from 1.1.1.1: icmp_seq=14 ttl=58 time=5.18 ms 64 bytes from 1.1.1.1: icmp_seq=15 ttl=58 time=5.04 ms 64 bytes from 1.1.1.1: icmp_seq=16 ttl=58 time=5.39 ms 64 bytes from 1.1.1.1: icmp_seq=17 ttl=58 time=5.24 ms 64 bytes from 1.1.1.1: icmp_seq=18 ttl=58 time=5.27 ms 64 bytes from 1.1.1.1: icmp_seq=19 ttl=58 time=5.47 ms 64 bytes from 1.1.1.1: icmp_seq=20 ttl=58 time=5.46 ms --- 1.1.1.1 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 19031ms rtt min/avg/max/mdev = 5.040/5.408/6.669/0.327 ms pi@raspi:~ $ ping -c 20 8.8.8.8 (Google) PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=11.2 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=10.0 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=10.4 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=10.2 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=118 time=9.82 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=118 time=9.91 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=118 time=9.93 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=118 time=9.91 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=118 time=9.94 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=118 time=10.0 ms 64 bytes from 8.8.8.8: icmp_seq=11 ttl=118 time=9.68 ms 64 bytes from 8.8.8.8: icmp_seq=12 ttl=118 time=10.1 ms 64 bytes from 8.8.8.8: icmp_seq=13 ttl=118 time=9.85 ms 64 bytes from 8.8.8.8: icmp_seq=14 ttl=118 time=9.92 ms 64 bytes from 8.8.8.8: icmp_seq=15 ttl=118 time=10.1 ms 64 bytes from 8.8.8.8: icmp_seq=16 ttl=118 time=10.1 ms 64 bytes from 8.8.8.8: icmp_seq=17 ttl=118 time=10.2 ms 64 bytes from 8.8.8.8: icmp_seq=18 ttl=118 time=9.90 ms 64 bytes from 8.8.8.8: icmp_seq=19 ttl=118 time=10.4 ms 64 bytes from 8.8.8.8: icmp_seq=20 ttl=118 time=10.0 ms --- 8.8.8.8 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 19026ms rtt min/avg/max/mdev = 9.678/10.075/11.169/0.302 ms pi@raspi:~ $ ping -c 20 2606:4700:4700::1111 (Cloudflare IPv6) PING 2606:4700:4700::1111(2606:4700:4700::1111) 56 data bytes 64 bytes from 2606:4700:4700::1111: icmp_seq=1 ttl=59 time=5.07 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=2 ttl=59 time=4.60 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=3 ttl=59 time=4.66 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=4 ttl=59 time=4.84 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=5 ttl=59 time=4.71 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=6 ttl=59 time=4.59 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=7 ttl=59 time=4.58 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=8 ttl=59 time=4.71 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=9 ttl=59 time=4.66 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=10 ttl=59 time=4.69 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=11 ttl=59 time=4.67 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=12 ttl=59 time=4.59 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=13 ttl=59 time=4.69 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=14 ttl=59 time=4.83 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=15 ttl=59 time=4.90 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=16 ttl=59 time=4.57 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=17 ttl=59 time=4.62 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=18 ttl=59 time=4.58 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=19 ttl=59 time=4.63 ms 64 bytes from 2606:4700:4700::1111: icmp_seq=20 ttl=59 time=4.68 ms --- 2606:4700:4700::1111 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 19033ms rtt min/avg/max/mdev = 4.571/4.693/5.065/0.123 ms pi@raspi:~ $ ping -c 20 2001:4860:4860::8844 (Google IPv6) PING 2001:4860:4860::8844(2001:4860:4860::8844) 56 data bytes 64 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=119 time=9.93 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=119 time=9.08 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=119 time=9.05 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=4 ttl=119 time=9.14 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=5 ttl=119 time=10.1 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=6 ttl=119 time=9.09 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=7 ttl=119 time=9.15 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=8 ttl=119 time=9.05 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=9 ttl=119 time=9.05 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=10 ttl=119 time=9.08 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=11 ttl=119 time=9.15 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=12 ttl=119 time=9.06 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=13 ttl=119 time=9.10 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=14 ttl=119 time=9.24 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=15 ttl=119 time=9.29 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=16 ttl=119 time=8.99 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=17 ttl=119 time=9.02 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=18 ttl=119 time=9.19 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=19 ttl=119 time=9.05 ms 64 bytes from 2001:4860:4860::8844: icmp_seq=20 ttl=119 time=9.07 ms --- 2001:4860:4860::8844 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 19026ms rtt min/avg/max/mdev = 8.994/9.194/10.123/0.287 ms pi@raspi:~ $ -
Ja, stimmt, mtr via UDP geht irgendwie nicht richtig.
Ich hab ja einen AON Anschluss, und da sehe ich folgendes:
- IPv4 ist schlechter, als IPv6
- Jitter ist maßgeblich vom Ziel abhängig
- Die ersten Hops des Providers sind ganz schlechte Ziele. Riesiger Jitter von 2 ms und mehr
-
Ich würde jetzt mal auf die 1:64 Splitter tippen(je mehr Kunden desto längere Wartezeit bis ein Nutzer senden darf = höherer Jitter).
Dann müsste dein Upload Test das Ergebnis aber verschlechtern, da die wenigen Ressourcen, die du bekommst, jetzt neben dem Ping auch noch von anderen Daten benutzt werden wollen.
Ich tippe eher auf niedrige Priorität bei ICMP Paketen. Teste mal mtr mit UDP Paketen. Und mach die Tests via IPv6, nicht IPv4, weil da ein NAT Router dazwischen ist.
-
Due meisten Anbieter erlauben die nomadische Nutzung nicht. Geht das bei geotel überhaupt? Das solltest du vorher klären.
-
Bei uns z.B. ist es so, das Glasfaser Nordwest für die Telekom und die EWE die Anschlüsse legt.
Und die Anschlüsse sind schon realisiert? Solange die Bauphase noch läuft, ist es erfahrungsgemäß so, dass man noch kostenlos ordern kann. Nachanschlüsse sind dann häufig nicht mehr kostenlos.
-
Von daher: Wenn DSL abgeschaltet werden soll, dann bitte erst wenn a.) die Telekom das DG-Netz überbbaut, b.) übernommen oder c.) zumindest als Dark Fiber angemietet hat.
Da hab ich gegenteilige Erfahrungen gemacht. Wenn ich die Ausfallzeiten des DSL Anschlusses meiner Mutter mit denen meines Glasfaseranschlusses vergleiche, dann war meine Mutter öfter und länger offline. Und damit meine ich keine Sync-Verluste (die das größte Problem bei DSL sind und bei Glasfaser nicht auftreten). Ich meine wirklich Ausfälle ausgelöst durch die Infrastruktur der Telekom. Ich monitore das über RIPE Atlas.
Das super-stabile (keine Ironie!) Telekom-DSL-Netz hat mir in den letzten Monaten mehrmals den Arsch gerettet.
Da hast du Glück, wenn der DSL Anschluss so stabil ist. Viele DSL Kunden haben da andere Erfahrung gemacht, und je nach Anwendung kann auch das Peering der Telekom zum Problem werden.
Wie immer ist so eine Erfahrung eine höchst individuelle Einschätzung. Was nicht heißt, dass man nicht vorsorgen sollte. Wenn man aufs Home-Office angewiesen ist, sollte man eine Backup-Verbindung in Petto haben. Das empfehle ich aber dem DSL Kunden genauso, wie dem Kabel- oder Glasfaserkunden. Ich hab auch eine über Mobilfunk, das nur am Rande.
-
Dafür wären jetzt schon die Anschlusskosten mit drin (Straße aufreißen und Co). Da es langfristig wsl schon die Zukunftstechnologie wird, überlege ich mich drauf einzulassen.
Du kannst davon ausgehen, dass es zukünftig nicht mehr kostenlos ist. Inkl. Erdarbeiten können da schnell einige tausend EUR fällig werden - wenn du überhaupt noch einen Anschluss bekommst.
Glasfaserausbau: Der Bagger kommt nicht wieder - Golem.deSollte Deutschland bis 2030 nicht flächendeckend mit Glasfaser versorgt sein, liegt das auch daran, dass derzeit nicht alle Häuser angeschlossen werden. Diese…www.golem.deIn Kombination mit dem aktuell laufenden Bemühungen um die Abschaltung des Kupfernetzes kann das nur bedeuten: Nimm den Anschluss. Wenn du ihn jetzt verpasst, ist nicht sicher, dass du eine zweite Chance auf Glasfaser bekommst, bevor DSL abgeschaltet wird. Ganz abgesehen von den Kosten.
ThemaDie Kupfernetzabschaltung wird zum taktischen Mittel
Folgender Bericht ließ mich heute aufhorchen:
https://www.brekoverband.de/aktuelles/news…au-zu-staerken/
Es geht darin darum, wie die Telekom durch taktisches Abschalten von Kupfernetze die Kunden ins eigene Glasfasernetz treiben kann, und wie sie Konkurrenten behindert.
Interessant auch: Erste Abschaltungsanträge dürfte es spätestens nächstes Jahr geben - vielleicht schon Ende diesen Jahres.frank_m11. April 2024 um 19:00 Thema"Verzweifelte Menschen würden nach Glasfaser hungern und unversorgte Kommunen Probleme bekommen."
https://www.golem.de/news/deutsche-…403-183372.html
"Verzweifelte Menschen werden nach Glasfaser hungern" ... ja, Glasfaser ist das Medium der Zukunft, aber wer so auf Investorenfang geht, der klingt für mich eher verzweifelt als kompetent.
Wie seht ihr das?
Thomas197819. März 2024 um 23:46 ThemaEU: Abschaltung der TK Kupfernetze bis 2030
Es wird auch hier im Forum immer wieder über die bevorstehende Abschaltung der kupferbasierten TK Netze gesprochen bzw. spekuliert.
In der EU werden gerade die Weichen hierzu gestellt. 80% bis 2028, der Rest bis 2030.
https://www.heise.de/news/Digital-N…an-9635130.html
Es wird zwar nichts so heiß gegessen wie es gekocht wird, es wird jedochenkeng für die Kupferprotagonisten.HubeBube21. Februar 2024 um 21:49 ThemaDie Kupfernetzabschaltung in Deutschland hat begonnen
In zwei Testgebieten in Wiesbaden (Stadtteil Biebrich) und Bad Salzungen können ab Februar keine DSL-Zugänge mehr gebucht werden. In Bad Salzungen sollen zudem Kündigungen für bestehende DSL-Verträge erfolgen. Ausgenommen vom Test sind jedoch die TV-Kabelnetze von Vodafone.
https://www.golem.de/news/glasfaser…402-181789.html
Thomas19781. Februar 2024 um 22:08 mbo7727. Oktober 2023 um 03:13 -
Warum stellst du bei IPv6 "6to4 Tunnel" ein? Das halte ich für keine gute Idee.
-
Du meinst in Upstream Richtung, weil die Auslastung auf der Kapazität liegt?
Das dürfte GPON spezifisch sein.
-
Das ist eine logarithmische Darstellung. Du kommst kaum über 20% Auslastung, im Spitzenwert. In Upload-Richtung immer unter 10%.
-
Ich würde einfach keinerlei Rückbau Entscheidungen treffen, bis es zahlreiche Beispiele für funktionierendes Open Access gibt.
Ja, da stimme ich zu. Allein mir fehlt der Glaube, dass es so kommt.
-
Die UGG muß ihren Prozess so anpassen, das externe ONT provisioniert werden können.
Genau. Es reicht nämlich auch, wenn die UGG einen weiteren Parameter abfragt, dann funktioniert das Vorgehen auch nicht mehr.
-
-
-
Wenn ich henniero richtig verstanden habe, geht es ihm gar nicht um seinen Anschluss. Der scheint zu funktionieren.
Wie reagiert da die Telekom?
Das würde mich auch interessieren. Keine Ahnung, ob sie da irgendwann härter durchgreifen. Von so einem Fall höre ich zum ersten Mal.
Die Frage ist: Warum will deine Nachbarin nicht wechseln? Nach meinen Informationen unterscheiden sich die Preise in den Tarifen ja nicht.
-