War bei mir genau das selbe. Leicht gedrückt und plopp, die Buchse war drin. Aber einfach auf gemacht, die Buchse richtig eingesetzt und dann war auch alles super. Kein Hexenwerk.
Probleme bei SFP Modulen für FTTH mit UDMP / UDMSE / UXG
-
- Privat
- UDM
- Dream Machine Pro (UDM-Pro)
- offen
- aNt
Es gibt 636 Antworten in diesem Thema, welches 83.908 mal aufgerufen wurde. Der letzte Beitrag () ist von Uwe.
-
-
Anbei
Wie bekomme ich das dicke Grüne rausgelöst und weiter nach unten gesetzt?
-
Oh Duplex Dose, ungewöhnlich finde ich und vielleicht der Grund warum der Anschluss „intern“ gelassen wurde.
Zwei Anschlüsse ist sogar recht normal, aber dann einzeln und der zweite bleibt als Reserve in der Dose
(und ist oft auch nicht im Straßenverteiler aufgelegt).
Wenn du alleine bist also die Dose nur für dich ist war wohl grade nicht anders Greifbar.
Na ja einfach die Klammern Vorsicht etwas biegen und dann raus damit, das ist alles nur eingeschnappt.
Etwas Leitung von PigTail (also da Grüne mit der Glasfaser aus der Kassette entfriemeln...
VORSICHT oben links das sieht schon nicht sooo gut aus.
Knicke unbedingt vermeiden, das ist Quasi das reine Glas und nur Dünner Schutzmantel drumherum (mehr ne dicke
Beschichtung also ein wirklicher Schutz)
Oder halt Stecker raus denen neuen Drauf und wider zu machen...
-
Tendiere eher zum zweiten. Neuen Stecker drauf.
-
Moin,
benötige nun doch eure Hilfe bitte.
Bin Kunde der Telekom, habe UDM Pro und war zufriedener Nutzer des Zyxel SFP Moduls. Aufgrund der zuletzt aufgetretenen Probleme habe ich das Luleey Modul bestellt und heute versucht zum Laufen zu kriegen.
Anbei die Einstellungen aus meinem Zyxel mit dem ich die Verbindung aufbauen kann:
Laut Weboberfläche wird die Verbindung ganz kurz aufgebaut inkl. IP Zuweisung aber dann bricht es wieder ab.
Hier ein Bild der Luleey Config von der ich erwarten würde, dass sie funktioniert:
Ergänzende Infos:
So sieht es in /var/log/messages aus wenn die Verbindung abbricht:
2023-09-08T22:09:13+02:00 UDM pppd[1386]: Timeout waiting for PADO packets
2023-09-08T22:09:13+02:00 UDM inadyn[1650]: Failed resolving hostname api.ipify.org: Temporary failure in name resolution
2023-09-08T22:09:13+02:00 UDM inadyn[1650]: Communication with checkip server api.ipify.org failed, run again with 'inadyn -l debug' if problem persists
2023-09-08T22:09:18+02:00 UDM pppd[1386]: PPP session is 71
2023-09-08T22:09:18+02:00 UDM pppd[1386]: Connected to cc:e1:7f:ad:b4:ad via interface eth9.7
2023-09-08T22:09:18+02:00 UDM pppd[1386]: Using interface ppp0
2023-09-08T22:09:18+02:00 UDM pppd[1386]: Connect: ppp0 <--> eth9.7
2023-09-08T22:09:21+02:00 UDM pppd[1386]: Remote message: SRU=55000#SRD=110000#
2023-09-08T22:09:21+02:00 UDM pppd[1386]: PAP authentication succeeded
2023-09-08T22:09:21+02:00 UDM pppd[1386]: peer from calling number CC:E1:7F:AD:B4:AD authorized
2023-09-08T22:09:21+02:00 UDM pppd[1386]: local IP address 91.21.x.x
2023-09-08T22:09:21+02:00 UDM pppd[1386]: remote IP address 62.155.241.43
2023-09-08T22:09:21+02:00 UDM pppd[1386]: primary DNS address 217.237.150.205
2023-09-08T22:09:21+02:00 UDM pppd[1386]: secondary DNS address 217.237.149.142
2023-09-08T22:09:21+02:00 UDM ubios-udapi-server[1223]: wan-failover-interfaces: wf-interface-ppp0 (91.21.x.x) is unknown [_---ddd](no dns)(~down~)
2023-09-08T22:09:22+02:00 UDM ubios-udapi-server[1223]: wan-failover-monitor-icmp: wf-monitor-ppp0-2-icmp (91.21.x.x->8.8.8.8) has dpinger update: 8.8.8.8 is up {"alarm":false,"id":"ppp0-mon2-8.8.8.8","latencyAverage":233.0,"latencyStdDev":1017.0,"lossPercentage":0.0}
2023-09-08T22:09:22+02:00 UDM ubios-udapi-server[1223]: wan-failover-interfaces: wf-interface-ppp0 (91.21.x.x) is up [_U--___](no dns)
2023-09-08T22:09:23+02:00 UDM ubios-udapi-server[1223]: wan-failover-group-base: wf-group-1-single is up [u](ppp0)
2023-09-08T22:09:23+02:00 UDM ubios-udapi-server[1223]: wan-failover-groups: wf-groups-container is using wf-group-1-single + ppp0 (table 201) { wf-group-1-single is up [u](ppp0) wf-group-2-single is down [d](eth10) }
2023-09-08T22:09:23+02:00 UDM ubios-udapi-server[1223]: res-interfaces: Removing unknown PPPoE route {
2023-09-08T22:09:23+02:00 UDM ubios-udapi-server[1223]: res-interfaces: "destination": "::/0",
2023-09-08T22:09:23+02:00 UDM ubios-udapi-server[1223]: res-interfaces: "distance": 1024,
2023-09-08T22:09:23+02:00 UDM ubios-udapi-server[1223]: res-interfaces: "enabled": true,
2023-09-08T22:09:23+02:00 UDM ubios-udapi-server[1223]: res-interfaces: "fib": true,
2023-09-08T22:09:23+02:00 UDM ubios-udapi-server[1223]: res-interfaces: "interface": "ppp0",
2023-09-08T22:09:23+02:00 UDM ubios-udapi-server[1223]: res-interfaces: "selected": true,
2023-09-08T22:09:23+02:00 UDM ubios-udapi-server[1223]: res-interfaces: "staticType": "interface",
2023-09-08T22:09:23+02:00 UDM ubios-udapi-server[1223]: res-interfaces: "table": 201,
2023-09-08T22:09:23+02:00 UDM ubios-udapi-server[1223]: res-interfaces: "type": "KernelRoute"
2023-09-08T22:09:23+02:00 UDM ubios-udapi-server[1223]: res-interfaces: } (interface ppp0)
2023-09-08T22:09:31+02:00 UDM ubios-udapi-server[1223]: wan-failover-monitor-dns: wf-monitor-ppp0-3-dns (91.21.x.x->1.1.1.1) has dns-monitor update: 1.1.1.1:ui.com is up
2023-09-08T22:09:31+02:00 UDM ubios-udapi-server[1223]: wan-failover-monitor-dns: wf-monitor-ppp0-4-dns (91.21.x.x->8.8.8.8) has dns-monitor update: 8.8.8.8:ui.com is up
2023-09-08T22:09:44+02:00 UDM kernel: al_mod_eth_group_lm_link_manage: eth0 - link wasn't established, link went down
2023-09-08T22:10:15+02:00 UDM ubios-udapi-server[1223]: wan-failover-monitor-icmp: wf-monitor-ppp0-2-icmp (91.21.x.x->8.8.8.8) has dpinger update: 8.8.8.8 is down {"alarm":true,"id":"ppp0-mon2-8.8.8.8","latencyAverage":4240.0,"latencyStdDev":1500.0,"lossPercentage":52.63159942626953}
2023-09-08T22:10:16+02:00 UDM ubios-udapi-server[1223]: wan-failover-monitor-dns: wf-monitor-ppp0-3-dns (91.21.x.x->1.1.1.1) has dns-monitor update: 1.1.1.1:ui.com is down
2023-09-08T22:10:16+02:00 UDM ubios-udapi-server[1223]: wan-failover-interfaces: wf-interface-ppp0 (91.21.x.x) is down [_DDU___](no dns)
2023-09-08T22:10:16+02:00 UDM ubios-udapi-server[1223]: wan-failover-monitor-dns: wf-monitor-ppp0-4-dns (91.21.x.x->8.8.8.8) has dns-monitor update: 8.8.8.8:ui.com is down
2023-09-08T22:10:17+02:00 UDM ubios-udapi-server[1223]: wan-failover-group-base: wf-group-1-single is down [d](ppp0)
2023-09-08T22:10:21+02:00 UDM pppd[1386]: No response to 3 echo-requests
2023-09-08T22:10:21+02:00 UDM pppd[1386]: Serial link appears to be disconnected.
2023-09-08T22:10:21+02:00 UDM pppd[1386]: Connect time 1.0 minutes.
2023-09-08T22:10:21+02:00 UDM pppd[1386]: Sent 236262 bytes, received 188340 bytes.
2023-09-08T22:10:21+02:00 UDM ubios-udapi-server[1223]: res-interfaces: Cannot delete PPPoE route: Failed to delete route ::/0 dev ppp0: Object not found
2023-09-08T22:10:21+02:00 UDM ubios-udapi-server[1223]: res-interfaces: Cannot delete PPPoE route: Failed to delete route 0.0.0.0/0 dev ppp0: Object not found
2023-09-08T22:10:21+02:00 UDM ubios-udapi-server[1223]: process: Got process exit event for process dnsmasq-ppp0
2023-09-08T22:10:27+02:00 UDM pppd[1386]: Connection terminated.
2023-09-08T22:10:27+02:00 UDM pppd[1386]: Modem hangup
2023-09-08T22:10:50+02:00 UDM kernel: al_mod_eth_group_lm_link_manage: eth0 - link established successfully
2023-09-08T22:11:07+02:00 UDM pppd[1386]: Timeout waiting for PADO packets
2023-09-08T22:11:13+02:00 UDM inadyn[1650]: Failed resolving hostname api.ipify.org: Temporary failure in name resolution
2023-09-08T22:11:13+02:00 UDM inadyn[1650]: Communication with checkip server api.ipify.org failed, run again with 'inadyn -l debug' if problem persists
[/tt]
Was ich außerdem auffällig finde:
Wenn ich den SFP Port in dem der Luleey steckt auf LAN umstelle um dann per http das Modul zu konfigurieren, ist die Verbindung zum Modul möglich aber instabil. Im CLI sieht man:
2023-09-09T01:11:03+02:00 UDM kernel: al_mod_eth_group_lm_link_manage: eth2 - link established successfully
2023-09-09T01:11:03+02:00 UDM kernel: br2: port 2(eth10) entered blocking state
2023-09-09T01:11:03+02:00 UDM kernel: br2: port 2(eth10) entered forwarding state
2023-09-09T01:11:03+02:00 UDM kernel: br0: port 2(eth10.1) entered blocking state
2023-09-09T01:11:03+02:00 UDM kernel: br0: port 2(eth10.1) entered forwarding state
2023-09-09T01:11:03+02:00 UDM kernel: br3: port 2(eth10.3) entered blocking state
2023-09-09T01:11:03+02:00 UDM kernel: br3: port 2(eth10.3) entered forwarding state
2023-09-09T01:11:03+02:00 UDM kernel: br10: port 2(eth10.10) entered blocking state
2023-09-09T01:11:03+02:00 UDM kernel: br10: port 2(eth10.10) entered forwarding state
2023-09-09T01:11:03+02:00 UDM kernel: br11: port 2(eth10.11) entered blocking state
2023-09-09T01:11:03+02:00 UDM kernel: br11: port 2(eth10.11) entered forwarding state
2023-09-09T01:11:03+02:00 UDM kernel: br12: port 2(eth10.12) entered blocking state
2023-09-09T01:11:03+02:00 UDM kernel: br12: port 2(eth10.12) entered forwarding state
2023-09-09T01:11:03+02:00 UDM kernel: br30: port 2(eth10.30) entered blocking state
2023-09-09T01:11:03+02:00 UDM kernel: br30: port 2(eth10.30) entered forwarding state
2023-09-09T01:11:03+02:00 UDM kernel: br40: port 2(eth10.40) entered blocking state
2023-09-09T01:11:03+02:00 UDM kernel: br40: port 2(eth10.40) entered forwarding state
2023-09-09T01:11:03+02:00 UDM kernel: br50: port 2(eth10.50) entered blocking state
2023-09-09T01:11:03+02:00 UDM kernel: br50: port 2(eth10.50) entered forwarding state
2023-09-09T01:11:03+02:00 UDM kernel: br70: port 2(eth10.70) entered blocking state
2023-09-09T01:11:03+02:00 UDM kernel: br70: port 2(eth10.70) entered forwarding state
2023-09-09T01:11:03+02:00 UDM kernel: br80: port 2(eth10.80) entered blocking state
2023-09-09T01:11:03+02:00 UDM kernel: br80: port 2(eth10.80) entered forwarding state
2023-09-09T01:11:03+02:00 UDM kernel: br130: port 2(eth10.130) entered blocking state
2023-09-09T01:11:03+02:00 UDM kernel: br130: port 2(eth10.130) entered forwarding state
2023-09-09T01:11:51+02:00 UDM kernel: al_mod_eth_group_lm_link_manage: eth2 - link wasn't established, link went down
2023-09-09T01:11:51+02:00 UDM kernel: br2: port 2(eth10) entered disabled state
2023-09-09T01:11:51+02:00 UDM kernel: br0: port 2(eth10.1) entered disabled state
2023-09-09T01:11:51+02:00 UDM kernel: br3: port 2(eth10.3) entered disabled state
2023-09-09T01:11:51+02:00 UDM kernel: br10: port 2(eth10.10) entered disabled state
Kann mir jemand sagen, was falsch läuft oder mir helfen der Ursache auf den Grund zu gehen?
Vielen Dank!
-
Tendiere eher zum zweiten. Neuen Stecker drauf.
Ist wohl das einfachste wenn du dir nicht sicher bist
-
Moin,
benötige nun doch eure Hilfe bitte.
Bin Kunde der Telekom, habe UDM Pro und war zufriedener Nutzer des Zyxel SFP Moduls. Aufgrund der zuletzt aufgetretenen Probleme habe ich das Luleey Modul bestellt und heute versucht zum Laufen zu kriegen.
Anbei die Einstellungen aus meinem Zyxel mit dem ich die Verbindung aufbauen kann:
Laut Weboberfläche wird die Verbindung ganz kurz aufgebaut inkl. IP Zuweisung aber dann bricht es wieder ab.
Hier ein Bild der Luleey Config von der ich erwarten würde, dass sie funktioniert:
Ergänzende Infos:
So sieht es in /var/log/messages aus wenn die Verbindung abbricht:
Was ich außerdem auffällig finde:
Wenn ich den SFP Port in dem der Luleey steckt auf LAN umstelle um dann per http das Modul zu konfigurieren, ist die Verbindung zum Modul möglich aber instabil. Im CLI sieht man:
Kann mir jemand sagen, was falsch läuft oder mir helfen der Ursache auf den Grund zu gehen?
Vielen Dank!
Was für eine Version hast du bei UnifiOS und bei Network. Meine Logs sehen anders aus.
Und schau auch mal in das /var/log/ppp0.log (leider ist dieses Log ohne Zeiten.
-
Was für eine Version hast du bei UnifiOS und bei Network. Meine Logs sehen anders aus.
Und schau auch mal in das /var/log/ppp0.log (leider ist dieses Log ohne Zeiten.
Danke für die Antwort. Ich habe heute Nacht ein Update bekommen und fahre jetzt mit UDM Pro v3.1.16 und Netzwerk 7.4.162.
Ich bin gerade wieder dabei das Problem zu untersuchen. Ich denke es gibt ein Problem mit dem LuLeey SFP Modul und meiner UDM. ppp0.log wäre dann wohl nachrangig zu betrachten?
Das Modul läuft nicht stabil egal ob es als WAN Modem konfiguriert ist oder "nur so" als LAN genutzt wird. Woran das liegt, ist mir nicht klar. Ich habe aber heute Zyxel ausgebaut und WAN quasi deaktiviert. Das LuLeey habe ich dann in Port10 gesteckt und als LAN konfiguriert. Die UDM sollte dann offline sein und mir an Port10 zuverlässig das LuLeey anzeigen. In der webbasierten Konsole sehe ich, wie der Port ständig zwischen grün und schwarz wechselt.
Im CLI sehe ich:
2023-09-09T10:06:40+02:00 UDM pppd[18078]: Timeout waiting for PADO packets
2023-09-09T10:07:05+02:00 UDM kernel: al_mod_eth_group_lm_link_manage: eth2 - link established successfully
2023-09-09T10:07:05+02:00 UDM kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth10: link becomes ready
2023-09-09T10:07:05+02:00 UDM kernel: br2: port 1(eth10) entered blocking state
2023-09-09T10:07:05+02:00 UDM kernel: br2: port 1(eth10) entered forwarding state
2023-09-09T10:07:18+02:00 UDM dpi-flow-stats[1779]: ubnt-dpi-util: dpi ml request failed
2023-09-09T10:07:20+02:00 UDM pppd[18078]: Timeout waiting for PADO packets
2023-09-09T10:07:53+02:00 UDM kernel: al_mod_eth_group_lm_link_manage: eth2 - link wasn't established, link went down
2023-09-09T10:07:53+02:00 UDM kernel: br2: port 1(eth10) entered disabled state
2023-09-09T10:08:00+02:00 UDM pppd[18078]: Timeout waiting for PADO packets
Zeitglich lasse ich ping -t auf die IP des Luleey laufen und sehe wie er sporadisch für eine Weile antwortet aber die meiste Zeit nicht. Das "nicht antworten" deckt sich dann zeitlich mit den Meldungen im CLI und dem "schwarz werden" des Ports im Interface. Ist mein Modul kaputt oder habe ich vielleicht eine verbastelte Konfig bzgl. SFP?
-
Ich glaube, du hast das Pech, ein Montagsgerät erwischt zu haben.
Du bist der Erste, der dieses Problem mit diesen Modultypen hat. Ich denke da eher an ein Defekt. Ich bin auch in glasfaserforum.de unterwegs, auch da gab es zu dem Modul noch keine Negativmeldung. -
Damit kann ich zur Not leben. Wenn die Chinesen das anders sehen, ist der Schaden ca. 50 EUR..
Jedoch wäre es natürlich ärgerlich, wenn es mit dem zweiten dann zu den selben Problemen kommen würde. Gibt es noch eine Möglichkeit das weiter zu Untersuchen? Ich habe hier auch einen USW24 mit SFP Ports. Da hatte ich den auch kurz dran und das Verhalten war vergleichbar.
Sep 9 10:36:26 USW-24-PoE kern.notice kernel: [494544.660000] Port 25 link up
Sep 9 10:36:26 USW-24-PoE kern.warn kernel: [494544.720000] Port 25 moving from Disabled to Blocking
Sep 9 10:36:29 USW-24-PoE kern.warn kernel: [494547.220000] Port 25 moving from Blocking to Forwarding
Sep 9 10:37:14 USW-24-PoE kern.notice kernel: [494592.510000] Port 25 link down
Sep 9 10:37:14 USW-24-PoE kern.warn kernel: [494592.720000] Port 25 moving from Forwarding to Disabled
Sep 9 10:38:20 USW-24-PoE kern.notice kernel: [494658.390000] Port 25 link up
Sep 9 10:38:20 USW-24-PoE kern.warn kernel: [494658.470000] Port 25 moving from Disabled to Blocking
Sep 9 10:38:23 USW-24-PoE kern.warn kernel: [494661.220000] Port 25 moving from Blocking to Forwarding
Sep 9 10:39:08 USW-24-PoE kern.notice kernel: [494706.240000] Port 25 link down
Sep 9 10:39:08 USW-24-PoE kern.warn kernel: [494706.470000] Port 25 moving from Forwarding to Disabled
Sep 9 10:40:14 USW-24-PoE kern.notice kernel: [494772.070000] Port 25 link up
Sep 9 10:40:14 USW-24-PoE kern.warn kernel: [494772.230000] Port 25 moving from Disabled to Blocking
Sep 9 10:40:17 USW-24-PoE kern.warn kernel: [494775.230000] Port 25 moving from Blocking to Forwarding
Kann jemand was zu FW Updates für das Modul sagen? Evtl. würde das ja was bringen. Ich komme auf mein Modul nur schwer rauf, weil es ständig wegfliegt. Das erschwert das "Suchen".
-
Also wenn das Verhalten an einem "einfachen" Switch identisch ist, würde ich deutlich auf ein Hardwareproblem schließen.
Wenn man neben der UDM Pro/SE noch ein Switch mit SFP hat würde ich immer den nehmen. Verbindung zur UDM kappen und dann hat man am wenigsten gehuddel mit IP-Adressen und Ranges. -
Update:
Ich habe LuLeey meine Beobachtungen geschildert und um Ersatz gebeten. Es kam prompt eine Antwort die ich zur Information hier veröffentliche:
ZitatDear xxx
Do you have 2.5g/1G media converter test. it is the simplest method to the the xpon stick.
and you have to config the verify method. like MAC LOID SN VLAN ...
and please make sure the same ip with xpon stick. default is 192.168.1.1/24
access xpon stick through web 192.168.1.1 to config.
https://www.luleey.com/2-5g-gpon-onu-solution/
all product will be tested before send it to customers.The probability of problems is relatively low. could you continue to verify it.
In der Zwischenzeit war mir aber noch eine Idee gekommen. Habe das SFP Modul in den paar Sekunden die ich bis zum Abbruch der Verbindung hatte über das Web GUI auf Werkseinstellungen zurückgesetzt. Das schien zu klappen. Die von mir zuvor vorgenommenen Anpassungen waren danach aber immer noch drin. Also habe ich es mehrfach zurückgesetzt. Jedes mal angeblich erfolgreich aber die von mir gemachten Änderungen blieben drin.
Erstaunlicherweise war dann aber zu beobachten, dass die Verbindung zwischen USW und SFP Modul nun stabil blieb. Habe dann pppoe Einwahl mit dem LuLeey Modul probiert und siehe da es klappt auf Anhieb und ist bisher stabil. Und auch kein packet loss.
tl,dr: Zurücksetzen des Moduls auf Werkseinstellungen hat bei mir geholfen, um Kompatibilität zwischen SFP Modul und Ubiquiti Hardware herzustellen. Die Konfiguration des Modems erfolgte dann wie hier mehrfach beschrieben und ging dann problemlos.
Vielen Dank für die Unterstützung!
-
Hi, ich habe eine Eaton 5PX USV hier und ein Silence Rack.
Anscheinend sind die beiden Teleskopstangen zu kurz um an die zweite Schiene hinten zu kommen. Fehlen ca. 2cm. Längere Schrauben oder jemand andere Idee ?
So Switch auf Lulej im Schrank hat beim ersten Mal direkt funktioniert.
-
Du kannst eine Langmutter dazwischen setzen, die gibt es in jeder Länge.
-
Du kannst eine Langmutter dazwischen setzen, die gibt es in jeder Länge.
Entschuldige wenn ich dumm frage aber welche Schrauben passen in diese Langmutter?
Ist mein erstes Netzwerkschrand Projekt.
Bin ja schon froh den Switch auf Luley geschafft zu haben und nun alles über die UDM Pro Se läuft.
-
Also Käfigschrauben(so die Bezeichnung für die Serverschrankbefestigung) sind fast immer M6.
Also musst du eine Langmutter mit M6 Gewinde nehmen. Die Länge bestimmt dein fehlender Abstand, die Schienen sind ja flexibel, also lieber 5 mm länger nehmen als benötigt.
-
Braucht noch jemand Kabel LC-APC auf SC-UPC, ich bestelle mitte der Woche bei FS: https://www.fs.com/de/products/151414.html
-
Also Käfigschrauben(so die Bezeichnung für die Serverschrankbefestigung) sind fast immer M6.
Also musst du eine Langmutter mit M6 Gewinde nehmen. Die Länge bestimmt dein fehlender Abstand, die Schienen sind ja flexibel, also lieber 5 mm länger nehmen als benötigt.
Ich habe welche von Digitus hier liegen. War ein 50 er Pack.
-
Die vertikalen schienen insgesamt um die nötigen 2 cm verschieben ist keine Option ?
-
Die vertikalen schienen insgesamt um die nötigen 2 cm verschieben ist keine Option ?
Könnte klappen.
Passt dann aber ggf. nicht für andere Komponenten?