Beiträge von pufferueberlauf

Zitat von hetti72

Ok, dann hab ich das wirklich falsch verstanden. Aber ich finds immer noch verwunderlich das Leute glauben das es bei FTTH wieder zurück zu PtP / AON gehen könnte. PON is the way

PON mag "the way" sein, aber PtMP ist trotzdem ein Sparausbau der uns noch in den hintern kneifen wird. Der Punkt fuer PtP ist IMHO sweniger, AON, sondern das es echte Faser-Entbuendelung erlaubt, und die belebt den Wettbewerb (weil Wettbewerber nicht zu reinen Resellern der Technologie des Betreibers degradiert werden). Ueber entbuendelte Fasern kann der mietende ISP dann selber entscheiden ob er PON oder AON anbieten will und for allen welche PON oder AON Variante.

Zitat von mbo77

Und zwar weltweit. Da will und kann sich kein Provider die Kostenvorteile entgehen lassen.

Nein, nicht weltweit, da wo die Regulierer weitsichtig genug sind (z.B. Schweiz) wird PtP gebaut, und im Resultat hat das Hochpreisland Schweiz deutlich gunstigere Internetpreise als Deutschland. Aber ueberall da wo man ISPs selber entscheiden laesst, ja da wird auf PON und vor allem PtMP gesetzt...

Zitat von hetti72

es ist auch ein deutlicher Unterschied ob ich 24 Fasern spleißen muss oder 768.

Das ist wahr, aber die Erwartung ist, dass diese Spleisse fuer Jahre werden halten...

Na ja, die CPUs der 5500er Serie von AVM sind auch zu schmalbruestig um interessante Sachen bei 2.5 oder auch "nur" 1 Gbps zu erledigen. Was die Offloadengines angeht, da wiuerde ich zumindest ausreichende Leistung bis 1 Gbps erwarten, vielleicht auch mehr, aber das ist Spekulation meinerseits.

Zitat von -104-

wieder zurück zur 5590 wechseln und dort ein 10G AON Modul betreiben.

Na ja, die 5590 ist ein bisschen zu schwachbruestig mit CPUs bestueckt um mit 10 Gbps viel Sinnvolles anstellen zu koennen, d.h. alles was nicht ueber Offloadengines bearbeitet wird, duerfte unerfreulich langsam werden. Paketprozessierung @10 Gbps ist kein Pappenstiel.

Mmmh, also wenn ich die Kapazitaetsbemessungsmethode eines befreundeten ISPs anwende und von einem 64er Segment ausgehe, komme ich auf:

GPON brutto it FEC:

2488.32 * 239/255 = 2332.19 Mbps
1244.16 * 239/255 = 1166.10 Mbps

Dazu noch sagen wir 1 Mbps OMCI Traffic pro ONT (Huaweis Standard ist wohl 5 Mbps pro ONT):

((1244.16-(64*1)) - (1000)) / 64 = 2.815 Mbps.

D.h. dieses Segment erlaubt den einzelnen ONTs eine durchschnittliche Last in der Spitzenzeit von 2.815 Mbps. Das ist ziemlich nahe an den aktuellen Auslastzungszahlen fuer den Upload aus Preseems Network Report 2025 (der genau genommen nur fuer Preseem Kunden gilt).

Kann man aktuell machen, aber das erscheint mir auf Kante genaeht... Wenn man allerdings nur 32er Segmente nutzt:

((1244.16-(32*1)) - (1000)) / 32 = 6.63 Mbps.

Aber das muss natuerlich jeder ISP selber sehen wie er die Kapazitaet dimensioniert und solange die FTTH Netze eher nur ein paar vereinsamte Nutzer haben ist das ganze eher theoretisch. Allerdings scheint es kaum ISPs in Deutschland zu geben die per GPON 1000 Mbps Upload nbieten, oder mehr als 1000+Kleingeld im Download (mit Kleingeld meine ich den Umstand, dass die Telekom bei den nominellen 1000er Tarifen brutto eher 1200 Mbps provisioniert, damit netto ausreichend viel ankommt und die Kunden das Gefuehl haben etwas geschenkt zu bekommen).

