Onregelmatige of periodieke problemen met het maken van verbinding met SQL Server oplossen

Overzicht

In dit artikel wordt uitgelegd hoe u onregelmatige of periodieke netwerkgerelateerde problemen oplost die ertoe leiden dat SQL Server verbindingen mislukken, een time-out optreden of onverwacht opnieuw instellen. Hierin worden de meest voorkomende foutberichten, de onderliggende oorzaken (zoals verwijderde pakketten, antivirusfilters of uitgeputte kortstondige poorten) beschreven, en een proces voor het oplossen van gegevensgestuurde problemen op basis van SQLCHECK, SQLTRACE en analyse van netwerktracering met SQL Network Analyzer (SQLNA). Gebruik deze om te bepalen of het probleem zich op de client, op de server of in het netwerkpad ertussen bevindt.

Notitie

Voordat u begint met het oplossen van problemen, controleert u de vereisten en doorloopt u de controlelijst. Zie Zelfhulpartikelen voor meer informatie.

Veelvoorkomende foutberichten voor onregelmatige SQL Server connectiviteitsproblemen

Onregelmatige problemen treden onregelmatig op, terwijl periodieke problemen meestal optreden met voorspelbare intervallen. Het identificeren van het type probleem is de eerste stap bij het oplossen van problemen. Wanneer onregelmatige of periodieke SQL Server verbindingsproblemen optreden, kunnen de volgende foutberichten optreden:

Communicatiekoppelingsfout: deze fout geeft een onderbreking aan in de communicatie tussen netwerkonderdelen.
Time-out van de verbinding verlopen: de time-out voor de verbinding met de server is verlopen, wat wijst op een vertraging of onbeschikbaarheid van de server.
Algemene netwerkfout: Een algemeen netwerkfoutbericht duidt vaak op een niet-opgegeven probleem met het netwerk.
Fout op transportniveau: deze fout treedt op in de transportlaag, wat problemen met gegevensoverdracht voorstelt.
De opgegeven netwerknaam is niet meer beschikbaar: dit bericht impliceert dat de opgegeven netwerkresource niet kan worden bereikt.
Semafoor-time-out: deze fout duidt op een time-outsituatie die verband houdt met het gebruik van semaforen in het netwerk.
De wachtbewerking heeft een time-out bereikt: Een wachtbewerking heeft de toegestane tijd overschreden, doorgaans door netwerkvertragingen.
Er is een fatale fout opgetreden tijdens het lezen van de invoerstroom van het netwerk: dit bericht duidt op een kritieke fout bij het lezen van gegevens uit het netwerk.
Protocolfout in TDS-stroom: Tabular Data Stream (TDS) is een protocol dat wordt gebruikt door SQL Server. Deze fout geeft een probleem met het protocol aan.
De server is niet gevonden of is niet toegankelijk: dit foutbericht geeft aan dat de server die u probeert te openen niet beschikbaar is of niet kan worden gevonden.
SQL Server bestaat niet of de toegang is geweigerd: deze fout kan duiden op het ontbreken van de SQL Server of een verificatiefout bij het openen van SQL Server.

Veelvoorkomende oorzaken van onregelmatige SQL Server connectiviteitsproblemen

De meest voorkomende problemen zijn pakketuitval veroorzaakt door antivirussoftware, netwerkoptimalisatie, verouderde netwerkstuurprogramma's, slechte routers of switches en niet-gegroepeerde verbindingen in de toepassing.

Sommige oorzaken, zoals antivirussoftware, kunnen moeilijk te bewijzen zijn, maar zijn nog steeds gebruikelijk. Mogelijk moet u de software verwijderen en de computer opnieuw opstarten om het te bewijzen, zonder duidelijk bewijs. Het maken van een uitzondering voor SQL Server werkt mogelijk ook. Maar het uitschakelen van het antivirusprogramma werkt meestal niet omdat de netwerkfilterstuurprogramma's nog steeds worden geladen, zelfs als ze niet worden bewaakt.

Probleemoplossingsproces

Notitie

Dit proces is ontworpen voor SQL Server-client- en serververbindingen. Er worden geen andere communicaties aangepakt, zoals SQL Server Mirroring, AlwaysOn en Service Broker-synchronisatieverkeer via poort 5022.

