Frustrierende mehrdimensionale Hardwaredefekte und Bugs (?)

Kolungate · September 3, 2025 at 9:34 AM

Hallo zusammen,

gestern war wieder so ein Tag: Gute Vorsätze und viel Zeit. Das Resultet jedoch war Frust ohne Ende und an die Wand gefahrene Zeit.

Grob zusammengefasst:
Ich habe einen unserer Unternehmenstandorte (an dem ich erfolgreich UI installiert habe und auch auf 1GBit betreibe) die Infrastruktur auf 10GBit bzw. stellenweise 2.5GBit ausbauen wollen.
Dazu habe ich mir "SFP+ zu RJ45 Module" und "10G Direct Attach Cables" bei unserem "Hauslieferanten" OMG gekauft.

IST Situation:
So sieht eine typische Installation bei den von mri betreuten Standorten aus:

Vorgehensweise:

Lösen der Bestandvserbindung (UDM-SE-Port7 --> USW24Pro-Port24)
Verbinden eines "10G Direct Attach Cable" am zweiten SFP+ zu Port 25 (SFP+ der UWS24Pro)
Automatische Konfiguration belassen
Die Verbindung kommt zu Stande mit 1GBit
Die Verbindungseinstellung geändert auf 10GBps FDX
USW24Pro meldet Blockierung von Port 24 am USW24Pro wegen Loop (hier hatte ich aber vgl. oben vorher das Kabel abgezogen)
USW24Pro geht offline. Site-Manager meldet "Device unreachable"
Port 26 ausprobiert.
Beide Ports melden zwar Verbindung von Daten (sie blinken) aber der USW24Pro kommt nicht zurück
Remove USW24Pro + Factory-Reset des USW24Pro bei eingestecktem "10G Direct Attach Cable"
UDM-SE erkennt neuen USW24Pro nicht
Erneuter Factory Reset, Verbindung an SFP+-Ports beendet und auf Kupfer umgeschwenkt - nun wieder an Port 24 des USW24Pro
Keine Verbindung zum Device möglich
Restart UDM-SE und USW24Pro + Verbindung von UDM-Se zu USW24Pro an anderem Port
Device wird erkannt + Adopt.
Sobald ich danach auf 10GB des 10G Direct Attach Cable gehe, verliert UDM-SE wieder die Verbindung zur USW24Pro - das gleiche gilt für Verbindung an Port 24 der USW24Pro

Mehrere mögliche Problem, die mir auch zuhause aufgefallen sind:

Ubiquiti scheint einen Bug zu haben, dass Devices die in irgendeine Firewallregel (oder Loop-Protection) geraten, nicht mehr an dem beanstandeten Port betrieben werden können UND dass die Firewallregel weiter besteht - auch wenn das Gerät aus der Konfiguration gelöscht wird. Allerdings sieht man diesen Vorfall nirgends
Ubiquiti hat zudem (vgl. oben) den Bug, dass Firewallregeln irgendwo "weiterleben", ohne sichtbar zu sein. Zuhause habe ich die UI-Protection-Firewall aktiv. Hier hatte ich Regeln editiert. Nach einem Editiervorgang, wurden plötzlich alle Reglen gelöscht - waren aber weiterhin aktiv, denn das was die Regel tun sollten, taten sie, obwohl die Regel nicht mehr zu sehen war. Ich musste zuhause erst das komplette virtuelle Netzwerk auf dem die Regel editiert war löschen und erneut anlegen. Erst danach kamen alle meine IoT-Produkte wieder online.

Nach diesem Frust habe ich zumindest versucht, von der USW24Pro (im Schaubild die [24Pro]-SWV-B1.2) zur [Enter]-Verteiler-UG-Elektroraum (USW-Enterprise-8-PoE (120W)) eine 2.5GBit-Verbindung herzustellen.

Hierzu habe ich einen SFP+-to-RJ45-Connector (1/2.5/5/10) in Port 25 eingebaut und mit einem Kupferkabel (Cat7a) am Patchpanel verbunden. Der Elektroraum ist 20m entfernt. Cat7a schafft auf jeden Fall auf der Strecke 10Gbit - und 2.5Gbit in jedem Fall.
Via 1GBit überhaupt kein Problem.
Stelle ich Geschwindigkeit aber auf 2.5GBit, dann ist auch dieses Gerät nicht mehr verfügbar --> "Device Unreachable"

