[Ubiquiti-Netwerkapparatuur] Ervaringen & Discussie - Deel 4

[Bruzski]

Falcon10 schreef op dinsdag 5 januari 2021 @ 06:33:
[...]


Dat zwarte opvulunit stuk onder je onderste Unifi vervangen door zo'n opvulstuk met borstels waar je de kabels kan doorvoeren ?

[Afbeelding]

dank voor de tip, ik ga eens kijken of dat wat is.

[MasterMaceMichu]

Mijn collectie Unifi gear groeit gestaag en inmiddels heb ik niet voldoende plek meer om alles in de meterkast te herbergen. Idee is dus om een deel naar de zolder te verhuizen. Omdat ik dan sowieso boven iets van een nieuwe switch moet hebben (en omdat het kan), wil ik het gelijk goed doen en een 10G 'backbone' maken naar boven.

Om dit te doen wil ik 2x de UniFi Switch Aggregation aanschaffen, één beneden en één boven. Ik ben echter benieuwd of ik ook daadwerkelijk de beoogde snelheid zal halen tussen deze switches en niet terug ga vallen op 'normaal' gigabit snelheid.

Overal in huis ligt Cat6 kabel en ik blijf ook netjes binnen de 30 meter kabel, dus theoretisch zou het moeten werken, echter 2 keer een 'patch-through', dus kabel zal van de USA naar patchpaneel in de meterkast (keystone op keystone) gaan, dan naar boven en daar uit muur patch verder met Cat6 naar de USA.

Iemand ervaring met een vergelijkbare situatie?

[ANdrode]

MasterMaceMichu schreef op woensdag 6 januari 2021 @ 20:14:
Overal in huis ligt Cat6 kabel en ik blijf ook netjes binnen de 30 meter kabel, dus theoretisch zou het moeten werken, echter 2 keer een 'patch-through', dus kabel zal van de USA naar patchpaneel in de meterkast (keystone op keystone) gaan, dan naar boven en daar uit muur patch verder met Cat6 naar de USA.

Iemand ervaring met een vergelijkbare situatie?

Dat is toch precies de situatie waar 10GBASE-T voor ontworpen is? Het lijkt mij dat SFPs daar mee overweg moeten kunnen.

[RobertMe]

MasterMaceMichu schreef op woensdag 6 januari 2021 @ 20:14:
Mijn collectie Unifi gear groeit gestaag en inmiddels heb ik niet voldoende plek meer om alles in de meterkast te herbergen. Idee is dus om een deel naar de zolder te verhuizen. Omdat ik dan sowieso boven iets van een nieuwe switch moet hebben (en omdat het kan), wil ik het gelijk goed doen en een 10G 'backbone' maken naar boven.

Om dit te doen wil ik 2x de UniFi Switch Aggregation aanschaffen, één beneden en één boven. Ik ben echter benieuwd of ik ook daadwerkelijk de beoogde snelheid zal halen tussen deze switches en niet terug ga vallen op 'normaal' gigabit snelheid.

Overal in huis ligt Cat6 kabel en ik blijf ook netjes binnen de 30 meter kabel, dus theoretisch zou het moeten werken, echter 2 keer een 'patch-through', dus kabel zal van de USA naar patchpaneel in de meterkast (keystone op keystone) gaan, dan naar boven en daar uit muur patch verder met Cat6 naar de USA.

Iemand ervaring met een vergelijkbare situatie?

Geen ervaring mee, maar hoe wil je de boel precies gaan aansluiten? Naar mijn idee is de Switch Aggregation meer bedoeld als echte core switch waar je er dom gezegd "zo min mogelijk" van plaatst en ook geen end devices op aansluit. Gevoelsmatig is deze switch veel meer bedoeld voor: Je hebt een router, daar hang je de Switch Aggregation achter, en verder door het (kantoor) pand / bedrijfshal / ... plaats je dan weer allemaal "normale" switches en daarop sluit je de end devices (PCs, APs, ...) aan.

In jouw geval zou ik dan eerder voor twee gewone switches gaan met SFP+, maar volgens mij kom je bij de nieuwe (/Gen 2) switches dan wel bij de Pro modellen uit en minimaal de Pro 24 (E3xx uit mijn hoofd, of de Pro 24 PoE met PoE support, maar die is wel "ietsjes" duurder met ik meen E7xx).

Vergeet overigens ook niet dat de Switch Aggregation niet "plug & play" is. Deze bevat dus alleen SFP+ poorten dus als je gewoon CAT wilt aansluiten heb je een SFP+ RJ45 module nodig. En eerlijk gezegd, als je dan toch over the top wilt gaan, pak dan 2x een SFP+ BiDi glasvezel module en trek glasvezel. Zeker als je toch al twee SFP+ modules moet aanschaffen zal dat het geld niet kosten. Simplex glasvezel is voor een paar euro te krijgen op fs.com.

[MasterMaceMichu]

ANdrode schreef op woensdag 6 januari 2021 @ 20:56:
[...]


Dat is toch precies de situatie waar 10GBASE-T voor ontworpen is? Het lijkt mij dat SFPs daar mee overweg moeten kunnen.

Soms heb je even wat extra beverstiging nodig...

[MasterMaceMichu]

RobertMe schreef op woensdag 6 januari 2021 @ 21:04:
[...]

Geen ervaring mee, maar hoe wil je de boel precies gaan aansluiten? Naar mijn idee is de Switch Aggregation meer bedoeld als echte core switch waar je er dom gezegd "zo min mogelijk" van plaatst en ook geen end devices op aansluit. Gevoelsmatig is deze switch veel meer bedoeld voor: Je hebt een router, daar hang je de Switch Aggregation achter, en verder door het (kantoor) pand / bedrijfshal / ... plaats je dan weer allemaal "normale" switches en daarop sluit je de end devices (PCs, APs, ...) aan.

In jouw geval zou ik dan eerder voor twee gewone switches gaan met SFP+, maar volgens mij kom je bij de nieuwe (/Gen 2) switches dan wel bij de Pro modellen uit en minimaal de Pro 24 (E3xx uit mijn hoofd, of de Pro 24 PoE met PoE support, maar die is wel "ietsjes" duurder met ik meen E7xx).

Vergeet overigens ook niet dat de Switch Aggregation niet "plug & play" is. Deze bevat dus alleen SFP+ poorten dus als je gewoon CAT wilt aansluiten heb je een SFP+ RJ45 module nodig. En eerlijk gezegd, als je dan toch over the top wilt gaan, pak dan 2x een SFP+ BiDi glasvezel module en trek glasvezel. Zeker als je toch al twee SFP+ modules moet aanschaffen zal dat het geld niet kosten. Simplex glasvezel is voor een paar euro te krijgen op fs.com.

Dat dacht ik dus eerst ook, maar na een internet zoektochtje blijken deze prima als switch in te zetten.

Heb ook naar de 'echte' switches zitten kijken, maar dat is een stuk duurder. Bovendien kan ik zo mijn File/Plex/DAS server voluit mee laten doen (dubbele 10G).

Glas zou een optie kunnen zijn, maar de modules liggen voor het grijpen...

[RobertMe]

MasterMaceMichu schreef op woensdag 6 januari 2021 @ 21:30:
[...]

Dat dacht ik dus eerst ook, maar na een internet zoektochtje blijken deze prima als switch in te zetten.

Het blijft dan natuurlijk ook een switch. Dus dat die zijn werk doet geloof ik wel maar blijft natuurlijk een Ubiquiti product . Alleen is dit natuurlijk niet de use case waarvoor het ding gemaakt is. Als die wel gemaakt was voor end devices hadden er ook wel RJ45 poorten op gezeten i.p.v. SFP+.

Heb ook naar de 'echte' switches zitten kijken, maar dat is een stuk duurder. Bovendien kan ik zo mijn File/Plex/DAS server voluit mee laten doen (dubbele 10G).

Dat van die prijs van de Pro switches valt zeer zeker niet te ontkennen. En als je 2x 10Gbit/s naar NAS wilt doen + tussen twee switches heb je IIRC maar één optie, de Pro 48 (of ja, twee opties, de Pro 48 PoE). Die heeft als enige 4x SFP+, de overige maar 2x.

Glas zou een optie kunnen zijn, maar de modules liggen voor het grijpen...

Ik neem aan dat je dan al RJ45 modules hebt? Want kostentechnisch denk ik dat RJ45 vs BiDi glasvezel SFP+ niet veel uit zal maken (IIRC betaalde ik toen ik dit zelf heb gedaan met glasvezel iets van 8 & 10 euro voor de BiDi SFP (geen + dus) modules, kan me dus niet indenken dat RJ45 zoveel goedkoper is / BiDi duur is).

[Behoorlijk Leek]

[quote]ed1703 schreef op dinsdag 5 januari 2021 @ 14:56:
[...]

vziw zijn met nieuwere firmware de laatste issues met snooping opgelost. Deze is ook beschikbaar voor de 8- en 16-lite. Dit gaat om USW Firmware 5.43.18.12487.
- [USW] Disable IGMP header validation to fix IPTV issues.


Inderdaad, ik had met caiway in mijn usg3p vlan 101 ingesteld om iptv te kunnen kijken wat wel voor een erg trage up en down zorgde, na teug zetten naar vlan 100 werkt het weer perfect.

[MasterMaceMichu]

RobertMe schreef op woensdag 6 januari 2021 @ 22:58:
Ik neem aan dat je dan al RJ45 modules hebt? Want kostentechnisch denk ik dat RJ45 vs BiDi glasvezel SFP+ niet veel uit zal maken (IIRC betaalde ik toen ik dit zelf heb gedaan met glasvezel iets van 8 & 10 euro voor de BiDi SFP (geen + dus) modules, kan me dus niet indenken dat RJ45 zoveel goedkoper is / BiDi duur is).

Duik ik in. Heb echter zoveel moeite gehad om de ethernet kabels op de zolder te krijgen (doorvoer buizen tijdens de bouw met de Franse slag aangelegd), dat ik niet het risico wil nemen dat ik die niet door de buizen krijg, want om te passen moet er sowieso één buis leeg...

[Gert456]

Valderrama schreef op dinsdag 5 januari 2021 @ 13:20:
[...]


Ik heb deze 16 Port gen 2 Switch op een plank liggen met een USG erop, rechts ervan een cloud key gen 2 en daar weer rechts van een Raspberry Pi4. Ik vind de gen 2 Switch eigenlijk helemaal niet warm aanvoelen.

Wil wel de USG binnenkort gaan vervangen en het liefst zet ik de apparatuur dan in een (niet al te duur) simpel rack frame. Het hoeft niet fancy te zijn, het ligt nu toch op een plank op elkaar maar in zo’n frame kan ik de kabels wat mooier wegwerken en wellicht scheelt het ook weer een paar graadjes. Heb nog niet een niet al te prijzig leuk frame gevonden.

Kijk eens bij Thomann.
Ik heb zelf een Millennium wall rack.

[Cagdas]

*knip*. Vragen over deuren zijn hier een beetje offtopic

[ Voor 92% gewijzigd door rens-br op 07-01-2021 10:48 ]

[Arunia]

@_Arthur Dank je. Ik heb het eens omgezet. Alleen de Transmit waarde stond bij ons op auto.
We gaan eens kijken of dat wat verhelpt. Anders ga ik wel terug naar de versie die eerder is aangehaald.

[RobertMe]

MasterMaceMichu schreef op donderdag 7 januari 2021 @ 09:34:
[...]

Duik ik in. Heb echter zoveel moeite gehad om de ethernet kabels op de zolder te krijgen (doorvoer buizen tijdens de bouw met de Franse slag aangelegd), dat ik niet het risico wil nemen dat ik die niet door de buizen krijg, want om te passen moet er sowieso één buis leeg...

Uiteraard is het ook geen verplichting om glasvezel te gebruiken. Maar als je twee van deze switches wilt plaatsen lijkt het voor mij een gevalletje "geld speelt geen rol ik wil het over the top doen". Glasvezel is dan natuurlijk ook lekker over the top, zonder dat het duur(der) is.

