Bonjour

Je constate des débits équivalents en IPv4 et en IPv6 aujourd'hui dans les VM en utilisant des GUA et en désactivant le NH dans freboxOS pour le 1er subnet
Débits mesurés ce matin : 2,1 Gbps (v4 + v6)

Ce débit chute de + de 50% en ipv6 uniquement lorsqu'on a 1 NH de configuré pour le 1er subnet public de la freebox, même quand la VM à 1 GUA sur ce subnet et que la première adresse ipv6 GUA du bloc (= ipv6 publique de la freebox) est le NH (gateway) dans la table de routage de la VM : donc quand le flux sort en direct de la VM sur internet en passant directement par la freebox et en ignorant le NH configuré dans freeboxOS (vérifié avec tcpdump).


Aussi ce débit de 2,1 Gbps double quand le trafic sort par une ULA ---> routeur ipv6 LAN ----> freebox
Mesuré dans la VM à 4,2Gbps à 'instant

Débits et comportement identique en IPv4 (2 fois plus de débit en sortant par un routeur du LAN qu'en sortant en direct sur internet)

Aujourd'hui pour avoir un débit internet équivalent à celui mesuré dans les VM durant l'incident (un peu inférieur à ~5Gbps) en IPv4 et en IPv6, je suis obligé de faire sortir le trafic des VM par un équipement du LAN lui-même sortant sur internet par la freebox.

NB:
Ce comportement est apparu suite au rétablissement des 8 Gbps sur le lien internet fibre global, et durant l'incident le débit direct sur internet des vm v4/v6 était 2 fois meilleur que depuis le rétablissement du débit 8 Gbps sur les liens

Cordialement
nbanba

J'ai peur de ne pas comprendre. Tu fais sortir le FLUX d'une VM par un des ports de la FREEBOX? Par définition ta VM n'est donc pas dans ta Freebox mais par un ordinateur en dehors des disques dur de ta Freebox.
Désolé mais je ne comprends pas l'interet et le but du test.

Me concernant le passage le passage de la DELTA a l ULTRA m'a fait chuté le débit de ma VM de 2.5gbits. Par définition c'est donc soit une limite du DD soit une limite de la Freebox ou les deux.

J’ai une petite augmentation du débit avec le test de checkFtthFree, mais aussi un nouveau message d’avertissement « [!] Le débit pourrait avoir été limité par le paramétrage de la mémoire tampon TCP du système », il faut que je regarde ça quand j’aurai le temps.

Tu peux relancer checkFtthFree en rajoutant le paramètre --suggestions (ou -s en abrégé), cela te donnera directement des conseils précis pour corriger le problème identifié.

Bonjour

Est ce que quelqu'un constate toujours le bridage de sa ligne à ~4Gbps ?

@Free:
Concernant l'incident de chute de débit internet à 2Gbps dans les VM provoqué par le retour des 8Gbps sur les lignes: Voulez vous qu'on ouvre un autre ticket et que je passe ce thread en [Résolu] ?
Merci pour le retour

Cordialement
nbanba

Bonjour

Merci pour votre retour plein de bon sens... au même titre que ma proposition

Il ne me semble pas objectif d'update le présent ticket tant que l'opérateur n'aura pas pris la parole de manière substantielle (La France entière était touchée => un rapport d'incident devrait être publié, enfin il me semble...)


Bien cordialement
nbanba

Bonjour

ca ne me choque pas que le débit d'un VM soit limité a 2Gbps vu le cpu de la freebox... c'est aussi le cas en multi session (-P 4 par exemple) ? apres combien de vcpu une VM de freebox a ?

Merci pour votre retour et l'intérêt que vous portez au sujet.

En fait le problème n'est pas là :
Durant l'incident de bridage des liens à ~4GBps les débits internet mesurés dans les VM sortant en direct sur internet étaient de 4Gbps voir un peu plus car limité par l'incident.
Au moment précis où le débit de 8Gbps est revenu sur les liens, le débit internet des VM sortant en direct sur internet est tombé à 2Gbps
Le débit LAN lui reste de ~6Gbps dl / 8Gbps up (du point de vue de la VM), comme pendant l'incident.
Autre point à noter : si on route le trafic internet de la VM au travers d'un routeur 10Gbps du LAN lui même sortant sur internet par la Freebox au lieu d'utiliser la Freebox comme gateway dans la VM,  alors on obtient un trafic internet de 4,5Gbps ~5Gbps dans la VM (sans aucune optimisation à aucun niveau,  je suis sûr qu'on peut faire mieux)
Cela montre bien les capacités de la VM à avoir un débit reseau global d'environ 5Gbps+ donc aucune raison que le débit de sortie direct internet soit limité à 2Gbps (c'est la même nic virtio pour sortirsur le wan ou sur le lan, les vm n'ont qu'une interface "physique").

