Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[David Ponzone]

> Le 11 mai 2021 à 10:29, Fabien H  a écrit :
> 
> Il y'a effectivement de la fragmentation sur le CPE sur le trafic montant.
> C'est un fonctionnement habituel. Normalement ton CPE est dimensionné
> selon le débit de ton lien, donc le CPU devrait suivre même avec un peu de
> fragmentation.
> 
> Sachant que la plupart du temps c'est le trafic descendant qui a le débit
> le plus élevé sur un lien donc le CPE ne subit pas de fragmentation dans le
> sens descendant (le LNS oui mais il est surement dimensionné)
> 

Je corrige, je pense que tu voulais dire que les paquets sortants sont 
statistiquement plus petits puisqu’il s’agit essentiellement de requêtes HTTP 
(on va dire 200-300 octets en moyenne), donc pas besoin de frag.
Le CPU est impacté de la même manière qu’on fragmente un gros ou un petit 
paquet, mais effectivement, le gros de la fragmentation, c’est le LNS.
Mais le CPE va être sollicité pour ré-assembler les 2 paquets, défrag quoi, et 
sans ASIC, ça doit prendre autant de CPU que la frag.
Donc à vue de nez, l’impact est le même pour les 2 côtés, sauf que voilà, on va 
pas comparer un ASR avec un RB2011 :)

Kevin,

Pour revenir au RB2011, il est donné pour 800Mbps en routage avec fastpath.
Tu es sûr que tu as fast-path activé ?
Y a pas mal de trucs qui vont le désactiver, donc à ta place, je regarderais 
plutôt les perfs avec des filtres IP (j’imagine que tu en as), soit autour de 
400Mbps.
Mikrotik est pas très clair sur tout ça, comme tous les constructeurs 
d’ailleurs.


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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Remi Desgrange]

On Tue, May 11, 2021 at 11:29 AM Alexis Lameire 
wrote:

> Hello,
> Je rajouterais une information supplémentaire. Avec la négo de la MSS en
> TCP cette impact est d'autant moins visible ! Finalement le trafic UDP,
> hormis le DNS, il ne reste plus grand monde.
>
>
Gene les VPN en tout genre, les services Google qui utilise tous UDP (sur
chrome en tout cas), c'est négligeable ?


> Cordialement
> Alexis
>
> Le mar. 11 mai 2021 à 10:34, Kevin Thiou  a écrit :
>
> > Merci
> >
> > Le mar. 11 mai 2021 à 10:31, Fabien H  a écrit :
> >
> > > Il y'a effectivement de la fragmentation sur le CPE sur le trafic
> > montant.
> > > C'est un fonctionnement habituel. Normalement ton CPE est dimensionné
> > > selon le débit de ton lien, donc le CPU devrait suivre même avec un peu
> > de
> > > fragmentation.
> > >
> > > Sachant que la plupart du temps c'est le trafic descendant qui a le
> débit
> > > le plus élevé sur un lien donc le CPE ne subit pas de fragmentation
> dans
> > le
> > > sens descendant (le LNS oui mais il est surement dimensionné)
> > >
> > >
> > >
> > > Le mar. 11 mai 2021 à 10:13, Kevin Thiou  a
> écrit
> > :
> > >
> > > > Pour changer toujours dans le dépatouillage :)
> > > >
> > > > J'ai des comportements étranges.
> > > >
> > > > Avec les valeurs MTU 1460 et tcp mss 1420, la grande majorité des
> liens
> > > > semblent fonctionner.
> > > >
> > > > Pour certains j'ai des problèmes de débit.
> > > >
> > > > Je me pose la question de la puissance du CPE, car dans beaucoup de
> cas
> > > il
> > > > y a un RB2011.
> > > > Je ne demande pas une solution mais juste une validation de ma
> > réflexion.
> > > >
> > > > La station cliente (windows souvent) à une MTU à 1500, l'interface
> LAN
> > > > client sur le CPE a une MTU de 1500.
> > > > La session pppoe se retrouve avec une MTU à 1460. L'interface de
> > > > terminaison sur le cisco est aussi à 1460.
> > > >
> > > > Me trompè-je si je pense qu'une grosse partie de la fragmentation a
> > lieu
> > > > sur le CPE ?
> > > > Et par conséquent si le CPE est un peu juste niveau CPU le débit
> > > s'écroule.
> > > >
> > > > Merci de vos lumières
> > > >
> > > >
> > > > Le mar. 4 mai 2021 à 23:21, Kevin Thiou  a
> > écrit :
> > > >
> > > >> Je me posais justement la question des calculs théoriques.
> > > >>
> > > >> j'ai trouvé ca comme article :
> > > >>
> > > >>
> > > >>
> > >
> >
> https://www.gigabit-wireless.com/gigabit-wireless/actual-maximum-throughput-gigabit-ethernet/
> > > >>
> > > >>
> > > >> Le mar. 4 mai 2021 à 23:10, David Ponzone 
> a
> > > >> écrit :
> > > >>
> > > >>> J’ai pas osé te le suggérer :)
> > > >>> Le 2011, il commence à dater.
> > > >>> CHR dans une VM c’est pas mal pour les tests de BW.
> > > >>>
> > > >>> Je pense pas qu’ un MTU/MSS un peu réduit puisse générer une perte
> > > >>> significative de bande passante (pas 70% en tout cas).
> > > >>> Il y a des spécialistes en Maths Appliquées aux Problèmes de MTU
> sur
> > la
> > > >>> liste, je suis sûr qu’ils vont venir m'égorger si j’ai tort, tu as
> > > juste à
> > > >>> attendre.
> > > >>>
> > > >>>
> > > >>> Le 4 mai 2021 à 23:04, Kevin Thiou  a écrit
> :
> > > >>>
> > > >>> Merde le mikrotik qui me permet de faire mes tests est un RB2011 et
> > il
> > > >>> galère à envoyer plus ...
> > > >>>
> > > >>> Donc avec un serveur de test public mikrotik on atteint des valeurs
> > > bien
> > > >>> meilleurs.
> > > >>>
> > > >>> Le mar. 4 mai 2021 à 23:01, Kevin Thiou  a
> > > écrit :
> > > >>>
> > >  j'ai le même modèle.
> > > 
> > >  Je vais essayer de comparer à d'autres collectes qui ont le même
> CPE
> > > et
> > >  faire des tests croisés.
> > > 
> > >  Le mar. 4 mai 2021 à 22:53, David Ponzone <
> david.ponz...@gmail.com>
> > a
> > >  écrit :
> > > 
> > > > Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en
> > > > PPP/L2TP (c’est le CPU du MK qui limite à 470 à priori).
> > > > Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
> > > >
> > > > Donc je pense que ton problème est ailleurs.
> > > > Ou alors tu te méfies pas assez du CPU de ton MK.
> > > > Le test UDP prend moins de CPU que TCP, donc si ton MK est moins
> > > > puissant que mon hAPac2, c’est peut-être lui qui te limite en TCP
> > > (en tout
> > > > cas, qui limite le bandwidth-test).
> > > >
> > > > > Le 4 mai 2021 à 22:39, Kevin Thiou  a
> > écrit
> > > :
> > > > >
> > > > > Je ne vais pas rentrer dans le c'est la faute à truc.
> > > > > Pour le moment, celui qui m'occupe ne commence pas par un S.
> > > > >
> > > > > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une
> > vrai
> > > > perte de débit en tcp par rapport à l'udp par exemple.
> > > > >
> > > > > J'utilise l'outil de test de mikrotik qui donne des résultat
> que
> > je
> > > > trouve acceptable.
> > > > > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en
> tcp.
> > > > >
> > > > > Donc en plus de ne 

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Alexis Lameire]

Hello,
Je rajouterais une information supplémentaire. Avec la négo de la MSS en
TCP cette impact est d'autant moins visible ! Finalement le trafic UDP,
hormis le DNS, il ne reste plus grand monde.

Cordialement
Alexis

Le mar. 11 mai 2021 à 10:34, Kevin Thiou  a écrit :