Over het algemeen moet het oplossen van problemen gegevensgestuurd zijn, waardoor empirische tests in een meer gerichte context kunnen worden gebruikt. Als het probleem zeer onregelmatig is en netwerktraceringen moeilijk kunnen worden vastgelegd, past u eerst de empirische methoden toe.

Een rapport verzamelen met BEHULP van SQLCHECK op elke computer

Voer SQLCHECK uit op elke computer om een rapport te produceren. Het is handig om te bepalen waarom een verbinding kan mislukken.

Netwerktraceringen verzamelen op de client en server

Verzamel netwerktraceringen op Windows-computers met behulp van SQLTRACE.

Volg deze stappen om de tracering voor te bereiden en uit te voeren. Stap 2 en 3 hoeven slechts één keer te worden uitgevoerd.
1. Download de nieuwste versie van SQLTRACE en pak deze uit in een map, zoals C:\MSDATA.
2. Open het bestand SQLTrace.ini en schakel de volgende instellingen uit:
  
  BIDTrace=no, AuthTrace=no en EventViewer=no
3. Sla het bestand op.
4. Open PowerShell als beheerder en ga naar de map met SQLTrace.ps1.
```
CD C:\MSDATA
```
5. Start de traceverzameling.
```
.\SQLTrace.ps1 -start
```
6. Reproduceer het probleem of wacht tot de fout optreedt.
7. Stop met traceren.
```
.\SQLTrace.ps1 -stop
```
Het proces maakt een uitvoermap in de huidige map. Gebruik deze map voor verdere analyse.
Gebruik TCPDUMP of WireShark op niet-Windows-computers om een pakketopname te verzamelen.

SQL Server Network Analyzer uitvoeren

SQL Network Analyzer UI (SQLNAUI) biedt een grafische interface voor het selecteren van traceringsbestanden voor het parseren en instellen van opties. Download deze vanuit SQL Network Analyzer (SQLNA).

Client- en servertraceringen afzonderlijk verwerken. Als u aaneengeschakelde traces hebt, verwerk ze tegelijkertijd. De totale grootte van deze bestanden mag niet groter zijn dan 80% van het geheugen van uw computer. Zorg ervoor dat u voldoende geheugen hebt om alle gerelateerde traceringsbestanden te verwerken.

Met dit hulpprogramma wordt een rapport gegenereerd van verdachte problemen en een CSV-bestand dat u in Excel kunt verkennen voor alternatief onderzoek.

Probeer overeenkomende gesprekken te vinden in de clienttracering en de servertracering. Over het algemeen komen de IP-adressen en poortnummers overeen. Als de verbindingen echter via enige vorm van Network Address Translation (NAT) of poortmapping verlopen, kan dat lastiger zijn en moet u mogelijk de IPv4-pakket-ID's op elkaar afstemmen en de payloads vergelijken.

Patronen om te zoeken in netwerktraceringsanalyse

Bekijk hoe de gesprekken eindigen in NETMON of WireShark. Controleer of de client en server hetzelfde ermee eens zijn of dat ze een ander verhaal vertellen.

Verbinding gesloten tijdens SSL-handshake

Als in het ServerHello-pakket de gebruikte coderingssuite een Diffie-Hellman-suite is en het verkeer tussen Windows 2012 of eerder en Windows 2016 of hoger ligt, verandert dit algoritme vanaf beveiligingspatches voor Windows 2016. U moet deze groep coderingssuites uitschakelen. Voor meer informatie, raadpleeg Toepassingen ondervinden geforceerd gesloten TLS-verbindingsfouten bij het verbinden van SQL Servers in Windows.

Als de verbinding na de ClientHello wordt gesloten, controleer dan of er sprake is van een mismatch in TLS 1.0 of TLS 1.2 tussen client en server. Als ze hetzelfde zijn, controleert u de ingeschakelde coderingssuites en ingeschakelde hashes op beide computers.

Zie Advanced Secure Sockets Layer-gegevens vastleggen voor meer informatie.

Verworpen pakketten

Bekijk het einde van de overeenkomende gesprekken. Als een van beide veel opnieuw verzonden pakketten heeft (of 10 Keep-Alive-pakketten met tussenpozen van 1 seconde), gevolgd door een ACK+RESET, en de andere kant niet, of als de een een tijdige reactie meldt en de ander deze vertraagd binnen ziet komen en de verbinding sluit of reset, duidt dit op een probleem met het netwerkapparaat en gaan pakketten verloren of worden ze vertraagd.

