Beiträge von JS86

    Kann auch bestätigen, dass ich mit den UDC-1 nie Probleme hatte auch wenn ca. 20 Kabel nicht unbedingt repräsentativ sind :smiling_face:. Im Ubiquiti-Store sind die leider nicht mehr zu finden. Ich nehme an das UC-DAC-SFP+ Kabel ist der Nachfolger und die UDC-1 werden nicht mehr hergestellt?

    @EJHome deine Überlegungen sind grundsätzlich berechtigt, aber ich kann dir versichern, dass keine Schleife zu dem Zeitpunkt im Netzwerk eingebaut war und dass auch auf anderer Strecke mit zwei anderen Switchen sich dieses Fehlerbild zeigte.

    Beim "umdrehen" des Kabels wurde auf dem Port kein SFP+ Modul angezeigt. Der Port leuchtete kurz auf und die LED blieb danach aus. Auf dem anderen Switch war der Port aktiv, den konnte ich aber nicht mehr erreichen. Mit einem funktionierendem Kabel war alles in Ordnung.


    Auch bin ich mir nicht sicher, ob beim eingreifen von Spenningtree die Dämpfung der Module -40dbm Ein- und Ausgangsleistung anzeigt?

    Kurt-oe1kyw Es ist doch gut, dass bei dir nicht Gesperrt steht :smiling_face:

    Der Screenshot ist von einem Modul des defekten UC-DAC-SFP+ Kabels. Bei den 102°C tippe ich ehr auf einen defekt des Sensors im Modul. Das Kabel wurde gerade eben (kurz vorm Screenshot) erst in den Slot gesteckt und ich denke nicht, dass die Temperatur wirklich so schnell so stark angestiegen ist. Bei dem anderen defekten Kabel wurde keins der integrierten Module mehr erkannt.

    Danke euch beiden für eure Rückmeldung. Da es wohl ein weitreichenderes Problem ist und nicht an der Region, in der unsere Anschlüsse liegen, bzw. nicht an der Telekom fest zu machen ist werde ich wohl einfach warten :winking_face:

    Lästig ist es natürlich, aber ich werde damit auch leben können.

    Bei einen Teil unserer Anschlüsse (überwiegend Ewetel) ist mir die Problematik nicht aufgefallen bzw. auch die Downloads von ui.com liefen normal. Ich warte einfach ab, wird schon werden!

    Zur Info:


    habe heute unsere UC-DAC-SFP+ Kabel getestet, allerdings nicht mit einer UDM Pro (kann ich morgen nachholen) sondern erst einmal an neuen USW Pro 48 POE Gen2.


    Versuchsaufbau (bzw. wollte eh die Switche vor Konfigurieren) waren also fünf Switche und als Kabel für die Uplinks eben die UC-DAC-SFP+.

    Da die Switche im Auslieferungszustand mit der Firmware 4.0.64.**** bespielt waren und augenscheinlich alle vier Kabel funktionierten (Einbinden der Switche im Controller war einwandfrei möglich) habe ich erst einmal auf den Switch, welcher auch den Uplink (per Patchkabel) zum bestehenden Netz bereitstellte, die aktuellste Firmware eingespielt.

    Nach erfolgreichem beenden des Updates erschienen allerdings die anderen Switche nicht mehr im Controller. Sie waren Offline.
    Meine Vermutung war dann erst einmal, dass vielleicht die Firmware-Versionen zu weit auseinander liegen würden und daher der Uplink nicht mehr funktioniert, auch wenn es keinen Sinn ergeben würde .... Manchmal hat man ja solche Erlebnisse mit Ubiquiti.

    Also den Uplink vom bestehenden Netzwerk auf einen der anderen Switche gesteckt. Da waren wieder die anderen vier sichtbar, nur der bereits aktualisierte Switch war nun offline.

    Dann die weiteren vier Switche aktualisiert (dieses Mal alle vier auf einmal). Als alle hätten durch sein müssen, kamen allerdings wieder einige Switche nicht zurück.


    Darauf hin habe ich mir die Uplink mal genauer angeschaut und gesehen, dass keine Aktivität auf einigen SFP+-Ports war. Die LEDs war aus.


    Es stellte sich also heraus, dass beim Firmware-Upgrade der Switche zwei der UC-DAC-SFP+ Kabel kaputt gegangen sind. Auch zwischen Switchen (USW-48-500W) mit älterer Firmware (4.3.13) funktionierten diese Kabel nicht mehr.

    Von einem der Kabel wurde ein Modul von den Switchen erkannt, das andere Kabel gar nicht mehr.



    Fazit: die neuen UC-DAC-SFP+ Kabel kaufe ich nicht wieder! Wenn man Angst haben muss dass sie nach einem Firmware-Upgrade der Switche nicht mehr funktionieren.... :frowning_face:

    OK, erst einmal nicht wieder. Solange ich nicht lese, dass die Probleme beseitigt sind ...

    Hallo zusammen,


    dienstlich wie auch privat habe ich an mehreren Telekom-Anschlüssen seit dem 17.02.2021 Probleme mit der Latenz in Richtung USA (Amazon, Amazonaws?). Andere Anschlüsse sind unauffällig und auch nicht all unsere Anschlüsse bei der Telekom sind auffallend.

    Leider war mein heutiger Versuch der Telekom-Support wenig erfolgreich. Ich glaube der freundlichen Dame am Telefon aber auch, dass es nicht in ihrer Möglichkeit ist an dem Verhalten etwas zu ändern, aber das hilft mir/uns leider nicht weiter.

    Problematisch ist zur Zeit der Seitenaufbau (z.B. Amazon.de) einiger Seiten oder auch Downloads (siehe unten). So schlimm, dass die Leute bei mir anrufen mit dem Problembild "das Internet ist heute so langsam"! :winking_face:


    Na ja, hier ist mein Latenzverlauf der letzten sieben Tage.

    Andere Anschlüsse (ADSL, VDSLer u. Fibre, allesamt in der selben Region) sehen ähnlich aus, in unterschiedlicher Ausprägung:


    Hier ist ein tracert auf ui.com u. amazon.com von jetzt eben.


    Gerade ein Download von ui.com:


    Meine Fragen sind nun eigentlich, habt ihr in letzter Zeit ähnliches beobachten können? Habt ihr eine Idee an welche Adresse man sich wenden kann, um Unterstützung zu erhalten? Oder ist abwarten angesagt und das Problem behebt sich auf Dauer von selbst?


    Viele Grüße

    Hallo 00Schneider,


    ich denke nicht, dass die Firewall das richtige Werkzeug ist. Wenn du es mit ihr erledigen möchtest, geht es nur auf Basis der IPs.


    1."WAN Ausgehend" eine Regel erstellen die für das Subnetz "Gäste-Netz" alles blockiert.

    2. Davor (die Regeln werden von oben nach unten abgearbeitet) eine Regel erstellen die dem Subnetz "Gäste-Netz" den Zugriff auf eine bestimmte IP (wenn ich spiegel.de auflöse bekomme ich die IP 128.65.210.8 zurück) erlaubt.

    Das funktioniert natürlich nur solange spiegel.de auch über diese IP aufzurufen ist.


    Hilfreicher ist da bestimmteine andere Lösung die ein Whitlisting auf Basis der Domain machen kann.

    Pi-hole z.B.?


    Da können andere hier bestimmt mehr zu sagen :smiling_face:

    Hallo Freigeist,


    uboot21 hat schon sehr viel richtiges und wichtiges genannt.


    An deiner Stelle würde ich, zumindest für den Anfang und für einen schnellen Erfolg, auch den Reverse Proxy Server der Synology (nginx) benutzen. Synology stellt quasi für nginx hier eine anwenderfreundliche GUI bereit mit der man bereits viele Dinge erledigen kann.

    Der Reverse Proxy versteckt sich hier und nicht im Paket "Proxy Server":


    Praktisch ist auch das automatische beziehen eines Lets Encrypt Zertifikats über die Systemsteuerung.

    Über "Konfigurieren" kannst du dann dem Zertifikat deinem Reverse-Proxy-Eintrag zuweisen. Solange auf die Synology eine Portweiterleitung Port 80 u. 443 existiert wird das Zertifikat automatisch erneuert.


    Bitte möglichst https verwenden und nicht http für den Zugriff von extern!


    In dem Link, den uboot21 dir geschickt hat, steht auch schon alles detailliert beschrieben auch wenn es etwas älter ist. :smiling_face: "Neu" ist z.B. die Registerkarte "Benutzerdefinierter Header". Vorgefertigt lassen sich z.B. die Header für WebSocket setzen. Notwendig um z.B. seinen Ubiquiti Unifi Controller über den Reverse Proxy direkt erreichbar zu machen. Ob dein NextCloud-Vorhaben darüber abzuwickeln ist weiß ich allerdings nicht.


    Viel Erfolg!

    Jupi333 Ich tippe ebenso wie Cosmos auf ein defektes Kabel oder mechanisches Problem. Mit den alten schwarzen originalen 1m SFP+ DAC-Kabeln von Ubiquiti hatte ich bis dato noch keine Probleme, die neuen Weißen habe ich bei der Arbeit liegen aber noch nicht verbaut. Ich teste die kommende Woche bei Zeiten :smiling_face:. Inkompatibilität würde ich, Aufgrund original Ubiquiti, nicht vermuten. Es wäre schlimm wenn die nur mit den neuen Gen2 Switchen kompatibel sind.


    Um auf Nummer sicher zu gehen, du hast schon die SFP+ Ports (links, weiß umrandet u. mit SFP+ beschriftet) verwendet?:grinning_face_with_smiling_eyes:

    Dein Controller steht in deinem LAN oder Online?


    Und du schon recht, DNS sollte er dann den vom Provider ziehen. Hast du denn schon einmal auf deinem Controller geschaut ob deine USG nicht vielleicht trotzdem eine WAN-IP hat und dein Rechner nur hat keinen DNS?



    Wie sieht deine Netzwerkkonfiguration deines Clients aus? Teile dies uns doch einmal mit.

    1. win+r

    2. cmd

    3. ipconfig /all

    die Ausgabe hier posten

    4. ping 8.8.8.8

    die Ausgabe hier posten


    Wenn da allerdings alles ok ist habe ich spontan auch keine Idee.


    Wenn dort alles gut ist und du einen DNS per DHCP zugewiesen bekommen hast und er in deinem LAN steht, versuch doch mal die Variante dass der Zyxel das VLAN-Tagging übernimmt und die USG keinen VLAN-Tag mitgibt.

    1. Reset des Zyxel (default mit VLAN-Tag)

    2. In der WAN-Config über deinen Controller den VLAN-Tag entfernen und die USG neu provisionieren. Eingebunden hast du sie ja bereits :smiling_face:. Wenn es nicht funktioniert nochmals ganz penibel die Zugangsdaten prüfen.

    Moin Leo2010


    auch wenn ich dazu im Handbuch und beim schnellen Suchen nichts finden kann und es gerade auch nicht ausprobieren mag :grinning_face_with_smiling_eyes:, ich gehe mit dem WAN-Port des Router immer auf den LAN1 Port am Switch des Zyxel. Mir ist so, als ob ich mal ein ähnliches Problem hatte. Ansonsten, ist das Modem denn synchron (die LED neben der Weltkugel. Sieht aus wie ein RJ12 Stecker)?

    Ansonsten reicht es wenn das Modem den VLAN Tag mitgibt und das macht das Zyxel ja default. Einstellen musst du am Zyxel nichts, lediglich das Passwort solltest du ändern.

    gibst du die Zugangsdaten auf dem Webinterface der USG ein? Wenn ja, dann ist klar warum er die Daten wieder vergisst :smiling_face:. Er provisioniert neu und bekommt seine Konfiguration wieder vom Controller überspielt.


    Bitte in den Einstellungen (Einstellungen -> Netzwerk -> WAN1 bearbeiten) des Controllers die pppoe-Daten hinterlegen! VLAN-Tag macht bei mir der Zyxel ohne dass ich es auf ihm extra konfiguriert haben.

    Leo2010 da dein "Modem" die Einwahl macht, hast du ihn als Router konfiguriert und dieser macht NAT. L2TP/IPSec (bzw. IPSec) hinter NAT funktioniert nicht ohne weiteres. Die Einwahl erfolgt über ein Windowsgerät?

    Dann musst du am Client die Registry anpassen. Konfigurieren des L2TP/IPsec-Servers hinter dem NAT-T-Gerät - Windows Server | Microsoft Docs

    Optimal wäre natürlich die Einwahl (pppoe) deiner USG zu überlassen und den Zyxel in den Bridge-Mode zu versetzen. Dann muss an den Clients keine Anpassung erfolgen und die Einwahl funktioniert auch so :smiling_face:

    Telekomanschluss? Dann ggf. noch die neuste Firmware: Zyxel VMG 1312-B30A | Telekom Hilfe

    Du kannst alternativ auch von einem Windows-System aus, direkt an den Draytek angeschlossen, eine DFÜ-Einwahl testen. Aber eine Idee für die Ursache deiner Probleme habe ich leider auch nicht. Aber wie Samhain vorgeschlagen hat kann es nicht schaden die Einwahl mit einem anderen System zu prüfen. Dann weißt du zumindest schon einmal ob es allgemein Funktioniert oder nicht.

    Hi, ich habe gestern auch noch ein bisschen rumgespielt und es ist bei mir, so wie du JS86 es beschreibst. Sobald man den Zugang in beide Richtungen blockt, muss man auch in beide Richtungen Ausnahmen festlegen. In meinem Fall habe ich erstmal die Block Office zu Privat rausgenommen. Ergebnis: Funktioniert. Dann habe ich die wieder reingenommen und zusätzlich dem (privaten) Drucker erlaubt ins Office zu funken. Ergebnis: Funktioniert. Im Grunde würde mir dieses Wissen schon reichen, um das zu verwirklichen, was ich haben möchte. So viele Clients gibt es jetzt auch nicht, auf die ich aus anderen Netzbereichen zwingend zugreifen möchte. Trotzdem frage ich mich, ob man dem Teil nicht irgendwie erklären kann, dass wenn eine erlaubte Verbindung aus einem ansonsten Geblockten VLAN entsteht, der entsprechende Client auch antworten darf, ohne für diesen eine spezifische Regel gesetzt zu haben.

    Müsste funktionieren, wenn das Gerät, welches aus allen Netzen von deinem Admin-PC aus erreichbar sein soll allgemein auf Pakete antworten darf. Sicherer wird es natürlich, wenn du es auf die Ports und Protokolle beschränkst welche du benötigst.

    Samhain Steht die UDM Pro nicht WAN-seitig default auf DHCP, wie die USGs auch? 192.168.1.1 ist die default-IP im LAN der UDM Pro.


    thoelken versuchst du aus dem Netzadressbereich des Gigacubes auf die UDM Pro zuzugreifen? WAN-seitig blockt dann die Firewall der UDM Pro. Wenn du aus dem Netzadressbereich 192.168.8.0/24 den UDM Pro Konfigurieren möchtest musst du schon über die Cloud. Um die UDM Pro direkt zu erreichen musst du natürlich mit deinem Gerät an den Switch der UDM Pro. Oder funktioniert es selbst dann nicht? Hat dein Gerät auch eine IP aus dem 192.168.1.0/24 Adressbereich, oder noch statisch eine andere IP?

    BlackSpy hm, ich habe gerade versucht es nachzustellen aber bei mir funktioniert es erst, wenn ich auch in die Gegenrichtung eine Regel erstelle. Wenn dem so ist, wird es mit dem Vorhaben von cosmos schwierig da als Ziel eine IP-Adresse oder ein Subnetz angegeben werden muss.