Histoires de MTU

Le
JKB
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 ?

Merci de vos lumières,

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Le Forgeron
Le #26401060
Le 07/06/2016 22:40, JKB a écrit :
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 ?


ça dépend. En IPv4, la passerelle a le droit de fragmenter.
Mais c'est strictement interdit pour IPv6.
Et pour des performances optimales, c'est mieux si on ne fragmente pas. (surtout 1500 en 1492 + 8 (enfin à un entete près) )
--
Email to the Reply-To address will not be read.
IQ of crossposters with FU: 100 / (number of groups)
IQ of crossposters without FU: 100 / (1 + number of groups)
IQ of multiposters: 100 / ( (number of groups) * (number of groups))
Pascal Hambourg
Le #26401070
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
Le #26401078
Le Wed, 08 Jun 2016 21:47:17 +0200,
Pascal Hambourg
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.

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.
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.

Merci pour les deux réponses. Donc le routeur devrait fragmenter.
Chez moi, je n'ai pas pour habitude de rejeter les paquest ICMP.
Quant au reste du monde, je n'ai pas la main dessus. En tout cas,
mon problème semble résolu par une MTU à 1492.
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 ?
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Pascal Hambourg
Le #26401081
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
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.


En fait même la première parade n'est efficace que pour TCP et les
protocoles qui transmettent la MTU ou dérivée.
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 ?

On t'a répondu : ça dépend du paquet.
IPv4 avec DF=0 : fragmente
IPv4 avec DF=1 : erreur ICMP
IPv6 : erreur ICMPv6
JKB
Le #26401085
Le Thu, 09 Jun 2016 07:42:42 +0200,
Pascal Hambourg
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.
Cordialement,
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Pascal Hambourg
Le #26401167
Le 09/06/2016 09:04, JKB a écrit :
Pascal Hambourg
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.
JKB
Le #26401230
Le Thu, 9 Jun 2016 20:10:44 +0200,
Pascal Hambourg
Le 09/06/2016 09:04, JKB a écrit :
Pascal Hambourg
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 ?

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.
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.

J'ai dû descendre à 1416 ou 1414 (de mémoire) parce qu'en plus, je
passe sur un VPN/UDP sur l'un des sites).
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Pascal Hambourg
Le #26401305
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
Le #26401552
Le Fri, 10 Jun 2016 20:20:03 +0200,
Pascal Hambourg
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 ?

IPv6 avec tous les protocoles classiques TCP (et certainement UDP,
mais je n'ai pas testé).
D'après ce que j'ai compris, le problème ne devrait se
produire qu'en IPv6.

Pourquoi ?

Parce qu'en IPv4, la passerelle devrait fragmenter...
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Publicité
Poster une réponse
Anonyme