> Merci
>
> Le mar. 11 mai 2021 à 10:31, Fabien H  a écrit :
>
> > Il y'a effectivement de la fragmentation sur le CPE sur le trafic
> montant.
> > C'est un fonctionnement habituel. Normalement ton CPE est dimensionné
> > selon le débit de ton lien, donc le CPU devrait suivre même avec un peu
> de
> > fragmentation.
> >
> > Sachant que la plupart du temps c'est le trafic descendant qui a le débit
> > le plus élevé sur un lien donc le CPE ne subit pas de fragmentation dans
> le
> > sens descendant (le LNS oui mais il est surement dimensionné)
> >
> >
> >
> > Le mar. 11 mai 2021 à 10:13, Kevin Thiou  a écrit
> :
> >
> > > Pour changer toujours dans le dépatouillage :)
> > >
> > > J'ai des comportements étranges.
> > >
> > > Avec les valeurs MTU 1460 et tcp mss 1420, la grande majorité des liens
> > > semblent fonctionner.
> > >
> > > Pour certains j'ai des problèmes de débit.
> > >
> > > Je me pose la question de la puissance du CPE, car dans beaucoup de cas
> > il
> > > y a un RB2011.
> > > Je ne demande pas une solution mais juste une validation de ma
> réflexion.
> > >
> > > La station cliente (windows souvent) à une MTU à 1500, l'interface LAN
> > > client sur le CPE a une MTU de 1500.
> > > La session pppoe se retrouve avec une MTU à 1460. L'interface de
> > > terminaison sur le cisco est aussi à 1460.
> > >
> > > Me trompè-je si je pense qu'une grosse partie de la fragmentation a
> lieu
> > > sur le CPE ?
> > > Et par conséquent si le CPE est un peu juste niveau CPU le débit
> > s'écroule.
> > >
> > > Merci de vos lumières
> > >
> > >
> > > Le mar. 4 mai 2021 à 23:21, Kevin Thiou  a
> écrit :
> > >
> > >> Je me posais justement la question des calculs théoriques.
> > >>
> > >> j'ai trouvé ca comme article :
> > >>
> > >>
> > >>
> >
> https://www.gigabit-wireless.com/gigabit-wireless/actual-maximum-throughput-gigabit-ethernet/
> > >>
> > >>
> > >> Le mar. 4 mai 2021 à 23:10, David Ponzone  a
> > >> écrit :
> > >>
> > >>> J’ai pas osé te le suggérer :)
> > >>> Le 2011, il commence à dater.
> > >>> CHR dans une VM c’est pas mal pour les tests de BW.
> > >>>
> > >>> Je pense pas qu’ un MTU/MSS un peu réduit puisse générer une perte
> > >>> significative de bande passante (pas 70% en tout cas).
> > >>> Il y a des spécialistes en Maths Appliquées aux Problèmes de MTU sur
> la
> > >>> liste, je suis sûr qu’ils vont venir m'égorger si j’ai tort, tu as
> > juste à
> > >>> attendre.
> > >>>
> > >>>
> > >>> Le 4 mai 2021 à 23:04, Kevin Thiou  a écrit :
> > >>>
> > >>> Merde le mikrotik qui me permet de faire mes tests est un RB2011 et
> il
> > >>> galère à envoyer plus ...
> > >>>
> > >>> Donc avec un serveur de test public mikrotik on atteint des valeurs
> > bien
> > >>> meilleurs.
> > >>>
> > >>> Le mar. 4 mai 2021 à 23:01, Kevin Thiou  a
> > écrit :
> > >>>
> >  j'ai le même modèle.
> > 
> >  Je vais essayer de comparer à d'autres collectes qui ont le même CPE
> > et
> >  faire des tests croisés.
> > 
> >  Le mar. 4 mai 2021 à 22:53, David Ponzone 
> a
> >  écrit :
> > 
> > > Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en
> > > PPP/L2TP (c’est le CPU du MK qui limite à 470 à priori).
> > > Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
> > >
> > > Donc je pense que ton problème est ailleurs.
> > > Ou alors tu te méfies pas assez du CPU de ton MK.
> > > Le test UDP prend moins de CPU que TCP, donc si ton MK est moins
> > > puissant que mon hAPac2, c’est peut-être lui qui te limite en TCP
> > (en tout
> > > cas, qui limite le bandwidth-test).
> > >
> > > > Le 4 mai 2021 à 22:39, Kevin Thiou  a
> écrit
> > :
> > > >
> > > > Je ne vais pas rentrer dans le c'est la faute à truc.
> > > > Pour le moment, celui qui m'occupe ne commence pas par un S.
> > > >
> > > > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une
> vrai
> > > perte de débit en tcp par rapport à l'udp par exemple.
> > > >
> > > > J'utilise l'outil de test de mikrotik qui donne des résultat que
> je
> > > trouve acceptable.
> > > > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
> > > >
> > > > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la
> BP
> > > annoncée.
> > > >
> > >
> > >
> > >>>
> >
> > ---
> > 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/

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

Merci

Le mar. 11 mai 2021 à 10:31, Fabien H  a écrit :

> Il y'a effectivement de la fragmentation sur le CPE sur le trafic montant.
> C'est un fonctionnement habituel. Normalement ton CPE est dimensionné
> selon le débit de ton lien, donc le CPU devrait suivre même avec un peu de
> fragmentation.
>
> Sachant que la plupart du temps c'est le trafic descendant qui a le débit
> le plus élevé sur un lien donc le CPE ne subit pas de fragmentation dans le
> sens descendant (le LNS oui mais il est surement dimensionné)
>
>
>
> Le mar. 11 mai 2021 à 10:13, Kevin Thiou  a écrit :
>
> > Pour changer toujours dans le dépatouillage :)
> >
> > J'ai des comportements étranges.
> >
> > Avec les valeurs MTU 1460 et tcp mss 1420, la grande majorité des liens
> > semblent fonctionner.
> >
> > Pour certains j'ai des problèmes de débit.
> >
> > Je me pose la question de la puissance du CPE, car dans beaucoup de cas
> il
> > y a un RB2011.
> > Je ne demande pas une solution mais juste une validation de ma réflexion.
> >
> > La station cliente (windows souvent) à une MTU à 1500, l'interface LAN
> > client sur le CPE a une MTU de 1500.
> > La session pppoe se retrouve avec une MTU à 1460. L'interface de
> > terminaison sur le cisco est aussi à 1460.
> >
> > Me trompè-je si je pense qu'une grosse partie de la fragmentation a lieu
> > sur le CPE ?
> > Et par conséquent si le CPE est un peu juste niveau CPU le débit
> s'écroule.
> >
> > Merci de vos lumières
> >
> >
> > Le mar. 4 mai 2021 à 23:21, Kevin Thiou  a écrit :
> >
> >> Je me posais justement la question des calculs théoriques.
> >>
> >> j'ai trouvé ca comme article :
> >>
> >>
> >>
> https://www.gigabit-wireless.com/gigabit-wireless/actual-maximum-throughput-gigabit-ethernet/
> >>
> >>
> >> Le mar. 4 mai 2021 à 23:10, David Ponzone  a
> >> écrit :
> >>
> >>> J’ai pas osé te le suggérer :)
> >>> Le 2011, il commence à dater.
> >>> CHR dans une VM c’est pas mal pour les tests de BW.
> >>>
> >>> Je pense pas qu’ un MTU/MSS un peu réduit puisse générer une perte
> >>> significative de bande passante (pas 70% en tout cas).
> >>> Il y a des spécialistes en Maths Appliquées aux Problèmes de MTU sur la
> >>> liste, je suis sûr qu’ils vont venir m'égorger si j’ai tort, tu as
> juste à
> >>> attendre.
> >>>
> >>>
> >>> Le 4 mai 2021 à 23:04, Kevin Thiou  a écrit :
> >>>
> >>> Merde le mikrotik qui me permet de faire mes tests est un RB2011 et il
> >>> galère à envoyer plus ...
> >>>
> >>> Donc avec un serveur de test public mikrotik on atteint des valeurs
> bien
> >>> meilleurs.
> >>>
> >>> Le mar. 4 mai 2021 à 23:01, Kevin Thiou  a
> écrit :
> >>>
>  j'ai le même modèle.
> 
>  Je vais essayer de comparer à d'autres collectes qui ont le même CPE
> et
>  faire des tests croisés.
> 
>  Le mar. 4 mai 2021 à 22:53, David Ponzone  a
>  écrit :
> 
> > Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en
> > PPP/L2TP (c’est le CPU du MK qui limite à 470 à priori).
> > Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
> >
> > Donc je pense que ton problème est ailleurs.
> > Ou alors tu te méfies pas assez du CPU de ton MK.
> > Le test UDP prend moins de CPU que TCP, donc si ton MK est moins
> > puissant que mon hAPac2, c’est peut-être lui qui te limite en TCP
> (en tout
> > cas, qui limite le bandwidth-test).
> >
> > > Le 4 mai 2021 à 22:39, Kevin Thiou  a écrit
> :
> > >
> > > Je ne vais pas rentrer dans le c'est la faute à truc.
> > > Pour le moment, celui qui m'occupe ne commence pas par un S.
> > >
> > > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai
> > perte de débit en tcp par rapport à l'udp par exemple.
> > >
> > > J'utilise l'outil de test de mikrotik qui donne des résultat que je
> > trouve acceptable.
> > > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
> > >
> > > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
> > annoncée.
> > >
> >
> >
> >>>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Fabien H]

Il y'a effectivement de la fragmentation sur le CPE sur le trafic montant.
C'est un fonctionnement habituel. Normalement ton CPE est dimensionné
selon le débit de ton lien, donc le CPU devrait suivre même avec un peu de
fragmentation.

Sachant que la plupart du temps c'est le trafic descendant qui a le débit
le plus élevé sur un lien donc le CPE ne subit pas de fragmentation dans le
sens descendant (le LNS oui mais il est surement dimensionné)



Le mar. 11 mai 2021 à 10:13, Kevin Thiou  a écrit :

> Pour changer toujours dans le dépatouillage :)
>
> J'ai des comportements étranges.
>
> Avec les valeurs MTU 1460 et tcp mss 1420, la grande majorité des liens
> semblent fonctionner.
>
> Pour certains j'ai des problèmes de débit.
>
> Je me pose la question de la puissance du CPE, car dans beaucoup de cas il
> y a un RB2011.
> Je ne demande pas une solution mais juste une validation de ma réflexion.
>
> La station cliente (windows souvent) à une MTU à 1500, l'interface LAN
> client sur le CPE a une MTU de 1500.
> La session pppoe se retrouve avec une MTU à 1460. L'interface de
> terminaison sur le cisco est aussi à 1460.
>
> Me trompè-je si je pense qu'une grosse partie de la fragmentation a lieu
> sur le CPE ?
> Et par conséquent si le CPE est un peu juste niveau CPU le débit s'écroule.
>
> Merci de vos lumières
>
>
> Le mar. 4 mai 2021 à 23:21, Kevin Thiou  a écrit :
>
>> Je me posais justement la question des calculs théoriques.
>>
>> j'ai trouvé ca comme article :
>>
>>
>> https://www.gigabit-wireless.com/gigabit-wireless/actual-maximum-throughput-gigabit-ethernet/
>>
>>
>> Le mar. 4 mai 2021 à 23:10, David Ponzone  a
>> écrit :
>>
>>> J’ai pas osé te le suggérer :)
>>> Le 2011, il commence à dater.
>>> CHR dans une VM c’est pas mal pour les tests de BW.
>>>
>>> Je pense pas qu’ un MTU/MSS un peu réduit puisse générer une perte
>>> significative de bande passante (pas 70% en tout cas).
>>> Il y a des spécialistes en Maths Appliquées aux Problèmes de MTU sur la
>>> liste, je suis sûr qu’ils vont venir m'égorger si j’ai tort, tu as juste à
>>> attendre.
>>>
>>>
>>> Le 4 mai 2021 à 23:04, Kevin Thiou  a écrit :
>>>
>>> Merde le mikrotik qui me permet de faire mes tests est un RB2011 et il
>>> galère à envoyer plus ...
>>>
>>> Donc avec un serveur de test public mikrotik on atteint des valeurs bien
>>> meilleurs.
>>>
>>> Le mar. 4 mai 2021 à 23:01, Kevin Thiou  a écrit :
>>>
 j'ai le même modèle.

 Je vais essayer de comparer à d'autres collectes qui ont le même CPE et
 faire des tests croisés.

 Le mar. 4 mai 2021 à 22:53, David Ponzone  a
 écrit :

> Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en
> PPP/L2TP (c’est le CPU du MK qui limite à 470 à priori).
> Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
>
> Donc je pense que ton problème est ailleurs.
> Ou alors tu te méfies pas assez du CPU de ton MK.
> Le test UDP prend moins de CPU que TCP, donc si ton MK est moins
> puissant que mon hAPac2, c’est peut-être lui qui te limite en TCP (en tout
> cas, qui limite le bandwidth-test).
>
> > Le 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
> >
> > Je ne vais pas rentrer dans le c'est la faute à truc.
> > Pour le moment, celui qui m'occupe ne commence pas par un S.
> >
> > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai
> perte de débit en tcp par rapport à l'udp par exemple.
> >
> > J'utilise l'outil de test de mikrotik qui donne des résultat que je
> trouve acceptable.
> > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
> >
> > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
> annoncée.
> >
>
>
>>>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

Pour changer toujours dans le dépatouillage :)

J'ai des comportements étranges.

Avec les valeurs MTU 1460 et tcp mss 1420, la grande majorité des liens
semblent fonctionner.

Pour certains j'ai des problèmes de débit.

Je me pose la question de la puissance du CPE, car dans beaucoup de cas il
y a un RB2011.
Je ne demande pas une solution mais juste une validation de ma réflexion.

La station cliente (windows souvent) à une MTU à 1500, l'interface LAN
client sur le CPE a une MTU de 1500.
La session pppoe se retrouve avec une MTU à 1460. L'interface de
terminaison sur le cisco est aussi à 1460.

Me trompè-je si je pense qu'une grosse partie de la fragmentation a lieu
sur le CPE ?
Et par conséquent si le CPE est un peu juste niveau CPU le débit s'écroule.

Merci de vos lumières


Le mar. 4 mai 2021 à 23:21, Kevin Thiou  a écrit :

> Je me posais justement la question des calculs théoriques.
>
> j'ai trouvé ca comme article :
>
>
> https://www.gigabit-wireless.com/gigabit-wireless/actual-maximum-throughput-gigabit-ethernet/
>
>
> Le mar. 4 mai 2021 à 23:10, David Ponzone  a
> écrit :
>
>> J’ai pas osé te le suggérer :)
>> Le 2011, il commence à dater.
>> CHR dans une VM c’est pas mal pour les tests de BW.
>>
>> Je pense pas qu’ un MTU/MSS un peu réduit puisse générer une perte
>> significative de bande passante (pas 70% en tout cas).
>> Il y a des spécialistes en Maths Appliquées aux Problèmes de MTU sur la
>> liste, je suis sûr qu’ils vont venir m'égorger si j’ai tort, tu as juste à
>> attendre.
>>
>>
>> Le 4 mai 2021 à 23:04, Kevin Thiou  a écrit :
>>
>> Merde le mikrotik qui me permet de faire mes tests est un RB2011 et il
>> galère à envoyer plus ...
>>
>> Donc avec un serveur de test public mikrotik on atteint des valeurs bien
>> meilleurs.
>>
>> Le mar. 4 mai 2021 à 23:01, Kevin Thiou  a écrit :
>>
>>> j'ai le même modèle.
>>>
>>> Je vais essayer de comparer à d'autres collectes qui ont le même CPE et
>>> faire des tests croisés.
>>>
>>> Le mar. 4 mai 2021 à 22:53, David Ponzone  a
>>> écrit :
>>>
 Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en
 PPP/L2TP (c’est le CPU du MK qui limite à 470 à priori).
 Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.

 Donc je pense que ton problème est ailleurs.
 Ou alors tu te méfies pas assez du CPU de ton MK.
 Le test UDP prend moins de CPU que TCP, donc si ton MK est moins
 puissant que mon hAPac2, c’est peut-être lui qui te limite en TCP (en tout
 cas, qui limite le bandwidth-test).

 > Le 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
 >
 > Je ne vais pas rentrer dans le c'est la faute à truc.
 > Pour le moment, celui qui m'occupe ne commence pas par un S.
 >
 > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai
 perte de débit en tcp par rapport à l'udp par exemple.
 >
 > J'utilise l'outil de test de mikrotik qui donne des résultat que je
 trouve acceptable.
 > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
 >
 > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
 annoncée.
 >


>>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

Je me posais justement la question des calculs théoriques.

j'ai trouvé ca comme article :

https://www.gigabit-wireless.com/gigabit-wireless/actual-maximum-throughput-gigabit-ethernet/


Le mar. 4 mai 2021 à 23:10, David Ponzone  a
écrit :

> J’ai pas osé te le suggérer :)
> Le 2011, il commence à dater.
> CHR dans une VM c’est pas mal pour les tests de BW.
>
> Je pense pas qu’ un MTU/MSS un peu réduit puisse générer une perte
> significative de bande passante (pas 70% en tout cas).
> Il y a des spécialistes en Maths Appliquées aux Problèmes de MTU sur la
> liste, je suis sûr qu’ils vont venir m'égorger si j’ai tort, tu as juste à
> attendre.
>
>
> Le 4 mai 2021 à 23:04, Kevin Thiou  a écrit :
>
> Merde le mikrotik qui me permet de faire mes tests est un RB2011 et il
> galère à envoyer plus ...
>
> Donc avec un serveur de test public mikrotik on atteint des valeurs bien
> meilleurs.
>
> Le mar. 4 mai 2021 à 23:01, Kevin Thiou  a écrit :
>
>> j'ai le même modèle.
>>
>> Je vais essayer de comparer à d'autres collectes qui ont le même CPE et
>> faire des tests croisés.
>>
>> Le mar. 4 mai 2021 à 22:53, David Ponzone  a
>> écrit :
>>
>>> Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en PPP/L2TP
>>> (c’est le CPU du MK qui limite à 470 à priori).
>>> Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
>>>
>>> Donc je pense que ton problème est ailleurs.
>>> Ou alors tu te méfies pas assez du CPU de ton MK.
>>> Le test UDP prend moins de CPU que TCP, donc si ton MK est moins
>>> puissant que mon hAPac2, c’est peut-être lui qui te limite en TCP (en tout
>>> cas, qui limite le bandwidth-test).
>>>
>>> > Le 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
>>> >
>>> > Je ne vais pas rentrer dans le c'est la faute à truc.
>>> > Pour le moment, celui qui m'occupe ne commence pas par un S.
>>> >
>>> > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai
>>> perte de débit en tcp par rapport à l'udp par exemple.
>>> >
>>> > J'utilise l'outil de test de mikrotik qui donne des résultat que je
>>> trouve acceptable.
>>> > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
>>> >
>>> > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
>>> annoncée.
>>> >
>>>
>>>
>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[David Ponzone]

J’ai pas osé te le suggérer :)
Le 2011, il commence à dater.
CHR dans une VM c’est pas mal pour les tests de BW.

Je pense pas qu’ un MTU/MSS un peu réduit puisse générer une perte 
significative de bande passante (pas 70% en tout cas).
Il y a des spécialistes en Maths Appliquées aux Problèmes de MTU sur la liste, 
je suis sûr qu’ils vont venir m'égorger si j’ai tort, tu as juste à attendre.


> Le 4 mai 2021 à 23:04, Kevin Thiou  a écrit :
> 
> Merde le mikrotik qui me permet de faire mes tests est un RB2011 et il galère 
> à envoyer plus ...
> 
> Donc avec un serveur de test public mikrotik on atteint des valeurs bien 
> meilleurs.
> 
> Le mar. 4 mai 2021 à 23:01, Kevin Thiou  > a écrit :
> j'ai le même modèle.
> 
> Je vais essayer de comparer à d'autres collectes qui ont le même CPE et faire 
> des tests croisés.
> 
> Le mar. 4 mai 2021 à 22:53, David Ponzone  > a écrit :
> Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en PPP/L2TP 
> (c’est le CPU du MK qui limite à 470 à priori).
> Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
> 
> Donc je pense que ton problème est ailleurs.
> Ou alors tu te méfies pas assez du CPU de ton MK.
> Le test UDP prend moins de CPU que TCP, donc si ton MK est moins puissant que 
> mon hAPac2, c’est peut-être lui qui te limite en TCP (en tout cas, qui limite 
> le bandwidth-test).
> 
> > Le 4 mai 2021 à 22:39, Kevin Thiou  > > a écrit :
> > 
> > Je ne vais pas rentrer dans le c'est la faute à truc.
> > Pour le moment, celui qui m'occupe ne commence pas par un S.
> > 
> > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai perte 
> > de débit en tcp par rapport à l'udp par exemple.
> > 
> > J'utilise l'outil de test de mikrotik qui donne des résultat que je trouve 
> > acceptable.
> > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
> > 
> > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP 
> > annoncée.
> > 
> 


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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

Merde le mikrotik qui me permet de faire mes tests est un RB2011 et il
galère à envoyer plus ...

Donc avec un serveur de test public mikrotik on atteint des valeurs bien
meilleurs.

Le mar. 4 mai 2021 à 23:01, Kevin Thiou  a écrit :

> j'ai le même modèle.
>
> Je vais essayer de comparer à d'autres collectes qui ont le même CPE et
> faire des tests croisés.
>
> Le mar. 4 mai 2021 à 22:53, David Ponzone  a
> écrit :
>
>> Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en PPP/L2TP
>> (c’est le CPU du MK qui limite à 470 à priori).
>> Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
>>
>> Donc je pense que ton problème est ailleurs.
>> Ou alors tu te méfies pas assez du CPU de ton MK.
>> Le test UDP prend moins de CPU que TCP, donc si ton MK est moins puissant
>> que mon hAPac2, c’est peut-être lui qui te limite en TCP (en tout cas, qui
>> limite le bandwidth-test).
>>
>> > Le 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
>> >
>> > Je ne vais pas rentrer dans le c'est la faute à truc.
>> > Pour le moment, celui qui m'occupe ne commence pas par un S.
>> >
>> > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai
>> perte de débit en tcp par rapport à l'udp par exemple.
>> >
>> > J'utilise l'outil de test de mikrotik qui donne des résultat que je
>> trouve acceptable.
>> > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
>> >
>> > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
>> annoncée.
>> >
>>
>>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