Zitat von Sowieso

Bezogen auf die Anzahl der Haushalte glaube ich das nicht. Die vor allem in Städten wie Berlin, Hamburg, Köln/Bonn eigenwirtschaftlich gebauten XGS-PON Gebiete (siehe Karte) beinhalten sicherlich deutlich mehr Haushalte als die versprengten XGS-PON Gebiete in Fördergebieten.

Lass es mich anders formulieren, buchen kannst die den 2000er laut Aussage der Telekom in gefoerdert ausgebauten Gebieten und in zwei zusaetzlichen Pilotgebieten (eines davon Berlin). Ob/wie weit in eigenfinanziert ausgebauten Gebieten XGSPON oder Combo-OLTs verbaut wurden kann ich nicht sagen (wobei das verlinkte Video andeutet, dass Combo-OLTs weiter verbreitet sind).

Merci, Entschuldige die Demonstion meiner dig Inkompetenz... (ueblicherweise starte ich mit "man dig" aber diesmal war ich mir zu sicher...)

Bei Google, so wie world of tank das empfiehlt (zumindest hat das meine kurze Recherche ergeben, ich spiele das Spiel selber nicht).

user@123-123456 ~ % dig @2001:4860:4860::8888 dl-wot-gc.wargaming.net   

; <<>> DiG 9.10.6 <<>> @2001:4860:4860::8888 dl-wot-gc.wargaming.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17546
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dl-wot-gc.wargaming.net.	IN	A

;; ANSWER SECTION:
dl-wot-gc.wargaming.net. 78	IN	CNAME	cl-ac7e0adb.gcdn.co.
cl-ac7e0adb.gcdn.co.	20	IN	A	92.223.40.62

;; Query time: 21 msec
;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888)
;; WHEN: Mon Oct 13 21:42:42 CEST 2025
;; MSG SIZE  rcvd: 101

Also die Telekom setzt XGSPON OLTs primaer in gefoerderten Gebieten ein. Die Foerderung nach Gigabitrichtlinie 2.0 verlangt dass (mindestens) symmetrisches Gigabit buchbar ist, und in solchen Gebieten bietet die Telekom als maximalen Tarif Glasfaser2000 an das mit 2/1 Gbps die Anforderung uebererfuellt. Bei GPON ist ein 1 Gbps Downstream wohl ganz passabel moeglich, aber mit einer nutzbaren Segmentskapazitaet von < 1.2 Gbps im Upload wird das eng darueber 1 Gbps Upload-Tarife zu schnitzen. Ansonsten wird sich zeigen wann und wo XGSPON Tarife angeboten werden. Solanage die Kundschaft allerdings solche Tsarife die nur mit XGSPON realisiert werden koennen in grosser Stueckzahl nachfragt und auch zu buchen bereit ist, sehe ich wenig Motivation fuer ISPs den wohl kommenden Wechsel hin zu XGSPON zu beschleunigen. IMHO duerfte da eine Umstellung irgendwann im Rahmen des normalen Hardwareaustauschs kommen, also wenn der GPON OLT am Ende ist und dann XGS oder Combo OLT nicht oder nur wenig teurer sind als ein neuer reiner GPON OLT. Aber das ist Spekulation...

Mmmh, der OP scheint world of tanks zu spielen, ich bekomme da fuer dl-wot-gc.wargaming.net immer eine IPv4 Adresse, egal ob ich IPv4 oder IPv6 DNS Server frage.

Das P in PON (GPON oder Xgspon) steht fuer passiv, d.h. da sind keine aktiven Verstaerker eingeplant zwischen OLT und ONT. Daher darf die Daempfung zwischen beiden auch ein bestimmtes Link Budget nicht ueberschreiten... (Ein Grund warum optische Netze nach Fertigstellung durchgemessen werden und warum diese Messungen mit "abgeheftet" werden). D.h. man kann Splitter kaskadieren, solange man noch im Link Budget bleibt... (auch die reine Faser hat etwas Daempfung pro Meter, und Fusionsspleisse und Steckverbinder auch, aber der Loewenanteil der Daempfung sollte von dem/den Splitter(n) kommen).

