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
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
ç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))
PPPoE ? C'est un classique.
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.
Pascal Hambourg
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.
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
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.
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.
On t'a répondu : ça dépend du paquet.
IPv4 avec DF=0 : fragmente
IPv4 avec DF=1 : erreur ICMP
IPv6 : erreur ICMPv6
Pascal Hambourg
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
La réécriture du MSS n'est efficace qu'avec TCP, par définition.
Quel genre de problème as-tu ?
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.
Pascal Hambourg
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.
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
Ça, je m'en doutais. Mais avec quel type de trafic ?
IPv4 ou IPv6, TCP natif (sans VPN), VPN sur UDP, autre, tous ?
Pourquoi ?
Pascal Hambourg
IPv6 avec tous les protocoles classiques TCP (et certainement UDP,
mais je n'ai pas testé).
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