j'ai actuellement un réseau local constitué de :
- un switch routeur firewall Netgear FR114P
- une freebox V2
- 1 PC équipé d'une interface ethernet 10/100/1000
- d'autres PC équipés de cartes ethernet 10/100 (Realtek)
Je souhaite augmenter les performances pour les transferts de gros
fichiers entre mes 2 PC principaux, j'envisage donc de remplacer
une carte réseau 10/100 par une 10/100/1000 et d'acheter un switch
10/100/1000.
Les 2 PC principaux seraient connectés au nouveau switch,
celui-ci serait connecté au switch-routeur Netgear et les vieux PC
pourraient être connectés indifféremment au nouveau switch
ou à l'ancien switch-routeur Netgear.
J'ai regardé les prix des cartes réseaux 10/100/1000,
ça va de moins de 15 EUR à plus de 60 EUR.
La D-Link DGE-530T a l'air appréciée des utilisateurs et coûte
environ 20 EUR.
Sinon dans les premiers prix, il y a des Trendnet TEG-PCITX et
TEG-PCITXR, et aussi une Peabird PEAB-GIGA-32T à base de chip
Realtek.
Jusqu'à présent j'ai toujours été satisfait des cartes à base
de chips Realtek (en 10/100) et la seule carte plus chère que
j'ai, une Netgear, est en fait moins bien : elle ne partage pas les
IRQ.
J'utilise habituellement Windows 2000 et ponctuellement Linux
Knoppix, la compatibilité avec des distributions variées et
les kernels 2.2, 2.4, 2.6 serait un point positif intéressant.
Pour le switch, j'envisage le D-Link DGS-1005D ou le Netgear
GS105. Le boîtier du Netgear donne l'impression de solidité,
alors que celui du Dlink fait plutôt toc.
Pour éviter cet inconvénient, on utilise les jumbo frames, des trames de 9 k au lieu de 1500 octets habituels.
Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui ne supportent pas les jumbo frames ?
[Ou même des éléments en gigabit ethernet qui ne supportent pas les jumbo frames, si ça existe.]
Après quelques rapides tests : ça se passe mieux que ce qu'on pourrait craindre.
Rapide, rapide, tu as quand même mis 8 mois à répondre. ;-)
On active les jumbo frames sur une interface en faisant, par exemple, ifconfig eth0 mtu 9000. Chaque fois qu'on cause à une autre machine qui ne parle pas jumbo (ethernet 100 mbits/s MTU 1500), il y a un délai d'une ou deux secondes mais on finit par y arriver.
Quel type de communication ?
Ca doit fonctionner si l'icmp n'est pas filtré. Dans ce cas, la machine destinataire peut faire remonter qu'elle ne peut pas recevoir les données, et demander la fragmentation, par exemple.
J'ai un gros doute. Le message ICMP de demande de fragmentation ne peut être émis que par un routeur intermédiaire, pas par la destination finale. Le destinataire d'un paquet IP n'a aucune raison d'envoyer un tel message ICMP car cela impliquerait qu'il a reçu le paquet, et dans ce cas pas besoin d'envoyer un ICMP.
Si le destinataire est en fast ethernet, le switch le sait et ne peut pas lui transmettre les jumbo frames. Mais un switch, équipement de couche 2 (liaison), ne peut pas émettre de messages d'erreur ICMP qui sont de la couche 3 (réseau).
En TCP, cela devrait néanmoins bien se passer grâce à l'option MSS (maximum segment size, typiquement MTU - la taille de l'en-tête IP+TCP) transmise à l'établissement d'une connexion TCP : la machine en fast ethernet transmet un MSS de 1500 - 40 = 1460, donc la machine en gigabit ethernet lui envoie des segments de cette taille au plus, résultant en des paquets IP de taille maximum 1500 octets en supposant que les segments de données ne contiennent pas d'option.
Je suppose que la couche réseau Linux n'est pas capable de se souvenir de la taille des paquets à utiliser par destination
Si, le cache de routage (ip route show cache) contient le "path MTU" des destinations récentes, résultant éventuellement du mécanisme de découverte "path MTU discovery" (PMTUd) ou des messages ICMP de demande de fragmentation reçus.
mais qu'elle est capable de la réduire jusqu'à ce que ça passe.
Oui si le PMTUd est activé. Mais il me semble que ce n'est pas la couche IP (réseau) de la pile qui s'occupe des retransmissions, se limitant à activer le flag DF et à faire remonter la taille maxi à la couche supérieure en cas d'erreur. En TCP, c'est la couche TCP (transport) qui s'en occupe toute seule ; en UDP par contre, j'ai peur que ce soit à la charge de l'application émettrice.
Pour éviter cet inconvénient, on utilise les jumbo frames, des
trames de 9 k au lieu de 1500 octets habituels.
Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui
ne supportent pas les jumbo frames ?
[Ou même des éléments en gigabit ethernet qui ne supportent pas les
jumbo frames, si ça existe.]
Après quelques rapides tests : ça se passe mieux que ce qu'on
pourrait craindre.
Rapide, rapide, tu as quand même mis 8 mois à répondre. ;-)
On active les jumbo frames sur une interface en faisant, par
exemple, ifconfig eth0 mtu 9000. Chaque fois qu'on cause à une
autre machine qui ne parle pas jumbo (ethernet 100 mbits/s MTU
1500), il y a un délai d'une ou deux secondes mais on finit par
y arriver.
Quel type de communication ?
Ca doit fonctionner si l'icmp n'est pas filtré.
Dans ce cas, la machine destinataire peut faire remonter qu'elle ne peut
pas recevoir les données, et demander la fragmentation, par exemple.
J'ai un gros doute. Le message ICMP de demande de fragmentation ne peut
être émis que par un routeur intermédiaire, pas par la destination
finale. Le destinataire d'un paquet IP n'a aucune raison d'envoyer un
tel message ICMP car cela impliquerait qu'il a reçu le paquet, et dans
ce cas pas besoin d'envoyer un ICMP.
Si le destinataire est en fast ethernet, le switch le sait et ne peut
pas lui transmettre les jumbo frames. Mais un switch, équipement de
couche 2 (liaison), ne peut pas émettre de messages d'erreur ICMP qui
sont de la couche 3 (réseau).
En TCP, cela devrait néanmoins bien se passer grâce à l'option MSS
(maximum segment size, typiquement MTU - la taille de l'en-tête IP+TCP)
transmise à l'établissement d'une connexion TCP : la machine en fast
ethernet transmet un MSS de 1500 - 40 = 1460, donc la machine en gigabit
ethernet lui envoie des segments de cette taille au plus, résultant en
des paquets IP de taille maximum 1500 octets en supposant que les
segments de données ne contiennent pas d'option.
Je suppose que la couche réseau Linux n'est pas capable de se
souvenir de la taille des paquets à utiliser par destination
Si, le cache de routage (ip route show cache) contient le "path MTU" des
destinations récentes, résultant éventuellement du mécanisme de
découverte "path MTU discovery" (PMTUd) ou des messages ICMP de demande
de fragmentation reçus.
mais qu'elle est capable de la réduire jusqu'à ce que ça passe.
Oui si le PMTUd est activé. Mais il me semble que ce n'est pas la couche
IP (réseau) de la pile qui s'occupe des retransmissions, se limitant à
activer le flag DF et à faire remonter la taille maxi à la couche
supérieure en cas d'erreur. En TCP, c'est la couche TCP (transport) qui
s'en occupe toute seule ; en UDP par contre, j'ai peur que ce soit à la
charge de l'application émettrice.
Pour éviter cet inconvénient, on utilise les jumbo frames, des trames de 9 k au lieu de 1500 octets habituels.
Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui ne supportent pas les jumbo frames ?
[Ou même des éléments en gigabit ethernet qui ne supportent pas les jumbo frames, si ça existe.]
Après quelques rapides tests : ça se passe mieux que ce qu'on pourrait craindre.
Rapide, rapide, tu as quand même mis 8 mois à répondre. ;-)
On active les jumbo frames sur une interface en faisant, par exemple, ifconfig eth0 mtu 9000. Chaque fois qu'on cause à une autre machine qui ne parle pas jumbo (ethernet 100 mbits/s MTU 1500), il y a un délai d'une ou deux secondes mais on finit par y arriver.
Quel type de communication ?
Ca doit fonctionner si l'icmp n'est pas filtré. Dans ce cas, la machine destinataire peut faire remonter qu'elle ne peut pas recevoir les données, et demander la fragmentation, par exemple.
J'ai un gros doute. Le message ICMP de demande de fragmentation ne peut être émis que par un routeur intermédiaire, pas par la destination finale. Le destinataire d'un paquet IP n'a aucune raison d'envoyer un tel message ICMP car cela impliquerait qu'il a reçu le paquet, et dans ce cas pas besoin d'envoyer un ICMP.
Si le destinataire est en fast ethernet, le switch le sait et ne peut pas lui transmettre les jumbo frames. Mais un switch, équipement de couche 2 (liaison), ne peut pas émettre de messages d'erreur ICMP qui sont de la couche 3 (réseau).
En TCP, cela devrait néanmoins bien se passer grâce à l'option MSS (maximum segment size, typiquement MTU - la taille de l'en-tête IP+TCP) transmise à l'établissement d'une connexion TCP : la machine en fast ethernet transmet un MSS de 1500 - 40 = 1460, donc la machine en gigabit ethernet lui envoie des segments de cette taille au plus, résultant en des paquets IP de taille maximum 1500 octets en supposant que les segments de données ne contiennent pas d'option.
Je suppose que la couche réseau Linux n'est pas capable de se souvenir de la taille des paquets à utiliser par destination
Si, le cache de routage (ip route show cache) contient le "path MTU" des destinations récentes, résultant éventuellement du mécanisme de découverte "path MTU discovery" (PMTUd) ou des messages ICMP de demande de fragmentation reçus.
mais qu'elle est capable de la réduire jusqu'à ce que ça passe.
Oui si le PMTUd est activé. Mais il me semble que ce n'est pas la couche IP (réseau) de la pile qui s'occupe des retransmissions, se limitant à activer le flag DF et à faire remonter la taille maxi à la couche supérieure en cas d'erreur. En TCP, c'est la couche TCP (transport) qui s'en occupe toute seule ; en UDP par contre, j'ai peur que ce soit à la charge de l'application émettrice.
Andre Majorel
On 2007-05-27, Pascal Hambourg wrote:
Pour éviter cet inconvénient, on utilise les jumbo frames, des trames de 9 k au lieu de 1500 octets habituels.
Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui ne supportent pas les jumbo frames ?
[Ou même des éléments en gigabit ethernet qui ne supportent pas les jumbo frames, si ça existe.]
Hélas, ça existe. C'est même la norme pour les switches à pas cher.
Après quelques rapides tests : ça se passe mieux que ce qu'on pourrait craindre.
Rapide, rapide, tu as quand même mis 8 mois à répondre. ;-)
C'est le temps qu'il a fallu pour que les switches compatibles soient disponibles. Les tests eux-mêmes ont bien pris dix minutes, si c'est pas onze. :-)
On active les jumbo frames sur une interface en faisant, par exemple, ifconfig eth0 mtu 9000. Chaque fois qu'on cause à une autre machine qui ne parle pas jumbo (ethernet 100 mbits/s MTU 1500), il y a un délai d'une ou deux secondes mais on finit par y arriver.
Quel type de communication ?
NFS et SSH entre des Nunux.
Ca doit fonctionner si l'icmp n'est pas filtré. Dans ce cas, la machine destinataire peut faire remonter qu'elle ne peut pas recevoir les données, et demander la fragmentation, par exemple.
J'ai un gros doute. Le message ICMP de demande de fragmentation ne peut être émis que par un routeur intermédiaire, pas par la destination finale. Le destinataire d'un paquet IP n'a aucune raison d'envoyer un tel message ICMP car cela impliquerait qu'il a reçu le paquet, et dans ce cas pas besoin d'envoyer un ICMP.
Si le destinataire est en fast ethernet, le switch le sait et ne peut pas lui transmettre les jumbo frames. Mais un switch, équipement de couche 2 (liaison), ne peut pas émettre de messages d'erreur ICMP qui sont de la couche 3 (réseau).
NB : la cohabitation du gigabit et du 100 Mb/s sur le même switch se passe très bien. Le même client, équipé d'une carte gigabit sait parler en gigabit avec un des serveurs et en 100 Mb/s avec l'autre. Je ne sais pas si c'est le client qui reprogramme sa carte en fonction de l'IP cible ou le switch qui reçoit en gigabit et recrache en 100 Mb/s mais ça marche. Les problèmes portent uniquement sur les jumbo frames.
Je sais que tu n'as pas dit le contraire, c'est juste un complément d'information, hein.
Je suppose que la couche réseau Linux n'est pas capable de se souvenir de la taille des paquets à utiliser par destination
Si, le cache de routage (ip route show cache) contient le "path MTU" des destinations récentes, résultant éventuellement du mécanisme de découverte "path MTU discovery" (PMTUd) ou des messages ICMP de demande de fragmentation reçus.
Intéressant.
mais qu'elle est capable de la réduire jusqu'à ce que ça passe.
Oui si le PMTUd est activé.
J'ai pas.
Mais il me semble que ce n'est pas la couche IP (réseau) de la pile qui s'occupe des retransmissions, se limitant à activer le flag DF et à faire remonter la taille maxi à la couche supérieure en cas d'erreur. En TCP, c'est la couche TCP (transport) qui s'en occupe toute seule ; en UDP par contre, j'ai peur que ce soit à la charge de l'application émettrice.
C'est aussi comme ça que je comprends, d'où mon étonnement que ça marche en UDP. (Je ne pense pas que mes clients NFS passent en TCP tous seuls.)
-- André Majorel <URL:http://www.teaser.fr/~amajorel/> (Counterfeit: ) "Duty, honor, country" -- Douglas MacArthur "Travail, famille, patrie" -- Philippe Pétain
On 2007-05-27, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Pour éviter cet inconvénient, on utilise les jumbo frames, des
trames de 9 k au lieu de 1500 octets habituels.
Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui
ne supportent pas les jumbo frames ?
[Ou même des éléments en gigabit ethernet qui ne supportent pas les
jumbo frames, si ça existe.]
Hélas, ça existe. C'est même la norme pour les switches à pas
cher.
Après quelques rapides tests : ça se passe mieux que ce qu'on
pourrait craindre.
Rapide, rapide, tu as quand même mis 8 mois à répondre. ;-)
C'est le temps qu'il a fallu pour que les switches compatibles
soient disponibles. Les tests eux-mêmes ont bien pris dix
minutes, si c'est pas onze. :-)
On active les jumbo frames sur une interface en faisant, par
exemple, ifconfig eth0 mtu 9000. Chaque fois qu'on cause à une
autre machine qui ne parle pas jumbo (ethernet 100 mbits/s MTU
1500), il y a un délai d'une ou deux secondes mais on finit par
y arriver.
Quel type de communication ?
NFS et SSH entre des Nunux.
Ca doit fonctionner si l'icmp n'est pas filtré.
Dans ce cas, la machine destinataire peut faire remonter qu'elle ne peut
pas recevoir les données, et demander la fragmentation, par exemple.
J'ai un gros doute. Le message ICMP de demande de fragmentation ne peut
être émis que par un routeur intermédiaire, pas par la destination
finale. Le destinataire d'un paquet IP n'a aucune raison d'envoyer un
tel message ICMP car cela impliquerait qu'il a reçu le paquet, et dans
ce cas pas besoin d'envoyer un ICMP.
Si le destinataire est en fast ethernet, le switch le sait et ne peut
pas lui transmettre les jumbo frames. Mais un switch, équipement de
couche 2 (liaison), ne peut pas émettre de messages d'erreur ICMP qui
sont de la couche 3 (réseau).
NB : la cohabitation du gigabit et du 100 Mb/s sur le même
switch se passe très bien. Le même client, équipé d'une carte
gigabit sait parler en gigabit avec un des serveurs et en 100
Mb/s avec l'autre. Je ne sais pas si c'est le client qui
reprogramme sa carte en fonction de l'IP cible ou le switch qui
reçoit en gigabit et recrache en 100 Mb/s mais ça marche. Les
problèmes portent uniquement sur les jumbo frames.
Je sais que tu n'as pas dit le contraire, c'est juste un
complément d'information, hein.
Je suppose que la couche réseau Linux n'est pas capable de se
souvenir de la taille des paquets à utiliser par destination
Si, le cache de routage (ip route show cache) contient le "path MTU" des
destinations récentes, résultant éventuellement du mécanisme de
découverte "path MTU discovery" (PMTUd) ou des messages ICMP de demande
de fragmentation reçus.
Intéressant.
mais qu'elle est capable de la réduire jusqu'à ce que ça passe.
Oui si le PMTUd est activé.
J'ai pas.
Mais il me semble que ce n'est pas la couche
IP (réseau) de la pile qui s'occupe des retransmissions, se limitant à
activer le flag DF et à faire remonter la taille maxi à la couche
supérieure en cas d'erreur. En TCP, c'est la couche TCP (transport) qui
s'en occupe toute seule ; en UDP par contre, j'ai peur que ce soit à la
charge de l'application émettrice.
C'est aussi comme ça que je comprends, d'où mon étonnement que
ça marche en UDP. (Je ne pense pas que mes clients NFS passent
en TCP tous seuls.)
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
(Counterfeit: gufuholaq@amethystine.com cigij@billmenow.com)
"Duty, honor, country" -- Douglas MacArthur
"Travail, famille, patrie" -- Philippe Pétain
Pour éviter cet inconvénient, on utilise les jumbo frames, des trames de 9 k au lieu de 1500 octets habituels.
Comment cela se passe-t-il s'il reste des éléments en fast ethernet qui ne supportent pas les jumbo frames ?
[Ou même des éléments en gigabit ethernet qui ne supportent pas les jumbo frames, si ça existe.]
Hélas, ça existe. C'est même la norme pour les switches à pas cher.
Après quelques rapides tests : ça se passe mieux que ce qu'on pourrait craindre.
Rapide, rapide, tu as quand même mis 8 mois à répondre. ;-)
C'est le temps qu'il a fallu pour que les switches compatibles soient disponibles. Les tests eux-mêmes ont bien pris dix minutes, si c'est pas onze. :-)
On active les jumbo frames sur une interface en faisant, par exemple, ifconfig eth0 mtu 9000. Chaque fois qu'on cause à une autre machine qui ne parle pas jumbo (ethernet 100 mbits/s MTU 1500), il y a un délai d'une ou deux secondes mais on finit par y arriver.
Quel type de communication ?
NFS et SSH entre des Nunux.
Ca doit fonctionner si l'icmp n'est pas filtré. Dans ce cas, la machine destinataire peut faire remonter qu'elle ne peut pas recevoir les données, et demander la fragmentation, par exemple.
J'ai un gros doute. Le message ICMP de demande de fragmentation ne peut être émis que par un routeur intermédiaire, pas par la destination finale. Le destinataire d'un paquet IP n'a aucune raison d'envoyer un tel message ICMP car cela impliquerait qu'il a reçu le paquet, et dans ce cas pas besoin d'envoyer un ICMP.
Si le destinataire est en fast ethernet, le switch le sait et ne peut pas lui transmettre les jumbo frames. Mais un switch, équipement de couche 2 (liaison), ne peut pas émettre de messages d'erreur ICMP qui sont de la couche 3 (réseau).
NB : la cohabitation du gigabit et du 100 Mb/s sur le même switch se passe très bien. Le même client, équipé d'une carte gigabit sait parler en gigabit avec un des serveurs et en 100 Mb/s avec l'autre. Je ne sais pas si c'est le client qui reprogramme sa carte en fonction de l'IP cible ou le switch qui reçoit en gigabit et recrache en 100 Mb/s mais ça marche. Les problèmes portent uniquement sur les jumbo frames.
Je sais que tu n'as pas dit le contraire, c'est juste un complément d'information, hein.
Je suppose que la couche réseau Linux n'est pas capable de se souvenir de la taille des paquets à utiliser par destination
Si, le cache de routage (ip route show cache) contient le "path MTU" des destinations récentes, résultant éventuellement du mécanisme de découverte "path MTU discovery" (PMTUd) ou des messages ICMP de demande de fragmentation reçus.
Intéressant.
mais qu'elle est capable de la réduire jusqu'à ce que ça passe.
Oui si le PMTUd est activé.
J'ai pas.
Mais il me semble que ce n'est pas la couche IP (réseau) de la pile qui s'occupe des retransmissions, se limitant à activer le flag DF et à faire remonter la taille maxi à la couche supérieure en cas d'erreur. En TCP, c'est la couche TCP (transport) qui s'en occupe toute seule ; en UDP par contre, j'ai peur que ce soit à la charge de l'application émettrice.
C'est aussi comme ça que je comprends, d'où mon étonnement que ça marche en UDP. (Je ne pense pas que mes clients NFS passent en TCP tous seuls.)
-- André Majorel <URL:http://www.teaser.fr/~amajorel/> (Counterfeit: ) "Duty, honor, country" -- Douglas MacArthur "Travail, famille, patrie" -- Philippe Pétain
Zythum
NB : la cohabitation du gigabit et du 100 Mb/s sur le même switch se passe très bien. Le même client, équipé d'une carte gigabit sait parler en gigabit avec un des serveurs et en 100 Mb/s avec l'autre. Je ne sais pas si c'est le client qui reprogramme sa carte en fonction de l'IP cible ou le switch qui reçoit en gigabit et recrache en 100 Mb/s mais ça marche.
C'est la deuxième hypothèse, le switch stocke dans ses buffers la trame reçue en Giga et la réémet en 100 vers la cible.
-- Zythum
NB : la cohabitation du gigabit et du 100 Mb/s sur le même
switch se passe très bien. Le même client, équipé d'une carte
gigabit sait parler en gigabit avec un des serveurs et en 100
Mb/s avec l'autre. Je ne sais pas si c'est le client qui
reprogramme sa carte en fonction de l'IP cible ou le switch qui
reçoit en gigabit et recrache en 100 Mb/s mais ça marche.
C'est la deuxième hypothèse, le switch stocke dans ses buffers la trame
reçue en Giga et la réémet en 100 vers la cible.
NB : la cohabitation du gigabit et du 100 Mb/s sur le même switch se passe très bien. Le même client, équipé d'une carte gigabit sait parler en gigabit avec un des serveurs et en 100 Mb/s avec l'autre. Je ne sais pas si c'est le client qui reprogramme sa carte en fonction de l'IP cible ou le switch qui reçoit en gigabit et recrache en 100 Mb/s mais ça marche.
C'est la deuxième hypothèse, le switch stocke dans ses buffers la trame reçue en Giga et la réémet en 100 vers la cible.
