d'apres la pub et differents tests, le routeur peut atteindre 800Mbps en NAT ipv4 mais avec le firmware d'origine qui contient de l’accélération matérielle.
avec OpenWRT on retombe a entre 300 et 400 environ (ca depend du sens de mesure) car a ce jour OpenWRT ne fait aucune accélération matérielle en NAT.

Le ticket #11779 sur le tracker d'OpenWRT donne plus de détail sur les perfs.

donc si le firmware d'origine ne supporte pas les VLAN faudrat se contenter de 400Mbps (ca me parait tres raisonnable quand meme...).

par contre y'a un bug connu pour les VLAN avec OpenWRT et le 4300: le #12550. A priori les vlan au dela de l'ID 128 ne fonctionnent pas correctement. donc attention le vlan 836 pour Free risque de pas marcher avec l'OpenWRT de base. peut-etre un autre firmware alternatif marcherait mieux genre dd-wrt , gargoyle ou tomato ? J'ai pas été voir ces 3 la donc je sais meme pas s'ils sont compatibles avec le 4300.

faut peut-être donc t'orienter vers un autre routeur offrant plus de choix de firmware par exemple.

Tu peux détailler l'opération qui est accélérée?

Le NAT fait appel à des milliers de lignes de code C. C'est vraiment complexe!

Sans rentrer dans les détails, on peut simplement supposer que des puces sont dédiées à ça, ce qui libère des ressources pour le processeur qui doit s'occuper d'autres tâches (exactement de la même manière que l'accélération GPU pour les PC).

Le partage d'adresse IP, c'est à dire une même IP sur plusieurs PC, c'est faisable si tu es prêt à te salir les mains vraiment!

Même si c'est HS, le HS ne me dérange pas, et si tu as un lien qui me permet de comprendre le procédé, je suis intéressé, par curiosité. Pour l'instant, je ne vois pas comment on peut procéder (à part ne pas allumer les ordis en même temps)

Il n'y a pas "différents traitements logiciels" au pluriel, il y a un unique tunnel 6in4 qui d'un coté encapsule un paquet IPv6 dans de l'IPv4, et de l'autre coté ressort le paquet IPv6. C'est vraiment très simple, même simpliste.

Quand tu fais de l'IPv6, tu ne fais pas de NAT justement. Donc ça décharge le processeur.

Aussi simpliste soit-il, il faut une table de routage, et ça prend des ressources, et donc inévitablement, ça ralentit la connexion (sauf si le processeur arrive à suivre)

Sans rentrer dans les détails, on peut simplement supposer que des puces sont dédiées à ça, ce qui libère des ressources pour le processeur qui doit s'occuper d'autres tâches (exactement de la même manière que l'accélération GPU pour les PC).

Pour le graphisme, je vois bien les opérations spécialisées assez simples utiles :
- pour recopier des bitmaps
- pour dessiner pleins de pixels
- faire des opérations vectorisées : transparences, convolutions...

Pour le NAPT, je ne vois pas quelles opérations spécialisées sont utiles. Donc intuitivement le pense que la puce dédiée peut être un CPU générique.

Même si c'est HS, le HS ne me dérange pas, et si tu as un lien qui me permet de comprendre le procédé, je suis intéressé, par curiosité. Pour l'instant, je ne vois pas comment on peut procéder (à part ne pas allumer les ordis en même temps)

Comme pour les serveurs virtuels avec partage d'IP de linux :
- même adresse IP
- même adresse Ethernet
- diffusion sur le lien : utiliser un hub ou utiliser une adresse Ethernet multicast
- plages de ports différentes entres les machines

Aussi simpliste soit-il, il faut une table de routage, et ça prend des ressources, et donc inévitablement, ça ralentit la connexion (sauf si le processeur arrive à suivre)

Il y a juste une route par défaut.

Je ne vois pas en quoi ça ralentirait quoi que ce soit.

Pour répondre aux questions sur les accélérateurs :

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

Certains routeurs ont pour la même raison un débit très faible en IPv6, car on passe systématiquement par le CPU faute de circuits pour passer par les accélérateurs.

Un transfert avec IPv4 + Nat sera alors plus rapide.

Exemple concret : La neufbox v4 qui a un débit catastrophique en IPv6, le chipset Broadcom utilisé ne gérant pas IPv6 au niveau hard.

Est-ce qu'il y a une astuce qui permet au 6in4 d'échapper au NAT?

Sûrement. Il suffit d'exploiter les informations de l'IPV6 pour distinguer les machines et ainsi faire des tables de routage. Mais est-ce que ça a été intégré dans le code du 6in4 ? On peut penser que cet algorithme est trop récent, mais comme je n'y connais rien, peut-être que je me trompe et je sous-estime le code...

L'IPV6 encapsulée dans de l'IPV4 nécessite un traitement, donc ça, d'une part ça ralentit.

Oui, mais un traitement simple.

Ensuite, tu communiques avec une adresse IPV4, donc tu as bien besoin d'une table de routage, la NAT, 2ème ralentissement.

Oui, j'ai réalisé après coup que tout paquet IPv4 sortant avec va passer par le code NAT, par une connexion NAT de type générique dans ce cas c'est géré comme un protocole inconnu voir net/netfilter/nf_nat_proto_unknown.c

On doit logiquement avoir un triplet (6in4, IPv4 locale, IPv4 distante)
associé à tout paquet IPv6 (mais la plupart du temps on aura un seul triplet)

Mais ça reste assez lourd.

Il faut que j'analyse ça mieux, si j'y arrive.

Après, on pourrait supposer que l'IPV6to4

Attention, c'est du 6to4rd, pas du 6to4!

permet d'éviter de faire de la NAT, mais je suppose que cette technologie est trop récente pour prévoir des translations d'adresses. Je pense que dans la Freebox (par exemple), on a un premier traitement d'IPV6 encapsulé dans de l'IPV4, et ensuite la NAT pour permettre aux paquets IPV4 d'aller sur la bonne machine.

Tu veux dire que la NAT est utile ici?

Les paquets 6in4 sortants n'ont pas besoin de NAT. Je pense qu'ils passent pas la couche NAT, parce que linux est conçu pour que tout passe par la couche NAT, mais c'est contournable (je ne sais plus comment).