j'ai le même modèle.

Je vais essayer de comparer à d'autres collectes qui ont le même CPE et
faire des tests croisés.

Le mar. 4 mai 2021 à 22:53, David Ponzone  a
écrit :

> Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en PPP/L2TP
> (c’est le CPU du MK qui limite à 470 à priori).
> Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.
>
> Donc je pense que ton problème est ailleurs.
> Ou alors tu te méfies pas assez du CPU de ton MK.
> Le test UDP prend moins de CPU que TCP, donc si ton MK est moins puissant
> que mon hAPac2, c’est peut-être lui qui te limite en TCP (en tout cas, qui
> limite le bandwidth-test).
>
> > Le 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
> >
> > Je ne vais pas rentrer dans le c'est la faute à truc.
> > Pour le moment, celui qui m'occupe ne commence pas par un S.
> >
> > Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai
> perte de débit en tcp par rapport à l'udp par exemple.
> >
> > J'utilise l'outil de test de mikrotik qui donne des résultat que je
> trouve acceptable.
> > En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
> >
> > Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
> annoncée.
> >
>
>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[David Ponzone]

Sur un hAPac2, je suis à 470Mbps en TCP sur un FTTH collecté en PPP/L2TP (c’est 
le CPU du MK qui limite à 470 à priori).
Avec MTU 1460 et MSS 1420 sur mon Virtual-Template.

Donc je pense que ton problème est ailleurs.
Ou alors tu te méfies pas assez du CPU de ton MK.
Le test UDP prend moins de CPU que TCP, donc si ton MK est moins puissant que 
mon hAPac2, c’est peut-être lui qui te limite en TCP (en tout cas, qui limite 
le bandwidth-test).

> Le 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
> 
> Je ne vais pas rentrer dans le c'est la faute à truc.
> Pour le moment, celui qui m'occupe ne commence pas par un S.
> 
> Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai perte de 
> débit en tcp par rapport à l'udp par exemple.
> 
> J'utilise l'outil de test de mikrotik qui donne des résultat que je trouve 
> acceptable.
> En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
> 
> Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP annoncée.
> 


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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

J'ai une VT par porte de collecte, ce qui me permet d'être très granulaire
dans les configurations.

Le mar. 4 mai 2021 à 22:49, Fabien H  a écrit :

> Sinon utilise des VT différents avec des MTU différents selon les
> interfaces de collecte ? La collecte ADSL/VDSL est livrée à part ?
>
> Le mar. 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
>
>> Je ne vais pas rentrer dans le c'est la faute à truc.
>> Pour le moment, celui qui m'occupe ne commence pas par un S.
>>
>> Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai perte
>> de débit en tcp par rapport à l'udp par exemple.
>>
>> J'utilise l'outil de test de mikrotik qui donne des résultat que je
>> trouve acceptable.
>> En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
>>
>> Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
>> annoncée.
>>
>> Le mar. 4 mai 2021 à 22:33, David Ponzone  a
>> écrit :
>>
>>> Ah c’est pas un problème opérationnel mais juste un fournisseur qui veut
>>> un ping clean à 2000 ?
>>> C’est qui ce casse-pieds ? C’est un acronyme à 3 lettres qui commence
>>> par S et finit par R ?
>>> Ah mais tu avais tout dit en Janvier: SFR REFLEX (c’est so 1980 comme
>>> nom…)
>>>
>>> Tu as donc un Arista entre le Cisco et SFR ?
>>> Si tu mets temporairement (à 3h du mat), l’IP sur l’Arista plutôt que le
>>> Cisco, le ping est ok à 2000 ?
>>> Je vois que ça comme manière de procéder.
>>>
>>> Mais surtout, surtout, n’oublie pas qu’il est tout à fait possible que
>>> SFR aient fait de la merde de leur côté.
>>>
>>> > Le 4 mai 2021 à 22:24, Kevin Thiou  a écrit :
>>> >
>>> > je l'ai fait sur certains accès.Et ça fonctionne pour certaines
>>> collectes.
>>> >
>>> > Mais certains fournisseurs veulent pouvoir faire un ping -s 2000
>>> df-bit et
>>> > que cela fonctionne.
>>> >
>>> > C'est d'ailleurs écrit dans leur STAS.
>>> >
>>> > Le mar. 4 mai 2021 à 22:17, Fabien H  a écrit
>>> :
>>> >
>>> >> Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as
>>> >> bien mis :
>>> >>
>>> >> mtu 1460
>>> >> ip tcp adjust-mss 1420
>>> >>
>>> >> ?
>>> >> A priori c'est le seul endroit où il faut jouer sur le MTU.
>>> >>
>>> >>
>>> >> Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a
>>> écrit :
>>> >>
>>> >>> Je relance le sujet.
>>> >>> Toujours en galère avec certains accès, des problèmes de MTU en veux
>>> tu en
>>> >>> voilà.
>>> >>>
>>> >>> Mon souci du moment c'est comment faire en sorte que la MTU entre le
>>> LAC
>>> >>> du
>>> >>> provider et mon LNS soit a 2000 minimum.
>>> >>> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui
>>> termine
>>> >>> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
>>> >>> Le ping  df-bit size 2000 ne passe pas.
>>> >>>
>>> >>> Si quelqu'un a fait marcher une conf similaire sur un asr je suis
>>> preneur.
>>> >>>
>>> >>> Merci
>>> >>>
>>> >>> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
>>> >>> fr...@radu-adrian.feurdean.net> a écrit :
>>> >>>
>>>  On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
>>> > L2 et L3 sur le même port.
>>> >
>>> > Le paquet qui passe c'est 1460.
>>> 
>>>  ip tcp adjust-mss 1420 ?
>>> 
>>>  1420 = 1460 - 40 (IP + TCP headers)
>>> 
>>> 
>>>  ---
>>>  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/
>>>
>>>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Fabien H]

Ou alors autre solution tu mets le MTU / TCP MSS qui t'arrange sur le VT
global.

Et sur tes ADSL/VDSL, tu peux faire envoyer par ton radius les attributs IP
forcés :

mtu 1460
ip tcp adjust-mss 1420



Le mar. 4 mai 2021 à 22:49, Fabien H  a écrit :

> Sinon utilise des VT différents avec des MTU différents selon les
> interfaces de collecte ? La collecte ADSL/VDSL est livrée à part ?
>
> Le mar. 4 mai 2021 à 22:39, Kevin Thiou  a écrit :
>
>> Je ne vais pas rentrer dans le c'est la faute à truc.
>> Pour le moment, celui qui m'occupe ne commence pas par un S.
>>
>> Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai perte
>> de débit en tcp par rapport à l'udp par exemple.
>>
>> J'utilise l'outil de test de mikrotik qui donne des résultat que je
>> trouve acceptable.
>> En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
>>
>> Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
>> annoncée.
>>
>> Le mar. 4 mai 2021 à 22:33, David Ponzone  a
>> écrit :
>>
>>> Ah c’est pas un problème opérationnel mais juste un fournisseur qui veut
>>> un ping clean à 2000 ?
>>> C’est qui ce casse-pieds ? C’est un acronyme à 3 lettres qui commence
>>> par S et finit par R ?
>>> Ah mais tu avais tout dit en Janvier: SFR REFLEX (c’est so 1980 comme
>>> nom…)
>>>
>>> Tu as donc un Arista entre le Cisco et SFR ?
>>> Si tu mets temporairement (à 3h du mat), l’IP sur l’Arista plutôt que le
>>> Cisco, le ping est ok à 2000 ?
>>> Je vois que ça comme manière de procéder.
>>>
>>> Mais surtout, surtout, n’oublie pas qu’il est tout à fait possible que
>>> SFR aient fait de la merde de leur côté.
>>>
>>> > Le 4 mai 2021 à 22:24, Kevin Thiou  a écrit :
>>> >
>>> > je l'ai fait sur certains accès.Et ça fonctionne pour certaines
>>> collectes.
>>> >
>>> > Mais certains fournisseurs veulent pouvoir faire un ping -s 2000
>>> df-bit et
>>> > que cela fonctionne.
>>> >
>>> > C'est d'ailleurs écrit dans leur STAS.
>>> >
>>> > Le mar. 4 mai 2021 à 22:17, Fabien H  a écrit
>>> :
>>> >
>>> >> Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as
>>> >> bien mis :
>>> >>
>>> >> mtu 1460
>>> >> ip tcp adjust-mss 1420
>>> >>
>>> >> ?
>>> >> A priori c'est le seul endroit où il faut jouer sur le MTU.
>>> >>
>>> >>
>>> >> Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a
>>> écrit :
>>> >>
>>> >>> Je relance le sujet.
>>> >>> Toujours en galère avec certains accès, des problèmes de MTU en veux
>>> tu en
>>> >>> voilà.
>>> >>>
>>> >>> Mon souci du moment c'est comment faire en sorte que la MTU entre le
>>> LAC
>>> >>> du
>>> >>> provider et mon LNS soit a 2000 minimum.
>>> >>> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui
>>> termine
>>> >>> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
>>> >>> Le ping  df-bit size 2000 ne passe pas.
>>> >>>
>>> >>> Si quelqu'un a fait marcher une conf similaire sur un asr je suis
>>> preneur.
>>> >>>
>>> >>> Merci
>>> >>>
>>> >>> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
>>> >>> fr...@radu-adrian.feurdean.net> a écrit :
>>> >>>
>>>  On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
>>> > L2 et L3 sur le même port.
>>> >
>>> > Le paquet qui passe c'est 1460.
>>> 
>>>  ip tcp adjust-mss 1420 ?
>>> 
>>>  1420 = 1460 - 40 (IP + TCP headers)
>>> 
>>> 
>>>  ---
>>>  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/
>>>
>>>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Fabien H]

Sinon utilise des VT différents avec des MTU différents selon les
interfaces de collecte ? La collecte ADSL/VDSL est livrée à part ?

