> 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.
>
>
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
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
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
>
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
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
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
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
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 à
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).
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
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.
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
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
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
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
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
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)
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
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
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
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,
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
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/
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
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é
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
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
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
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.
>
>
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
Bonjour,
je pensais être arrivé au bout de ma migration Redback > ASR, mais non.
Toutes les sessions clientes étaient remontées. Tout avait l'air au top.
Ça pingait dans tous les sens, même dans les VRF.
Mais il n'en était rien. 7h appel téléphonique :
X : "je crois qu'on a un problème, y a
33 matches
Mail list logo
