Bonjour,

Suite à quelques tests chez nous de perfs IPv6 en fonction des équipements L3, je vous propose de répertorier un peu les différents résultats en fonction des équipements traversés. Je suis preneurs également de retours d'expérience différents sur le même matos.

Contexte :

Je fais mes tests vers un serveur hébergé sur un réseau avec lequel je peer, mon serveur est plafonné à 1 Gbps et n'a pas d'autre trafic que celui de test. C'est une VM Debian classique sous VMWare ESXi 5.1 sur un serveur physique peu chargé.

J'ai choisi donc ces liens pour mes tests :
IPv4 : http://ipv4.intuxication.testdebit.info/fichiers/1000Mo.dat
IPv6 : http://ipv6.intuxication.testdebit.info/fichiers/1000Mo.dat

Traceroute IPv4 :

Host                                Loss%  Last   Avg  Best  Wrst
 1. 80.70.xxx.xx                     11.1%  20.6   4.6   1.2  20.6
 2. Te-0-0-2-0-asr2-il1par.ip.rtblw.  0.0%   1.4   1.4   1.3   1.7
 3. rentabiliweb.45x-1.pni.dc2.poney  0.0%   1.4   3.3   1.3   8.0
 4. a9k1-pni-dc2.dc3.poneytelecom.eu  0.0%  28.1   4.3   1.4  28.1
 5. 45x-s44-2-a9k1.dc3.poneytelecom.  0.0%   4.0   4.3   1.4  16.5
 6. jaguar.intuxication.net           0.0%   0.8   0.8   0.8   0.8

Traceroute IPv6 :

Host                              Loss%  Last   Avg  Best  Wrst
 1. 2a02:d48:x:xx::1                0.0%   1.4   1.4   1.3   1.6
 2. 2a02:d48:bb:1c::d               0.0%   1.5   1.5   1.3   1.9
 3. 2001:bc8:400:2::9               0.0%   1.3   2.9   1.2  18.2
 4. 2001:bc8:0:1::11                0.0%  20.0   2.7   1.4  20.0
 5. 2001:bc8:0:1::b6                0.0%   5.2   2.1   1.3   5.2
 6. jaguar.ipv6.intuxication.net    0.0%   0.8   0.8   0.8   1.0


1) Cisco ASR9K en direct :

IPv4 1000Mo.dat : 110M/s   in 8.7s
IPv6 1000Mo.dat : 110M/s   in 8.7s

Aucune différence de débit, au taquet et des valeurs toujours identiques entre IPv4 et IPv6

2) Cisco 7600 / sup720-3BXL :

IPv4 1000Mo.dat : 110M/s   in 8.7s
IPv6 1000Mo.dat : 110M/s   in 8.7s

La vieille sup720-3BXL sur 7600 supporte assez bien IPv6 quand le routeur est peu chargé. Je n'ai pas pu faire le test sur un 7600 avec beaucoup de trafic, pas trop envie de rebasculer de la prod dessus.

3) Cisco  3560G / IOS 12.2 IPSERVICESK9-M

Le setup BGP pour cet équipement est particulier. J'ai des problèmes de timeout BGP toutes les 3 minutes en sessions BGP IPv6 (le 3560G ne voit pas le paquet de keep-alive envoyé par le core router), donc les préfixes IPv6 sont appris via la sessions BGP IPv4.

IPv4 1000Mo.dat : 110M/s   in 8.7s
IPv6 1000Mo.dat : en 1M/s et 25M/s dans de nombreux cas, j'ai eu du 110M/s sur des tests que je ne m'explique pas pour le moment. Quand j'ai 2 VM sur le même ESXi et sur le même subnet et que l'une tape le 110M/s et l'autre péniblement les 1.2M/s, je me dis qu'il un comportement bizarre...


J'imagine que les différences de perfs se sentent surtout sur des équipements type CPE chez des clients ou d'abonnés FAI du coup. Je n'ai pas encore eu l'occasion de faire ces tests là de mon côté. Egalement on se doute que les non IPv6 native morflent.

Ce qui serait intéressant serait que des abonnés SFR FTTH 1 Gb/s testent sur testdebit.info en IPv4 et en IPv6

Ça marche pas extrêmement bien l'IPv6, ce qui n'empêche pas un abonné de tester ceci dit.

