Mesure de vitesse d’un tunnel GRE : causes d’un débit faible et méthodes de diagnostic
Un débit plus faible dans un tunnel GRE ne signifie pas forcément que la fibre, la box ou l’opérateur rencontre une panne. L’encapsulation ajoute des en-têtes, tandis que la MTU, la fragmentation, la latence, la perte de paquets, le processeur du routeur et le chemin réseau peuvent limiter les performances. Cet article explique comment comparer un test direct et un test à travers le tunnel, isoler chaque cause avec des mesures simples, puis ajuster la MTU, le MSS, le routage et la configuration du routeur. Les méthodes proposées conviennent aux utilisateurs avancés comme aux administrateurs qui souhaitent distinguer un problème local d’une limite liée au réseau distant.
Pourquoi le débit baisse dans un tunnel GRE
Un test de débit effectué directement depuis une box ou un routeur peut afficher un débit descendant et un débit montant proches des performances attendues sur une connexion fibre. Le même test réalisé à travers un tunnel GRE peut toutefois être plus lent, avec une latence plus élevée ou des variations importantes.
Cette différence vient du fait que les paquets sont encapsulés avant leur transmission. Le tunnel ajoute une charge au réseau et impose un traitement supplémentaire sur les deux équipements GRE. La baisse peut être légère, mais elle devient visible lorsque le routeur manque de puissance, lorsque le chemin réseau est long ou lorsque les paquets sont fragmentés.
Les causes fréquentes d’un débit faible sur un tunnel GRE
MTU trop élevée et fragmentation
Le tunnel GRE ajoute des en-têtes à chaque paquet. Si la MTU configurée reste identique à celle de l’interface physique, la taille totale peut dépasser la limite du chemin. Les paquets sont alors fragmentés ou rejetés, ce qui réduit le débit et augmente la latence. Une MTU adaptée au chemin GRE, ainsi qu’un réglage cohérent du MSS, permet souvent d’améliorer la stabilité.
Capacité limitée du routeur
Un routeur peut atteindre sa limite de traitement avant que la fibre ou la box ne soit réellement saturée. L’encapsulation, la désencapsulation, le chiffrement éventuel, le pare-feu et le suivi des connexions consomment du processeur. Cette situation est fréquente sur les équipements grand public ou sur les routeurs utilisant un traitement GRE principalement logiciel.
Perte de paquets sur le chemin réseau
Une perte de paquets oblige TCP à retransmettre les données et à réduire sa fenêtre de congestion. Le débit mesuré à travers le tunnel peut alors chuter fortement, même si un test direct vers le même service reste correct. La perte peut se situer sur l’accès local, chez l’opérateur, sur le chemin Internet ou à proximité de l’extrémité distante du tunnel.
Latence élevée et distance entre les extrémités
Un tunnel GRE reliant deux sites éloignés ajoute parfois plusieurs sauts et une latence importante. Les transferts TCP sont sensibles au temps aller-retour, surtout lorsque la fenêtre TCP est limitée ou que le serveur de test ne dispose pas d’une capacité suffisante. Un débit faible peut donc provenir du trajet choisi plutôt que de la connexion fibre locale.
Routage asymétrique
Le trafic aller et retour peut emprunter des chemins différents. Cette asymétrie complique le diagnostic et peut provoquer des performances irrégulières lorsque certains équipements filtrent, réordonnent ou traitent différemment les paquets GRE. Elle peut aussi rendre les résultats différents selon le sens du débit montant ou descendant.
Filtrage ou traitement excessif du trafic
Un pare-feu, une inspection approfondie des paquets, une règle de qualité de service ou une limitation appliquée à l’interface du tunnel peut réduire le débit. Les règles ne sont pas toujours visibles dans un test direct depuis la box, car elles peuvent s’appliquer uniquement au trafic entrant ou sortant du tunnel.
Comment mesurer correctement la vitesse du tunnel GRE
Commencez par établir une référence avec un test réalisé depuis la box ou le routeur, sans passer par le tunnel. Utilisez autant que possible une connexion Ethernet plutôt que le Wi-Fi, fermez les téléchargements en cours et répétez la mesure à plusieurs moments. Notez le débit descendant, le débit montant, la latence et la stabilité du résultat.
Effectuez ensuite le même test depuis un équipement situé derrière le tunnel GRE. Choisissez un serveur de mesure proche de l’extrémité distante et comparez les résultats avec le test direct. Un outil comme Speedtest peut servir de référence grand public, mais un test contrôlé entre deux serveurs est préférable pour isoler le tunnel.
Vérifier la perte de paquets et la latence
Utilisez ping pour observer le temps aller-retour et la perte de paquets. Un outil de type traceroute ou mtr aide à repérer le saut où la latence augmente. Comparez le chemin vers l’adresse distante avec le chemin utilisé sans tunnel. Une perte régulière ou une forte variation de latence constitue un indice plus utile qu’un seul résultat de débit.
Tester la MTU du chemin
Réalisez des tests avec des paquets dont la fragmentation est interdite, puis diminuez progressivement leur taille jusqu’à obtenir une réponse stable. La valeur trouvée doit tenir compte des en-têtes GRE et des éventuels autres protocoles d’encapsulation. Le réglage final doit être appliqué de manière cohérente sur les interfaces concernées.
Contrôler la charge du routeur
Surveillez l’utilisation du processeur, la mémoire, les interruptions réseau et le débit de chaque interface pendant le test. Si le processeur atteint un niveau élevé au moment où le débit plafonne, le tunnel est probablement limité par la capacité de traitement du routeur. Comparez également les performances avec les fonctions de pare-feu ou de suivi de connexion temporairement ajustées dans un environnement maîtrisé.
Optimiser le débit descendant et montant du tunnel
- Ajuster la MTU : choisissez une valeur compatible avec le chemin réel afin d’éviter la fragmentation.
- Réduire le MSS : appliquez un MSS cohérent lorsque les échanges TCP traversent le tunnel.
- Mettre à jour le routeur : utilisez une version stable du système et vérifiez les optimisations disponibles pour le traitement GRE.
- Alléger les règles : examinez le pare-feu, la qualité de service et les fonctions d’inspection qui peuvent ralentir le trafic.
- Choisir un chemin adapté : privilégiez une extrémité distante et un serveur de test présentant une latence régulière.
- Comparer les deux sens : mesurez séparément le débit descendant et le débit montant pour détecter une limitation asymétrique.
Distinguer un problème de tunnel d’un problème opérateur
Si le test direct depuis la box affiche un débit normal, mais que le test à travers le tunnel reste faible, l’analyse doit se concentrer sur la MTU, le routeur, le routage et l’extrémité distante. À l’inverse, si les deux tests sont dégradés sur une connexion Ethernet, vérifiez l’accès fibre, le câble, l’ONT éventuel, la box et l’état du réseau de l’opérateur.
Les opérateurs tels qu’Orange, SFR, Bouygues Telecom ou Free peuvent être utilisés comme exemples de réseaux d’accès, mais le nom de l’opérateur ne permet pas à lui seul d’identifier la cause. Fournissez au support des mesures comparables, l’heure des tests, la latence, la perte de paquets et la présence ou non du tunnel.
Checklist de diagnostic
- Mesurer le débit sans tunnel avec un câble Ethernet.
- Mesurer le débit à travers le tunnel GRE dans les deux sens.
- Comparer la latence et la perte de paquets sur plusieurs minutes.
- Vérifier la MTU, la fragmentation et le MSS.
- Surveiller la charge processeur du routeur pendant le test.
- Contrôler le routage, les règles de pare-feu et la qualité de service.
- Répéter les mesures avec plusieurs serveurs et à différents horaires.
Une mesure de vitesse tunnel GRE fiable repose donc sur une comparaison contrôlée. En séparant l’accès local, le tunnel, le routeur et le chemin distant, vous pouvez identifier la cause réelle du débit faible et appliquer une optimisation adaptée plutôt que modifier la configuration de la box au hasard.