JetStream 8-Port 10GE SFP+ L2+ Managed Switch
JetStream 8-Port 10GE SFP+ L2+ Managed Switch. Als ein SFP+-Switch, welches sich nahtlos in der Omada Software Defined Networking (SDN) integriert, bietet der…
www.tp-link.com
In deinem Screenshot ist mir noch aufgefallen, dass dort ja auch die LAN-Ports für die einzelnen Services eingestellt werden. Ich vermisse da den LAN-Port für Internet! Ist der (an anderer Stelle?) richtig eingerichtet bzw. hast du das Modem mit dem richtigen Port verbunden?
Was hast du überhaupt für einen Anschluß? AON oder GPON? Bei EWE ist mir in beiden Fällen nicht bekannt, dass man irgendwelche Geräte für 1 Stunde vom Netz nehmen soll.
Was man (bei jedem Provider und jeder Anschlusstechnik) nie machen sollte, ist hochfrequente Ein- bzw. Ausschalten/Stecken. Das kann durchaus durch die Providerseitigen Geräte als schwerer Leitungsfehler angesehen werden. Da werden dann die Anschlüsse gesperrt.
Was für ein Beschluss!! Es sitzt wirklich jeder auf seinen eigenen Eiern, will dafür Höchstpreise und möchte die Eier der anderen für lau ...
Die Eingabefelder sehen so aus, als ob da noch nix eingegeben wurde.
Versuche mal 7 bei Internet VID und 0 bei Internet Prio.
Dass EWE dediziert IP-TV überträgt ist mir aktuell nicht bekannt, also leer lassen.
Hat er das damals nicht auf der 255.255.255.255 versucht?! Geile Diskussion ...
"Anzahl ONUs im optischen Netz"
Im Supportprotokoll steht die genaue Anzahl im Stundentakt -> "FIBER 7 Day per Hour Stats"
Nun ja, wenn er den Anschluss "Optisches Ethernet" hat, dann könnte er die schon verwenden.
Man hängt allerdings am Fliegenfänger, wenn noch nichtmal der Support Bescheid weiß!
O5 zeigt nur, dass der eigentliche GPON Transport-Layer aufgebaut ist.
Die logische GPON-Konfiguration (Zuordnung GEM-Ports zu Traffic-klassen, QOS-Konfig, Austausch der AES-Keys etc.) läuft auf dem OMCI-Layer. Über das OMCI-Protokoll konfiguriert der OLT den ONU.
Dazu wird ein eigener GEM-Port aufgemacht, der nur OMCI-Messages überträgt. Das passiert bei dir augenscheinlich nicht, denn die Anzahl Gem-Ports steht auf 0. Bei meinem Glasfaser-Nordwest Anschluss werden immer 3 GEM-Ports aufgemacht -> OMCI,Multicast und Unicast
Erst wenn das passiert ist können überhaupt Ethernetpakete übertragen werden, zu allererst DHCP, damit du überhaupt eine IP bekommst.
Du hast ja geschrieben, dass bei DGF eine alte Modem-ID vorhanden ist. Ich vermute mal, dass sich der Standard-Aktivierungsprozess nur durchlaufen lässt, wenn die Modem-ID für einen Anschluss in den DGF-Systemen auf NUL steht und bei vorhandener Modem-ID manuell eingegriffen werden muß- Das setzt natürlich Supportmitarbeiter voraus, die wissen was sie tun ...
Modub Dan schau mal in die Sektion
FIBER Overview
------------
Ein paar Zeilen drunter steht, zumindest bei mir, der OLT Vendor.
Ups! 129 Euro ![]()
Sowas kostet normalerweise 20 Euro für 20m!
Da ist dann aber nur ein Anschluss hinüber!
Auf dem PON können bis zu 32/64 nicht mehr arbeiten. Und die Fehlersuche ist extrem schwierig, da das nur am Splitter, also in der Regel im Nvt erfolgen kann. Das gilt zumindest, wenn der PON nicht voll belegt ist. Ist er nur teilweise belegt, muss man rausfahren.
Nun ja, es gibt Anleitungen für diverse GPON-SFPs, um die Seriennummer zu manipulieren. Mit dem Wissen lassen sich bestimmt auch andere Parameter ändern. Da fehlen mir allerdings Werkzeuge und Erfahrungen, um das beurteilen zu können.
Was möglich ist, wird auch irgendwann mal gemacht ...
EDIT: Such mal im Netz nach "Hacking RTL960x"
Hmm, sicher? Such mal nur nach avm_supportdata .
In der 5590 ist der Abschnitt sowohl in den normalen, als auch in den erweiterten Supportdaten drin.
Nun denn, ich tippe mal auf Zusammenarbeitsproblem zwischen AVM und DGF, denn der Status O5 kann nur erreicht werden, zumindest wenn alle Beteiligten sich an den Standard halten, wenn der Seriennummernrequest erfolgreich quittiert UND das Ranging erfolgreich durchlaufen wurde. Das Ranging führt aber der OLT durch und teilt dann das EQD dem ONU mit. Du hast O5 in Kombination mit EQD = 0. Entweder übernimmt die Box das EQD nicht -> Fehler AVM oder der OLT schickt Mist.
Versuch es doch mal über den AVM-Support. Der könnte sich dann mal die erweiterte Glasfaserdiagnose ansehen. Die ist leider binär und nicht menschlich zu entziffern.
Besser nicht, sind zuviele private Daten drin.
Einfach im Editor nach dem String suchen.
BTW Im Oktober letzten Jahres gab es von Telekom die offizielle Aussage, dass die 5690 mit bestimmten OLT der Telekom nicht funktioniert. Es wurde allerdings nicht gesagt um welche es sich handelt. Evtl. ist das Problem von AVM bis heute nicht gefixt und DG hat dieselbe OLT Hardware im Einsatz.
Die Box durchläuft 2,3,4,5,6 in regelmäßigen Abständen. Nach der Statusmaschine zu urteilen, wird vom OLT nach erreichen von O5 nichts mehr gesendet - LOS/LOF ->O6
Ws steht denn in diesem Abschnitt der Supportdaten:
omci avm_supportdata
-------------------------------
Counters
==========
optic alarms canceled: 0
optic alarms activated: 1
optic alarms ignored: 716
tx power ignored: 112
received ploam O7 set: 0
received ploam O7 clear: 0
reported ploam O7 events: 0
delayed ploam O7 events: 0
invalid mcc packets: 0
create unsupported me: 8
handle unsupported me: 0
Kein Fehler! Meine Geschriebenes zu dem Thema ist ja nur eine sehr grobe und vereinfachte Zusammenfassung der Funktionsweise. Da gibt es natürlich eine große Bandbreite von möglichen "Fahrweisen" und Sonderfällen im Protokoll. Das Protokoll ist ja in den ITU Papers sehr gut und vollständig beschrieben - Details und Ausnahmen also dort nachlesen!
Kein ONU muss in jedem Frame Downstream-Daten bekommen, kein ONU muss in jedem Frame Upstream-Daten senden. Es kann passieren, dass ein ONU in einer Downstream-BWMap keinen Slot zugeteilt bekommt - dann muss er seinen Laser abschalten!
Es existieren ja noch viel mehr Randbedingungen! Z.B. muß der OLT ja dafür sorgen, dass sich neue ONUs synchronisieren können. Das kann der neue ONU NICHT alleine entscheiden. Er darf erstmal seinen Laser nicht einschalten und hört nur den Downstream ab. Der OLT muß nun in regelmäßigen Abständen eine Message für ein Quietwindow an alle ONUs senden. Dann haben alle aktiven ONUs ihren Laser für 250 μs abzuschalten. Der neu ONU bekommt das auch mit und kann seine Message loswerden. Bei meinem Anbieter passiert dass etwa alle 5 Sekunden. Es dauert nämlich max. 5 s bis zur Synchronisierung. Könnte man auch alle 100 ms machen - Aber ist das notwendig?
Die gute Ausnutzung und faire Verteilung hängt eben stark von der Parametrierung und den gewählten Bandbreitenzuteilungsverfahren ab. Wenn der ONU auch evtl. nicht 8000 mal pro Sekunde seine Daten loswerden kann so sicherlich 500 oder 1000 mal pro Sekunde! Immer noch im < 1 ms Bereich.
Diese notwendige enge Zusammenarbeit zwischen ONU und ONT ist der eigentliche Grund, warum einige Netzbetreiber "not amused" über die Routerfreiheit bei GPON sind. Wenn alle ONUs sich an die ITU-Richtlinien halten, läuft es wunderbar, ist irgendwo ein Scriptkiddy mit Open-WRT und evtl. umprogrammiertem GPON-SFP auf dem PON, kann dieser sofort lahmgelegt werden. Es reicht schon, den Sendelaser auf dem ONU einfach nicht auszuschalten ...
Um zu sehen, ob die GPON-Synchronisierung (Durchlauf der Status-Maschine von O1-O5) wiederholt im Hintergrund fehlschlägt, kannst du die Supportdaten ziehen und nach folgendem Abschnitt suchen:
PLOAM
----------
Current PLOAM State: 5
Emergency Alarm State: CLEAR
PLOAM State History:
State 2: 845471.666 s ago
State 1: 845470.850 s ago
State 2: 845470.770 s ago
State 3: 845465.152 s ago
State 4: 845464.250 s ago
State 5: 845464.045 s ago