Discussion :

[elhanche]

Bonjour,




Exercice 3 : Un datagramme IP contenant 2048 octets de données est émis sur un réseau A de MTU=4096. 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 ci-dessous :

Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : ????????
Identification : 12345
Drapeau : 010
Décalage fragment : 0


1. Complétez le champ en-tête ci-dessus.
2. Quelle sera la structure de l'en-tête des datagrammes dans les réseaux B.
3. Pourquoi le réassemblage de paquets IP n'est-il réalisé que par le destinataire final et pas par un noeud intermédiaire ?

[Invité]

Salut,

je t'invite à consulter cet article :

http://www.cisco.com/en/US/tech/tk82...800d6979.shtml

Ensuite, il manque une donnée critique dans l'énoncé de cet article. Sauras-tu trouver laquelle ?

Steph

[elhanche]

il ya un tableu de datagramme ou il ne donne de trouvé la longueur total

la longueur total = data + Longueur d'en-tête



donc je met 2048 + 20 octet = 2068 octet mais un ami ma dit que la longueur total est egal 2048 et que L’en tête IP compte 20 octets, la quantité des données à transmettre est donc 2048 – 20 = 2028 octets.

est ce que tu peux m'éclairer, merci

[Invité]

RFC791 :

Total Length: 16 bits Total Length is the length of the datagram, measured in octets, including internet header and data.

donc si on veut envoyer un datagramme IP de 2048 octets de données pures, il faudra l'encapsuler dans un paquet qui contiendra lesdites données plus l'en-tête.

D'où longueur totale du paquet : 2068B.

Steph

[elhanche]

merci pour me repondre, mon probleme c'est que l'exercice nous donne un MTU superieur que la données

et que le cours dit: Lorsqu'il doit émettre un datagramme sur un réseau dont le MTU est inférieur à la taille du datagramme, il doit fragmenter le datagramme.


donc pour moi qu'il ce que je dois faire a ce niveau la

Un datagramme IP contenant 2048 octets de données est émis sur un réseau A de MTU=4096. En passant par un routeur R1, il atteint le réseau B de MTU=1024 octets.


Quelle sera la structure de l'en-tête des datagrammes dans les réseaux B.


merci encore une fois

[Invité]

L'article que je t'ai donné en référence détaille la fragmentation d'un datagramme IP de longueur totale 5140B qui doit transiter dans un réseau de MTU 1500B.

Ton exercice consiste à fragmenter un datagramme IP de longueur totale 2068B qui doit transiter dans un réseau de MTU 1024B... C'est du copier/coller en changeant les valeurs

Si tu sais faire des divisions et que tu connais ta table de 8, ça devrait prendre 10 mn. Un singe stupide muni d'une calculatrice y arriverait

Si je te donne la réponse, je suis le seul à bosser sur ce coup-là
Si t'essaies, oui, je veux bien t'aider.

Steph

[elhanche]

merci beaucoup Monsieur
voila ma reponce :

http://www.developpez.net/forums/att...1&d=1338117736


donc je fait se que tu ma demander

merci encore une fois

[Invité]

Avant d'entrer dans le détail d'IP Frag, il faut bien comprendre que les données pures IP sont encapsulées et qu'il faudra toujours trainer ces 20B supplémentaires de header lors du forwarding. Si l'interface de sortie offre un IP MTU de 1024B, ça signifie qu'on pourra envoyer 1024-20=1004B de data. Pourquoi avoir limité tes paquets à 1000B ?

Voici comment se déroule l'algorithme IP Frag.

1) Le routeur reçoit le paquet IP et isole le champ data par décapsulation : 2068B - 20B = 2048B.

2) Le routeur calcule le mombre de paquets nécessaires pour fragmenter le paquet original :

nbre de pkts = ENT(2048/1004)+1 = 3 pkts

3) Le routeur réserve ses buffers :

pkt1 = 1004B data + 20B header
pkt2 = 1004B data + 20B header
pkt3 = 40B data + 20B header

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

4) Le routeur construit ensuite les headers des 3 paquets. Voyons comment sont renseignés les champs.

* longueur totale
Cf 3)

* 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_pkt1 = MF_pkt2 = 1 et MF_pkt3 = 0)

d'où drapeau_pkt1 = 001
drapeau_pkt2 = 001
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)

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

