Een wifi-dongle, 50 apparaten en een maand netwerkellende

Een kantoor met ongeveer vijftig apparaten. Windows, Mac, netwerkapparatuur van Ubiquiti en Netgear. Meestal werkte alles. Maar om de vier à vijf dagen verloor een deel van de apparaten binnen één VLAN de internetverbinding. Ongeveer drie uur lang.

De collega ernaast kon gewoon doorwerken. Dat maakt een storing extra gezellig: dezelfde ruimte, hetzelfde netwerk, twee verschillende werkelijkheden.

De beheerder zocht ongeveer een maand naar de oorzaak. ARP-tabellen leegmaken, DHCP-leases vernieuwen, computers herstarten, verkeer bekijken met Wireshark en Ubiquiti-firmware terugzetten. Soms leek iets te helpen. Tot de volgende ronde.

Uiteindelijk leidde het spoor naar een kleine USB-wifi-adapter. Zo’n ding dat eerder zoekraakt tussen de pennen dan dat je het verdenkt van een kantoorbrede verstoring.

De adapter was het begin van het verhaal

Een medewerker wilde het wifi-bereik verbeteren en besloot de verbinding vanaf de eigen computer te delen. Daarvoor kwam er een extra USB-wifi-adapter.

In die configuratie claimde de computer, via een fysieke of virtuele netwerkinterface, het IP-adres dat op het kantoornetwerk bij de gateway hoorde. Een deel van de clients stuurde daardoor verkeer naar die computer in plaats van naar de echte router.

Een USB-adapter kaapt niet uit zichzelf een gateway-adres. Het probleem zat in de combinatie van internetdeling en een verkeerde IP-configuratie op de host. De adapter maakte die extra netwerkfunctie mogelijk; de inrichting ervan veroorzaakte het conflict.

Dat onderscheid helpt ook bij de oplossing. Alleen een ander merk adapter kopen voorkomt geen herhaling. Begrijpen welke netwerkfunctie op de computer actief was, wel.

Twee apparaten, één adres

Voor verkeer buiten het eigen IPv4-subnet gebruikt een computer normaal gesproken een standaardgateway. De client kent het IP-adres van die gateway, maar moet binnen het lokale netwerk ook weten naar welk MAC-adres hij het verkeer moet sturen.

Daarvoor dient ARP: een lokaal adresboek dat IP-adressen aan MAC-adressen koppelt. De computer vraagt in feite: wie heeft het gateway-adres? Het antwoord bewaart hij tijdelijk.

Wanneer twee interfaces op hetzelfde netwerk hetzelfde gateway-IP claimen, kunnen clients verschillende antwoorden opslaan. De ene client heeft het MAC-adres van de echte router in zijn ARP-cache. De andere heeft het adres van de verkeerd ingestelde computer.

Voor die tweede client lijkt internet weg. De client kan nog steeds wifi-bereik hebben en een geldig eigen IP-adres tonen. Alleen gaat het verkeer voor buiten het subnet naar de verkeerde bestemming. Direct verkeer naar apparaten binnen hetzelfde subnet kan nog werken. Een sterk wifi-signaal zegt daar weinig over.

Waarom slechts een deel, en waarom om de paar dagen?

ARP-caches worden niet op alle apparaten tegelijk opgebouwd of vernieuwd. Ook kunnen besturingssystemen verschillend omgaan met ARP-berichten. Daardoor kan een adresconflict naast elkaar werkende en getroffen apparaten opleveren.

Periodiek gebruik van de computer, internetdeling die wordt ingeschakeld of veranderingen in de verbindingsstatus kunnen zo’n conflict zichtbaar maken. Het ritme van vier à vijf dagen en de duur van ongeveer drie uur bewijzen op zichzelf geen vaste ARP-timer of DHCP-leasetijd. Daarvoor moet je gebeurtenissen tijdens de storing naast elkaar leggen.

De VLAN-grens is ook een aanwijzing. ARP werkt binnen het lokale netwerksegment; routers sturen deze verzoeken normaal niet door naar andere VLANs. Een conflict in één VLAN hoeft dus niet het hele kantoor te raken. Segmentatie beperkt de reikwijdte, maar voorkomt niet ieder conflict binnen een segment.