Maar als je met pijn en moeite cat6 getrokken hebt gekregen kan ik mij inderdaad indenken dat je die niet voor de lol eruit gaat halen. Zeker gezien glasvezel een vele kwetsbaardere kabel is en je die ook niet kunt trekken (in letterlijke zin). Die moet je echt heel voorzichtig doorvoeren zonder kracht op de connector (dus geen trekveer gebruiken) en zonder de vezel te knikken.
Zelf heb ik er dus laatst ook een van zolder naar kelder gelegd. Rechte buis, maar wel mof erin en van op zolder naar beneden, in de meterkast waar die door gaat, en in de kelder, stukken met flexbuis ertussen, en dat is gewoon moeilijk. Want je hebt niks om te trekken en de stekker zet zich steeds vast in de ribbels.

[briecht]

Kan je op een UAP Pro kiezen welk untagged VLAN er in de tweede (niet PoE) poort zit? Die neemt hier standaard een IP uit mijn default VLAN 1.

[Enforcer]

Ik heb sinds gisteren 3 Lite Access Points strategisch in huis geplaatst (3woonlagen), is dan het algemeen advies om de TX Power gewoon op Auto te laten staan of toch zelf inregelen qua 2,4 Low/5Ghz High? De TX Power op Auto in combinatie met de optie "Connect high performance clients to 5 GHz only" (staat standaard aan) lijkt me dat ik geen roaming issues zou moeten krijgen toch?

[loeberce]

@Enforcer Wat weerhoudt je ervan om het zo even te laten draaien om te kijken of je problemen hebt? Als het werkt, dan niet wijzigen toch?

[backupdevice]

Betreffende mijn USG3 & Tweak slow speed problemen.

Ik kom er niet echt uit. Kabels zijn onderweg .

Dit is hoe het bij mij in de USG staat



Dit is de output die ik krijg via SSH

code:

IP offload module   : loaded
IPv4
  forwarding: enabled
  vlan      : enabled
  pppoe     : enabled
  gre       : enabled
IPv6
  forwarding: enabled
  vlan      : enabled
  pppoe     : disabled

IPSec offload module: loaded

Traffic Analysis    :
IPv4
  forwarding: enabled
  vlan      : enabled
  pppoe     : enabled
  gre       : enabled
  export    : disabled
  dpi       : disabled
IPSec offload module: loaded

Krijg ergens anders de tip om IPSEC uit te schakelen, maar ik kom dat alleen maar tegen bij de X serie en weet niet of dat op de USG3P werkt.

[Tylen]

backupdevice schreef op donderdag 7 januari 2021 @ 13:42:
Betreffende mijn USG3 & Tweak slow speed problemen.

Ik kom er niet echt uit. Kabels zijn onderweg .

Dit is hoe het bij mij in de USG staat

[Afbeelding]

Dit is de output die ik krijg via SSH

code:

IP offload module   : loaded
IPv4
  forwarding: enabled
  vlan      : enabled
  pppoe     : enabled
  gre       : enabled
IPv6
  forwarding: enabled
  vlan      : enabled
  pppoe     : disabled

IPSec offload module: loaded

Traffic Analysis    :
IPv4
  forwarding: enabled
  vlan      : enabled
  pppoe     : enabled
  gre       : enabled
  export    : disabled
  dpi       : disabled
IPSec offload module: loaded

Krijg ergens anders de tip om IPSEC uit te schakelen, maar ik kom dat alleen maar tegen bij de X serie en weet niet of dat op de USG3P werkt.

Maar gisteren zei je dat je laptop direct aan de media converter ook maar 500Mbps gaf. Waarom zoek je het dan in de USG???

backupdevice schreef op woensdag 6 januari 2021 @ 17:57:
Vandaag Tweak Glas geleverd gekregen, 1Gbps .

Ik gebruik een USG3P en ik haal totaal de snelheid niet. Kom om een 3e van de snelheid.

Heb mijzelf van te voren goed ingelezen betreffende wat wel en niet kan met dit apparaat . Dus meteen DPI, IPS, IDs & Smart Queue uitgezet , en hardware offloading etc aangezet.

Toch haal ik met Speedtest maar 250 tot 300 down en 400 a 450 up.

Met een laptop direct op de media converter zit ik rond de 500 , dit zou kunnen liggen aan de hardware Bij het leveren zag ik duidelijk dat de monteur boven de 900 kwam.

Ik heb verschillende kabels geprobeerd , de USG al gereset en van de laatste firmware voorzien .

Heb nu denk ik alles geprobeerd en weet niet of ik iets over het hoofd gezien heb.

Iemand een idee of tip?

[backupdevice]

Tylen schreef op donderdag 7 januari 2021 @ 14:13:
[...]


Maar gisteren zei je dat je laptop direct aan de media converter ook maar 500Mbps gaf. Waarom zoek je het dan in de USG???


[...]

3 redenen.

Rechtsreeks geeft de download 500Mbps aan, ik wijdt dit aan de leeftijd of spec van de laptop .

De download via de USG blijft hangen rond de 250-300Mbps, de upload op 500Mbps. Dit op een bedraade aansluiting met een 4 jaar oude Lenovo Thinkpad.

De monteur prikte zijn laptop rechtstreeks op de converter met zijn eigen kabel en haalde 930Mbps


Mijn inziens moet de down en upload ongeveer gelijk zijn. Onderstaande screenshot is consistent resultaat via een bekablede verbinding naar de USG.

[ Voor 39% gewijzigd door backupdevice op 07-01-2021 14:58 ]

[jswinkels]

Ik heb sinds kort een probleem met de verbinding tussen mijn MacBook Pro en het wifi netwerk en dan in het bijzonder het AP (een UniFi AP AC LR) wat ik beneden in huis heb hangen.

Ik thuis de volgende configuratie: Een UniFi AP AC LR in de meterkast, een UniFi AP AC Lite op de eerste verdieping en nog een UniFi AP AC Lite (draadloos verbonden) onder mijn carport (dit is voor mijn zonnepanelen en de auto).

sinds kort (ik weet niet precies wanneer) valt de verbinding op mijn macBook vaak weg wanneer ik beneden zit en wordt er vaak een connectie gemaakt met het AP boven of onder de carport. Het signaal van die AP's is erg slecht waardoor het niet werkbaar is (het signaal van het AP beneden is prima). Door de wifi uit te zetten en weer te activeren is het probleem soms opgelost, maar vaak ook niet.