En conclusion,

pkt1
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : 1024
Identification : 12345
Drapeau : 001
Décalage fragment : 0

pkt2
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : 1024
Identification : 12345
Drapeau : 001
Décalage fragment : 123

pkt3
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : 60
Identification : 12345
Drapeau : 000
Décalage fragment : 246

Steph

[gangsoleil]

Bonjour,

Ensuite, il manque une donnée critique dans l'énoncé de cet article. Sauras-tu trouver laquelle ?

Pour mon information, quelle est la donnee critique manquante ? Je vois bien quelques trucs de ci de la qui permettraient de preciser l'enonce, mais rien de critique.
Peux-tu eclairer ma lanterne ?

[gangsoleil]

La structure du datagramme dans le réseau A est présentée ci-dessous :

Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : ????????
Identification : 12345
Drapeau : 010
Décalage fragment : 0

* drapeau (3 bits)
- le 1er bit n'est pas utilisé et toujours égal à 0
- le DF bit
- le MF (More Fragment)

Est-ce que la presence du DF bit n'est pas genante ?

[Invité]

Est-ce que la presence du DF bit n'est pas genante ?

Yes !!!!

En théorie, le routeur va dropper le paquet reçu en émettant un ICMP Type 3 Code 4 (Destination Unreachable, Fragmentation needed and DF set) vers l'IP source qui émet un tel paquet en précisant la valeur de MTU attendue. C'est alors la source qui va fragmenter le paquet original et non plus le routeur. C'est le principe de base du Path MTU Discovery (PMTUD, RFC1191): forcer la fragmentation à la source parce que c'est intensif pour les routeurs en terme de buffers et cycles CPU.

A noter que s'il y a un firewall qui bloque le traffic ICMP entre la source et la destination, l'IP source qui a émis le paquet ne recevra jamais le Type 3 Code 4 ! Donc le paquet n'arrivera jamais à destination parce que la station émettrice ne saura jamais qu'elle doit fragmenter, elle fera des 'retries' avec le même paquet. C'est un problème connu sous le nom de "PMTUD Black Hole".

La seule façon de contourner ce problème est :
- soit de forcer les hosts à émettre des paquets avec le DF à 0,
- soit de demander aux routeurs de réécrire le DF.

Steph

[gangsoleil]

Est-ce que la presence du DF bit n'est pas genante ?

Yes !!!!

Oui oui, ca, les ICMP, je connais bien. Trop bien meme.

D'ailleurs, le meme exo en IPv6 aurait ete encore plus drole (vu qu'il n'y a pas de DF bit, puisque la norme impose que la fragmentation se fasse a la source. Donc ICMP PTB obligatoire, et tout le tralala).

[Invité]

D'ailleurs, le meme exo en IPv6 aurait ete encore plus drole (vu qu'il n'y a pas de DF bit, puisque la norme impose que la fragmentation se fasse a la source.

Oui, IPv6 s'est débarrassé d'une des misères d'IPv4

Et pour compléter ma note...

Par défaut Linux envoie ses paquets IP avec le DF 0, c'est configurable dans /proc/sys/net/ipv4/ip_no_pmtu_disc (donc par défaut Linux "n'écoute pas" les ICMP T3 C4).

Concernant Windows, le réglage se fait au travers de confreg et je crois que les valeurs par défaut ont changé selon les versions.

Les PMTUD Black Holes apparaissent souvent lors de déploiements de protocoles qui encapsulent les paquets IP. Exemple typique que j'ai vécu il y a quelques temps lors de la mise en place de tunnels IPSec eux-même encapsulés dans des tunnels GRE. Les encapsulations successives IPSec+GRE ajoutaient jusqu'à 82B au datagramme original... Les options de 'ping' et 'traceroute' sur le DF bit permettent de mettre en évidence les points de routage qui posent problème (et ce sont très souvent les firewalls qui bloquent les ICMP).

Bien...

Pour faire le closing sur cette discussion, il reste la question 3 posée par elhanche

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

Comme j'avais suggéré, l'IP Frag est intensive pour les routeurs.

