Bonjour, On a finalement trouvé une solution (MTU= 1499 sur les interfaces) et ci-dessous l’explication de ChatGPT qui semble plausible
A noter que le point 4 proposé 'propre' ne marche pas 😉 Michel ------- Très bonne question, et ton intuition est bonne : le fait de descendre la MTU physique à 1499 a permis d’éviter un mécanisme particulier lié à la fragmentation et au DF (Don't Fragment). Voici l’explication complète : ________________________________________ ✅ 1. MTU et overhead IPsec + EOIP • Une interface Ethernet classique : 1500 octets de MTU. • EOIP ajoute un header de 42 octets (IP + GRE-like). • IPsec ESP en mode tunnel ajoute encore ~56 à 74 octets (selon chiffrement, authentification, NAT-T). • Total overhead = environ 100 à 120 octets. Donc ton tunnel ne peut pas réellement transporter 1500 octets, mais environ 1380 à 1400 octets maximum. ________________________________________ ✅ 2. Pourquoi forcer la MTU à 1499 règle le problème ? Quand l’interface physique reste à 1500, le Mikrotik croit qu’il peut envoyer des trames de 1500, et il essaie de faire de la fragmentation interne si nécessaire. Mais : • IPsec, surtout avec NAT-T, déteste la fragmentation interne. • Le DF bit peut être copié dans le tunnel, empêchant la fragmentation. • Résultat : les paquets supérieurs à la capacité réelle du tunnel (≈1400) sont drop (ou "host unreachable"). Quand tu mets 1499 (ou même 1496), RouterOS comprend qu’il doit adapter la taille avant encapsulation. Cela force une PMTUD locale (Path MTU Discovery) et empêche l’envoi de trames trop grosses avant encapsulation. ________________________________________ ✅ 3. Pourquoi pas simplement la MTU de l’EOIP à 1400 ? Parce que la fragmentation problématique peut se produire avant d’entrer dans l’EOIP, sur la sortie physique, si Mikrotik croit que le lien supporte 1500. En baissant la MTU physique : • L’OS sait qu’il ne peut pas envoyer plus de 1499 → il fragmente plus tôt (ou ajuste MSS). • Les paquets IPsec restent en une seule pièce après encapsulation → pas de DF drop. ________________________________________ ✅ 4. La vraie solution “propre” • Définir une MTU cohérente partout (WAN physique, EOIP, bridge). • Ajuster le MSS Clamping pour TCP dans mangle: bash CopierModifier /ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn action=change-mss new-mss=1360 passthrough=yes Vérifier que fragmentation est bien activée pour IPsec si nécessaire -----Message d'origine----- De : [email protected] <[email protected]> De la part de Fabien H Envoyé : mercredi 20 août 2025 09:22 À : frnog-tech <[email protected]> Objet : Re: [FRnOG] [TECH] Config L2 Mikrotik Bonjour Michel, j'avais étudié cette solution dans le passé, mais lors des tests, j'avais obtenu de très mauvais résultats sur le througput (par rapport au débit des liens sous jacents), du coup j'avais abandonné. Le CPU des Mikrotik ne plafonne pas lors de tes tests ? Est-ce que quand tu fais un ping -s 4000 1.1.1.1 ou ping -l 4000 1.1.1.1 , ça fonctionne depuis le PC qui tente d'accéder au site web ? Si ça ne marche pas, il faut réduire ton MTU sur l'interface L2 Mikrotik des 2 côtés pour l'encapsulation Le mer. 13 août 2025 à 11:59, Michel KOENIG via frnog <[email protected]> a écrit : > Bonjour, > Nous rencontrons des lenteurs sur un lien EOIP entre 2 Mikrotik Les > liaison internet des 2 côté sont bonnes et on a bien des temps de > réponse en ping via la L2 correct Par contre, certains sites WEB sont > super lents Je suis parti sur de la modif de MTU puis activation du > MSS Clamping et enfin suppression du FastTack Malheureusement pas > mieux Quelqu'un a une config type pour que je puisse comparer avec > celle qu'on a mis en place ? > Merci > > Michel > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