Het probleem doet zich alleen voor op mij MacBook, alle andere devices (Windows laptops, MacBook Air's van de kinderen, telefoons en iPads) werken gewoon prima en connecten in principe met het juiste AP.

Iemand een idee?

[Valderrama]

Gert456 schreef op donderdag 7 januari 2021 @ 10:08:
[...]

Kijk eens bij Thomann.
Ik heb zelf een Millennium wall rack.

Ah top. Ik ben nu uitgekomen op: https://m.thomann.de/nl/millenium_steel_box_4.htm

Kan ik gewoon in z’n geheel stabiel op de plank leggen en de Gen 2 Switch erin schroeven. Als de UDM Pro er is gaat die er ook direct in natuurlijk en heb ik nog ruimte om er een patch paneel in te schroeven. Hier wil ik dan een paneel in stoppen waar ik keystones in kan doen voor al afgewerkte CAT6 kabels en een paar keystones (of hoe ze ook mogen heten) waarin ik een paar onafgewerkte kabels in verwerk. Heb deze nog niet op Thomann kunnen vinden, zo meteen maar even verder Googlen.

[MasterMaceMichu]

backupdevice schreef op donderdag 7 januari 2021 @ 14:27:
[...]

3 redenen.

Rechtsreeks geeft de download 500Mbps aan, ik wijdt dit aan de leeftijd of spec van de laptop .

De download via de USG blijft hangen rond de 250-300Mbps, de upload op 500Mbps. Dit op een bedraade aansluiting met een 4 jaar oude Lenovo Thinkpad.

De monteur prikte zijn laptop rechtstreeks op de converter met zijn eigen kabel en haalde 930Mbps


Mijn inziens moet de down en upload ongeveer gelijk zijn. Onderstaande screenshot is consistent resultaat via een bekablede verbinding naar de USG.

Stop maar met zoeken. Ten eerste zuigt de speedtest op de Controller apen-ballen, ten tweede kan de USG deze snelheden niet aan.

Ik heb in het begin ook van alles geprobeerd en zelfs een monteur van m'n ISP langs gehad: rechtstreeks op modem met laptop strak 700/700, USG er tussen en terugzakken naar 400/500.

[caspertje19]

Heb je ook niet Enable Smart Queues aanstaan op de WAN kant van de usg?

Zelf een keer gehad, Ziggo langs omdat ik de snelheid niet haal maar de monteur haalde keurig wat ik moest hebben...

[backupdevice]

MasterMaceMichu schreef op donderdag 7 januari 2021 @ 14:58:
[...]

Stop maar met zoeken. Ten eerste zuigt de speedtest op de Controller apen-ballen, ten tweede kan de USG deze snelheden niet aan.

Ik heb in het begin ook van alles geprobeerd en zelfs een monteur van m'n ISP langs gehad: rechtstreeks op modem met laptop strak 700/700, USG er tussen en terugzakken naar 400/500.

Deze speedtest is van Tweak.

caspertje19 schreef op donderdag 7 januari 2021 @ 15:00:
Heb je ook niet Enable Smart Queues aanstaan op de WAN kant van de usg?

Zelf een keer gehad, Ziggo langs omdat ik de snelheid niet haal maar de monteur haalde keurig wat ik moest hebben...

Smart Queues staan uit

[Kodess]

MasterMaceMichu schreef op donderdag 7 januari 2021 @ 14:58:
[...]

Stop maar met zoeken. Ten eerste zuigt de speedtest op de Controller apen-ballen, ten tweede kan de USG deze snelheden niet aan.

Ik heb in het begin ook van alles geprobeerd en zelfs een monteur van m'n ISP langs gehad: rechtstreeks op modem met laptop strak 700/700, USG er tussen en terugzakken naar 400/500.

Ik heb met USG op TMobile gigabit 900-1000Mbit.

[backupdevice]

Kodess schreef op donderdag 7 januari 2021 @ 15:45:
[...]

Ik heb met USG op TMobile gigabit 900-1000Mbit.

Heb je een DM gestuurd.

[reinoudkil]

Enforcer schreef op donderdag 7 januari 2021 @ 13:19:
Ik heb sinds gisteren 3 Lite Access Points strategisch in huis geplaatst (3woonlagen), is dan het algemeen advies om de TX Power gewoon op Auto te laten staan of toch zelf inregelen qua 2,4 Low/5Ghz High? De TX Power op Auto in combinatie met de optie "Connect high performance clients to 5 GHz only" (staat standaard aan) lijkt me dat ik geen roaming issues zou moeten krijgen toch?

Mijn advies zou zijn 2,4 Low en 5 High.

Roaming issues zouden alleen nog komen door eigenwijze hardware die toch blijft plakken of door dat je een te groot oppervlakte af wil dekken

[Valderrama]

De USG kan gewoon probleemloos een 1 gigabit lijn aan hoor.

Je moet alleen niet IPS/IDS aanzetten. Dan is de CPU de bottleneck.

[MasterMaceMichu]

Excuus, bedoelde 2 keer hetzelfde, te snel getikt: als je/ik in de controller een speedtest doet, maxed hij rond de 500/600 out, als ik iets behoorlijks binnen hengel, gaat dat op de daadwerkelijke isp snelheid.

[Jeroen_ae92]

Nee, er zijn mogelijkheden waardoor offloading uitgeschakeld kan worden. Bridged interfaces, modify rules, shapers of limiters en bonding. Dan kan het nog wel aanstaan in de config maar fysiek wordt het uitgeschakeld. Er zitten wat variaties in qua merkbaarheid. Dus ja, een USG routeerd wel 1Gb maar kan dus ook door een configuratie dat ineens niet meer doen.

[RobertMe]

briecht schreef op donderdag 7 januari 2021 @ 13:10:
Kan je op een UAP Pro kiezen welk untagged VLAN er in de tweede (niet PoE) poort zit? Die neemt hier standaard een IP uit mijn default VLAN 1.

Bij mijn weten zijn de poorten bridged. Alle data die op het ene poortje binnen komt wordt letterlijk één op één doorgezet naar het andere poortje. Dus geen mogelijkheid tot configuratie of instellen andere VLANs.

[nero355]

briecht schreef op donderdag 7 januari 2021 @ 13:10:
Kan je op een UAP Pro kiezen welk untagged VLAN er in de tweede (niet PoE) poort zit? Die neemt hier standaard een IP uit mijn default VLAN 1.

Volgens mij is dit gewoon het probleem :

RobertMe schreef op donderdag 7 januari 2021 @ 18:01:
Bij mijn weten zijn de poorten bridged. Alle data die op het ene poortje binnen komt wordt letterlijk één op één doorgezet naar het andere poortje. Dus geen mogelijkheid tot configuratie of instellen andere VLANs.

Maar op voorwaarde dat die poort ALLES doorgeeft als een simpele Bridge zou je wel een Managed Switch erachter kunnen zetten en daar dan weer alle data opvangen en de VLAN's weer opsplitsen

Als die poort echter alleen VLAN 1 doorgeeft dan heb je daar ook niet zoveel aan...

RobertMe schreef op donderdag 7 januari 2021 @ 12:17:
Uiteraard is het ook geen verplichting om glasvezel te gebruiken. Maar als je twee van deze switches wilt plaatsen lijkt het voor mij een gevalletje "geld speelt geen rol ik wil het over the top doen". Glasvezel is dan natuurlijk ook lekker over the top, zonder dat het duur(der) is.

Maar als je met pijn en moeite cat6 getrokken hebt gekregen kan ik mij inderdaad indenken dat je die niet voor de lol eruit gaat halen. Zeker gezien glasvezel een vele kwetsbaardere kabel is en je die ook niet kunt trekken (in letterlijke zin). Die moet je echt heel voorzichtig doorvoeren zonder kracht op de connector (dus geen trekveer gebruiken) en zonder de vezel te knikken.
Zelf heb ik er dus laatst ook een van zolder naar kelder gelegd. Rechte buis, maar wel mof erin en van op zolder naar beneden, in de meterkast waar die door gaat, en in de kelder, stukken met flexbuis ertussen, en dat is gewoon moeilijk. Want je hebt niks om te trekken en de stekker zet zich steeds vast in de ribbels.

Volgens mij had iemand een leuke video over glasvezel "trekken" geplaatst in Het grote topic voor nette lan afwerking deel 4 waar je een beetje de grenzen van dat spul ziet, echter heb je dan nog steeds de speciale apparatuur nodig om weer een connector eraan vast te maken...

[backupdevice]

Valderrama schreef op donderdag 7 januari 2021 @ 16:34:
De USG kan gewoon probleemloos een 1 gigabit lijn aan hoor.

Je moet alleen niet IPS/IDS aanzetten. Dan is de CPU de bottleneck.

Dat denk ik ook, maar denk dat mijn hardware het niet aankan.

Mijn werklaptop heeft een fysieke 100 ethernet aansluiting . Als ik deze rechtstreeks aansluit dan kom ik dus niet verder als 100. Als ik deze op een USB-C Dock aansluit geeft Windows wel een 1Gbps verbinding aan maar haal ik maar 200 down en 500 up. De laptop staat dan wel te loeien.

Onze huis laptop heeft wel een 1Gbps aansluiting, maar die laptop is zo traag , vooral de harddisk

Een andere apparaat is mijn DS214+ met gewone harde schrijven , ik haal via Usenet maar 9Mbit. Dit via twee usenet providers.

Dus ik ben bang dat ik gelimiteerd wordt door mijn apparatuur

Ach ja, haal nu 200/300 voor 34 euro per maand.... is ook goed .

[nero355]

backupdevice schreef op donderdag 7 januari 2021 @ 19:24:
Onze huis laptop heeft wel een 1Gbps aansluiting, maar die laptop is zo traag , vooral de harddisk

Een andere apparaat is mijn DS214+ met gewone harde schrijven , ik haal via Usenet maar 9Mbit. Dit via twee usenet providers.

Dus ik ben bang dat ik gelimiteerd wordt door mijn apparatuur

wget -O /dev/null

De rest mag je zelf uitzoeken!

[backupdevice]

Geen idee wat je daarmee bedoelt . /Dev/null is toch prullenbak

[UTMachine]

backupdevice schreef op donderdag 7 januari 2021 @ 20:08:
Geen idee wat je daarmee bedoelt . /Dev/null is toch prullenbak

Dat klopt, maar als je het naar /dev/null schrijft, dan is er 0.0 schrijf activiteit (en sluit je dus je harddisk bottleneck uit)

[backupdevice]

UTMachine schreef op donderdag 7 januari 2021 @ 20:23:
[...]


Dat klopt, maar als je het naar /dev/null schrijft, dan is er 0.0 schrijf activiteit (en sluit je dus je harddisk bottleneck uit)

Ah, dus op de DS214+ een console openen en via dit commando iets downloaden

[MdBruin]

Jeroen_ae92 schreef op donderdag 7 januari 2021 @ 17:58:
[...]
Dus ja, een USG routeerd wel 1Gb maar kan dus ook door een configuratie dat ineens niet meer doen.

Goed om je weer te zien in het topic Jeroen

De vraag blijft dan wel, is de USG geschikt voor een 1Gb internet verbinding.
In mijn optiek heeft de USG een te langzame processor om zonder problemen een 1Gb internet verbinding aan te kunnen. Ja het lukt zodra je functies uitzet, maar schiet je dan niet het doel voorbij.
Om deze alleen als router te gebruikten en een basic firewall om toch de snelheid te behouden, dan zou ik persoonlijk kiezen voor een krachtigere router (vooral bij zo'n snelle internetverbinding). Ik snap dat als je in de Unifi lijn wilt blijven dat er dan niet echt veel keuze is en het gelijk een stuk duurder is.

[RobertMe]

MdBruin schreef op donderdag 7 januari 2021 @ 21:31:
[...]


Goed om je weer te zien in het topic Jeroen

De vraag blijft dan wel, is de USG geschikt voor een 1Gb internet verbinding.
In mijn optiek heeft de USG een te langzame processor om zonder problemen een 1Gb internet verbinding aan te kunnen. Ja het lukt zodra je functies uitzet, maar schiet je dan niet het doel voorbij.
Om deze alleen als router te gebruikten en een basic firewall om toch de snelheid te behouden, dan zou ik persoonlijk kiezen voor een krachtigere router (vooral bij zo'n snelle internetverbinding). Ik snap dat als je in de Unifi lijn wilt blijven dat er dan niet echt veel keuze is en het gelijk een stuk duurder is.

Als IDS/IPS of traffic shaping / smart queues voor jou een vereiste is dan is de USG inderdaad niet goed. Daarbij wordt hardware offloading uitgeschakeld en is de CPU inderdaad te langzaam. Bij gebruik met een standaard configuratie (alleen DPI aan, geen smart queues noch IDS/IPS) dan doet de CPU er niet toe omdat het NATen / routeren geoffload is naar de hardware en niet "handmatig" door de CPU / het OS wordt gedaan, en die hardware is wel capabel genoeg.

[Jeroen_ae92]

MdBruin schreef op donderdag 7 januari 2021 @ 21:31:
[...]De vraag blijft dan wel, is de USG geschikt voor een 1Gb internet verbinding.
In mijn optiek heeft de USG een te langzame processor om zonder problemen een 1Gb internet verbinding aan te kunnen. Ja het lukt zodra je functies uitzet, maar schiet je dan niet het doel voorbij.
Om deze alleen als router te gebruikten en een basic firewall om toch de snelheid te behouden, dan zou ik persoonlijk kiezen voor een krachtigere router (vooral bij zo'n snelle internetverbinding). Ik snap dat als je in de Unifi lijn wilt blijven dat er dan niet echt veel keuze is en het gelijk een stuk duurder is.

Jawel, de USG doet net als de Edgerouter 3 keurig 1Gb routeren maarrrrrr binnen de Unifi lijn doen ze weleens truukjes uithalen. Dus een vinkje verkeerd kan impact hebben. Je zal dus echt binnen de CLI moeten kijken of er niet iets uitgehaald wordt. Ik heb geen USG om te testen maar ik lees inmiddels wel dat de bottleneck ergens anders zit dan in de USG

[Will_M]

Jeroen_ae92 schreef op donderdag 7 januari 2021 @ 21:38:
[...]

Jawel, de USG doet net als de Edgerouter 3 keurig 1Gb routeren maarrrrrr binnen de Unifi lijn doen ze weleens truukjes uithalen. Dus een vinkje verkeerd kan impact hebben. Je zal dus echt binnen de CLI moeten kijken of er niet iets uitgehaald wordt. Ik heb geen USG om te testen maar ik lees inmiddels wel dat de bottleneck ergens anders zit dan in de USG

Als je op een USG3P DPI aan zet dan gaat 't apparaatje stoppen met 'hardware-offloaden' doordat 't ding zelf gewoon niet genoeg resources heeft om dat door de CPU alléén te kunnen afhandelen. Gevolg is dat je nog maar een maximale bandbreedte van ±85 Mbit aan de WAN kant over houdt.



Niet héél spannend, tenzij je een WAN lijn hebt welke meer levert

[ Voor 16% gewijzigd door Will_M op 07-01-2021 23:04 ]

[ed1703]

Will_M schreef op donderdag 7 januari 2021 @ 22:57:
[...]


Als je op een USG3P DPI aan zet dan gaat 't apparaatje stoppen met 'hardware-offloaden' doordat 't ding zelf gewoon niet genoeg resources heeft om dat door de CPU alléén te kunnen afhandelen. Gevolg is dat je nog maar een maximale bandbreedte van ±85 Mbit aan de WAN kant over houdt.

Niet héél spannend, tenzij je een WAN lijn hebt welke meer levert

Nee, dat is IPS/IDS. Nogal een verschil. DPI kan gewoon door de offloadchip worden gedaan.

[RobertMe]

Will_M schreef op donderdag 7 januari 2021 @ 22:57:
[...]


Als je op een USG3P DPI aan zet dan gaat 't apparaatje aan't 'hardware-offloaden' doordat 't ding zelf gewoon niet genoeg resources heeft om dat op de CPU alléén te kunnen afhandelen. Gevolg is dat je nog maar een maximale bandbreedte van ±85 Mbit aan de WAN kant over houdt.

Niet héél spannend, tenzij je een WAN lijn hebt welke meer levert

Volgens mij haal je wat dingen door elkaar? De USG doet standaard hardware offloading. Immers is er dan niet veel spannends aan, beetje pakketjes heen en weer sturen en NATen. DPI hebben ze in de hardware offloading erbij weten te frotten. Die zal dus (periodiek?) "vanuit de hardware" aan het OS mededelen wat er aan verkeer doorheen is gegaan. Dit kan ook allemaal netjes met 1Gbit/s zonder enige problemen. En DPI is ook een feature die standaard aan staat, en dus niet tot enige issues leidt.

De problemen ontstaan bij smart queues en IDS/IPS. Dit is (te) complex om in de firmware van de hardware offloading "chip" in te bakken. Daardoor gaat bij die features hardware offloading uit, en dan heb je inderdaad een probleem. Hoe groot dat probleem is hangt vervolgens af van wat je allemaal doet. IDS/IPS met alle toeters & bellen (en de USG lineup heeft al minder toeters & bellen op IDS/IPS gebied dan de UDM lineup bij mijn weten, en de USG 3P meen ik zelfs minder dan de USG Pro) loop je inderdaad tegen een limiet van om en nabij de 85Mbit/s aan. Als je vervolgens een bulk aan regels uit zet zal de snelheid ook wel weer iets toenemen (immers zijn er minder regels waartegen het verkeer gecontroleerd moet worden dus zal het sneller verwerkt worden)

[reinoudkil]

Will_M schreef op donderdag 7 januari 2021 @ 22:57:
[...]


Als je op een USG3P DPI aan zet dan gaat 't apparaatje stoppen met 'hardware-offloaden' doordat 't ding zelf gewoon niet genoeg resources heeft om dat door de CPU alléén te kunnen afhandelen. Gevolg is dat je nog maar een maximale bandbreedte van ±85 Mbit aan de WAN kant over houdt.

Niet héél spannend, tenzij je een WAN lijn hebt welke meer levert

Wat is dit nou weer voor onzin....?
DPI gaat niet een bottleneck opleveren, daarmee kun je prima een gigabit verbinding bedienen doordat hij off-road naar de hardware (die daar expliciet voor bedoelt is). Het probleem ontstaat als hardware offloading uit staat ( zoals bij gebruik van smart queues en of ids/ips) aangezien de cpu niet sterk genoeg is om die functionaliteiten bij ga snelheden af te handelen.

De usg3 komt met ids/ips tot pakweg 85mb en de pro tot pakweg 400 mb.

En nou ben ik spuit elf....

[Will_M]

Heb er even een plaatje bij gezet. DPI aanzetten om alleen maar DPI aan te zetten is vrij zinloos (IMHO), je gebruikt dat juist om IPS / IDS te gaan gebruiken (en dan liefst IPS).

[reinoudkil]

Will_M schreef op donderdag 7 januari 2021 @ 23:08:
Heb er even een plaatje bij gezet. DPI aanzetten om alleen maar DPI aan te zetten is vrij zinloos (IMHO), je gebruikt dat juist om IPS / IDS te gebruiken (en dan liefst IPS).

Nogmaals dit heeft helemaal niets met dpi te maken.....

[ed1703]

Will_M schreef op donderdag 7 januari 2021 @ 23:08:
Heb er even een plaatje bij gezet. DPI aanzetten om alleen maar DPI aan te zetten is vrij zinloos (IMHO), je gebruikt dat juist om IPS / IDS te gaan gebruiken (en dan liefst IPS).

DPI gebruik je voor statistieken wat je clients doen, totaal apart van IPS die aanvallen op je netwerk blocked.

[Will_M]

ed1703 schreef op donderdag 7 januari 2021 @ 23:12:
[...]

DPI gebruik je voor statistieken wat je clients doen, totaal apart van IPS die aanvallen op je netwerk blocked.

Ik zit daar misschien iets anders in. Als ik semi wéét wat machines op m'n netwerk doen dan wil ik daar meer mee doen dan alleen maar een FW rule voor kunnen opstellen.

[ed1703]

Will_M schreef op donderdag 7 januari 2021 @ 23:17:
[...]


Ik zit daar misschien iets anders in. Als ik semi wéét wat machines op m'n netwerk doen dan wil ik daar meer mee doen dan alleen maar een FW rule voor kunnen opstellen.

Prima, maar ga niet die zaken aan elkaar linken, want ze kunnen onafhankelijk van elkaar werken.
DPI is door UI zelf gemaakt om stats te tonen in de GUI van de controller. (overigens is dit verre van DPI, maar ok)
IPS = op basis van Suricata Signatures, die ook regelmatig gedownload worden als het goed is.

Overigens wens ik je succes met firewall-rules opstellen op basis van DPI. Mij zal dat niet lukken denk ik, want het is niet te doen op Unifi. Specifieke verbindingen laat hij niet zien. Dat kan alleen als je een logging regel laat meelopen in je firewall zodat je eruit kunt halen welke verbindingen er allemaal opgezet worden.

[ Voor 30% gewijzigd door ed1703 op 07-01-2021 23:37 ]

[BugBoy]

Ik overweeg een Unifi DM pro en wil eigenlijk ook alle DNS requesten afvangen. De Google Chromecast heeft een hardcoded DNS van Google en kijkt niet naar de DNS die uitgegeven wordt door DHCP. Is het mogelijk met de DM pro om al het DNS verkeer standaard te routen naar een andere DNS?

Ik heb een eigen DNS server draaien op een Linux doos die ook de nodige logging uitvoert. Dat zou ik dus graag voor al mijn devices de DNS naartoe sturen. Is dat mogelijk met de DM pro?

[Hulliee]

BugBoy schreef op donderdag 7 januari 2021 @ 23:50:
Ik overweeg een Unifi DM pro en wil eigenlijk ook alle DNS requesten afvangen. De Google Chromecast heeft een hardcoded DNS van Google en kijkt niet naar de DNS die uitgegeven wordt door DHCP. Is het mogelijk met de DM pro om al het DNS verkeer standaard te routen naar een andere DNS?

Ik heb een eigen DNS server draaien op een Linux doos die ook de nodige logging uitvoert. Dat zou ik dus graag voor al mijn devices de DNS naartoe sturen. Is dat mogelijk met de DM pro?

Wat jij wil, is mogelijk met een firewall-rule die alle dns-requests routeert. Dus ja kan met UDM pro, maar met ook met een eenvoudigere router.

[Ernste]

Misschien eerst even goed Googlen....

Blijkt een known issue te zijn van UDM Pro icm TMobile. Overstappen op SFP zou moeten helpen, ga ik eens proberen.


Goedemorgen all. Sinds enkele dagen eindelijk glasvezel (T-Mobile over KPN GPON netwerk). Helaas blijkt de verbinding via mijn UDM-Pro niet goed te gaan. Het werkt op zich, speedtest lijkt ook goed te zijn, maar het is met tussenpozen langzaam. Nu heb ik gisteren wat zitten testen, en het blijkt dat ik veel packet loss heb:

[code]❯ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=8.349 ms
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=7.936 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=7.668 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=8.316 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=7.715 ms
Request timeout for icmp_seq 8
64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=7.836 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=7.504 ms
64 bytes from 1.1.1.1: icmp_seq=11 ttl=58 time=7.522 ms
Request timeout for icmp_seq 12
64 bytes from 1.1.1.1: icmp_seq=13 ttl=58 time=7.630 ms
64 bytes from 1.1.1.1: icmp_seq=14 ttl=58 time=7.916 ms
64 bytes from 1.1.1.1: icmp_seq=15 ttl=58 time=7.555 ms
Request timeout for icmp_seq 16
64 bytes from 1.1.1.1: icmp_seq=17 ttl=58 time=7.749 ms
Request timeout for icmp_seq 18
64 bytes from 1.1.1.1: icmp_seq=19 ttl=58 time=7.521 ms
64 bytes from 1.1.1.1: icmp_seq=20 ttl=58 time=8.669 ms
64 bytes from 1.1.1.1: icmp_seq=21 ttl=58 time=9.996 ms
64 bytes from 1.1.1.1: icmp_seq=22 ttl=58 time=33.168 ms
64 bytes from 1.1.1.1: icmp_seq=23 ttl=58 time=45.791 ms
64 bytes from 1.1.1.1: icmp_seq=24 ttl=58 time=34.808 ms
64 bytes from 1.1.1.1: icmp_seq=25 ttl=58 time=28.190 ms
Request timeout for icmp_seq 26
64 bytes from 1.1.1.1: icmp_seq=27 ttl=58 time=7.667 ms
64 bytes from 1.1.1.1: icmp_seq=28 ttl=58 time=7.997 ms
64 bytes from 1.1.1.1: icmp_seq=29 ttl=58 time=7.533 ms
64 bytes from 1.1.1.1: icmp_seq=30 ttl=58 time=7.905 ms
64 bytes from 1.1.1.1: icmp_seq=31 ttl=58 time=7.727 ms
64 bytes from 1.1.1.1: icmp_seq=32 ttl=58 time=7.889 ms
64 bytes from 1.1.1.1: icmp_seq=33 ttl=58 time=8.005 ms
64 bytes from 1.1.1.1: icmp_seq=34 ttl=58 time=7.783 ms
64 bytes from 1.1.1.1: icmp_seq=35 ttl=58 time=7.532 ms
64 bytes from 1.1.1.1: icmp_seq=36 ttl=58 time=7.923 ms
64 bytes from 1.1.1.1: icmp_seq=37 ttl=58 time=22.208 ms
Request timeout for icmp_seq 38
Request timeout for icmp_seq 39
64 bytes from 1.1.1.1: icmp_seq=40 ttl=58 time=8.601 ms
Request timeout for icmp_seq 41
Request timeout for icmp_seq 42
Request timeout for icmp_seq 43
64 bytes from 1.1.1.1: icmp_seq=44 ttl=58 time=30.162 ms
64 bytes from 1.1.1.1: icmp_seq=45 ttl=58 time=7.986 ms[/code]

Met de meegeleverde router (Zyxel VMG8825-T50) heb ik dit probleem niet (al is het ook minder stabiel qua response times dan ik zou verwachten):

[code]PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=58 time=9.969 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=10.068 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=9.925 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=9.527 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=9.522 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=8.823 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=13.839 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=9.295 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=58 time=11.124 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=9.378 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=8.980 ms
64 bytes from 1.1.1.1: icmp_seq=11 ttl=58 time=8.584 ms
64 bytes from 1.1.1.1: icmp_seq=12 ttl=58 time=24.859 ms
64 bytes from 1.1.1.1: icmp_seq=13 ttl=58 time=10.050 ms
64 bytes from 1.1.1.1: icmp_seq=14 ttl=58 time=16.645 ms
64 bytes from 1.1.1.1: icmp_seq=15 ttl=58 time=25.345 ms
64 bytes from 1.1.1.1: icmp_seq=16 ttl=58 time=8.762 ms
64 bytes from 1.1.1.1: icmp_seq=17 ttl=58 time=9.515 ms
64 bytes from 1.1.1.1: icmp_seq=18 ttl=58 time=18.174 ms
64 bytes from 1.1.1.1: icmp_seq=19 ttl=58 time=9.209 ms
^C
--- 1.1.1.1 ping statistics ---
20 packets transmitted, 20 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.584/12.080/25.345/5.024 ms[/code]

De UDM-Pro achter de TMobile router hangen werkt ook, maar dat wil ik natuurlijk niet.

Wat zou een goede volgende stap zijn om uit te zoeken waarom ik zoveel packet loss heb met de verbinding rechtstreeks op de UDM-Pro?

[backupdevice]

Jeroen_ae92 schreef op donderdag 7 januari 2021 @ 21:38:
[...]

Jawel, de USG doet net als de Edgerouter 3 keurig 1Gb routeren maarrrrrr binnen de Unifi lijn doen ze weleens truukjes uithalen. Dus een vinkje verkeerd kan impact hebben. Je zal dus echt binnen de CLI moeten kijken of er niet iets uitgehaald wordt. Ik heb geen USG om te testen maar ik lees inmiddels wel dat de bottleneck ergens anders zit dan in de USG

Vanmorgen onze oude laptop, die een 1Gb nic heeft, op de Switch aangesloten en ik haal nu netjes de volle snelheid .

Weet niet waarom dat nu wel zo is want deze laptop heb ik afgelopen woensdag rechtstreeks op de media converter aangesloten en toen was de snelheid zeer laag.

Maar ja, blij dat het allemaal werkt. De USG werkt dus naar behoren op een 1Gbps I-net lijn.

[ Voor 43% gewijzigd door backupdevice op 08-01-2021 08:05 ]

[stormfly]

Hulliee schreef op vrijdag 8 januari 2021 @ 00:27:
[...]


Wat jij wil, is mogelijk met een firewall-rule die alle dns-requests routeert. Dus ja kan met UDM pro, maar met ook met een eenvoudigere router.

Wat hij vraagt is een DNS verzoek naar 8.8.8.8 af te buigen naar een interne of andere externe DNS. Hoe doe jij dat in de UDM PRO?

[Hulliee]

stormfly schreef op vrijdag 8 januari 2021 @ 07:57:
[...]


Wat hij vraagt is een DNS verzoek naar 8.8.8.8 af te buigen naar een interne of andere externe DNS. Hoe doe jij dat in de UDM PRO?

Een dns-verzoek gaat over poort 53. Ik dacht dan alle uitgaande verzoeken om te leiden naar je eigen dns-server?

[RobertMe]

Hulliee schreef op vrijdag 8 januari 2021 @ 08:18:
[...]


Een dns-verzoek gaat over poort 53. Ik dacht dan alle uitgaande verzoeken om te leiden naar je eigen dns-server?

Dat kan op een router die D-NAT (of was het nu S-NAT?) ondersteund ja. Maar de UDM doet dat niet en de USG alleen via de config.gateway.json

[Hulliee]

RobertMe schreef op vrijdag 8 januari 2021 @ 08:20:
[...]

Dat kan op een router die D-NAT (of was het nu S-NAT?) ondersteund ja. Maar de UDM doet dat niet en de USG alleen via de config.gateway.json

Ok, ik heb het nog niet getest, maar wat als je alle Secure dns verkeer op poort 443 blokkeert? En verkeer over poort 53 dan redirect?

https://forum.xda-develop...t-tv-dns-options.4178829/
Eind vd pagina

[ Voor 10% gewijzigd door Hulliee op 08-01-2021 08:30 ]

[stormfly]

Hulliee schreef op vrijdag 8 januari 2021 @ 08:18:
[...]


Een dns-verzoek gaat over poort 53. Ik dacht dan alle uitgaande verzoeken om te leiden naar je eigen dns-server?

Alleen kan de UDM-PRO dat bij mijn weten niet ;-) die heeft alleen FW rules en geen traffic interception rules. Echter, als hij het wel kan, dan leer ik graag hoe!

Heb afgelopen periode ook gekeken naar not allowed DNS, daar scoren de volgende devices hoog op:

-Chromecast
-NEST mini
-Ziggo NEXT STB

Overigens als ik 8.8.8.8 geheel block blijft alles hier doorwerken.

[ed1703]

stormfly schreef op vrijdag 8 januari 2021 @ 08:55:
[...]


Alleen kan de UDM-PRO dat bij mijn weten niet ;-) die heeft alleen FW rules en geen traffic interception rules. Echter, als hij het wel kan, dan leer ik graag hoe!

Ook geen mogelijkheid om het iptables commando uit te voeren op de CLI?
Ben je na een reboot wel kwijt, maar even benieuwd.

Of werkt de UDM met nftables?

[ Voor 3% gewijzigd door ed1703 op 08-01-2021 09:35 ]

[xbeam]

Hulliee schreef op vrijdag 8 januari 2021 @ 00:27:
[...]


Wat jij wil, is mogelijk met een firewall-rule die alle dns-requests routeert. Dus ja kan met UDM pro, maar met ook met een eenvoudigere router.

Welke firewall rule gebruik je dan daarvoor?
Want zo ver ik weet doe je dat met een nat forward regel en dat kan alleen op de USG en niet op een UDM

Hulliee schreef op vrijdag 8 januari 2021 @ 08:28:
[...]


Ok, ik heb het nog niet getest, maar wat als je alle Secure dns verkeer op poort 443 blokkeert? En verkeer over poort 53 dan redirect?

https://forum.xda-develop...t-tv-dns-options.4178829/
Eind vd pagina

Dit gaat all helemaal niet werken, omdat dns verkeer bij dns over https zit ingepakt in normaal het normale https internet verkeer. Zou je deze er alleen uit kunnen filteren waneer je beschikt over SSL inspectie. En dat hebben de UDM en usg niet waardoor je bij een Port remapping all je https verkeer naar Port 53 forward waardoor niemand in huis https internet heeft.

[ Voor 46% gewijzigd door xbeam op 08-01-2021 12:59 ]

[Comp User]

stormfly schreef op vrijdag 8 januari 2021 @ 07:57:
[...]


Wat hij vraagt is een DNS verzoek naar 8.8.8.8 af te buigen naar een interne of andere externe DNS. Hoe doe jij dat in de UDM PRO?

Ik heb het op deze manier - Edgerouter 6P - opgelost.

[Hulliee]

xbeam schreef op vrijdag 8 januari 2021 @ 09:47:
[...]


Welke firewall rule gebruik je dan daarvoor?
Want zo ver ik weet doe je dat met een nat forward regel en dat kan alleen op de USG en niet op een UDM

Ik kom van een EdgeRouter af en had dat dus als [Comp User] hier boven ingeregeld.

[...]


Dit gaat all helemaal niet werken, omdat dns verkeer bij dns over https zit ingepakt in normaal https internet verkeer. Zou je deze er alleen uit kunnen filteren waneer je beschikt over SSL inspectie. En dat hebben de UDM en usg niet waardoor je bij een Port remapping all je https verkeer naar Port 53 forward waardoor niemand in huis https internet heeft.

Die 443 redirect gaat niet werken idd of alles wordt geblokkeerd.

[Thoit]

Wellicht dat hier mij iemand kan helpen. Sinds een aantal dagen heb ik een Unifi Dream Machine. Hiervoor heb ik een aantal port forwards ingesteld die ik wil disablen zodra ik ze niet gebruik. Middels PowerShell wil ik tegen de API kunnen aanpraten.

Ik kan inmiddels verbinding maken met de API, want ik kan de port forwarding rules ophalen. Dit kan ik middels het volgende commando:

code:

$a = Invoke-RestMethod -Uri 'https://<IPADRES>/proxy/network/api/s/default/rest/portforward' -Method get -WebSession $s -ContentType "application/json" -Headers $headers
$a | ConvertTo-Json | Write-Output

Ik heb de rule disabled en gekeken in developer mode in mijn browser wat die doet. Het is in feite hetzelfde als het ophalen van de rule, alleen doe je een put ipv get en voeg je de ruleid in de url toe. Als ik dit vertaal naar mijn script zou ik op het volgende moeten uitkomen:

code:

$params = @{
    'enabled' = 'false';
}
$body = $params | ConvertTo-Json

Invoke-RestMethod -Uri 'https://IPADRES/proxy/network/api/s/<sitename>/rest/portforward/IDVANRULE' -Method put -Body $body -WebSession $s -ContentType "application/json" -Headers $headers

Echter blijf ik hierbij de volgende foutmelding krijgen: Invoke-RestMethod : Not Found

Wat ik reeds gedaan heb:
- Volledige body meegestuurd i.p.v. alleen enabled = false
- De volgende wiki vaak doorgelezen: https://ubntwiki.com/products/software/unifi-controller/api
- Verschillende URLs geprobeerd
- Met de user waarmee ik tegen de API aanpraat de rule enabled / disabled zodat ik zeker weet dat die rechten heeft
- Firmware upgrade

Op een gegeven moment dacht ik, ik probeer middels de API een nieuwe rule aan te maken. Echter krijg ik daarbij ook dezelfde foutmelding.

Hopelijk is er hier iemand die mij hiermee kan helpen?

[BugBoy]

Comp User schreef op vrijdag 8 januari 2021 @ 10:23:
Ik heb het op deze manier - Edgerouter 6P - opgelost.

Dat is inderdaad wat ik zoek. Juist voor de devices zoals Chromecast, Nest, Ziggo, ... ben ik wel eens benieuwd wat die allemaal uitspoken. Nu is het alleen nog de vraag of dit soort masquarading ook kan met de UDM pro. Neem aan dat die met een ingebouwde USG wat meer kan dan de standaard UDM.

[Behoorlijk Leek]

Ernste schreef op vrijdag 8 januari 2021 @ 07:33:
Misschien eerst even goed Googlen....

Blijkt een known issue te zijn van UDM Pro icm TMobile. Overstappen op SFP zou moeten helpen, ga ik eens proberen.


Goedemorgen all. Sinds enkele dagen eindelijk glasvezel (T-Mobile over KPN GPON netwerk). Helaas blijkt de verbinding via mijn UDM-Pro niet goed te gaan. Het werkt op zich, speedtest lijkt ook goed te zijn, maar het is met tussenpozen langzaam. Nu heb ik gisteren wat zitten testen, en het blijkt dat ik veel packet loss heb:

[code]❯ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=8.349 ms
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=7.936 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=7.668 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=8.316 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=7.715 ms
Request timeout for icmp_seq 8
64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=7.836 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=7.504 ms
64 bytes from 1.1.1.1: icmp_seq=11 ttl=58 time=7.522 ms
Request timeout for icmp_seq 12
64 bytes from 1.1.1.1: icmp_seq=13 ttl=58 time=7.630 ms
64 bytes from 1.1.1.1: icmp_seq=14 ttl=58 time=7.916 ms
64 bytes from 1.1.1.1: icmp_seq=15 ttl=58 time=7.555 ms
Request timeout for icmp_seq 16
64 bytes from 1.1.1.1: icmp_seq=17 ttl=58 time=7.749 ms
Request timeout for icmp_seq 18
64 bytes from 1.1.1.1: icmp_seq=19 ttl=58 time=7.521 ms
64 bytes from 1.1.1.1: icmp_seq=20 ttl=58 time=8.669 ms
64 bytes from 1.1.1.1: icmp_seq=21 ttl=58 time=9.996 ms
64 bytes from 1.1.1.1: icmp_seq=22 ttl=58 time=33.168 ms
64 bytes from 1.1.1.1: icmp_seq=23 ttl=58 time=45.791 ms
64 bytes from 1.1.1.1: icmp_seq=24 ttl=58 time=34.808 ms
64 bytes from 1.1.1.1: icmp_seq=25 ttl=58 time=28.190 ms
Request timeout for icmp_seq 26
64 bytes from 1.1.1.1: icmp_seq=27 ttl=58 time=7.667 ms
64 bytes from 1.1.1.1: icmp_seq=28 ttl=58 time=7.997 ms
64 bytes from 1.1.1.1: icmp_seq=29 ttl=58 time=7.533 ms
64 bytes from 1.1.1.1: icmp_seq=30 ttl=58 time=7.905 ms
64 bytes from 1.1.1.1: icmp_seq=31 ttl=58 time=7.727 ms
64 bytes from 1.1.1.1: icmp_seq=32 ttl=58 time=7.889 ms
64 bytes from 1.1.1.1: icmp_seq=33 ttl=58 time=8.005 ms
64 bytes from 1.1.1.1: icmp_seq=34 ttl=58 time=7.783 ms
64 bytes from 1.1.1.1: icmp_seq=35 ttl=58 time=7.532 ms
64 bytes from 1.1.1.1: icmp_seq=36 ttl=58 time=7.923 ms
64 bytes from 1.1.1.1: icmp_seq=37 ttl=58 time=22.208 ms
Request timeout for icmp_seq 38
Request timeout for icmp_seq 39
64 bytes from 1.1.1.1: icmp_seq=40 ttl=58 time=8.601 ms
Request timeout for icmp_seq 41
Request timeout for icmp_seq 42
Request timeout for icmp_seq 43
64 bytes from 1.1.1.1: icmp_seq=44 ttl=58 time=30.162 ms
64 bytes from 1.1.1.1: icmp_seq=45 ttl=58 time=7.986 ms[/code]

Met de meegeleverde router (Zyxel VMG8825-T50) heb ik dit probleem niet (al is het ook minder stabiel qua response times dan ik zou verwachten):

[code]PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=58 time=9.969 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=10.068 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=9.925 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=9.527 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=9.522 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=8.823 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=13.839 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=9.295 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=58 time=11.124 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=9.378 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=8.980 ms
64 bytes from 1.1.1.1: icmp_seq=11 ttl=58 time=8.584 ms
64 bytes from 1.1.1.1: icmp_seq=12 ttl=58 time=24.859 ms
64 bytes from 1.1.1.1: icmp_seq=13 ttl=58 time=10.050 ms
64 bytes from 1.1.1.1: icmp_seq=14 ttl=58 time=16.645 ms
64 bytes from 1.1.1.1: icmp_seq=15 ttl=58 time=25.345 ms
64 bytes from 1.1.1.1: icmp_seq=16 ttl=58 time=8.762 ms
64 bytes from 1.1.1.1: icmp_seq=17 ttl=58 time=9.515 ms
64 bytes from 1.1.1.1: icmp_seq=18 ttl=58 time=18.174 ms
64 bytes from 1.1.1.1: icmp_seq=19 ttl=58 time=9.209 ms
^C
--- 1.1.1.1 ping statistics ---
20 packets transmitted, 20 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.584/12.080/25.345/5.024 ms[/code]

De UDM-Pro achter de TMobile router hangen werkt ook, maar dat wil ik natuurlijk niet.

Wat zou een goede volgende stap zijn om uit te zoeken waarom ik zoveel packet loss heb met de verbinding rechtstreeks op de UDM-Pro?

Ik heb net jouw link even doorgenomen en veel instellingen bij mij zijn redelijk vergelijkbaar, maar er valt me iets op. Er wordt nl. Cloudflare gebruikt als dns, en die veroorzaakte medio april zeer hoge latency, toen ben ik overgestapt op google en de latency was weer normaal.
Wat hoge latency precies veroorzaakt gaat mijn petje te boven, misschien is dat ook wel de oorzaak van de vele meldingen in het dashboard, verbindingsproblemen enz.

Ik heb geen ervaring met wat er hier allemaal geschreven wordt, maar ik volg het wel dagelijks, gisteravond en net heb ik voor even weer cloudflare ingesteld.

[xbeam]

BugBoy schreef op vrijdag 8 januari 2021 @ 12:29:
[...]

Dat is inderdaad wat ik zoek. Juist voor de devices zoals Chromecast, Nest, Ziggo, ... ben ik wel eens benieuwd wat die allemaal uitspoken. Nu is het alleen nog de vraag of dit soort masquarading ook kan met de UDM pro. Neem aan dat die met een ingebouwde USG wat meer kan dan de standaard UDM.

Nogmaals nee dat kan niet met een UDM omdat je geen toegang hebt tot de configuratie settings van de NAT functie.

Dit kan alleen met en USG en edgerouter.

[ Voor 9% gewijzigd door xbeam op 08-01-2021 13:41 ]

[BugBoy]

xbeam schreef op vrijdag 8 januari 2021 @ 13:02:
Nogmaals nee dat niet met een UDM omdat geen toegang tot de configuratie settings van de NAT.
Dit kan allen n met en USG en edge router.

De UDM pro heeft toch een ingebouwde USG? Of mis ik dan nog wat?

[Hulliee]

BugBoy schreef op vrijdag 8 januari 2021 @ 13:14:
[...]

De UDM pro heeft toch een ingebouwde USG? Of mis ik dan nog wat?

UDM (pro) heeft bijna een USG. Sommige functies zitten er niet in

[agitri]

Ernste schreef op vrijdag 8 januari 2021 @ 07:33:
Misschien eerst even goed Googlen....

Blijkt een known issue te zijn van UDM Pro icm TMobile. Overstappen op SFP zou moeten helpen, ga ik eens proberen.


Goedemorgen all. Sinds enkele dagen eindelijk glasvezel (T-Mobile over KPN GPON netwerk). Helaas blijkt de verbinding via mijn UDM-Pro niet goed te gaan. Het werkt op zich, speedtest lijkt ook goed te zijn, maar het is met tussenpozen langzaam. Nu heb ik gisteren wat zitten testen, en het blijkt dat ik veel packet loss heb:

[code]❯ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=8.349 ms
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=7.936 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=7.668 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=8.316 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=7.715 ms
Request timeout for icmp_seq 8
64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=7.836 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=7.504 ms
64 bytes from 1.1.1.1: icmp_seq=11 ttl=58 time=7.522 ms
Request timeout for icmp_seq 12
64 bytes from 1.1.1.1: icmp_seq=13 ttl=58 time=7.630 ms
64 bytes from 1.1.1.1: icmp_seq=14 ttl=58 time=7.916 ms
64 bytes from 1.1.1.1: icmp_seq=15 ttl=58 time=7.555 ms
Request timeout for icmp_seq 16
64 bytes from 1.1.1.1: icmp_seq=17 ttl=58 time=7.749 ms
Request timeout for icmp_seq 18
64 bytes from 1.1.1.1: icmp_seq=19 ttl=58 time=7.521 ms
64 bytes from 1.1.1.1: icmp_seq=20 ttl=58 time=8.669 ms
64 bytes from 1.1.1.1: icmp_seq=21 ttl=58 time=9.996 ms
64 bytes from 1.1.1.1: icmp_seq=22 ttl=58 time=33.168 ms
64 bytes from 1.1.1.1: icmp_seq=23 ttl=58 time=45.791 ms
64 bytes from 1.1.1.1: icmp_seq=24 ttl=58 time=34.808 ms
64 bytes from 1.1.1.1: icmp_seq=25 ttl=58 time=28.190 ms
Request timeout for icmp_seq 26
64 bytes from 1.1.1.1: icmp_seq=27 ttl=58 time=7.667 ms
64 bytes from 1.1.1.1: icmp_seq=28 ttl=58 time=7.997 ms
64 bytes from 1.1.1.1: icmp_seq=29 ttl=58 time=7.533 ms
64 bytes from 1.1.1.1: icmp_seq=30 ttl=58 time=7.905 ms
64 bytes from 1.1.1.1: icmp_seq=31 ttl=58 time=7.727 ms
64 bytes from 1.1.1.1: icmp_seq=32 ttl=58 time=7.889 ms
64 bytes from 1.1.1.1: icmp_seq=33 ttl=58 time=8.005 ms
64 bytes from 1.1.1.1: icmp_seq=34 ttl=58 time=7.783 ms
64 bytes from 1.1.1.1: icmp_seq=35 ttl=58 time=7.532 ms
64 bytes from 1.1.1.1: icmp_seq=36 ttl=58 time=7.923 ms
64 bytes from 1.1.1.1: icmp_seq=37 ttl=58 time=22.208 ms
Request timeout for icmp_seq 38
Request timeout for icmp_seq 39
64 bytes from 1.1.1.1: icmp_seq=40 ttl=58 time=8.601 ms
Request timeout for icmp_seq 41
Request timeout for icmp_seq 42
Request timeout for icmp_seq 43
64 bytes from 1.1.1.1: icmp_seq=44 ttl=58 time=30.162 ms
64 bytes from 1.1.1.1: icmp_seq=45 ttl=58 time=7.986 ms[/code]

Met de meegeleverde router (Zyxel VMG8825-T50) heb ik dit probleem niet (al is het ook minder stabiel qua response times dan ik zou verwachten):

[code]PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=58 time=9.969 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=10.068 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=9.925 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=9.527 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=9.522 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=8.823 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=13.839 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=9.295 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=58 time=11.124 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=9.378 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=8.980 ms
64 bytes from 1.1.1.1: icmp_seq=11 ttl=58 time=8.584 ms
64 bytes from 1.1.1.1: icmp_seq=12 ttl=58 time=24.859 ms
64 bytes from 1.1.1.1: icmp_seq=13 ttl=58 time=10.050 ms
64 bytes from 1.1.1.1: icmp_seq=14 ttl=58 time=16.645 ms
64 bytes from 1.1.1.1: icmp_seq=15 ttl=58 time=25.345 ms
64 bytes from 1.1.1.1: icmp_seq=16 ttl=58 time=8.762 ms
64 bytes from 1.1.1.1: icmp_seq=17 ttl=58 time=9.515 ms
64 bytes from 1.1.1.1: icmp_seq=18 ttl=58 time=18.174 ms
64 bytes from 1.1.1.1: icmp_seq=19 ttl=58 time=9.209 ms
^C
--- 1.1.1.1 ping statistics ---
20 packets transmitted, 20 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 8.584/12.080/25.345/5.024 ms[/code]

De UDM-Pro achter de TMobile router hangen werkt ook, maar dat wil ik natuurlijk niet.

Wat zou een goede volgende stap zijn om uit te zoeken waarom ik zoveel packet loss heb met de verbinding rechtstreeks op de UDM-Pro?

ja naar sfp overstappen helpt, je moet dan een sc naar lc glasvezel hebben met sfp, -> heb ik ook

[xbeam]

BugBoy schreef op vrijdag 8 januari 2021 @ 13:14:
[...]

De UDM pro heeft toch een ingebouwde USG? Of mis ik dan nog wat?

Nee de UDM stukje eenvoudiger dan de USG en heeft als doelgroep de minder technische it leveranciers en prosumer gebruikers. Vandaar ook dat de controller ingebouwd en beschikt hij niet over een json gestuurde input voor de geavanceerde configuratie mogelijkheden.(handig wanneer grote aantallen moet uitrollen en beheren)

Json gestuurde configuratie vragen een boven gemiddelde kennis niveau van het edgeOS (vyos OS) en alle netwerkprotocollen wat betreft juiste instelling daarnaast een een hand gemaakte json file er fout gevoelig.

Deze combinatie zorgt voor een hele stijle leer curve en veel probleem bij de prosumers en de plaatselijke allround ICT leverancier die deze jsons files in elkaar proberen te plakken van voorbeelden die online vinden en omdat een verkeerd comma, nesting of statement gebruik gelijk resulteert in zo genoemde bootloop crashes (eigenlijk is het de commit fail save rollback modus ). Wat dan schuld van de usg en Ubnt is.

Daarom hebben voor deze gebruikers groep de UDM uitgebracht en voor experts/ mssp providers een nieuwe USG zonder controller.

[legofanaten]

xbeam schreef op vrijdag 8 januari 2021 @ 14:56:
[...]
Daarom hebben voor deze gebruikers groep de UDM uitgebracht en voor experts/ mssp providers een nieuwe USG zonder controller.

Behalve dat de UXG nog steeds geen json ondersteund toch? Het is het routergedeelte uit de UDM Pro zonder de ingebouwde controller, switch of HDD-bay voor meer Euro's. Of heb ik een ontwikkeling gemist?

[xbeam]

legofanaten schreef op vrijdag 8 januari 2021 @ 15:27:
[...]


Behalve dat de UXG nog steeds geen json ondersteund toch? Het is het routergedeelte uit de UDM Pro zonder de ingebouwde controller, switch of HDD-bay voor meer Euro's. Of heb ik een ontwikkeling gemist?

De UXG heeft gewoon hele andere doelgroep en gebruik het is daarom lastig om de prijs te vergelijken.
YouTube: Review: Ubiquiti UniFi Dream Machine Pro (UDM-Pro)

Ik mag hopen dat die json die er wel komt omdat veel grote afnemers zijn zoals hotspot en cloud management partijen op deze manier vanuit hun eigen software het unifi aansturen en beheren.

Plus dat die als die er niet komt er upgrade comptabiliteitsprobleem ontstaat. Ga als bedrijf nog een nieuwe uxg kopen als niet alle huidige instellingen kan over zetten naar nieuw gateway.

Het niet hebben van een json configuratie mogelijkheid of het ontbreken van een alternatieve compatibel systeem op de UDM was juist voor de controller/eigen software gestuurde netwerkbeheers een van de redenen van discussie geweest en juiste voor deze groep hebben ze splitsing gemaakt professionele en homebuilders Soho/small installers.

Aangezien de extra notie bij de UXG lijkt me dat de json of gelijkwaardig gewoon ondersteund wordt.

Easily pair UXG-Pro with a Cloud Key for an integrated UniFi management solution.

Ga ik er van uit dat er een soortgelijke functie op de UXG komt.
Dat die er nog niet vind best logisch, Omdat het opstart proces van alpine-OS heel anders is dan edg-os waarbij er ook nog een extra dimensie aanwezig is omdat ubiOS in een container binnen alpine-OS draait. Moet een er extra vertaal slag plaats vinden voor alle functies.


Er is rede dat de uxg beta units pas op Firmware 0.4.0 zitten dat houd in dat ze op ongeveer 40 procent van de router software ontwikkeling zitten. Door de overtap naar alpine-os moet bijna alles worden herschreven.

[ Voor 19% gewijzigd door xbeam op 08-01-2021 19:40 ]

[MdBruin]

Jeroen_ae92 schreef op donderdag 7 januari 2021 @ 21:38:
[...]

Jawel, de USG doet net als de Edgerouter 3 keurig 1Gb routeren maarrrrrr binnen de Unifi lijn doen ze weleens truukjes uithalen. Dus een vinkje verkeerd kan impact hebben. Je zal dus echt binnen de CLI moeten kijken of er niet iets uitgehaald wordt. Ik heb geen USG om te testen maar ik lees inmiddels wel dat de bottleneck ergens anders zit dan in de USG

De Unifi schil lijkt dus de beperking te veroorzaken, hardware technisch zit er niet heel veel verschil tussen de EdgeRouter 3 en de USG. Ik heb ervaring met de ER3 welke behoorlijk sneller was als de USG. De USG is ondertussen al weer vervangen voor een EdgeRouter 4, de 3 lite is bij OpenVPN te beperkend qua doorvoersnelheid.

[Ernste]

Behoorlijk Leek schreef op vrijdag 8 januari 2021 @ 12:37:
[...]

Ik heb net jouw link even doorgenomen en veel instellingen bij mij zijn redelijk vergelijkbaar, maar er valt me iets op. Er wordt nl. Cloudflare gebruikt als dns, en die veroorzaakte medio april zeer hoge latency, toen ben ik overgestapt op google en de latency was weer normaal.
Wat hoge latency precies veroorzaakt gaat mijn petje te boven, misschien is dat ook wel de oorzaak van de vele meldingen in het dashboard, verbindingsproblemen enz.

Ik heb geen ervaring met wat er hier allemaal geschreven wordt, maar ik volg het wel dagelijks, gisteravond en net heb ik voor even weer cloudflare ingesteld.
[Afbeelding]

Thanks. Ik dacht in eerste instantie ook aan een DNS probleem, maar het was duidelijk packet loss. Ik maak overigens gebruik van NextDNS.

[Ernste]

agitri schreef op vrijdag 8 januari 2021 @ 14:07:
[...]


ja naar sfp overstappen helpt, je moet dan een sc naar lc glasvezel hebben met sfp, -> heb ik ook

Ik heb T-Mobile Thuis over het KPN network (GPON?). Zijn er nog specifieke specs waaraan de SFP adapter en kabel moeten voldoen?

[Boudewijn]

Ik heb vandaag een nieuwe ubiquiti setup in productie genomen. Thuis en bij mijn ouders draaien al opstellingen en vandaag bij mijn vriendin aangestoken:

USG Pro 4
US-8-150W
Cloud Key Gen2 Plus
2x UAP AC Pro

Redelijk op de toekomst voorbereid, er ligt glas en er komen wellicht ooit camera's. Prima de bima dus.
De AC Pros heb ik genomen omdat ik naar de tv hoek en naar de slaapkamer maar 1 UTP-kabel heb liggen (en ook niet erbij ga trekken). De bestaande KPN tv-settopboxen (baasvrouw...) ga ik aansluiten via de IPTV tips (https://www.vanachterberg...teway-kpn-ftth-iptv-ipv6/ en het ubiquiti + iptv topic)....


Nu alleen nog even die fans van de USG vervangen, dat is geen heel lekker geluidje nee. En die iptv crap regelen.


Wat ik me wel afvraag is:

ik heb de KPN settopboxjes doorgelinkt via de UAP AC Pro's staan. Daar hebben we straks uitzendingen op teruggekeken (dat gaat wel itt live tv, ik moet de hele IGMP toestand nog instellen). In de controller blijven die clients op <weinig> bytes up/down staan (ook als totaal) . Andere clients genereren wel netjes statistieken. Weet iemand of dat inherent is aan doorlussen... of komt het doordat de "tv gemist" feature van KPN alsnog iets geks doet met routering/multicast/whatever?

Een half uur TV kijken is vast geen 36kbyte.

[ Voor 26% gewijzigd door Boudewijn op 08-01-2021 22:54 ]

[Behoorlijk Leek]

Ernste schreef op vrijdag 8 januari 2021 @ 21:09:
[...]


Thanks. Ik dacht in eerste instantie ook aan een DNS probleem, maar het was duidelijk packet loss. Ik maak overigens gebruik van NextDNS.

Ik kijk net weer even in mijn controller, en heb veel meer afwijkingen,veel hogere latency en een matige ISP belasting sinds ik cloudflare vanochtend als test ingesteld heb, dus die komt er nooit meer op.
Heb inmiddels ook nextdns ingesteld, thanks, ff proberen.

[RobertMe]

Boudewijn schreef op vrijdag 8 januari 2021 @ 22:12:
De AC Pros heb ik genomen omdat ik naar de tv hoek en naar de slaapkamer maar 1 UTP-kabel heb liggen (en ook niet erbij ga trekken).

Eerlijk gezegd klonk dat eerder als een mooie use case voor een In-Wall. Dan had je meteen 2 of 4 aansluitingen gehad (IW HD heeft er 4). En dan kon je ook VLANs op de poorten instellen etc. Bij de AC Pro zitten de poorten aan elkaar geknoopt als domme bridge. En dus is het gelijk aan een ouderwetse hub waarbij alle pakketjes alle kanten op vliegen of dat nu relevant is of niet. Mogelijk dat dat dus ook issues gaat geven met het hele IPTV verhaal.

Je vraag kan ik overigens niet mee helpen. Heb zelf namelijk ook geen IPTV.

[rookie no. 1]

Will_M schreef op donderdag 7 januari 2021 @ 22:57:
[...]


Als je op een USG3P DPI aan zet dan gaat 't apparaatje stoppen met 'hardware-offloaden' doordat 't ding zelf gewoon niet genoeg resources heeft om dat door de CPU alléén te kunnen afhandelen. Gevolg is dat je nog maar een maximale bandbreedte van ±85 Mbit aan de WAN kant over houdt.

Ik kom boven de 100mbit down en 130mbit up uit met IPS en DPI aan. Best netjes voor zo'n oud en relatief goedkoop ding, toch!?

[Boudewijn]

RobertMe schreef op vrijdag 8 januari 2021 @ 23:13:
[...]

Eerlijk gezegd klonk dat eerder als een mooie use case voor een In-Wall. Dan had je meteen 2 of 4 aansluitingen gehad (IW HD heeft er 4). En dan kon je ook VLANs op de poorten instellen etc. Bij de AC Pro zitten de poorten aan elkaar geknoopt als domme bridge. En dus is het gelijk aan een ouderwetse hub waarbij alle pakketjes alle kanten op vliegen of dat nu relevant is of niet. Mogelijk dat dat dus ook issues gaat geven met het hele IPTV verhaal.

Je vraag kan ik overigens niet mee helpen. Heb zelf namelijk ook geen IPTV.

Ja dat snap ik. Goed advies. Punt is beetje dat we hier mogelijk niet al te lang meer zitten en ik dan gewoon meer mogelijkheden heb met losse APs. Ook begrijp ik dat beide in-wall's per 31/3 EOL zijn, dat vind ik wel wat problematisch.

In het worst case geval hang ik de settopbox in de woonkamer direct aan de switch en dan het AP terug in de meterkast/halletje.
Boven wordt de settopbox eigenlijk nooit voor live-tv gebruikt dus dat is minder een probleem. In het echte worst case scenario desnoods maar een extra UTPtje bijtrekken.

[loeberce]

Boudewijn schreef op vrijdag 8 januari 2021 @ 23:54:
[...]

Ja dat snap ik. Goed advies. Punt is beetje dat we hier mogelijk niet al te lang meer zitten en ik dan gewoon meer mogelijkheden heb met losse APs. Ook begrijp ik dat beide in-wall's per 31/3 EOL zijn, dat vind ik wel wat problematisch.

In het worst case geval hang ik de settopbox in de woonkamer direct aan de switch en dan het AP terug in de meterkast/halletje.
Boven wordt de settopbox eigenlijk nooit voor live-tv gebruikt dus dat is minder een probleem. In het echte worst case scenario desnoods maar een extra UTPtje bijtrekken.

Alleen de Pro is straks EOL volgens mij; de gewone en HD niet.

[Boudewijn]

De gewone ook helaas:

What This Means:

The following UniFi Access Point (AP) models will no longer receive new system releases, critical bug fixes, or security updates after March 1, 2021:

UAP-Outdoor
UAP-Outdoor+
UAP-Pro
UAP-IW
UAP (v1+v2)
UAP-LR (v1+v2)
UAP-AC-EDU
UAP-AC-IW-PRO
These UniFi AP models will continue to be supported by network controllers that have not upgraded to versions released past the obsoletion date (March 1, 2021). These AP models will still remain visible in controllers that are upgraded beyond the obsoletion date, but they will no longer be configurable.


https://community.ui.com/...9d-49f4-85b9-b6aa54659ef7

[lolgast]

Dat is de oude. De huidige 'gewone' is de UAP-AC-IW

[Bruzski]

Falcon10 schreef op dinsdag 5 januari 2021 @ 06:33:
[...]


Dat zwarte opvulunit stuk onder je onderste Unifi vervangen door zo'n opvulstuk met borstels waar je de kabels kan doorvoeren ?

zo’n opvulstuk met borstels is erg mooi, ik heb het voorlopig zo even opgelost..

[xbeam]

Thoit schreef op vrijdag 8 januari 2021 @ 12:21:
Wellicht dat hier mij iemand kan helpen. Sinds een aantal dagen heb ik een Unifi Dream Machine. Hiervoor heb ik een aantal port forwards ingesteld die ik wil disablen zodra ik ze niet gebruik. Middels PowerShell wil ik tegen de API kunnen aanpraten.

Ik kan inmiddels verbinding maken met de API, want ik kan de port forwarding rules ophalen. Dit kan ik middels het volgende commando:

code:

$a = Invoke-RestMethod -Uri 'https://<IPADRES>/proxy/network/api/s/default/rest/portforward' -Method get -WebSession $s -ContentType "application/json" -Headers $headers
$a | ConvertTo-Json | Write-Output

Ik heb de rule disabled en gekeken in developer mode in mijn browser wat die doet. Het is in feite hetzelfde als het ophalen van de rule, alleen doe je een put ipv get en voeg je de ruleid in de url toe. Als ik dit vertaal naar mijn script zou ik op het volgende moeten uitkomen:

code:

$params = @{
    'enabled' = 'false';
}
$body = $params | ConvertTo-Json

Invoke-RestMethod -Uri 'https://IPADRES/proxy/network/api/s/<sitename>/rest/portforward/IDVANRULE' -Method put -Body $body -WebSession $s -ContentType "application/json" -Headers $headers

Echter blijf ik hierbij de volgende foutmelding krijgen: Invoke-RestMethod : Not Found

Wat ik reeds gedaan heb:
- Volledige body meegestuurd i.p.v. alleen enabled = false
- De volgende wiki vaak doorgelezen: https://ubntwiki.com/products/software/unifi-controller/api
- Verschillende URLs geprobeerd
- Met de user waarmee ik tegen de API aanpraat de rule enabled / disabled zodat ik zeker weet dat die rechten heeft
- Firmware upgrade

Op een gegeven moment dacht ik, ik probeer middels de API een nieuwe rule aan te maken. Echter krijg ik daarbij ook dezelfde foutmelding.

Hopelijk is er hier iemand die mij hiermee kan helpen?

Log je wel in om de api post uit te voeren ?

[Thoit]

xbeam schreef op zaterdag 9 januari 2021 @ 03:03:
[...]


Log je wel in om de api post uit te voeren ?

Yes, anders krijg je een unauthorized melding

[Miki]

Boudewijn schreef op zaterdag 9 januari 2021 @ 00:41:
De gewone ook helaas:

What This Means:

The following UniFi Access Point (AP) models will no longer receive new system releases, critical bug fixes, or security updates after March 1, 2021:

UAP-Outdoor
UAP-Outdoor+
UAP-Pro
UAP-IW
UAP (v1+v2)
UAP-LR (v1+v2)
UAP-AC-EDU
UAP-AC-IW-PRO
These UniFi AP models will continue to be supported by network controllers that have not upgraded to versions released past the obsoletion date (March 1, 2021). These AP models will still remain visible in controllers that are upgraded beyond the obsoletion date, but they will no longer be configurable.


https://community.ui.com/...9d-49f4-85b9-b6aa54659ef7

Edit.. nevermind het is nog vroeg, slaap gerust verder

[ Voor 14% gewijzigd door Miki op 09-01-2021 08:59 ]

[agitri]

Ernste schreef op vrijdag 8 januari 2021 @ 21:31:
[...]


Ik heb T-Mobile Thuis over het KPN network (GPON?). Zijn er nog specifieke specs waaraan de SFP adapter en kabel moeten voldoen?

Mag gewoon een single mode sfp zijn ik heb er een cisco in zitten

[Gunner]

TheMystery schreef op woensdag 6 januari 2021 @ 16:34:
[...]


Probleem ook gehad en als volgt opgelost:
https://help.ui.com/hc/en...Fi-USW-Flex-Mini-Recovery
Na deze procedure heb ik hem normaal kunnen updaten als er weer een nieuwere update was.

En @Nnoitra .... kwam op het UI forum iemand tegen die het opgelost had door het apparaat op DHCP te zetten (mijne had ook een static IP). Custom upgrade gedaan en toen update hij wel

[RobertMe]

agitri schreef op zaterdag 9 januari 2021 @ 10:12:
[...]


Mag gewoon een single mode sfp zijn ik heb er een cisco in zitten

En welke stekker/connector? En moet het dan BiDi zijn? En welke TX/RX frequenties? In glasvezel SFP land is de keuze reuze. Zelf heb ik overigens geen glasvezel, of ja, sinds kort wel in huis van kelder naar zolder, maar geen FttH, dus de antwoorden op de vragen weet ik ook niet.

[VHware]

Bij verschillende providers had ik deze specificaties voorbij zien komen:

1Gbit (1000Base-BX-10-U)
SFP specificaties: TX 1310 nm , RX 1490/1550 nm
Type Fiber: singlemode Fiber (9/125) met SC/PC connector (blauw) of SC/APC (groen)

[ed1703]

MdBruin schreef op vrijdag 8 januari 2021 @ 20:46:
[...]


De Unifi schil lijkt dus de beperking te veroorzaken, hardware technisch zit er niet heel veel verschil tussen de EdgeRouter 3 en de USG. Ik heb ervaring met de ER3 welke behoorlijk sneller was als de USG. De USG is ondertussen al weer vervangen voor een EdgeRouter 4, de 3 lite is bij OpenVPN te beperkend qua doorvoersnelheid.

100% niet. De hardware is eigenlijk 1 op 1 hetzelfde. Dan zou het moeten zitten in de software-binaries die UI heeft toegevoegd in EdgeOS. OpenVPN is wel logisch, want die kan niet (daar issie weer) geoffload worden.

Wat men zou moeten kopen is gewoon een router in een NUC met een celeron, die zijn krachtig genoeg voor dat soort zaken. AES-NI zorgt voor genoeg performance om openvpn en andere tunnels zonder grote problemen te gebruiken.

De UDM heeft echter vziw ook weer geen AES-NI, wat je toch wel mag verwachten. Dit zorgt uiteraard wel weer voor een hogere prijs als ze dit zouden faciliteren.

[ Voor 255% gewijzigd door ed1703 op 09-01-2021 11:02 ]

[RobertMe]

ed1703 schreef op zaterdag 9 januari 2021 @ 10:44:
[...]

100% niet. De hardware is eigenlijk 1 op 1 hetzelfde. Dan zou het moeten zitten in de software-binaries die UI heeft toegevoegd in EdgeOS. OpenVPN is wel logisch, want die kan niet (daar issie weer) geoffload worden.

Wat men zou moeten kopen is gewoon een router in een NUC met een celeron, die zijn krachtig genoeg voor dat soort zaken. AES-NI zorgt voor genoeg performance om openvpn en andere tunnels zonder grote problemen te gebruiken.

De UDM heeft echter vziw ook weer geen AES-NI, wat je toch wel mag verwachten. Dit zorgt uiteraard wel weer voor een hogere prijs als ze dit zouden faciliteren.

Van de andere kant kun je natuurlijk ook zeggen dat diegenen die een VPN willend raaien (server of client) dat natuurlijk ook op een dedicated apparaat kunnen doen. Want als je betere hardware erin zet alleen voor de VPN use case dan betaalt 100% van de gebruikers voor een feature die wellicht maar door 25% wordt gebruikt.

En daarnaast heeft UI al genoeg problemen om basisfunctionaliteiten op te nemen in de controller (zoals s-nat, d-nat etc). Laat staan dat ze daar ook nog verschillende VPN types moeten ondersteunen. Want nu zit wel IPSEC/L2TP erin, maar vervolgens willen er weer OpenVPN hebben, tegenwoordig is Wireguard weer een hot topic, etc. Dan heb ik liever dat het er gewoon niet in zit en je er zelf maar iets voor moet verzinnen als je een VPN wilt draaien. Want uiteindelijk kun je nog altijd een NUCje plaatsen met Linux erop en een VPN server en dan de port forwards aanmaken naar die NUC. Of andersom een NUC met een VPN client en static routes opnemen om verkeer voor de VPN naar die NUC te sturen.

[ed1703]

RobertMe schreef op zaterdag 9 januari 2021 @ 11:35:
[...]

Van de andere kant kun je natuurlijk ook zeggen dat diegenen die een VPN willend raaien (server of client) dat natuurlijk ook op een dedicated apparaat kunnen doen. Want als je betere hardware erin zet alleen voor de VPN use case dan betaalt 100% van de gebruikers voor een feature die wellicht maar door 25% wordt gebruikt.

De kracht van een site-to-site VPN is juist dat je dan geen extra software op clients hoeft te draaien.
Heb je meerdere devices in huis die daarvan gebruiken willen maken, dan hoef je alles maar 1x uit te voeren.
25% met je eens, echter is dat voor heel veel functionaliteit in Unifi en ook de Edgemax-routers in algemene zin.

En daarnaast heeft UI al genoeg problemen om basisfunctionaliteiten op te nemen in de controller (zoals s-nat, d-nat etc). Laat staan dat ze daar ook nog verschillende VPN types moeten ondersteunen. Want nu zit wel IPSEC/L2TP erin, maar vervolgens willen er weer OpenVPN hebben, tegenwoordig is Wireguard weer een hot topic, etc. Dan heb ik liever dat het er gewoon niet in zit en je er zelf maar iets voor moet verzinnen als je een VPN wilt draaien.

UI staat er om bekend zich behoorlijk onder druk te laten zetten door de community om zaken toch te implementeren, met als gevolg een hoop teleurstelling op reddit en de community. Ik ben dat verder met je eens.

[RobertMe]

ed1703 schreef op zaterdag 9 januari 2021 @ 11:51:
[...]

De kracht van een site-to-site VPN is juist dat je dan geen extra software op clients hoeft te draaien.
Heb je meerdere devices in huis die daarvan gebruiken willen maken, dan hoef je alles maar 1x uit te voeren.
25% met je eens, echter is dat voor heel veel functionaliteit in Unifi en ook de Edgemax-routers in algemene zin.

Nu heb ik me er niet 100% in verdiept controller wise. Maar je kunt toch een VPN client op bv een NUC draaien, en dan in de controller instellen dat verkeer naar bv 172.16.0.0/24 een static route naar die NUC heeft? En dat de NUC het dan over de tunnel gooit.

Zelf heb ik op mijn thuisserver een VM draaien met een VPN client, die draait in een eigen VLAN en in de controller heb ik bij dat VLAN de default gateway op het IP van die VM gezet. Alle verkeer van apparaten in dat VLAN gaat dan ook mooi via de VPN.
En volgens mij kun je in de controller ook iets met static routes doen? Dus waarschijnlijk kun je daarin ook instellen om een subnet via een server / NUC met een VPN client te laten lopen.
En ja, dat is meer werk om (zelf) te doen, maar dan kun je het wel op krachtigere hardware draaien, zelf de VPN implementatie kiezen (IPSEC/L2TP, OpenVPN, Wireguard, ...).

In die zin heb ik zoiets van: fijn dat het in de USG zit (en client VPN gebruik ik ook om met telefoon van buitenaf te verbinden). Maar als het er niet op zat zijn er voldoende mogelijkheden om het zelf te doen en is de USG (/UDM) niet de limiteerde factor. Alleen kennis / tijd is dan een probleem.
Terwijl iets als S-NAT of D-NAT in bepaalde gevallen wel echt vereist zijn (bv het hele DNS redirecten verhaal), en dat wordt (ook) niet ondersteund. Dat ze dan eerst maar de tijd steken in functionaliteiten die echt in de router moeten zitten en waarvoor geen work-a-round is. I.p.v. eerst tich verschillende VPN implementaties inbakken, evt. krachtigere hardware gebruiken alleen voor het encryption verhaal, etc. Terwijl iedereen vrij is om een VPN op een ander stuk hardware te draaien en dat net zo goed werkt (gebruikersgemak in setup daargelaten).

[agitri]

RobertMe schreef op zaterdag 9 januari 2021 @ 10:30:
[...]

En welke stekker/connector? En moet het dan BiDi zijn? En welke TX/RX frequenties? In glasvezel SFP land is de keuze reuze. Zelf heb ik overigens geen glasvezel, of ja, sinds kort wel in huis van kelder naar zolder, maar geen FttH, dus de antwoorden op de vragen weet ik ook niet.

Deze

https://www.fs.com/de-en/products/39135.html

[serial_killa159]

Bruzski schreef op zaterdag 2 januari 2021 @ 22:31:
[...]


G4 deurbel werkt hier prima op 39dBm, ook komen de notificaties direct op mijn iPhone echter na de laatste update openen de notificaties met een zwart scherm, helaas zijn hier meer meldingen over.

Unifi Protect iOS black screen when opening notification
https://community.ui.com/...d4-4196-940a-95fff51123a0

ook mist de IOS app de optie om notificaties terug te zien wie er aangebeld heeft, op de android van mijn vrouw zijn deze wel zichtbaar.

[Afbeelding]

Dat zwart scherm heb ik ook al ontdekt met de camera's, hoop dat er snel een update komt van de app die dit oplost. Soms gaat de app wel open zonder zwart scherm maar verder kom je niet, hij blijft hangen in het beginscherm en de motion event speelt niet af.

Heb het risico genomen en de deurbel gisteren online besteld in de US. Zie er al naar uit

[Polyphemus]

serial_killa159 schreef op zaterdag 9 januari 2021 @ 12:29:
[...]

Heb het risico genomen en de deurbel gisteren online besteld in de US. Zie er al naar uit

Met welke bedrijf laat je hem 'shippen'?

[JayOne]

Gunner schreef op zaterdag 9 januari 2021 @ 10:29:
[...]

En @Nnoitra .... kwam op het UI forum iemand tegen die het opgelost had door het apparaat op DHCP te zetten (mijne had ook een static IP). Custom upgrade gedaan en toen update hij wel

Zelf had ik dit probleem ook en heb nadat de firmware stable is gegaan, de firmware eerst in het cache geladen en daarna werkte de update wel. @Nnoitra

[serial_killa159]

Polyphemus schreef op zaterdag 9 januari 2021 @ 12:50:
[...]

Met welke bedrijf laat je hem 'shippen'?

Ik heb besteld via b&h Video, die versturen naar europa. Verzendingskost is iets van $21.