Lange wifi associatie tijden + timeouts

[Tha Render_2]

Ik heb ergens een Unifi setup draaien met: UDM-PRO + USW-24-POE-Gen2 + 5x NanoHD + 5x U6 Pro. Alles laatste firmware.

In totaal een +/- 200 wifi clients, voornamelijk chromebooks & smartphones. Alles ingesteld volgens best practices:

- Non-overlapping channels + channel width 20mhz (snelheid is niet belangrijk, stabiliteit wel)
- Zendsterkte naar beneden gehaald tot het voldoende is voor goede dekking
- Auto-optimize uit
- Slechter dan -80dbm krijgen clients een soft kick
- Bandwidth profile ingesteld zodat niet 1 iemand heel de lijn kan dicht trekken
- Block multicast & broadcast
- DHCP scope is /23 dus 510 ip adressen beschikbaar

Cru gezegd, er zit ergens een probleem in het netwerk maar ik kan het niet vinden. Clients doen er enorm lang over om een IP adres te krijgen van de UDM-PRO en soms krijgen ze zelf geen, maar geeft het OS van de client wel aan dat ze verbonden zijn. Als je dan verbonden bent en je doet een speedtest kan dat soms 80mbps zijn en soms 1mbps.

Als ik daar alleen ben met mijn laptop is er natuurlijk geen probleem, ik krijg direct een IP en speedtest is max volgens bandwidth profile, ook 100% stabiel, 1u lang ping test -> 0% verlies. Maar vanaf er een hoop clients verbonden zijn, tussen de 100 en 200, beginnen de problemen.

De internetlijn is een 1000/50mbps connectie dus voldoende. Ik zie in de Unifi GUI ook geen WAN pieken, max is 180mbps, dus het is niet dat ze de lijn voltrekken. Ook in de 'clients' tab als je sorteert op traffic blijft dat laag.

Ik vermoed dat er ergens een toestel heel de airtime verstoord, maar ik kan het niet vinden.. In de GUI kan ik o.a. zien, enkel laatste uur:



Akkoord dat die cijfers bij Unifi nooit echt deftig gewerkt hebben maar het is een indicatie denk ik, op 1u tijd meer dan 1000 associatie timeouts. Helaas kan je niet verder kijken over welke toestellen het bijvoorbeeld gaat, misschien komt dit allemaal van 1 en dezelfde stoorzender? Maar hoe kan ik dat uitzoeken? Ik heb al wat scriptjes gevonden die je kan uitvoeren via SSH op een AP om zo hopelijk een MAC address te vinden van het toestel dat moeilijk doet maar misschien is het toch iets anders. Het is ook overal in het netwerk, maakt niet uit met welke van de 10 AP's dat je verbonden bent.

Iemand tips hoe ik dieper en geavanceerder kan troubleshooten?

[Ben(V)]

Ik vermoed dat je gewoon te veel clients hebt die al de beschikbare airtime opeten met alleen het onderhouden van enkel de connectie.

Voor een NanoHd geld een theoretisch maximum van 200 clients en unifi adviseert een max van 125.
Maar in de praktijk is een stuk of 40 per radio al niet meer werkbaar.

[Voor 3% gewijzigd door Ben(V) op 14-02-2023 12:05]

[dion_b]

Hamvraag: hoe zijn die 200 clients over de beide banden van de 6 AP's verdeeld?

Als ze perfect gelijkmatig verdeeld zijn over 5GHz, heb je 32 op 5GHz per AP, wat prima te doen moet zijn. Als daarentegen de ene AP 150 heeft en de andere 5 AP's slechts 10 elk, dan kun je dit krijgen op die drukke.

Als significante hoeveelheden op 2.4GHz zitten is dat bij voorbaat een probleem.

- Slechter dan -80dbm krijgen clients een soft kick

Dit is veel te laag, onder de -75dBm heb je geen bruikbare verbinding over. Als je overal goede dekking hebt zou je dit eerder rond de -67dBm moeten zetten zodat alle verbindingen gelijk ook goede zijn.