Zitat von mbo77

ob du überhaupt in der Nähe von 1000 Verbindungen bist.

Na ja, was zaehlt ist weniger was Opnsense als aktive Verbindungen zaehlt, sondern was der AFTR der DG da macht... und wenn die sehr lange TimeOuts hat dann mag das relevante Limit erreicht sein, selbst wenn der eigene NAT router noch Luft nach oben andeutet.

Zitat von gponner

AON ist nicht nur ein bisschen teurer als GPON, sondern erheblich teurer! Die Hauptkostentreiber sind der Platzbedarf und die Energiekosten des Providerequipments. Am besten schneidet XGS-Pon ab. (Siehe z.B. https://www.optisis.at/Portals/2/Doku…p=1716552657214)

Mmmh, wenn ich das lese finde ich da:

Zitat

In practice however in XGS-PON networks, we can easily offer services up to 10G.

Und das ist halt unpraezise... bzw. zeigt, der Vergleich ist, trotz des Claim "apples to apples", ein wenig mit der heissen Nadel gestrickt:

XGS-PON
T-REC-G.9807.1-201606-I!!PDF-E.pdf
B.9.2.1 Line rate
The transmission line rate is a multiple of 8 kHz. The target standardized XGS-PON system supports
the following variant: XGS-PON with a downstream line rate of 9.95328 Gbit/s and an upstream line
rate of 9.95328 Gbit/s.

C.10.1.3.1 Downstream FEC
C.10.1.3.1.1 Downstream FEC codeword
For 9.95328 Gbit/s nominal line rate, the downstream FEC code is RS(248, 216). Each downstream
PHY frame contains 627 FEC codewords. Each codeword is 248 bytes long. Within a codeword, 216
data bytes are followed by 32 parity bytes.

C.10.1.3.2 Upstream FEC
C.10.1.3.2.1 Upstream FEC codeword
For 9.95328 Gbit/s, the upstream FEC code is RS(248, 216). The PSBu section is not included in the
FEC codeword. The first codeword in a PHY burst begins with the upstream FS header section. All
allocations of a particular ONU have the same FEC status. Contiguous allocations are encoded as a
single block of data, so that there is at most one shortened codeword at the end of the burst. For
9.95328 Gbit/s, the upstream FEC parity bytes insertion and payload reconstruction are shown in
Figures C.10.13 and C.10.14, respectively.

brutto nach FEC:
9.95328 * (216/248) = 8.66899 Gbps

8.7 < 10... bin bespannt wie die mit 8.7 brutto 10 produzieren wollen. Ja, generell ist es nicht falsch, dass man mit XGS-PON hohe Gbps recht zuverlasessig realisieren kann, aber halt keine 10.

Alles in allem kein schlechter Text, aber au8ch keine wissenschaftlich objektive Abhandlung optisis hat sich fuer PON entschieden und versucht davon zu ueberzeugen. Das ist deren gutes Recht, so wie es mein Recht ist das anders zu sehen (Was letztlich irrelevant dafuer ist was tatsaechlich ausgebaut wird: PtMP wo ISPs eigenfinanziert uasbauen, PtP wo ISPs mit Foerderung ausbauen, mit dem Resultat eines Fleckenteppichs bei9i dem die Wettbewerbsvorteile von PtP nicht zur Geltung kommen koennen, da in den lukrativsten Gebieten nur PtMP existiert).

Ich vermute, Du meinst mich... aber zum einen ist ein neuer 911er nicht nur 10% teurer als ein neuer Golf, zum anderen habe ich hoffentlich klar gemacht, dass es mir hier nicht um AON gegen PON geht, sondern darum den Markt fuer Internetzugang effizienter zu machen in dem mehr Wettbewerb ermoeglicht wird. Bin halt Endkunde und kein ISP

Zitat von frank_m

Selbst wenn er eine öffentliche IP hätte, aber zwei Endgeräte zu Hause, die beide einen VPN Tunnel zum AG aufbauen wollen (Handy und Notebook), hätte er das Problem.

Nein, das waere IMHO dann ein selbst gewaehltes Problem mit simpler Loesung "mach' es halt nicht gleichzeitig".

Zitat von frank_m

Klar, die größere Anzahl an Kunden hinter einem CG-NAT Router erhöht die Wahrscheinlichkeit von Kollisionen, ändert aber nichts an der grundlegenden Problematik.

Das sehe ich anders, der Unterschied ist IMHO: im ersten Fall hat der Nutzer erstmal die Kontrolle nur ein VPN gleichzeitig zu oeffnen (ich spare den Fall aus, dass zwei VPN Nutzer im selben Heimnetz sitzen, aber selbst dann kann man sich da bei der VPN Nutzung serialisieren). Im zweiten Fall ist es Aufgabe des ISPs vollumfaengliches Internet bereit zustellen.

Zitat von frank_m

Unsere Firma ist deshalb von IPSec auf OpenVPN gewechselt, weil es mit wachsender Anzahl Kollegen aus Kabel-Netzen und Mobilfunkverbindungen am Ende nicht mehr darstellbar war.

Das ist grossartig von Deiner Firma und ein pragmatischer Weg vorwaerts, waere dem OP zu wuenschen. Aber das entbindet IMHO den ISP nicht das Problem zu loesen*... oft vergeben ISPs in solchen Faellen halt dynamische oeffentliche IPv4 auf Nachfrage/Quaengeln.

*) Das Produkt ist Internetzugang.