Mogelijk ziet u ook het clientrapport dat aangeeft dat de server het gesprek opnieuw instelt en het serverrapport dat aangeeft dat de client het gesprek opnieuw instelt. Dit is te wijten aan een defecte switch of router die de verbinding halverwege verbreekt, en deze kunnen soms zo worden geconfigureerd als ze detecteren dat de verbinding een tijd inactief is geweest - waarbij Keep-Alive-pakketten vaak worden genegeerd.

Zie voor meer informatie over verbroken verbindingen:

Zowel de servertracering als de clienttracering komen overeen dat het probleem zich op de client bevindt

Als beide traceringen een vertraging of geen reactie op de client vertonen, of als de client een ACK+RESET uitgeeft nadat een serverantwoord is erkend, of anderszins, sluit de verbinding vroeg tijdens de aanmeldingsreeks, moet u een BID-trace en een NETSH-trace op de client nemen om te kijken binnen de TCP/IP-stack en wat het stuurprogramma denkt. Dit is gebruikelijk als de antivirus- of andere netwerkfilterstuurprogramma's het ontvangen van het pakket vertragen of het verzenden van het antwoord. Verbindingstime-outs kunnen ook worden veroorzaakt door een trage DNS-reactie of trage beveiligings-API die werd aangeroepen voordat het eerste SYN-pakket via de kabel werd verzonden.

Controleer het tijdelijke poortenrapport van SQL Network Analyzer en controleer of de client geen uitgaande poorten heeft.

Als de client lang wacht met het verzenden van het SYN-pakket, kunt u een patroon zien waarbij alleen de TCP-openinghandshake in drie stappen zichtbaar is, direct gevolgd, of soms pas na het verzenden van het PreLogin-pakket, door een ACK+FIN van de client.

Een netwerktracering en BID-trace verzamelen om clientproblemen op Windows te isoleren

Open het bestand SQLTrace.ini en schakel de volgende instellingen weer in:

BIDTrace=Yes, AuthTrace=Yes en EventViewer=Yes
Configureer het BIDProviderList in SQLTrace.ini zodat deze overeenkomt met het stuurprogramma dat uw toepassing gebruikt.

.NET System.Data.SqlClient is standaard ingeschakeld. Als dat niet het stuurprogramma is dat u gebruikt, schakelt u BIDProviderList uit door # aan het begin van de regel toe te voegen en het aan het begin van de ODBC- of OLEDB-lijst te verwijderen. Hiermee worden alle ondersteunde stuurprogramma's van dat type vastgelegd. Zie INI-configuratie voor meer informatie.
Sla het bestand op.
Open PowerShell als beheerder en ga naar de map met SQLTrace.ps1.
```
CD C:\MSDATA
```
Initialiseer het BID-traceringsregister indien u BID-traceringen verzamelt.

Notitie

BID Tracing is standaard ingeschakeld.
```
.\SQLTrace.ps1 -setup
```
Start de service of toepassing die u volgt opnieuw op.

Voor sommige toepassingen, zoals SSIS-pakketten (SQL Server Integration Services), wordt een nieuw exemplaar van DTEXEC of ISServerExec gestart wanneer het pakket wordt uitgevoerd, zodat opnieuw opstarten niet zinvol is.
Start de traceverzameling.
```
.\SQLTrace.ps1 -start
```
Reproduceer het probleem of wacht tot de fout optreedt.
Stop met traceren.
```
.\SQLTrace.ps1 -stop
```

Het proces maakt een uitvoermap in de huidige map. Gebruik deze map voor verdere analyse.

Raadpleeg de volgende artikelen om andere Microsoft SQL Server-stuurprogramma's te traceren. Voer dit uit met een netwerktrace.

Raadpleeg de documentatie van de leverancier om stuurprogramma's van derden te traceren.

Zowel de servertracering als de clienttracering komen overeen dat het probleem zich op de server bevindt

Als beide traceringen een vertraging of geen reactie op de server vertonen, of als de server de verbinding op een onverwacht punt in de aanmeldingsreeks sluit, of als de server veel verbindingen tegelijk sluit, betekent dit dat er enkele problemen zijn op de server.

