Discussion :

[tomateSalade]

Bonjour, je suis en pleine révision et j'ai plusieurs questions à poser. Dès fois la question ne sera pas directement écrite mais j'aimerais savoir si la logique est la bonne.

Sous un même réseau (domaine de diffusion), j'envoie une requête de ICMP 'ping' (couche 3 ip/paquet): hote1 (port 0 côté switch L2) vers hote4 (port 3 côté switch L2). La requête passe par un switch L2 (commutateur).
Quand l'hôte envoie une requête ICMP, il envoie un 'paquet' dans lequel se situe aussi une 'trame' encapsuler à l'intérieur.

La requête ICMP est de couche 3 (IP) et à ce niveau on communique à partir des adresses IP (hors connexion). Le switch L2 étant un équipement de niveau 2, il ne comprend pas l'adresse IP de la requête ICMP. Mais comme celle-ci est de niveau 3, elle va fournir la trame qui comporte les adresses MAC au switch L2. A partir de là, il compare sa table MAC avec l'@MAC source et de destination

Sa table d'adressage (Couche 2/trame, MAC: medium access control) est vide, donc il rajoute ligne 1 port 0 l'@ MAC Source de hote1.
A partir de là, le switch L2 génère lui même une requête en Broadcast car il ne connait pas l'@MAC de destination contenu dans la trame.

Cette requête de type Broadcast est de type x806 ARP (couche 2-3. est-ce considéré comme un paquet ? une trame ? un mis-paquet mis-trame ?). Elle est distincte de la table MAC qui se trouve sur le switch L2 et ne se trouve uniquement qu'en local sur les différents hôtes en fonction de leurs besoins et/ou sur un routeur et/ou switch L3 (commutateur + switch L2). A la fin de l'échange entre host1 et host3, il y aura : TABLE ARP host1 ligne1 @IP host2 et @MAC host2 et host2 ligne1 @IP host1 et @MAC host1.

Quand cette opération de broadcast se termine et que les tables ARP CACHE sont remplies, on a accès ensuite depuis l'unique hôte concerné Hôte3, sa réponse vers le switch L2 : ICMP pour répondre à l'hôte1 et une trame d'encapsuler pour remplir la table MAC du switch L2. Celui-ci complète sa table MAC: Ligne1 Port1 @MAC1 Port3 @MAC3

C'est bien cela qui se passe ?

[becket]

Non, ce n'est pas le switch qui génère le broadcast, c'est le client

[tomateSalade]

Non, ce n'est pas le switch qui génère le broadcast, c'est le client

Salut, donc comment cela se passe ? Le client envoie une requête ICMP et celle-ci est intercepté par le switch. Comme celui ne connait pas l'@MAC, il prévient le client source pour que celui-ci vérifie dans sa tâble ARP ? Si elle est vide, le client renvoi une requête arp ? j'aimerais bien connaître l'ordre dans tous cela stp.

edit: A moins que l'hôte regarde toujours sa table ARP avant de faire quoi que ce soit. Et qu'il envoie un ARP si sa tâble est vide avant ou en même temps que l'ICMP ?

edit2: En analysant plus:
Un paquet ICMP pour être envoyée a besoin de l'IP du destinateur mais aussi du service de la couche d'en dessous pour avoir l'@MAC du destinateur.
Quand j'encapsule (Haut vers Bas) mon paquet dans une trame, il me faut l'@MAC destinateur.
L'hôte regarde dans son cache ARP. Si c'est vide, il envoie une requête ARP broadcast au switch qui se charge de la diffuser.
Le switch ne ne génère pas de requête ARP, c'est le rôle de l'hôte.

edit3:
Dernière version:
Sous un même réseau (domaine de diffusion), j'envoie une requête de ICMP 'ping' (couche 3 ip/paquet): hote1 (port 0 côté switch L2) vers hote4 (port 3 côté switch L2).
Un paquet ICMP pour être envoyée a besoin de l'IP du destinateur mais aussi du service de la couche d'en dessous pour avoir l'@MAC du destinateur.
Quand j'encapsule (Haut vers Bas) mon paquet dans une trame, il me faut l'@MAC destinateur.
L'hôte regarde dans son cache ARP. Si c'est vide, il met en pause la requête ICMP et envoie une requête ARP broadcast au switch qui se charge de la diffuser. Par contre, si l'hôte a la correspondance @MAC et @IP, il envoie directement le paquet ICMP.
Le switch ne génère pas de requête ARP, c'est le rôle de l'hôte.

