Datagramme : fragmentation. [Résolu]

[Stoicien]

Bonjour à tous, je viens solliciter votre aide concernant un blocage à mon niveau.

Voici l'énoncée:

Un datagramme IP contenant 3028 octets de données est émis sur un réseau A de MTU=500. En passant par un routeur R1, il atteint le réseau B de MTU=1024 octets. La structure du datagramme dans le réseau A est présentée cidessous :
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : ????????
Identification : 1234
Drapeau : 010
Décalage fragment : 0
Durée de vie : 32

Proposition de solution:

Si l'interface de sortie offre un IP MTU de 1024 B, cela signifie qu'on pourra envoyer :
1024-20=1004 B de data.

Voici comment se déroule la fragmentation :

a- Le routeur reçoit le paquet IP et isole le champ data par décapsulation :
3048 B – 20 B = 3028 B.

b- Le routeur calcule le nombre de paquets nécessaires pour fragmenter le paquet original :

nombre de paquets = ENT(3028/1004)+1 = 4 paquets

c- Le routeur réserve ses buffers :
Paquet 1= 1004 B data + 20 B header
Paquet 2= 1004 B data + 20 B header
Paquet 3= 1004 B data + 20 B header
Paquet 4= 16 B data + 20 B header

Aider moi à comprendre cette partie s'il vous plait.
Peut on emmètre 1004 octets à partir de MTU= 500 ?

[IP_Steph]

Salut,

ce que je comprends de l'énoncé, c'est qu'il faut fragmenter un paquet IP de longueur 3028B afin de l'envoyer sur un réseau de MTU IP 500B (le réseau A). Le réseau B étant de MTU supérieur à celui de A, les paquets seront routés sans modification... Donc je ne vois pas ce que le routeur vient faire dans l'énoncé. Ca aurait été plus simple de poser la question sous la forme : un PC doit envoyer un paquet IP de 3028B sur un réseau de MTU 500B, donner le détail de l'IP Frag.

Ou bien...

C'est une erreur d'énoncé, le réseau A est de MTU 1024B et le réseau B de MTU 500B. Auquel cas, tu dois donner le détail de l'IP Frag 3028B -> réseau MTU 1024B puis l'IP Frag faite par le routeur pour passer les paquets dans le réseau B...

En revanche, avec un drapeau à 010, le routeur va dropper les paquets qui demandent à être fragmentés...

Steph

[ram-0000]

Envoyé par IP_Steph

Ou bien...

C'est une erreur d'énoncé...

Ou une autre solution, la personne qui a fait l'énoncé a oublié que les routeurs intermédiaires ne ré-assemblaient pas les paquets. C'est la destination et uniquement la destination qui ré-assemble.

[gangsoleil]

Envoyé par Stoicien

Peut on emmètre 1004 octets à partir de MTU= 500 ?

Non.

L'emetteur va emettre des paquets avec le plus petit MTU connu : soit celui du lien auquel il est branche, soit celui de la route s'il utilise des algorithmes de PMTUD (Path MTU Discovery). Dans ton cas, c'est 500.

Pour moi, le piege de l'enonce est justement ici : on te fait reflechir plein sur la suite, alors que la contrainte est au debut. Et comme l'ont dit justement les autres posteurs, un routeur ne re-assemble pas. Donc hop, paquets de 500, ca passe partout, et destinataire qui reassemble.

[Stoicien]

Voici comment je l'ai résolu dans ce cas:

a- Le routeur calcule le nombre de paquets nécessaires pour fragmenter le paquet original :

nombre de paquets = ENT(3028/ 480)+1 = 7 paquets

b- Le routeur réserve ses buffers :

Paquet 1= 480 B data + 20 B header
Paquet 2= 480 B data + 20 B header
Paquet 3= 480 B data + 20 B header
Paquet 4= 480 B data + 20 B header
Paquet 5= 480 B data + 20 B header
Paquet 6= 480 B data + 20 B header
Paquet 7= 148 B data + 20 B header

On retrouve bien les 3028 B de data IP du paquet original en utilisant au maximum l'IP MTU de l'input interface.

c- Le routeur construit ensuite les headers des 3 paquets. Voyons comment sont renseignés les champs.
* longueur totale
Paquet 1= 480 B data + 20 B header
Paquet 2= 480 B data + 20 B header
Paquet 3= 480 B data + 20 B header
Paquet 4= 480 B data + 20 B header
Paquet 5= 480 B data + 20 B header
Paquet 6= 480 B data + 20 B header
Paquet 7= 148 B data + 20 B header

* drapeau (3 bits)
- le 1er bit n'est pas utilisé et toujours égal à 0
- le DF bit est toujours mis à 0 dans le cadre d'une IP Frag
- le MF (More Fragment) bit est mis à 1 sur tous les fragments hormis le dernier.
Donc :
MF(Paquet 1) = MF(Paquet 2) = MF(Paquet 3)= MF(Paquet 4) = MF(Paquet 5) = 1 ;
MF(Paquet 6) = 1 et MF(Paquet 7) = 0.
D'où :
drapeau(Paquet 1) = drapeau(Paquet 2) = drapeau(Paquet 3) = drapeau(Paquet 4) =001 ;
drapeau(Paquet 5) = drapeau(Paquet 6) = 001 et drapeau(Paquet 7) = 000.
drapeau_pkt3 = 000
* offset/décalage
L'offset permet à la machine destinataire de reconstituer le datagramme original. Exprimé en multiple de 8B, c'est un pointeur qui indique la position du fragment dans le datagramme original. Voici le détail des offsets :