Mmmh, hat die Telekom mal kurz in Angriff genommen und es dann fallen lassen*. IMHO ist das Hauptproblem aus Endkkundensicht bei PPPoE weniger die 8 Byte pro Packet weniger**, und mehr die relativ hohen Kosten fuer das Ver- und Entkapseln.

*) Warum ist unklar, mein Verdacht ist erwartete Probleme mit Bestands-DSL-Routern im Feld... aber man haette das Ganze ja exklusiv fuer FTTH Anschluesse einfuehren koennen, da gibt es so viele Bestands-ONTs gar nicht...

**) Wobei es Dir vermutlich weniger um die geringfuegig hoehere Effizienz einer Internet-MTU 1500 geht und mehr darum die leidige MTU/MSS Geschichte umgehen zu koennen.

Zitat von frank_m

Das interessiert nur leider die Gesetzgebung nicht.

Bin sicher das Digitalministerium wird bei eventueller Gesetzgebung ein Woertchen mitreden, und bei denen sehe ich schon eine gewisse realistische Position dessen was moeglich ist.

Zitat von frank_m

Wenn da irgendjemand 2030 reinschreibt, hat er üblicherweise vorher nicht die Realisierbarkeit geprüft - zumal man heute schon mit diesen schönen "Homes passed" und "Homes connected" Variablen spielt. Meines Erachtens steuern wir da sehenden Auges in ein arges Problem hinein, und gekniffen sind vor allem die, die Glasfaser vor der Tür liegen haben und sich aus was für Gründen auch immer gegen einen Anschluss in der Ausbauphase entschieden haben.

Jein, es wird aber wohl noch Nachverdichtungswellen in eigentlich schon ausgebauten Gebieten geben... Das Problem, um es klar zu sagen ist weniger ein politisches sondern ein technisches. Die Produktion der ISP-seitigen Komponenten fuer VDSL2@FTTC wird/wurde gerade eingestellt, ab jetzt geht der DSL-Betrieb auf Verschleiss, ich erwarte, dass trotz neuer Ersatzteile im Lager der DSL Betreiber und auch mit Jonglage von Komponenen aus bereits abgeschalteten DSL-Bereichen, ein DSL Weiterbetrieb zunehmend unrentabel wird. IMHO wird das Netz noch 10-15 Jahre wirtschaftlich betreibbar bleiben... Das zeigt aber auch den Zeithorizont an fuer die DSL Abschaltungen, da ist noch Zeit die Details zu bestimmen.

