Routeur => Discussion démarrée par: Pilou42 le 19 avril 2013 à 22:08:58 Routeur => Discussion démarrée par: Pilou42 le 19 avril 2013 à 22:08:58(https://lafibre.info/testdebit/wifi/201304_TP-Link_TL-WDR4300_openwrt.png)
Y'a un truc qui me fait quand même un peu peur, ce sont les performances en NAT:
http://wiki.openwrt.org/toh/tp-link/tl-wdr4300#performance.test.with.trunkr35995 (http://wiki.openwrt.org/toh/tp-link/tl-wdr4300#performance.test.with.trunkr35995)
Ça tombe à 300Mbits en NAT. Enfin bon, peut-être que ça me permettra d'apprendre des trucs.
Le firmware a l'air facile à installer. Luci, un peu moins, et après, configurer les Vlan correctement, je sens que je vais galérer... Vous parlez du Vlan 835, mais ça, c'est pour la Freebox, moi j'ai surtout besoin du Vlan 836 qui sera redistribué sur la plupart des port ethernet et pour le Wifi via de la NAT.
J'avais Luci 0.11 dedans deja installé (je suis pas sur que la doc du site soit a jour a ce sujet). donc configurable par web des le reboot.Cool, c'est pour ça que je trouvais pas grand chose sur l'installation de cette interface.
si t'actives IPv6 t'auras du traffic qui fera pas de NAT (notamment youtube et pas de mal de p2p).L'activation de l'IPV6 correspond en fait à l'activation d'un logiciel/service dans la Freebox qui fait de l'IPV6to4, mais il ya toujours besoin de la NAT pour l'IPV4.
la Freebox dépasse vraiment 300 Mbps en NAT ?Ah bin non, j'ai même la Freebox V5 qui est super limitée, c'est pour ça que je ne la branche pas. Je me branche directement au convertisseur optique (voir lien du 1er post).
Je ne pense pas non. Free travaille avec de l'IPV4, et utilise différents traitements logiciels (notamment dans la Freebox, mais surement dans leurs équipements) afin de disposer d'IPV6. Je suppose qu'utiliser de l'IPV6 ralentit encore un peu le processeur déjà chargé de faire de la NAT.
(je l'utilise pas en NAT chez moi)Mais comment tu fais alors lorsque tu as plusieurs ordinateurs connectés sur ton routeur ? Je ne pense pas qu'il y ait bien le choix. Il faut bien qu'il y ait un service qui redistribue correctement aux bons ordinateurs, non ?
Mais comment tu fais alors lorsque tu as plusieurs ordinateurs connectés sur ton routeur ? Je ne pense pas qu'il y ait bien le choix. Il faut bien qu'il y ait un service qui redistribue correctement aux bons ordinateurs, non ?
Attention, de nombreux routeurs ont de bonnes performances avec IPv4, car on passe par les accélérateursTu peux détailler l'opération qui est accélérée?
Mais comment tu fais alors lorsque tu as plusieurs ordinateurs connectés sur ton routeur ?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!
Je ne pense pas non. Free travaille avec de l'IPV4, et utilise différents traitements logiciels (notamment dans la Freebox, mais surement dans leurs équipements) afin de disposer d'IPV6. Je suppose qu'utiliser de l'IPV6 ralentit encore un peu le processeur déjà chargé de faire de la NAT.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.
comme on fait pas de NAT avec v6 justement tu pourras peut etre depasser 300 pour le traffic pas v4. faut voir si le coté Free est pur V6 ou pas. s'il faut encore faire du 6rd dans le routeur ca donnera pas grand chose niveau perf (mais y'aura plus de NAT pour ce traffic).NAT ou pas, ça reste de l'IPV4 qui circule, donc il faudra bien une table de routage pour renvoyer au bon ordinateur, au lieu que ce soit des tables NAT, peut-être les infos IPV6 encapsulées permettent de rediriger sur le bon ordinateur, mais je ne suis pas sûr que ce soit encore bien optimisé (trop récent ?).
Je sais pas comment ils ont mesuré leur 300 mais ca me parait bien pour du NAT.C'est peut-être bien pour du NAT, mais je télécharge certains fichiers à plus de 60 Mo/s, alors, moralement, ça m’embêtera toujours de savoir que je suis bridé par un appareil intermédiaire À MOI.
Tu peux détailler l'opération qui est accélérée?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 NAT fait appel à des milliers de lignes de code C. C'est vraiment complexe!
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.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)
Quand tu fais de l'IPv6, tu ne fais pas de NAT justement. Donc ça décharge le processeur.
There's no hardware NAT in any OpenWRT platform (so far)du 1er ticket ne m'incite pas à utiliser ce firmware.
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 :
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 :
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.
si t'actives IPv6 t'auras du traffic qui fera pas de NATÀ la réflexion :
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
Il y a juste une route par défaut.L'IPV6 encapsulée dans de l'IPV4 nécessite un traitement, donc ça, d'une part ça ralentit. Ensuite, tu communiques avec une adresse IPV4, donc tu as bien besoin d'une table de routage, la NAT, 2ème ralentissement.
Je ne vois pas en quoi ça ralentirait quoi que ce soit.
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...
Tu peux détailler l'opération qui est accélérée?J'ai trouvé le document :
Le NAT fait appel à des milliers de lignes de code C. C'est vraiment complexe!
Stateful control path requires 90% of the code and is used 10% of the time.Donc ils arrivent à séparer la partie "simple" et la partie compliquée du NAPT, sachant que la partie simple comprend quand même :
►Stateless data path requires just 10% of the code and is used 90% of the
time.
►This session focuses on how to accelerate the 10% of the code in the
stateless path to increase packet processing performance.
Application Data Path Control Path NAPT 5-tuple lookup, IP/Port/L2 modify Connection setup/destroy, policy, ALG
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
Après, on pourrait supposer que l'IPV6to4Attention, 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? ???
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...Il n'y a pas de table de routage, sauf les tables triviales IPv6 et IPv4 avec une route par défaut!
| ipv6 350 Mbps ipv4 NAT 250 Mbps ipv4 hardware NAT 550 Mbps (on est loin des 800 Mbps annoncés. surement obtenables en jouant sur la taille des trames toutefois) avec OpenWRT (Attitude Adjustment 12.09 RC1): ipv6 480 Mbps ipv4 NAT 300 Mbps pas de hardware NAT mais on a les VLANs et plein d'autres choses y'a donc pas photo a moins d'avoir une connexion a plus de 300 Mbps. |
Il faudrait pas compter en paquet/s?Les deux je dirais.
À la réflexion :Puisque le 6rd est un tunnel IPv6 dans IPv4 (SIT (http://lxr.linux.no/linux+v3.9/net/ipv6/sit.c)), au final on va dans __ip_local_out (http://lxr.linux.no/linux+v3.9/net/ipv4/ip_output.c#L94) qui va dans la règle NF_INET_LOCAL_OUT.
- si tu actives 6rd les paquets IPv6 ressortent en IPv4 avec l'adresse source IPv4 publique
- si tu actives le NAT, habituellement tous les paquets qui ressortent avec l'adresse source IPv4 publique passent par le NAT
Donc à cause du fonctionnement du 6rd, il y a un passage obligé pour chaque paquet IPv6 par la couche NAT, non?
Tu m'expliques comment tu fais pour que les paquets 6rd sortants (ou bien un paquet IPv4 quelconque passant par NF_INET_LOCAL_OUT) ne passent pas par le système SNAT?
le SNAT se declenche en fonction de l'addresse source.Oui
les paquets 6rd ont, par construction, pour addresse source directement l'addresse publique du routeur
donc ne sont pas affectés par le SNAT.Si, justement. IP publique = IP utilisée par le SNAT
En théorie, ca me parait évident une fois qu'on comprend bien les 2 notions.Justement, quand on comprend bien les deux, on voit que toutes les connexions sortantes avec une même IP sont SNATées.
toutes les connexions sortantes avec une même IP sont SNATées.
non par forcement justement.Non, forcèment.
T'as un peu de mal a séparer la compréhension des notions de la compréhension de leur implèmentations particulières (Netfilter sous Linux j'imagine au vue de tes précédents commentaires).Tu imagines mal.
non par forcement justement.Non.
T'as un peu de mal a séparer la compréhension des notions de la compréhension de leur implèmentations particulières (Netfilter sous Linux j'imagine au vue de tes précédents commentaires).
On sent vraiment l'influence de Linux dans votre compréhension des concepts et même des termes (SNAT c'est tres linuxien de meme que MASQUERADE. SNAT pour Cisco ca veut dire Stateful NAT et Secure NAT pour Microsoft...etc et autres choses pour d'autres)SNAT (source NAT) s'oppose à DNAT (destination NAT), tout simplement. Ce n'est pas spécialement netfilterien, c'est une distinction fondamentale. (J'ai modifié la forme de mon message précédant pour que ça soit clair, ce qui n'en modifie pas le sens.)
Essayez d'oublier Linux un moment et revenez aux concepts (et termes) de base ça ira mieux.Ce sont des concepts de base comme je disais.
SNAT (dans le sens source NAT), PAT ou NAT (ou qu'importe) n'impose en rien que le routeur fasse aussi ce traitement pour son propre trafic.Et si, comme le disais c'est inhérent au Source-NAT : c'est un partage d'adresse source et la S-NAT-box partage cette adresse avec les autres.
et ca c'est quand même pas si compliqué que ca a comprendre ...C'est marrant que tu n'arrives pas à comprendre que c'est le partage est symétrique, et les processus locaux qui génèrent des paquets S-NAT-box jouent exactement le même rôle que les PC derrières (sur les IP privées) qui envoient des paquets.
et ca c'est quand même pas si compliqué que ca a comprendre ...Exactement : ce que je dis n'est pas si compliqué.
Là on était dans un contexte netfilter donc y'avait pas d'ambigüté sur les termes (sauf pour corrector).Quelle ambiguïté?
Là on était dans un contexte netfilter donc y'avait pas d'ambigüté sur les termes (sauf pour corrector).
SNAT (dans le sens source NAT), PAT ou NAT (ou qu'importe)Attention : déjà Source-NAT implique PAT!
oui et moi depuis le début je ne suis pas du tout dans un contexte netfilter et il veut m'y ramener a chaque fois ;)Si tu crois que SNAT ça veut juste dire "avoir une certaine IP source en sortie", c'est que tu es bien loin de saisir la complexité effarante de SNAT.
et meme, j'ai pas été voir le code de netfilter mais j'ose espérer qu'ils ont été malins et qu'ils ne SNAT pas les paquets qui ont déjà la bonne IP source.
RTFMEn l'absence de précision sur l'origine de cette invention, j'en déduis que c'était bien une pure invention.
(t'es pas un peu lourd des fois ?)
Attention : déjà Source-NAT implique PAT!depuis le début c'est clair pour moi qu'il y a du PAT.
C'est ça que tu n'as pas l'air de voir.
Si tu crois que SNAT ça veut juste dire "avoir une certaine IP source en sortie", c'est que tu es bien loin de saisir la complexité effarante de SNAT.
depuis le début c'est clair pour moi qu'il y a du PAT.OK
Je vois vraiment pas ou mon raisonnement coince et ou le tiens serait valide. la complexité de SNAT n'a rien avoir la dedans.Déjà tu es d'accord que SNAT implique conntrack? (oui, j'utilise un vocabulaire netfilter, parce que je n'en connais pas d'autre qui soit aussi précis)
tu consideres peut-etre que le traffic partant du routeur a pour source l'adresse ip LAN du routeur (donc privée) et doit etre aussi SNAT-ée ?Non. Question sans intérêt. Tu te perds dans les détails. (Les IP privées sont du détail. La réécriture d'adresse est du détail.)
ou que pour éviter des conflits de ports tout doit etre rePATer dans le module SNAT ?!Oui, notamment.
(ce qui n'est pas le cas si le code SNAT est bien concu).Conçu comment?
moi mon exemple c'est VMWare Player par exemple qui arrive à faire causé ma MV (configurée NAT) avec la même IP que mon poste sans pourtant que tout mon traffic réseau passe par VMWare Player ...Intéressant, c'est VMWare qui implèmente le NAT et pas Windows?