offset_pkt1 = 0 (octets 1 à 1004 du datagramme original)
offset_pkt2 = 1004/8 = 123 (octets 1005 à 2008 du datagramme original)
offset_pkt3 = 2008/8 = 246 (octets 2009 à 2048 du datagramme original)

offset(Paquet 1) = 0 (1 octet à 480 octets du datagramme original)
offset(Paquet 2)= 480/8=60 (octets 481 à 960 du datagramme original)
offset(Paquet 3)= 960/8=120 (octets 961 à 1440 du datagramme original)
offset(Paquet 4)= 1440/8 =180 (octets 1441 à 1920 du datagramme original)
offset(Paquet 5)=1920/8=240 (octets 1921 à 2400 du datagramme original)
offset(Paquet 6)=2400/8=300 (octets 2401 à 2880 du datagramme original)
offset(Paquet 7)=2880/8=360 (octets 2881 à 3028 du datagramme original)


* identification
Tous les fragments construits possèdent l'identifiant du paquet original.
En conclusion,

Paquet 1
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : 500
Identification : 1234
Drapeau : 001
Décalage fragment : 0

Paquet 2
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : 500
Identification : 1234
Drapeau : 001
Décalage fragment : 60

Paquet 3
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : 500
Identification : 1234
Drapeau : 001
Décalage fragment : 120

Paquet 4
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : 500
Identification : 1234
Drapeau : 001
Décalage fragment : 180

Paquet 5
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : 500
Identification : 1234
Drapeau : 001
Décalage fragment : 240



Paquet 6
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : 500
Identification : 1234
Drapeau : 001
Décalage fragment : 300

Paquet 7
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : 500
Identification : 1234
Drapeau : 000
Décalage fragment : 360


Est-ce normal ?

Cordialement,

[IP_Steph]

Oui, ça a l'air correct !

Hormis que dans ce cas de figure, c'est la station émettrice qui fragmente le datagramme original de 3028B, ça n'est pas le routeur...

Finalement, la station émet ses 7 paquets, qui seront routés sans problème par le routeur puisque le MTU du réseau B est supérieur à celui du réseau A.

Steph

[Stoicien]

Cependant, il ya une derniere question qui m'embête un peu.

Etant donné que la fragmentation a lieu ici dans le routeur A,
pourquoi cette cdernière question:

3. Pourquoi le ré-assemblage de paquets IP n'est-il réalisé que par le
destinataire final et pas par un nTmud intermédiaire ?

[IP_Steph]

Etant donné que la fragmentation a lieu ici dans le routeur A

Non !

Encore une fois, les calculs que tu as faits s'appliquent à une station connectée à un réseau de MTU 500B voulant envoyer un datagramme IP de 3028B. Le stack IP de la station effectue donc la fragmentation en 7 paquets, la station envoie les 7 paquets sur réseau, et les 7 paquets sont par la suite "forwardés" par le routeur dans le réseau B.

Pourquoi le ré-assemblage de paquets IP n'est-il réalisé que par le
destinataire final et pas par un nTmud intermédiaire ?

Parce que chaque noeud intermédiaire n'a aucune connaissance des différents MTU le long d'un chemin. Donc si un routeur intermédiaire réassemblait les paquets IP, il y aurait des chances que le datagramme soit à nouveau fragmenté lorsqu'il doit passer au travers d'un lien de faible MTU. Au final, entre la source et la destination du datagramme, on aurait de multiples fragmentation/réassemblage pour expédier le datagramme...

D'autre part, ce serait extrêmement intensif pour le routeur. Et surtout gourmand en mémoire/buffer. En effet, lorsque le routeur recevrait le premier fragment, il serait obligé de buffériser tous les fragments IP jusqu'à ce que le but MF soit nul. Il n'y a aucune information dans l'en-tête IP qui renseigne sur le nombre de fragments, il faudrait donc allouer la taille maximale (64kB) d'un datagramme IP dès que le réassemblage se déclenche.

Steph

[Stoicien]

Bonsoir à tous, je vous remercie tous pour votre aide et soutien.

Je remercie particulièrement ram-0000, et les Modérateurs gangsoleil et IP_Steph pour leur inlassable soutien.

Cordialement,

[ram-0000]

Envoyé par Stoicien

Je remercie particulièrement ram-0000, et les Modérateurs gangsoleil et IP_Steph pour leur inlassable soutien.

Les remerciements nominatifs étant particulièrement rares en ces temps de crise, je te remercie de cette attention (du moins pour mon cas).

[gangsoleil]

Envoyé par Stoicien

Je remercie particulièrement ram-0000, et les Modérateurs gangsoleil et IP_Steph pour leur inlassable soutien.

Je te remercie aussi de cette attention. Pour information, avant d'etre moderateur, nous sommes surtout des utilisateurs du forum .

Ravi d'avoir pu t'aider.

[IP_Steph]

Envoyé par Stoicien

Je remercie particulièrement ram-0000, et les Modérateurs gangsoleil et IP_Steph pour leur inlassable soutien.

Oui, merci pour ces bons mots, ça fait toujours plaisir

Steph