et des abonnés 1 Gb/s Bouygues Télécom dans un certain temps.

C'est activé !? Il ne me semble pas.

L'encapsulation demande tant de ressources pour écrouler le debit autant?

En fait les processeurs des box ne savent pas router de façon logicielle a plus de 100 / 150 Mb/s.

Un routeur 1 Gb/s serait hors de prix par contre il est possible de faire des circuits spécialisé dans le NAT qui vont être utilisés pour monter facilement à 1 Gb/s full-duplex.

Dés qu'on n'active pas ces accélérateurs ou que l'opération n'est pas pris en charge par ces accélérateurs, les débits s'effondrent.

Voici la réponse du chef de projet de CPE FTTH Sagem le 31 juillet 2006 :

Explication des performances non satisfaisantes vues sur un téléchargement HTTP.

Fonctionnement des Accélérateurs:
Lorsque l'utilisateur lance un téléchargement TCP/UDP, les premiers paquets qui sont responsables de l'établissement de la connexion passent par le CPU(chemin classique :NAT/FIREWALL/policies...), une fois le lien est établie tous les prochains paquets passeront par les accélérateurs (chemin rapide). Les accélérateurs n'analyse que l'entête TCP/IP du paquet et pas son contenue.

Cas d'un transfert de texte par MSN MESSENGER:
Lorsque un client utilise MSN MESSENGER pour chatter se dernier se connecte sur le port 1863/TCP à un serveur de chez Microsoft. dans ce cas le Nat est traversé proprement et le message retour est bien identifié par le Firewall du F@st3374.

Cas d'un transfert de vidéo par MSN MESSENGER :
Les problèmes arrivent lorsque le client demande une connexion vocale/video. Dans ce cas, MSN MESSENGER va demander au serveur de choisir un autre port pour faire passer le flux vidéo. Et le problème c'est que ce port est choisie au hasard entre le port TCP/9000 et TCP/65535. Pour que le flux
vidéo provenant du serveur soit identifier par le firewall du F@st3374 et qu'il soit forwardé correctement, tous les paquets msn( TCP et destPort/srcPort = 1863) passeront par une fonction de traitement supplèmentaire qui permet d'analyser les contenues des paquets en plus de leurs entêtes TCP/IP.
Dans ce cas le flux vidéo passera par les accélérateurs(chemin rapide) mais tous les paquets msn(TCP-port =1863) passeront par le CPU(chemin classique).

Cas du port 80:
Si pour une raison ou pour une autre le MSN MESSENGER n'arrive pas à se connecter au serveur Microsoft sur le port 1863 alors il retombe sur le port 80 en faisant du HTTP tunneling. Affin de supporter ce cas bien particulier le F@st3374 fait passer touts les paquets HTTP(port 80) par le même chemin par lequel passe les paquets msn (port 1863).

Solution immédiate :
Ne supporter que le chat en mode texte dans le cas où le client MSN MESSENGER fait du backup sur le port 80. Et si dans ce cas particulier l'utilisateur veut faire du Chat en mode vidéo il doit installer UPNP sur son poste qui va s'en charger  de communiquer avec le Firewall du F@st3374 pour ouvrir les bons ports.

Je reste à votre disposition pour tout éclaircissement supplèmentaire.

Cordialement.

A noter que le même phénomène est utilisé sur le port 21 pour le FTP.

Note : Les box équipées de Watchdog reboot lors d'un transfert HTTP à 20 Mb/s ou plus, le CPU étant utilisé à 100%, le watchdog est là pour rétablir la situation via un reboot

La Neufbox v4 n'a pas d’accélérateurs en IPv6 et son débit sera toujours limité mais la NeufBox v6 dispose d’accélérateurs IPv6, quand IPv6 natif sera proposé. Aucune box n'a d’accélérateur pour encapsuler IPv6 dans de l'IPv4 ou inversement.

Je présume une 12.2 (55) SEx ?

Avec la VM bizarre, rien d'anormal dans l'activité CPU ? (sh proc cpu history) A voir aussi les compteurs de drop (quelque part dans "show controllers interface" ou "show platform")

12.2(58)SE2

Pas encore creusé l'histoire, mais je vais le faire je vous direz ce qui en ressort. Je testerai également avec une 15.0(2)SE6.