Zudem habe ich an WAN2 massive Probleme mit dem internet - haltet euch fest : hier kommt auch ein SFP+-to-RJ45-Modul zum Einsatz, um über den ersten SFP+-Platz eine zweite WAN-Leitung zu realisieren. So sieht das dann täglich aus:

WAN1 ist klar - hier habe ich kaum Probleme. WAN2 habe ich über den Tag verteilt dermaßen viele Ausfälle. Die Telekom hat die Leitung schon geprüft. Es war ein Techniker vor Ort. Die Leitung funktioniert einwandfrei und wenn ich WAN2 NUR über eine Fritzbox gehen lasse, habe ich diese Verbindungsprobleme nicht. Kommt aber die UDM-SE ins Spiel fängt es an...

Mehrere Hardwareprobleme:

Möglicherweise beide SFP+-Ports am USW24Pro defekt (kann ich kaum glauben)?
Möglicherweise fehlerhafte Marge an SFP+-to-RJ45-Modulen?

Ich habe dei Freigabe für 2 weitere Standorte mit Ubiquiti bekommen, habe aber keine Lust gerade 12.000€ zu investieren, wenn ich nichtmal eine 2.5Gibt oder gar 10GBit-Verbindung realisiert bekomme.
Wie kann ich weiter vorgehen? Was kann ich machen? Habe ich etwas falsch gemacht?

**defcon** · September 3, 2025 at 9:48 AM

Welche Sfp+ RJ45 Module benutzt du denn? (Habe eins von 10Gtec im USW Aggregation zur Verbindung mit dem PC - läuft auf Auto Neg mit 10G)

Habe von der USW Aggregation auch mehrere 20G Verbindungen (1x zu UsW Pro und 1x zu USW Pro PoE, allerdings über Glas - läuft auch auf Auto Neg)

Hast du die Switchports richtig konfiguriert? Sprich port 25/26?

Kolungate · September 3, 2025 at 9:53 AM

Hallo defcon

Ich nutze dieses Modul hier: UACC-CM-RJ45-MG

Am port nutze ich die "Standard"-Konfiguration:

Danke im Voraus.

Ich habe schon bei OMG angefragt, die das intern klären - ggf. fehlerhafte Marge....aber ggf. liegt der Fehler auch woanders

**defcon** · September 3, 2025 at 10:05 AM

Sorry, der Link Speed ist bei mir auch manuell gesetzt - habe ich mich vertan.

Eigentlich ist aber der obere Teil der Port Config interessanter.

Kolungate · September 3, 2025 at 10:09 AM

Hallo Defcon

Der obere Teil sieht bei mir genauso aus wie bei dir...

DoPe · September 3, 2025 at 10:23 AM

Ich denke mal defcon meinte mit Portkonfiguration eher die VLANs ... Wenn Geräte Offline gehen die gerade adopted wurden oder schon länger sind, dann kann das Gerät den Controller nicht erreichen, was bei Portwechseln gerne mal an der VLAN Konfiguration liegen kann, insbesondere wenn man z.B. mit der Network Override Funktion bei den Geräten ein anderes Management VLAN eingestellt hat. Je nach Konfiguration kann dann das Adopten selbst schon problematisch werden.

Bisher liefen hier alle Module mit Auto Neg. einwandfrei. Einstellen der Geschwindigkeit war bislang nur nötig, wenn man ein SFP+ Modul mit einem SFP Modul verbindet, was in der Regel eher temporärer Natur ist. Oftmals muss man die Geschwindigkeit, wenn man die fest vorgeben will, auch auf beiden Seiten fest einstellen. Allerdings bin ich skeptisch wenn sich 2 10G SFP+ Module nicht per Auto Neg. einigen können, gerade bei 10G Rj45.

Was ich im Übrigen bei einigen RJ45 SFP/SFP+ Modulen schon gesehen habe, das der Port einen Link anzeigt obwohl kein Kabel drin steckt ... da bin ich mir aber nicht sicher ob das nur bei 10GTek war oder auch bei anderen Modulen, wir vermeiden die möglichst komplett.

