Glasfaser FTTH Telekom 2000 down / 1000 up (XGS-PON)

@robert_s: Gute Frage - ich habe keinerlei Erfahrung mit Kabelanschlüssen.

Offenbar scheint ja irgendwie die Hardware - und zwar konkret die Puffergröße - eine Rolle zu spielen. Ich sehe solche Effekte z.B. auch bei GPON mit unterschiedlichen ONTs. Wir (ein Freund und ich) haben z.B. verschiedene Typen von ONT-Sticks auf Basis des Lantiq PEB98035 ausprobiert (ZyXEL PMG3000-D20B und Huawei MA5671A). Dem Chipsatz wird nachgesagt, dass er vglw. kleine Puffer hat.

Tatsächlich war bei Gigabit-Line-Speed trotz HSGMII mit 2.5 Gbps uplink zunächst keine gute Geschwindigkeit zu erzielen, bis wir an der OpnSense den FQ_Codel Shaper genutzt haben. Noch besser ging es mit einem Cake-Shaper unter OpenWRT. Witzigerweise sind neuere Firmwares laut Hack GPON sogar schlechter als ältere (Lantiq SDK 7.5.1 vs. 6.4.2).

Ich nehme an, dass die ISPs sich bei bekannten Problemen sich verständlicherweise nicht auf eine Lösung auf Kundenseite verlassen wollen. Teilweise folgen sie wohl auch nur den Empfehlungen der GPON-Hersteller. Es gibt z.B. Default-Einstellungen von Huawei, die neben den üblichen Checks von S/N und PLOAM-Passwort noch mehr Prüfungen durchführen, um ja den Anschluss von Fremdhardware zu verhindern. Das war bei meinem ISP wohl einfach noch in den Standardprofilen drauf (never change a running system).
 
mfgPC schrieb:
Bitte erkläre mal warum GPON „hoffnungslos“ veraltet ist?
Bitteschön:
https://www.itu.int/rec/T-REC-G.984.3
Erste Edition von 2004, dann noch eine 2006 und zuletzt 2014, und noch ein Amendment 2020.

Zum Vergleich: DOCSIS 1.1 ist 2005 erschienen, danach gab es DOCSIS 2.0, 3.0 und 3.1 (letzte Edition von 2023). Und DOCSIS beschränkt sich nicht nur darauf, wie man die Bits über das Medium bekommt, sondern befasst auch damit, wie man darauf Dienste in einer gewünschten Qualität realisiert, Stichwort: Advanced Queue Management (AQM).

In diese Richtung scheint GPON nie entwickelt worden zu sein. Vielleicht hat man sich ja gedacht, dass man einfach alles mit der nächsten Technologiegeneration erschlägt - und nicht damit gerechnet, dass geizige Telkos noch GPON betreiben, wenn sie vom Koax bereits rechts überholt worden sind.
Ergänzung ()

meyergru schrieb:
Ich nehme an, dass die ISPs sich bei bekannten Problemen sich verständlicherweise nicht auf eine Lösung auf Kundenseite verlassen wollen. Teilweise folgen sie wohl auch nur den Empfehlungen der GPON-Hersteller.
Was mögen die wohl empfehlen? "Geht mit GPON nicht über 940Mbit/s. Für mehr haben wir ganz schicke XGS-PON OLTs und ONTs im Angebot"...
Ergänzung ()

mfgPC schrieb:
Ich vermute mal auch, dass anfangs die Netze ganz anders dimensioniert waren und Multicast mit zusätzlich großer Erwartung vom Erfolg von MagentaTV einfach sinnvoll erschien.
Ja, diese Panik von wegen: "Wenn 14 Mio um 20 Uhr die Tagesschau einschalten, bricht das Internet in Deutschland zusammen". So ein Blödsinn! 14 Mio IPTV-Kunden muss man erst mal haben. Bei der Elektromobilität haben die Stromnetzbetreiber derzeit ähnliche Panikattacken. Wozu auch über den Tellerrand schauen... :rolleyes:
 