De meest waarschijnlijke oorzaken zijn slechte serverprestaties, hoge MAXDOP, grote parallelle query's en blokkeren. Deze voorwaarden kunnen leiden tot thread-starvatie, waardoor een verificatieaanvraag niet snel wordt verwerkt, met name als veel time-outs van verbindingen op hetzelfde moment eindigen en de kolom LoginAck laat wordt weergegeven. In het SQL Server ERRORLOG-bestand kunnen IO-bewerkingen langer dan 15 seconden worden weergegeven. Dit is een andere indicator van prestatieproblemen. In de netwerktracering ziet u mogelijk ook veel gesprekken in het rapport Opnieuw instellen met zes frames of minder, wat aangeeft dat de TCP 3-weg handshake mogelijk niet is voltooid. Zie voor meer informatie De Connectivity Ring Buffer verzamelen.

Voer de RingBufferConnectivity query uit en plak de resultaten in Excel. Omdat deze lijst historisch is, kunt u deze uitvoeren nadat het probleem zich voordoet. Maar voor een drukke server kan het snel eindigen. Voor een trage server kan het enkele dagen gegevens bevatten.

Als uw toepassing gebruikmaakt van Multiple Active Result Sets (MARS), eindigt deze met reset als onderdeel van de afsluitvolgorde. Dit is goedaardig als de SMP:FIN- en ACK+FIN-pakketten al vanaf de client zijn verzonden. Het SMP:FIN-pakket van de server arriveert na ACK+FIN van de client en Windows geeft een ACK+RESET uit en vervolgens een RESET voor alle andere serverreacties als onderdeel van de afsluitende reeks verbindingen.

Groepsgewijze verbinding

Zie Groepsgewijze verbindingen voor meer informatie.

Als u groepsgewijze verbindingen gebruikt, zijn gesprekken in de netwerktracering doorgaans vrij lang. U kunt het CSV-bestand dat is gegenereerd door SQL Server Network Analyzer gebruiken om te sorteren en filteren op protocollen en frames. U ziet waarschijnlijk geen begin- of eindframes als de netwerkopname minder dan een half uur is. Als veel gesprekken korter zijn dan 30 frames van het SYN-pakket naar het ACK+FIN-pakket, duidt deze voorwaarde op niet-gegroepeerde verbindingen. Als deze niet-gegroepeerde verbindingen worden gemengd met een paar langere gesprekken, vermoedt u dat niet-gegroepeerde achtergrondverbindingen worden veroorzaakt door het uitvoeren van opdrachten op een niet-MARS-verbinding tijdens het lezen van een resultatenset.

Het tijdelijke poortrapport toont het aantal nieuwe verbindingen gedurende de levensduur van de tracering. U kunt de verbindingssnelheid beoordelen op basis van het aantal verbindingen per seconde.

RESET versus ACK+RESET

Normaal gesproken ziet u ACK+RESET wanneer de toepassing of Windows een verbinding afbreekt. Deze voorwaarde wordt over het algemeen veroorzaakt door een TCP-fout op laag niveau. Het pakket informeert de andere computer om het verzenden onmiddellijk te stoppen. Als de server zich echter midden in de verzending bevindt, kunnen een of twee pakketten op de client aankomen nadat de ACK+RESET is verzonden. Omdat de poort is gesloten, verzendt het besturingssysteem een RESET-pakket. Deze voorwaarde treedt ook op als pakketten binnenkomen na het ACK+FIN-pakket dat geen deel uitmaakt van de normale afsluitende handshake.

Sommige stuurprogramma's van derden verzenden ook een ACK+RESET-pakket om de verbinding te sluiten in plaats van een ACK+FIN. Sommige probeverbindingen kunnen ook deze actie uitvoeren. Als het ACK+RESET-pakket niet voorafgegaan wordt door Keep-Alive-pakketten, herverzonden pakketten of Zero Windows-pakketten, en het van de client afkomstig is wanneer een normale afsluiting met ACK+FIN wordt verwacht, kan dit onschuldig zijn.

NETSTAT gebruiken om netwerkproblemen te analyseren

NETSTAT wordt automatisch verzameld wanneer u SQLTrace.ps1 uitvoert voor het verzamelen van gegevens.

U kunt ook als beheerder in NETSTAT -abon > c:\ports.txt uitvoeren om informatie over netwerkproblemen te verzamelen.

