Auteur Sujet: FTTH 10G Free: Mesure de débit automatisé avec iPerf3 en IPv4 vs IPv6 (Lu 75781 fois)

Breizh29 · « **Réponse #312 le:** 16 février 2020 à 18:52:37 »

C'est à nouveau KO chez moi depuis 18h40 (toujours uniquement en IPv6, je reprécise).
J'ai accès à tes 2 images.

underground78 · « **Réponse #313 le:** 16 février 2020 à 18:55:14 »

Ça pourrait pas être une mesure de type "anti-DDoS" qui se déclencherait ?

vivien · « **Réponse #314 le:** 16 février 2020 à 19:21:11 »

Voici les limitations mises en place sur le serveur :

# cat /root/iptables-rules.sh
#!/bin/dash
# Limiter le nombre de sessions tcp par client (un client = une IPv4 ou un /64 en IPv6)
/sbin/iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/sbin/iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 -j REJECT
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 --connlimit-mask 64 -m limit --limit 30/hour --limit-burst 1 -j LOG --log-prefix="drop-c-"
/sbin/ip6tables -A INPUT -p tcp --syn -m connlimit --connlimit-above 100 --connlimit-mask 64 -j REJECT

Je ne sais pas si Bouygues Telecom a une protection.

Maintenant je note que les connexions à Apache fonctionnent.

Deux cas :
- Si le système DDOS bloque les connexions sont bloqués sur tous les ports, Apache ne devrait pas répondre
- Si le système DDOS ne bloque que les connexions du port en question, tu devrait pouvoir utiliser un autre port TCP, sachant que iPerf3 écoute sur 22 ports.

Ton script teste bien les ports un à un ?

Breizh29 · « **Réponse #315 le:** 16 février 2020 à 19:24:32 »

Citation de: vivien le 16 février 2020 à 19:21:11

Ton script teste bien les ports un à un ?

Oui, mais en l'occurrence, lorsque ça merde sur un port en IPv6, ça fait la même chose sur tous les autres a priori...

vivien · « **Réponse #316 le:** 16 février 2020 à 19:27:25 »

Tu aurais moyen de tester depuis une autre IPv6 quand c'est bloqué, pour savoir si c'est ton IP qui est bloqué ou tout les connexion IPv6 ?

Je pense à ton mobile si tu es chez Bouygues Telecom ou Orange.

Breizh29 · « **Réponse #317 le:** 16 février 2020 à 19:33:16 »

Je n’ai pas ça, mais du mac, qui se voit attribuer une autre IPv6, ça le ferait ? Même si c’est le même préfixe...

underground78 · « **Réponse #318 le:** 16 février 2020 à 19:40:04 »

Ça pourrait être côté Free aussi non ? Des pics de trafic sur des ports bizarres qui provoqueraient des faux positifs ?

Breizh29 · « **Réponse #319 le:** 16 février 2020 à 20:12:48 »

De nouveau OK depuis 19h20...
Je ne touche à rien !

vivien · « **Réponse #320 le:** 16 février 2020 à 20:54:20 »

Ce qui est étonnant, c'est que seul l'IPv6 est impacté.

Je ne sais pas si dans ton script il est simple d'inverser l'ordre des tests ipv4 et ipv6 pour voir si cela a un impact.

Sinon, il faudrait vraiment savoir savoir si tu es le seul impacté par le blocage de connexion ou si cela concerne tout le trafic IPv6 du serveur.

Tu pourrais aussi utiliser lille.testdebit.info, qui est moins chargé pour seulement 4ms de latence en +

Breizh29 · « **Réponse #321 le:** 16 février 2020 à 21:05:28 »

Citation de: vivien le 16 février 2020 à 20:54:20

Je ne sais pas si dans ton script il est simple d'inverser l'ordre des tests ipv4 et ipv6 pour voir si cela a un impact.

Ce n’est pas direct, mais possible si vraiment...
Actuellement, les tests sont faits dans cet ordre:
- DL IPv4 mono
- UL IPv4 mono
- DL IPv6 mono
- UL IPv6 mono
- DL IPv4 multi
- UL IPv4 multi
- DL IPv6 multi
- UL IPv6 multi

C’est la présentation dans le csv qui est différente ensuite.

Breizh29 · « **Réponse #322 le:** 17 février 2020 à 09:17:59 »

BBR fait vraiment des merveilles... à se demander à quel prix pour les autres du coup ?
Cela se comporte-t-il comme si j'avais un gyrophare et que tout le monde s'écartait le long du chemin pour laisser passer mes paquets ?

Cf. https://lafibre.info/tcpip/bbr/msg732496/#msg732496 (1er graphique...)

Et quand même un truc que je ne comprends pas : si, pour que BBR soit efficace, il suffit qu'il soit installé sur la machine émettrice, pourquoi, dans les anciens tests avec le mac, alors qu'il était activé côté serveur, a-t-il plombé les débits DL par rapport à Cubic et Illinois ?

vivien · « **Réponse #323 le:** 17 février 2020 à 11:16:43 »

Les tests avec ton Mac sont en contradiction avec les test sous Ubuntu.

J'ai passé le week-end à lire de la doc sur BBR, c'est bien uniquement coté de celui qui émet les données.

Il est même possible de changer de Cubic à BBR en cours de connexion TCP.

Citation de: vivien le 16 février 2020 à 22:24:43

Spotify a également fait des tests sur BBR

L'expérience

De nombreux changements de protocole Internet nécessitent des mises à jour coordonnées des clients et des serveurs (en vous regardant, IPv6!). BBR est différent, il ne doit être activé que du côté de l'expéditeur. Il peut même être activé après l'ouverture de la connexion TCP !

Pour cette expérience, nous avons configuré un sous-ensemble aléatoire d'utilisateurs pour inclure «bbr» dans le nom d'hôte de la demande audio en tant qu'indicateur, et ajouter quelques lignes à la configuration du serveur. Les autres requêtes sont traitées en utilisant la valeur par défaut, CUBIC.

Voici les graphiques plus lisibles pour ceux qui n'ont pas d'écran 4k avec en bonus la mention CUBIC / BBR :