Le mar. 4 mai 2021 à 22:39, Kevin Thiou  a écrit :

> Je ne vais pas rentrer dans le c'est la faute à truc.
> Pour le moment, celui qui m'occupe ne commence pas par un S.
>
> Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai perte
> de débit en tcp par rapport à l'udp par exemple.
>
> J'utilise l'outil de test de mikrotik qui donne des résultat que je trouve
> acceptable.
> En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.
>
> Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
> annoncée.
>
> Le mar. 4 mai 2021 à 22:33, David Ponzone  a
> écrit :
>
>> Ah c’est pas un problème opérationnel mais juste un fournisseur qui veut
>> un ping clean à 2000 ?
>> C’est qui ce casse-pieds ? C’est un acronyme à 3 lettres qui commence par
>> S et finit par R ?
>> Ah mais tu avais tout dit en Janvier: SFR REFLEX (c’est so 1980 comme
>> nom…)
>>
>> Tu as donc un Arista entre le Cisco et SFR ?
>> Si tu mets temporairement (à 3h du mat), l’IP sur l’Arista plutôt que le
>> Cisco, le ping est ok à 2000 ?
>> Je vois que ça comme manière de procéder.
>>
>> Mais surtout, surtout, n’oublie pas qu’il est tout à fait possible que
>> SFR aient fait de la merde de leur côté.
>>
>> > Le 4 mai 2021 à 22:24, Kevin Thiou  a écrit :
>> >
>> > je l'ai fait sur certains accès.Et ça fonctionne pour certaines
>> collectes.
>> >
>> > Mais certains fournisseurs veulent pouvoir faire un ping -s 2000 df-bit
>> et
>> > que cela fonctionne.
>> >
>> > C'est d'ailleurs écrit dans leur STAS.
>> >
>> > Le mar. 4 mai 2021 à 22:17, Fabien H  a écrit :
>> >
>> >> Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as
>> >> bien mis :
>> >>
>> >> mtu 1460
>> >> ip tcp adjust-mss 1420
>> >>
>> >> ?
>> >> A priori c'est le seul endroit où il faut jouer sur le MTU.
>> >>
>> >>
>> >> Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a
>> écrit :
>> >>
>> >>> Je relance le sujet.
>> >>> Toujours en galère avec certains accès, des problèmes de MTU en veux
>> tu en
>> >>> voilà.
>> >>>
>> >>> Mon souci du moment c'est comment faire en sorte que la MTU entre le
>> LAC
>> >>> du
>> >>> provider et mon LNS soit a 2000 minimum.
>> >>> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui
>> termine
>> >>> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
>> >>> Le ping  df-bit size 2000 ne passe pas.
>> >>>
>> >>> Si quelqu'un a fait marcher une conf similaire sur un asr je suis
>> preneur.
>> >>>
>> >>> Merci
>> >>>
>> >>> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
>> >>> fr...@radu-adrian.feurdean.net> a écrit :
>> >>>
>>  On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
>> > L2 et L3 sur le même port.
>> >
>> > Le paquet qui passe c'est 1460.
>> 
>>  ip tcp adjust-mss 1420 ?
>> 
>>  1420 = 1460 - 40 (IP + TCP headers)
>> 
>> 
>>  ---
>>  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/
>>
>>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

Je ne vais pas rentrer dans le c'est la faute à truc.
Pour le moment, celui qui m'occupe ne commence pas par un S.

Si je met la conf ip mtu 1460 et tcp adjust-mss 1420, j'ai une vrai perte
de débit en tcp par rapport à l'udp par exemple.

J'utilise l'outil de test de mikrotik qui donne des résultat que je trouve
acceptable.
En udp je monte a 420Mbps alors que je plafonne à 125Mbps en tcp.

Donc en plus de ne pas suivre les STAS, les clients n'ont pas la BP
annoncée.

Le mar. 4 mai 2021 à 22:33, David Ponzone  a
écrit :

> Ah c’est pas un problème opérationnel mais juste un fournisseur qui veut
> un ping clean à 2000 ?
> C’est qui ce casse-pieds ? C’est un acronyme à 3 lettres qui commence par
> S et finit par R ?
> Ah mais tu avais tout dit en Janvier: SFR REFLEX (c’est so 1980 comme nom…)
>
> Tu as donc un Arista entre le Cisco et SFR ?
> Si tu mets temporairement (à 3h du mat), l’IP sur l’Arista plutôt que le
> Cisco, le ping est ok à 2000 ?
> Je vois que ça comme manière de procéder.
>
> Mais surtout, surtout, n’oublie pas qu’il est tout à fait possible que SFR
> aient fait de la merde de leur côté.
>
> > Le 4 mai 2021 à 22:24, Kevin Thiou  a écrit :
> >
> > je l'ai fait sur certains accès.Et ça fonctionne pour certaines
> collectes.
> >
> > Mais certains fournisseurs veulent pouvoir faire un ping -s 2000 df-bit
> et
> > que cela fonctionne.
> >
> > C'est d'ailleurs écrit dans leur STAS.
> >
> > Le mar. 4 mai 2021 à 22:17, Fabien H  a écrit :
> >
> >> Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as
> >> bien mis :
> >>
> >> mtu 1460
> >> ip tcp adjust-mss 1420
> >>
> >> ?
> >> A priori c'est le seul endroit où il faut jouer sur le MTU.
> >>
> >>
> >> Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a écrit
> :
> >>
> >>> Je relance le sujet.
> >>> Toujours en galère avec certains accès, des problèmes de MTU en veux
> tu en
> >>> voilà.
> >>>
> >>> Mon souci du moment c'est comment faire en sorte que la MTU entre le
> LAC
> >>> du
> >>> provider et mon LNS soit a 2000 minimum.
> >>> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui
> termine
> >>> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
> >>> Le ping  df-bit size 2000 ne passe pas.
> >>>
> >>> Si quelqu'un a fait marcher une conf similaire sur un asr je suis
> preneur.
> >>>
> >>> Merci
> >>>
> >>> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
> >>> fr...@radu-adrian.feurdean.net> a écrit :
> >>>
>  On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
> > L2 et L3 sur le même port.
> >
> > Le paquet qui passe c'est 1460.
> 
>  ip tcp adjust-mss 1420 ?
> 
>  1420 = 1460 - 40 (IP + TCP headers)
> 
> 
>  ---
>  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/
>
>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[David Ponzone]

Oui voir mon dernier mail, je pense que tu peux faire cette hypothèse.
Ca serait rigolo de prendre une trace sur le port, pour voir si tu reçois une 
réponse tronquée à ton ping que donc le Cisco discard, ou pas de réponse du 
tout.

Et tu peux pas ouvrir un ticket pour demander une normalisation de la conf chez 
eux ?
Ah oui c’est vrai pardon, ils ont pas de support…

> Le 4 mai 2021 à 22:30, Kevin Thiou  a écrit :
> 
> Je suis d'accord que la mtu sur la loopback est inutile.
> Sur les interface 10G j'ai 9214 en MTU donc je suis large.
> Sur l'interface de collecte qui est en 1G j'ai aussi 9214
> 
> Ethernet5 is up, line protocol is up (connected) 
>  Hardware is Ethernet, address is 444c.a830.ba00 (bia 444c.a830.ba00) 
>  Ethernet MTU 9214 bytes , BW 100 kbit 
>  Full-duplex, 1Gb/s, auto negotiation: on, uni-link: disabled
> 
> Mais lorsque je fais des tests de ping, je m'arrête à 1500.
> Donc je suppose que les STAS ne sont pas forcément respectées chez eux ce qui 
> est un peu pénible.
> 
> Le mar. 4 mai 2021 à 22:22, David Ponzone  > a écrit :
> Je doute que le MTU de la Loopback serve à qqchose.
> 
> Et le MTU sur le port TenG, il est bien à 2000 ?
> Si tu as une IP directement en face (parce que tu as peut-être pas vraiment 
> 2000 de MTU jusqu’au LAC), tu devrais pouvoir la pinger avec 2000 et DF.
> Sinon, réduis la taille pour trouver à combien ça bloque (déjà, est-ce que tu 
> dépasses 1500 ?).
> 
> > Le 4 mai 2021 à 22:11, Kevin Thiou  > > a écrit :
> > 
> > Je relance le sujet.
> > Toujours en galère avec certains accès, des problèmes de MTU en veux tu en
> > voilà.
> > 
> > Mon souci du moment c'est comment faire en sorte que la MTU entre le LAC du
> > provider et mon LNS soit a 2000 minimum.
> > J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui termine
> > les tunnels L2TP mais ça n'a pas l'air de fonctionner.
> > Le ping  df-bit size 2000 ne passe pas.
> > 
> > Si quelqu'un a fait marcher une conf similaire sur un asr je suis preneur.
> > 
> > Merci
> > 
> > Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
> > fr...@radu-adrian.feurdean.net > a 
> > écrit :
> > 
> >> On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
> >>> L2 et L3 sur le même port.
> >>> 
> >>> Le paquet qui passe c'est 1460.
> >> 
> >> ip tcp adjust-mss 1420 ?
> >> 
> >> 1420 = 1460 - 40 (IP + TCP headers)
> >> 
> >> 
> >> ---
> >> 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/

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[David Ponzone]

Ah c’est pas un problème opérationnel mais juste un fournisseur qui veut un 
ping clean à 2000 ?
C’est qui ce casse-pieds ? C’est un acronyme à 3 lettres qui commence par S et 
finit par R ?
Ah mais tu avais tout dit en Janvier: SFR REFLEX (c’est so 1980 comme nom…)

Tu as donc un Arista entre le Cisco et SFR ?
Si tu mets temporairement (à 3h du mat), l’IP sur l’Arista plutôt que le Cisco, 
le ping est ok à 2000 ?
Je vois que ça comme manière de procéder.

Mais surtout, surtout, n’oublie pas qu’il est tout à fait possible que SFR 
aient fait de la merde de leur côté.