Zuletzt bearbeitet:
Richtig, die allerneuesten DOCSIS-Standards versprechen jetzt endlich mehr (so wie XGS-PON auch mehr verspricht als GPON), aber das tatsächlich in der Breite eingesetzte Krams hatte für mich immer den fahlen Beigeschmack des "Ausbauen bis zur letzten Meile tun wir erst, wenn die Daten für die Benutzer nur noch dahintröpfeln und letztere dann in rauen Mengen abwandern.".

Außerdem: wenn ich konkret bei mir in München gucke, habe ich die Wahl zwischen VDSL (250/50), Kabel (1000/50) und Glasfaser (1000/400). Und da mich nicht nur der Upstream interessiert, fällt die Wahl relativ leicht.

Insofern auch hier wieder der Unterschied zwischen Theorie und Praxis: Es zählt, was ich praktisch bestellen kann. Und selbst, wenn ich nach dem "Könnte" gehe, sehe ich nicht, wo DOCSIS 4.0 so viel toller sein soll als XGS-PON.

Investitionsschutz wird hüben wie drüben betrieben und dass am Ende der Kunde für die neuesten Gimmicks bezahlt, ist auch klar.
 
meyergru schrieb:
Richtig, die allerneuesten DOCSIS-Standards versprechen jetzt endlich mehr (so wie XGS-PON auch mehr verspricht als GPON), aber das tatsächlich in der Breite eingesetzte Krams hatte für mich immer den fahlen Beigeschmack des "Ausbauen bis zur letzten Meile tun wir erst, wenn die Daten für die Benutzer nur noch dahintröpfeln und letztere dann in rauen Mengen abwandern.".
Bei mir ist "Fiber Deep" jedenfalls offenbar schon angekommen: Fibernode im Kasten an der nächsten Straßenecke, 175m Koaxkabel bis zu mir, 128 Kunden im Segment, davon 32 in meinem Upstream-Segment. "GPON-like segment size", wie angekündigt.

Dabei wäre der letzte Segmentierungsschritt von ~350 Kunden auf besagte 128 Kunden von der Auslastung her noch lange nicht nötig gewesen. Die Überbuchung liegt jetzt im niedrigen zweistelligen Bereich, und das Segment "langweilt" sich rund um die Uhr bei Auslastungen von 10-20%.
 
meyergru schrieb:
Dann können wir festhalten, dass es bei Dir nicht die Gigabit-Limitierung hinter dem ONT ist. Dann kommt auch bei Dir Grund Nummer 2 in Frage - war ja bei mir auch so.

Und dass es bei mfgPC bei der Telekom offenbar keine Limitierung gibt, muss nicht dagegen sprechen - wie andere ISPs auch haben die vermutlich in unterschiedlichen Ausbaugebieten unterschiedliche Hardware verbaut. Mein Ansprechpartner sagte was von "auf den alten Huaweis"... zum Glück hat ihn das First-World-Problem technisch interessiert und er konnte die Ursache finden und beseitigen.
Es gibt ja auch keine Limitierung. Ich bin da eher die Ausnahme. Mir sind bis jetzt erst 3 weitere Anschlüsse quer durch DE bekannt, die das identische Bild zeigen.
Bei allen anderen geht es bis 1100 wie angegeben.

Einzige Gemeinsamkeit: Alte OLT-Platform Anfang 10er
Andreas als Mitarbeiter hatte aber auch schon drüber geschaut und nichts feststellen können.

Interessant ist aber dann, dass mein 1&1 Anschluss über das Versatel Backbone die 1100 erreicht. Vorher über Telekom WIA hingegen nicht. Der verhielt sich identisch zum Telekom Original, sogar identischer IP-Bereich. Teilweise unterschied sich nur die letzte Ziffer. Die Umstellung war auch rein virtuell, es gab weniger Minuten Downtime (per Brief angekündigt) und danach war es eine 1&1 IP inkl. neuem Gateway.

Wie genau sieht eigentlich der Pfad ab OLT aus, wenn es einen Reseller mit eigenem BNG/ Backbone gibt?
Viel ändern dürfte sich eigentlich nicht.
Die werden ja wohl kaum eine weitere Faser oder Wellenlänge zum Gerät kriegen, oder?