NB: les tests effectués durant l'incident ont été faits avec la même VM (celle utilisée pendant l'incident) puis reproduis avec exactement les mêmes VM (même conf hardware,  même image,  même réseaux, même conf réseaux, etc...) et aussi en gonflant RAM + vCPU, toujours avec les mêmes résultats

D'où la persistance du présent tickets (d'ailleurs merci encore pour votre aide)

Cordialement
nbanba

Bonjour

J'avais déjà cet historique.


C'est la meme nic mais pas les memes chemins dans le kernel de la freebox.
dans un cas c'est INPUT/OUTPUT vers WAN
dans l'autre c'est INPUT/OUTPUT vers LAN puis quand ca revient dans la freebox FORWARD, ce dernier est fortement optimisé dans la freebox pour tenir le débit. ca peut expliqué la différence.
j'imagine que cette nic virtio est sur le bridge lan de la freebox ? puisqu'il doit subir le NAT en sortie IPv4.

les IP des VMs sont sur le LAN aussi ou un subnet a part? quid en IPv6?

Ca n'explique bien sur pas le changement survenu sauf s'ils ont poussé un changement sur les box (sans reboot) au niveau des allocations ressources cpu ou lignes PCI par exemple ou autre pour privilégier le trafic traversant (FORWARD). c'est ca que je ne trouverai pas choquant (meme si c'est une regression par rapport a avant).

Je suis bien d'accord au niveau des chemins dans le kernel hôte (peut être même y a t'il du routage entre plusieurs namespaces (netns)?)
Je suppose également pour le 'bridge VirtIO'

historiquement c'était sur de subnets séparés (non prévu par Free initialement mais Free laisse un accès non limitatif au L2 (promiscus) et je ne vous fait pas un dessin... quand on à accès au L2 ... on fait ce qu'on veut...)
Mais lors de l'incident de bridage des liens, j'ai bypass tout ça, et j'ai activé le L3 sur la nic "physique" dans la VM au lieu de faire sortir le trafic par des interfaces vlan utilisant pour gateway les firewalls du LAN
J'ai mis la gateway en direct sur la Freebox
Les tables de routages sont ici https://lafibre.info/1gb-free/test-svp-suspicion-de-limitation-a-4gps-des-freebox-delta-ultra/msg1108262/#msg1108262
(192.168.100.0/24 c'est le subnet derrière la freebox)

idem IPv4 / IPv6 sauf qu'en IPv6 j'ai fini par configurer une GUA direct dans la VM avec comme NH l'IPv6 de la Freebox et j'ai fini par désactiver le NH dans FreeboxOS pour ce subnet car cela créait une situation de routage asymétrique (dans 50% des cas car si je mettait dans la VM omme NH une GUA du firewall au lieu de metrre celle de la Freebox le routage était bien symétrique)

Donc oui les IP des VM pour ces tests sont bien sur une pseudo DMZ (nomansland entre freebox et firewall) avec la dualité IPv4 privée sur le "LAN freebox" et IPv6 public sur le "WAN derrnière la freebox" (j'attend le magic packet avant de shoot l'image car sur ce point je ne partage pas votre point de vue (même pas du tout, j'ai vu des attaques à la limite de électronique... donc tous à poil sur le net sous prétexte qu'IPv6 et pas de ports ouvert, ce n'est pas pour moi ) fin de digression)...

En gros je suis retourné dans le mode le plus basique possible, celui utilisé par 99,99% des utilisateurs des VM Freebox pour faire les tests

Tout est pareil, limité à 2Gbps en IPv6 et en IPv4 (et la parallèlisation n'apporte rien) quand on sort sur le net en direct alors que le même iperf vers un peer du LAN (qui plus est derrière les firewalls) donne 8Gbps/6Gbps

Et le test de faire sortir le trafic de la VM par un équipement du LAN montre bien que la VM n'est pas en cause (elle est même très capable)

Concernant le bridge interne à la freebox, il faut noter que pendant l'incident on mesurait plus de 4Gbps sur le net en sortant en direct par ce bridge et sans rien faire (même pas reboot la box ou la VM) au rétablissement du débit de 8Gbps sur les liens le débit de ce fameux bridge à été divisé de moitié (peut-être plus)
=> le BUG ! perte de capacité soudaine de plus de 50% dans les VM coordonnées avec la résolution de l'incident de bridage des liens (effet de bord? régression en tout cas)

Après de mon côté je peux spéculer longtemps malheureusement, comme le fournisseur ne s'exprime pas... Une seule chose est sure, je ne lâcherai pas !

Cordialement
nbanba