Contentons-nous dans un premier temps de démarrer une unique machine virtuelle. $ ./machine.py ↵ Elle n'est reliée à aucun autre équipement et n'a donc aucun moyen physique de communiquer avec autre chose qu'elle même.

Une fois démarrée, cette machine virtuelle propose dans sa fenêtre un terminal permettant à l'administrateur (root) de saisir des commandes.
Commençons par lister les interfaces réseau dont dispose cette machine. [s7crs]~# ip addr ↵ Bien nous ne lui ayons pas explicitement attribué d'interface réseau, nous constatons l'existence d'une unique interface réseau de nom symbolique lo (variable d'un système d'exploitation à l'autre).
Il s'agit d'une interface virtuelle✍ de type loopback et elle est dans l'état actif (UP).

De plus, nous constatons dans l'affichage produit par cette commande que l'interface lo est implicitement configurée avec l'adresse IP et le masque 127.0.0.1/8. L'interface lo est donc censée faire partie d'un sous-réseau dans lequel toutes les adresses IP attribuables commencent par 127., à l'exception de 127.0.0.0 (adresse de sous-réseau) et 127.255.255.255 (adresse de diffusion).
L'adresse 127.0.0.1 qui lui est spécifiquement affectée au sein de ce sous-réseau désigne donc notre machine virtuelle elle-même.
Tentons alors de la joindre avec l'utilitaire ping qui demande au système d'exploitation de notre machine virtuelle d'émettre (à deux reprises seulement ici) un message (ICMP-echo-request) à destination de l'adresse IP en question. [s7crs]~# ping -c2 127.0.0.1 ↵ Un système d'exploitation recevant un tel message doit normalement produire une réponse (ICMP-echo-reply) en retour.
Sans surprise, c'est le cas ici puisque notre machine s'adresse à elle-même.

Bien qu'en apparence seule l'adresse 127.0.0.1 soit attribuée à l'interface lo, vous devriez constater que notre machine répond également à toutes les adresses du sous-réseau 127.0.0.0/8 : de 127.0.0.1 à 127.255.255.254.
Il s'agit justement d'une propriété très particulière de l'interface loopback : puisque rien ne peut être relié physiquement à cette interface, toutes les adresses du sous-réseau semblent lui être attribuées (sauf les deux extrêmes représentant le sous-réseau et la diffusion).
Si vous tentez maintenant de joindre avec ping une adresse IP n'appartenant pas au sous-réseau 127.0.0.0/8, la commande doit vous répondre immédiatement que cette adresse est inaccessible.

L'intérêt de l'interface loopback est de permettre à une machine coupée du réseau de faire dialoguer des logiciels qui en temps normal interagissent à travers le réseau.
Pour le vérifier, démarrons par exemple un serveur TCP simpliste écoutant sur un port arbitraire (1234 par exemple). [s7crs]~# ncat -lp 1234 ↵ En ouvrant un nouveau terminal dans la même machine virtuelle, grâce à la combinaison de touches Alt F2✍ et en utilisant l'identifiant root au login (sans mot de passe), nous pouvons exécuter un client TCP simpliste qui se connecte au serveur précédent. [s7crs]~# ncat 127.0.0.1 1234 ↵ En alternant les combinaisons de touches Alt F1 et Alt F2, vous devriez constater que ce qui est saisi dans l'un est bien retranscrit dans l'autre et inversement (il suffit d'utiliser la combinaison de touches Ctrl C pour arrêter ces programmes).
Nous avons utilisé ici l'outil de mise au point ncat qui permet de vérifier simplement la connectivité entre client et serveur mais d'autres logiciels de communication plus élaborés pourraient tout aussi bien interagir au sein de cette unique machine grâce à l'interface loopback.

Nous cherchons maintenant à donner à nos machines la possibilité de communiquer avec autre chose qu'elles-mêmes.
La machine précédente doit être arrêtée (en fermant simplement sa fenêtre) puisqu'elle ne dispose d'aucune interface réseau autre que loopback.

