Bonsoir,
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 ?
Bonsoir,
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 ?
Bonsoir,
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 ?
A mon avis, les 3
fragments vont à la poubelle, je vois mal la machine destinatrice faire
uneremise en ordre (ên s'appuyant sur le numéro d'identification).
Et vous, quel est votre avis ?
A mon avis, la couche IP est là pour s'occuper du réassemblage. Comme tous
les paquets doivent comporter le même ID, la couche Ip pourra facilement
regrouper les fragments dans un même groupe afin de les remettrent dans
l'ordre grâce au positionnement de l'offset.
Comme tu le dis, IP est bien en mode non connecté, car si il manque un
fragment, étant donnée qu'il n'y a pas de contrôle à ce niveau, le
fragment
manquant ne sera pas renvoyé.
Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?
J'ai pas compris où tu désirais en venir, car je dirais plutôt :
on provoque la fragmentation grâce au MTU. :)
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 ?
A mon avis, la couche IP est là pour s'occuper du réassemblage. Comme tous
les paquets doivent comporter le même ID, la couche Ip pourra facilement
regrouper les fragments dans un même groupe afin de les remettrent dans
l'ordre grâce au positionnement de l'offset.
Comme tu le dis, IP est bien en mode non connecté, car si il manque un
fragment, étant donnée qu'il n'y a pas de contrôle à ce niveau, le
fragment
manquant ne sera pas renvoyé.
Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?
J'ai pas compris où tu désirais en venir, car je dirais plutôt :
on provoque la fragmentation grâce au MTU. :)
A mon avis, les 3
fragments vont à la poubelle, je vois mal la machine destinatrice faire
uneremise en ordre (ên s'appuyant sur le numéro d'identification).
Et vous, quel est votre avis ?
A mon avis, la couche IP est là pour s'occuper du réassemblage. Comme tous
les paquets doivent comporter le même ID, la couche Ip pourra facilement
regrouper les fragments dans un même groupe afin de les remettrent dans
l'ordre grâce au positionnement de l'offset.
Comme tu le dis, IP est bien en mode non connecté, car si il manque un
fragment, étant donnée qu'il n'y a pas de contrôle à ce niveau, le
fragment
manquant ne sera pas renvoyé.
Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?
J'ai pas compris où tu désirais en venir, car je dirais plutôt :
on provoque la fragmentation grâce au MTU. :)
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).
Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?
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).
Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?
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).
Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?
Merci Seb de ces éléments,A mon avis, les 3
fragments vont à la poubelle, je vois mal la machine destinatrice faire
uneremise en ordre (ên s'appuyant sur le numéro d'identification).
Et vous, quel est votre avis ?
A mon avis, la couche IP est là pour s'occuper du réassemblage. Comme
tous les paquets doivent comporter le même ID, la couche Ip pourra
facilement regrouper les fragments dans un même groupe afin de les
remettrent dans l'ordre grâce au positionnement de l'offset.
ça paraîtrait logique en effet, mais pour l'instant je n'ai pas encore
trouvé trace de ce mécanisme dans les RFC.
Quelqu'un a une idée de recherche ?
Comme tu le dis, IP est bien en mode non connecté, car si il manque un
fragment, étant donnée qu'il n'y a pas de contrôle à ce niveau, le
fragmentmanquant ne sera pas renvoyé.
En principe, un timer est déclenché au 1er fragment et, s'il en manque un,
le timer claque avec envoi d'une erreur ICMP.
Mais, pour revenir au point précédent, comment le timer pourrait-il se
déclencher si le dernier fragment arrive en premier !!!!Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?
J'ai pas compris où tu désirais en venir, car je dirais plutôt :
on provoque la fragmentation grâce au MTU. :)
Dans les machines traditionnelles(!), il ne devrait pas avoir de
fragmentation IP. Un MTU de valeur 1472 serait remonté à la couche
transport afin que le SDU-IP ne puisse pas être fragmenté pour réussir son
encapsulation entière dans Ethernet.
Cordialement,
Angelot
Merci Seb de ces éléments,
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 ?
A mon avis, la couche IP est là pour s'occuper du réassemblage. Comme
tous les paquets doivent comporter le même ID, la couche Ip pourra
facilement regrouper les fragments dans un même groupe afin de les
remettrent dans l'ordre grâce au positionnement de l'offset.
ça paraîtrait logique en effet, mais pour l'instant je n'ai pas encore
trouvé trace de ce mécanisme dans les RFC.
Quelqu'un a une idée de recherche ?
Comme tu le dis, IP est bien en mode non connecté, car si il manque un
fragment, étant donnée qu'il n'y a pas de contrôle à ce niveau, le
fragment
manquant ne sera pas renvoyé.
En principe, un timer est déclenché au 1er fragment et, s'il en manque un,
le timer claque avec envoi d'une erreur ICMP.
Mais, pour revenir au point précédent, comment le timer pourrait-il se
déclencher si le dernier fragment arrive en premier !!!!
Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?
J'ai pas compris où tu désirais en venir, car je dirais plutôt :
on provoque la fragmentation grâce au MTU. :)
Dans les machines traditionnelles(!), il ne devrait pas avoir de
fragmentation IP. Un MTU de valeur 1472 serait remonté à la couche
transport afin que le SDU-IP ne puisse pas être fragmenté pour réussir son
encapsulation entière dans Ethernet.
Cordialement,
Angelot
Merci Seb de ces éléments,A mon avis, les 3
fragments vont à la poubelle, je vois mal la machine destinatrice faire
uneremise en ordre (ên s'appuyant sur le numéro d'identification).
Et vous, quel est votre avis ?
A mon avis, la couche IP est là pour s'occuper du réassemblage. Comme
tous les paquets doivent comporter le même ID, la couche Ip pourra
facilement regrouper les fragments dans un même groupe afin de les
remettrent dans l'ordre grâce au positionnement de l'offset.
ça paraîtrait logique en effet, mais pour l'instant je n'ai pas encore
trouvé trace de ce mécanisme dans les RFC.
Quelqu'un a une idée de recherche ?
Comme tu le dis, IP est bien en mode non connecté, car si il manque un
fragment, étant donnée qu'il n'y a pas de contrôle à ce niveau, le
fragmentmanquant ne sera pas renvoyé.
En principe, un timer est déclenché au 1er fragment et, s'il en manque un,
le timer claque avec envoi d'une erreur ICMP.
Mais, pour revenir au point précédent, comment le timer pourrait-il se
déclencher si le dernier fragment arrive en premier !!!!Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?
J'ai pas compris où tu désirais en venir, car je dirais plutôt :
on provoque la fragmentation grâce au MTU. :)
Dans les machines traditionnelles(!), il ne devrait pas avoir de
fragmentation IP. Un MTU de valeur 1472 serait remonté à la couche
transport afin que le SDU-IP ne puisse pas être fragmenté pour réussir son
encapsulation entière dans Ethernet.
Cordialement,
Angelot
Ce qui ne va pas en general lorsqu'on dit vulgairement qu'on a un
probleme de MTU c'est qu'un host ip quelque part sur le trajet
source-->destination fait mal son boulot de fragmentation ...
forcement ca coince et c'est de la faute de l'un des maillons traverses,
pas de l'internaute. En effet,si celui ci met par exemple le MTU a 1500
et que l'un des hosts sur le parcours presente un MTU inferieur, il doit
s'en suivre une fragmentation (accompagnee d'une tres legere perte
d'efficacite ) mais aucun blocage ne devrait se produire ... ...
Serait interessant de savoir quels sont les types d'equipement qui
coincent ainsi ...
Ce qui ne va pas en general lorsqu'on dit vulgairement qu'on a un
probleme de MTU c'est qu'un host ip quelque part sur le trajet
source-->destination fait mal son boulot de fragmentation ...
forcement ca coince et c'est de la faute de l'un des maillons traverses,
pas de l'internaute. En effet,si celui ci met par exemple le MTU a 1500
et que l'un des hosts sur le parcours presente un MTU inferieur, il doit
s'en suivre une fragmentation (accompagnee d'une tres legere perte
d'efficacite ) mais aucun blocage ne devrait se produire ... ...
Serait interessant de savoir quels sont les types d'equipement qui
coincent ainsi ...
Ce qui ne va pas en general lorsqu'on dit vulgairement qu'on a un
probleme de MTU c'est qu'un host ip quelque part sur le trajet
source-->destination fait mal son boulot de fragmentation ...
forcement ca coince et c'est de la faute de l'un des maillons traverses,
pas de l'internaute. En effet,si celui ci met par exemple le MTU a 1500
et que l'un des hosts sur le parcours presente un MTU inferieur, il doit
s'en suivre une fragmentation (accompagnee d'une tres legere perte
d'efficacite ) mais aucun blocage ne devrait se produire ... ...
Serait interessant de savoir quels sont les types d'equipement qui
coincent ainsi ...
On Tue, 15 Jun 2004 01:59:01 +0200, Patrick_91
wrote:Ce qui ne va pas en general lorsqu'on dit vulgairement qu'on a un
probleme de MTU c'est qu'un host ip quelque part sur le trajet
source-->destination fait mal son boulot de fragmentation ...
forcement ca coince et c'est de la faute de l'un des maillons traverses,
pas de l'internaute. En effet,si celui ci met par exemple le MTU a 1500
et que l'un des hosts sur le parcours presente un MTU inferieur, il doit
s'en suivre une fragmentation (accompagnee d'une tres legere perte
d'efficacite ) mais aucun blocage ne devrait se produire ... ...
Serait interessant de savoir quels sont les types d'equipement qui
coincent ainsi ...
Le problème ne vient pas en général d'équipements qui ne fragmentent pas
correctement, mais de filtres un peu abusifs qui interdisent tous les
messages ICMP sans restriction, en particulier "need to fragment but DF
bit set". Un firewall devant un serveur web qui filtrerait ces messages
empêche pMTUd de fonctionner, et donc le serveur essaie vainement
d'envoyer des paquets avec sa MTU à lui avec DF à 1, et l'équipement qui
doit fragmenter plus loin sur le chemin essaie vainement de lui dire que
la MTU est plus petite que ce qu'il pense.
Jacques.
On Tue, 15 Jun 2004 01:59:01 +0200, Patrick_91 <patrick_91@nospam.com>
wrote:
Ce qui ne va pas en general lorsqu'on dit vulgairement qu'on a un
probleme de MTU c'est qu'un host ip quelque part sur le trajet
source-->destination fait mal son boulot de fragmentation ...
forcement ca coince et c'est de la faute de l'un des maillons traverses,
pas de l'internaute. En effet,si celui ci met par exemple le MTU a 1500
et que l'un des hosts sur le parcours presente un MTU inferieur, il doit
s'en suivre une fragmentation (accompagnee d'une tres legere perte
d'efficacite ) mais aucun blocage ne devrait se produire ... ...
Serait interessant de savoir quels sont les types d'equipement qui
coincent ainsi ...
Le problème ne vient pas en général d'équipements qui ne fragmentent pas
correctement, mais de filtres un peu abusifs qui interdisent tous les
messages ICMP sans restriction, en particulier "need to fragment but DF
bit set". Un firewall devant un serveur web qui filtrerait ces messages
empêche pMTUd de fonctionner, et donc le serveur essaie vainement
d'envoyer des paquets avec sa MTU à lui avec DF à 1, et l'équipement qui
doit fragmenter plus loin sur le chemin essaie vainement de lui dire que
la MTU est plus petite que ce qu'il pense.
Jacques.
On Tue, 15 Jun 2004 01:59:01 +0200, Patrick_91
wrote:Ce qui ne va pas en general lorsqu'on dit vulgairement qu'on a un
probleme de MTU c'est qu'un host ip quelque part sur le trajet
source-->destination fait mal son boulot de fragmentation ...
forcement ca coince et c'est de la faute de l'un des maillons traverses,
pas de l'internaute. En effet,si celui ci met par exemple le MTU a 1500
et que l'un des hosts sur le parcours presente un MTU inferieur, il doit
s'en suivre une fragmentation (accompagnee d'une tres legere perte
d'efficacite ) mais aucun blocage ne devrait se produire ... ...
Serait interessant de savoir quels sont les types d'equipement qui
coincent ainsi ...
Le problème ne vient pas en général d'équipements qui ne fragmentent pas
correctement, mais de filtres un peu abusifs qui interdisent tous les
messages ICMP sans restriction, en particulier "need to fragment but DF
bit set". Un firewall devant un serveur web qui filtrerait ces messages
empêche pMTUd de fonctionner, et donc le serveur essaie vainement
d'envoyer des paquets avec sa MTU à lui avec DF à 1, et l'équipement qui
doit fragmenter plus loin sur le chemin essaie vainement de lui dire que
la MTU est plus petite que ce qu'il pense.
Jacques.
Si si la mecanique de fragmentation et reassemblage est parfaitement
decrite, voici un link par exemple :
http://www.linktionary.com/f/fragmentation.html
Pourquoi cela ?? le 'MTU' est le (maximum transmission unit) et c'est une
carracteristique de host ip qui n'est a priori pas fixé .
IL est vrai que la valeur 1500 pour les machines équipées de ports
ethernet
semble optimale mais rien n'oblige pour de gros debits a fonctionner sous
ethernet (!!) dans ce cas des valeurs de MTU beaucoup plus importante
seront utilisees.
Si si la mecanique de fragmentation et reassemblage est parfaitement
decrite, voici un link par exemple :
http://www.linktionary.com/f/fragmentation.html
Pourquoi cela ?? le 'MTU' est le (maximum transmission unit) et c'est une
carracteristique de host ip qui n'est a priori pas fixé .
IL est vrai que la valeur 1500 pour les machines équipées de ports
ethernet
semble optimale mais rien n'oblige pour de gros debits a fonctionner sous
ethernet (!!) dans ce cas des valeurs de MTU beaucoup plus importante
seront utilisees.
Si si la mecanique de fragmentation et reassemblage est parfaitement
decrite, voici un link par exemple :
http://www.linktionary.com/f/fragmentation.html
Pourquoi cela ?? le 'MTU' est le (maximum transmission unit) et c'est une
carracteristique de host ip qui n'est a priori pas fixé .
IL est vrai que la valeur 1500 pour les machines équipées de ports
ethernet
semble optimale mais rien n'oblige pour de gros debits a fonctionner sous
ethernet (!!) dans ce cas des valeurs de MTU beaucoup plus importante
seront utilisees.
Et pourtant si, c'est ce que doit faire la machine, d'après la RFC 760
(section 3.2, pages 24 et suivantes).
On peut éviter la fragmentation avec pMTUd (path MTU discovery).
Et pourtant si, c'est ce que doit faire la machine, d'après la RFC 760
(section 3.2, pages 24 et suivantes).
On peut éviter la fragmentation avec pMTUd (path MTU discovery).
Et pourtant si, c'est ce que doit faire la machine, d'après la RFC 760
(section 3.2, pages 24 et suivantes).
On peut éviter la fragmentation avec pMTUd (path MTU discovery).
Sapristi, on peut mettre plus de 1500 octets en charge utile de la
trame MAC !
D'où vous vient cette information ?
Sapristi, on peut mettre plus de 1500 octets en charge utile de la
trame MAC !
D'où vous vient cette information ?
Sapristi, on peut mettre plus de 1500 octets en charge utile de la
trame MAC !
D'où vous vient cette information ?
Bonsoir Patrick,Si si la mecanique de fragmentation et reassemblage est parfaitement
decrite, voici un link par exemple :
http://www.linktionary.com/f/fragmentation.html
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 :
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
Si j'ai bien lu IEEE 802.3 la charge utile d'une trame MAC normale est
comprise entre 46 et 1500 octets, celle d'une trame étiquetée entre 42 et
1500 octets.
Trame MAC normale pour IEE 802.3 absolument ..!
Cordialement,
Angelot
Amicalement
Bonsoir Patrick,
Si si la mecanique de fragmentation et reassemblage est parfaitement
decrite, voici un link par exemple :
http://www.linktionary.com/f/fragmentation.html
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 :
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
Si j'ai bien lu IEEE 802.3 la charge utile d'une trame MAC normale est
comprise entre 46 et 1500 octets, celle d'une trame étiquetée entre 42 et
1500 octets.
Trame MAC normale pour IEE 802.3 absolument ..!
Cordialement,
Angelot
Amicalement
Bonsoir Patrick,Si si la mecanique de fragmentation et reassemblage est parfaitement
decrite, voici un link par exemple :
http://www.linktionary.com/f/fragmentation.html
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 :
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
Si j'ai bien lu IEEE 802.3 la charge utile d'une trame MAC normale est
comprise entre 46 et 1500 octets, celle d'une trame étiquetée entre 42 et
1500 octets.
Trame MAC normale pour IEE 802.3 absolument ..!
Cordialement,
Angelot
Amicalement