> Le 4 mai 2021 à 22:24, Kevin Thiou  a écrit :
> 
> je l'ai fait sur certains accès.Et ça fonctionne pour certaines collectes.
> 
> Mais certains fournisseurs veulent pouvoir faire un ping -s 2000 df-bit et
> que cela fonctionne.
> 
> C'est d'ailleurs écrit dans leur STAS.
> 
> Le mar. 4 mai 2021 à 22:17, Fabien H  a écrit :
> 
>> Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as
>> bien mis :
>> 
>> mtu 1460
>> ip tcp adjust-mss 1420
>> 
>> ?
>> A priori c'est le seul endroit où il faut jouer sur le MTU.
>> 
>> 
>> Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a écrit :
>> 
>>> Je relance le sujet.
>>> Toujours en galère avec certains accès, des problèmes de MTU en veux tu en
>>> voilà.
>>> 
>>> Mon souci du moment c'est comment faire en sorte que la MTU entre le LAC
>>> du
>>> provider et mon LNS soit a 2000 minimum.
>>> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui termine
>>> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
>>> Le ping  df-bit size 2000 ne passe pas.
>>> 
>>> Si quelqu'un a fait marcher une conf similaire sur un asr je suis preneur.
>>> 
>>> Merci
>>> 
>>> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
>>> fr...@radu-adrian.feurdean.net> a écrit :
>>> 
 On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
> L2 et L3 sur le même port.
> 
> Le paquet qui passe c'est 1460.
 
 ip tcp adjust-mss 1420 ?
 
 1420 = 1460 - 40 (IP + TCP headers)
 
 
 ---
 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/


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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

Je suis d'accord que la mtu sur la loopback est inutile.
Sur les interface 10G j'ai 9214 en MTU donc je suis large.
Sur l'interface de collecte qui est en 1G j'ai aussi 9214

Ethernet5 is up, line protocol is up (connected)
 Hardware is Ethernet, address is 444c.a830.ba00 (bia 444c.a830.ba00)
 Ethernet MTU 9214 bytes , BW 100 kbit
 Full-duplex, 1Gb/s, auto negotiation: on, uni-link: disabled

Mais lorsque je fais des tests de ping, je m'arrête à 1500.
Donc je suppose que les STAS ne sont pas forcément respectées chez eux ce
qui est un peu pénible.

Le mar. 4 mai 2021 à 22:22, David Ponzone  a
écrit :

> Je doute que le MTU de la Loopback serve à qqchose.
>
> Et le MTU sur le port TenG, il est bien à 2000 ?
> Si tu as une IP directement en face (parce que tu as peut-être pas
> vraiment 2000 de MTU jusqu’au LAC), tu devrais pouvoir la pinger avec 2000
> et DF.
> Sinon, réduis la taille pour trouver à combien ça bloque (déjà, est-ce que
> tu dépasses 1500 ?).
>
> > Le 4 mai 2021 à 22:11, Kevin Thiou  a écrit :
> >
> > Je relance le sujet.
> > Toujours en galère avec certains accès, des problèmes de MTU en veux tu
> en
> > voilà.
> >
> > Mon souci du moment c'est comment faire en sorte que la MTU entre le LAC
> du
> > provider et mon LNS soit a 2000 minimum.
> > J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui termine
> > les tunnels L2TP mais ça n'a pas l'air de fonctionner.
> > Le ping  df-bit size 2000 ne passe pas.
> >
> > Si quelqu'un a fait marcher une conf similaire sur un asr je suis
> preneur.
> >
> > Merci
> >
> > Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
> > fr...@radu-adrian.feurdean.net> a écrit :
> >
> >> On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
> >>> L2 et L3 sur le même port.
> >>>
> >>> Le paquet qui passe c'est 1460.
> >>
> >> ip tcp adjust-mss 1420 ?
> >>
> >> 1420 = 1460 - 40 (IP + TCP headers)
> >>
> >>
> >> ---
> >> 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/

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[David Ponzone]

Fabien,

Je crois que désespéré d’arriver à éliminer ses problèmes de MTU avec le bon 
MTU/MSS au niveau du VT, il tente d’augmenter le MTU de son interco pour 
pouvoir rester en 1500 en PPP.
J’en ai rêvé moi aussi, mais comme je l’ai pas fait au départ, j’ose plus 
maintenant :)

Ceci dit, avec MTU 1460 et MSS 1420 sur le VT, il ne devrait pas avoir de 
problème.
A mon avis, y a un mismatch de MTU ailleurs.

> Le 4 mai 2021 à 22:17, Fabien H  a écrit :
> 
> Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as bien
> mis :
> 
> mtu 1460
> ip tcp adjust-mss 1420
> 
> ?
> A priori c'est le seul endroit où il faut jouer sur le MTU.
> 
> 
> Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a écrit :
> 
>> Je relance le sujet.
>> Toujours en galère avec certains accès, des problèmes de MTU en veux tu en
>> voilà.
>> 
>> Mon souci du moment c'est comment faire en sorte que la MTU entre le LAC du
>> provider et mon LNS soit a 2000 minimum.
>> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui termine
>> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
>> Le ping  df-bit size 2000 ne passe pas.
>> 
>> Si quelqu'un a fait marcher une conf similaire sur un asr je suis preneur.
>> 
>> Merci
>> 
>> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
>> fr...@radu-adrian.feurdean.net> a écrit :
>> 
>>> On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
 L2 et L3 sur le même port.
 
 Le paquet qui passe c'est 1460.
>>> 
>>> ip tcp adjust-mss 1420 ?
>>> 
>>> 1420 = 1460 - 40 (IP + TCP headers)
>>> 
>>> 
>>> ---
>>> 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/


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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

je l'ai fait sur certains accès.Et ça fonctionne pour certaines collectes.

Mais certains fournisseurs veulent pouvoir faire un ping -s 2000 df-bit et
que cela fonctionne.

C'est d'ailleurs écrit dans leur STAS.

Le mar. 4 mai 2021 à 22:17, Fabien H  a écrit :

> Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as
> bien mis :
>
>  mtu 1460
>  ip tcp adjust-mss 1420
>
> ?
> A priori c'est le seul endroit où il faut jouer sur le MTU.
>
>
> Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a écrit :
>
>> Je relance le sujet.
>> Toujours en galère avec certains accès, des problèmes de MTU en veux tu en
>> voilà.
>>
>> Mon souci du moment c'est comment faire en sorte que la MTU entre le LAC
>> du
>> provider et mon LNS soit a 2000 minimum.
>> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui termine
>> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
>> Le ping  df-bit size 2000 ne passe pas.
>>
>> Si quelqu'un a fait marcher une conf similaire sur un asr je suis preneur.
>>
>> Merci
>>
>> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
>> fr...@radu-adrian.feurdean.net> a écrit :
>>
>> > On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
>> > > L2 et L3 sur le même port.
>> > >
>> > > Le paquet qui passe c'est 1460.
>> >
>> > ip tcp adjust-mss 1420 ?
>> >
>> > 1420 = 1460 - 40 (IP + TCP headers)
>> >
>> >
>> > ---
>> > 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/

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[David Ponzone]

Je doute que le MTU de la Loopback serve à qqchose.

Et le MTU sur le port TenG, il est bien à 2000 ?
Si tu as une IP directement en face (parce que tu as peut-être pas vraiment 
2000 de MTU jusqu’au LAC), tu devrais pouvoir la pinger avec 2000 et DF.
Sinon, réduis la taille pour trouver à combien ça bloque (déjà, est-ce que tu 
dépasses 1500 ?).

> Le 4 mai 2021 à 22:11, Kevin Thiou  a écrit :
> 
> Je relance le sujet.
> Toujours en galère avec certains accès, des problèmes de MTU en veux tu en
> voilà.
> 
> Mon souci du moment c'est comment faire en sorte que la MTU entre le LAC du
> provider et mon LNS soit a 2000 minimum.
> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui termine
> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
> Le ping  df-bit size 2000 ne passe pas.
> 
> Si quelqu'un a fait marcher une conf similaire sur un asr je suis preneur.
> 
> Merci
> 
> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
> fr...@radu-adrian.feurdean.net> a écrit :
> 
>> On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
>>> L2 et L3 sur le même port.
>>> 
>>> Le paquet qui passe c'est 1460.
>> 
>> ip tcp adjust-mss 1420 ?
>> 
>> 1420 = 1460 - 40 (IP + TCP headers)
>> 
>> 
>> ---
>> 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/

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Fabien H]

Dans tu virtual-Template sur le LNS, comme indiqué précedemment, tu as bien
mis :

 mtu 1460
 ip tcp adjust-mss 1420

?
A priori c'est le seul endroit où il faut jouer sur le MTU.


Le mar. 4 mai 2021 à 22:13, Kevin Thiou  a écrit :

> Je relance le sujet.
> Toujours en galère avec certains accès, des problèmes de MTU en veux tu en
> voilà.
>
> Mon souci du moment c'est comment faire en sorte que la MTU entre le LAC du
> provider et mon LNS soit a 2000 minimum.
> J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui termine
> les tunnels L2TP mais ça n'a pas l'air de fonctionner.
> Le ping  df-bit size 2000 ne passe pas.
>
> Si quelqu'un a fait marcher une conf similaire sur un asr je suis preneur.
>
> Merci
>
> Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
> fr...@radu-adrian.feurdean.net> a écrit :
>
> > On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
> > > L2 et L3 sur le même port.
> > >
> > > Le paquet qui passe c'est 1460.
> >
> > ip tcp adjust-mss 1420 ?
> >
> > 1420 = 1460 - 40 (IP + TCP headers)
> >
> >
> > ---
> > 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/

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

Je relance le sujet.
Toujours en galère avec certains accès, des problèmes de MTU en veux tu en
voilà.

Mon souci du moment c'est comment faire en sorte que la MTU entre le LAC du
provider et mon LNS soit a 2000 minimum.
J'ai essayé de mettre :  ip mtu 2000 sur l'interface loopback qui termine
les tunnels L2TP mais ça n'a pas l'air de fonctionner.
Le ping  df-bit size 2000 ne passe pas.

Si quelqu'un a fait marcher une conf similaire sur un asr je suis preneur.

Merci

Le mer. 24 mars 2021 à 22:04, Radu-Adrian Feurdean <
fr...@radu-adrian.feurdean.net> a écrit :