Cette requête ARP 806 Broadcast (couche 2-3) est distincte de la table MAC qui se trouve sur le switch L2 et ne se trouve uniquement qu'en local sur les différents hôtes en fonction de leurs besoins et/ou sur un routeur et/ou switch L3 (commutateur + switch L2). A la fin de l'échange ARP entre host1 et host3, il y aura :
TABLE ARP
host1 ligne1 @IP host2 @MAC host2 (cache ARP hôte1)
host2 ligne1 @IP host1 et @MAC host1 (cache ARP hôte4)

Par la même occasion, la table MAC du switch s'est remplie avec l'aller-retours de la requête ARP:
Ligne 1 port0 l'@ MAC Source de hote1 (aller)
Ligne1 Port0 @MAC1 Port3 @MAC3, (retour)
Maintenant, on débloque la requête ICMP qui passe par un switch L2 (commutateur) au niveau du port (domaine de collision).
Quand l'hôte envoie une requête ICMP, il envoie un 'paquet' dans lequel se situe aussi une 'trame' encapsuler à l'intérieur qui contient maintenant l'@MAC de destination.

La requête ICMP est de couche 3 (IP) et à ce niveau on communique à partir des adresses IP (hors connexion). Le switch L2 étant un équipement de niveau 2, il ne comprend pas l'adresse IP de la requête ICMP. Mais comme celle-ci est de niveau 3, elle va fournir la trame qui comporte les adresses MAC au switch L2. A partir de là, le switch compare sa table MAC avec l'@MAC source et de destination

Sa table d'adressage (Couche 2/trame, MAC: medium access control) est à jours.
A partir de là, le switch L2 retransmet uniquement et directement le paquet à l'hôte concerné (hote4).

[Invité]

Salut,

j'ai lu en diagonale, il y a quelques incompréhensions...

Voyons comment se passe la cinématique des flux d'un 'ping'.

Hypothèses
- hôte 1 sur port1 du switch, il possède la MAC@ Mac1 et son IP est IP1
- hôte 2 sur port2 du switch associé à Mac2, IP2
- IP1 et IP2 sont des adresses appartenant au même sous-réseau


1er cas : hôte 1 connait la MAC adresse de hôte 2, voilà la cinématique
La couche IP de hôte 1 forge l'ICMP correspondant (source IP1, destination IP2). Hôte 1 encapsule le paquet IP dans une trame Ethernet (source Mac1, destination Mac2).
Hôte 2 reçoit la trame Ethernet, extrait le paquet IP encapsulé puis forge l'ICMP Reply (source IP2, destination IP1). Il encapsule l'ICMP dans une trame Ethernet (source Mac2, destination Mac1).

2ème cas : hôte 1 ne connait pas la MAC adresse de hôte 2
Alors Hôte 1 forge un ARP Request pour obtenir Mac2 (source IP1, destination IP2) mais lorsque hôte 1 encapsule le paquet dans une trame Ethernet, il mettra Mac1 en source et le full broadcast en destination (ff:ff:ff:ff:ff:ff) de telle façon que toutes les stations puissent intercepter l'ARP Request.
Hôte 2 reçoit l'ARP Request, voit que c'est son adresse qui est demandée et répond à Hôte 1.
Hôte 1 connait alors la MAC adresse de hôte 2, et on se retrouve dans le 1er cas.


Maintenant, concernant le switch...
Il y a plusieurs choses à savoir...

a) Un switch peuple sa table de MAC adresses (forwarding database, ou FDB) "au fil de l'eau".
b) Lorsqu'une trame Ethernet arrive sur un de ses ports et qu'il ne sait pas où se trouve la MAC adresse destination, il va dupliquer la trame en mémoire et l'envoyer sur tous ses ports (cette opération s'appelle le flooding). Puisque la trame est envoyée partout, la destination va répondre et le switch créera une entrée dans sa FDB.
c) Lorsqu'une entrée MAC est créée dans la FDB, un timer est amorcé (il s'appelle l'ageing time) et si le switch n'a pas entendu causer ladite MAC adress avant l'échéance du timer, l'entrée est effacée.

J'espère que ça clarifie !

-VX

[becket]

Merci d'avoir pris le temps d'une explication plus complète que la mienne