Pour la MTU, je ne vois pas ce que je pourrais faire de mon côté car si
il y a fragmentation des paquets du a une MTU réduite par
l'encapsulation IPSEC, c'est côté client. Côté serveur, je devrais
recevoir des paquets re-assemblés ou avec une MTU plus petite.

La piste reste intéressante et je vais voir si je peux faire un test
avec une MTU plus petite côté client.

Jeff

Le mercredi 17 janvier 2024 à 15:26 +0100, ic a écrit :
> Hello, quelques remarques :
> 
> > On 17 Jan 2024, at 14:54, Jean-Francois Maeyhieux <b...@free.fr> wrote:
> > 
> > - Je n'ai pas le looking glass de l'autre côté qui nous intéresse,
> > néanmoins voici un (des rare) traceroute depuis un client de l'AS288
> > vers AS16276 transitant par AS174 (Cogent) exhibant une latence
> > anormale:
> > 
> > 4  154.54.60.21 (154.54.60.21)  143.786 ms  2.221 ms
> 
> La seule chose que ça montre c’est que l’équipement a autre chose à faire que 
> répondre à ton traceroute.
> 
> > -L'analyse de la bande passante en fonction de la taille d'upload
> > montre que le débit diminue lorsque la taille augmente comme si il y
> > avait un bottleneck ou de la QOS:
> 
> ça
> 
> > - Coté AS288, ils utilisent des tunnel IPSEC en interne jusqu'à la
> > sortie vers GTT. Pas de QOS ou de limitation de traffic spécifique.
> 
> + ça me fait penser que tu pourrais essayer de baisser le MTU (à une valeur 
> relativement faible, genre 1400) et voir si ça change quelque chose.
> 
> ++ ic
> 
> 
> 
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à