Bei den DAC Kabeln handelt es sich auch um Ubiquiti Kabel? Mit DAC gab es hier die wenigsten Probleme, lediglich bei DAC Kabeln ab 3m hatten wir mal Probleme mit dem Querschnitt der Leiter (war AWG 30). Mit AWG26 lief es auf Anhieb rund.

Das man gleich so viele defekte Komponenten hat, halte ich für unwahrscheinlich, das gleicht ja einem Griff ins Klo.

Kolungate · September 3, 2025 at 6:55 PM

Hallo DoPe

Ja das ist frustig gewesen gestern. Ich habe 4x 0,5m DAC von Ubiquiti und 8x1m DAC gekauft. Auch hatte ich 3 SFP+-to-RJ45-Module am Start.

Nach 3 Kabeln und zwei Module tippe ich eher auf zwei defekte SFP+-Schächte im USW24Pro. - aber gleich beide? Puh...

Was deine Frage nach den Ports @VLAN anbelangt, so habe ich auch hier eher Standard konfiguriert. Die gleichen Einstellungen, wie an meinen übrigen Standorten, die keine Probleme bereiten. Netweork Override nutze ich nicht.

Bigdog71 · September 3, 2025 at 8:30 PM

Kurze Frage bezüglich VLAN auf den SFP+ ports, die stehen auf Default/Management? Nicht dass die Vlans mal aus Sicherheitsgründen geändert wurden und deshalb das Management Vlan nicht Default ist? Du hast ja genau den VLan Namen unkenntlich gemacht? An der IP kannan es ja schwer erkennen.

Mein USW Pro 24 läuft per Link Aggregation auf 20Gbit an meinem ISW Aggregation mit DAC Kabeln.

Kolungate · September 3, 2025 at 8:46 PM

Quote from Bigdog71

Kurze Frage bezüglich VLAN auf den SFP+ ports, die stehen auf Default/Management? Nicht dass die Vlans mal aus Sicherheitsgründen geändert wurden und deshalb das Management Vlan nicht Default ist? Du hast ja genau den VLan Namen unkenntlich gemacht? An der IP kannan es ja schwer erkennen.
Mein USW Pro 24 läuft per Link Aggregation auf 20Gbit an meinem ISW Aggregation mit DAC Kabeln.

Hallo

Also ich habe das VLAN ausgeblendet, weil es den Standort beinhaltet - das war mir wegen Interna zu heikel

Das "Haupt-VLAN" ist eingestellt, also das. was ich überall für Mitarbeiter nutze.

Bigdog71 · September 3, 2025 at 8:50 PM

Es sollte aber das Vlan eingestellt sein, was das Management macht und nicht die User (außer es gibt nur eins).

Kolungate · September 3, 2025 at 10:16 PM

Jaja das VLan dass das Management macht ist mein "Mitarbeiter-VLAN", dann gibt es noch Teilnehmer, Telefonie und Gast . die sind aber nicht eingestellt, denn sonst könnte ich den Switch ja nicht mehr erreichen

**Networker** · September 4, 2025 at 2:04 AM

Quote from Kolungate

USW24Pro meldet Blockierung von Port 24 am USW24Pro wegen Loop (hier hatte ich aber vgl. oben vorher das Kabel abgezogen)

Nur kurzes Feedback zu diesem Punkt, weil mir dazu in einem Projekt letzte Woche etwas aufgefallen ist. Es gab dort ein bisschen Netzwerkumbau und ein Pro-Max-24-PoE-Switch ist in einem neu entstandenen Netzwerkschrank zum Bestand (Pro-48-PoE, UDM-Pro und Switch-Kleinkram) dazu gekommen.

Beim Umkonfigurieren von Ports und Neuverbinden von Endgeräten kam es mehrfach dazu, dass einer der Switches gemeldet hat "Loop detected, Port disabled" (oder so ähnlich). RSTP ist dabei auf allen Switches aktiv. Diese Meldung verschwand aber in allen Fällen nach ca. 20 Sekunden, der Port war nicht stillgelegt und das jeweils frisch verkabelte Endgerät wurde im Controller sichtbar.