Het bestandports.txt bevat een lijst met alle binnenkomende en uitgaande poorten, poortnummers, proces-id's en namen van toepassingen die eigenaar zijn van de poorten. Gebruik deze lijst om de slechtste daders te zien en of de poortlimiet is bereikt. Schakel de statusbalk in Kladblok in en schakel Word Wrap uit. De statusbalk geeft het aantal regels weer. U kunt delen door twee om een geschat poortgebruik te krijgen.

TcpTimedWaitDelay en MaxUserPort aanpassen

Als een toepassing de uitgaande poorten op de hostcomputer uitput en u geen directe wijzigingen aan de toepassing kunt aanbrengen, kunt u van 240 tot 30 seconden verlagen TcpTimedWaitDelay , waardoor uitgaande poorten sneller kunnen worden gerecycled.

U kunt ook het dynamische poortbereik van de client op de hostcomputer uitbreiden met behulp van de netsh int ipv4 set dynamicport tcp opdracht (of ipv6) . Deze actie elimineert niet de inefficiënties van niet-gegroepeerde verbindingen of niet-gegroepeerde achtergrondverbindingen. In het ideale geval moet de toepassing worden gewijzigd om groepsgewijze verbindingen te gebruiken.

De huidige ondersteunde versies van Windows maken al gebruik van het standaard dynamische clientpoortbereik van 49152 tot en met 65535, dat ongeveer 16.384 tijdelijke poorten biedt.

Zie De instellingen maxUserPort en TcpTimedWaitDelay aanpassen voor meer informatie.

Bijna alle pakketten die van de client naar de server of de server naar de client worden verzonden, worden beantwoord met een ACK-pakket dat in omgekeerde richting gaat. De TCP.SYS laag genereert de ACK. Als een pakket wordt ontvangen op de client en de clienttracering laat zien dat het binnenkomt, maar er geen ACK wordt geretourneerd naar de server, is deze voorwaarde een goede indicatie dat het antivirusprogramma of een ander netwerkfilterstuurprogramma het pakket kwijtraakt of heeft verwijderd of gedurende een lange tijd is vastgehouden (voorbij het einde van de netwerktraceringsverzameling). Als de servertracering ook een pakket weergeeft dat afkomstig is van een client, maar er geen ACK naar de client wordt verzonden, geeft deze voorwaarde aan dat de antivirussoftware van de server op de server mogelijk een probleem heeft.

Wanneer u echter een grote hoeveelheid gegevens uploadt of downloadt, kunnen de ACK-pakketten na een reeks gegevenspakketten komen om te helpen met stroombeheer.

Het is erg moeilijk te bewijzen dat de antivirus- en filterstuurprogramma's de schuldige zijn. U moet bijna altijd een empirische test uitvoeren. Maak een uitzondering voor de toepassing of SQL Server in de antivirussoftware en bewaak deze gedurende 48 uur om te zien of het gedrag verbetert. Als u geen uitzondering kunt instellen, verwijdert u het antivirusprogramma en start u opnieuw op. Het uitschakelen ervan helpt meestal niet omdat het stuurprogramma voor antivirusfilters nog steeds wordt geladen. Doe dit alleen als laatste redmiddel als uw randbeveiliging aanwezig is.

Neem contact op met uw netwerkbeveiligingsbeheerders. Als de situatie verbetert, moet u mogelijk samenwerken met de antivirusleverancier om het probleem te verhelpen. Als dit niet het probleem is, kunnen andere netwerkfilterstuurprogramma's de schuld zijn.

Windows Firewall-controle inschakelen

Als u wilt bepalen of de firewall pakketten verwijdert, schakelt u firewallcontrole in Windows in.

Voor SQL Server kan dit probleem betrekking hebben op de client of servercomputer. De netwerktracering geeft aan dat de machine een pakket heeft ontvangen, maar niet heeft gereageerd. Het pakket kan vervolgens opnieuw worden verzonden, opnieuw geen antwoord krijgen en uiteindelijk wordt de verbinding opnieuw ingesteld.

Empirische en andere acties

Tijdelijke poorten

Onvoldoende tijdelijke poorten is een relatief veelvoorkomende oorzaak van onregelmatige verbindingstime-outs, vooral als u het SYN-pakket niet op de kabel ziet.

