Supposez qu'un datagramme IP soit fragmenté (par un routeur par exemple) en
3 datagrammes pour continuer son chemin.
Le mode IP étant non connecté, le 3ème fragment (MF=0, offset != 0) pourrait
bien arriver à destination avant le 1er (MF=1, offset =0). A mon avis, les 3
fragments vont à la poubelle, je vois mal la machine destinatrice faire une
remise en ordre (ên s'appuyant sur le numéro d'identification).
Et vous, quel est votre avis ?
Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?
Et pourtant si, c'est ce que doit faire la machine, d'après la RFC 760 (section 3.2, pages 24 et suivantes).
Exact, l'algorithme est aussi décrit dans RFC 815. J'avais loupé ces développements.
On peut éviter la fragmentation avec pMTUd (path MTU discovery). Oui mais le prix a payer est dans ce cas de ne pas beneficier des
performances d'un troncon à a haute valeur de MTU.Suffit de reduire MSS de facon à ce que : data + overhead ip < Plus petit MTU rencontre sur le circuit .. (si les messages icmp ne sont pas bloques ca marche ...).
En fait qui fragmente réellement ? C'est l'interface d'un host (le MTU est une carracteristique d'interface).
Le cas le plus exposé est celui du routeur qui réceptionne un datagramme dont la taille est supérieure au MTU du bond suivant. non car la taille max des packets retransmis ne peut exceder le MTU de
l'interface qui recoit.Le bond suivant fragmentera ou defragmentera suivant le besoin.Sur une session tcp il y a negociation de MSS a l'etablissement du circuit , donc entre machines de bout en bout ... ce qui se passe au milieu devrait etre transparent.. mais ...
A-t-on des cas où cette fragmentation est engendrée par la machine source parce que TCP par exemple envoie un segment de taille importante ? Normalement, un paramètre MTU (au pire par défaut) devrait remonter dans la couche transport pour éviter cette fragmentation qui réduit les performances. non , ne pas defragmenter reduit les perfs. Exemple grossier MSS = 4 MTU
(moins une en tete ip de 40 octets soit : 5960 octets) . Ce datagramme , qui se promene fragmente sous forme de 4 packets de 1500 octets (chacun leur en tete avec numero d'ordre etc) s'il recontre une interface avec MTU >= 8k se transmormera en un seul packet de 6000 octets data + en tete ip . CA sera plus rentable bien sur ... charge ensuite aux autre machines a MTU plus faibles de fragmenter comme il se doit ...
Cordialement, Angelot Amicalement
Hello,
Angelot wrote:
Bonsoir Jacques,
Et pourtant si, c'est ce que doit faire la machine, d'après la RFC 760
(section 3.2, pages 24 et suivantes).
Exact, l'algorithme est aussi décrit dans RFC 815. J'avais loupé ces
développements.
On peut éviter la fragmentation avec pMTUd (path MTU discovery).
Oui mais le prix a payer est dans ce cas de ne pas beneficier des
performances d'un troncon à a haute valeur de MTU.Suffit de reduire MSS de
facon à ce que : data + overhead ip < Plus petit MTU rencontre sur le
circuit .. (si les messages icmp ne sont pas bloques ca marche ...).
En fait qui fragmente réellement ?
C'est l'interface d'un host (le MTU est une carracteristique d'interface).
Le cas le plus exposé est celui du routeur qui réceptionne un datagramme
dont la taille est supérieure au MTU du bond suivant.
non car la taille max des packets retransmis ne peut exceder le MTU de
l'interface qui recoit.Le bond suivant fragmentera ou defragmentera suivant
le besoin.Sur une session tcp il y a negociation de MSS a l'etablissement
du circuit , donc entre machines de bout en bout ... ce qui se passe au
milieu devrait etre transparent.. mais ...
A-t-on des cas où cette fragmentation est engendrée par la machine source
parce que TCP par exemple envoie un segment de taille importante ?
Normalement, un paramètre MTU (au pire par défaut) devrait remonter dans
la couche transport pour éviter cette fragmentation qui réduit les
performances.
non , ne pas defragmenter reduit les perfs. Exemple grossier MSS = 4 MTU
(moins une en tete ip de 40 octets soit : 5960 octets) . Ce datagramme , qui
se promene fragmente sous forme de 4 packets de 1500 octets (chacun leur en
tete avec numero d'ordre etc) s'il recontre une interface avec MTU >= 8k
se transmormera en un seul packet de 6000 octets data + en tete ip .
CA sera plus rentable bien sur ... charge ensuite aux autre machines a MTU
plus faibles de fragmenter comme il se doit ...
Et pourtant si, c'est ce que doit faire la machine, d'après la RFC 760 (section 3.2, pages 24 et suivantes).
Exact, l'algorithme est aussi décrit dans RFC 815. J'avais loupé ces développements.
On peut éviter la fragmentation avec pMTUd (path MTU discovery). Oui mais le prix a payer est dans ce cas de ne pas beneficier des
performances d'un troncon à a haute valeur de MTU.Suffit de reduire MSS de facon à ce que : data + overhead ip < Plus petit MTU rencontre sur le circuit .. (si les messages icmp ne sont pas bloques ca marche ...).
En fait qui fragmente réellement ? C'est l'interface d'un host (le MTU est une carracteristique d'interface).
Le cas le plus exposé est celui du routeur qui réceptionne un datagramme dont la taille est supérieure au MTU du bond suivant. non car la taille max des packets retransmis ne peut exceder le MTU de
l'interface qui recoit.Le bond suivant fragmentera ou defragmentera suivant le besoin.Sur une session tcp il y a negociation de MSS a l'etablissement du circuit , donc entre machines de bout en bout ... ce qui se passe au milieu devrait etre transparent.. mais ...
A-t-on des cas où cette fragmentation est engendrée par la machine source parce que TCP par exemple envoie un segment de taille importante ? Normalement, un paramètre MTU (au pire par défaut) devrait remonter dans la couche transport pour éviter cette fragmentation qui réduit les performances. non , ne pas defragmenter reduit les perfs. Exemple grossier MSS = 4 MTU
(moins une en tete ip de 40 octets soit : 5960 octets) . Ce datagramme , qui se promene fragmente sous forme de 4 packets de 1500 octets (chacun leur en tete avec numero d'ordre etc) s'il recontre une interface avec MTU >= 8k se transmormera en un seul packet de 6000 octets data + en tete ip . CA sera plus rentable bien sur ... charge ensuite aux autre machines a MTU plus faibles de fragmenter comme il se doit ...
Cordialement, Angelot Amicalement
Jacques Caron
Salut,
On Wed, 16 Jun 2004 05:59:14 +0200, Patrick_91 wrote:
On peut éviter la fragmentation avec pMTUd (path MTU discovery). Oui mais le prix a payer est dans ce cas de ne pas beneficier des
performances d'un troncon à a haute valeur de MTU.Suffit de reduire MSS de facon à ce que : data + overhead ip < Plus petit MTU rencontre sur le circuit .. (si les messages icmp ne sont pas bloques ca marche ...).
C'est justement ce que fait pMTUd...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On Wed, 16 Jun 2004 05:59:14 +0200, Patrick_91 <patrick_91@nospam.com>
wrote:
On peut éviter la fragmentation avec pMTUd (path MTU discovery).
Oui mais le prix a payer est dans ce cas de ne pas beneficier des
performances d'un troncon à a haute valeur de MTU.Suffit de reduire MSS
de facon à ce que : data + overhead ip < Plus petit MTU rencontre sur le
circuit .. (si les messages icmp ne sont pas bloques ca marche ...).
C'est justement ce que fait pMTUd...
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Wed, 16 Jun 2004 05:59:14 +0200, Patrick_91 wrote:
On peut éviter la fragmentation avec pMTUd (path MTU discovery). Oui mais le prix a payer est dans ce cas de ne pas beneficier des
performances d'un troncon à a haute valeur de MTU.Suffit de reduire MSS de facon à ce que : data + overhead ip < Plus petit MTU rencontre sur le circuit .. (si les messages icmp ne sont pas bloques ca marche ...).
C'est justement ce que fait pMTUd...
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Angelot
Bonjour Patrick,
Merci pour cette discussion
Le début de l'explication est aguichant, mais pour continuer le texte, il
faut se procurer l'ouvrage ! Comment quel ouvrage ?? les RFC's suivants sont accessibles :
791 815 1122 879 1180
Ca c'est gratos ...
Assurément, je n'évoque pas du tout les RFC mais de l'ouvrage auquel votre lien se réfère. Vous aurez noté que, bien évidemment, une RFC n'est pas un ouvrage.
"Fragmentation is always undesirable because it reduces performance. In fact, fragmentation is not allowed in IPv6. Large packets are always preferable... This topic continues in "The Encyclopedia of Networking and Telecommunications" with a discussion of the following..."
Sapristi, on peut mettre plus de 1500 octets en charge utile de la trame MAC ! D'où vous vient cette information ? Bien sur , l'information vient des carracteristiques des équipements niv 2
(point a point) et j'avais pris la precaution de dire qu'on etait pas obligé de rester en ethernet classique ...ou IEE 802.3 voir ce link ... http://www2.rad.com/networks/2003/largemtu/avlnets.htm des MTU de 4k à 65.280 k sont mentionnées.Heureusement , si non le reseau INternet serait bien peu performant ...
Le lien est très intéressant. Je lis aussi ceci :
"Statistically, most Internet communications pass through an Ethernet network somewhere on the way. This is why Ethernet's 1,500 byte MTU has become the standard MTU, and the main Internet bottleneck"
Donc, selon vos termes, internet est bien peu performant.
Cordialement, Angelot
Bonjour Patrick,
Merci pour cette discussion
Le début de l'explication est aguichant, mais pour continuer le texte,
il
faut se procurer l'ouvrage !
Comment quel ouvrage ?? les RFC's suivants sont accessibles :
791 815 1122 879 1180
Ca c'est gratos ...
Assurément, je n'évoque pas du tout les RFC mais de l'ouvrage auquel votre
lien se réfère. Vous aurez noté que, bien évidemment, une RFC n'est pas un
ouvrage.
"Fragmentation is always undesirable because it reduces performance. In
fact, fragmentation is not allowed in IPv6. Large packets are always
preferable...
This topic continues in "The Encyclopedia of Networking and
Telecommunications" with a discussion of the following..."
Sapristi, on peut mettre plus de 1500 octets en charge utile de la trame
MAC !
D'où vous vient cette information ?
Bien sur , l'information vient des carracteristiques des équipements niv 2
(point a point) et j'avais pris la precaution de dire qu'on etait pas
obligé de rester en ethernet classique ...ou IEE 802.3
voir ce link ...
http://www2.rad.com/networks/2003/largemtu/avlnets.htm
des MTU de 4k à 65.280 k sont mentionnées.Heureusement , si non le reseau
INternet serait bien peu performant ...
Le lien est très intéressant. Je lis aussi ceci :
"Statistically, most Internet communications pass through an Ethernet
network somewhere on the way. This is why Ethernet's 1,500 byte MTU has
become the standard MTU, and the main Internet bottleneck"
Donc, selon vos termes, internet est bien peu performant.
Le début de l'explication est aguichant, mais pour continuer le texte, il
faut se procurer l'ouvrage ! Comment quel ouvrage ?? les RFC's suivants sont accessibles :
791 815 1122 879 1180
Ca c'est gratos ...
Assurément, je n'évoque pas du tout les RFC mais de l'ouvrage auquel votre lien se réfère. Vous aurez noté que, bien évidemment, une RFC n'est pas un ouvrage.
"Fragmentation is always undesirable because it reduces performance. In fact, fragmentation is not allowed in IPv6. Large packets are always preferable... This topic continues in "The Encyclopedia of Networking and Telecommunications" with a discussion of the following..."
Sapristi, on peut mettre plus de 1500 octets en charge utile de la trame MAC ! D'où vous vient cette information ? Bien sur , l'information vient des carracteristiques des équipements niv 2
(point a point) et j'avais pris la precaution de dire qu'on etait pas obligé de rester en ethernet classique ...ou IEE 802.3 voir ce link ... http://www2.rad.com/networks/2003/largemtu/avlnets.htm des MTU de 4k à 65.280 k sont mentionnées.Heureusement , si non le reseau INternet serait bien peu performant ...
Le lien est très intéressant. Je lis aussi ceci :
"Statistically, most Internet communications pass through an Ethernet network somewhere on the way. This is why Ethernet's 1,500 byte MTU has become the standard MTU, and the main Internet bottleneck"
Donc, selon vos termes, internet est bien peu performant.
Cordialement, Angelot
Eric Masson
"Jacques" == Jacques Caron writes:
'Lut,
Jacques> C'est justement ce que fait pMTUd...
Il y a des fois ou tu dois te demander si tu dois rire ou pleurer, non ?
Eric Masson
-- McA> C'est pas des injures ça?? JJS> Fu2. McA> Tiens encore une fois et c'est toi qui parle d'injures!! -+- McA in GNU : Va te faire follow-Upper chez les grecs -+-
"Jacques" == Jacques Caron <jc@imfeurope.com> writes:
'Lut,
Jacques> C'est justement ce que fait pMTUd...
Il y a des fois ou tu dois te demander si tu dois rire ou pleurer, non ?
Eric Masson
--
McA> C'est pas des injures ça??
JJS> Fu2.
McA> Tiens encore une fois et c'est toi qui parle d'injures!!
-+- McA in GNU : Va te faire follow-Upper chez les grecs -+-
Il y a des fois ou tu dois te demander si tu dois rire ou pleurer, non ?
Eric Masson
-- McA> C'est pas des injures ça?? JJS> Fu2. McA> Tiens encore une fois et c'est toi qui parle d'injures!! -+- McA in GNU : Va te faire follow-Upper chez les grecs -+-
Patrick_91
Hello
Jacques Caron wrote:
Salut,
On Wed, 16 Jun 2004 05:59:14 +0200, Patrick_91 wrote:
On peut éviter la fragmentation avec pMTUd (path MTU discovery). Oui mais le prix a payer est dans ce cas de ne pas beneficier des
performances d'un troncon à a haute valeur de MTU.Suffit de reduire MSS de facon à ce que : data + overhead ip < Plus petit MTU rencontre sur le circuit .. (si les messages icmp ne sont pas bloques ca marche ...).
C'est justement ce que fait pMTUd... OUi , qui a dit le contraire ? c'est justement ce que j'expliquais, mais le
commentaire : "oui mais le prix a payer est dans ce cas de ne pas beneficier des performances d'un troncon à a haute valeur de MTU." amene la question : Que vaut il mieux : utiliser pmutd ou laisser fragmenter et reassembler si un grand pourcentage de hosts sur le reseau presentent des interfaces a tres fort MTU ??
Amicalement
Hello
Jacques Caron wrote:
Salut,
On Wed, 16 Jun 2004 05:59:14 +0200, Patrick_91 <patrick_91@nospam.com>
wrote:
On peut éviter la fragmentation avec pMTUd (path MTU discovery).
Oui mais le prix a payer est dans ce cas de ne pas beneficier des
performances d'un troncon à a haute valeur de MTU.Suffit de reduire MSS
de facon à ce que : data + overhead ip < Plus petit MTU rencontre sur le
circuit .. (si les messages icmp ne sont pas bloques ca marche ...).
C'est justement ce que fait pMTUd...
OUi , qui a dit le contraire ? c'est justement ce que j'expliquais, mais le
commentaire : "oui mais le prix a payer est dans ce cas de ne pas
beneficier des performances d'un troncon à a haute valeur de MTU."
amene la question :
Que vaut il mieux : utiliser pmutd ou laisser fragmenter et reassembler si
un grand pourcentage de hosts sur le reseau presentent des interfaces a tres
fort MTU ??
On Wed, 16 Jun 2004 05:59:14 +0200, Patrick_91 wrote:
On peut éviter la fragmentation avec pMTUd (path MTU discovery). Oui mais le prix a payer est dans ce cas de ne pas beneficier des
performances d'un troncon à a haute valeur de MTU.Suffit de reduire MSS de facon à ce que : data + overhead ip < Plus petit MTU rencontre sur le circuit .. (si les messages icmp ne sont pas bloques ca marche ...).
C'est justement ce que fait pMTUd... OUi , qui a dit le contraire ? c'est justement ce que j'expliquais, mais le
commentaire : "oui mais le prix a payer est dans ce cas de ne pas beneficier des performances d'un troncon à a haute valeur de MTU." amene la question : Que vaut il mieux : utiliser pmutd ou laisser fragmenter et reassembler si un grand pourcentage de hosts sur le reseau presentent des interfaces a tres fort MTU ??
Amicalement
Patrick_91
Bonjour,
Angelot wrote:
Bonjour Patrick,
Merci pour cette discussion
Le début de l'explication est aguichant, mais pour continuer le texte, il
faut se procurer l'ouvrage ! Comment quel ouvrage ?? les RFC's suivants sont accessibles :
791 815 1122 879 1180
Ca c'est gratos ...
Assurément, je n'évoque pas du tout les RFC mais de l'ouvrage auquel votre lien se réfère. Vous aurez noté que, bien évidemment, une RFC n'est pas un ouvrage. Non c'est un document de reference ! ceux qui servent a écrire les
bouquins .. c'est rugeux certe mais c'est precis ..
"Fragmentation is always undesirable because it reduces performance. In fact, fragmentation is not allowed in IPv6. Large packets are always preferable... "large packets ... c'est clair .. "
2 (point a point) et j'avais pris la precaution de dire qu'on etait pas obligé de rester en ethernet classique ...ou IEE 802.3 voir ce link ... http://www2.rad.com/networks/2003/largemtu/avlnets.htm des MTU de 4k à 65.280 k sont mentionnées.Heureusement , si non le reseau INternet serait bien peu performant ...
Le lien est très intéressant. Je lis aussi ceci :
"Statistically, most Internet communications pass through an Ethernet network somewhere on the way. This is why Ethernet's 1,500 byte MTU has become the standard MTU, and the main Internet bottleneck"
Donc, selon vos termes, internet est bien peu performant. Non Internet est divers, non homogene pour ce qui concerne le reseau et les
1500 bytes de MTU rencontres classiquement sur beaucoups de terminaux presque une regle ... (sauf pour les liaisons ADSL entre autre ca fait moins que 1500) mon interogation est : faut il conformer les packets de facon a ne jamais fragmenter , (donc inferieurs a 1500 voir 1472 ou mieux en laissant pmutd faire l'ajustement) ou bien laisser fragmenter et reassembler pour tirer parti des tres fortes valeurs de MTU rencontrees au niveau des infrastructures reseau (remember : large packets). En d'autres termes, avoir au depart un MTU de 1500 (aux alentours) mais un MSS egal a 4 ou 6 MTU (-40 octets) permettrai de reconstituer de gros packets la ou c'est possible au niveau transport.. apres faut fragmenter a nouveau c'est sur , mon interogation est : que vaut il mieux faire ?? Et je n'ai pas la reponse toute faite ... je ne raisonne pas sur un troncon unique mais sur une somme importante de troncons divers bien sur ... La ou l'adage : "vaut mieux ne pas fragmenter" devient moins evident ..
Cordialement, Angelot Amicalement
Patrick
Bonjour,
Angelot wrote:
Bonjour Patrick,
Merci pour cette discussion
Le début de l'explication est aguichant, mais pour continuer le texte,
il
faut se procurer l'ouvrage !
Comment quel ouvrage ?? les RFC's suivants sont accessibles :
791 815 1122 879 1180
Ca c'est gratos ...
Assurément, je n'évoque pas du tout les RFC mais de l'ouvrage auquel votre
lien se réfère. Vous aurez noté que, bien évidemment, une RFC n'est pas un
ouvrage.
Non c'est un document de reference ! ceux qui servent a écrire les
bouquins .. c'est rugeux certe mais c'est precis ..
"Fragmentation is always undesirable because it reduces performance. In
fact, fragmentation is not allowed in IPv6. Large packets are always
preferable...
"large packets ... c'est clair .. "
2 (point a point) et j'avais pris la precaution de dire qu'on etait pas
obligé de rester en ethernet classique ...ou IEE 802.3
voir ce link ...
http://www2.rad.com/networks/2003/largemtu/avlnets.htm
des MTU de 4k à 65.280 k sont mentionnées.Heureusement , si non le reseau
INternet serait bien peu performant ...
Le lien est très intéressant. Je lis aussi ceci :
"Statistically, most Internet communications pass through an Ethernet
network somewhere on the way. This is why Ethernet's 1,500 byte MTU has
become the standard MTU, and the main Internet bottleneck"
Donc, selon vos termes, internet est bien peu performant.
Non Internet est divers, non homogene pour ce qui concerne le reseau et les
1500 bytes de MTU rencontres classiquement sur beaucoups de terminaux
presque une regle ... (sauf pour les liaisons ADSL entre autre ca fait
moins que 1500) mon interogation est : faut il conformer les packets de
facon a ne jamais fragmenter , (donc inferieurs a 1500 voir 1472 ou mieux
en laissant pmutd faire l'ajustement) ou bien laisser fragmenter et
reassembler pour tirer parti des tres fortes valeurs de MTU rencontrees au
niveau des infrastructures reseau (remember : large packets).
En d'autres termes, avoir au depart un MTU de 1500 (aux alentours) mais un
MSS egal a 4 ou 6 MTU (-40 octets) permettrai de reconstituer de gros
packets la ou c'est possible au niveau transport.. apres faut fragmenter a
nouveau c'est sur , mon interogation est : que vaut il mieux faire ??
Et je n'ai pas la reponse toute faite ... je ne raisonne pas sur un troncon
unique mais sur une somme importante de troncons divers bien sur ...
La ou l'adage : "vaut mieux ne pas fragmenter" devient moins evident ..
Le début de l'explication est aguichant, mais pour continuer le texte, il
faut se procurer l'ouvrage ! Comment quel ouvrage ?? les RFC's suivants sont accessibles :
791 815 1122 879 1180
Ca c'est gratos ...
Assurément, je n'évoque pas du tout les RFC mais de l'ouvrage auquel votre lien se réfère. Vous aurez noté que, bien évidemment, une RFC n'est pas un ouvrage. Non c'est un document de reference ! ceux qui servent a écrire les
bouquins .. c'est rugeux certe mais c'est precis ..
"Fragmentation is always undesirable because it reduces performance. In fact, fragmentation is not allowed in IPv6. Large packets are always preferable... "large packets ... c'est clair .. "
2 (point a point) et j'avais pris la precaution de dire qu'on etait pas obligé de rester en ethernet classique ...ou IEE 802.3 voir ce link ... http://www2.rad.com/networks/2003/largemtu/avlnets.htm des MTU de 4k à 65.280 k sont mentionnées.Heureusement , si non le reseau INternet serait bien peu performant ...
Le lien est très intéressant. Je lis aussi ceci :
"Statistically, most Internet communications pass through an Ethernet network somewhere on the way. This is why Ethernet's 1,500 byte MTU has become the standard MTU, and the main Internet bottleneck"
Donc, selon vos termes, internet est bien peu performant. Non Internet est divers, non homogene pour ce qui concerne le reseau et les
1500 bytes de MTU rencontres classiquement sur beaucoups de terminaux presque une regle ... (sauf pour les liaisons ADSL entre autre ca fait moins que 1500) mon interogation est : faut il conformer les packets de facon a ne jamais fragmenter , (donc inferieurs a 1500 voir 1472 ou mieux en laissant pmutd faire l'ajustement) ou bien laisser fragmenter et reassembler pour tirer parti des tres fortes valeurs de MTU rencontrees au niveau des infrastructures reseau (remember : large packets). En d'autres termes, avoir au depart un MTU de 1500 (aux alentours) mais un MSS egal a 4 ou 6 MTU (-40 octets) permettrai de reconstituer de gros packets la ou c'est possible au niveau transport.. apres faut fragmenter a nouveau c'est sur , mon interogation est : que vaut il mieux faire ?? Et je n'ai pas la reponse toute faite ... je ne raisonne pas sur un troncon unique mais sur une somme importante de troncons divers bien sur ... La ou l'adage : "vaut mieux ne pas fragmenter" devient moins evident ..
Cordialement, Angelot Amicalement
Patrick
Angelot
Merci Patrick,
OUi , qui a dit le contraire ? c'est justement ce que j'expliquais, mais le
commentaire : "oui mais le prix a payer est dans ce cas de ne pas beneficier des performances d'un troncon à a haute valeur de MTU." amene la question : Que vaut il mieux : utiliser pmutd ou laisser fragmenter et reassembler si un grand pourcentage de hosts sur le reseau presentent des interfaces a tres
fort MTU ??
Plus on discute plus les points se précisent d'eux mêmes.
Le réassemblage n'est réalisé que par la machine destinatrice du datagramme.
Un routeur ne peut que fragmenter, il ne réassemble pas. Ce qui est fragmenté le reste jusqu'à la destination finale. Le routeur ne saurait d'ailleurs pas réassembler à tout coup puisque, en mode non connecté, les fragments peuvent suivre des chemins différents.
D'accord ? Cordialement, Angelot
Merci Patrick,
OUi , qui a dit le contraire ? c'est justement ce que j'expliquais, mais
le
commentaire : "oui mais le prix a payer est dans ce cas de ne pas
beneficier des performances d'un troncon à a haute valeur de MTU."
amene la question :
Que vaut il mieux : utiliser pmutd ou laisser fragmenter et reassembler si
un grand pourcentage de hosts sur le reseau presentent des interfaces a
tres
fort MTU ??
Plus on discute plus les points se précisent d'eux mêmes.
Le réassemblage n'est réalisé que par la machine destinatrice du datagramme.
Un routeur ne peut que fragmenter, il ne réassemble pas. Ce qui est
fragmenté le reste jusqu'à la destination finale. Le routeur ne saurait
d'ailleurs pas réassembler à tout coup puisque, en mode non connecté, les
fragments peuvent suivre des chemins différents.
OUi , qui a dit le contraire ? c'est justement ce que j'expliquais, mais le
commentaire : "oui mais le prix a payer est dans ce cas de ne pas beneficier des performances d'un troncon à a haute valeur de MTU." amene la question : Que vaut il mieux : utiliser pmutd ou laisser fragmenter et reassembler si un grand pourcentage de hosts sur le reseau presentent des interfaces a tres
fort MTU ??
Plus on discute plus les points se précisent d'eux mêmes.
Le réassemblage n'est réalisé que par la machine destinatrice du datagramme.
Un routeur ne peut que fragmenter, il ne réassemble pas. Ce qui est fragmenté le reste jusqu'à la destination finale. Le routeur ne saurait d'ailleurs pas réassembler à tout coup puisque, en mode non connecté, les fragments peuvent suivre des chemins différents.
D'accord ? Cordialement, Angelot
Angelot
Bonsoir Angelot,
Une trouvaille extraordinaire dont je fais bénéficier les lecteurs (enfin ! extraordinaire, pour l'un des nombreux points que nous avons débattus. Et puis, cela va paraître tout a fait trivial pour beaucoup d'entre vous).
Une question m'a tenaillé l'esprit pendant un bon bout de temps : existe-t'il un cas typique de fragmentation produite en local, par la machine source, et non par un routeur comme tous les exemples que nous voyons sur le sujet.
Eh bien, j'ai trouvé un cas !
ping -l 5000 www.voila.fr
L'indicateur -l force l'envoi d'un IP-SDU de 5000 octets par exemple. J'observe alors par Ethereal les fragments : quelle délectation, beau comme le passage de Vénus toute nue devant le Soleil !
Bon ! c'est anodin. Cordialement, Angelot
Bonsoir Angelot,
Une trouvaille extraordinaire dont je fais bénéficier les lecteurs (enfin !
extraordinaire, pour l'un des nombreux points que nous avons débattus. Et
puis, cela va paraître tout a fait trivial pour beaucoup d'entre vous).
Une question m'a tenaillé l'esprit pendant un bon bout de temps :
existe-t'il un cas typique de fragmentation produite en local, par la
machine source, et non par un routeur comme tous les exemples que nous
voyons sur le sujet.
Eh bien, j'ai trouvé un cas !
ping -l 5000 www.voila.fr
L'indicateur -l force l'envoi d'un IP-SDU de 5000 octets par exemple.
J'observe alors par Ethereal les fragments : quelle délectation, beau comme
le passage de Vénus toute nue devant le Soleil !
Une trouvaille extraordinaire dont je fais bénéficier les lecteurs (enfin ! extraordinaire, pour l'un des nombreux points que nous avons débattus. Et puis, cela va paraître tout a fait trivial pour beaucoup d'entre vous).
Une question m'a tenaillé l'esprit pendant un bon bout de temps : existe-t'il un cas typique de fragmentation produite en local, par la machine source, et non par un routeur comme tous les exemples que nous voyons sur le sujet.
Eh bien, j'ai trouvé un cas !
ping -l 5000 www.voila.fr
L'indicateur -l force l'envoi d'un IP-SDU de 5000 octets par exemple. J'observe alors par Ethereal les fragments : quelle délectation, beau comme le passage de Vénus toute nue devant le Soleil !
Bon ! c'est anodin. Cordialement, Angelot
_SebF - www.frameip.com
"Angelot" a écrit dans le message de news: caq3n6$9f7$
L'indicateur -l force l'envoi d'un IP-SDU de 5000 octets par exemple. J'observe alors par Ethereal les fragments : quelle délectation, beau comme
le passage de Vénus toute nue devant le Soleil !
Tu peux aussi le visualiser avec un générateur de datagramme IP en spécifiant un playload supérieur au MTU de ton interface. Le fait de générer te permettra d'utiliser Tcp, Igmp, .. . Le fait de changer l'ip_type, n'influant pas sur la fragmentation qui est gérer au niveau 2(TCPIP), est beau aussi. Cela permet de voir la lune passer :)
--
_SebF
http://www.frameip.com Pour ceux qui aiment TCPIP
"Angelot" <OnSePame@KesceKonSePame.fr> a écrit dans le message de news:
caq3n6$9f7$1@news-reader2.wanadoo.fr...
L'indicateur -l force l'envoi d'un IP-SDU de 5000 octets par exemple.
J'observe alors par Ethereal les fragments : quelle délectation, beau
comme
le passage de Vénus toute nue devant le Soleil !
Tu peux aussi le visualiser avec un générateur de datagramme IP en
spécifiant un playload supérieur au MTU de ton interface. Le fait de générer
te permettra d'utiliser Tcp, Igmp, .. . Le fait de changer l'ip_type,
n'influant pas sur la fragmentation qui est gérer au niveau 2(TCPIP), est
beau aussi. Cela permet de voir la lune passer :)
"Angelot" a écrit dans le message de news: caq3n6$9f7$
L'indicateur -l force l'envoi d'un IP-SDU de 5000 octets par exemple. J'observe alors par Ethereal les fragments : quelle délectation, beau comme
le passage de Vénus toute nue devant le Soleil !
Tu peux aussi le visualiser avec un générateur de datagramme IP en spécifiant un playload supérieur au MTU de ton interface. Le fait de générer te permettra d'utiliser Tcp, Igmp, .. . Le fait de changer l'ip_type, n'influant pas sur la fragmentation qui est gérer au niveau 2(TCPIP), est beau aussi. Cela permet de voir la lune passer :)