> On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
> > L2 et L3 sur le même port.
> >
> > Le paquet qui passe c'est 1460.
>
> ip tcp adjust-mss 1420 ?
>
> 1420 = 1460 - 40 (IP + TCP headers)
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Radu-Adrian Feurdean]

On Wed, Mar 24, 2021, at 15:56, Kevin Thiou wrote:
> L2 et L3 sur le même port.
> 
> Le paquet qui passe c'est 1460.

ip tcp adjust-mss 1420 ?

1420 = 1460 - 40 (IP + TCP headers)


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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

Je ne crie pas victoire mais c'est mieux.

Les ping de toutes tailles passent, la session ssh sur le cpe de test monte
alors qu'elle ne fonctionnait pas avant.

Pour aider les prochains voila des commande de debug utiles :
L2TP:
 L2TP packet errors debugging is on
 L2TP errors debugging is on
 L2TP events debugging is on
PPP:
 PPP authentication debugging is on
 PPP protocol negotiation debugging is on
VPN:
 VPDN events debugging is on
 VPDN errors debugging is on
 VPDN packet debugging is on

J'ai ajouté à la conf du vpdn :
lcp renegotiation on-mismatch

Et précisé la mtu sur l'interface virtual-template :
interface Virtual-Template5
mtu 1460
ip unnumbered Loopback5
no peer default ip address
ppp mtu adaptive
ppp authentication pap chap

Ressource intéressante qui m'a bien aidé :
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/vpdn/configuration/xe-3s/vpd-xe-3s-book/vpd-cfg-additional-feat.html#GUID-CD96BA0D-BC86-4FD7-B89C-602CFA4272B9

Je vous dirais si ça règle mon problème avec tous les types de collecte et
tous les cpe.


Le mer. 24 mars 2021 à 17:02, Kevin Thiou  a écrit :

> Actuellement, j'ai une dizaine de portes certaines en 10G d'autres en 1G.
> Tout ce petit monde arrive sur un Arista.
> Toutes mes sessions connectées sur le un Redback.
>
> J'essaie de changer ce redback par l'ASR.
> Première différence entre Redback et ASR, la connexion physique.
> Le Redback est connecté avec des lag de port 1G
> Le Cisco est connecté avec des ports 10G.
>
> J'ai précisé la MTU à 9214 sur les ports du cisco, de base elle est à 9214
> sur les arista.
> Un "ping ip 172.16.70.76 size 9214 df-bit" entre les ip sur le arista et
> sur le cisco fonctionne jusqu'à 9214 comme attendu.
>
> Je pars donc du principe que la connexion entre arista et cisco supporte
> des paquets de 9214.
>
> J'ai regardé la différence entre ppp mtu adaptative et sans.
>
> Sans mtu adaptative
> Mar 24 14:29:43.432 CET: PPP: Alloc Context [7F252B08EB48]
> Mar 24 14:29:43.432 CET: ppp2358 PPP: Phase is ESTABLISHING
> Mar 24 14:29:43.432 CET: ppp2358 LCP: Event[Jam Start] State[Initial to
> Closed]
> Mar 24 14:29:43.432 CET: ppp2358 LCP: I FORCED rcvd CONFACK len 19
> Mar 24 14:29:43.432 CET: ppp2358 LCP:MRU 1492 (0x010405D4)
> Mar 24 14:29:43.432 CET: ppp2358 LCP:AuthProto CHAP (0x0305C22305)
> Mar 24 14:29:43.432 CET: ppp2358 LCP:MagicNumber 0x2FDDBE11
> (0x05062FDDBE11)
> Mar 24 14:29:43.432 CET: ppp2358 LCP: I FORCED sent CONFACK len 14
> Mar 24 14:29:43.432 CET: ppp2358 LCP:MRU 1480 (0x010405C8)
> Mar 24 14:29:43.432 CET: ppp2358 LCP:MagicNumber 0x042877CC
> (0x0506042877CC)
> *Mar 24 14:29:43.433 CET: ppp2358 PPP: LCP not accepting sent CONFACK*
> Mar 24 14:29:43.433 CET: ppp2358 LCP: O TERMREQ [Closed] id 1 len 4
> Mar 24 14:29:43.433 CET: ppp2358 PPP DISC: LCP Jam options rejected
> Mar 24 14:29:43.433 CET: ppp2358 PPP: Sending Acct Event[Down] id[2F127]
> Mar 24 14:29:43.433 CET: PPP: NET STOP send to AAA.
> Mar 24 14:29:43.433 CET: ppp2358 LCP: Event[DOWN] State[Closed to Initial]
> Mar 24 14:29:43.433 CET: ppp2358 PPP: Phase is DOWN
>
> avec ppp mtu adaptative
> Mar 24 16:04:55.231 CET: ppp3423 PPP: Phase is ESTABLISHING
> Mar 24 16:04:55.231 CET: ppp3423 LCP: Event[Jam Start] State[Initial to
> Closed]
> Mar 24 16:04:55.231 CET: ppp3423 LCP: I FORCED rcvd CONFACK len 19
> Mar 24 16:04:55.231 CET: ppp3423 LCP:MRU 1492 (0x010405D4)
> Mar 24 16:04:55.231 CET: ppp3423 LCP:AuthProto CHAP (0x0305C22305)
> Mar 24 16:04:55.231 CET: ppp3423 LCP:MagicNumber 0x2FDF19D5
> (0x05062FDF19D5)
> Mar 24 16:04:55.231 CET: ppp3423 LCP: I FORCED sent CONFACK len 14
> Mar 24 16:04:55.231 CET: ppp3423 LCP:MRU 1480 (0x010405C8)
> Mar 24 16:04:55.231 CET: ppp3423 LCP:MagicNumber 0x496149B5
> (0x0506496149B5)
> Mar 24 16:04:55.231 CET: ppp3423 LCP: Event[Jam UP] State[Closed to Open]
> Mar 24 16:04:55.252 CET: ppp3423 PPP: Phase is FORWARDING, Attempting
> Forward
> Mar 24 16:04:55.252 CET: ppp3423 LCP: State is Open
> Mar 24 16:04:55.253 CET: ppp3423 PPP: Phase is AUTHENTICATING,
> Unauthenticated User
> Mar 24 16:04:55.253 CET: ppp3423 PPP: Sent CHAP LOGIN Request
> Mar 24 16:04:55.292 CET: ppp3423 PPP: Received LOGIN Response PASS
> Mar 24 16:04:55.292 CET: ppp3423 PPP: Phase is FORWARDING, Attempting
> Forward
> Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   App type set to VPDN
> Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Sequencing default
> tx disabled
> Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Sequencing default
> rx disabled
> Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Framing set to sync
> Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Bearer set to none
> Mar 24 16:04:55.298 CET: VPDN Received L2TUN socket message Data UP
> Mar 24 16:04:55.298 CET: L2TP 00D5F:3BDA4:13E7: FSM-Sn ev DP-Up
> Mar 24 16:04:55.298 CET: L2TP 00D5F:3BDA4:13E7: FSM-Snin
> established
> Mar 24 16:04:55.298 CET: L2TP 00D5F:3BDA4:13E7: FSM-Sn do Ignore-DP-UP
> Mar 24 

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

Actuellement, j'ai une dizaine de portes certaines en 10G d'autres en 1G.
Tout ce petit monde arrive sur un Arista.
Toutes mes sessions connectées sur le un Redback.

J'essaie de changer ce redback par l'ASR.
Première différence entre Redback et ASR, la connexion physique.
Le Redback est connecté avec des lag de port 1G
Le Cisco est connecté avec des ports 10G.

J'ai précisé la MTU à 9214 sur les ports du cisco, de base elle est à 9214
sur les arista.
Un "ping ip 172.16.70.76 size 9214 df-bit" entre les ip sur le arista et
sur le cisco fonctionne jusqu'à 9214 comme attendu.

Je pars donc du principe que la connexion entre arista et cisco supporte
des paquets de 9214.

J'ai regardé la différence entre ppp mtu adaptative et sans.

Sans mtu adaptative
Mar 24 14:29:43.432 CET: PPP: Alloc Context [7F252B08EB48]
Mar 24 14:29:43.432 CET: ppp2358 PPP: Phase is ESTABLISHING
Mar 24 14:29:43.432 CET: ppp2358 LCP: Event[Jam Start] State[Initial to
Closed]
Mar 24 14:29:43.432 CET: ppp2358 LCP: I FORCED rcvd CONFACK len 19
Mar 24 14:29:43.432 CET: ppp2358 LCP:MRU 1492 (0x010405D4)
Mar 24 14:29:43.432 CET: ppp2358 LCP:AuthProto CHAP (0x0305C22305)
Mar 24 14:29:43.432 CET: ppp2358 LCP:MagicNumber 0x2FDDBE11
(0x05062FDDBE11)
Mar 24 14:29:43.432 CET: ppp2358 LCP: I FORCED sent CONFACK len 14
Mar 24 14:29:43.432 CET: ppp2358 LCP:MRU 1480 (0x010405C8)
Mar 24 14:29:43.432 CET: ppp2358 LCP:MagicNumber 0x042877CC
(0x0506042877CC)
*Mar 24 14:29:43.433 CET: ppp2358 PPP: LCP not accepting sent CONFACK*
Mar 24 14:29:43.433 CET: ppp2358 LCP: O TERMREQ [Closed] id 1 len 4
Mar 24 14:29:43.433 CET: ppp2358 PPP DISC: LCP Jam options rejected
Mar 24 14:29:43.433 CET: ppp2358 PPP: Sending Acct Event[Down] id[2F127]
Mar 24 14:29:43.433 CET: PPP: NET STOP send to AAA.
Mar 24 14:29:43.433 CET: ppp2358 LCP: Event[DOWN] State[Closed to Initial]
Mar 24 14:29:43.433 CET: ppp2358 PPP: Phase is DOWN