Voor binnenkomende aanvragen op de server kunnen poorten zoals 80 of 1433 maximaal 64.000 binnenkomende verbindingen per client-IP-adres verwerken en zijn over het algemeen onbeperkt voor alle praktische doeleinden.

Voor uitgaande verbindingen is het aantal poorten beperkt en gedeeld tussen alle serververbindingen. In de huidige ondersteunde versies van Windows is het standaardpoortbereik van de dynamische client 49152 tot en met 65535, dat ongeveer 16.384 tijdelijke poorten biedt.

Normaal gesproken bevat het besturingssysteem poorten gedurende vier minuten (240 seconden) voordat ze worden gerecycled en kunnen toepassingen ze opnieuw gebruiken. Deze vertraging voorkomt poortvervalsing door schadelijke software of onbedoelde omleiding van een nieuwe verbinding met de vorige houder van die poort. Vanwege deze vertraging kan een clienttoepassing die gebruikmaakt van het standaard dynamische poortbereik en de standaardwaarde TcpTimedWaitDelay van 240 seconden slechts ongeveer 68 nieuwe uitgaande verbindingen per seconde openen tot SQL Server voordat deze de ongeveer 16.384 kortstondige poorten verbruikt. Het verlagen van TcpTimedWaitDelay of het vergroten van het dynamische poortbereik met netsh int ipv4 set dynamicport tcp verhoogt die bovengrens.

Voor toepassingen zoals IIS heeft elke HTTP-client mogelijk één uitgaande poort naar SQL Server. Voor een drukke webserver is het een reële mogelijkheid om zonder uitgaande poorten te komen zitten bij hoge belasting. Een webfarm kan deze situatie beperken.

Maximaal servergeheugen aanpassen (MB)

Als u problemen met betrekking tot weinig kernelgeheugen wilt oplossen, past u het maximale servergeheugen (MB) aan.

Offloading uitschakelen

Voor testdoeleinden kunt u bepaalde vormen van taakontlasting uitschakelen via een Opdrachtprompt voor beheerders:

netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global NetDMS=disabled
netsh int tcp set global autotuninglevel=disabled

Houd deze instellingen niet lang uitgeschakeld, tenzij ze een probleem oplossen. Ze worden standaard ingeschakeld voor de huidige ondersteunde versies van Windows.

Voor andere offloadfuncties moet u naar de eigenschappen van de netwerkadapter gaan om deze te bekijken en uit te schakelen.

Problemen met VMware-netwerkbuffer

De ESX-host die de virtuele machine (VM) bevat, heeft een kleine netwerkbuffer die betrouwbaarheidsproblemen kan veroorzaken als er sprake is van een burst in het verkeer. In het volgende VMware-artikel wordt beschreven hoe u de buffergrootte vergroot. Opnieuw opstarten is niet vereist. Deze bewerking moet worden uitgevoerd op de ESX-hostcomputer, niet op de VM.

Groot pakketverlies in het gastbesturingssysteem bij gebruik van VMXNET3 in ESXi

Probeer bovendien de VM's naar een andere ESX-hostserver te verplaatsen of de client en server naar dezelfde ESX-hostserver te verplaatsen en te zien of het probleem weggaat. Als dit het geval is, is het een probleem met het basisnetwerk.

VMware-momentopnamen

Controleer of er VMware-momentopnamen optreden tijdens de fout en schakel deze uit.

RSS (Receive Side Scaling) uitgeschakeld op de hostcomputer

Wanneer RSS is uitgeschakeld, gebruikt de SQL Server-host slechts één CPU om alle netwerkaanvragen te verwerken. Dit kan een piek veroorzaken in de CPU tot 100% en problemen veroorzaken, zelfs als de niveaus van de andere CPU's (en de totale CPU) laag zijn.

Zie Inleiding tot Receive Side Scaling en Receive Side Scaling versie 2 (RSSv2) voor meer informatie.

Disclaimer voor informatie van derden

De producten van derden die in dit artikel worden vermeld, worden vervaardigd door bedrijven die onafhankelijk zijn van Microsoft. Microsoft verleent dan ook geen enkele garantie, impliciet noch anderszins, omtrent de prestaties of de betrouwbaarheid van deze producten.

Feedback

Is deze pagina nuttig?

Last updated on 2026-07-30