Eine vergessene Einstellung am OLT, BNG bzw. Shaper könnte es auch sein. Vielleicht ist irgendwo in einer Config noch etwas hardcoded, das vor Drölf Jahren mal so eingestellt wurde. Als es 2012 bei der Telekom nur Call & Surf Comfort Fiber 100/200 gab, ist ein ONT-Profil mit Downstream QoS 1000 nicht weiter aufgefallen.

Man weiß es nicht und wird es auch nie erfahren ;)

meyergru schrieb:
Offenbar scheint ja irgendwie die Hardware - und zwar konkret die Puffergröße - eine Rolle zu spielen. Ich sehe solche Effekte z.B. auch bei GPON mit unterschiedlichen ONTs. Wir (ein Freund und ich) haben z.B. verschiedene Typen von ONT-Sticks auf Basis des Lantiq PEB98035 ausprobiert (ZyXEL PMG3000-D20B und Huawei MA5671A). Dem Chipsatz wird nachgesagt, dass er vglw. kleine Puffer hat.
meyergru schrieb:
Tatsächlich war bei Gigabit-Line-Speed trotz HSGMII mit 2.5 Gbps uplink zunächst keine gute Geschwindigkeit zu erzielen, bis wir an der OpnSense den FQ_Codel Shaper genutzt haben. Noch besser ging es mit einem Cake-Shaper unter OpenWRT. Witzigerweise sind neuere Firmwares laut Hack GPON sogar schlechter als ältere (Lantiq SDK 7.5.1 vs. 6.4.2).
Das war bei der Telekom nie ein Problem. Die Geschwindigkeit ist mit jedem getesteten ONT (SFP oder Box) identisch schnell.
Auch der in Kanada oder Italien oft beschriebene FQ_Codel Shaper für den Upload bei sehr schnellen Tarifen war nie erforderlich.

Die ältere Firmware mit OpenWrt 12.09 ist ebenfalls identisch zur neueren mit 14.07

Wichtig ist allerdings eine schnelle CPU, da das olle PPPoE zumindest unter FreeBSD nicht gut skaliert.
Hinzu kommt, dass einige Treiber nicht alle verfügbaren Queues auf der NIC nutzen.

