GRE-tunnelsnelheid testen: oorzaken van lage snelheid en oplossingen

Wie een GRE-tunnel gebruikt, kan een duidelijk verschil zien tussen de snelheid van de directe internetverbinding en de throughput door de tunnel. Een speedtest op de router of computer meet dan niet alleen de GRE-configuratie, maar ook de onderliggende verbinding, routing, firewall en gebruikte apparatuur. Een betrouwbare analyse begint daarom met een vergelijking tussen verkeer buiten en binnen de tunnel.

Wat betekent een lage snelheid in een GRE-tunnel?

De snelheid van een GRE-tunnel wordt meestal beoordeeld aan de hand van download, upload, latency, jitter en packet loss. De beschikbare throughput kan lager zijn dan de snelheid van een glasvezel-, kabel- of DSL-aansluiting, omdat GRE extra headers toevoegt en de router elk pakket moet inkapselen en uitpakken.

Een korte test met één download is niet altijd representatief. TCP heeft tijd nodig om zijn verzendvenster op te bouwen en kan sterk reageren op vertraging of pakketverlies. Test daarom bij voorkeur in beide richtingen en onder verschillende belastingen.

Veelvoorkomende oorzaken van een trage GRE-tunnel

Te kleine MTU of fragmentatie

GRE voegt extra bytes toe aan elk pakket. Als de MTU van de tunnel te hoog is voor het pad tussen beide eindpunten, ontstaan fragmentatie, wegvallende pakketten of een lagere TCP-snelheid. Dit is vooral zichtbaar bij grote downloads, VPN-verkeer en verbindingen waarbij ICMP-fragmentatiemeldingen worden geblokkeerd.

Packet loss op de onderliggende verbinding

Packet loss tussen de twee GRE-eindpunten heeft direct invloed op de prestaties. TCP verlaagt zijn verzendsnelheid zodra het verlies detecteert, waardoor de throughput sterk kan dalen terwijl een eenvoudige ping soms normaal lijkt. Controleer daarom verlies zowel buiten als binnen de tunnel.

Beperkte CPU-capaciteit op router of firewall

GRE-verkeer wordt niet op iedere router hardwarematig verwerkt. Een oudere router, modem of firewall kan bij hoge packet rates tegen de maximale CPU-capaciteit aanlopen. De snelheid zakt dan vooral tijdens meerdere gelijktijdige downloads of uploads, terwijl de lijn buiten de tunnel wel snel blijft.

Verkeerde routing of een ongunstig pad

Een GRE-tunnel kan verkeer via een langere route sturen dan de normale internetverbinding. Extra hops verhogen latency en jitter en vergroten de kans op congestie. Asymmetrische routing kan bovendien zorgen voor verschillende prestaties in de download- en uploadrichting.

Firewall, QoS of rate limiting

Een firewallregel, traffic shaper of QoS-profiel kan GRE-verkeer beperken zonder dat dit direct zichtbaar is in de configuratie van de tunnel. Ook een provider of netwerkbeheerder kan een limiet toepassen op een specifieke interface, VLAN of transportverbinding. Vergelijk daarom de prestaties met en zonder deze regels, als dat veilig mogelijk is.

Te weinig TCP-paralleliteit of een korte test

Een enkele TCP-stream benut een langeafstandstunnel niet altijd volledig. Bij hogere latency kan één verbinding onvoldoende data tegelijk onderweg hebben. Een test met meerdere parallelle streams kan aantonen of de verbinding zelf beperkt is of dat vooral het TCP-venster de gemeten snelheid beïnvloedt.

GRE-tunnelsnelheid betrouwbaar testen

Gebruik voor een technische meting bij voorkeur iperf3 op twee systemen achter de GRE-eindpunten. Test eerst de directe route buiten de tunnel en daarna hetzelfde verkeer via de tunnel. Voer zowel een downloadtest als een uploadtest uit met één en meerdere parallelle streams.

1. Controleer de basissnelheid zonder GRE, bij voorkeur met een bekabelde verbinding.
2. Meet latency en packet loss tussen de tunnel-eindpunten.
3. Voer een iperf3-test uit in beide richtingen.
4. Herhaal de meting met meerdere parallelle verbindingen.
5. Noteer CPU-belasting, interfacefouten, MTU en retransmissies.

Een publieke speedtest kan nuttig zijn voor een algemene indicatie, maar is minder geschikt om alleen de GRE-prestaties te beoordelen. Kies tijdens de diagnose één vaste testserver en test buiten piekuren om drukte bij de ISP of operator uit te sluiten.

Hoe bepaal je de werkelijke oorzaak?

Vergelijk eerst de resultaten buiten en binnen de tunnel. Is de snelheid in beide situaties laag, dan ligt het probleem waarschijnlijk bij de internetverbinding, de router, Wi-Fi of de gekozen testserver. Is alleen de tunnel langzaam, onderzoek dan MTU, routing, CPU-belasting, firewallregels en packet loss.

Gebruik ping met verschillende pakketgroottes en controleer met traceroute of mtr waar vertraging of verlies ontstaat. Bekijk daarnaast de interface-statistieken op beide tunnelrouters. Fouten, drops en een oplopende CPU-belasting geven vaak meer informatie dan alleen een speedtestresultaat.

Praktische optimalisaties voor meer GRE-throughput

• Stel een passende tunnel-MTU in en controleer de effectieve MSS voor TCP.
• Voorkom fragmentatie en zorg dat noodzakelijke ICMP-berichten niet onnodig worden geblokkeerd.
• Gebruik bekabelde verbindingen voor metingen en sluit Wi-Fi als variabele uit.
• Controleer of de router of firewall GRE hardwarematig kan verwerken.
• Verwijder onnodige QoS- of rate-limitregels en controleer de prioriteiten.
• Vergelijk beide verkeersrichtingen, omdat upload en download verschillende knelpunten kunnen hebben.
• Gebruik meerdere iperf3-streams, maar vergelijk de resultaten altijd met een enkele stream.

Wanneer is de GRE-snelheid normaal?

Een lagere snelheid dan de geadverteerde lijnsnelheid is niet automatisch een storing. GRE-overhead, latency, encryptie in een aanvullende VPN-laag en de capaciteit van de tunnelrouters kunnen de praktische throughput beperken. De juiste referentie is daarom de gemeten snelheid van dezelfde verbinding zonder tunnel, onder vergelijkbare omstandigheden.

Als de tunnel na het aanpassen van MTU en routing nog steeds duidelijk achterblijft, controleer dan de capaciteit van beide eindpunten en vraag de ISP of operator om de onderliggende lijn op packet loss en congestie te onderzoeken. Documenteer daarbij tijdstip, testserver, richting, pakketgrootte en gebruikte configuratie.