Hulp gevraagd bij (Unifi AP) netwerk probleem

[dc31xx]

Mijn vraag

Ik probeer een extra Unifi AP op te nemen in mijn netwerk, maar krijg het niet werkend. Ik heb het geprobeerd terug te brengen tot een minimale repro (zie figuren hieronder) maar kan niet verklaren waarom het nieuwe AP mijn netwerk verstoord wat terug te herleiden lijkt naar dat hij na x minuten uitvalt. Daarnaast kan het nieuwe AP niet adopten op de controller.

Ik ben geen netwerk expert, dus ik doe vast iets verkeerd. Heeft iemand een idee wat er hier aan de hand kan zijn?

Relevante software en hardware die ik gebruik:

OPNsense (virtueel op zelfde host als Unifi Controller)
Unifi 6 LR (AP1), verbonden via switch TP-Link (PoE)
Unifi 6 Lite (AP2), verbonden via switch Unifi (aparte PoE injector, voor reasons)
Unifi 6+ (AP3) , verbonden via switch Netgear (PoE)
Unifi Controller in Docker (recentste versie)

Alle AP's managed / bieden ondersteuning voor VLAN's.

Hieronder de vertreksituatie die werkt (ok), en de vervolgstappen die ik heb genomen.
...

Huidig



Gewenst (mislukt/nok)
Als ik AP3 wil toevoegen en een extra trunk poort op de switch configureer gaat het mis. Het netwerk wordt verstoord, de controller laat AP1, AP2 afwisselend online/offline zien en van AP3 geeft hij aan dat er problemen zijn met het adopten. In een van de volgende stappen heb ik achterhaald dat het nieuwe AP's netwerk weg lijkt te vallen (WiFi signaal valt weg, geopende connecties via LAN worden gesloten) lijkt te gaan en mogelijk zorgt dit voor de verstoring.

In eerste instantie dacht ik dat de dubbele trunk wellicht de oorzaak van de problemen was, maar in de volgende stappen zul je zien dat het ook in een simpel scenario niet werkt.

Een andere hypothese was dat de Unifi switch niet lekker samen zou gaan met de andere switches, maar ook dat heb ik een volgende stap uitgesloten.



Iets anders dat ik geprobeerd heb, maar nog niet had teruggebracht naar een minimale repro:
Gedachte: misschien is er iets met die trunk poort, laat ik de AP inprikken op een poort met het default VLAN. Hierdoor zal de AP niet alle VLAN's ondersteunen, maar om te kijken of het werkt. En dat deed het wel.



Verder teruggebracht naar het bare minimum, waarvan ik had verwacht dat het sowieso zou moeten werken.

Na deze stap begon ik eigenlijk te twijfelen of de hardware wel OK is, maar het is een nieuw apparaat, dus dat lijkt me onwaarschijnlijk. Waarom werkt het niet met slechts 1 enkele AP terwijl het vertrekpunt dat veel complexer is met meerdere AP's (anders dan deze nieuwe) wel werkt.

Ik dacht: misschien kan de switch niet voldoende power leveren, dus heb het nog geprobeerd met een aparte PoE adapter, maar no luck.



Tot slot heb ik nog het volgende geprobeerd



Dit "werkt" maar heeft uiteraard niet het gewenste resultaat. De AP geeft alleen toegang tot het default network.

Conclusie

Mijn AP lijkt een trunk-port allergie te hebben? Ik weet het echt even niet meer. Hoop dat iemand met meer verstand van deze tech me hier verder mee kan helpen.

[CrankyGamerOG]

Als je AP uitvalt, wat jij zegt, dan ligt het toch echt aan de Netgear. Of bedoel je met UIT alleen dat het netwerk wegvalt?

[ Voor 27% gewijzigd door CrankyGamerOG op 11-12-2024 15:50 ]

[dc31xx]

Het Wifi netwerk (en ook bedrade toegang) valt weg, de LED van het AP blijft bijvoorbeeld wel branden. Als ik met behulp van een PoE injector (waarmee ik stroom kan blijven geven en toch de netwerkkabel kan wisselen) hem weer in een default VLAN poort steek komt hij weer terug.

[CrankyGamerOG]

dc31xx schreef op woensdag 11 december 2024 @ 15:54:
Het Wifi netwerk (en ook bedrade toegang) valt weg, de LED van het AP blijft bijvoorbeeld wel branden. Als ik met behulp van een PoE injector (waarmee ik stroom kan blijven geven en toch de netwerkkabel kan wisselen) hem weer in een default VLAN poort steek komt hij weer terug.

Dan moet je niet zeggen dat hij UIT valt

Hoezo trunk je alles naar die ap's en niet alleen het vlan waar het in thuis hoort?
Of ja alles, geen idee, wat je noemt geen vlans.

P.S. die netgears zijn echt ondingen, ik heb ook veel gezeik gehad (multicast iptv) en heb toen alles vervangen met het hele unifi eco systeem

Als je nu eens die AP3 test op de unifi switch, wat gebeurt er dan? Kun je vrij eenvoudig de netgear uitsluiten of niet.

Laat de config van die netgear eens zien ,want het feit dat het op default vlan wel werkt en met jouw config niet, doet mij vermoeden dat je iets verkeerd doet in de netgear.

[ Voor 39% gewijzigd door CrankyGamerOG op 11-12-2024 16:08 ]

[SniperGuy]

Begin er eens mee om de controller bedraad aan te sluiten. Want anders heb je bij het instellen/adopten wellicht een kip-ei situatie met een AP wat niet bij de controller kan.