meyergru schrieb:
Ich nehme an, dass die ISPs sich bei bekannten Problemen sich verständlicherweise nicht auf eine Lösung auf Kundenseite verlassen wollen. Teilweise folgen sie wohl auch nur den Empfehlungen der GPON-Hersteller. Es gibt z.B. Default-Einstellungen von Huawei, die neben den üblichen Checks von S/N und PLOAM-Passwort noch mehr Prüfungen durchführen, um ja den Anschluss von Fremdhardware zu verhindern. Das war bei meinem ISP wohl einfach noch in den Standardprofilen drauf (never change a running system
Kann man aber auch verstehen. Nichts ist schlimmer als Kunden, die irgendwas rumbasteln und womöglich das gesamte Segment lahmlegen.
Da bin ich froh, dass mir die Oma nebenan nicht mein Internet killt, wenn der Receiver spinnt. Es gibt auch keinen Nachbarn, der den Verstärker im Keller verstellen kann, damit er "besseres Bild" kriegt.
Bei DOCSIS alles an der Tagesordnung, wenn man Pech hat.

Über die Stabilität kann ich mich zumindest überhaupt nicht beschweren.
In den letzten 7 Jahren war die Verbindung nicht einmal ungeplant down. Es gibt etwa einmal pro Jahr nachts ein paar Sekunden (evtl. Linecard Firmware?) und nartürlich meine eigenen Themen wie Updates für Firewall etc.
Das habe ich selbst bei teilweise sündhaften teuren Businessleitungen schon schlechter erlebt.

Sogar Stromabschaltungen gab es schon mehr, die man aber dank P(assive)ON mit einer USV komplett überbrücken kann. Der halbe Ort hat keinen Strom, aber das Internet läuft weiter :D
 
KernelMaker schrieb:
Wie genau sieht eigentlich der Pfad ab OLT aus, wenn es einen Reseller mit eigenem BNG/ Backbone gibt?
Das wird bei L2-BSA (eigener BNG vom Reseller) am Telekom-BNG ausgekoppelt und geht dann zum Reseller-BNG. Sprich von OLT bis Telekom-BNG geht alles über eine Leitung.
 
  • Gefällt mir
Reaktionen: KernelMaker und kingpin42
Interessentenliste wäre schon ganz nett

Können sie gern auch auf GPON schalten, ich stelle es mir auch selbst in der config ein :D
 
  • Gefällt mir
Reaktionen: sendai
Mit Interessenlisten wüssten sie ja am ende womöglich wo sich ein bevorzugtestes Ausbauen oder das XGS-PON Aufrüsten von Bestandsgebieten lohnen könnte. Das wäre zu fortschrittlich 😅

Ich würde das auch sofort über GPON nehmen, dürfte in meinem Segment keinen stören.
 
sendai schrieb:
Ich würde das auch sofort über GPON nehmen, dürfte in meinem Segment keinen stören.
Du kannst doch für fast den gleichen Gesamtpreis einen zweiten MagentaZuhause 1000 Tarif bestellen. Dann kannst du vielleicht sogar mit einem(!) ONT mit 2,5G LAN-Port zwei PPPoE-Verbindungen mit den jeweiligen Zugangsdaten aufbauen. Sollte die Telekom auf eine PPPoE-Session pro ONT begrenzen, dann halt einen zweiten ONT.

Und dann die beiden WAN-Verbindungen zu einer mit 2000/500Mbit/s bündeln.
 
Das ist de facto gar nicht so einfach: Wenn kein Multilink-PPPoE unterstützt wird, ist nämlich das Gateway für beide Verbindungen normalerweise dasselbe. Mit OpnSense habe ich das mit einer Instanz nicht hinbekommen.

Am Rande: Wenn der BRAS doppelte Anmeldungen mit den selben Zugangsdaten nicht verhindert, geht das sogar mit denselben Zugangsdaten - es soll ja ISPs geben, die mit dieser Möglichkeit nicht rechnen.

Und wie gesagt, sind dann zwei unabhängige Verbindungen, die im selben Router eventuell Routingprobleme machen.
 
meyergru schrieb:
Das ist de facto gar nicht so einfach: Wenn kein Multilink-PPPoE unterstützt wird, ist nämlich das Gateway für beide Verbindungen normalerweise dasselbe. Mit OpnSense habe ich das mit einer Instanz nicht hinbekommen.
Ich habe es mit Linux-Bordmitteln hinbekommen. Das ist dann eben loadbalancing über 2 WAN-Verbindungen (mit unterschiedlichen IP-Adressen). Es hängt von der Anwendung ab, ob mehrere Verbindungen zu unterschiedlichen Zielen aufgebaut werden. Der ookla Browser-Speedtest kriegt das ganz gut für den Download hin:

15977459758.png


Im Upstream mag es damit nicht gelingen, aber das schafft dann der fast.com Speedtest (siehe auch mein Profilbild). Wobei fast.com im Download dann schon grob ungenau wird und mir bis über 3Gbit/s bescheinigt...
 
Der ping bei laufendem Download ist halt schon bescheiden.
Liegt das an deinem loadbalancing?
 
Per Session Loadbalacing bestimmt umsetzbar, trotzdem is 1x 2000/1000 im Handling angenehmer als 2x 1000/250 im Loadbalancing, welche dann noch mal mehr als der Magenta Zuhause 2000 kosten würden.

Dann gibt's sicher auch noch Dinge die von Session Loadbalacing nicht wirklich profitieren.

Am Ende des Tages ist XGS-PON auch nur eine weitere Zugangstechnik und eigentlich nichts wo man nicht auch mit dem vorhanden GPON Giga klar kommt.
Wahrscheinlich ist es nur der Technik Enthusiasmus für 2000/1000 und XGS-PON, der einen das bestellen lassen würde. 🤣
 
Brainorg schrieb:
Der ping bei laufendem Download ist halt schon bescheiden.
Liegt das an deinem loadbalancing?
Fehlender Traffic Shaper bzw. Verhinderung von Bufferbloat

robert_s schrieb:
Du kannst doch für fast den gleichen Gesamtpreis einen zweiten MagentaZuhause 1000 Tarif bestellen. Dann kannst du vielleicht sogar mit einem(!) ONT mit 2,5G LAN-Port zwei PPPoE-Verbindungen mit den jeweiligen Zugangsdaten aufbauen.
Setzt aber voraus, dass beide Anschlüsse auf dem gleichen OLT-Port liegen, was bei mir bewusst nicht der Fall ist. Darum hatte ich den Techniker gebeten.

robert_s schrieb:
Sollte die Telekom auf eine PPPoE-Session pro ONT begrenzen, dann halt einen zweiten ONT.

Und dann die beiden WAN-Verbindungen zu einer mit 2000/500Mbit/s bündeln.
Habe ich ja genau so im Einsatz, wobei das nur für mehrere Connections bzw. Load Balancing (Client 1 lädt Steam Spiel, Client 2 lädt Windows Updates, Client 3 schaut Netflix) gut funktioniert.

Für echtes Bonding braucht es einen Server z.B. beim ISP oder im Datacenter, der die Pakete von zwei Leitungen wieder zusammensetzt. OpenMPTCProuter ist ein cooler Ansatz dafür, da es Multipath TCP nutzt.

Ich konnte sogar mittels Static Bonding (Round-Robin) wirklich brauchbare Ergebnisse erzielen, da die beiden Verbindungen qualitativ und auch aufs Routing bezogen identisch sind (zumindest als mein zweiter 1&1 noch Telekom war). Sobald aber die Leitungen nicht gleich sind, geht das aufgrund von Out-of-Order Fehlern quasi nicht mehr.

Das Bonding funktioniert dann auch für Single Connections, wobei man dann wieder Probleme mit der IP-Adresse der Klasse Datacenter bekommt. Benötigt dann Ausnahmen für Dienste wie Netflix, auch Captchas gibts ohne Ende.

Und ein 10G Port am besten noch unmetered an einem Dedicated Server kostet auch mal eben weitere 100€/Monat. So sind das insgesamt fast 300€/Monat, da wäre mir eine schnellere einzelne Leitung schon lieber :D

Dafür gibts aber auch echte statische IPs bzw. ganze Subnetze zuhause am eigenen Anschluss. Die kriegt man privat so nicht und auch nicht bei "Spar" Business (Maximal eine IP kein Subnetz).

meyergru schrieb:
Das ist de facto gar nicht so einfach: Wenn kein Multilink-PPPoE unterstützt wird, ist nämlich das Gateway für beide Verbindungen normalerweise dasselbe. Mit OpnSense habe ich das mit einer Instanz nicht hinbekommen.

Und wie gesagt, sind dann zwei unabhängige Verbindungen, die im selben Router eventuell Routingprobleme machen.
Funktioniert unter FreeBSD (zumindest pf) eigentlich problemlos, sofern das WAN-Interface ein Tunnelprotokoll wie PPPoE ist. Damit sind identische Gateways möglich. Alles andere geht nicht, höchstens Aktiv Passiv.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Brainorg
KernelMaker schrieb:
Setzt aber voraus, dass beide Anschlüsse auf dem gleichen OLT-Port liegen, was bei mir bewusst nicht der Fall ist. Darum hatte ich den Techniker gebeten.
Hm.. vielleicht der Workaround, den Pilotausbau abwarten, Neuanschluss bestellen und hoffentlich einen Techniker erwischen den man auch freundlich darum bitten kann auf einem anderen Port am OLT zu landen, wo dann schon ne XGS-Combo Optic steckt. 🤣

Setzt natürlich vorraus die Telekom hat hier nicht schon vorsorglich alle Fasern im Gf-AP auf den gleichen Koppler im Nvt gelegt und enden damit am gleichen alten OLT Port.
 
sendai schrieb:
und hoffentlich einen Techniker erwischen den man auch freundlich darum bitten kann auf einem anderen Port am OLT zu landen, wo dann schon ne XGS-Combo Optic steckt. 🤣
In Zeiten von GBGS sollte es mich wundern, wenn der NE3-Techniker da noch Einfluss hat, abgesehen davon, das er die Optik im OLT nicht kennt. Das war ja schon vor GBGS ein großes Entgegenkommen vom Techniker.
sendai schrieb:
Setzt natürlich vorraus die Telekom hat hier nicht schon vorsorglich alle Fasern im Gf-AP auf den gleichen Koppler im Nvt gelegt und enden damit am gleichen alten OLT Port.
Das ist recht wahrscheinlich, außer der Koppler am NVt ist zwischendurch voll geworden.
 
sendai schrieb:
[...] den Pilotausbau abwarten, Neuanschluss bestellen und hoffentlich einen Techniker erwischen den man auch freundlich darum bitten kann auf einem anderen Port am OLT zu landen, wo dann schon ne XGS-Combo Optic steckt. 🤣
Funktioniert nicht, denn der NE4-Techniker kann nicht ändern auf welchem Port der Anschluss geschaltet wird.
sendai schrieb:
Setzt natürlich vorraus die Telekom hat hier nicht schon vorsorglich alle Fasern im Gf-AP auf den gleichen Koppler im Nvt gelegt und enden damit am gleichen alten OLT Port.
Typischerweise werden für kleine MFH 1:4 Koppler am AP genutzt (und 1:8 im NVt). Bei einem Neubau wird oft der gesamte AP schon mit Signal versorgt. Damit würde der komplette AP auf dem gleichen Port landen.
Bei einem Altbau (vorher Kupfer Versorgung) werden meist nur die ersten 4 Stifte am AP mit Signal versorgt und sobald diese voll sind, wird erweitert und wenn wie @rezzler schrub der Koppler voll ist, würden die nächsten 4 Stifte dann auf einem anderen Port enden.

Bei Häusern mit mehr als 32 Wohneinheiten wird ggf. auch ein 1:32 Koppler im AP verwendet. Da hängt dann sowieso alles auf dem gleichen Port bzw. zumindest die ersten 32 Anschlüsse.
rezzler schrieb:
In Zeiten von GBGS sollte es mich wundern, wenn der NE3-Techniker da noch Einfluss hat, abgesehen davon, das er die Optik im OLT nicht kennt. Das war ja schon vor GBGS ein großes Entgegenkommen vom Techniker.
Wenn das System einen Auftrag dafür schreibt vielleicht schon, aber im Normalfall wird ja nur ein NE4 Auftrag geschrieben.
 
rezzler schrieb:
Das ist recht wahrscheinlich, außer der Koppler am NVt ist zwischendurch voll geworden.
Hier gibt's nur ein paar vereinzelte GPON Inseln im jetzt flächig geplanten XGS Ausbaugebiet.
Bei meinem GPON Segment bin ich mir recht sicher, da ist noch Luft für weitere Anschlüsse.
Für die noch nicht erschlosssende Nachbarschaft kann man dann nur hoffen, dass die NE3 Planung sie dann nicht auf meinem alten GPON Koppler/Segment wirft, auch wenn sie jetzt Fiber 2000 vorbestellen könnten. 😅

blastinMot schrieb:
Typischerweise werden für kleine MFH 1:4 Koppler am AP genutzt (und 1:8 im NVt). Bei einem Neubau wird oft der gesamte AP schon mit Signal versorgt. Damit würde der komplette AP auf dem gleichen Port landen.
Bei einem Altbau (vorher Kupfer Versorgung) werden meist nur die ersten 4 Stifte am AP mit Signal versorgt und sobald diese voll sind, wird erweitert und wenn wie @rezzler schrub der Koppler voll ist, würden die nächsten 4 Stifte dann auf einem anderen Port enden.

Bei Häusern mit mehr als 32 Wohneinheiten wird ggf. auch ein 1:32 Koppler im AP verwendet. Da hängt dann sowieso alles auf dem gleichen Port bzw. zumindest die ersten 32 Anschlüsse.
Wie sähe das Beispiel bei EFH oder Doppelhaushälften (Altbau mit bestehender Kupferversorgung), welche zu FTTH1.7 Zeiten erschlossen wurden?

Aber denke auch nicht wirklich das ein Zweitanschluss mir XGS-PON einbringen könnte.
Da hilft wohl eher ne zusätzliche Hausnummer+neuen Hausanschluss und viel Glück nicht auf dem gleichen Koppler/GPON Segment zu landen, oder übers noch nicht erschlossende Nachbarhaus Fremdversorgen lassen 🤣
 
Zuletzt bearbeitet:
Zurück
Oben