Zitat von frank_m

Nein, es geht um die Kohlekraftwerke,

Dann entschuldige ich mich fuer meinen denn unpassenden Text. Zu den Kohlekraftwerken habe ich noch nicht recherchiert und kann daher nichts sinnvolles dazu beisteuern.

Zitat von gponner

Anscheinend sind ja dann wohl alle Netzwerkbetreiber mit dem Klammerbeutel gepudert

Nein, sind sie nicht, sondern sie optimieren nach BWL-Kriterien, und da reichen bereits geringe Kostenunterschiede um ON attraktiver zu machen, aber besonders halt der Umstand, dass ein PON Betreiber realistisch schlimmstenfalls zu OpenAccess via Bitstrom gezwungen werden kann statt zum weniger rentablen physischen Entbuendeln einzelner Fasern. Damit behaelt der Betreiber die Kontrolle ueber die Technik und vermeidet, z.B. dass ein Mitbewerber im selben Gebiet z.B. XGSPON basierte Tarife anbietet statt GPON.

Aus Sicht der Allgemeinheit hingegen, ist IMHO der staerkere Wettbewerb der durch ein PtP Netz ermoeglicht wird die milden Extrakosten des Ausbaus wert... (noch mal mir geht es primaer um die Netzstrukltur, weniger um die verwendete Technologie, allerdings kann man auf PtP Netzen problemlos PONs verwenden, aber auf PtMP Netzen kein AON*).

Zitat von gponner

Oder wieso entscheidet sich die Mehrheit der Netzbetreiber weltweit für PON (ob G oder X sei mal dahin gestellt) im Privatkundenumfeld?

Weil ISPs in der Regel gar nicht daran interessiert sind echten Wettbewerb zu ermoeglichen, wenn sie die Chance haben statt dessen der Hecht im Karpfenteich zu bleiben. Das ist in unserem Wirtschaftssystem so erwartet, der Fehler ist IMHO so zu tun, als koenne man es den Marktteilnehmern ueberlassen Infrastruktur fuer die naechsen Jahrzehnte nach ihren eigenen Kriterien zu bauen und trotzdem hoffen das fuehre zu einen guten Marktloesung.

*) Ja, technisch kann man sich eine DWDM Variante ertraeumen aber das ist im Zugangsnetz mit hoher Sicherheit niemals rentabel. Das ist IMHO ein Feigenblatt derer die PtMP durchsetzen wollen.

MTU 1480 ist IMHO etwas ungewoehnlich, bei PPPoE ist 1492 ueblicher...

Schalte doch diese Einstellungen nochmal aus (nur fuer den Test) und folge dieser Anleitung zur manuellen Ueberpruefung der MTU:

Basic Stuff: MTU-Grösse mit ping testen – Tech Blog

(Leider finde ich bei SachsenWLAN noch keine Informationen zur Schnittstellenbeschreibung, aber ein manueller Test ist so oder so informativ und interessant.)

Zitat von dkoopmans77

Vielleicht ist es auch nicht 1000 ports fix, sondern maximale Anzahl

Das ist mit hoher Wahrscheinlichkeit so, dass die 1000 das Maximum sind.

Zitat von frank_m

Doch, definitiv. Es ist unzureichend eingerichtet für NAT Szenarien. Kein IPv6 anzubieten und gleichzeitig Clients hinter NAT zu vernachlässigen, ist schon extrem ignorant in heutigen Zeiten.

Unklar. Warum sollte ein Betreiber eines VPNs extra Klimmzuege machen um die Fehler inkompetenter ISPs auszugleichen? Im Ernst, es ist klar, dass spaetgekommene ISPs mit IPv4 Adressen Tricks anwenden muessen, und das ist auch OK, aber diese Tricks sollten dann auch so umgesetzt werden, dass Kunden davon nichts/kaum etwas verspueren. Und das schint hier nicht der Fall zu sein.

Und was hast Du eingetragen?