Probleme bei SFP Modulen für FTTH mit UDMP / UDMSE / UXG

Es gibt 636 Antworten in diesem Thema, welches 77.516 mal aufgerufen wurde. Der letzte Beitrag () ist von Uwe.

    Ich bin mal wieder einen Schritt weiter. Die GUI geht zwar immer noch nicht, aber ich habe ein Vermutung warum....


    Immer wenn ich die UDM-Pro komplett vom Strom nehme (SFP Modul resetet auch) geht nach Neustart die GUI für ca. 2-3 Minuten. Dann schlägt sie um und es ist wieder nichts mehr zu sehen. (Siehe oben)


    Jetzt ist mir aufgefallen, dass ich über SSH bei "info" die WAN IP genau für den funktionierenden Zeitraum drin stehen habe und in dem Moment wo die GUI nicht mehr geht, ändert sich die IP auf 192.168.1.20. Ich weiß leider nicht, ob die UDM oder das Modul dafür verantwortlich ist. Ich wollte daher eine feste WAN IP im Modul konfigurieren (Habe eine statische IP vom ISP), nur leider finde ich den Befehl dafür nicht :frowning_face:


    Hat jemand von euch noch eine Idee oder vllt den Behlen?


    SFP Modul: https://www.fs.com/de/products/133619.html

    ID:10T error

    4 Mal editiert, zuletzt von aNt ()

    Die IP Adresse kannst du auf dem Controller unter "Internet" konfigurieren. Hast du dir mal die CPU Last/RAM Auslastung der SE angeschaut wenn sie läuft? Das geht auch über den kleinen Bildschirm. Eventuell ist da was zu sehen?

    Zitat von aNt

    ändert sich die IP auf 192.168.1.20

    Moment, die 192.168.1.20 ist die default unifi fallback IP! Dh. jedes neue Gerät, bzw Unifigeräte welche auf Werkseinstellungen gesetzt werden oder die vom DHCP keine IP erhalten/beziehen können erhalten automatisch die 192.168.1.20!

    Der Grund warum man die 192.168.1.20 nicht fix vergeben sollte und unbedingt "frei halten" sollte, sonst gibt es Konflikte wenn man ein neues/werksreset zurückgesetztes Unifi Gerät ins Netzwerk bringen will.

    Was ich nicht ganz verstehe normalerweise erhält die UDM-P immer die 192.168.1.1 und ich konnte die bisher auch noch nie ändern.

    Wo genau steht dann bei dir die 192.168.1.20?


    Die UDM (Gateway) ist bei mir auch die korrekte IP (192.168.1.1). Die WAN IP unter Einstellungen der GUI ist auch die korrekte IP. Aber wenn ich "info" im SSH eingebe, sagt er mir meine WAN IP wäre die 192.168.1.20. Und immer wenn das der Fall ist, funktioniert die GUI nicht. In den 1-3 Minuten, wo die WAN IP korrekt ist, funktioniert auch das GUI.


    DesertH2O wo kann ich die denn festlegen? Mir wird doch vom ISP die IP zugeteilt. Ich wähle mich per PPPoE ein und "zack" ist die IP da. Ich habe noch keinen Weg gefunden, um die irgendwie vorher schon festzulegen oder auch danach festzulegen. Auf dem kleinen Bildschirm der UDM ist leider nichts zu sehen, was mir weiterhelfen würde :frowning_face:


    ich verzweifel bald mit meinen Herausforderungen hier :grinning_squinting_face:


    LG

    ID:10T error

    Zitat von aNt

    (Habe eine statische IP vom ISP)

    Du hast geschrieben du hast eine statische vom ISP oder ist diese IP an die Zugangsdaten gekoppelt? Wenn ja, vergiss was ich gesagt habe, dann brauchst du die nicht einzutragen. Den Bildschirm habe ich erwähnt damit du die CPU/RAM Auslastung einsehen kannst, bis zum Zeitpunkt wenn die GUI nicht mehr geht. Vielleicht passiert ja irgendwas auf der WAN Schnittstelle das den Controller abschmieren lässt?

    Aber auf dem kleinen Info-Display direkt auf der UDM-P da wird die WAN IP im Normalfall angezeigt, welche WAN IP zeigt dieses kleine Infodisplay bei dir?

    Das müsst sein am Display rechts der letzte Menüpunkt "About" "i" und dort dann 1 x nach von rechts nach links wischen auf den 2. Punkt da sollte dann zu sehen sein:

    WAN xxxxxxxx

    LAN xxxxxxxx

    Zitat von Kurt-oe1kyw

    Ich gehe also davon aus, dass auch für die packet loss Anfragen/Test jetzt der Custom - Server benutzt wird?

    ‚Packet loss‘ kann man (im Gegensatz zur Ping-Zeit) nicht aktiv abfragen. Packet loss passiert, während man Daten überträgt. Also potentiell mit jeder Gegenstelle.

    Zitat von Kurt-oe1kyw

    ich habe jetzt den Echo Server auf "Custom" umgestellt und zwar auf jene IP welche mir mit winMTR als erste bei meinem Provider angezeigt wird, das dürfte also die Verbindung vom Modem zum Provider sein und natürlich erhalte ich da beim Pingen Werte von 2-4ms zurück.

    Dadurch sind mal die vorher vorhandenen gelben Segmente (hohe Latenz) verschwunden.

    Ist aber auch ein bisschen in die Tasche gelogen. Wenn der Backbone deines Providers dicht ist, bekommst du zwar jetzt super Ping-Zeiten angezeigt, die Verbindung zu echten Servern ist trotzdem langsam.

    Vielen Dank für die Infos Uwe, aber genau das trifft es doch auf den Punkt.

    "Früher" war der Balken immer grün, über 1,5 Jahre, aber die Verkabelung, das Modem, der Provider sind immer ident.

    Also werden wir jetzt mit der neuen FW 3.0.20 mit network 7.3.83 viel weniger angelogen :smiling_face: Und wir sehen jetzt "ehrlichere" Werte.


    Ja und klar, mir ist das bewusst dass ich jetzt "geschönte" Werte erhalte, im Grunde ist es bei mir nicht tragisch, wie schon öfter erwähnt ich bemerke es im Praxisbetrieb ja nicht.


    Aber euch allen vielen Dank für den Austausch, ich bin sicher dass auch viele andere durch das mitlesen dann wenigstens Erfahren dass ihr Netzwerk nicht "defekter" als vorher ist :smiling_face:

    Zitat von Kurt-oe1kyw

    Aber auf dem kleinen Info-Display direkt auf der UDM-P da wird die WAN IP im Normalfall angezeigt, welche WAN IP zeigt dieses kleine Infodisplay bei dir?

    Das müsst sein am Display rechts der letzte Menüpunkt "About" "i" und dort dann 1 x nach von rechts nach links wischen auf den 2. Punkt da sollte dann zu sehen sein:

    WAN xxxxxxxx

    LAN xxxxxxxx

    Da werden die IP´s korrekt angezeigt.


    WAN 2......

    Gateway 192.168.1.1


    Die werden auch in der GUI korrekt angezeigt. Nur im SSH bei "info" steht die WAN IP als 192.168.1.20. Und genau wenn das der Fall ist, funktioniert 90% der GUI nicht :smiling_face:

    ID:10T error

    2 Mal editiert, zuletzt von aNt ()

    Zitat von Uwe

    Ist aber auch ein bisschen in die Tasche gelogen. Wenn der Backbone deines Providers dicht ist, bekommst du zwar jetzt super Ping-Zeiten angezeigt, die Verbindung zu echten Servern ist trotzdem langsam.

    Ist es denn besser mit der 8.8.8.8 oder der 1.1.1.1 server in „TimBuktu“ anzusprechen und deren PING auszuwerten ?

    Google z.B sagt in ihre Dokumente das ICMP auf deren DNS keine PRIO hat und ggf gedrosselt wird.


    siehe den Beitrag hier:

    Beitrag
    RE: UDM - Pro Failover Funktioniert nicht immer
    Pfeifen in der der Luft...

    https://developers.google.com/…-dns/docs/troubleshooting
    (ggf. auf English stellen, wenn er meint das auf deutsch änder zu müssen)
    ubiquiti-networks-forum.de/attachment/18903/


    Das wird bei Cloudflare nicht anders sein. ICMP Echo hat halt
    gierig

    Da habe mal links zu den Google Dokumenten und nen Bild gepostet.

    Guten Morgen zusammen,


    seit dem 11.05.2023 habe ich an zwei Anschlüssen mit gleichem Setup (UDM Pro, Telekom SFP+ Modul GPON Modem - ist ja Zyxel) Packet Loss.
    Beides beim Provider EWE. Beide Anschlüsse sind am gleichen Verteilerkasten angeschlossen. Es gab von meiner Seite aus keine Änderung. Das Update auf v3.0.20 war am 08.05.2023 - somit würde ich das ausschließen.


    Neustart der UDM Pro hat keinen Erfolg gebracht.

    Techniker der EWE kann den Anschluss prüfen und erhält HINTER meiner UDM Pro das gleiche Ergebnis. Allerdings können die die Leitung nicht prüfen.


    Nun kommt ein Techniker von der Glasfaser Nordwest (dem Versorger) und prüft.


    Zitat von Uwe

    ‚Packet loss‘ kann man (im Gegensatz zur Ping-Zeit) nicht aktiv abfragen. Packet loss passiert, während man Daten überträgt. Also potentiell mit jeder Gegenstelle.


    Kann man.

    Einfach am PC/Mac eine Eingabeaufforderung machen. Anschließend "ping 8.8.8.8 -t" (ist ein Beispiel) machen. Dann warten. Es kann sein, dass die ersten 10-30 Pings durchgehen. Anschließend sieht man aber die Timeouts.


    Bild


    Ich bin bin gespannt wie es weiter geht.

    Viele Grüße

    Zitat von hussi

    Kann man.

    eben nicht.


    Ping Zeiten kann man in ms messen. Die werden durch viele Einflüsse schwanken, aber man kann sie messen und normal auch Schlüsse draus ziehen.

    Packet Loss kann man feststellen. Aber man kann ihn nicht direkt messen. Der "Packet Loss ist 7 Einheit XY" macht keinen Sinn.

    Das was du mit Deiner Ping Dauerschleife machst sagt streng genommen erst mal nur, dass für eine Anfrage keine Antwort zurück kam. Ob die Anfrage gar nicht erst das Ziel erreicht hat, die Antwort des Zielservers nicht zurück gekommen ist, oder der Server einfach grad wichtigeres zu tun hatte, als auf einen Ping zu antworten, kannst Du aus Deinem Ergebnis nicht ablesen.

    Da müsstest Du schon mindestens Wireshark oder ähnliches bemühen, um die Pakete zu analysieren. Ping ist aber auch dann denkbar unbrauchbar dafür, da das Verschicken von Antworten auf Ping Requests im Regelfall die niedrigst mögliche Priorität hat und ausbleibende Antworten daher meist eher überlastete Server sind.


    Kannst den Packet loss allenfalls in % vom gesamten Datenverkehr angeben. Das wäre dann am ehesten noch "Messen". Das wird aber aller Voraussicht nach auch extrem schwanken und sagt dir dann auch noch nicht, WARUM ein Paket verloren geht.


    Du hast natürlich Recht damit, dass ich nicht sehen kann ob mein Paket nun am Windows PC, am Router oder irgendwo anders verloren gegangen ist. Es ist aber verloren gegangen.

    Und genau das ist die Schwierigkeit an diesem Problem.


    Der Techniker vor Ort macht auch nichts anderes mit seinem 30.000 Euro testgerät, als einen Ping auf Verschiedene Server.


    Komisch ist nur, dass mehrere User haben auf einmal Paket Loss, obwohl kaum bzw. nichts geändert worden ist.

    Es werden ja nicht alle merken ob man Packet Loss hat. Nutzt man nichts was in Echtzeit ist (VOIP, online Spiele), wirst du das es nicht (kaum) merken.

    Es kann auch sein, das es eine kleine Inkompatibilität zwischen UDM und dem Zyxel Model besteht.

    aNt hat das Modul von FS.com getestet und seit dem keinen paketloss mehr. Allerdings spinnt seine UDM etwas (Dashboard buggy, Ports können nicht konfiguriert werden usw und die Traffic Analyse geht nicht.


    Wir sind noch am Testen, woran es liegt.

    Zitat von hussi

    Es ist aber verloren gegangen.

    wie gesagt. Bei Ping hat der Server ggf. auch einfach absichtlich nicht geantwortet!

    Zitat von hussi

    die Schwierigkeit an diesem Problem

    jo, Packet Loss ist doof!

    Zitat von hussi

    als einen Ping auf Verschiedene Server

    ich hoffe schon, dass der was anderes macht. Ping wäre, ich sagte es bereits, die schlechteste aller Alternativen.

    Zitat von hussi

    obwohl kaum bzw. nichts geändert worden ist.

    also bei mir passt das sehr gut mit dem Update der UDM zusammen. Wobei ich davon ausgehe, dass das Update den PacketLoss jetzt einfach anzeigt, was frühere Versionen nicht gemacht haben, sich am PacketLoss als solches aber nichts geändert hat. TCP hat damit grundsätzlich ja auch kein Problem und fordert das Paket einfach noch mal an. Meist wird das also gar nicht auffallen.

    Ein "bischen" loss ist glaub ich ganz normal. Die Meinungen gehen da von 1% bis 5%, wobei ich persönlich 5% als viel zu viel erachte.
    Laut UDM gibt es aber keinen ständigen Paketverlust sonder eher sporadisch. Für mich kein Grund dem mit viel Aufwand nachzugehen.