Waarom een reset overtuigend kan lijken

Een ARP-cache leegmaken dwingt een nieuwe adresvraag af. Antwoordt de echte router vervolgens op het juiste moment, dan werkt de verbinding weer. De andere deelnemer aan het conflict bestaat daarmee nog steeds.

Ook een herstart of DHCP-vernieuwing kan de timing en lokale netwerkstatus veranderen. Dat is nog geen bewijs dat DHCP de oorzaak was. Als meerdere ingrepen kort na elkaar gebeuren, wordt het lastig om herstel aan één verandering toe te schrijven.

Hetzelfde geldt voor firmware. Een verbetering na een rollback bewijst geen bug in Ubiquiti- of Netgear-apparatuur. De samenloop kan toevallig zijn.

Wireshark blijft juist nuttig. Een opname buiten het storingsmoment kan het conflict missen. En op een willekeurige switchpoort zie je doorgaans niet al het verkeer van andere clients. Tijdstip, getroffen VLAN en opnamepunt bepalen wat een capture kan laten zien; soms is een zorgvuldig ingestelde mirrorpoort nodig.

Wat je tijdens de volgende storing vastlegt

Begin met vergelijken, voordat je overal caches wist:

1. Kies een getroffen en een werkend apparaat in hetzelfde VLAN. Noteer tijdstip, eigen IP-configuratie en ingestelde gateway. Controleer welk MAC-adres beide apparaten op dat moment aan het gateway-IP koppelen.
2. Vergelijk met de echte infrastructuur. Controleer routerconfiguratie, gateway-interface en netwerkdocumentatie. Houd rekening met legitieme redundantie: een virtueel gateway-MAC-adres of afgesproken failover kan normaal zijn.
3. Zoek het afwijkende MAC-adres op. Gebruik de MAC-adrestabel van de switch, clientgegevens van het accesspoint en endpointinformatie om poort, verbinding en host te vinden. Een fabrikantnaam alleen identificeert geen schuldige.
4. Isoleer de verdachte host gecontroleerd. Stem de onderbreking af, bewaar relevante instellingen en schakel gericht de ongewenste deelfunctie of verbinding uit. Controleer daarna opnieuw de gatewaykoppeling en bereikbaarheid bij de getroffen clients.

Controleer bij die host ook of internetdeling een DHCP-service, een hotspot of een netwerkbrug heeft ingeschakeld.

Voorkomen dat de oplossing in een USB-poort verdwijnt

Maak duidelijk dat medewerkers internetdeling en netwerkbruggen niet zelfstandig mogen activeren. Zorg tegelijk voor een eenvoudige manier om onvoldoende wifi of een ontbrekende aansluiting te melden. Anders wordt een praktische behoefte al snel een eigen netwerkproject.

Beheer die instellingen centraal waar dat kan. Documenteer gateways, VLANs en toegestane netwerkapparatuur. Overweeg DHCP snooping en ARP-inspectie als de infrastructuur dit ondersteunt, met onderling afgestemde instellingen en aandacht voor statische adressen en redundantie. Verkeerd ingestelde bescherming kan zelf verkeer blokkeren.

Goede scheiding van werkplekken, gasten en apparaten met VLANs blijft daarbij nuttig. Combineer die met beheer en documentatie binnen ieder segment.

Technische achtergrond: ARP (RFC 826) en IPv4-adresconflictdetectie (RFC 5227).

Een frisse blik zonder nieuwe IT-partner

Bij een terugkerende storing kan een aparte diagnose meer opleveren dan nog een resetronde. Oros ICT Support Limburg kan zo’n onderzoek uitvoeren naast je bestaande IT-beheerder. Je hoeft daarvoor niet van IT-partner te wisselen of een verplicht abonnement af te sluiten.

We spreken vooraf de onderzoeksvraag, scope en het budget af. Op de tarievenpagina vind je meer over de dienstverlening.

Blijft een deel van je kantoor af en toe zonder internet zitten? Neem contact op om een gerichte diagnose te bespreken →