Avant de démarrer de nouvelles machines, nous devons préparer un nouvel équipement dont le rôle est justement de les interconnecter physiquement✍ : un hub (concentrateur).
Dans le monde physique, un tel équipement permet de rassembler en un même point les câbles issus des cartes réseau physiques des machines afin que les signaux électriques circulent de l'une à l'autre.

Dans le cadre de cette expérimentation nous émulons un hub par un logiciel d'interconnexion sur un port TCP arbitraire (9991 par exemple)✍.
Cette commande doit être exécutée sur un terminal de votre poste de travail $ ./hub_switch.py h:9991 ↵ emulating a hub with port 9991 HubSwitch> et ce terminal doit rester ouvert tant que le hub sera utilisé.
Dès lors, nous pouvons démarrer, depuis un autre terminal, une machine virtuelle (d'identifiant A par exemple) ayant une carte réseau reliée à ce même hub. $ ./machine.py A 9991 ↵ À ce moment, le hub virtuel doit signaler par un message le fait qu'une machine virtuelle vient d'y être connectée.

La liste des interfaces réseau dont dispose cette machine [A]~# ip addr ↵ montre toujours l'interface loopback lo mais présente désormais une nouvelle interface eth0✍ désignant la carte réseau qui est reliée au hub.
En l'état, il apparaît que cette interface est inactive (DOWN).
Pour qu'elle devienne utilisable il est nécessaire de l'activer avec la commande [A]~# ip link set dev eth0 up ↵ Contrôlez alors son nouvel état pour en constater l'effet.

Contrairement à lo, aucune adresse IP n'est implicitement associée à cette nouvelle l'interface.
Ajoutons-lui par exemple l'adresse et le masque 192.168.10.1/24✍ grâce à cette commande [A]~# ip addr add 192.168.10.1/24 dev eth0 ↵ puis contrôlons son nouvel état pour en constater l'effet.

Tout comme avec l'interface lo, notre machine doit être capable de communiquer avec elle-même en utilisant l'adresse de l'interface eth0.
Vérifiez que c'est bien le cas, avec les outils ping et ncat, comme nous l'avons fait à l'étape précédente, mais en utilisant cette fois-ci l'adresse 192.168.10.1.

Essayez de joindre avec ping une adresse IP non attribuée qui fasse partie du sous-réseau 192.168.10.0/24 (192.168.10.2 par exemple) et une autre adresse IP qui n'en fasse pas partie (192.168.20.1 par exemple). Bien que ces commandes échouent toutes les deux, vous devez observer un comportement différent pour chacune d'elles :

Démarrons une nouvelle machine virtuelle (d'identifiant B par exemple) reliée au hub virtuel 9991 précédent afin d'être en mesure d'interagir avec la machine virtuelle A précédente. $ ./machine.py B 9991 ↵ Son interface eth0 doit être activée et configurée avec l'adresse IP et le masque 192.168.10.2/24.

Vérifiez que la connectivité est bien assurée entre les machines A et B. [A]~# ping -c2 192.168.10.2 ↵ [B]~# ping -c2 192.168.10.1 ↵ Vérifiez également qu'une paire de serveur/client TCP simplistes peuvent effectivement interagir entre ces deux machines✍. [A]~# ncat -lp 1234 ↵ [B]~# ncat 192.168.10.1 1234 ↵

Complétez ce sous-réseau en lui ajoutant de la même façon une troisième machine virtuelle (d'identifiant C par exemple) dont l'interface eth0 sera configurée avec 192.168.10.3/24.
Le sous-réseau simulé par nos quatre équipements virtuels interconnectés correspond désormais à ce schéma :

Vérifiez avec ping que toutes les connectivités sont autorisées entre cette machine et les deux précédentes.

Toutes les interfaces d'un même sous-réseau peuvent être atteintes simultanément par un unique message émis par l'une d'elles sur l'adresse IP de diffusion.
En théorie l'outil ping devrait permettre de le constater mais, pour des raisons de sécurité, les systèmes d'exploitation l'interdisent désormais.
Pour constater malgré tout l'effet de la diffusion, nous utiliserons sur deux machines (A et B par exemple) une commande servant à afficher un message UDP reçu sur un port choisi arbitrairement (1234 par exemple) [A, B]~# ncat -ulp 1234 ↵ (il faudra l'arrêter avec la combinaison de touche Ctrl C dès la réception du premier message).
Depuis la troisième machine (C par exemple) nous diffuserons un message à destination du même port UDP. [C]~# echo "hi there" | ncat -u 192.168.10.255 1234 ↵ Bien que l'adresse IP visée par cet envoi ne corresponde à aucune de celles que nous avons attribuées à nos machines, nous constatons que toutes reçoivent le message✍. Cette adresse particulière ne peut en effet être attribuée à aucune interface puisqu'il s'agit de l'adresse IP de diffusion✍.

Assurez-vous, avec quelques commandes ping si nécessaire, du fait que vos trois machines se sont contactées mutuellement depuis peu.
Ensuite, sur chacune d'elles, visualisez l'état des interfaces et de leurs tables ARP (Address Resolution Protocol).
[A, B, C]~# ip addr ↵ [A, B, C]~# ip neigh ↵ La table ARP d'une machine sert à associer des adresses IP à des adresses MAC (Medium Access Control).
Les adresses MAC sont reconnaissables à leur forme xx:xx:xx:xx:xx:xx (six octets usuellement exprimés et hexadécimal).
Contrairement aux adresses IP, les adresses MAC ne sont normalement pas attribuées explicitement par configuration✍ ; elles sont au contraire attribuées à la production de la carte réseau par son fabriquant✍.
Observez avec attention les adresses MAC et IP affichées par les commandes précédentes.
Vous devriez constater que :

En effet, bien que nous ne nous soyons intéressés uniquement aux adresses IP pour expérimenter les communications précédentes, celles-ci reposent fondamentalement sur une couche de communication inférieure (la couche 2-liaison du modèle OSI, ou la couche liens du modèle DoD-TCP/IP).
Seulement, à aucun moment dans la configuration des interfaces réseau de chacune de nos trois machines nous n'avons donné d'information sur les deux autres ; la table ARP de chacune d'elles a donc été renseignée automatiquement.

Cherchons alors à mettre en évidence le mécanisme ARP.
Tout d'abord nous forçons chacune des trois machines à oublier le contenu de leur table ARP✍. [A, B, C]~# ip neigh flush dev eth0 ↵ Visualisez à nouveau les tables ARP des trois machines pour constater qu'elles ont bien été vidées.
Depuis une machine (B par exemple) nous allons écouter le trafic au sein du sous-réseau relié à son interface eth0 pendant que les deux autres communiquent.
[B]~# tcpdump -eni eth0 ↵ La communication entre les deux autres machines pourra se contenter de ping (de A vers C par exemple). [A]~# ping -c2 192.168.10.3 ↵

Nous voyons alors défiler sur la machine B une succession de représentations symboliques des trames réseau qui ont été capturées par tcpdump✍.
Chacune commence par un horodatage, la paire d'adresses MAC source et destination de la trame, et contient ensuite une description du contenu de cette trame.
Nous voyons apparaître, dans l'ordre : Une observation attentive des trames précédentes doit mettre en évidence le fait qu'une requête ARP ne se contente pas de poser une question ; elle informe également sur l'association IP/MAC de l'émetteur.
En effet, la réponse ICMP-echo-reply de C vers A a bien eu lieu (avec la bonne adresse MAC de destination) alors que la machine C n'a elle-même provoqué aucune requête ARP à propos de A !
Lorsque la requête ARP diffusée par A a été prise en compte par C, cette dernière, en plus de répondre, à mis sa jour sa table ARP à propos de A✍, ce qui lui permet de répondre immédiatement dès l'arrivée d'une sollicitation depuis A.
Une nouvelle consultation des tables ARP des machines A et C montre bien que :

À travers cette expérimentation, nous venons de mettre en évidence le principe de fonctionnement du protocole ARP qui rend les adresses IP effectivement utilisables :

Pour effectuer l'expérimentation précédente, nous avons eu recours à l'outil tcpdump afin d'écouter toutes les trames qui parvenaient à l'interface eth0 de la machine B.
Bien que le trafic entre les machines A et C ne concerne absolument pas B, cette dernière est tout de même atteinte par toutes les trames relayées par le hub.
C'est justement ce qui caractérise un équipement de type hub : il répète systématiquement sur tous ses autres ports (ses prises) ce qu'il reçoit sur l'un deux.
Un hub est un équipement de niveau 1-Physique dans le modèle OSI : il ne sait retransmettre qu'un signal physique sans accorder de signification à la trame décrite par ce signal.

Ce comportement est très satisfaisant en ce qui concerne, comme ici, la mise au point et l'expérimentation✍, mais n'est pas idéal en terme de performances.
En effet, si un hub relie de nombreuses machines, ou si plusieurs hubs sont reliés entre-eux, dès que l'une d'elle émet une trame, elle mobilise tous les brins (les câbles) du sous-réseau.
Cela risque d'engendrer des collisions et un ralentissement du trafic : chaque carte réseau doit attendre qu'aucune autre n'émette au sein du sous-réseau pour émettre à son tour !

Depuis de nombreuses années maintenant les hubs ont laissé place✍ aux switches (commutateurs).
Le switch est un équipement de niveau 2-Liaison dans le modèle OSI : il sait interpréter les adresses MAC des trames qu'il relaie.
Son principal intérêt repose sur le fait qu'il ne retransmet une trame que sur le brin du sous-réseau qui est supposé aboutir à l'adresse MAC destinataire.
De nombreuses collisions sont ainsi évitées, ce qui fluidifie le trafic et permet de garder de bonnes performances même lorsque de nombreux équipements sont reliés à un ou plusieurs switches.

Pour en constater l'effet, intervenons sur l'outil qui émule le hub 9991 afin de le transformer en switch. HubSwitch> switch 9991 ↵ emulating a switch with port 9991 Cette modification affecte le comportement du hub existant sans le détruire.
Vous pouvez vérifier avec la commande HubSwitch> list ↵ que les trois machines virtuelles sont toujours reliées au switch, il n'est donc pas nécessaire de les arrêter et les relancer.

Si, comme dans l'expérimentation précédente, vous utilisez à nouveau tcpdump sur l'interface eth0 de B pendant que ping provoque des échanges entre A et C, vous devriez constater que rien ne parvient plus à B.
En effet, la commande HubSwitch> list ↵ montre que le switch a connaissance des adresses MAC des machines qu'il relie ; il se sert de cette information pour choisir sur quel port (prise) retransmettre une trame.

Seulement, à aucun moment nous n'avons explicitement fourni ces adresses au switch ; il les a découvertes par ses propres moyens.
Pour mettre en évidence ce phénomène, forçons tout d'abord le switch à oublier ces adresses. HubSwitch> flush ↵ avant de relancer l'expérimentation avec tcpdump sur B et ping entre A et C.
Cette fois-ci, une seule trame atteint B : il s'agit du tout premier message ICMP-echo-request de A vers C :

Dans cette section, nous avons mis en évidence l'importance de l'adresse MAC de diffusion pour le fonctionnement du protocole ARP.
Après avoir forcé nos trois machine à oublier le contenu de leur table ARP [A, B, C]~# ip neigh flush dev eth0 ↵ reprenons encore l'expérience avec tcpdump et ping.
À nouveau, nous ne voyons qu'une seule trame être capturée sur la machine B ; nous constatons qu'il s'agit de la diffusion de la requête ARP-who-has.
En effet, par essence, une trame diffusée est supposée atteindre toutes les interfaces du sous-réseau (du “domaine de diffusion”) ; tout comme le hub, le switch la retransmet sur tous ses ports.