[dc31xx]

CrankyGamerOG schreef op woensdag 11 december 2024 @ 16:02:
[...]
Dan moet je niet zeggen dat hij UIT valt

Terecht punt. Je doet een poging duidelijk te zijn, maar maakt wel eens een foutje..

Hoezo trunk je alles naar die ap's en niet alleen het vlan waar het in thuis hoort?
Of ja alles, geen idee, wat je noemt geen vlans.

Dit kan een gebrek aan kennis zijn van mijn kant, maar omdat ik meerdere VLAN's ontsluit via de AP heb ik dit in de Netgear aangegeven als Uplink/Trunk

Als je nu eens die AP3 test op de unifi switch, wat gebeurt er dan? Kun je vrij eenvoudig de netgear uitsluiten of niet.

Ik heb de AP3 met AP2 verwisseld en dan werkt de AP3 als een zonnetje en zorgt de AP2 voor problemen. Probleem met hardware lijkt dus uitgesloten. Het lijkt erop dat alleen het SSID dat het default VLAN ontsluit voor problemen zorgt. In de controller zie je om de beurt devices onbereikbaar/bereikbaar worden en als ik met het SSID verbonden ben komt het verkeer wisselend door (en moment kun je verbinden, andere niet).

Laat de config van die netgear eens zien ,want het feit dat het op default vlan wel werkt en met jouw config niet, doet mij vermoeden dat je iets verkeerd doet in de netgear.

8 (uplink naar AP 1) was er altijd al, ik heb 7 toegevoegd (uplink naar AP3). 1 geeft toegang tot de controller, 2,3,4 zijn wat IOT devices.

[dc31xx]

SniperGuy schreef op woensdag 11 december 2024 @ 16:52:
Begin er eens mee om de controller bedraad aan te sluiten. Want anders heb je bij het instellen/adopten wellicht een kip-ei situatie met een AP wat niet bij de controller kan.

Ik heb geen hardware controller. De controller draait virtueel op een host die is "bedraad"

[SniperGuy]

Ah, maar het staat nu zo getekend dat het draadloos is of aan dat AP hangt. De tekening is een L1 en L4 tekening door elkaar

[dc31xx]

SniperGuy schreef op woensdag 11 december 2024 @ 19:25:
Ah, maar het staat nu zo getekend dat het draadloos is of aan dat AP hangt. De tekening is een L1 en L4 tekening door elkaar

Nu je het zegt, ik snap ik de verwarring. De software links draait op dezelfde machine. Dat wordt achteraf idd niet duidelijk uit de tekening. Heb de software er later bijgezet “ter verduidelijking”, maar begrijp de verwarring.

[CrankyGamerOG]

Het lijkt er dus op dat bij je trunk het default vlan niet meekomt, of dat de AP deze niet herkent, laat je unifi controller settings mbt deze ap eens zien.

[ Voor 39% gewijzigd door CrankyGamerOG op 12-12-2024 10:57 ]

[dc31xx]

@CrankyGamerOG Ik heb de Netgear mede n.a.v. je opmerking vervangen door een Unifi swich en het werkt nu prima. Bedankt voor het meedenken!

[ Voor 7% gewijzigd door dc31xx op 15-12-2024 15:12 ]

[RiDo78]

Het probleem lijkt hier vooral de definitie van een Trunk.

Er zijn namelijk meerdere soorten trunks en als ze het gewoon over een 'trunk' hebben dan kan het verschillende dingen betekenen. In mijn beleving is een trunk meestal synoniem aan channel-bonding waarbij meerdere kabels worden samengepakt tot één grote verbinding. Dus 2x kabels van 1G om een 2G verbinding te maken bijvoorbeeld.

Helaas is het zo dat zeker in de 'kleinere' / consumenten switches vanuit wordt gegaan dat er niet meer dan één poort per verbinding is. En technisch gesproken kunnen ze dat ook niet aan; de switch kan van binnen bijvoorbeeld geen 2 Gbit aan. Dus dat ze met een 'trunk' dan een poort bedoelen waar alle VLAN's op worden aangeboden. Geen channel-bonding dus, maar een VLAN-trunk. En zo is de verwarring compleet.

Blijkbaar ziet de netgear een trunk ook echt als het samenpakken van meerdere lijnen, ofwel channel-bonding. En in dat geval is het verklaarbaar dat het netwerk inzakt; hij verwacht namelijk op elk van de twee poorten een verbinding met de TPLink óf met de AP. Wat er volgens mij dus gebeurd is dat hij probeert te leren waar de MAC-adressen te vinden zijn. Hij krijgt dan een tabel van de TPLink (en dan is de AP offline) totdat de AP zich weer meldt waarbij de rest van het netwerk uit de tabel gehaald wordt.

Tegelijk ziet de TP-link een trunk blijkbaar als VLAN-trunk, oftewel één verbinding waar meerdere VLAN's overheen gaan.

Mocht je je netwerk verder gaan uitbreiden en die netgear weer wilt proberen dan moet op de netgear dus geen trunk gebruiken maar een 'gewone' poort waar je alle VLANs op meegeeft. Eventueel het switch-management-vlan instellen als native vlan.

Just keep in mind, je zit niet aan Ubiquity vast, ookal zouden ze dat graag willen. Een vlan is een vlan maar een trunk . . . hóeft dus geen trunk te zijn. Ga er gewoon vanuit dat alle verbindingen tussen de unify-apparaten automatisch VLAN-trunks zijn en je die ook als zodanig door je netwerk moet leiden.