Le réassemblage est encore plus "challenging". En effet, si le routeur devait réassembler les fragments, il devrait buffériser jusqu'à ce qu'il reçoive le dernier fragment qui possède le bit MF 0. Ce serait donc la folie pour gérer les buffers de façon dynamique. Sans parler du problème de la perte d'un des fragments... Ce serait du grand gsapillage de ressources. On laisse donc cette taĉhe aux stations.

Voilà

Steph

[gangsoleil]

Des travaux de recherche sont en cours sur ICMP : http://hal.inria.fr/hal-00695746

[Invité]

Oui, bel article qui redonne ses lettres de noblesse à ICMP qui est d'une richesse insoupçonnée...

Quand j'interviens sur de grosses archis IP pour des problèmes de perf/routing, j'analyse toutes sortes de stats ICMP. Et dans beaucoup de cas, ça ma donné des pistes prometteuses à explorer pour shooter les problèmes. Ce "background traffic" est un très bon indicateur de la solidité des couches 3/4 dans un réseau...

Steph

[ram-0000]

Le réassemblage est encore plus "challenging". En effet, si le routeur devait réassembler les fragments, il devrait buffériser jusqu'à ce qu'il reçoive le dernier fragment qui possède le bit MF 0. Ce serait donc la folie pour gérer les buffers de façon dynamique. Sans parler du problème de la perte d'un des fragments... Ce serait du grand gsapillage de ressources. On laisse donc cette taĉhe aux stations.

Et puis si un des routeurs sur la route ré-assemblait et que sur le routeur après, il faut refragmenter, quel gâchis de ressources. Autant le faire à la fin (par la destination) quand on est sûr que le paquet ne sera plus refragmenté

[raniyakn]

Avant d'entrer dans le détail d'IP Frag, il faut bien comprendre que les données pures IP sont encapsulées et qu'il faudra toujours trainer ces 20B supplémentaires de header lors du forwarding. Si l'interface de sortie offre un IP MTU de 1024B, ça signifie qu'on pourra envoyer 1024-20=1004B de data. Pourquoi avoir limité tes paquets à 1000B ?

Voici comment se déroule l'algorithme IP Frag.

1) Le routeur reçoit le paquet IP et isole le champ data par décapsulation : 2068B - 20B = 2048B.

2) Le routeur calcule le mombre de paquets nécessaires pour fragmenter le paquet original :

nbre de pkts = ENT(2048/1004)+1 = 3 pkts

3) Le routeur réserve ses buffers :

pkt1 = 1004B data + 20B header
pkt2 = 1004B data + 20B header
pkt3 = 40B data + 20B header

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

4) Le routeur construit ensuite les headers des 3 paquets. Voyons comment sont renseignés les champs.

* longueur totale
Cf 3)

* 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_pkt1 = MF_pkt2 = 1 et MF_pkt3 = 0)

d'où drapeau_pkt1 = 001
drapeau_pkt2 = 001
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)

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

En conclusion,

pkt1
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : 1024
Identification : 12345
Drapeau : 001
Décalage fragment : 0

pkt2
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : 1024
Identification : 12345
Drapeau : 001
Décalage fragment : 123

pkt3
Version : 4
Longueur d'en-tête : 5
Type de service : 0
Longueur totale : 60
Identification : 12345
Drapeau : 000
Décalage fragment : 246

Steph

Slaut,
pourquoi 1024-20=1004B ? c'est le 20 octet ? est ce que toujours en fait -20 ?

[Invité]

Slaut,
pourquoi 1024-20=1004B ? c'est le 20 octet ? est ce que toujours en fait -20 ?

Bonne question. Dans l'exemple que j'ai donné, j'ai pris le cas usuel. L'algorithme est en effet un peu plus compliqué...

En fait, lorsque le routeur a décapsulé la trame datalink pour en extraire le paquet IP, il y a un test qui est fait sur la valeur IHL (Internet Header Length) de l'en-tête.
L'IHL est codé sur 4 bits, et donne la longueur de l'en-tête en multiple de mots 32 bits.
La valeur maximale théorique est donc 15 x 32 = 480 bits = 60 octets et dans ce cas, c'est parce qu'il y a des options (par exemple pour l'IP Source Routing). Les options sont alors dupliquées dans chacun des fragments, partiellement ou entièrement (de mémoire, il y a quelques subtilités en fonctions des cas, je ne me rappelle plus des micro-détails).

Steph