RE: [FRnOG] [TECH] lien de transit SFR
un petit outil pourfaire les tests facilement : http://www.elifulkerson.com/projects/mturoute.php -- Louis -Message d'origine- De : David Ponzone Envoyé : vendredi 18 décembre 2020 14:56 À : Nicolas Parpandet Cc : BELLOTTO Louis ; frnog-tech Objet : Re: [FRnOG] [TECH] lien de transit SFR Attention y a des ping qui attendent en argument la taille du paquet headers inclus, et d’autre la taille du payload. Généralement ça affiche size_payload(size_withheaders) avant de commencer le ping. Ceci dit, pour être sûr sûr que tout est ok, ajoute le bit DF. Si ça passe à 1472(1500) avec DF, et que ça passe plus avec 1473(1501), tout va bien. Sinon problème. > Le 18 déc. 2020 à 14:41, Nicolas Parpandet a écrit : > > > Bonjour, > > Ok bonne idée pour le mtu, > j'ai le ping qui monte à 1472, donc c'est OK à priori... (+20 IP + 8 > ICMP = 1500) > > > Merci > > Nicolas > > - Mail original - >> De: "BELLOTTO Louis" >> À: "frnog-tech" >> Envoyé: Vendredi 18 Décembre 2020 14:09:50 >> Objet: RE: [FRnOG] [TECH] lien de transit SFR > >> Bonjour, >> >> On a eu aussi un truc du même genre. >> Le souci venait du réglage du MTU sur un des routeurs opérateur... >> >> Point peut être à vérifier >> >> >> -- >> Louis >> >> >> >> -Message d'origine- >> De : frnog-requ...@frnog.org De la part de >> Thierry Chich Envoyé : vendredi 18 décembre 2020 13:54 À : 'Olivier >> Tirat BYON' ; 'Nicolas Parpandet' >> ; 'frnog-tech' Objet : RE: >> [FRnOG] [TECH] lien de transit SFR >> >> Bonjour >> >> C'est vrai que j'aurais pensé à priori à un shaping. Bien sûr, il >> peut aussi y avoir des soucis liés à la latence sur le lien qui peut >> diminuer fortement le débit atteignable en tcp. >> J'ai déjà eu aussi des effets particulièrement forts de l'interaction >> entre politique de firewalling et offloading des cartes réseaux. Le >> débit passait de 70Mo/s à 250 Mo/s en désactivant l'offloading ( >> ethtool -K ens192 tso off) sur certaines version de redhat. >> >> Tout ça pour dire que ce genre de constat dépend parfois de >> paramètres très complexes à identifier >> >> Thierry CHICH >> >> -Message d'origine- >> De : frnog-requ...@frnog.org De la part de >> Olivier Tirat BYON Envoyé : vendredi 18 décembre 2020 12:25 À : >> Nicolas Parpandet ; frnog-tech >> Objet : Re: [FRnOG] [TECH] lien de transit SFR >> >> Bonjour >> >> Bon différence majeur entre udp et tcp... l'aquittement des paquets >> (TCP ACK). >> >> On peut tester un upload indépendament du download ent UDP mais pas >> du tout en TCP. >> >> Il faut faire gaffe au debit en download, s'assurer qu'il y a la >> place dans le tuyau pour les paquets TCP ACK. Et bien geré la fenêtre >> pour eviter les TCP RETRANSMIT >> >> Si en fait ton lien passe les 850 Mbit/s en udp c'est que le niveau >> peut atteindre ces performances indépendamment. Donc le problème en >> TCP ne doit pas venir du lien. Après tester des performances réelles >> d'un transit c'est pas facile car ca dépend aussi de l'autre >> extrémité;) >> >> Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit : >>> >>> Bonjour, >>> >>> Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte >>> bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si >>> il y avait une QOS quelque part sur les sessions TCP, (le chiffre de >>> 100Mbits/s revient tellement souvent dans nos tests, la probabilité >>> que cela soit lié au hasard me semble faible...) >>> >>> De plus, avec une dizaine de sessions tcp en // , le débit global >>> plafonne à 350Mbits... >>> >>> Cela fait plusieurs semaines que nous échangeons dans tous les sens >>> avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le >>> problème, et cela n'avance pas ! >>> >>> est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de >>> limite avec cet opérateur ?, nous avons fait énormément de contrôles >>> de notre côté, il me semble que c'est bien en face le soucis ..., il >>> peut toujours subsister un doute, mais si quelqu'un à une expérience sur le >>> sujet ! >>> >>> Merci, A+ >>> >>> Nicolas >>> >>> >>> >>> --- >>> Liste de diffusion du FRnOG >>> http://www.frnog.org/ >> &g
Re: [FRnOG] [TECH] lien de transit SFR
Bonjour, Ok bonne idée pour le mtu, j'ai le ping qui monte à 1472, donc c'est OK à priori... (+20 IP + 8 ICMP = 1500) Merci Nicolas - Mail original - > De: "BELLOTTO Louis" > À: "frnog-tech" > Envoyé: Vendredi 18 Décembre 2020 14:09:50 > Objet: RE: [FRnOG] [TECH] lien de transit SFR > Bonjour, > > On a eu aussi un truc du même genre. > Le souci venait du réglage du MTU sur un des routeurs opérateur... > > Point peut être à vérifier > > > -- > Louis > > > > -Message d'origine- > De : frnog-requ...@frnog.org De la part de Thierry > Chich > Envoyé : vendredi 18 décembre 2020 13:54 > À : 'Olivier Tirat BYON' ; 'Nicolas Parpandet' > ; 'frnog-tech' > Objet : RE: [FRnOG] [TECH] lien de transit SFR > > Bonjour > > C'est vrai que j'aurais pensé à priori à un shaping. Bien sûr, il peut aussi y > avoir des soucis liés à la latence sur le lien qui peut diminuer fortement le > débit atteignable en tcp. > J'ai déjà eu aussi des effets particulièrement forts de l'interaction entre > politique de firewalling et offloading des cartes réseaux. Le débit passait de > 70Mo/s à 250 Mo/s en désactivant l'offloading ( ethtool -K ens192 tso off) sur > certaines version de redhat. > > Tout ça pour dire que ce genre de constat dépend parfois de paramètres très > complexes à identifier > > Thierry CHICH > > -Message d'origine- > De : frnog-requ...@frnog.org De la part de Olivier > Tirat BYON Envoyé : vendredi 18 décembre 2020 12:25 À : Nicolas Parpandet > ; frnog-tech Objet : Re: [FRnOG] [TECH] > lien de transit SFR > > Bonjour > > Bon différence majeur entre udp et tcp... l'aquittement des paquets > (TCP ACK). > > On peut tester un upload indépendament du download ent UDP mais pas du tout en > TCP. > > Il faut faire gaffe au debit en download, s'assurer qu'il y a la place dans le > tuyau pour les paquets TCP ACK. Et bien geré la fenêtre pour eviter les TCP > RETRANSMIT > > Si en fait ton lien passe les 850 Mbit/s en udp c'est que le niveau peut > atteindre ces performances indépendamment. Donc le problème en TCP ne doit pas > venir du lien. Après tester des performances réelles d'un transit c'est pas > facile car ca dépend aussi de l'autre extrémité;) > > Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit : >> >> Bonjour, >> >> Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte >> bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si >> il y avait une QOS quelque part sur les sessions TCP, (le chiffre de >> 100Mbits/s revient tellement souvent dans nos tests, la probabilité >> que cela soit lié au hasard me semble faible...) >> >> De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à >> 350Mbits... >> >> Cela fait plusieurs semaines que nous échangeons dans tous les sens >> avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le problème, >> et >> cela n'avance pas ! >> >> est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de >> limite avec cet opérateur ?, nous avons fait énormément de contrôles >> de notre côté, il me semble que c'est bien en face le soucis ..., il peut >> toujours subsister un doute, mais si quelqu'un à une expérience sur le sujet >> ! >> >> Merci, A+ >> >> Nicolas >> >> >> >> --- >> 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/ > > - > Ce message et toutes les pièces jointes sont confidentiels. Il est établi à > l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce > message non conforme à sa destination, toute diffusion, copie ou toute > publication, totale ou partielle, est interdite, sauf autorisation expresse > préalable. Son contenu ne saurait constituer en aucun cas un engagement > contractuel, une offre de souscrire à quelconque produit ou instrument > financier ou une sollicitation à investir de la part du Groupe La Française et > toutes opinions exprimées dans ce message ne sauraient nécessairement refléter > celle du Groupe La Française. Le contenu de cet email peut contenir des virus > informatiques qui pourraient endommager votre système informatique. Bien que > Groupe La Française ait pris toutes l
RE: [FRnOG] [TECH] lien de transit SFR
Bonjour, On a eu aussi un truc du même genre. Le souci venait du réglage du MTU sur un des routeurs opérateur... Point peut être à vérifier -- Louis -Message d'origine- De : frnog-requ...@frnog.org De la part de Thierry Chich Envoyé : vendredi 18 décembre 2020 13:54 À : 'Olivier Tirat BYON' ; 'Nicolas Parpandet' ; 'frnog-tech' Objet : RE: [FRnOG] [TECH] lien de transit SFR Bonjour C'est vrai que j'aurais pensé à priori à un shaping. Bien sûr, il peut aussi y avoir des soucis liés à la latence sur le lien qui peut diminuer fortement le débit atteignable en tcp. J'ai déjà eu aussi des effets particulièrement forts de l'interaction entre politique de firewalling et offloading des cartes réseaux. Le débit passait de 70Mo/s à 250 Mo/s en désactivant l'offloading ( ethtool -K ens192 tso off) sur certaines version de redhat. Tout ça pour dire que ce genre de constat dépend parfois de paramètres très complexes à identifier Thierry CHICH -Message d'origine- De : frnog-requ...@frnog.org De la part de Olivier Tirat BYON Envoyé : vendredi 18 décembre 2020 12:25 À : Nicolas Parpandet ; frnog-tech Objet : Re: [FRnOG] [TECH] lien de transit SFR Bonjour Bon différence majeur entre udp et tcp... l'aquittement des paquets (TCP ACK). On peut tester un upload indépendament du download ent UDP mais pas du tout en TCP. Il faut faire gaffe au debit en download, s'assurer qu'il y a la place dans le tuyau pour les paquets TCP ACK. Et bien geré la fenêtre pour eviter les TCP RETRANSMIT Si en fait ton lien passe les 850 Mbit/s en udp c'est que le niveau peut atteindre ces performances indépendamment. Donc le problème en TCP ne doit pas venir du lien. Après tester des performances réelles d'un transit c'est pas facile car ca dépend aussi de l'autre extrémité;) Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit : > > Bonjour, > > Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte > bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si > il y avait une QOS quelque part sur les sessions TCP, (le chiffre de > 100Mbits/s revient tellement souvent dans nos tests, la probabilité > que cela soit lié au hasard me semble faible...) > > De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à > 350Mbits... > > Cela fait plusieurs semaines que nous échangeons dans tous les sens > avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le problème, > et cela n'avance pas ! > > est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de > limite avec cet opérateur ?, nous avons fait énormément de contrôles > de notre côté, il me semble que c'est bien en face le soucis ..., il peut > toujours subsister un doute, mais si quelqu'un à une expérience sur le sujet ! > > Merci, A+ > > Nicolas > > > > --- > 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/ - Ce message et toutes les pièces jointes sont confidentiels. Il est établi à l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce message non conforme à sa destination, toute diffusion, copie ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse préalable. Son contenu ne saurait constituer en aucun cas un engagement contractuel, une offre de souscrire à quelconque produit ou instrument financier ou une sollicitation à investir de la part du Groupe La Française et toutes opinions exprimées dans ce message ne sauraient nécessairement refléter celle du Groupe La Française. Le contenu de cet email peut contenir des virus informatiques qui pourraient endommager votre système informatique. Bien que Groupe La Française ait pris toutes les précautions raisonnables pour minimiser ce risque, nous déclinons toute responsabilité pour tout dommage que vous pourriez subir en raison de virus informatiques. Si vous recevez ce courriel par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. Nous vous invitons à prendre connaissance de notre politique de confidentialité et de cookies en cliquant ici https://www.la-francaise.com/fr/politique-de-confidentialite-et-de-cookies/ - This message and any attachments are confidential and may be legally privileged or otherwise protected from disclosure. It is intended only for the stated addressee(s). Any use, dissemination, copy or disclosure of this message not in accordance with its purpose, either in whole or in part, is prohibited without our prior form
RE: [FRnOG] [TECH] lien de transit SFR
Bonjour C'est vrai que j'aurais pensé à priori à un shaping. Bien sûr, il peut aussi y avoir des soucis liés à la latence sur le lien qui peut diminuer fortement le débit atteignable en tcp. J'ai déjà eu aussi des effets particulièrement forts de l'interaction entre politique de firewalling et offloading des cartes réseaux. Le débit passait de 70Mo/s à 250 Mo/s en désactivant l'offloading ( ethtool -K ens192 tso off) sur certaines version de redhat. Tout ça pour dire que ce genre de constat dépend parfois de paramètres très complexes à identifier Thierry CHICH -Message d'origine- De : frnog-requ...@frnog.org De la part de Olivier Tirat BYON Envoyé : vendredi 18 décembre 2020 12:25 À : Nicolas Parpandet ; frnog-tech Objet : Re: [FRnOG] [TECH] lien de transit SFR Bonjour Bon différence majeur entre udp et tcp... l'aquittement des paquets (TCP ACK). On peut tester un upload indépendament du download ent UDP mais pas du tout en TCP. Il faut faire gaffe au debit en download, s'assurer qu'il y a la place dans le tuyau pour les paquets TCP ACK. Et bien geré la fenêtre pour eviter les TCP RETRANSMIT Si en fait ton lien passe les 850 Mbit/s en udp c'est que le niveau peut atteindre ces performances indépendamment. Donc le problème en TCP ne doit pas venir du lien. Après tester des performances réelles d'un transit c'est pas facile car ca dépend aussi de l'autre extrémité;) Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit : > > Bonjour, > > Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte > bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si > il y avait une QOS quelque part sur les sessions TCP, (le chiffre de > 100Mbits/s revient tellement souvent dans nos tests, la probabilité > que cela soit lié au hasard me semble faible...) > > De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à > 350Mbits... > > Cela fait plusieurs semaines que nous échangeons dans tous les sens > avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le problème, > et cela n'avance pas ! > > est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de > limite avec cet opérateur ?, nous avons fait énormément de contrôles > de notre côté, il me semble que c'est bien en face le soucis ..., il peut > toujours subsister un doute, mais si quelqu'un à une expérience sur le sujet ! > > Merci, A+ > > Nicolas > > > > --- > 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] lien de transit SFR
Bonjour Bon différence majeur entre udp et tcp... l'aquittement des paquets (TCP ACK). On peut tester un upload indépendament du download ent UDP mais pas du tout en TCP. Il faut faire gaffe au debit en download, s'assurer qu'il y a la place dans le tuyau pour les paquets TCP ACK. Et bien geré la fenêtre pour eviter les TCP RETRANSMIT Si en fait ton lien passe les 850 Mbit/s en udp c'est que le niveau peut atteindre ces performances indépendamment. Donc le problème en TCP ne doit pas venir du lien. Après tester des performances réelles d'un transit c'est pas facile car ca dépend aussi de l'autre extrémité;) Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit : > > Bonjour, > > Nous avons un nouveau lien de transit 1Gbits/s avec SFR, > l'UDP monte bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme > si il y avait une QOS quelque part sur les sessions TCP, > (le chiffre de 100Mbits/s revient tellement souvent dans nos tests, la > probabilité que cela soit lié au hasard me semble faible...) > > De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à > 350Mbits... > > Cela fait plusieurs semaines que nous échangeons dans tous les sens avec > l'opérateur (iperfs etc), > c'est bien sur à nous de prouver le problème, et cela n'avance pas ! > > est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de limite > avec cet opérateur ?, > nous avons fait énormément de contrôles de notre côté, il me semble que c'est > bien en face le soucis ..., > il peut toujours subsister un doute, mais si quelqu'un à une expérience sur > le sujet ! > > Merci, A+ > > Nicolas > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] lien de transit SFR
Glasnost fait le job. Voir ici https://github.com/marcelscode/glasnost Kv > Le 18 déc. 2020 à 11:52, Nicolas Parpandet a écrit : > > > > Bonjour, > > Nous avons un nouveau lien de transit 1Gbits/s avec SFR, > l'UDP monte bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme > si il y avait une QOS quelque part sur les sessions TCP, > (le chiffre de 100Mbits/s revient tellement souvent dans nos tests, la > probabilité que cela soit lié au hasard me semble faible...) > > De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à > 350Mbits... > > Cela fait plusieurs semaines que nous échangeons dans tous les sens avec > l'opérateur (iperfs etc), > c'est bien sur à nous de prouver le problème, et cela n'avance pas ! > > est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de limite > avec cet opérateur ?, > nous avons fait énormément de contrôles de notre côté, il me semble que c'est > bien en face le soucis ..., > il peut toujours subsister un doute, mais si quelqu'un à une expérience sur > le sujet ! > > Merci, A+ > > Nicolas > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] lien de transit SFR
Bonjour, Latence, packet loss quelconque ? Quel type de lien de transit ? sur quel medium ? btw pourquoi prendre du transit chez SFR ? (seul transitaire disponible ?) Cdt, On 18/12/2020 11:52, Nicolas Parpandet wrote: Bonjour, Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si il y avait une QOS quelque part sur les sessions TCP, (le chiffre de 100Mbits/s revient tellement souvent dans nos tests, la probabilité que cela soit lié au hasard me semble faible...) De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à 350Mbits... Cela fait plusieurs semaines que nous échangeons dans tous les sens avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le problème, et cela n'avance pas ! est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de limite avec cet opérateur ?, nous avons fait énormément de contrôles de notre côté, il me semble que c'est bien en face le soucis ..., il peut toujours subsister un doute, mais si quelqu'un à une expérience sur le sujet ! Merci, A+ Nicolas --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] lien de transit SFR
Bonjour, Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si il y avait une QOS quelque part sur les sessions TCP, (le chiffre de 100Mbits/s revient tellement souvent dans nos tests, la probabilité que cela soit lié au hasard me semble faible...) De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à 350Mbits... Cela fait plusieurs semaines que nous échangeons dans tous les sens avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le problème, et cela n'avance pas ! est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de limite avec cet opérateur ?, nous avons fait énormément de contrôles de notre côté, il me semble que c'est bien en face le soucis ..., il peut toujours subsister un doute, mais si quelqu'un à une expérience sur le sujet ! Merci, A+ Nicolas --- Liste de diffusion du FRnOG http://www.frnog.org/
