Bonsoir à tous,
Un point me taraude l'esprit.
Considérons une passerelle Linux avec deux interfaces eth0 et eth1.
eth1 est connecté au LAN avec une MTU standard de 1500. eth0 pour
une raison scabreuse ne peut dépasser 1492.
Les machines côté LAN doivent être présenter une MTU de 1492 ou la
passerelle est-elle assez intelligente pour transformer les paquets
quitte à les fragmenter ?
Bonsoir à tous,
Un point me taraude l'esprit.
Considérons une passerelle Linux avec deux interfaces eth0 et eth1.
eth1 est connecté au LAN avec une MTU standard de 1500. eth0 pour
une raison scabreuse ne peut dépasser 1492.
Les machines côté LAN doivent être présenter une MTU de 1492 ou la
passerelle est-elle assez intelligente pour transformer les paquets
quitte à les fragmenter ?
Bonsoir à tous,
Un point me taraude l'esprit.
Considérons une passerelle Linux avec deux interfaces eth0 et eth1.
eth1 est connecté au LAN avec une MTU standard de 1500. eth0 pour
une raison scabreuse ne peut dépasser 1492.
Les machines côté LAN doivent être présenter une MTU de 1492 ou la
passerelle est-elle assez intelligente pour transformer les paquets
quitte à les fragmenter ?
Considérons une passerelle Linux avec deux interfaces eth0 et eth1.
eth1 est connecté au LAN avec une MTU standard de 1500. eth0 pour
une raison scabreuse ne peut dépasser 1492.
Les machines côté LAN doivent être présenter une MTU de 1492 ou la
passerelle est-elle assez intelligente pour transformer les paquets
quitte à les fragmenter ?
Considérons une passerelle Linux avec deux interfaces eth0 et eth1.
eth1 est connecté au LAN avec une MTU standard de 1500. eth0 pour
une raison scabreuse ne peut dépasser 1492.
Les machines côté LAN doivent être présenter une MTU de 1492 ou la
passerelle est-elle assez intelligente pour transformer les paquets
quitte à les fragmenter ?
Considérons une passerelle Linux avec deux interfaces eth0 et eth1.
eth1 est connecté au LAN avec une MTU standard de 1500. eth0 pour
une raison scabreuse ne peut dépasser 1492.
Les machines côté LAN doivent être présenter une MTU de 1492 ou la
passerelle est-elle assez intelligente pour transformer les paquets
quitte à les fragmenter ?
JKB a écrit :Considérons une passerelle Linux avec deux interfaces eth0 et eth1.
eth1 est connecté au LAN avec une MTU standard de 1500. eth0 pour
une raison scabreuse ne peut dépasser 1492.
PPPoE ? C'est un classique.
Les machines côté LAN doivent être présenter une MTU de 1492 ou la
passerelle est-elle assez intelligente pour transformer les paquets
quitte à les fragmenter ?
Normalement, le routeur doit faire ce qu'il faut à réception d'un paquet
trop gros : fragmenter quand c'est possible (IPv4 avec flag DF=0) ou
renvoyer un message d'erreur ICMP "destination unreachable/fragmentation
needed" (IPv4 avec flag DF=1) ou ICMPv6 "packet too big" indiquant la
MTU du lien.
Les hôtes IPv4 utilisant le Path MTU Discovery envoient systématiquement
avec DF=1 pour apprendre la valeur de MTU qui évite la fragmentation en
chemin.
Mais ce n'est pas suffisant : il faut que tous les intervenants soit
conforme aux RFC, et notamment le routeur à l'autre bout du lien de MTU
réduite doit faire pareil de son côté, les hôtes de part et d'autre
doivent accepter les messages d'erreur ICMP|ICMPv6 sinon tout ça ne sert
à rien. Sinon on crée un "trou noir de MTU". Les parades classiques
consistent à baisser la MTU sur le LAN ou à modifier la MSS à la volée
par le routeur, mais cette dernière parade n'est efficace que pour TCP.
JKB a écrit :
Considérons une passerelle Linux avec deux interfaces eth0 et eth1.
eth1 est connecté au LAN avec une MTU standard de 1500. eth0 pour
une raison scabreuse ne peut dépasser 1492.
PPPoE ? C'est un classique.
Les machines côté LAN doivent être présenter une MTU de 1492 ou la
passerelle est-elle assez intelligente pour transformer les paquets
quitte à les fragmenter ?
Normalement, le routeur doit faire ce qu'il faut à réception d'un paquet
trop gros : fragmenter quand c'est possible (IPv4 avec flag DF=0) ou
renvoyer un message d'erreur ICMP "destination unreachable/fragmentation
needed" (IPv4 avec flag DF=1) ou ICMPv6 "packet too big" indiquant la
MTU du lien.
Les hôtes IPv4 utilisant le Path MTU Discovery envoient systématiquement
avec DF=1 pour apprendre la valeur de MTU qui évite la fragmentation en
chemin.
Mais ce n'est pas suffisant : il faut que tous les intervenants soit
conforme aux RFC, et notamment le routeur à l'autre bout du lien de MTU
réduite doit faire pareil de son côté, les hôtes de part et d'autre
doivent accepter les messages d'erreur ICMP|ICMPv6 sinon tout ça ne sert
à rien. Sinon on crée un "trou noir de MTU". Les parades classiques
consistent à baisser la MTU sur le LAN ou à modifier la MSS à la volée
par le routeur, mais cette dernière parade n'est efficace que pour TCP.
JKB a écrit :Considérons une passerelle Linux avec deux interfaces eth0 et eth1.
eth1 est connecté au LAN avec une MTU standard de 1500. eth0 pour
une raison scabreuse ne peut dépasser 1492.
PPPoE ? C'est un classique.
Les machines côté LAN doivent être présenter une MTU de 1492 ou la
passerelle est-elle assez intelligente pour transformer les paquets
quitte à les fragmenter ?
Normalement, le routeur doit faire ce qu'il faut à réception d'un paquet
trop gros : fragmenter quand c'est possible (IPv4 avec flag DF=0) ou
renvoyer un message d'erreur ICMP "destination unreachable/fragmentation
needed" (IPv4 avec flag DF=1) ou ICMPv6 "packet too big" indiquant la
MTU du lien.
Les hôtes IPv4 utilisant le Path MTU Discovery envoient systématiquement
avec DF=1 pour apprendre la valeur de MTU qui évite la fragmentation en
chemin.
Mais ce n'est pas suffisant : il faut que tous les intervenants soit
conforme aux RFC, et notamment le routeur à l'autre bout du lien de MTU
réduite doit faire pareil de son côté, les hôtes de part et d'autre
doivent accepter les messages d'erreur ICMP|ICMPv6 sinon tout ça ne sert
à rien. Sinon on crée un "trou noir de MTU". Les parades classiques
consistent à baisser la MTU sur le LAN ou à modifier la MSS à la volée
par le routeur, mais cette dernière parade n'est efficace que pour TCP.
Oui. Et j'avoue que Nerim m'emm*rde sur ce point. J'ai deux lignes
qui arrivent au même endroit. L'une est en PPPoA et ne pose aucun
problème de ce genre et la seconde est en PPPoE.
Pascal Hambourg écrivait :Les parades classiques
consistent à baisser la MTU sur le LAN ou à modifier la MSS à la volée
par le routeur, mais cette dernière parade n'est efficace que pour TCP.
Mais ça ne répond pas exactement à ma question : avec une MTU de
1500 sur une patte et de 1492 sur une autre, est-ce qu'un paquet
de longueur 1500 va être scindé par le routeur Linux en deux paquets
de longueurs 1492 et 8 ou est-ce que ça part en erreur ICMP ?
Oui. Et j'avoue que Nerim m'emm*rde sur ce point. J'ai deux lignes
qui arrivent au même endroit. L'une est en PPPoA et ne pose aucun
problème de ce genre et la seconde est en PPPoE.
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :
Les parades classiques
consistent à baisser la MTU sur le LAN ou à modifier la MSS à la volée
par le routeur, mais cette dernière parade n'est efficace que pour TCP.
Mais ça ne répond pas exactement à ma question : avec une MTU de
1500 sur une patte et de 1492 sur une autre, est-ce qu'un paquet
de longueur 1500 va être scindé par le routeur Linux en deux paquets
de longueurs 1492 et 8 ou est-ce que ça part en erreur ICMP ?
Oui. Et j'avoue que Nerim m'emm*rde sur ce point. J'ai deux lignes
qui arrivent au même endroit. L'une est en PPPoA et ne pose aucun
problème de ce genre et la seconde est en PPPoE.
Pascal Hambourg écrivait :Les parades classiques
consistent à baisser la MTU sur le LAN ou à modifier la MSS à la volée
par le routeur, mais cette dernière parade n'est efficace que pour TCP.
Mais ça ne répond pas exactement à ma question : avec une MTU de
1500 sur une patte et de 1492 sur une autre, est-ce qu'un paquet
de longueur 1500 va être scindé par le routeur Linux en deux paquets
de longueurs 1492 et 8 ou est-ce que ça part en erreur ICMP ?
JKB a écrit :Oui. Et j'avoue que Nerim m'emm*rde sur ce point. J'ai deux lignes
qui arrivent au même endroit. L'une est en PPPoA et ne pose aucun
problème de ce genre et la seconde est en PPPoE.
Ah, je m'en doutais. Je suis passé par là, et j'ai fait ce qu'il faut
pour passer en PPPoA tant que c'est disponible. La faute n'en revient
pas exclusivement à Nerim. Le problème est que le routeur d'accès du FAI
(LNS) ne connaît pas forcément la MTU du lien xDSL, et le concentrateur
d'accès (BAS) de l'opérateur de collecte la connaît mais n'est pas un
routeur donc ne peut pas fragmenter ni émettre d'erreur ICMP. Le trou
noir de MTU n'est pas en upload mais en download. Chez Nerim comme chez
d'autres, c'est contourné avec la modification de MSS à la volée par le LNS.
JKB a écrit :
Oui. Et j'avoue que Nerim m'emm*rde sur ce point. J'ai deux lignes
qui arrivent au même endroit. L'une est en PPPoA et ne pose aucun
problème de ce genre et la seconde est en PPPoE.
Ah, je m'en doutais. Je suis passé par là, et j'ai fait ce qu'il faut
pour passer en PPPoA tant que c'est disponible. La faute n'en revient
pas exclusivement à Nerim. Le problème est que le routeur d'accès du FAI
(LNS) ne connaît pas forcément la MTU du lien xDSL, et le concentrateur
d'accès (BAS) de l'opérateur de collecte la connaît mais n'est pas un
routeur donc ne peut pas fragmenter ni émettre d'erreur ICMP. Le trou
noir de MTU n'est pas en upload mais en download. Chez Nerim comme chez
d'autres, c'est contourné avec la modification de MSS à la volée par le LNS.
JKB a écrit :Oui. Et j'avoue que Nerim m'emm*rde sur ce point. J'ai deux lignes
qui arrivent au même endroit. L'une est en PPPoA et ne pose aucun
problème de ce genre et la seconde est en PPPoE.
Ah, je m'en doutais. Je suis passé par là, et j'ai fait ce qu'il faut
pour passer en PPPoA tant que c'est disponible. La faute n'en revient
pas exclusivement à Nerim. Le problème est que le routeur d'accès du FAI
(LNS) ne connaît pas forcément la MTU du lien xDSL, et le concentrateur
d'accès (BAS) de l'opérateur de collecte la connaît mais n'est pas un
routeur donc ne peut pas fragmenter ni émettre d'erreur ICMP. Le trou
noir de MTU n'est pas en upload mais en download. Chez Nerim comme chez
d'autres, c'est contourné avec la modification de MSS à la volée par le LNS.
Pascal Hambourg écrivait :JKB a écrit :Oui. Et j'avoue que Nerim m'emm*rde sur ce point. J'ai deux lignes
qui arrivent au même endroit. L'une est en PPPoA et ne pose aucun
problème de ce genre et la seconde est en PPPoE.
Ah, je m'en doutais. Je suis passé par là, et j'ai fait ce qu'il faut
pour passer en PPPoA tant que c'est disponible. La faute n'en revient
pas exclusivement à Nerim. Le problème est que le routeur d'accès du FAI
(LNS) ne connaît pas forcément la MTU du lien xDSL, et le concentrateur
d'accès (BAS) de l'opérateur de collecte la connaît mais n'est pas un
routeur donc ne peut pas fragmenter ni émettre d'erreur ICMP. Le trou
noir de MTU n'est pas en upload mais en download. Chez Nerim comme chez
d'autres, c'est contourné avec la modification de MSS à la volée par le LNS.
Dans ce cas, c'est assez mal contourné...
Je vais voir si ça fonctionne normalement avec une MTU à 1492.
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :
JKB a écrit :
Oui. Et j'avoue que Nerim m'emm*rde sur ce point. J'ai deux lignes
qui arrivent au même endroit. L'une est en PPPoA et ne pose aucun
problème de ce genre et la seconde est en PPPoE.
Ah, je m'en doutais. Je suis passé par là, et j'ai fait ce qu'il faut
pour passer en PPPoA tant que c'est disponible. La faute n'en revient
pas exclusivement à Nerim. Le problème est que le routeur d'accès du FAI
(LNS) ne connaît pas forcément la MTU du lien xDSL, et le concentrateur
d'accès (BAS) de l'opérateur de collecte la connaît mais n'est pas un
routeur donc ne peut pas fragmenter ni émettre d'erreur ICMP. Le trou
noir de MTU n'est pas en upload mais en download. Chez Nerim comme chez
d'autres, c'est contourné avec la modification de MSS à la volée par le LNS.
Dans ce cas, c'est assez mal contourné...
Je vais voir si ça fonctionne normalement avec une MTU à 1492.
Pascal Hambourg écrivait :JKB a écrit :Oui. Et j'avoue que Nerim m'emm*rde sur ce point. J'ai deux lignes
qui arrivent au même endroit. L'une est en PPPoA et ne pose aucun
problème de ce genre et la seconde est en PPPoE.
Ah, je m'en doutais. Je suis passé par là, et j'ai fait ce qu'il faut
pour passer en PPPoA tant que c'est disponible. La faute n'en revient
pas exclusivement à Nerim. Le problème est que le routeur d'accès du FAI
(LNS) ne connaît pas forcément la MTU du lien xDSL, et le concentrateur
d'accès (BAS) de l'opérateur de collecte la connaît mais n'est pas un
routeur donc ne peut pas fragmenter ni émettre d'erreur ICMP. Le trou
noir de MTU n'est pas en upload mais en download. Chez Nerim comme chez
d'autres, c'est contourné avec la modification de MSS à la volée par le LNS.
Dans ce cas, c'est assez mal contourné...
Je vais voir si ça fonctionne normalement avec une MTU à 1492.
Le 09/06/2016 09:04, JKB a écrit :Pascal Hambourg écrivait :JKB a écrit :Oui. Et j'avoue que Nerim m'emm*rde sur ce point. J'ai deux lignes
qui arrivent au même endroit. L'une est en PPPoA et ne pose aucun
problème de ce genre et la seconde est en PPPoE.
Ah, je m'en doutais. Je suis passé par là, et j'ai fait ce qu'il faut
pour passer en PPPoA tant que c'est disponible. La faute n'en revient
pas exclusivement à Nerim. Le problème est que le routeur d'accès du FAI
(LNS) ne connaît pas forcément la MTU du lien xDSL, et le concentrateur
d'accès (BAS) de l'opérateur de collecte la connaît mais n'est pas un
routeur donc ne peut pas fragmenter ni émettre d'erreur ICMP. Le trou
noir de MTU n'est pas en upload mais en download. Chez Nerim comme chez
d'autres, c'est contourné avec la modification de MSS à la volée par le LNS.
Dans ce cas, c'est assez mal contourné...
La réécriture du MSS n'est efficace qu'avec TCP, par définition.
Quel genre de problème as-tu ?
Je vais voir si ça fonctionne normalement avec une MTU à 1492.
Pour ma part j'ai mis 1460, contre un éventuel problème de MTU affectant
ma propre connexion mais aussi celle des machines distantes avec qui je
communique (on ne pense jamais assez aux autres), pour éviter la
fragmentation du tunnel PPTP/GRE entre mon routeur et mon modem ADSL et
accessoirement pour optimiser le remplissage des cellules ATM.
Le 09/06/2016 09:04, JKB a écrit :
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> écrivait :
JKB a écrit :
Oui. Et j'avoue que Nerim m'emm*rde sur ce point. J'ai deux lignes
qui arrivent au même endroit. L'une est en PPPoA et ne pose aucun
problème de ce genre et la seconde est en PPPoE.
Ah, je m'en doutais. Je suis passé par là, et j'ai fait ce qu'il faut
pour passer en PPPoA tant que c'est disponible. La faute n'en revient
pas exclusivement à Nerim. Le problème est que le routeur d'accès du FAI
(LNS) ne connaît pas forcément la MTU du lien xDSL, et le concentrateur
d'accès (BAS) de l'opérateur de collecte la connaît mais n'est pas un
routeur donc ne peut pas fragmenter ni émettre d'erreur ICMP. Le trou
noir de MTU n'est pas en upload mais en download. Chez Nerim comme chez
d'autres, c'est contourné avec la modification de MSS à la volée par le LNS.
Dans ce cas, c'est assez mal contourné...
La réécriture du MSS n'est efficace qu'avec TCP, par définition.
Quel genre de problème as-tu ?
Je vais voir si ça fonctionne normalement avec une MTU à 1492.
Pour ma part j'ai mis 1460, contre un éventuel problème de MTU affectant
ma propre connexion mais aussi celle des machines distantes avec qui je
communique (on ne pense jamais assez aux autres), pour éviter la
fragmentation du tunnel PPTP/GRE entre mon routeur et mon modem ADSL et
accessoirement pour optimiser le remplissage des cellules ATM.
Le 09/06/2016 09:04, JKB a écrit :Pascal Hambourg écrivait :JKB a écrit :Oui. Et j'avoue que Nerim m'emm*rde sur ce point. J'ai deux lignes
qui arrivent au même endroit. L'une est en PPPoA et ne pose aucun
problème de ce genre et la seconde est en PPPoE.
Ah, je m'en doutais. Je suis passé par là, et j'ai fait ce qu'il faut
pour passer en PPPoA tant que c'est disponible. La faute n'en revient
pas exclusivement à Nerim. Le problème est que le routeur d'accès du FAI
(LNS) ne connaît pas forcément la MTU du lien xDSL, et le concentrateur
d'accès (BAS) de l'opérateur de collecte la connaît mais n'est pas un
routeur donc ne peut pas fragmenter ni émettre d'erreur ICMP. Le trou
noir de MTU n'est pas en upload mais en download. Chez Nerim comme chez
d'autres, c'est contourné avec la modification de MSS à la volée par le LNS.
Dans ce cas, c'est assez mal contourné...
La réécriture du MSS n'est efficace qu'avec TCP, par définition.
Quel genre de problème as-tu ?
Je vais voir si ça fonctionne normalement avec une MTU à 1492.
Pour ma part j'ai mis 1460, contre un éventuel problème de MTU affectant
ma propre connexion mais aussi celle des machines distantes avec qui je
communique (on ne pense jamais assez aux autres), pour éviter la
fragmentation du tunnel PPTP/GRE entre mon routeur et mon modem ADSL et
accessoirement pour optimiser le remplissage des cellules ATM.
Quel genre de problème as-tu ?
Un trou de MTU en IPv4 (et la même chose en IPv6) avec une MTU de
1500.
D'après ce que j'ai compris, le problème ne devrait se
produire qu'en IPv6.
Quel genre de problème as-tu ?
Un trou de MTU en IPv4 (et la même chose en IPv6) avec une MTU de
1500.
D'après ce que j'ai compris, le problème ne devrait se
produire qu'en IPv6.
Quel genre de problème as-tu ?
Un trou de MTU en IPv4 (et la même chose en IPv6) avec une MTU de
1500.
D'après ce que j'ai compris, le problème ne devrait se
produire qu'en IPv6.
JKB a écrit :Quel genre de problème as-tu ?
Un trou de MTU en IPv4 (et la même chose en IPv6) avec une MTU de
1500.
Ça, je m'en doutais. Mais avec quel type de trafic ?
IPv4 ou IPv6, TCP natif (sans VPN), VPN sur UDP, autre, tous ?
D'après ce que j'ai compris, le problème ne devrait se
produire qu'en IPv6.
Pourquoi ?
JKB a écrit :
Quel genre de problème as-tu ?
Un trou de MTU en IPv4 (et la même chose en IPv6) avec une MTU de
1500.
Ça, je m'en doutais. Mais avec quel type de trafic ?
IPv4 ou IPv6, TCP natif (sans VPN), VPN sur UDP, autre, tous ?
D'après ce que j'ai compris, le problème ne devrait se
produire qu'en IPv6.
Pourquoi ?
JKB a écrit :Quel genre de problème as-tu ?
Un trou de MTU en IPv4 (et la même chose en IPv6) avec une MTU de
1500.
Ça, je m'en doutais. Mais avec quel type de trafic ?
IPv4 ou IPv6, TCP natif (sans VPN), VPN sur UDP, autre, tous ?
D'après ce que j'ai compris, le problème ne devrait se
produire qu'en IPv6.
Pourquoi ?