Slik tester du hastigheten på en GRE-tunnel og finner årsaken til lav fart

En GRE-tunnel kan være treg på grunn av MTU, CPU-belastning, pakketap eller ruting. Slik måler og feilsøker du årsaken.

Publisert 2026-09-10 Sist oppdatert 2026-09-10 Kategori: Guider

Hva betyr lav hastighet i en GRE-tunnel?

Lav hastighet i en GRE-tunnel betyr ikke nødvendigvis at fiber-, kabel- eller DSL-linjen din er treg. GRE legger et ekstra IP-hode på trafikken, og både tunnelendepunktene, rutingen og forbindelsen mellom dem kan påvirke nedlasting, opplasting, latency, jitter og pakketap.

Start med å måle internettforbindelsen uten tunnelen. Test deretter en kjent server gjennom GRE-tunnelen, helst med samme klient, tidspunkt og nettverkskabel. Forskjellen mellom målingene viser om begrensningen sannsynligvis ligger i tunnelen eller hos ISP-en, operatøren, ruteren eller Wi-Fi-nettet.

Vanlige årsaker til lav GRE-hastighet

Feil MTU og fragmentering

GRE øker størrelsen på IP-pakkene. Hvis den effektive MTU-en blir større enn det forbindelsen mellom tunnelendepunktene støtter, kan pakker fragmenteres eller droppes. Resultatet kan være lav gjennomstrømming, ustabil nedlasting og høyere forsinkelse, særlig når store TCP-segmenter brukes.

CPU-belastning på ruter eller brannmur

Tunneltrafikk kan belaste prosessoren på en hjemmeruter, virtuell ruter eller brannmur. Når CPU-en når grensen, faller kapasiteten selv om bredbåndsabonnementet har ledig kapasitet. Dette er vanlig på eldre maskinvare eller når kryptering, QoS, NAT og trafikkfiltrering kjører samtidig.

Pakketap på underliggende forbindelse

Pakketap mellom tunnelendepunktene tvinger TCP til å sende data på nytt og redusere sendehastigheten. Feilen kan skyldes Wi-Fi-interferens, en overbelastet ISP-forbindelse, dårlig kabel, feil på modem eller problemer hos en mellomliggende operatør.

Ugunstig ruting og høy avstand

GRE følger den vanlige IP-ruten mellom endepunktene. En lang eller overbelastet rute kan gi høy latency og jitter, selv når begge lokale bredbåndslinjene fungerer normalt. En tunnelserver i et annet land kan derfor gi dårligere ytelse enn et nærmere endepunkt.

Begrensninger i TCP og testserveren

En enkelt teststrøm kan være for liten til å fylle en forbindelse med høy latency. Testserveren kan også ha begrenset kapasitet. Hvis flere parallelle strømmer gir betydelig høyere resultat, kan TCP-vinduet eller serveren være flaskehalsen, ikke selve GRE-tunnelen.

Wi-Fi eller lokal nettverksbelastning

En måling over Wi-Fi kan påvirkes av avstand, kanalstøy, mesh-hopp og andre brukere. Da kan resultatet se ut som et tunnelproblem. En test fra en datamaskin koblet direkte til ruteren med Ethernet gir et mer pålitelig sammenligningsgrunnlag.

Slik finner du hvor feilen ligger

  1. Mål nedlasting, opplasting, latency og pakketap uten GRE-tunnelen.

  2. Gjenta testen gjennom tunnelen med samme testserver og samme kablede klient.

  3. Bruk ping eller tilsvarende måling mot tunnelendepunktet for å se etter pakketap og jitter.

  4. Sammenlign én og flere parallelle teststrømmer. Store forskjeller kan peke mot TCP- eller serverbegrensninger.

  5. Kontroller CPU-bruk, minne og grensesnittstatistikk på begge tunnelrutere under testen.

  6. Test med en annen MTU og se etter fragmentering eller meldinger om for store pakker.

Praktisk metode for å teste GRE-hastighet

Kjør flere målinger på ulike tidspunkt, fordi kapasiteten hos ISP-en og belastningen på rutingen varierer. Bruk en lokal eller geografisk nær testserver når du vil måle bredbåndet, og en server på den andre siden av tunnelen når du vil måle hele forbindelsen.

En nyttig sammenligning er å overføre en stor fil med en kontrollert server og samtidig følge med på CPU, grensesnittkapasitet og pakketap. Nettleserbaserte hastighetstester er praktiske, men de kan påvirkes av nettleseren, testserveren og antallet samtidige forbindelser.

Optimalisering av en treg GRE-tunnel

  • Juster MTU og eventuelt TCP MSS slik at trafikken ikke fragmenteres på underliggende linjer.

  • Oppdater firmware eller programvare på ruter, modem og brannmur etter å ha kontrollert kompatibilitet.

  • Reduser unødvendig QoS, logging eller filtrering som bruker mye CPU under høy trafikk.

  • Bruk Ethernet under feilsøking og flytt krevende klienter bort fra ustabilt Wi-Fi.

  • Velg et tunnelendepunkt med kortere og mer stabil rute når løsningen tillater det.

  • Kontroller at begge tunnelendepunktene har tilstrekkelig kapasitet og riktige rutingregler.

Når bør du kontakte ISP eller operatør?

Kontakt ISP-en når du også ser pakketap, høy latency eller lav hastighet uten GRE, spesielt ved direkte Ethernet-tilkobling. Oppgi tidspunkt, testserver, måleresultater og om problemet gjelder både nedlasting og opplasting.

Hvis grunnlinjen er stabil, men ytelsen faller bare gjennom tunnelen, bør du først undersøke tunnelendepunktene, MTU, CPU-belastning og rutingen. Dokumenterte målinger på begge sider gjør det enklere å skille en lokal konfigurasjonsfeil fra et problem i transportnettet.