Waarom een modern thuisnetwerk technisch gezien een klein enterprise netwerk is.
Herken je dit?
Je hebt een prima internetabonnement, maar toch hapert de wifi. Streaming- en bel-apps stotteren, video’s bufferen eindeloos, en je telefoon meldt “beperkt bereik” terwijl je onder het access point staat. De IP-televisie pixelt bij het zappen, en je slimme lampen reageren soms wel en soms niet. Dat komt vaak niet door te weinig snelheid, maar door de complexe wirwar van slimme apparaten in huis.
Moderne IoT-gadgets (Alexa, Hue-lampen, smart-TV’s, camera’s, robot-stofzuigers, etc.) spuwen continu multicastverkeer en openen poorten (UPnP) op het netwerk. Kleinigheden als een verkeerd VLAN, een goedkope switch zonder IGMP snooping of ingeschakelde ‘broadcast’ kunnen het netwerk razendtraag maken of onveilige poorten openzetten. Mesh-systemen die standaard draadloos backhaul gebruiken verergeren het probleem als ze niet goed zijn geconfigureerd.
In dit artikel leggen we uit waaróm een thuisnetwerk tegenwoordig technisch gezien een klein enterprise netwerk is, wat de belangrijkste valkuilen zijn, en welke best practices je kunt toepassen. Denk aan IoT-segmentatie, IGMP-filtering, juiste switch-keuze, mesh-configuratie en slimme wifi-instellingen. Het doel: een netwerk dat doet wat je verwacht, zonder onverklaarbare haperingen.
Sterk wifi signaal, geen data
Je ziet je smartphone connecten met volle balkjes, maar webpagina’s laden langzaam of helemaal niet. Spotify spoelt haperend, Netflix buffert. Een upgrade van het abonnement hielp niet. Het probleem zit niet in de snelheid van je provider, maar in het feit dat de beschikbare zendtijd van je wifi-radio wordt opgeslokt door apparaten die je niet eens actief gebruikt.
Apparaten ‘zien’ elkaar niet
De lampen reageren niet op je telefoon, of je kunt de beveiligingscamera niet benaderen. Sonos-speakers spelen alleen muziek als je telefoon óók op datzelfde netwerk zit. Zodra je apparaten op een apart VLAN zet voor veiligheid, stoppen discovery-protocollen (zoals Bonjour en SSDP) met werken over de netwerksegmenten heen. Je hebt dan een veiliger netwerk, maar je apparaten kunnen elkaar niet meer vinden.
IP-televisie hapert en pixelt
Bij het zappen duurt het lang voordat het beeld opkomt, of je ziet blokvorming en stotterend beeld. Dit komt doordat IPTV volledig via multicast werkt. Eén HD-kanaal verbruikt typisch 8 tot 15 Mbit/s. Zonder IGMP snooping op je switches wordt die volledige stream naar álle poorten doorgestuurd, ook naar apparaten die helemaal geen televisie kijken. Dat vreet bandbreedte en veroorzaakt congestie op het hele netwerk.
Wifiluisteren en airtime-gevechten
Metingen laten zien dat de 2.4 GHz-band bijna 100% in gebruik is, terwijl er amper werkelijke data wordt verzonden. De zendtijd wordt opgegeten door management-frames, multicast-pakketten en trage IoT-apparaten die op de laagste snelheid zenden. Als je installateur binnenkomt, merkt hij direct dat er “iets knap mis” is met het spectrum.
Netwerk ‘spam’
Je plugt elk apparaat blind op het netwerk, en de router ziet er steeds meer. Elke nieuwe smart-plug, lamp of camera voegt multicast-berichten toe aan het netwerk. Plots ontstaat latency, packet loss, of het netwerk gaat zelfs plat. Vooral als er ergens in de keten een unmanaged switch zit die al dat verkeer naar alle poorten doorstuurt.
Mesh maakt het erger in plaats van beter
Je koopt een mesh-systeem omdat je wifi-dekking te wensen overlaat. Maar het mesh-systeem gebruikt standaard draadloos backhaul: het stuurt al het verkeer via dezelfde wifi-radio’s door naar het volgende knooppunt. Dat betekent dat jouw data twee keer (of vaker) over de lucht moet, waardoor de beschikbare bandbreedte per hop halveert. In een huis dat al bedraad is met ethernetkabels, voegt draadloos mesh alleen maar overhead toe.
Al deze frustraties hebben niets met de snelheid van je provider te maken, maar met hoe de apparaten samen het netwerk gebruiken. Dit begrijpen is de eerste stap naar oplossing.
Wi-Fi airtime is de bottleneck
Een Wi-Fi-kanaal heeft een beperkte tijdsdelingscapaciteit, de zogenaamde airtime. Slechts één apparaat mag tegelijk zenden of ontvangen op dezelfde radio. Als een apparaat data via 1 Mbps verstuurt (basissnelheid 2.4 GHz), dan blokkeert het de hele 600 Mbps (of meer) die andere apparaten zouden kunnen gebruiken. Zie het als een smalle eenbaansweg: zelfs langzaam verkeer verhindert snellere auto’s om vooruit te komen. Het cruciale inzicht hier is dat airtime per radio wordt gedeeld, niet per SSID. Alle apparaten op dezelfde fysieke radio concurreren om dezelfde zendtijd, ongeacht op welk netwerknaam (SSID) ze zijn ingelogd.
Multicast en mDNS kosten onevenredig veel airtime
Veel IoT-apparaten gebruiken multicast (bijv. Bonjour/mDNS of SSDP) om elkaar te ontdekken op het netwerk. Dergelijke pakketten worden op het laagst mogelijke wifi-rate verzonden (bij 2.4 GHz soms 1 of 6 Mbps), en naar alle verbonden clients tegelijk. Stel: een slimme lamp stuurt elke seconde een klein mDNS-pakketje van 50 bytes. Dat klinkt verwaarloosbaar, maar bij 1 Mbps kost dat pakketje alweer ~0,4 ms zendtijd per access point. En alle AP’s in huis herhalen dit voor elk aangesloten apparaat. Heb je twintig IoT-apparaten die dit doen, dan loopt de totale airtime-belasting snel op. Volgens Ubiquiti is enkele honderden Kbps aan mDNS-verkeer equivalent aan honderden Mbps unicast qua airtimeverbruik. Kortom: een handjevol mDNS kan het netwerk volledig domineren, zonder dat je het in je bandbreedtemonitor terugziet.
IoT (on)veiligheid door UPnP/PNP
Smart-apparaten gebruiken vaak UPnP (Universal Plug and Play) om automatisch poorten open te zetten op je router. Dat is handig voor de gebruiker, maar ook gevaarlijk: zo’n apparaat kan onbedoeld een gat in je firewall slaan. Er zijn bekende incidenten waarin kwaadwillenden via een ONVIF/UPnP-koppeling slimme camera’s binnendringen of gerichte advertenties injecteren. TrendMicro waarschuwt dat 76% van routers nog steeds UPnP aan heeft staan, vaak met exploits tot gevolg. Zonder netwerksegmentatie lopen al je netwerkverkeer en persoonlijke gegevens kans om via kwetsbare IoT-apparaten te lekken naar buiten.
VLAN- en SSID-segmentatie zorgt voor onvindbaarheid
Je splitst een IoT-netwerk op een apart VLAN voor veiligheid. Maar Sonos, Chromecast en AirPlay controller-apps zijn niet VLAN-aware: ze zenden hun discovery-protocol alleen binnen het eigen netwerksegment uit. Resultaat: je gaat op zoek naar apparaten die je niet kan vinden. Fabrikanten lossen dit op met mDNS/Bonjour gateways of proxies, maar in veel thuissettings ontbreekt die configuratie. Dan belandt de oplossing vaak in een compromis: ofwel alle Sonos-speakers en telefoons op hetzelfde netwerk zetten (minder veilig), ofwel ingewikkelde forwarding-regels bouwen. UniFi heeft hiervoor inmiddels een mDNS-forwarder, en Cisco WLC’s bieden mDNS Gateways.
AirTime is het kostbaarste goed op Wi-Fi
Een korte rekensom: een video van 5 MB streamen kost bij 100 Mbps minder dan een seconde airtime. Maar datzelfde pakket via multicast op de basisrate van 1 Mbps is ineens tientallen seconden bezig. Omdat multicasts en broadcasts naar alle clients worden gestuurd zonder ontvangstbevestiging, is er geen flow-control: het access point blijft maar zenden. Elk AP herhaalt dit bovendien voor alle toestellen in zijn bereik. Zie het zo: de snelheid van je wifi wordt afgestemd op de langzaamste ontvanger in de groep.
Radio versus SSID: het fundamentele verschil
Dit is het meest misverstane punt bij thuisnetwerken. Een Wi-Fi access point heeft fysieke radio’s: typisch één voor 2.4 GHz en één voor 5 GHz. Een SSID (netwerknaam) is slechts een virtuele laag bovenop die radio. Als je drie SSID’s aanmaakt (Home, IoT, Gast), draaien die alle drie op dezelfde fysieke radio. Ze delen exact dezelfde airtime. Een apart SSID creëert wel een gescheiden broadcast-domein op layer 2, waardoor multicast-pakketten van het ene SSID niet naar clients op het andere SSID worden doorgestuurd. Maar de radio-airtime wordt nog steeds gedeeld: als het IoT-SSID op 2.4 GHz continu multicast zendt, heeft elk ander SSID op diezelfde 2.4 GHz radio daar direct last van.
De echte oplossing is daarom frequentiescheiding: zet IoT op 2.4 GHz en stuur gebruikers via bandsteering naar 5 GHz. Dan zitten ze op twee fysiek gescheiden radio’s en concurreren ze niet meer om dezelfde zendtijd. Dát is het verschil dat werkt, niet simpelweg een extra SSID aanmaken.
Beacon frames: de verborgen kosten van meerdere SSID’s
Elke SSID zendt ongeveer tien keer per seconde (elke 102,4 ms) een beacon frame uit. Dit is een management-pakket waarmee het access point aankondigt: “ik besta, en dit zijn mijn mogelijkheden.” Beacon frames worden altijd verzonden op de laagst geconfigureerde basic rate, zodat zelfs de oudste apparaten ze kunnen ontvangen. Op 2.4 GHz is die standaardsnelheid vaak 1 Mbps.
Een concreet voorbeeld: één beacon van circa 300 bytes op 1 Mbps kost ongeveer 2,4 ms zendtijd. Dat klinkt weinig, maar met vier SSID’s op één radio wordt dat vier beacons per interval. Per seconde zijn dat 40 beacon-transmissies. Volgens metingen van Wi-Fi-expert Andrew von Nagy kost dit tot 11% van de totale beschikbare airtime, puur aan beacons. Daar is nog geen enkele client bij ingelogd en er is nog geen byte aan gebruikersdata verstuurd.
De oplossing is tweeledig. Ten eerste: verhoog de minimale basic rate naar 12 Mbps of hoger. Hierdoor worden beacons vijf tot twaalf keer sneller verzonden, en daalt de overhead naar minder dan 1%. Ten tweede: beperk het aantal SSID’s tot maximaal drie per radio. Wi-Fi 6 (802.11ax) introduceert daarnaast Multiple BSSID, een techniek waarbij meerdere SSID’s in één enkel beacon frame worden aangekondigd. Dit kan de beacon-overhead met meer dan de helft verlagen.
Waar eenrichtingsverkeer anders gaat
Bij unicast (normaal verkeer van punt A naar punt B) kan de zender met kortstondige bursts op hoge snelheid alles eruit persen, waarna de radio vrijkomt voor het volgende apparaat. Bij multicast wordt elk pakket continu op de laagste rate verspreid, en niemand bevestigt de ontvangst. Er is dus geen feedback-mechanisme: de airtime blijft continu belast, zelfs als geen enkel apparaat het pakket daadwerkelijk nodig had.
De rollercoaster van segmentatie
Door IoT op VLAN30 te zetten en je telefoon op VLAN20, verdwijnen de IoT-broadcasts uit je gebruikersnetwerk. Dat is de winst op layer 2. Maar als beide VLAN’s op dezelfde fysieke radio zitten (bijv. beide op 2.4 GHz), concurreren ze nog steeds om dezelfde airtime. De gebruiker merkt het minder doordat de broadcast-pakketten niet meer naar zijn apparaat worden doorgestuurd, maar het medium blijft wel druk.
In de praktijk betekent dit: zet IoT op 2.4 GHz via een eigen SSID en zorg dat je telefoon en laptop op 5 GHz zitten via bandsteering. Zo profiteer je van zowel layer 2 isolatie (gescheiden broadcast-domein) als fysieke radioscheiding (gescheiden airtime). Dat is de combinatie die werkt.
Waarom de switch er toe doet
Een switch lijkt een simpel apparaat: kabels erin, verkeer loopt. Maar bij multicast-verkeer maakt het type switch een wereld van verschil. Een unmanaged switch heeft geen enkele intelligentie rondom multicast. Omdat multicast-adressen nooit als bronadres voorkomen, leert de switch ze niet en komen ze nooit in de MAC-adrestabel terecht. Het gevolg: de switch behandelt elk multicast-pakket als broadcast en stuurt het naar alle poorten. Dit heet flooding.
In een thuisnetwerk met twee of drie unmanaged switches achter elkaar wordt dit probleem vermenigvuldigd. Elk multicast-pakket van elke IoT-lamp, elke Sonos-speaker en elke IPTV-stream wordt naar elk apparaat op elke switch gestuurd. De computer op zolder ontvangt de IPTV-stream van de decoder in de woonkamer, de printer in de studeerkamer wordt gebombardeerd met mDNS-pakketten van de keuken-speaker, en elk apparaat moet al die pakketten verwerken en weggooien. Dit kost CPU-tijd op elk aangesloten apparaat en vult de netwerkcapaciteit onnodig.
Managed switches en IGMP snooping
Een managed switch met IGMP snooping lost dit op. IGMP snooping luistert mee op het IGMP-verkeer tussen apparaten en de router. Wanneer een IPTV-decoder zich aanmeldt voor een multicastgroep (een TV-kanaal), noteert de switch op welke poort die decoder zit. Vanaf dat moment stuurt de switch de bijbehorende multicast-stream alleen naar die specifieke poort. Alle andere poorten worden met rust gelaten.
Zonder IGMP snooping wordt dus álle multicast-verkeer naar álle poorten gestuurd. Met IGMP snooping alleen naar de poorten die erom gevraagd hebben. Het verschil kan enorm zijn: een IPTV-setup met drie kanalen tegelijk is al 25 tot 45 Mbit/s aan multicast-verkeer. Zonder snooping gaat dat naar elk apparaat in je netwerk.
Fast Leave en de IGMP querier
Twee veelgemaakte fouten bij IGMP snooping. Ten eerste: Fast Leave niet aanzetten. Zonder Fast Leave blijft de switch na het wegzappen nog tot 60 seconden multicast doorsturen naar een poort die het niet meer nodig heeft. Met Fast Leave stopt dat direct. Ten tweede: geen IGMP querier configureren. IGMP snooping werkt alleen als er periodiek IGMP-queries worden verstuurd. Meestal doet de router dit, maar als de switch dat niet ziet (bijv. door VLAN-configuratie), stopt snooping met werken en valt de switch terug op flooding. Configureer daarom altijd één apparaat (bij voorkeur de router of één switch) als IGMP querier per VLAN.
Spanning Tree en loops
Een ander risico bij meerdere switches: netwerk-loops. Als je per ongeluk twee kabels trekt tussen dezelfde twee switches (of een kabel terugsteekt in dezelfde switch), ontstaat een broadcast-storm. Pakketten circuleren eindeloos rond en het netwerk gaat plat binnen seconden. Managed switches hebben Spanning Tree Protocol (STP) om dit te voorkomen: STP detecteert loops en schakelt automatisch overtollige paden uit. Unmanaged switches hebben die bescherming niet. Eén foutje in de bekabeling en je hele netwerk ligt eruit. Zet bij managed switches altijd edge-ports (portfast) aan op poorten naar eindapparaten, en BPDU guard om te voorkomen dat een aangesloten apparaat zich voordoet als switch.
Hoe IPTV werkt
IP-televisie, zoals aangeboden door KPN, T-Mobile Thuis en anderen, werkt via multicast. De provider stuurt elk TV-kanaal als één multicast-stream het netwerk in. De settopbox (of mediabox) meldt zich aan bij de gewenste multicastgroep via het IGMP-protocol. Concreet: als je zapt naar NPO 1, stuurt de decoder een IGMP Join-bericht naar de router. De router vertelt vervolgens het netwerk: “stuur de stream voor NPO 1 naar dit apparaat.” Bij wegzappen stuurt de decoder een IGMP Leave en stopt de stream.
Wat er misgaat in thuisnetwerken
In de keten van modem, router, switch en decoder moet elk apparaat correct met IGMP omgaan. Veelvoorkomende problemen zijn:
• De switch tussen router en decoder is unmanaged en stuurt de volledige IPTV-stream naar alle poorten. Bij drie HD-kanalen tegelijk (voor meerdere decoders) is dat 25-45 Mbit/s aan verkeer dat naar elk apparaat op het netwerk wordt geduwd.
• IGMP snooping staat wel aan op de switch, maar er is geen IGMP querier actief. Na verloop van tijd verliest de switch zijn snooping-tabel en valt terug op flooding.
• De decoder zit achter een tweede router (dubbel NAT), waardoor IGMP-berichten niet correct worden doorgestuurd naar de provider.
• Fast Leave staat niet aan, waardoor er bij het zappen een vertraging van tientallen seconden optreedt: de oude stream blijft lopen terwijl de nieuwe al is opgestart.
IGMP proxy op de router
De router speelt een sleutelrol bij IPTV. Hij moet als IGMP proxy functioneren: aan de WAN-kant meldt hij zich aan bij de multicast-streams van de provider, en aan de LAN-kant verdeelt hij die streams naar de juiste apparaten. Als de router geen IGMP proxy ondersteunt (of als die functie niet correct is geconfigureerd), komt de IPTV-stream simpelweg niet door. Dit is een veelvoorkomend probleem bij het vervangen van de provider-router door een eigen router: de IPTV-functionaliteit werkt niet meer omdat de IGMP-proxy niet is ingesteld.
De oplossing voor stabiele IPTV
Zorg dat de router IGMP proxy ondersteunt en correct is geconfigureerd voor je provider. Gebruik managed switches met IGMP snooping ingeschakeld op het VLAN waar IPTV-verkeer overheen loopt. Zet Fast Leave aan. Zorg voor een actieve IGMP querier. En sluit decoders bij voorkeur bedraad aan, niet via wifi: een HD-stream van 15 Mbit/s via wifi is op zich haalbaar, maar multicast over wifi is notoir onbetrouwbaar door het ontbreken van ontvangstbevestigingen.
Wat mesh belooft en wat het kost
Mesh-systemen zijn enorm populair geworden als oplossing voor wifi-dekking in huis. Het principe is simpel: meerdere access points vormen samen één netwerk en zorgen voor dekking in het hele huis. Apparaten roamen naadloos tussen de knooppunten. In de praktijk schuilt er een fundamenteel probleem in de standaardconfiguratie van de meeste mesh-systemen: draadloos backhaul.
Draadloos backhaul halveert je bandbreedte
Bij draadloos backhaul gebruikt het mesh-knooppunt dezelfde radio om zowel met jouw apparaat te communiceren als om het verkeer door te sturen naar het volgende knooppunt of de gateway. Omdat een radio maar één ding tegelijk kan (zenden óf ontvangen), moet elk pakket twee keer over de lucht: eerst van jouw apparaat naar het mesh-knooppunt, dan van het knooppunt naar de gateway. Dit halveert de effectieve bandbreedte per hop. Bij twee hops (drie mesh-knooppunten) hou je nog maar een kwart over. Heb je een verbinding van 500 Mbit/s op je router, dan kan een apparaat op het verste mesh-punt in theorie nog maar 125 Mbit/s halen, en in de praktijk vaak minder door overhead en gedeelde airtime met andere clients.
Sommige mesh-systemen hebben een dedicated backhaul-radio (een derde radio, vaak op 5 GHz of 6 GHz) die alleen voor het doorsturen van verkeer tussen knooppunten wordt gebruikt. Dit is aanzienlijk beter, maar voegt alsnog latency toe en is gevoelig voor dezelfde interferenceproblemen.
Bedraad backhaul: de beste oplossing
Als je huis al is voorzien van ethernetkabels (wat in veel Nederlandse woningen het geval is via de meterkast), is bedraad backhaul altijd de betere optie. Elk mesh-knooppunt wordt dan een volwaardig access point met een directe bedrade verbinding naar de kern van het netwerk. Er is geen airtime-verlies door backhaul, de latency is minimaal, en elke radio is volledig beschikbaar voor clients. In de praktijk kom je regelmatig netwerken tegen waar het huis volledig bedraad is, maar het mesh-systeem toch op draadloos backhaul staat. Dat is zonde: je verliest meer dan de helft van je wifi-prestaties zonder reden.
Roaming: 802.11r, 802.11k en 802.11v
Een ander aspect van mesh en meerdere access points is roaming: het naadloos overschakelen van het ene AP naar het andere als je door het huis loopt. In de praktijk is dit minder naadloos dan fabrikanten beweren. Wi-Fi is ontworpen als een client-gestuurd protocol: het apparaat beslist zelf wanneer het overstapt naar een ander AP. Veel apparaten houden veel te lang vast aan een zwak signaal (sticky clients) en schakelen pas over als de verbinding bijna onbruikbaar is.
Moderne protocollen helpen hierbij. 802.11r (Fast BSS Transition) versnelt de herverbinding door authenticatiesleutels alvast door te geven aan het volgende AP. 802.11k (Radio Resource Management) laat het AP een lijst met beschikbare buur-AP’s doorgeven aan de client, zodat die slimmer kan kiezen. 802.11v (BSS Transition Management) stelt het AP in staat om een client actief te adviseren om over te stappen naar een beter AP. Niet alle apparaten ondersteunen deze protocollen. Veel oudere IoT-apparaten kennen ze niet, wat leidt tot vastgeplakte verbindingen en slechte prestaties op afstand van het dichtstbijzijnde AP.
Zendvermogen: meer is niet altijd beter
Een veelgemaakte fout bij meerdere access points is het zendvermogen op maximaal zetten. Het idee lijkt logisch: hoe harder het AP zendt, hoe beter het bereik. Maar het apparaat van de gebruiker (een telefoon met een klein antennetje) zendt terug met veel minder vermogen. Het resultaat is asymmetrisch: je hoort het AP prima, maar het AP hoort jou nauwelijks. Bovendien zorgt een hoog zendvermogen ervoor dat clients te lang vasthouden aan een ver AP terwijl er een dichterbij AP beschikbaar is. Bij meerdere AP’s in huis is het beter om het zendvermogen te verlagen zodat elk AP een kleinere, scherpere cel heeft en clients sneller roamen naar het dichtstbijzijnde punt.
Dubbel NAT: router achter router
Een klassieke fout: je plaatst een eigen router achter de router van je provider, zonder de provider-router in bridge-mode te zetten. Het resultaat is dubbel NAT: je verkeer wordt twee keer vertaald. Internetten werkt prima, maar port-forwarding, VPN, gaming en IPTV kunnen mislukken. IGMP-multicast komt vaak niet door de tweede NAT-laag heen, waardoor IPTV stopt met werken. UPnP raakt in de war omdat twee apparaten allebei poorten proberen te beheren. De oplossing: zet de provider-router in bridge-mode of gebruik je eigen router als access point achter de provider-router.
Te veel SSID’s op één radio
Sommige gebruikers maken vijf, zes of meer SSID’s aan: voor elk gezinslid eentje, plus gast, plus IoT, plus camera’s. Elk SSID kost beacon-overhead. Bij de standaard basic rate van 1 Mbps op 2.4 GHz kan zes SSID’s al zo’n 15% van de airtime opeten, puur aan beacons. Houd het bij maximaal drie SSID’s per radio en verhoog de minimale basic rate.
2.4 GHz kanaalplanning: alleen kanaal 1, 6 of 11
Op de 2.4 GHz-band zijn er maar drie kanalen die niet met elkaar overlappen: 1, 6 en 11. Kies je een ander kanaal (bijv. 3 of 9), dan interfereer je met twee buurkanalen tegelijk. Dit heet co-channel interference en is erger dan het delen van een kanaal met een buur. Veel routers staan standaard op “auto” en kiezen soms verkeerde kanalen. Controleer dit handmatig en stel kanaal 1, 6 of 11 in.
DFS-kanalen op 5 GHz: onverwachte kanaalwisselingen
Op de 5 GHz-band zijn veel kanalen aangemerkt als DFS (Dynamic Frequency Selection). Deze kanalen worden gedeeld met radarinstallaties (luchtvaart, weer). Als het AP radaractiviteit detecteert, moet het onmiddellijk van kanaal wisselen. Dit duurt een paar seconden, en gedurende die tijd valt je wifi-verbinding weg. In de buurt van vliegvelden, havens of weerradarstations kan dit regelmatig voorkomen. Apparaten die verbonden waren op dat kanaal moeten opnieuw verbinding maken, wat merkbaar is als korte onderbrekingen. Kies bij voorkeur een niet-DFS kanaal (36, 40, 44, 48) als je stabiliteit belangrijker vindt dan maximale kanaalruimte. Houd er wel rekening mee dat niet-DFS kanalen drukker zijn omdat iedereen ze gebruikt.
DHCP-uitputting
Een standaard thuisrouter heeft een DHCP-pool van bijvoorbeeld 100 adressen. Met telefoons, laptops, tablets, smart-TV’s, game-consoles, Sonos-speakers, lampen, camera’s, stofzuigers, wasmachines en thermostaten is die pool bij een modern huishouden verrassend snel vol. Wanneer een nieuw apparaat geen IP-adres meer krijgt, werkt het niet. Dit uit zich in vage meldingen als “verbonden maar geen internet”. Vergroot de DHCP-pool of gebruik kortere lease-tijden zodat ongebruikte adressen sneller vrijkomen.
Verkeerd geplaatste access points
Wi-Fi signalen worden sterk gedempt door beton, metaal en water. Een AP in de meterkast (achter een metalen deur), in een tv-meubel of op de grond presteert dramatisch slechter dan een AP dat centraal, hoog en vrij is opgehangen. Muren, vloeren en zelfs aquariums zijn significante obstakels. Plaats access points centraal in het dekkingsgebied, op ooghoogte of hoger, en niet in een afgesloten kast.
Nieuwere Wi-Fi standaarden introduceren technologieën die een aantal van de hierboven beschreven problemen aanpakken. Maar ze zijn geen wondermiddel: een slecht geconfigureerd Wi-Fi 6 netwerk presteert slechter dan een goed geconfigureerd Wi-Fi 5 netwerk.
OFDMA (Orthogonal Frequency-Division Multiple Access)
Waar oudere standaarden het hele kanaal aan één apparaat tegelijk toewijzen, kan Wi-Fi 6 het kanaal opdelen in kleinere subkanalen (Resource Units) en die gelijktijdig aan verschillende apparaten toewijzen. Dit is precies wat helpt bij veel kleine pakketjes van IoT-apparaten: in plaats van elk mDNS-pakketje het hele kanaal te laten bezetten, kunnen meerdere kleine transmissies tegelijk plaatsvinden. In de praktijk hangt de winst af van hoeveel clients OFDMA ondersteunen.
BSS Coloring
Bij veel access points op dezelfde frequentie wachten apparaten onnodig op elkaar, ook als het verkeer van een ander netwerk komt (overlap met de buren). BSS Coloring voegt een kleurcode toe aan elk pakket, zodat een apparaat kan herkennen of het verkeer van zijn eigen netwerk komt of van een buurnetwerk. Als het van een buur komt, kan het apparaat gewoon doorzenden in plaats van te wachten. Dit vermindert co-channel interference aanzienlijk in dichtbebouwde gebieden.
Target Wake Time (TWT)
IoT-apparaten die niet continu hoeven te communiceren, kunnen met TWT afspraken maken met het AP over wanneer ze wakker worden om data te verzenden of ontvangen. De rest van de tijd slapen ze. Dit bespaart niet alleen batterij, maar ook airtime: minder apparaten die tegelijk het medium belasten. In de praktijk ondersteunen veel bestaande IoT-apparaten TWT nog niet, maar nieuwere generaties wel.
Multiple BSSID
Zoals eerder beschreven: Wi-Fi 6 kan meerdere SSID’s samenvoegen in één beacon frame. In een thuisnetwerk met drie SSID’s scheelt dit twee derde van de beacon-overhead. Dit is een significante verbetering, vooral op 2.4 GHz waar beacons op lage snelheden worden verzonden.
Wi-Fi 6E en 7: de 6 GHz-band
De grootste doorbraak is de 6 GHz-band, beschikbaar in Wi-Fi 6E en Wi-Fi 7. Dit voegt een enorme hoeveelheid schone spectrum-ruimte toe: er zijn geen legacy-apparaten die het vertragen, geen oudere standaarden die compatibiliteit afdwingen, en veel meer kanalen beschikbaar. Wi-Fi 7 introduceert daarnaast Multi-Link Operation (MLO), waarbij een apparaat gelijktijdig over meerdere banden kan communiceren. Dit kan de latency dramatisch verlagen en de betrouwbaarheid verhogen. De keerzijde: je hebt zowel access points als clients nodig die deze standaarden ondersteunen, en het bereik op 6 GHz is korter dan op 5 GHz door de hogere frequentie.
IGMP Snooping
Schakel dit aan op alle managed switches. Hiermee ziet de switch welk apparaat zich echt voor een multicastgroep heeft geabonneerd. Verkeer zonder abonnees wordt niet doorgestuurd (stel Forward Unknown Multicast in op Drop). Zo zorg je dat multicast niet naar plekken stroomt waar niemand luistert. Zet Fast Leave aan voor directe reactie als apparaten uitloggen. Configureer één apparaat als IGMP querier per VLAN.
mDNS/Bonjour-proxy
Wil je Sonos, AirPlay of Chromecast laten werken over VLAN-grenzen? Activeer de mDNS-proxy of forwarding-functie in je router of controller. UniFi’s nieuwste firmware heeft een ingebouwde mDNS-forwarder, Cisco WLC’s bieden mDNS Gateways. Zonder deze forwarding moeten speakers en bedieningsapps fysiek op hetzelfde netwerksegment zitten.
VLAN1 vs management-VLAN
Volgens Cisco best practices gebruik je VLAN1 niet voor productieverkeer. VLAN1 is het standaard-VLAN waarop alle poorten staan als ze niet geconfigureerd zijn. Dat betekent dat elk nieuw aangesloten apparaat automatisch in VLAN1 terechtkomt. Gebruik een apart management-VLAN (bijv. VLAN10) voor je beheerverkeer en access points. Zo voorkom je dat gewone apparaten in het beheernetwerk meekijken en verminder je het aanvalsoppervlak.
SSID’s beperken
Beperk je tot wat je echt nodig hebt: maximaal drie SSID’s per radio. In een huis met één AP heeft het geen zin vijf verschillende netwerken te maken: elke extra SSID vergroot de beacon-overhead en de management-complexiteit. Concentreer je op drie netwerken: één voor gebruikers, één voor IoT/media, en eventueel één gastnetwerk.
Minimale datarates verhogen
Stel bij alle 2.4 GHz SSID’s de minimale basic rate in op 12 Mbps of hoger. Dit heeft twee effecten. Ten eerste worden alle management-frames (beacons, probe responses) sneller verzonden, wat airtime bespaart. Ten tweede worden zeer oude apparaten die alleen 1 of 2 Mbps aankunnen van het netwerk geweerd. Eén zo’n traag apparaat kan het hele netwerk vertragen doordat het de radio langer bezet houdt per transmissie.
UPnP uitschakelen
Schakel UPnP uit in je router als je het niet expliciet nodig hebt. UPnP laat elk apparaat op het netwerk automatisch poorten openzetten in de firewall, zonder enige authenticatie. Zet liever handmatige port-forwarding in voor de specifieke apparaten die het nodig hebben. Dit is iets meer werk, maar vele malen veiliger.
Mesh correct configureren
Als je huis bedraad is, gebruik dan bedraad backhaul voor alle mesh-knooppunten en schakel draadloos backhaul uit. Verlaag het zendvermogen zodat cellen elkaar net overlappen voor roaming, maar niet te veel. Schakel 802.11r/k/v in als je apparaten het ondersteunen. En test: loop door het huis met een wifi-analyser en controleer of je apparaat daadwerkelijk roamt naar het dichtstbijzijnde AP.
Switches upgraden
Vervang unmanaged switches op kritieke punten door managed switches met IGMP snooping. Minimaal de switch direct achter de router moet managed zijn. Schakel Spanning Tree in (RSTP) en configureer edge-ports op alle poorten naar eindapparaten.
VLAN-indeling
Kies VLAN-nummers vanaf 10 (conform Cisco-richtlijn om VLAN1 vrij te houden):
VLAN10 – Management/AP’s (onzichtbaar voor gewone clients)
VLAN20 – Gebruikers (bekabeld en draadloos)
VLAN30 – IoT/Media (smart devices, printers, IPTV-decoders)
VLAN40 – Gast (alleen internettoegang, volledig geïsoleerd)
SSID’s & roaming
Gebruik maximaal 3 SSID’s: Home, IoT/Media, Guest. Verbind beheerapparatuur draadloos alleen via Home. Zet Sonos en andere smart-speakers in Home tenzij je een werkende mDNS-proxy hebt ingericht. Schakel 802.11r/k/v in op het Home-SSID voor betere roaming.
WiFi Advanced instellingen per SSID
- Multicast to Unicast: aan (converteert multicast naar unicast per client, bespaart airtime)
- Multicast/Broadcast filter: aan voor IoT-SSID (blokkeer ongewenste broadcasts)
- Band Steering: aan op hoofd-SSID (stuur clients naar 5 GHz); op IoT-SSID uit (IoT blijft op 2.4 GHz)
- Min Data Rate 2.4 GHz: 12–18 Mbps (versnelt beacons en management-frames, weert trage legacy-apparaten)
- Min Data Rate 5 GHz: 24 Mbps
- Client Isolation: aan op IoT-SSID (voorkomt directe communicatie tussen IoT-apparaten onderling)
IGMP Snooping op switches
- Enable IGMP Snooping per VLAN; stel Forward Unknown Multicast in op Drop
- Querier: configureer één switch of de router als IGMP querier per VLAN
- Fast Leave: aan (directe reactie bij uitloggen, cruciaal voor IPTV-zapsnelheid)
- Disable automatische flooding van bekende protocollen (SSDP, mDNS) indien mogelijk
Firewall & NAT
- Segmenteer IoT strikt: alleen uitgaand internetverkeer, geen toegang naar het gebruikersnetwerk
- Gast-netwerk volledig geïsoleerd: alleen internettoegang, geen toegang tot andere VLAN’s
- Gebruikersnetwerk mag beheer-VLAN en IoT-VLAN benaderen via gerichte firewall-regels
- Zet mDNS-forwarding alleen open waar nodig, met ACL’s of VLAN-specifieke regels
- Schakel UPnP uit; gebruik handmatige port-forwarding
Switch-configuratie
- Spanning Tree (RSTP): aan op alle managed switches
- Edge-ports (PortFast): aan op alle poorten naar eindapparaten
- BPDU Guard: aan op edge-ports (voorkomt dat een aangesloten apparaat loops veroorzaakt)
- Storm Control: aan (limiteert broadcast/multicast-verkeer per poort als percentage van de bandbreedte)
Kanaalplanning
- 2.4 GHz: gebruik alleen kanaal 1, 6 of 11; kanaalbreedte 20 MHz
- 5 GHz: gebruik 80 MHz kanaalbreedte; kies niet-DFS kanalen (36-48) voor stabiliteit, of DFS-kanalen voor meer ruimte als radar geen probleem is
- 6 GHz (Wi-Fi 6E/7): gebruik 160 MHz kanaalbreedte voor maximale doorvoer
Testen en valideren
Bij een nieuwe installatie: bouw stap voor stap op. Begin met de bedrade kern (router, switches, AP’s). Test de basisverbinding. Voeg dan VLAN’s toe en test segmentatie. Schakel IoT-apparaten één voor één in en meet de wifi-airtime na elke toevoeging. Zo vind je snel welk apparaat of welke instelling problemen veroorzaakt. Gebruik tools als wifi-analyzers om kanaalgebruik, beacon-overhead en airtime-verdeling in kaart te brengen.
Met deze maatregelen voorkom je dat slimme lampen, camera’s en televisiedecoders je wifi oversturen, en zorg je dat je netwerk veilig en beheersbaar blijft. Uiteindelijk geeft deze aanpak het gevoel van een betrouwbaar, snel netwerk – iets waar je internetabonnement naar hoort te voelen.
Neem gerust vrijblijvend contact met ons op.
We zijn er om u te adviseren en u te begeleiden bij het vinden van de beste oplossing voor uw behoeften.