[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3

[Ethirty]

Normaal ben ik altijd wel een fan van nieuwe gadgets, maar ik word een beetje UniFi moe met alle nieuwe categorieën terwijl andere dingen nog niet af of compleet zijn.

[RobertMe]

Ethirty schreef op dinsdag 16 april 2019 @ 20:49:
Normaal ben ik altijd wel een fan van nieuwe gadgets, maar ik word een beetje UniFi moe met alle nieuwe categorieën terwijl andere dingen nog niet af of compleet zijn.

Laten we dan in ieder geval hopen dat een volledig gescheiden team hieraan werkt. En er dus niet (bv) developers zijn die vandaag aan de UniFi Controller werken en morgen aan UniFi Access System.

An zich kan het natuurlijk wel werken en als het ook nog te combineren is met UniFi Protect en evt. andere uitbreidingen kan het wel leuk worden. Ze zullen ook vast niet voor niks een hele tijd terug de hoofdontwikkelaar / bedenker van Home Assistant hebben aangenomen.

[nero355]

Ethirty schreef op dinsdag 16 april 2019 @ 20:49:
Normaal ben ik altijd wel een fan van nieuwe gadgets, maar ik word een beetje UniFi moe met alle nieuwe categorieën terwijl andere dingen nog niet af of compleet zijn.

Helemaal mee eens

Er is nog werk zat aan de UniFi Controller wat betreft de USG vooral!

En verder is het ook niet echt een produkt waarvan ik denk : "Hey! Dat had ik nou net nodig!"

/EDIT :

ed1703 schreef op dinsdag 16 april 2019 @ 20:58:
Alleen een stroomstoring is wat extra vervelend

Daarover gesproken : Mijn Raspberry Pi heeft er weer één overleefd!

Zie ik de gewone CloudKey niet doen!

_{Iets met iemand die wat zat te knoeien met wat kabels, terwijl ik in een andere kamer opeens zonder stroom zat met een hele grote W-T-F op mijn gezicht : Leuk die rotzooi van de vorige bewoners opruimen!}

[ Voor 35% gewijzigd door nero355 op 16-04-2019 21:13 ]

[ed1703]

Ethirty schreef op dinsdag 16 april 2019 @ 20:49:
Normaal ben ik altijd wel een fan van nieuwe gadgets, maar ik word een beetje UniFi moe met alle nieuwe categorieën terwijl andere dingen nog niet af of compleet zijn.

Ik was al bang dat ik de enige was met die mening sinds het uitbrengen van de Dream Machine De volgende lijn hier in huis gaat voor mij wel de edgelijn worden denk ik, want dit schiet niet op zo Met dan nog wel wat Unifi-APjes, want die keuze is er niet. Voorlopig maar een beetje blijven aanrommelen met een config.gateway.json en wat handmatig openvpn-zooi, waarbij ik dan ook weer niet vaak provision. Alleen een stroomstoring is wat extra vervelend

[ Voor 15% gewijzigd door ed1703 op 16-04-2019 21:02 ]

[HKLM_]

Ethirty schreef op dinsdag 16 april 2019 @ 20:49:
Normaal ben ik altijd wel een fan van nieuwe gadgets, maar ik word een beetje UniFi moe met alle nieuwe categorieën terwijl andere dingen nog niet af of compleet zijn.

Ze hadden deze dingen beter onder een andere naam kunnen uitbrengen... met Home Assistant producten is niks mis. Maar gooi het dan onder een andere naam op de markt en roep dat het volledig compatible is met je unifi line up. Heb nu een beetje het idee dat ze de bekentheid van unifi misbruiken voor alles wat ze bedenken.

[ Voor 26% gewijzigd door HKLM_ op 16-04-2019 21:09 ]

[ed1703]

nero355 schreef op dinsdag 16 april 2019 @ 20:57:
[...]

Daarover gesproken : Mijn Raspberry Pi heeft er weer één overleefd!

Zie ik de gewone CloudKey niet doen!

Hier al meerdere stroomstoringen meegemaakt en geen centje pijn op de gen1.
Lucky me.

[ro3lie]

Quad schreef op woensdag 3 april 2019 @ 23:57:
[...]

Goeie, ik vroeg mij vandaag nog af wat ik nog meer kon met de CloudKey. Ik heb nu Acme.sh erop draaien icm Cloudfare account (free), voor Letsencrypt certs zodat ik de cloudkey veilig van buitenaf kan bereiken.
Nav jouw post gelijk Pi-Hole erbij op gezet. Werkt als een tiet.

Was wel ff klooien met de sources.list.
Ik heb hiervoor het volgende gedaan:
Nieuw bestand aangemaakt:

code: /etc/apt/apt.conf

Acquire::Check-Valid-Until "false";

Jessie wordt niet meer bijgewerkt, dus daarom de check eruit.

In sources.list het volgende toegevoegd (oude gebackupt en verwijderd):

code: /etc/apt/sources.list

deb http://cdn-fastly.deb.debian.org/debian/ jessie main
deb-src http://cdn-fastly.deb.debian.org/debian/ jessie main

deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main

deb http://archive.debian.org/debian jessie-backports main
deb-src http://archive.debian.org/debian jessie-backports main

Jessie is gewijzigd en heeft nieuwe links.

In de folder /etc/apt/sources.list.d/ de volgende bestanden hernoemd:
100-ubnt-unifi.list -> 100-ubnt-unifi.list.bak
security.list -> security.list.bak

Nu kan je het volgende uitvoeren:

apt-get update

Mogelijk dat je het 2 keer moet doen.
Nadien kan je zonder gedoe Pi-Hole erop zetten, ik heb hiervoor deze handleiding gevolgd: https://gist.github.com/s...247483d7a0a939b68f00b8f3d

Daarna op de CK alle netwerken de DNS aangepast naar de CloudKey, wel werkte het gasten netwerk niet meer, maar dit was op te lossen door een FW rule op LAN-IN aan te maken, Gasten netwerk -> accept -> PiHole IP.

_{Nb. Volgens de handleiding werkt PiHole na een FW update niet meer, wel iets om rekening mee te houden.}

@nero355 @grote_oever
Als je een beetje ruimte hebt in meterkast, ik heb zelf een 9u 10" patchkast geïnstalleerd met de verbouwing:
[Afbeelding]

Bestaat uit:
Alfaco 9u 10" wandkast
10" CAT6A 12p paneel
2x Leg bord
2x Kabelgeleiders
1x Planet GSD-1020s managed switch ivm glasvezel die hier rechtstreeks in gaat.
1x Unifi Gen1 CK
1x USG 3P
1x 8P UniFi Switch
2x UAP AC LR in huis

Ik wilde heel graag de UniFi met glasvezel poorten, maar helaas is dat te breed voor de patchkast. De Planet hangt er ook mooi in, is de enige verkrijgbare 10" switch die rackmounts heeft + glasvezel ingang (dedicated).

Vanavond is het mij succesvol gelukt om HomeBridge op de CloudKey Gen1 te installeren.
De UniFi Network Controller is ook verwijderd waardoor alleen de beheer interface van de CloudKey overblijft. Dit draai ik nu zelf op een VM.

Meer info er over in een ander topic:
ro3lie in "Homebridge topic"

De UniFi Network Controller kan je veilig verwijderen middels:

code:

dpkg -P unifi

Bron: Removing the UniFi Network Installation

Dit is mogelijk interessant voor sommige Tweakers die overstappen op de Gen2 en nu niks doen met de Gen1 CK

[GioStyle]

Even voor de beeldvorming qua verbruik van de switches.

Alle switches adopted met 1 utp kabel aangesloten, gemeten met Energy Logger 4000:

US-8-60W = 7,5W
US-16-150W = 16,8W
US-24 = 13,4W

Heb sinds gisteren de US-16-150W die de US-8-60W gaat vervangen.

[ericafterdark]

ed1703 schreef op dinsdag 16 april 2019 @ 20:58:
[...]
Ik was al bang dat ik de enige was met die mening sinds het uitbrengen van de Dream Machine De volgende lijn hier in huis gaat voor mij wel de edgelijn worden denk ik, want dit schiet niet op zo Met dan nog wel wat Unifi-APjes, want die keuze is er niet. Voorlopig maar een beetje blijven aanrommelen met een config.gateway.json en wat handmatig openvpn-zooi, waarbij ik dan ook weer niet vaak provision. Alleen een stroomstoring is wat extra vervelend

Volledig mee eens. IPv6 ondersteuning bijvoorbeeld is nog steeds verre van compleet. Ik krijg het niet aan de praat met XS4ALL en een FRITZ!Box 7581 in full bridge. En als ik bij XS4ALL tevens IPTV zou afnemen, zou ik ook moeten rommelen met een JSON bestand.

[HKLM_]

GioStyle schreef op woensdag 17 april 2019 @ 18:05:
Even voor de beeldvorming qua verbruik van de switches.

Alle switches adopted met 1 utp kabel aangesloten, gemeten met Energy Logger 4000:

US-8-60W = 7,5W
US-16-150W = 16,8W
US-24 = 13,4W

Heb sinds gisteren de US-16-150W die de US-8-60W gaat vervangen.

Wat extra beeldvorming Bij mij doet de US-16-150W met een cloudkey G1, AP-AC-Lite en een AC-LR in totaal 23Watt

[Jeroen V]

HKLM_ schreef op woensdag 17 april 2019 @ 18:22:
[...]


Wat extra beeldvorming Bij mij doet de US-16-150W met een cloudkey G1, AP-AC-Lite en een AC-LR 23W

Je houdt het spannend?? Ok, dan zorg ik voor het tromgeroffel

Maar wat verbruikt het nou precies?
Ik heb eerlijk gezegd geen flauw idee wat mijn setup in totaal verbruikt, maar ik denk dat de Nuon wel blij met me is... (en vandaag weer een extra server besteld, dus het stroomverbruik wordt niet lager....)

[HKLM_]

Jeroen V schreef op woensdag 17 april 2019 @ 19:02:
[...]

Je houdt het spannend?? Ok, dan zorg ik voor het tromgeroffel

Maar wat verbruikt het nou precies?
Ik heb eerlijk gezegd geen flauw idee wat mijn setup in totaal verbruikt, maar ik denk dat de Nuon wel blij met me is... (en vandaag weer een extra server besteld, dus het stroomverbruik wordt niet lager....)

Dacht dat het wel duidelijk was dat het hele zwikje 23 watt was

[Will_M]

HKLM_ schreef op woensdag 17 april 2019 @ 19:24:
[...]


Dacht dat het wel duidelijk was dat het hele zwikje 23 watt was

Het gaat nu dus een jaartje of wat duren voordat je het meetapparaat (vanwege het gering opgenomen vermogen) weer terug verdiend hebt

[Jeroen V]

HKLM_ schreef op woensdag 17 april 2019 @ 19:24:
[...]


Dacht dat het wel duidelijk was dat het hele zwikje 23 watt was

note to self: beter lezen

[GioStyle]

Ik heb nu dus een US-24 en een US-16-150W.

Ik wil graag deze switches aan elkaar koppelen door middel van de sfp poorten.

Kan ik best voor glasvezel modules gaan of utp? Zijn er voor- en nadelen van beiden?

[HKLM_]

GioStyle schreef op woensdag 17 april 2019 @ 20:30:
Ik heb nu dus een US-24 en een US-16-150W.

Ik wil graag deze switches aan elkaar koppelen door middel van de sfp poorten.

Kan ik best voor glasvezel modules gaan of utp? Zijn er voor- en nadelen van beiden?

Die SFP porten doen max 1Gb dus dat kan prima over utp.

[Wafeltje]

GioStyle schreef op woensdag 17 april 2019 @ 20:30:
Ik heb nu dus een US-24 en een US-16-150W.

Ik wil graag deze switches aan elkaar koppelen door middel van de sfp poorten.

Kan ik best voor glasvezel modules gaan of utp? Zijn er voor- en nadelen van beiden?

Beide zullen 1Gbps zijn, dus daar zit het verschil niet in. Als je poorten te kort komt, kun je SFP overwegen (zelfs met UTP). Als je over gigantische afstanden wilt gaan is glas soms de betere keuze (UTP kan officieel maar tot 100 meter, in praktijk vaak verder met fatsoenlijke kabels).

Heb je poorten zat en hangen ze naast elkaar, bestel 2 korte cat6a patchkabels en maak een LAG aan.

[ Voor 6% gewijzigd door Wafeltje op 17-04-2019 20:35 ]

[kevinl]

Wafeltje schreef op woensdag 17 april 2019 @ 20:34:
[...]


Beide zullen 1Gbps zijn, dus daar zit het verschil niet in. Als je poorten te kort komt, kun je SFP overwegen (zelfs met UTP). Als je over gigantische afstanden wilt gaan is glas soms de betere keuze (UTP kan officieel maar tot 100 meter, in praktijk vaak verder met fatsoenlijke kabels).

Heb je poorten zat en hangen ze naast elkaar, bestel 2 korte cat6a patchkabels en maak een LAG aan.

Wat is het verschil tussen LAG en ALL als profile?

[Wafeltje]

kevinl schreef op woensdag 17 april 2019 @ 20:39:
[...]


Wat is het verschil tussen LAG en ALL als profile?

LAG = Link aggregation Group, dus meerdere verbindingen worden tot 1 virtuele verbinding samengevoegd. Je hebt meer bandbreedte tussen de 2 switches, maar ook minder risico, omdat het ook werkt als 1 kabel er om wat voor reden tussenuit is.

Profile ALL = alle vlans op die ene poort.

op een LAG kun je zelf ook bepalen of je alle vlans wilt toestaan (wat je tussen 2 switches meestal wel wilt), of niet. Als je bijvoorbeeld alleen cameras op die PoE switch hebt, zou je alleen je camera-vlan er op toe kunnen staan, + je management-vlan om je switch te beheren.

[Jeroen V]

GioStyle schreef op woensdag 17 april 2019 @ 20:30:
Ik heb nu dus een US-24 en een US-16-150W.

Ik wil graag deze switches aan elkaar koppelen door middel van de sfp poorten.

Kan ik best voor glasvezel modules gaan of utp? Zijn er voor- en nadelen van beiden?

Voor snelheid maakt het zoals hierboven ook al wordt aangegeven niets uit.

Wat een nadeel is aan SFP is dat het een stuk duurder is dan een CAT5/6 kabeltje. Of je hebt een DAC (Direct Attach Copper/Cable) nodig die al snel een tientje of 3 kost en een stuk minder handig is in gebruik. Of je hebt 2 transceiver die dat ook al snel kosten. (fiber kabeltje is erg goedkoop, vergelijkbaar met een CAT5/6 kabeltje)

Voordeel van SFP is dat het veel mooier is om naar te kijken en heerlijk nerderig is, maar ja, hoe vaak ga je voor dat spul zitten staren

Ik heb zelf tussen twee Ubiquiti switches een setje CAT5 kabeltjes die een paar euro per stuk zijn. (en dan uiteraard link aggregation, simpelweg omdat het kan, ik denk niet dat ik het ooit ga merken)

Dan krijg je dus dit:

[Will_M]

Jeroen V schreef op woensdag 17 april 2019 @ 20:51:
[...]

Voor snelheid maakt het zoals hierboven ook al wordt aangegeven niets uit.

Wat een nadeel is aan SFP is dat het een stuk duurder is dan een CAT5/6 kabeltje. Of je hebt een DAC (Direct Attach Copper/Cable) nodig die al snel een tientje of 3 kost en een stuk minder handig is in gebruik. Of je hebt 2 transceiver die dat ook al snel kosten. (fiber kabeltje is erg goedkoop, vergelijkbaar met een CAT5/6 kabeltje)

Voordeel van SFP is dat het veel mooier is om naar te kijken en heerlijk nerderig is, maar ja, hoe vaak ga je voor dat spul zitten staren

Ik heb zelf tussen twee Ubiquiti switches een setje CAT5 kabeltjes die een paar euro per stuk zijn. (en dan uiteraard link aggregation, simpelweg omdat het kan, ik denk niet dat ik het ooit ga merken)

Dan krijg je dus dit:
[Afbeelding]

SFP's beginnen pas echt nut te bewijzen als je de "back-bone" in je privé omgeving naar 10Gb wilt zetten óf als je normale poorten te kort aan het komen gaat.

Een link over méér dan 100 Mtr, in een woonhuis zie ik nog niet snel gebeuren, net zoals dat ik ik 't nut van CAT6A in een woonhuis niet toepasselijk vind

[Comp User]

wimmel_1 schreef op woensdag 17 april 2019 @ 21:30:
[...]


Net zoals dat ik ik 't nut van CAT6A in een woonhuis niet toepasselijk vind

Ja en nee - je hebt in zoverre gelijk, dat als je je kabels "gewoon" in een switch steekt begrijp ik de keuze, echter als je met een patchpanel, keystones en inwandige bekabeling gaat werken, dan gaat mijn voorkeur uit naar Cat. 7 of recenter.

Ik ga ervan uit dat je het de komende jaren laat voor wat het is - net zoals bij Electra - daar ben je ook niet elk jaar mee bezig - zowel dan heb je iets niet goed gedaan imho.

[MisteRMeesteR]

Jeroen V schreef op woensdag 17 april 2019 @ 20:51:
[...]


Voordeel van SFP is dat het veel mooier is om naar te kijken en heerlijk nerderig is, maar ja, hoe vaak ga je voor dat spul zitten staren

Hoeveel hebben we al naar jouw opstelling zitten staren me z’n allen?

Hier glas tussen de routers en switches, puur omdat het kan en ‘mooier’ is

[ Voor 8% gewijzigd door MisteRMeesteR op 17-04-2019 23:01 ]

[Will_M]

Comp User schreef op woensdag 17 april 2019 @ 22:49:
[...]


Ja en nee - je hebt in zoverre gelijk, dat als je je kabels "gewoon" in een switch steekt begrijp ik de keuze, echter als je met een patchpanel, keystones en inwandige bekabeling gaat werken, dan gaat mijn voorkeur uit naar Cat. 7 of recenter.

Ik ga ervan uit dat je het de komende jaren laat voor wat het is - net zoals bij Electra - daar ben je ook niet elk jaar mee bezig - zowel dan heb je iets niet goed gedaan imho.

Ik ben zo'n "Eikel" welke het ± 20 jaar geleden overbodig vond om zakelijk in UMTS connecties te (laten) investeren terwijl we er toen al op gewezen werden door de Telco .....

Tegenwoordig lachen we om UMTS (als in: We klagen op het moment dat we via een "Edge" verbinding over die UMTS connectie moeten werken).

[Cartman!]

Comp User schreef op woensdag 17 april 2019 @ 22:49:
[...]


Ja en nee - je hebt in zoverre gelijk, dat als je je kabels "gewoon" in een switch steekt begrijp ik de keuze, echter als je met een patchpanel, keystones en inwandige bekabeling gaat werken, dan gaat mijn voorkeur uit naar Cat. 7 of recenter.

Ik ga ervan uit dat je het de komende jaren laat voor wat het is - net zoals bij Electra - daar ben je ook niet elk jaar mee bezig - zowel dan heb je iets niet goed gedaan imho.

Juist daarom zou ik Cat6 kiezen; ik heb inmiddels n hoop ellende gelezen met aardlussen en gedoe vanwege de afschermingen bij Cat6A. Cat7 lijkt me vrij lomp; pas er maar 1 van door een loze leiding en voegt qua snelheid weinig toe; immers kan Cat6 op afstanden tot ~35m ook wel 10gbit aan wat voor de meeste huizen prima is.

[Toppe]

Geen idee of ik hier welkom ben met mijn vraag maar mijn andere topic (aankoop advies) is niet relevant meer

Sinds gister een USG neer gezet, na wat stoeien (adoption failed meerdere keren) alles werkend gekregen, ik zie nu alleen nog maar 3 van de 10 bedrade apparaten die ik gister nog wel zag.

Ik mis bijvoorbeeld mijn Ikea & Hue Bridge en een IP camera.

Ben er 100% zeker van dat deze gewoon werken en verbonden zijn, ik zie namelijk de live-stream prima en ook de lampen reageren prima.

Er staan in de software geen filters aan dus dat kan het ook niet zijn.

Sowieso is die IP camera wel een beetje vreemd want die zit fixed op .22 (opgegeven in de controler, en dat werkt) terwijl de controller gister bleef aangeven dat hij op .108 zit

Iemand een idee?

[Laagheim]

@Toppe Vertel even hoe je netwerkje in elkaar zit en wat voor switches, modems etc je hebt. Dan kunnen we wat beter vertellen wat het probleem is (overigens 9 van de 10 keer dat zo'n soort probleem langs komt ligt het aan een ziggo horizon ding dus als je die hebt dan is dat het probleem 😄)

[Toppe]

Laagheim schreef op donderdag 18 april 2019 @ 08:27:
@Toppe Vertel even hoe je netwerkje in elkaar zit en wat voor switches, modems etc je hebt. Dan kunnen we wat beter vertellen wat het probleem is (overigens 9 van de 10 keer dat zo'n soort probleem langs komt ligt het aan een ziggo horizon ding dus als je die hebt dan is dat het probleem 😄)

FTU -> USG -> TP-Link (unmanaged) switch -> apparaten

De USG dient dus als modem

Gek genoeg zag ik net weer meer apparaten, het wisselt dus nogal sterk. De controller draait op een Pi

Opzich geen hele vreemde configuratie dus

[ Voor 3% gewijzigd door Toppe op 18-04-2019 08:42 ]

[Jeroen V]

MisteRMeesteR schreef op woensdag 17 april 2019 @ 23:00:
[...]

Hoeveel hebben we al naar jouw opstelling zitten staren me z’n allen?

Nog niet vaak genoeg? En mocht ik weer nieuw speelgoed hebben van Ubiquiti dan zal ik zeker weer een update plaatsen... (de rackmount voor de CK staat al in bestelling )

MisteRMeesteR schreef op woensdag 17 april 2019 @ 23:00:Hier glas tussen de routers en switches, puur omdat het kan en ‘mooier’ is

[Afbeelding]

Mooi spul, ziet er netjes uit!

Het punt wat ik meer probeerde te maken is dat ik weinig meerwaarde zie in de opstellingen met 1 Gbit die wij hebben van fiber tov CAT5/6. Leuk om naar te kijken, maar naar mijn mening merk je er niets van. Bij 10GBit is het ietsje anders, maar ook daar is fiber niet echt noodzakelijk. Ik heb zelf maar 1 machine die ik niet met een DAC kan doen omdat de afstand te groot is (ongeveer 10M) de rest staat vrijwel naast elkaar en dus heeft fiber ook daar weinig meerwaarde. De reden dat ik nu toch fiber heb is dat ik een 20-pack 10GBit transceivers op de kop kon tikken voor 150,- euro en ik het mooi vind, anders hadden er nog steeds de DAC's tussen gezeten...

[rens-br]

Toppe schreef op donderdag 18 april 2019 @ 07:07:
Ik zie nu alleen nog maar 3 van de 10 bedrade apparaten die ik gister nog wel zag.

Toppe schreef op donderdag 18 april 2019 @ 08:36:
FTU -> USG -> TP-Link (unmanaged) switch -> apparaten

Ik heb ook zo'n opstelling en ik zie ook niet altijd al mijn apparaten in het bedrade netwerk. Ik maak zelf gebruik van twee semi-managed TP-Link switches en die staan bijna nooit in het overzicht.

Sowieso is die IP camera wel een beetje vreemd want die zit fixed op .22 (opgegeven in de controler, en dat werkt) terwijl de controller gister bleef aangeven dat hij op .108 zit

Camera al een keer gereboot? Die krijgt pas een nieuw ip-adres wanneer de lease verloopt of hij via een reboot een nieuw ip krijgt toegewezen.

[RobertMe]

Toppe schreef op donderdag 18 april 2019 @ 08:36:
[...]


FTU -> USG -> TP-Link (unmanaged) switch -> apparaten

De USG dient dus als modem

Gek genoeg zag ik net weer meer apparaten, het wisselt dus nogal sterk. De controller draait op een Pi

Opzich geen hele vreemde configuratie dus

Je hebt dus alleen de USG en mogelijk wat UAPs? Bedrade apparaten die niet met internet verbinden zullen dan inderdaad niet snel in de Controller verschijnen lijkt mij. Dat omdat het verkeer dus ook maar zelden de USG (of UAPs) zal passeren. Wil je apparaten dus wel continu zien in de Controller zul je dus ook nog je switch(es) moeten vervangen

[Toppe]

rens-br schreef op donderdag 18 april 2019 @ 08:52:
[...]


[...]


Ik heb ook zo'n opstelling en ik zie ook niet altijd al mijn apparaten in het bedrade netwerk. Ik maak zelf gebruik van twee semi-managed TP-Link switches en die staan bijna nooit in het overzicht.


[...]


Camera al een keer gereboot? Die krijgt pas een nieuw ip-adres wanneer de lease verloopt of hij via een reboot een nieuw ip krijgt toegewezen.

Yes, alles een keer opnieuw opgestart en ik kan ook alle apparaten gewoon benaderen, zie ze alleen niet in het overzicht terug.

RobertMe schreef op donderdag 18 april 2019 @ 08:59:
[...]

Je hebt dus alleen de USG en mogelijk wat UAPs? Bedrade apparaten die niet met internet verbinden zullen dan inderdaad niet snel in de Controller verschijnen lijkt mij. Dat omdat het verkeer dus ook maar zelden de USG (of UAPs) zal passeren. Wil je apparaten dus wel continu zien in de Controller zul je dus ook nog je switch(es) moeten vervangen

Wil ik ze dus in mijn overzicht hebben moet ik een nieuwe switch kopen? Geloof dat dat me een beetje ver gaat eigelijk.

[rens-br]

Toppe schreef op donderdag 18 april 2019 @ 09:23:
Wil ik ze dus in mijn overzicht hebben moet ik een nieuwe switch kopen? Geloof dat dat me een beetje ver gaat eigelijk.

Ja, dat kan ik mij voorstellen en ik weet ook niet 100% zeker of het daar aan ligt.

[Toppe]

rens-br schreef op donderdag 18 april 2019 @ 09:30:
[...]


Ja, dat kan ik mij voorstellen en ik weet ook niet 100% zeker of het daar aan ligt.

Ergens zou het gek zijn omdat het verkeer altijd via de USG loopt, toch?

Moet wel toegeven: het was even een pain-in-the-ass om aan te sluiten. Vrouwlief kon niet zonder internet verbinding en ik kon niet wachten, uiteindelijk vrouwlief maar op een hotspot gezet zodat ik de rest in werking kon gaan zetten.

Maar voor nu draait het, heb alles maar even snel toegevoegd in het netwerk en vanmiddag wil ik de boel goed gaan inregelen, apparaten vaste IP adressen geven etc

[ Voor 41% gewijzigd door Toppe op 18-04-2019 09:32 ]

[rens-br]

Toppe schreef op donderdag 18 april 2019 @ 09:30:
Ergens zou het gek zijn omdat het verkeer altijd via de USG loopt, toch?

Dat verwacht ik wel, maar ik zit niet goed in te materie om die logica erachter de weten / begrijpen.

Moet wel toegeven: het was even een pain-in-the-ass om aan te sluiten. Vrouwlief kon niet zonder internet verbinding en ik kon niet wachten, uiteindelijk vrouwlief maar op een hotspot gezet zodat ik de rest in werking kon gaan zetten.

Ja even 'vlug', 'vlug' instellen is er meestal niet bij. Ik heb het ding ook bewust geïnstalleerd toen vrouwlief niet thuis was.

[RnB]

Ik heb sinds een firmware upgrade van mijn AP een gek probleem met mijn UniFi spul.

Na deze firmware upgrade komt mijn Cloud Key (gen 1 en gen 2 plus) in een bootloop terecht omdat PoE de powertoevoer steeds onderbreekt. Op de momenten dat PoE de powertoevoer onderbreekt, reboot mijn AP ook.

De bootloop van mijn Cloud Key is de ene keer te stoppen door de AP fysiek te disconnecten van mijn switch, maar niet altijd. Omdat deze de laatste keer niet uit de loop te halen was, heb ik een PoE injector gebruikt om mijn Cloud Key op aan te sluiten. Na deze aanpassing werkt alles naar behoren.

Het gekke is, deze spullen hebben een paar weken prima gedraaid, met de Cloud Key en de AP gevoed door PoE van de switch. Na een firmware upgrade, krijg ik het niet meer werkend. Ook niet meer na een dowgrade.

In de logs kan ik helaas geen PoE gerelateerde lines terug vinden, dus ik tast een beetje in het duister wat er aan de hand is.

Ik heb deze issues al op het Ubiquiti Community forum geplaatst, maar ik heb al gezien dat ze niet snel reageren. De enige reactie die ik tot nu toe heb gehad, is dat de firmware upgrade geen invloed op PoE zou moeten hebben:

That's realling interesting!

re PoE issue.

Since this test release is strictly AAA and wireless uplink/downlink - there should be no effect on PoE at all.

Iemand enig idee wat ik zou kunnen doen om dit probleem te fixen?

Mijn netwerk ziet er alsvolgt uit:

KPN FTU -- USG Pro --- USW 16 150 --- AP AC HD & Cloud Key

[ Voor 3% gewijzigd door RnB op 18-04-2019 09:42 ]

[MensionXL]

Weet iemand of het mogelijk is om de beacon interval aan te passen op de AP AC PRO/AP-AC LITE/AP AC LR?

Meer dan de DTIM period lijkt niet te kunnen namelijk. Of mis ik iets?

[RobertMe]

Toppe schreef op donderdag 18 april 2019 @ 09:30:
[...]


Ergens zou het gek zijn omdat het verkeer altijd via de USG loopt, toch?

Nee, niet alle verkeer gaat via de USG. Verkeer neemt de kortste route. Dus verkeer binnen je eigen netwerk (/hetzelfde (V)LAN) gaat alleen over de switches heen. De USG is ook alleen de router binnen je netwerk, en verkeer dat binnen hetzelfde netwerk blijft hoeft ook niet gerouteerd te worden.

Wat er technisch gebeurd is:

1. Je PC wil verbinding maken met je NAS (bv). Dit is IP 192.168.1.100 (PC) naar 192.168.1.101 (NAS)
2. Je PC zoekt in zijn lokale routing tabellen op hoe 192.168.1.101 te bereiken. Dit blijkt rechtstreeks te kunnen over de netwerkkaart (met IP 192.168.1.100)
3. Je PC achterhaald het MAC adres behorende bij 192.168.1.101, dit kan of in het ARP cache zitten of via ARP (broadcast) worden achterhaald
4. Je PC stuurt een ethernet pakket naar buiten naar het MAC adres van de NAS
5. Dit ethernet pakket word ontvangen door een switch
6. De switch kijkt in een lokaal cache via welke poort dit MAC bereikbaar is en stuurt het pakketje op die poort naar buiten
7. (tussenliggende switches hetzelfde als hierboven)
8. Het pakketje komt bij de NAS aan

Bij stap 6 is het alleen zo dat als de switch het MAC adres niet kent deze het pakketje op alle poorten uit stuurt (en bij een reply / pakketje vanaf dat MAC adres weet de switch ook op welke poort dat MAC adres zich bevind).

Onder normale omstandigheden (waarbij IP => MAC adres en poort behorende tot MAC adres bekend is) zal het verkeer dus ook nooit bij de USG aankomen. Alleen in het geval van een ARP request (broadcast) of het ontbreken van het MAC adres in de switch (waarbij het op alle poorten wordt uitgestuurd) zal verkeer binnen je lokale netwerk de USG passeren.

En in het geval van internet verkeer staat in je routing table van je bv PC dat voor onbekende IP adressen de default route gebruikt wordt en dat betekend dat het verkeer naar de USG wordt gestuurd

En bv de devices die je noemt zoals de Ikea & Hue Bridge zijn ook apparaten die niet super veel via internet (hoeven) te werken. Daardoor zal er ook niet veel verkeer gegenereerd worden, wat de USG passeerd.

[kevinl]

MisteRMeesteR schreef op woensdag 17 april 2019 @ 23:00:
[...]

Hoeveel hebben we al naar jouw opstelling zitten staren me z’n allen?

Hier glas tussen de routers en switches, puur omdat het kan en ‘mooier’ is

[Afbeelding]

Twee vraagjes:
1. Hoe heten die utp poort afdekstompjes?
2. Je gebruikt de lan poort in je USG 4Pro niet. Heb je de tweede wanport met LAG aan je switch gekoppeld? Zodat het lan verkeer daar over gaat? Ik neem aan dat de FTU rechtstreeks naar je USG 4Pro gaat.

[Comp User]

kevinl schreef op donderdag 18 april 2019 @ 10:17:
[...]


Twee vraagjes:
1. Hoe heten die utp poort afdekstompjes?

Die dopjes worden "Blindstops" genoemd.

[rens-br]

kevinl schreef op donderdag 18 april 2019 @ 10:17:
Twee vraagjes:
1. Hoe heten die utp poort afdekstompjes?

Blindstopjes inderdaad.

[ChiLLeR]

Helaas geeft Ubiquity aan om mijn Switch RMA aan te bieden. Op het UB forum geeft iedereen aan om de 24Poorts te kopen ipv de 16 omdat het probleem vrijwel zeker op bijna alle 16 poorts aanwezig is. Helaas is de 24 poorts eentje die erg veel lawaai maakt wat in mijn meterkast geen goed idee is.

Ik kan natuurlijk een andere managed switch kopen maar ik vind het juist zo mooi dat alles gecontrolled kan worden binnen Unify.

[Jeroen V]

ChiLLeR schreef op donderdag 18 april 2019 @ 11:31:
Helaas geeft Ubiquity aan om mijn Switch RMA aan te bieden. Op het UB forum geeft iedereen aan om de 24Poorts te kopen ipv de 16 omdat het probleem vrijwel zeker op bijna alle 16 poorts aanwezig is. Helaas is de 24 poorts eentje die erg veel lawaai maakt wat in mijn meterkast geen goed idee is.

Ik kan natuurlijk een andere managed switch kopen maar ik vind het juist zo mooi dat alles gecontrolled kan worden binnen Unify.

Als je het niet vervelend vindt kan je ook de fans vervangen, dan schijnt dat ding een stuk stiller te zijn...

Hier heb je wat informatie waar je misschien wat aan hebt:

[HKLM_]

ChiLLeR schreef op donderdag 18 april 2019 @ 11:31:
Helaas geeft Ubiquity aan om mijn Switch RMA aan te bieden. Op het UB forum geeft iedereen aan om de 24Poorts te kopen ipv de 16 omdat het probleem vrijwel zeker op bijna alle 16 poorts aanwezig is. Helaas is de 24 poorts eentje die erg veel lawaai maakt wat in mijn meterkast geen goed idee is.

Ik kan natuurlijk een andere managed switch kopen maar ik vind het juist zo mooi dat alles gecontrolled kan worden binnen Unify.

Gaat dit nog steeds om dat warmte probleem? (uitvallen / reboot)

[kevinl]

ChiLLeR schreef op donderdag 18 april 2019 @ 11:31:
Helaas geeft Ubiquity aan om mijn Switch RMA aan te bieden. Op het UB forum geeft iedereen aan om de 24Poorts te kopen ipv de 16 omdat het probleem vrijwel zeker op bijna alle 16 poorts aanwezig is. Helaas is de 24 poorts eentje die erg veel lawaai maakt wat in mijn meterkast geen goed idee is.

Ik kan natuurlijk een andere managed switch kopen maar ik vind het juist zo mooi dat alles gecontrolled kan worden binnen Unify.

Heb je meerdere poe appartuur aan die switch hangen?

[SchumiFAST]

Ik heb recent van Unify een USG en access points gekocht en een switch komt eraan.

De ISP is Telenet en die hebben een modem en router in één apparaat met ook IPTV erbij. De decoder voor IPTV heeft een eigen kabel van de meterkast naar de woonkamer en kan dus volledig onafhankelijk van het netwerk om te internetten worden aangesloten.

Ik lees wat tegenstrijdige berichten over de aansluiting:
Sommige mensen zeggen dat ik gewoon de USG achter de Telenet modem+router mag aansluiten, i.e.
Telenet modem+router --> USG --> switch --> clients
Sommige mensen zeggen dat je geen twee routers in het netwerk mag plaatsen en je best aan Telenet kan vragen om de routerfunctie uit te schakelen (bridge). Anderen (waaronder de techniekers van Telenet) zeggen dat de setup met twee routers geen probleem vormt.

Wat is wijsheid? Moet ik het gewoon proberen? Welke problemen kunnen er eventueel optreden?


Alvast bedankt

[HKLM_]

SchumiFAST schreef op donderdag 18 april 2019 @ 12:07:
Ik heb recent van Unify een USG en access points gekocht en een switch komt eraan.

De ISP is Telenet en die hebben een modem en router in één apparaat met ook IPTV erbij. De decoder voor IPTV heeft een eigen kabel van de meterkast naar de woonkamer en kan dus volledig onafhankelijk van het netwerk om te internetten worden aangesloten.

Ik lees wat tegenstrijdige berichten over de aansluiting:
Sommige mensen zeggen dat ik gewoon de USG achter de Telenet modem+router mag aansluiten, i.e.
Telenet modem+router --> USG --> switch --> clients
Sommige mensen zeggen dat je geen twee routers in het netwerk mag plaatsen en je best aan Telenet kan vragen om de routerfunctie uit te schakelen (bridge). Anderen (waaronder de techniekers van Telenet) zeggen dat de setup met twee routers geen probleem vormt.

Wat is wijsheid? Moet ik het gewoon proberen? Welke problemen kunnen er eventueel optreden?


Alvast bedankt

Als je twee routers hebt zul op 1 DHCP moeten uitschakelen omdat dit issues geeft als je er twee hebt. En je hebt last van dubbel NAT dus in bridge mode is de beste en netste oplossing.

[RobertMe]

SchumiFAST schreef op donderdag 18 april 2019 @ 12:07:
Ik heb recent van Unify een USG en access points gekocht en een switch komt eraan.

De ISP is Telenet en die hebben een modem en router in één apparaat met ook IPTV erbij. De decoder voor IPTV heeft een eigen kabel van de meterkast naar de woonkamer en kan dus volledig onafhankelijk van het netwerk om te internetten worden aangesloten.

Ik lees wat tegenstrijdige berichten over de aansluiting:
Sommige mensen zeggen dat ik gewoon de USG achter de Telenet modem+router mag aansluiten, i.e.
Telenet modem+router --> USG --> switch --> clients
Sommige mensen zeggen dat je geen twee routers in het netwerk mag plaatsen en je best aan Telenet kan vragen om de routerfunctie uit te schakelen (bridge). Anderen (waaronder de techniekers van Telenet) zeggen dat de setup met twee routers geen probleem vormt.

Wat is wijsheid? Moet ik het gewoon proberen? Welke problemen kunnen er eventueel optreden?


Alvast bedankt

Technisch kun je router achter router gewoon werkent krijgen. Waar je alleen op moet letten zijn:

• Gebruik van niet conficterende IP ranges (als je Telenet 192.168.1.0/24 als subnet gebruikt kan je USG dus niet ook 192.168.1.X gebruiken)
• Port forwards moet je dubbel instellen (Telenet modem => USG en USG => end device), of als dat kan in Telenet modem een DMZ instellen naar de USG

Als je Telenet modem in bridge kan is dat dus ook een optie en krijgt je USG een publiek IP en gaat dus per definitie alle verkeer naar de USG. Conflicterende IP ranges en dubbel instellen van port forwards is dan dus niet meer aan de orde.
Echter weet ik niet of je in jouw situatie het Telenet modem in bridge kunt zetten. Aangezien IPTV dus ook nog eens apart over het modem gaat.

[Broodro0ster]

HKLM_ schreef op donderdag 18 april 2019 @ 12:10:
[...]


Als je twee routers hebt zul op 1 DHCP moeten uitschakelen omdat dit issues geeft als je er twee hebt. En je hebt last van dubbel NAT dus in bridge mode is de beste en netste oplossing.

Helaas kun je het niet uitschakelen op de Telenet router

SchumiFAST schreef op donderdag 18 april 2019 @ 12:07:
Ik heb recent van Unify een USG en access points gekocht en een switch komt eraan.

De ISP is Telenet en die hebben een modem en router in één apparaat met ook IPTV erbij. De decoder voor IPTV heeft een eigen kabel van de meterkast naar de woonkamer en kan dus volledig onafhankelijk van het netwerk om te internetten worden aangesloten.

Ik lees wat tegenstrijdige berichten over de aansluiting:
Sommige mensen zeggen dat ik gewoon de USG achter de Telenet modem+router mag aansluiten, i.e.
Telenet modem+router --> USG --> switch --> clients
Sommige mensen zeggen dat je geen twee routers in het netwerk mag plaatsen en je best aan Telenet kan vragen om de routerfunctie uit te schakelen (bridge). Anderen (waaronder de techniekers van Telenet) zeggen dat de setup met twee routers geen probleem vormt.

Wat is wijsheid? Moet ik het gewoon proberen? Welke problemen kunnen er eventueel optreden?


Alvast bedankt

Ik heb dezelfde setup als jou, maar dan ook met Unifi switches.
Mijn Telenet router verzorgt het netwerk 192.168.0.1/24 en de USG 192.168.1.1/24.
Mijn USG heeft een static IP op zijn WAN interface en staat in het DMZ van de Telenet router. Op die manier hoef je geen dubbele portforwards te doen en kan je alles beheren op de USG.

Als je een extra kabel hebt voor de Digicorder, is het inderdaad het makkelijkst om die gewoon in de Telenet router te prikken.
Ik heb zelf maar 1 kabel die naar mijn TV kast gaat, maar met managed switches en VLAN's kan je het boeltje werkend krijgen. Dit is de makkelijkste manier om het dan te doen: https://imgur.com/a/rNS9Jkh

[Falcon10]

Ah, is het VLAN 20 dat telenet gebruikt voor ze'n IPTV toestanden ?

Waarom sluit je trouwens die kabel van de telenet router niet rechtstreeks op je WAN port van je USG en zet deze in DHCP ? Ben je geen 2 poorten kwijt op je eerste switch voor het doorsteken van de router.

[ChiLLeR]

HKLM_ schreef op donderdag 18 april 2019 @ 11:54:
[...]


Gaat dit nog steeds om dat warmte probleem? (uitvallen / reboot)

Het is niet zeker of het warmte gerelateerd is, in ieder geval vallen de poorten weg in de switch na een foutmelding thermal reading. Ubiquity heeft geen idee waar het door komt en heeft er geen oplossing voor.

[Wafeltje]

ChiLLeR schreef op donderdag 18 april 2019 @ 13:40:
[...]

Het is niet zeker of het warmte gerelateerd is, in ieder geval vallen de poorten weg in de switch na een foutmelding thermal reading. Ubiquity heeft geen idee waar het door komt en heeft er geen oplossing voor.

Ik had een soortgelijk iets, maar na fans met de hand te hebben ingesteld leek het probleem minder vaak voor te komen (elke paar weken ipv elke paar minuten), en na een firmware update was het weg.

Omdat ik poorten te kort kwam, heb ik uiteindelijk toch de overstap gemaakt naar een 24 poorts (en om dat deze op de milimeternauwkeurig tóch bleek te passen ). Daarbij heb ik het probleem nooit meer gehad.
Voor wat betreft de herrie van deze switch: Ik heb m direct na het uit de doos halen voorzien van 2 nieuwe fans. De schroeven die er bij zaten paste niet lekker, maar met een paar boutjes/moertjes die ik nog had liggen kwam ik een heel eind! (let er op dat je wel verzonken kop hebt op je boutjes, anders kan de kap er niet meer goed op.

Hij hangt bij ons in de meterkast, en de watermeter maakt soms meer lawaai dan de switch. Ik hoor hem in ieder geval alleen als ik er op let, en nog nooit heeft iemand gevraagd wat dat gezoem is (zelfs mijn vrouw niet)

[HKLM_]

Wafeltje schreef op donderdag 18 april 2019 @ 13:50:
[...]


Ik had een soortgelijk iets, maar na fans met de hand te hebben ingesteld leek het probleem minder vaak voor te komen (elke paar weken ipv elke paar minuten), en na een firmware update was het weg.

Omdat ik poorten te kort kwam, heb ik uiteindelijk toch de overstap gemaakt naar een 24 poorts (en om dat deze op de milimeternauwkeurig tóch bleek te passen ). Daarbij heb ik het probleem nooit meer gehad.
Voor wat betreft de herrie van deze switch: Ik heb m direct na het uit de doos halen voorzien van 2 nieuwe fans. De schroeven die er bij zaten paste niet lekker, maar met een paar boutjes/moertjes die ik nog had liggen kwam ik een heel eind! (let er op dat je wel verzonken kop hebt op je boutjes, anders kan de kap er niet meer goed op.

Hij hangt bij ons in de meterkast, en de watermeter maakt soms meer lawaai dan de switch. Ik hoor hem in ieder geval alleen als ik er op let, en nog nooit heeft iemand gevraagd wat dat gezoem is (zelfs mijn vrouw niet)

Hoe heb je de fans op de 16-150 zelf ingesteld fan controle is toch niet meer beschikbaar

[Wafeltje]

HKLM_ schreef op donderdag 18 april 2019 @ 14:01:
[...]


Hoe heb je de fans op de 16-150 zelf ingesteld fan controle is toch niet meer beschikbaar

Klopt, was ook mn workarround tot ik de firmware geüpdatet had.

[HKLM_]

Wafeltje schreef op donderdag 18 april 2019 @ 14:19:
[...]


Klopt, was ook mn workarround tot ik de firmware geüpdatet had.

Hopelijk komt de fan control feature nog een keer terug.... ik zou de fans best op de laagste stand willen laten draaien.

[SchumiFAST]

HKLM_ schreef op donderdag 18 april 2019 @ 12:10:
[...]


Als je twee routers hebt zul op 1 DHCP moeten uitschakelen omdat dit issues geeft als je er twee hebt. En je hebt last van dubbel NAT dus in bridge mode is de beste en netste oplossing.

RobertMe schreef op donderdag 18 april 2019 @ 12:14:
[...]

Technisch kun je router achter router gewoon werkent krijgen. Waar je alleen op moet letten zijn:

• Gebruik van niet conficterende IP ranges (als je Telenet 192.168.1.0/24 als subnet gebruikt kan je USG dus niet ook 192.168.1.X gebruiken)
• Port forwards moet je dubbel instellen (Telenet modem => USG en USG => end device), of als dat kan in Telenet modem een DMZ instellen naar de USG

Als je Telenet modem in bridge kan is dat dus ook een optie en krijgt je USG een publiek IP en gaat dus per definitie alle verkeer naar de USG. Conflicterende IP ranges en dubbel instellen van port forwards is dan dus niet meer aan de orde.
Echter weet ik niet of je in jouw situatie het Telenet modem in bridge kunt zetten. Aangezien IPTV dus ook nog eens apart over het modem gaat.

Broodro0ster schreef op donderdag 18 april 2019 @ 12:23:
[...]

Helaas kun je het niet uitschakelen op de Telenet router


[...]


Ik heb dezelfde setup als jou, maar dan ook met Unifi switches.
Mijn Telenet router verzorgt het netwerk 192.168.0.1/24 en de USG 192.168.1.1/24.
Mijn USG heeft een static IP op zijn WAN interface en staat in het DMZ van de Telenet router. Op die manier hoef je geen dubbele portforwards te doen en kan je alles beheren op de USG.

Als je een extra kabel hebt voor de Digicorder, is het inderdaad het makkelijkst om die gewoon in de Telenet router te prikken.
Ik heb zelf maar 1 kabel die naar mijn TV kast gaat, maar met managed switches en VLAN's kan je het boeltje werkend krijgen. Dit is de makkelijkste manier om het dan te doen: https://imgur.com/a/rNS9Jkh

Bedankt voor de antwoorden.

Of de Telenet moden+router effectief in bridge kan ingesteld worden weet ik niet. De resultaten op internet zijn nogal tegenstrijdig daarover. Wat wel eenduidig wordt aangeraden is het vervangen van de modem+router van Telenet door een modem only (ander toestel) als je je eigen router wil gebruiken.

Ik ga voorlopig de manier van Broodrooster proberen en later een modem-only vragen eens ik verhuisd ben.

[MisteRMeesteR]

kevinl schreef op donderdag 18 april 2019 @ 10:17:
[...]


Twee vraagjes:
1. Hoe heten die utp poort afdekstompjes?
2. Je gebruikt de lan poort in je USG 4Pro niet. Heb je de tweede wanport met LAG aan je switch gekoppeld? Zodat het lan verkeer daar over gaat? Ik neem aan dat de FTU rechtstreeks naar je USG 4Pro gaat.

1. Reeds beantwoord
2. Ik heb VVDSL thuis en gebruik de Cisco onderin als VVDSL modem in bridge voor het internet verkeer en als IGMP proxy voor mijn IPTV verkeer. De USG is dus gewoon internet router / firewall / VPN gateway etc.etc.

De 2e WAN poort staat als LAN ingesteld en is geen LAG (want maar 1 interface) maar een trunk naar de US-24-250W toe.

ChiLLeR schreef op donderdag 18 april 2019 @ 11:31:
Helaas geeft Ubiquity aan om mijn Switch RMA aan te bieden. Op het UB forum geeft iedereen aan om de 24Poorts te kopen ipv de 16 omdat het probleem vrijwel zeker op bijna alle 16 poorts aanwezig is. Helaas is de 24 poorts eentje die erg veel lawaai maakt wat in mijn meterkast geen goed idee is.

Ik kan natuurlijk een andere managed switch kopen maar ik vind het juist zo mooi dat alles gecontrolled kan worden binnen Unify.

Ik heb destijds de 2 herriemakers in mijn US-24-250W ook vervangen, destijds ook een post van gemaakt:

MisteRMeesteR in "[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 2"

[kevinl]

Iemand hier een AC in-wall in bezit?

Ik lees op fora ene keer wel en andere keren niet dat de interne switch managed is.
In dit topic is gezegd dat het niet managed is.

Kan iemand dat hier bevestigen wat waar is?

Ik stond op het punt een te halen. Maar nu twijfel ik.

[Gophlin]

kevinl schreef op donderdag 18 april 2019 @ 15:28:
Iemand hier een AC in-wall in bezit?

Ik lees op fora ene keer wel en andere keren niet dat de interne switch managed is.
In dit topic is gezegd dat het niet managed is.

Kan iemand dat hier bevestigen wat waar is?

Ik stond op het punt een te halen. Maar nu twijfel ik.

Hier heb ik een AP-AC In-Wall en die is managed in ieder geval.

[RobertMe]

Inhakende op de AC IW discussie. Ik meen hier ook eens gelezen te hebben dat het gebruik van de PoE passthrough poort zonder PoE apparaat aangesloten de hele PoE keten stopzet waardoor het AP dus uit gaat. Klopt dit? Of kun je wel gewoon beide poorten gebruiken met alleen een data apparaat aangesloten?

[The-Priest-NL]

RobertMe schreef op donderdag 18 april 2019 @ 17:03:
Inhakende op de AC IW discussie. Ik meen hier ook eens gelezen te hebben dat het gebruik van de PoE passthrough poort zonder PoE apparaat aangesloten de hele PoE keten stopzet waardoor het AP dus uit gaat. Klopt dit? Of kun je wel gewoon beide poorten gebruiken met alleen een data apparaat aangesloten?

Kan ik ff testen als mensen dit 100% zeker willen weten.

[Corvo]

The-Priest-NL schreef op donderdag 18 april 2019 @ 17:42:
[...]

Kan ik ff testen als mensen dit 100% zeker willen weten.

Als je wilt, dan graag.
Ik overweeg 2x AC In-Wall en 1x In-Wall HD aan te schaffen. De ethernet poorten ga ik ook gebruiken, maar uiteraard met apparatuur die niet PoE is.

[Toppe]

Ik probeer de VPN te installeren maar krijg met geen mogelijkheid verbinding.

De RADIUS server is ingeschakeld, de server staat aan en onder users een nieuwe gebruiker gemaakt met tunnel type 3 (L2TP) en tunnel medium type 1 (IPv4), VLAN is leeg.

Onder netwerken een nieuw netwerk gemaakt met als type "Remote User VPN" en L2TP server. Nieuw subnet ingevoerd (192.168.2.1/24 ipv 192.168.1.1/24). Name server staat op auto en WINS & Site-to-site staan beide uit. Als profiel heb ik RADIUS default.

Als ik een port scan doe dan lijken de poorten dicht te zitten maar ook via het lokale netwerk kan ik geen VPN starten, ik krijg simpel weg de melding dat de server niet reageert...

Iemand een idee?

[job]

RobertMe schreef op donderdag 18 april 2019 @ 17:03:
Inhakende op de AC IW discussie. Ik meen hier ook eens gelezen te hebben dat het gebruik van de PoE passthrough poort zonder PoE apparaat aangesloten de hele PoE keten stopzet waardoor het AP dus uit gaat. Klopt dit? Of kun je wel gewoon beide poorten gebruiken met alleen een data apparaat aangesloten?

Ik heb twee AC IW's in gebruik die aangesloten is op de unifi 8 poorts 60W.
Van beide AC IW's gebruik ik beide poorten. Geen van de aangesloten apparaten doet aan poe.
Nul problemen.

Moet ik nog iets testen?

Mijn IW's worden gevoed via 802.3af
Met 802.3at heb ik geen ervaring.

[ Voor 8% gewijzigd door job op 18-04-2019 19:50 ]

[RobertMe]

job schreef op donderdag 18 april 2019 @ 19:49:
[...]

Ik heb twee AC IW's in gebruik die aangesloten is op de unifi 8 poorts 60W.
Van beide AC IW's gebruik ik beide poorten. Geen van de aangesloten apparaten doet aan poe.
Nul problemen.

Moet ik nog iets testen?

Mijn IW's worden gevoed via 802.3af
Met 802.3at heb ik geen ervaring.

Volgens mij was het inderdaad zo simpel als jij stelt. Alleen in dat geval dat het aansluiten van ik meen een laptop op de PoE passthrough poort meteen de PoE toevoer van de switch naar het AP deed stopzetten. Case closed dus wat mij betreft.

802.3af vs 802.3at maakt denk ik ook niet uit. Want ondanks dat de IW officieel 802.3at vereist in combinatie met gebruik van PoE passthrough werkt de passthrough ook als je het AP maar op 802.3af aansluit, zolang het totale verbruik maar onder de 15W blijft. Dus zal ook niet zo zijn dat hardwarematig de passthrough is uitgeschakeld als het AP maar via 802.3af wordt gevoed.

[kevinl]

job schreef op donderdag 18 april 2019 @ 19:49:
[...]

Ik heb twee AC IW's in gebruik die aangesloten is op de unifi 8 poorts 60W.
Van beide AC IW's gebruik ik beide poorten. Geen van de aangesloten apparaten doet aan poe.
Nul problemen.

Moet ik nog iets testen?

Mijn IW's worden gevoed via 802.3af
Met 802.3at heb ik geen ervaring.

Jij kan ook bevestigen dat die iw een managed swith is. Echt raar dat drie webshops zeggen dat er geen managed switch in zit.

[RobertMe]

kevinl schreef op donderdag 18 april 2019 @ 20:51:
[...]


Jij kan ook bevestigen dat die iw een managed swith is. Echt raar dat drie webshops zeggen dat er geen managed switch in zit.

Ik meen dat dat een hele tijd terug ook zo was, dat je de switch niet kon managen en het gewoon trunks waren. Later hebben ze dit dan aangepast (in de firmware neem ik aan, nieuwe revisie hardware is me niet bekend).
Maar zoals duidelijk mag zijn heb ik geen IW dus uitsluitsel geven kan ik niet.

[borft]

Toppe schreef op donderdag 18 april 2019 @ 19:34:
Ik probeer de VPN te installeren maar krijg met geen mogelijkheid verbinding.

De RADIUS server is ingeschakeld, de server staat aan en onder users een nieuwe gebruiker gemaakt met tunnel type 3 (L2TP) en tunnel medium type 1 (IPv4), VLAN is leeg.

Onder netwerken een nieuw netwerk gemaakt met als type "Remote User VPN" en L2TP server. Nieuw subnet ingevoerd (192.168.2.1/24 ipv 192.168.1.1/24). Name server staat op auto en WINS & Site-to-site staan beide uit. Als profiel heb ik RADIUS default.

Als ik een port scan doe dan lijken de poorten dicht te zitten maar ook via het lokale netwerk kan ik geen VPN starten, ik krijg simpel weg de melding dat de server niet reageert...

Iemand een idee?

Van binnen het netwerk ewrkt het bij mij ook niet. Volgens mij werkt het over UDP, dus met een TCP portscan ga je die porten niet vinden. Met wat voor client probeer je te verbinden?

Check anders op je GW even met `ipsec status`

[job]

kevinl schreef op donderdag 18 april 2019 @ 20:51:
Jij kan ook bevestigen dat die iw een managed swith is. Echt raar dat drie webshops zeggen dat er geen managed switch in zit.

Managed zou ik het niet noemen. De functies die je kan wijzigen zijn beperkt.
Geen Qos, geen aggregation.

Enige bijzondere wat kan is een vlan aan een poort toewijzen, en zover ik kan vinden ook maar echt 1 vlan per poort. Ik gebruik zelf geen vlans, en vind dat net even te werk om even uit te testen.

[ Voor 12% gewijzigd door job op 18-04-2019 23:50 ]

[Will_M]

borft schreef op donderdag 18 april 2019 @ 21:11:
[...]


Van binnen het netwerk ewrkt het bij mij ook niet. Volgens mij werkt het over UDP, dus met een TCP portscan ga je die porten niet vinden. Met wat voor client probeer je te verbinden?

Check anders op je GW even met `ipsec status`

Waarom denk je dat? UDP verkeer is verkeer wat "niet belangrijk" is en derhalve dan ook nooit een re-transmit zal gaan krijgen zoals TCP verkeer dat per definitie wél krijgt.

Het opzetten van een VPN sessie lijkt me iets waarbij je dus TCP protocollen gaat volgen, wat je daarna IN die tunnel verder gaat doen ......

[Prx]

wimmel_1 schreef op donderdag 18 april 2019 @ 21:49:
[...]

Het opzetten van een VPN sessie lijkt me iets waarbij je dus TCP protocollen gaat volgen, wat je daarna IN die tunnel verder gaat doen ......

If your USG's WAN is behind NAT and has a private IP, it is necessary to configure port forwarding on the upstream router to forward UDP ports 500, 1701, and 4500 to the USG's WAN address.
https://help.ubnt.com/hc/...ng-L2TP-Remote-Access-VPN

Het gebruik van UDP voor je tunnel is niet gek, want het verkeer wat je daarna door je tunnel heen gaat stampen is vaak dus wel TCP. Die regelt dus zelf wel de re-transmit waarbij je tunnel alleen het verkeer af dient te handelen. Anders krijg je een dubbele re-transmit bij veel verkeer. Het is mogelijk, maar kan impact hebben op o.a. performance.

[Will_M]

Prx schreef op donderdag 18 april 2019 @ 21:56:
[...]


[...]


Het gebruik van UDP voor je tunnel is niet gek, want het verkeer wat je daarna door je tunnel heen gaat stampen is vaak dus wel TCP. Die regelt dus zelf wel de re-transmit waarbij je tunnel alleen het verkeer af dient te handelen. Anders krijg je een dubbele re-transmit bij veel verkeer. Het is mogelijk, maar kan impact hebben op o.a. performance.

Jij hebt het nu over de tunnel ansich, het opzetten van de tunnel is het eigenlijke issue (voor zover ik uit de huidige conversatie begrijp)

[RobertMe]

wimmel_1 schreef op donderdag 18 april 2019 @ 21:49:
[...]


Waarom denk je dat? UDP verkeer is verkeer wat "niet belangrijk" is en derhalve dan ook nooit een re-transmit zal gaan krijgen zoals TCP verkeer dat per definitie wél krijgt.

Het opzetten van een VPN sessie lijkt me iets waarbij je dus TCP protocollen gaat volgen, wat je daarna IN die tunnel verder gaat doen ......

Het gebruik van TCP maakt het ook meteen langzamer omdat overal een acknowledge op moet komen. Daarnaast kun je ook in UDP eender welke vorm van acks/retransmissions inbouwen. Als je een authenticatie verzoek stuurt en er komt binnen X milliseconde geen reactie kun je ook het verzoek opnieuw sturen, bv.

Kijk ook naar 'het web'. Vrij essentieel dat alle data aankomt dus HTTP gebruikt TCP. Vervolgens is Google nu bezig met een alternatief, QUIC, dat op UDP draait. Met een goede uitwerking kan UDP sneller werken met dezelfde zekerheden.

[Prx]

wimmel_1 schreef op donderdag 18 april 2019 @ 22:00:
[...]


Jij hebt het nu over de tunnel ansich, het opzetten van de tunnel is het eigenlijke issue (voor zover ik uit de huidige conversatie begrijp)

Maar dat is dus ook allemaal UDP. Er komt hier totaal geen TCP aan te pas, wat inderdaad een TCP scan nutteloos maakt. Anders zouden er ook TCP poorten open moeten om de verbinding op te kunnen zetten.

[nero355]

kevinl schreef op donderdag 18 april 2019 @ 15:28:
Iemand hier een AC in-wall in bezit?

Ik lees op fora ene keer wel en andere keren niet dat de interne switch managed is.
In dit topic is gezegd dat het niet managed is.

Kan iemand dat hier bevestigen wat waar is?

Ik stond op het punt een te halen. Maar nu twijfel ik.

De In-Wall AC is geweldig! Ik heb er 3 en ik wil niet meer iets anders!

US 16 PoE+ -> AC In-Wall via PoE+ -> US 8 via PoE

En hier en daar hangt er een client aan de non-PoE Data poort!

RobertMe schreef op donderdag 18 april 2019 @ 17:03:
Inhakende op de AC IW discussie. Ik meen hier ook eens gelezen te hebben dat het gebruik van de PoE passthrough poort zonder PoE apparaat aangesloten de hele PoE keten stopzet waardoor het AP dus uit gaat. Klopt dit? Of kun je wel gewoon beide poorten gebruiken met alleen een data apparaat aangesloten?

De laatste keer dat ik dit per ongeluk heb gedaan ging die inderdaad uit!

Maar dat is alweer een tijdje geleden dus ik ga eens kijken of ik dat effe opnieuw kan testen...

Corvo schreef op donderdag 18 april 2019 @ 18:58:
Als je wilt, dan graag.
Ik overweeg 2x AC In-Wall en 1x In-Wall HD aan te schaffen. De ethernet poorten ga ik ook gebruiken, maar uiteraard met apparatuur die niet PoE is.

De HD versie heb ik niet, maar de gewone basis versie kan ik voor je testen

wimmel_1 schreef op donderdag 18 april 2019 @ 21:49:
Waarom denk je dat? UDP verkeer is verkeer wat "niet belangrijk" is en derhalve dan ook nooit een re-transmit zal gaan krijgen zoals TCP verkeer dat per definitie wél krijgt.

Het opzetten van een VPN sessie lijkt me iets waarbij je dus TCP protocollen gaat volgen, wat je daarna IN die tunnel verder gaat doen......

En toen hadden we OpenVPN dat standaard UDP poort 1194 gebruikt, tenzij je het zelf omzet naar TCP
De reden : Speeeed!!!

RobertMe schreef op donderdag 18 april 2019 @ 22:23:
Kijk ook naar 'het web'. Vrij essentieel dat alle data aankomt dus HTTP gebruikt TCP. Vervolgens is Google nu bezig met een alternatief, QUIC, dat op UDP draait. Met een goede uitwerking kan UDP sneller werken met dezelfde zekerheden.

De enige reden dat Google QUIC heeft geintroduceerd is om jou nog sneller reclames voor te kunnen schotelen en ze op deze manier ook moeilijker blokkeerbaar te maken!

Kortom : Zet die meuk overal uit samen met nog een aantal ellendige opties die hetzelfde doel hebben!

[ardvark99]

RobertMe schreef op donderdag 18 april 2019 @ 17:03:
Inhakende op de AC IW discussie. Ik meen hier ook eens gelezen te hebben dat het gebruik van de PoE passthrough poort zonder PoE apparaat aangesloten de hele PoE keten stopzet waardoor het AP dus uit gaat. Klopt dit? Of kun je wel gewoon beide poorten gebruiken met alleen een data apparaat aangesloten?

Ik heb thuis een AC IW, gevoed door 802.3at (USW16p). Ik gebruik de poorten standaard niet.

Maar ik weet dat poort 1 (POE passthrough) met sommige netwerk adaptors problemen geeft. Ik heb een Lenovo laptop, wanneer ik die bekabeld aansluit, gaat de In-Wall in een soort sluiting status staan, het ledje knippert af en toe heel kort wit, de controller geeft aan heartbeat missing. Deze laptop blijft ook connected op de WiFi, van een andere AP natuurlijk.
Totdat ik de kabel weer los trek. Dan start de In-Wall weer opnieuw op. Op de andere poort geen probleem met die laptop. Ik heb zelfs geprobeerd met een profiel waarbij POE uitgeschakeld zou zijn, helpt ook niet. (geeft waarschijnlijk al aan hoe managed dat switchje is, zover ik weet is alleen de Vlan te managen)

Met een andere laptop, een Dell, heb ik geen problemen met de passthrough poort. Waar het nu precies aan ligt weet ik niet.

[Toppe]

@borft @wimmel_1 @Prx @RobertMe

Ik kwam dit tegen in de handleiding vanuit UniFI zelf:

Setting up L2TP will auto add firewall rules to WAN Local in Settings > Routing & Firewall, no manual rules are required on the user end.

Die USG is tevens het modem zelf, dus ik zou die poorten niet handmatig moeten open zetten lijkt me. In dat geval blijft de vraag waarom ik er niet bij kan, ook niet via m'n iPhone en 4G.

Het lijkt me dat als ik iets fout gedaan zou hebben bij de RADIUS server (ondanks dat de configuratie hiervan ook vrij simpel lijkt) je een foutmelding zou moeten krijgen met de gebruikersgegevens..??

[rens-br]

RobertMe schreef op donderdag 18 april 2019 @ 17:03:
Inhakende op de AC IW discussie. Ik meen hier ook eens gelezen te hebben dat het gebruik van de PoE passthrough poort zonder PoE apparaat aangesloten de hele PoE keten stopzet waardoor het AP dus uit gaat. Klopt dit? Of kun je wel gewoon beide poorten gebruiken met alleen een data apparaat aangesloten?

Ik heb vorig jaar bij mijn ouders drie van die dingen opgehangen en ik heb de poorten gewoon gebruikt, daarbij niet gelet of het POE poort of niet was, dus volgens mij hebben ze dit tegenwoordig via firmware opgevangen. En het werkt daar dus perfect.

Toppe schreef op donderdag 18 april 2019 @ 19:34:
Ik probeer de VPN te installeren maar krijg met geen mogelijkheid verbinding.

De RADIUS server is ingeschakeld, de server staat aan en onder users een nieuwe gebruiker gemaakt met tunnel type 3 (L2TP) en tunnel medium type 1 (IPv4), VLAN is leeg.

Onder netwerken een nieuw netwerk gemaakt met als type "Remote User VPN" en L2TP server. Nieuw subnet ingevoerd (192.168.2.1/24 ipv 192.168.1.1/24). Name server staat op auto en WINS & Site-to-site staan beide uit. Als profiel heb ik RADIUS default. Iemand een idee?

Ik neem aan dat je eerst dit hebt gedaan en daarna deze guide hebt gevolgd?

Ik heb dat ook zo ingesteld en dat werkt hier prima. Ik moet echter wel zeggen dat het pas echt goed werkte na een volledige herstart van de USG, dus als je dat nog niet gedaan hebt kan ik het je aanraden.

Daarnaast neem ik aan dat je verbinding probeert te maken met het WAN-IP?

[RobertMe]

ardvark99 schreef op donderdag 18 april 2019 @ 23:56:
[...]

Ik heb thuis een AC IW, gevoed door 802.3at (USW16p). Ik gebruik de poorten standaard niet.

Maar ik weet dat poort 1 (POE passthrough) met sommige netwerk adaptors problemen geeft. Ik heb een Lenovo laptop, wanneer ik die bekabeld aansluit, gaat de In-Wall in een soort sluiting status staan, het ledje knippert af en toe heel kort wit, de controller geeft aan heartbeat missing. Deze laptop blijft ook connected op de WiFi, van een andere AP natuurlijk.
Totdat ik de kabel weer los trek. Dan start de In-Wall weer opnieuw op. Op de andere poort geen probleem met die laptop. Ik heb zelfs geprobeerd met een profiel waarbij POE uitgeschakeld zou zijn, helpt ook niet. (geeft waarschijnlijk al aan hoe managed dat switchje is, zover ik weet is alleen de Vlan te managen)

Met een andere laptop, een Dell, heb ik geen problemen met de passthrough poort. Waar het nu precies aan ligt weet ik niet.

Je zou bijna gaan overwegen om de standaarden door te lezen. Ik zou bijna zeggen dat de PoE negotiation een optie heeft om aan te geven dat je geen PoE ondersteund/geleverd wilt krijgen, en dat dat in dit geval PoE vanaf de achterliggende switch uitschakelt. Waar andere/de meeste apparaten de volledige PoE negotiation negeren waardoor PoE dan wel nog steeds geleverd wordt aan de IW.

[borft]

wimmel_1 schreef op donderdag 18 april 2019 @ 21:49:
[...]


Waarom denk je dat? UDP verkeer is verkeer wat "niet belangrijk" is en derhalve dan ook nooit een re-transmit zal gaan krijgen zoals TCP verkeer dat per definitie wél krijgt.

Het opzetten van een VPN sessie lijkt me iets waarbij je dus TCP protocollen gaat volgen, wat je daarna IN die tunnel verder gaat doen ......

UDP is helemaal niet verkeer dat niet belangrijk is. Het is ook geen verkeer dat geen retransmits heeft. Het feit dat het niet in het protocol zelf afgehandeld wordt, betekent niet dat het niet in de laag daarboven kan gebeuren (zoals bv TCP doet).

Ik heb even op mijn USG gecheckt:

code:

charon     6910  6926       root   10u     IPv6           31761872      0t0        UDP *:isakmp 
charon     6910  6926       root   11u     IPv6           31761873      0t0        UDP *:4500 
charon     6910  6926       root   12u     IPv4           31761874      0t0        UDP *:isakmp 
charon     6910  6926       root   13u     IPv4           31761875      0t0        UDP *:4500

maar nogmaals, check even met sudo ipsec status of er daadwerkelijk wat draait. De l2tp+ipsec stack is 2 lagen. Er wordt eerst een ipsec verbinding opgezet, hier wordt een pre shared key voor gebruikt. Als dat gelukt is, wordt over die verbinding de l2tp opgezet, deze gebruikt user/pass authenticatie dmv radius.

Oftewel, als de ipsec verbinding niet lukt, kom je uberhaupt niet aan radius toe.

Wat betreft firewall rules, ik zie onder firewall -> wan local dat er wel degelijk porten zijn opengezet door Unifi. Er zijn 4 rules mbt l2tp.

[Toppe]

borft schreef op vrijdag 19 april 2019 @ 09:55:
[...]


UDP is helemaal niet verkeer dat niet belangrijk is. Het is ook geen verkeer dat geen retransmits heeft. Het feit dat het niet in het protocol zelf afgehandeld wordt, betekent niet dat het niet in de laag daarboven kan gebeuren (zoals bv TCP doet).

Ik heb even op mijn USG gecheckt:

code:

charon     6910  6926       root   10u     IPv6           31761872      0t0        UDP *:isakmp 
charon     6910  6926       root   11u     IPv6           31761873      0t0        UDP *:4500 
charon     6910  6926       root   12u     IPv4           31761874      0t0        UDP *:isakmp 
charon     6910  6926       root   13u     IPv4           31761875      0t0        UDP *:4500

maar nogmaals, check even met sudo ipsec status of er daadwerkelijk wat draait. De l2tp+ipsec stack is 2 lagen. Er wordt eerst een ipsec verbinding opgezet, hier wordt een pre shared key voor gebruikt. Als dat gelukt is, wordt over die verbinding de l2tp opgezet, deze gebruikt user/pass authenticatie dmv radius.

Oftewel, als de ipsec verbinding niet lukt, kom je uberhaupt niet aan radius toe.

Wat betreft firewall rules, ik zie onder firewall -> wan local dat er wel degelijk porten zijn opengezet door Unifi. Er zijn 4 rules mbt l2tp.

Ik zal thuis eens even lekker SSH'n

[rens-br]

borft schreef op vrijdag 19 april 2019 @ 09:55:
Wat betreft firewall rules, ik zie onder firewall -> wan local dat er wel degelijk porten zijn opengezet door Unifi. Er zijn 4 rules mbt l2tp.

Er worden ook wel poorten open gezet, maar de Controller doet dat automatisch en dat hoef je dus niet met de hand te doen.

[Toppe]

borft schreef op vrijdag 19 april 2019 @ 09:55:
[...]


UDP is helemaal niet verkeer dat niet belangrijk is. Het is ook geen verkeer dat geen retransmits heeft. Het feit dat het niet in het protocol zelf afgehandeld wordt, betekent niet dat het niet in de laag daarboven kan gebeuren (zoals bv TCP doet).

Ik heb even op mijn USG gecheckt:

code:

charon     6910  6926       root   10u     IPv6           31761872      0t0        UDP *:isakmp 
charon     6910  6926       root   11u     IPv6           31761873      0t0        UDP *:4500 
charon     6910  6926       root   12u     IPv4           31761874      0t0        UDP *:isakmp 
charon     6910  6926       root   13u     IPv4           31761875      0t0        UDP *:4500

maar nogmaals, check even met sudo ipsec status of er daadwerkelijk wat draait. De l2tp+ipsec stack is 2 lagen. Er wordt eerst een ipsec verbinding opgezet, hier wordt een pre shared key voor gebruikt. Als dat gelukt is, wordt over die verbinding de l2tp opgezet, deze gebruikt user/pass authenticatie dmv radius.

Oftewel, als de ipsec verbinding niet lukt, kom je uberhaupt niet aan radius toe.

Wat betreft firewall rules, ik zie onder firewall -> wan local dat er wel degelijk porten zijn opengezet door Unifi. Er zijn 4 rules mbt l2tp.

Met sudo ipsec status krijg ik 0 reactie...

[RobertMe]

Toppe schreef op vrijdag 19 april 2019 @ 16:21:
[...]


Met sudo ipsec status krijg ik 0 reactie...

Als ik het mij goed herinner was dat een vorm van logging van wat nu gebeurd. Dus dat proces blijft draaien. Als je vervolgens dus probeert de verbinding op te zetten zie je real-time de logs daar verschijnen.

[Toppe]

RobertMe schreef op vrijdag 19 april 2019 @ 16:30:
[...]

Als ik het mij goed herinner was dat een vorm van logging van wat nu gebeurd. Dus dat proces blijft draaien. Als je vervolgens dus probeert de verbinding op te zetten zie je real-time de logs daar verschijnen.

Er gebeurt niets:

code:

admins@USG:~$ sudo ipsec status
admins@USG:~$

Maar IPSec lijkt überhaupt niet te draaien:

code:

admins@USG:~$ show vpn ipsec status
IPSec Process NOT Running

admins@USG:~$

Edit: even het VPN profiel van de iPhone gegooid en opnieuw toegevoegd, werkt nu vreemd genoeg wel

[ Voor 9% gewijzigd door Toppe op 19-04-2019 16:45 ]

[RobertMe]

Toppe schreef op vrijdag 19 april 2019 @ 16:34:
[...]


Er gebeurt niets:

code:

admins@USG:~$ sudo ipsec status
admins@USG:~$

Zo te zien was het commando wat ik dacht dat het was sudo swanctl --log. Deze blijft wel draaien en logt "real-time" wat er gebeurd. sudo ipsec status geeft inderdaad alleen status output (of dan blijkbaar helemaal niks als er niks verbonden is)

[Toppe]

RobertMe schreef op vrijdag 19 april 2019 @ 16:47:
[...]

Zo te zien was het commando wat ik dacht dat het was sudo swanctl --log. Deze blijft wel draaien en logt "real-time" wat er gebeurd. sudo ipsec status geeft inderdaad alleen status output (of dan blijkbaar helemaal niks als er niks verbonden is)

Tijdens het verbinden krijg je wel wat info te zien...

Nu alleen nog even kijken waarom ik geen actieve VPN verbindingen zie in de controller terwijl die er wel zijn

Edit:

Ik: Currently I'm seeing my own VPN in the overview. It took only 30 minutes before it shows up, is that normal?
UniFI: Yes, that's normal.

Vindt dat toch wel erg lang, dat het nou een seconde of 30 duurt oke, maar 30 minuten...

[ Voor 17% gewijzigd door Toppe op 19-04-2019 17:37 ]

[vanputten80]

Na herstart van mijn Unifi Wifi AC, 8port switch en USG krijgen mijn devices geen ip adres meer. Tv doet het wel.
Heb de systemen gereset mbv een tandenstoker.

Ik had IDS aanstaan deze heb ik uitgeschakeld, na herstart popt dit probleem op.

- Op een pc staat de controller software. Deze direct aangesloten op USG. Geen ip.
- handmatig ip gegeven, geen succes
- Guest wifi doet het ook niet.

Wat kan ik doen?

Edit:
Met de laptop en dan bekabeld, niet eerder verbonden, krijg ik wel verbinding. Enkel een IP adres maar geen internet.
Ik kan wel naar de USG pagina gaan, met de waarschuwing geen internet.
SSH naar switch kan ook maar weet niet wat ik moet doen.

Edit 2
Alles losgekoppeld ,ook de USG. Op een moment kreeg de pc met Unifi een ip-adres . Daarmee wifi en switch kunnen toevoegen.
USG heeft geen internet en krijgt ook geen verbinding (ook niet wanneer kabel direct verbonden is).
USG verwijderd uit Unifi en daarna weer toegevoegd, gelijk is het IP adres verdwenen van de pc en krijgt hij er ook geen 1 meer.
Morgen weer verder zoeken

[ Voor 45% gewijzigd door vanputten80 op 20-04-2019 00:19 ]

[ericafterdark]

Wat is momenteel best practice om de UniFi Controller Software naar een andere server in mijn LAN te verplaatsen? Of kan ik beter een keer vanaf scratch beginnen. Misschien ook niet verkeerd na al dat gerommel van mij de laatste tijd

[RobertMe]

Eiríkr schreef op zaterdag 20 april 2019 @ 08:34:
Wat is momenteel best practice om de UniFi Controller Software naar een andere server in mijn LAN te verplaatsen? Of kan ik beter een keer vanaf scratch beginnen. Misschien ook niet verkeerd na al dat gerommel van mij de laatste tijd

Settings (=> Site) => Export site. Evt. kun je van daaruit ook alleen de backup hergebruiken en die in de nieuwe controller importeren (een van de eerste dingen die controller setup vraagt of je backup wilt importeren). Anders kun je vanuit de Export site wizard ook meteen de inform URL laten aanpassen bij alle devices. Toen ik in het begin mijn UniFi Controller van laptop "als test" naar NAS / thuisserver (definitief) heb verplaatst was aanpassen inform niet nodig, maar ik had die ook nooit aangepast.

Als je from scratch wilt beginnen moet je wel eerst alle devices verwijderen/vergeten uit de huidige controller. Anders kun je ze niet importeren in de nieuwe controller en moet je ze een factory reset geven (of via SSH of via reset knopje).

[d-vine]

vanputten80 schreef op vrijdag 19 april 2019 @ 21:33:
Na herstart van mijn Unifi Wifi AC, 8port switch en USG krijgen mijn devices geen ip adres meer. Tv doet het wel.
Heb de systemen gereset mbv een tandenstoker.

Ik had IDS aanstaan deze heb ik uitgeschakeld, na herstart popt dit probleem op.

- Op een pc staat de controller software. Deze direct aangesloten op USG. Geen ip.
- handmatig ip gegeven, geen succes
- Guest wifi doet het ook niet.

Wat kan ik doen?

Edit:
Met de laptop en dan bekabeld, niet eerder verbonden, krijg ik wel verbinding. Enkel een IP adres maar geen internet.
Ik kan wel naar de USG pagina gaan, met de waarschuwing geen internet.
SSH naar switch kan ook maar weet niet wat ik moet doen.

Edit 2
Alles losgekoppeld ,ook de USG. Op een moment kreeg de pc met Unifi een ip-adres . Daarmee wifi en switch kunnen toevoegen.
USG heeft geen internet en krijgt ook geen verbinding (ook niet wanneer kabel direct verbonden is).
USG verwijderd uit Unifi en daarna weer toegevoegd, gelijk is het IP adres verdwenen van de pc en krijgt hij er ook geen 1 meer.
Morgen weer verder zoeken

Ik heb ook een keer gehad dat mijn USG geen internet kreeg en geen ip uitdeelde (na FW upgrade)
Na 2x power eraf en erop was alles weer in orde.

[Falcon10]

Zonet even een leuke upgrade van de CLoudkey Gen2+ gedaan :



5Tb schijfje erin, en we hebben nu iets meer opslag voor onze Protect

Ik heb deze how-to gevolgd :

YouTube: Cloud Key Gen2 5TB HDD Upgrade

Halfweg het filmpje, zegt ie dus nog eens dat hij vergeten de Unifi Network backup te nemen was, en die moet je dus hebben om erna de Unifi Network settings van je spul terug te zetten, anders wortd het een gans nieuwe setup
De Protect is raar genoeg wel zonder een restore vanzelf in orde.

Ik ga het boeltje nu even een weekje gewoon terug op deze manier laten draaien, voordat ik de laatste updates van de devices ga doen ( just to make sure )

Makkelijke update eigenlijk.Fans vervangen in de switchen duurt langer

[Jeroen V]

Falcon10 schreef op zaterdag 20 april 2019 @ 11:23:
Halfweg het filmpje, zegt ie dus nog eens dat hij vergeten de Unifi Network backup te nemen was, en die moet je dus hebben om erna de Unifi Network settings van je spul terug te zetten, anders wortd het een gans nieuwe setup

Euh, das maf, dat had ik niet verwacht. Ik zou eerder denken dat deze settings op de eMMC storage terecht zou komen... (en de HDD puur voor opnames gebruikt zouden worden)

[vanputten80]

d-vine schreef op zaterdag 20 april 2019 @ 08:44:
[...]


Ik heb ook een keer gehad dat mijn USG geen internet kreeg en geen ip uitdeelde (na FW upgrade)
Na 2x power eraf en erop was alles weer in orde.

Heb uiteindelijk nieuwe site aangemaakt en alles opnieuw ingesteld. Nu werkt het weer super. Geen enkel idee wat het probleem was.

[Will_M]

Falcon10 schreef op zaterdag 20 april 2019 @ 11:23:
Zonet even een leuke upgrade van de CLoudkey Gen2+ gedaan :

[Afbeelding]

5Tb schijfje erin, en we hebben nu iets meer opslag voor onze Protect

Ik heb deze how-to gevolgd :

YouTube: Cloud Key Gen2 5TB HDD Upgrade

Halfweg het filmpje, zegt ie dus nog eens dat hij vergeten de Unifi Network backup te nemen was, en die moet je dus hebben om erna de Unifi Network settings van je spul terug te zetten, anders wortd het een gans nieuwe setup
De Protect is raar genoeg wel zonder een restore vanzelf in orde.

Ik ga het boeltje nu even een weekje gewoon terug op deze manier laten draaien, voordat ik de laatste updates van de devices ga doen ( just to make sure )

Makkelijke update eigenlijk.Fans vervangen in de switchen duurt langer

Je hebt per camera ± 1TB aan opslag nodig als je je beelden een maand wilt bewaren voordat ze automatisch overschreven gaan worden.

Ik ben hier overigens sinds de voorlaatste update van de software ineens spontaan verlost van de "reconnect" meldingen vanuit de Protect software (0.9.11 is inmiddels uit).

[Falcon10]

wimmel_1 schreef op zaterdag 20 april 2019 @ 17:20:
[...]

Je hebt per camera ± 1TB aan opslag nodig als je je beelden een maand wilt bewaren voordat ze automatisch overschreven gaan worden.

Momenteel 6 Ubiquiti cameras, dus zal inderdaad iets minder als een maandje zijn

[HKLM_]

ChiLLeR schreef op donderdag 18 april 2019 @ 13:40:
[...]

Het is niet zeker of het warmte gerelateerd is, in ieder geval vallen de poorten weg in de switch na een foutmelding thermal reading. Ubiquity heeft geen idee waar het door komt en heeft er geen oplossing voor.

Log jij alles naar een syslog server? Ik heb sinds dat de 16-150w op firmware 4.0.30.10217 (daarvoor geen last i.i.g) zit al twee x gehad dat mijn Switch reboot / de POE er uit knikkerde... Als ik tail -f /var/log/messages doe zie ik alleen het opstart proces de rest gaat zeker weer verloren

[ Voor 3% gewijzigd door HKLM_ op 20-04-2019 18:13 ]

[kevinl]

Falcon10 schreef op zaterdag 20 april 2019 @ 11:23:
Zonet even een leuke upgrade van de CLoudkey Gen2+ gedaan :

[Afbeelding]

5Tb schijfje erin, en we hebben nu iets meer opslag voor onze Protect

Ik heb deze how-to gevolgd :

YouTube: Cloud Key Gen2 5TB HDD Upgrade

Halfweg het filmpje, zegt ie dus nog eens dat hij vergeten de Unifi Network backup te nemen was, en die moet je dus hebben om erna de Unifi Network settings van je spul terug te zetten, anders wortd het een gans nieuwe setup
De Protect is raar genoeg wel zonder een restore vanzelf in orde.

Ik ga het boeltje nu even een weekje gewoon terug op deze manier laten draaien, voordat ik de laatste updates van de devices ga doen ( just to make sure )

Makkelijke update eigenlijk.Fans vervangen in de switchen duurt langer

Welke 5tb heb je gehaald?

[Falcon10]

kevinl schreef op zaterdag 20 april 2019 @ 18:23:
[...]

Welke 5tb heb je gehaald?

Deze :



Seagate BackupPlus 5 Tb.

5 Tb disk eruit, en in de Cloudkey.
Goedkoper dan de 5 Tb zonder behuizing te kopen.

[kevinl]

Falcon10 schreef op zaterdag 20 april 2019 @ 18:54:
[...]


Deze :

[Afbeelding]

Seagate BackupPlus 5 Tb.

5 Tb disk eruit, en in de Cloudkey.
Goedkoper dan de 5 Tb zonder behuizing te kopen.

125 euro. Alleen geen garantie meer...