avec ppp mtu adaptative
Mar 24 16:04:55.231 CET: ppp3423 PPP: Phase is ESTABLISHING
Mar 24 16:04:55.231 CET: ppp3423 LCP: Event[Jam Start] State[Initial to
Closed]
Mar 24 16:04:55.231 CET: ppp3423 LCP: I FORCED rcvd CONFACK len 19
Mar 24 16:04:55.231 CET: ppp3423 LCP:MRU 1492 (0x010405D4)
Mar 24 16:04:55.231 CET: ppp3423 LCP:AuthProto CHAP (0x0305C22305)
Mar 24 16:04:55.231 CET: ppp3423 LCP:MagicNumber 0x2FDF19D5
(0x05062FDF19D5)
Mar 24 16:04:55.231 CET: ppp3423 LCP: I FORCED sent CONFACK len 14
Mar 24 16:04:55.231 CET: ppp3423 LCP:MRU 1480 (0x010405C8)
Mar 24 16:04:55.231 CET: ppp3423 LCP:MagicNumber 0x496149B5
(0x0506496149B5)
Mar 24 16:04:55.231 CET: ppp3423 LCP: Event[Jam UP] State[Closed to Open]
Mar 24 16:04:55.252 CET: ppp3423 PPP: Phase is FORWARDING, Attempting
Forward
Mar 24 16:04:55.252 CET: ppp3423 LCP: State is Open
Mar 24 16:04:55.253 CET: ppp3423 PPP: Phase is AUTHENTICATING,
Unauthenticated User
Mar 24 16:04:55.253 CET: ppp3423 PPP: Sent CHAP LOGIN Request
Mar 24 16:04:55.292 CET: ppp3423 PPP: Received LOGIN Response PASS
Mar 24 16:04:55.292 CET: ppp3423 PPP: Phase is FORWARDING, Attempting
Forward
Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   App type set to VPDN
Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Sequencing default tx
disabled
Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Sequencing default rx
disabled
Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Framing set to sync
Mar 24 16:04:55.297 CET: L2TP 00D5F:3BDA4:13E7:   Bearer set to none
Mar 24 16:04:55.298 CET: VPDN Received L2TUN socket message Data UP
Mar 24 16:04:55.298 CET: L2TP 00D5F:3BDA4:13E7: FSM-Sn ev DP-Up
Mar 24 16:04:55.298 CET: L2TP 00D5F:3BDA4:13E7: FSM-Snin established
Mar 24 16:04:55.298 CET: L2TP 00D5F:3BDA4:13E7: FSM-Sn do Ignore-DP-UP
Mar 24 16:04:55.299 CET: Vi3.22 PPP: Phase is AUTHENTICATING, Authenticated
User
Mar 24 16:04:55.299 CET: Vi3.22 CHAP: O SUCCESS id 1 len 4
Mar 24 16:04:55.299 CET: L2TP:Vi3.22 FS Network to tunnel: Punted 44 byte
pak to l2x process queue
*Mar 24 16:04:55.299 CET: Vi3.22 PPP: Reducing MTU to peer's MRU*
Mar 24 16:04:55.299 CET: Vi3.22 PPP: Phase is UP

On voit la différence de traitement. mais ça ne m'explique pas pourquoi le
trafic "normal" ne fonctionne pas.
J'ai l'impression qu'un "do-not-fragment" apparaît avec ou sans ppp mtu
adaptative. Car seuls les paquets non fragmentés passent.

Le mer. 24 mars 2021 à 16:00, David Ponzone  a
écrit :

> Hmm t’as pas compris ma question je crois :)
> Ca devrait être 1500 sur une interface 10G.
> Je te parle vraiment du port 10G.
> Quand tu montes une collecte, tu commences généralement par vérifier que
> le MTU est ok.
> Bon en général, tu le fais pas, parce qu’entre professionnels, ça se passe
> plutôt bien.
> Eventuellement tu le fais si tu veux monter à plus de 1500 en accord avec
> l’autre côté.
> Mais là tu as un comportement anormal qui pourrait s’expliquer par un mtu
> foireux sur le port 10G.
>
> Le 24 mars 2021 à 15:56, Kevin Thiou  a écrit :
>
> L2 et L3 sur le même port.
>
> Le 

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[David Ponzone]

Hmm t’as pas compris ma question je crois :)
Ca devrait être 1500 sur une interface 10G.
Je te parle vraiment du port 10G.
Quand tu montes une collecte, tu commences généralement par vérifier que le MTU 
est ok.
Bon en général, tu le fais pas, parce qu’entre professionnels, ça se passe 
plutôt bien.
Eventuellement tu le fais si tu veux monter à plus de 1500 en accord avec 
l’autre côté.
Mais là tu as un comportement anormal qui pourrait s’expliquer par un mtu 
foireux sur le port 10G.

> Le 24 mars 2021 à 15:56, Kevin Thiou  a écrit :
> 
> L2 et L3 sur le même port.
> 
> Le paquet qui passe c'est 1460.
> 
> Le mer. 24 mars 2021 à 15:53, David Ponzone  > a écrit :
> On parle de collecte L2 et L3 qui arrivent sur des ports différents ou toutes 
> sur le même ?
> 
> Si ports différents -> je comprends pas
> Si même port -> tu as vérifié le MTU du port lui-même (vérifier, c’est 
> chercher le plus paquet qui passe à coup de ping, pas faire confiance à ce 
> que te dit le mec en face….) ?
> 
> > Le 24 mars 2021 à 15:47, Kevin Thiou  > > a écrit :
> > 
> > Autre précision, mon parc est constitué de mirkrotik et de modem type
> > technicolor.
> > Je ne pourrais pas changer la configuration du parc, il est trop grand.
> > Donc je suis cantonné à trouver une solution sur l'ASR.
> 


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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

L2 et L3 sur le même port.

Le paquet qui passe c'est 1460.

Le mer. 24 mars 2021 à 15:53, David Ponzone  a
écrit :

> On parle de collecte L2 et L3 qui arrivent sur des ports différents ou
> toutes sur le même ?
>
> Si ports différents -> je comprends pas
> Si même port -> tu as vérifié le MTU du port lui-même (vérifier, c’est
> chercher le plus paquet qui passe à coup de ping, pas faire confiance à ce
> que te dit le mec en face….) ?
>
> > Le 24 mars 2021 à 15:47, Kevin Thiou  a écrit :
> >
> > Autre précision, mon parc est constitué de mirkrotik et de modem type
> > technicolor.
> > Je ne pourrais pas changer la configuration du parc, il est trop grand.
> > Donc je suis cantonné à trouver une solution sur l'ASR.
>
>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[David Ponzone]

On parle de collecte L2 et L3 qui arrivent sur des ports différents ou toutes 
sur le même ?

Si ports différents -> je comprends pas
Si même port -> tu as vérifié le MTU du port lui-même (vérifier, c’est chercher 
le plus paquet qui passe à coup de ping, pas faire confiance à ce que te dit le 
mec en face….) ?

> Le 24 mars 2021 à 15:47, Kevin Thiou  a écrit :
> 
> Autre précision, mon parc est constitué de mirkrotik et de modem type
> technicolor.
> Je ne pourrais pas changer la configuration du parc, il est trop grand.
> Donc je suis cantonné à trouver une solution sur l'ASR.


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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

Autre précision, mon parc est constitué de mirkrotik et de modem type
technicolor.
Je ne pourrais pas changer la configuration du parc, il est trop grand.
Donc je suis cantonné à trouver une solution sur l'ASR.

Le mer. 24 mars 2021 à 15:38, Kevin Thiou  a écrit :

> Merci pour les réponses.
>
> Précision, j'ai de tout, adsl, sdsl, ftth.
> J'ai eu le problème sur toutes les collectes, ethernet ou ip
>
> Par contre je fais tourner des sessions L2tp qui passe par de la 4G sans
> problème depuis quelques semaines.
>
> Le mer. 24 mars 2021 à 15:25, David Ponzone  a
> écrit :
>
>> C’est de l’ADSL ?
>> T’as essayé en virant le mtu adaptative (j’ai jamais eu trop de réussite
>> avec ce truc) et en forçant un MTU 1460 partout ?
>> Parce que sur de l’ADSL en livraison L2TP, c’est plutôt 1460 le max.
>>
>> > Le 24 mars 2021 à 14:59, Kevin Thiou  a écrit :
>> >
>> > Côté client c'est un mikrotik avec une session pppoe max-mtu: auto
>> > max-mru:auto
>> > une fois la session montée tout ce petit monde est d'accord sur 1480
>> octets.
>> >
>> > Toutes les idées de debug ou de configuration sont les bien venues.
>> >
>>
>>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[Kevin Thiou]

Merci pour les réponses.

Précision, j'ai de tout, adsl, sdsl, ftth.
J'ai eu le problème sur toutes les collectes, ethernet ou ip

Par contre je fais tourner des sessions L2tp qui passe par de la 4G sans
problème depuis quelques semaines.

Le mer. 24 mars 2021 à 15:25, David Ponzone  a
écrit :

> C’est de l’ADSL ?
> T’as essayé en virant le mtu adaptative (j’ai jamais eu trop de réussite
> avec ce truc) et en forçant un MTU 1460 partout ?
> Parce que sur de l’ADSL en livraison L2TP, c’est plutôt 1460 le max.
>
> > Le 24 mars 2021 à 14:59, Kevin Thiou  a écrit :
> >
> > Côté client c'est un mikrotik avec une session pppoe max-mtu: auto
> > max-mru:auto
> > une fois la session montée tout ce petit monde est d'accord sur 1480
> octets.
> >
> > Toutes les idées de debug ou de configuration sont les bien venues.
> >
>
>

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

Re: [FRnOG] [TECH] Broadband Access Aggregation and DSL Configuration

[David Ponzone]

C’est de l’ADSL ?
T’as essayé en virant le mtu adaptative (j’ai jamais eu trop de réussite avec 
ce truc) et en forçant un MTU 1460 partout ?
Parce que sur de l’ADSL en livraison L2TP, c’est plutôt 1460 le max.

> Le 24 mars 2021 à 14:59, Kevin Thiou  a écrit :
> 
> Côté client c'est un mikrotik avec une session pppoe max-mtu: auto
> max-mru:auto
> une fois la session montée tout ce petit monde est d'accord sur 1480 octets.
> 
> Toutes les idées de debug ou de configuration sont les bien venues.
> 


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