Mir schien es so, als sei die aktuelle Firmware da etwas hypersensibel, denn keines der angeschlossenen Geräte hing mit zwei Schnittstellen gleichzeitig im Netz. Und nur das wäre ja ein plausibler Grund, dass RSTP auslöst und den Switchport abschaltet.

Peterfido · September 4, 2025 at 6:25 AM

Loop detected hatte ich in letzter Zeit auch mehrmals. Nervt etwas. RSTP habe ich daher abgeschaltet. Mein Netzwerk ist allerdings wesentlich kleiner und die Verbindungen überschaubar. Bei den APs muss Mesh ausgeschaltet sein, sonst kommen beim Umstecken Verbindungen zwischen den Swicthen per WLAN zustande, und der Loop ist dann tatsächlich vorhanden.

Bei der Größe an Netzwerk würde ich einige Verbindungen optisch durchführen. Nicht, dass sich da über die Netzwerkkabel unterschiedliche elektrische Potenziale ausgleichen. Die DAC-Verbindungen bieten sich da geradezu an.

**Networker** · September 4, 2025 at 8:22 AM

In meinem beschriebenen Fall ist Meshing global deaktiviert, es gibt gar keine APs, die nicht am Kabel hängen.

Die beiden großen Switches sind in der Tat per LWL verbunden. Da Du von DAC schreibst: DACs bestehen aus Kupfer ("Direct Attached Copper") und sind daher keine elektrischen Isolatoren.

Die kurzzeittigen Loop-Fehlermeldungen kamen u.a. beim Anschluss von Desktop-PCs, die gar keine zweite Netzwerkkarte haben. Mir ging es nur darum, aufzuzeigen, dass diese Meldungen derzeit offenbar fälschlich generiert werden könnten - man sollte also 30 Sekunden Geduld haben und nicht sorgenvoll direkt wieder alle Kabel rausrupfen (was im Normalfall ja die logische Reaktion wäre, ich hatte es auch so getan).

Kolungate · September 4, 2025 at 10:33 AM

Hallo zusammen

Mit LWL hatten wir auch nicht gerade die besten Erfahrungen. An einem Standort hatte ich LWL genutzt und es kam soweit, dass die Geräte ebenfalls einen Loop erkannten und zudem, dass ständig die Meldung kam, dass diverse Switche bereits "von einer anderen Console übernommen worden seien". Das trat alle 5min auf. Bin dann auf DAC und seither geht es an dem Standort (auch mit 10Gbit)

Meshing habe ich auch deaktiviert. kA warum dieser Rotz standardisiert aktiviert ist.

DoPe · September 4, 2025 at 7:44 PM

Ich tippe mal darauf, das beim Umstecken irgendwelcher Verbindungen an den Switchen, auf dem neuen Port Pakete von einer MAC Adresse kommen, die in der ARP Tabelle des Switches noch auf dem alten Port liegt. Somit kommt so ein Paket vermeintlich über eine zweite Schnittstelle, was eben genau bei einem Loop auch passiert ...

**Networker** · September 4, 2025 at 9:05 PM

Quote from DoPe

Ich tippe mal darauf, das beim Umstecken irgendwelcher Verbindungen an den Switchen, auf dem neuen Port Pakete von einer MAC Adresse kommen, die in der ARP Tabelle des Switches noch auf dem alten Port liegt. Somit kommt so ein Paket vermeintlich über eine zweite Schnittstelle, was eben genau bei einem Loop auch passiert ...

Sehr guter und interessanter Denkansatz, danke! Das würde die Situation bei meinem Projekt gut erklären, da die Warnungen nicht immer auftauchten, aber manche Geräte auch tatsächlich neu hinzugekommen sind und nicht nur umgesteckt worden sind.

Kolungate · September 22, 2025 at 11:04 AM

Quote from Networker

Sehr guter und interessanter Denkansatz, danke! Das würde die Situation bei meinem Projekt gut erklären, da die Warnungen nicht immer auftauchten, aber manche Geräte auch tatsächlich neu hinzugekommen sind und nicht nur umgesteckt worden sind.

Hallo DoPe und Networker

Ich glaube auch dass es so war. Ich fahre nun besser, wenn ich vor größeren Veränderungen den Port der alten Verbindung erst deaktiviere und später wieder aktiviere. UI hat mir zum den Tausch des wohl defekten USW24Pro angeboten.

Participate now!