[Tha Render_2]

Clients per AP is redelijk mooi verdeeld, de hoogste zit op 40 clients momenteel, is een U6-Pro. Al de rest zit tussen de 20 à 30 clients per AP. Zou ik dan niet de problemen zien bij enkel die AP's die "zwaar" belast zijn? Er is momenteel 1 AP die maar 1 client heeft, zou die dan normaliter wel vlot moeten gaan? (Kan ik morgen ter plaatse testen)

2.4ghz staat nog actief, een 25-tal clients zitten daar momenteel op, en 150 clients op 5ghz. Ik zou kunnen proberen om de 2.4ghz volledig uit te zetten. Er zijn nog enkele touchscreen TV's die enkel op 2.4ghz werken, die had ik al op een aparte SSID "Legacy" gestoken.

Ik heb de indruk dat héél het netwerk naar beneden getrokken wordt, en dat vind ik zo bizar. Als ik inlog op de UDM-PRO en een speedtest toe, dan werkt die gewoon 50% van de tijd niet, krijg ik een timeout, en helft van de tijd geeft die aan 50mbps ofzoiets. Als ik dan vanavond diezelfde test vanaf de UDM-PRO zou doen, zonder wireless clients verbonden, start die meteen en geeft die +/- 970mbps aan. Dus zelf de UDM-PRO heeft er last van..

Verbruik van de UDM-PRO lijkt mij ok te zijn:



Vandaar dat ik meer neig naar multicast/broadcast/ddos verkeer, gezien de UDM-PRO er blijkbaar ook last van heeft, gezien de WAN speedtest die in de soep loopt als er veel wireless clients verbonden zijn. Block multicast/broadcast staat actief.

Maar op zich werkt het allemaal wel want per dag is er +/- 90GB traffiek.. Zaken zoals torrents & P2P etc worden allemaal geblokkeerd door rules in de UDM-PRO.

[Voor 12% gewijzigd door Tha Render_2 op 14-02-2023 12:36]

[laurens0619]

Hmm als je inlogt op de UDM-PRO en vanuit daar werkt een speedtest niet dan denk ik dat het probleem in de udm zit en niet in je switches/ap. Ik neem aan dat je vanuit UDM direct met kabeltje het internet op gaat en niet langs je lokale lan infra komt?

De cpu load lijkt inderdaad mee te vallen maar ik zou verder onderzoeken waarom die speedtest ook al faalt.
Misschien iets met DPI? Zet die blokkade rules eens uit bijvoorbeeld.
Of de bekende "experimenteer met andere firmware versies" op je udm

[Voor 7% gewijzigd door laurens0619 op 14-02-2023 12:47]

[Tha Render_2]

Worth a try, ik heb alle block rules verwijderd en nu werkt de speed test vanuit de UDM PRO wel naar behoren.. Kan toeval zijn, ik bekijk even wat het in de praktijk oplevert (buiten dat er weer massaal zal getorrent worden )

[laurens0619]

Dat zou mooi zijn

en jammer...

UNIFI: here's some networking equipment with tons of features

Also UNIFI: Please disable all of those features if you want a stable system.

Ben bang dat dit soms wel beetje waar is bij unifi

[SVMartin]

Tha Render_2 schreef op dinsdag 14 februari 2023 @ 14:04:
Worth a try, ik heb alle block rules verwijderd en nu werkt de speed test vanuit de UDM PRO wel naar behoren.. Kan toeval zijn, ik bekijk even wat het in de praktijk oplevert (buiten dat er weer massaal zal getorrent worden )

Ik wist niet dat torrents nog zo populair waren?

Wellicht kun je een pihole draaien met deze lijst:

https://github.com/SM443/Pi-hole-Torrent-Blocklist

En in de firewall al het verkeer naar buiten op poort 53 redirecten naar de pihole. (Ook dns over tls blokkeren)

Zal nooit volledig alles tegenhouden, maar wellicht ontmoedigt het wat..