Introduction réseaux et web : TP
Initiation aux réseaux, deuxième séance
Ce document est soumis auCopyright © présent sur cette page.
Copyright © présent sur cette page.
Tous les TP se font en environnement Unix.
Vous devez redémarrer votre machine de la salle de TP sous Unix si elle est sous Windows.
Lors du précédent TP, vous avez mis en place une architecture capable d'illustrer les échanges entre un client Web et un serveur Web. Dans ce TP, l'objectif est d'observer les échanges quand le client fait des requêtes vers le serveur et interpréter leur contenu. Il s'agit d'illustrer les cours 5, 6, 7 et 8.
Vous devrez :HTTP, requêtes/réponses DNS, ouverture/fermeture des connexions TCP, en-têtes TCP/UDP/IP/Ethernet, requêtes/réponses ICMP, requêtes/réponses ARP, et le NAT.La figure ci-dessous représente l'architecture que vous avez mise en place au TP précédent et que vous devez remettre en état de fonctionnement.
Pour visualiser les échanges qui passent dans le réseau, vous utiliserez l'application wireshark qui permet de capturer les trames qui passent sur un lien du réseau.
Pour faire ce TP, vous allez utiliser l'émulateur réseau gns3. Ce logiciel n'est disponible que dans les salles TP du bâtiment Nautibus.
Vous ne pourrez donc pas faire le TP chez vous ou dans les autres salles informatiques du campus.
La plupart des questions posées dans les sujets de TP sont suivies d'une Aide.
Avant de faire une question, il faut lire l'Aide qui suit la question.
Tout au long du TP, notez les réponses aux questions dans un fichier texte pour garder une trace de vos réponses et permettre à votre enseignant de vérifier votre travail.
Dans cette partie vous devez remettre en état de fonctionnement la topologie ci-dessus conformément à ce que vous aviez fait lors du TP précédent.
Pour remettre en place la configuration du TP précédent, suivez les instructions que vous avez reçues par courrier électronique.
Vérifiez que ping 100.1.1.1 fonctionne depuis les machines CLIENT et DNS. Si tel n'est pas le cas, vous devez chercher l'erreur jusqu'à ce que cela fonctionne. Parfois, l'erreur vient du fait qu'en créant les liens vous n'avez pas respecté le nom des interfaces indiqué sur la figure de la topologie. Si tel est le cas, supprimez le lien qui pose problème et re-créez un lien avec les bonnes interfaces.
nginx
Vous avez à votre disposition des machines capables de jouer les rôles de Client ou Serveur DNS/Web. Par défaut, les serveurs ne sont pas démarrés. Commençons par démarrer le serveur Web.
Dans un terminal de SERVEUR, tapez la commande sudo nginx pour démarrer le serveur Web.
A présent, vous devriez être en mesure d'envoyer des requêtes HTTP au SERVEUR à partir du CLIENT et d'obtenir une réponse.
Sur CLIENT, lancez Firefox en cliquant sur l'icône du bureau et tapez l'adresse IP du SERVEUR http://100.1.1.1/ dans la barre d'adresse.
Si tout s'est bien passé, vous devriez à présent visualiser une page web avec deux images. Si cela ne fonctionne pas, vérifiez que nginx est bien lancé (commande ps -A),
et que la connectivité entre les machines est opérationnelle (avec ping).
HTTP avec wireshark
Pour visualiser le contenu des requêtes/réponses HTTP, vous allez intercepter les échanges qui ont lieu dans le réseau entre le CLIENT et le SERVEUR à l'aide de l'outil wireshark. Cette application permet de capturer tous les signaux qui passent dans une carte réseau et d'interpréter puis d'afficher chaque octet des messages transportés.
Ces messages contiennent non seulement les données de l'application qui utilise Internet mais aussi tous les en-têtes ajoutés par les protocoles qui permettent que tout fonctionne. Par exemple, lorsqu'un navigateur web demande une page à un serveur web, il utilise le protocole HTTP. La requête HTTP fabriquée par le navigateur web va être complétée de l'en-tête TCP qui permet d'assurer la fiabilité du transfert, de l'en-tête IP qui permet d'acheminer le message jusqu'à son destinataire et de l'en-tête/en-queue Ethernet qui permet au signal d'aller d'une carte réseau à la suivante. Vous allez visualiser cette encapsulation en utilisant wireshark.
Pour lancer wireshark, effectuez un clic droit sur le lien entre le CLIENT et la Box puis sélectionnez Start capture dans le menu déroulant affiché.
Dans la fenêtre qui s'ouvre, cliquez sur OK. Une nouvelle fenêtre s'ouvre. Ne fermez plus cette fenêtre jusqu'à la fin du TP.
wireshark s'ouvre alors et vous devriez rapidement voir s'afficher toutes les trames qui passent par la carte réseau FastEthernet0/0 de la Box.
HTTPA présent, vous allez accéder à une page web contenant un compteur utilisant des requêtes GET, identique à celui du CM4 (page 59).
Sur la machine CLIENT, ouvrez la page http://100.1.1.1/3-compteur-get.php dans Firefox.
Dans wireshark, tapez http dans la zone de texte juste en dessous de la barre d'outils, en haut de la fenêtre, puis validez. Cela permet de filtrer l'affichage en n'affichant que les trames qui encapsulent le protocole HTTP. En principe, deux trames subsistent suite à l'application du filtre.
Quelles sont les adresses IP source et destination des trames qui s'affichent ?
Quelle trame contient la requête HTTP du client ? La réponse du serveur ?
Cliquez sur la première trame et observez son contenu dans la partie centrale de la fenêtre qui affiche les en-têtes de la trame. Cliquez sur l'en-tête HTTP. S'agit-il d'une requête de type GET ou POST ?
Copiez la commande HTTP dans votre fichier de réponses. Vous en aurez besoin ultérieurement.
La commande contenue dans une requête HTTP est aussi visible dans la colonne Info de la liste des trames interceptées par wireshark.
Pour afficher plus de détails sur la requête HTTP, cliquez dessus. Dans la fenêtre qui s'ouvre, développez la section Hypertext Transfer Protocol afin de voir tout le contenu de la requête et répondez aux questions suivantes :
Quelle est la version du navigateur de CLIENT ?
Quel langage est accepté par le navigateur ?
La connexion avec le serveur est-elle fermée après la requête ou maintenue active ? Pourquoi ?
De même, affichez les détails de la réponse HTTP et répondez aux questions suivantes :
Quel est le code de statut de la réponse ?
Quelle est la version du serveur nginx lancé sur le SERVEUR ? Celle de PHP ?
Quel type de données le SERVEUR renvoie-t-il au CLIENT ?
Recherchez le contenu de la réponse HTTP et copiez-le dans votre fichier de réponses.
Le corps de la réponse HTTP est, dans cet exemple, le code HTML de la page qu'elle contient. Plus généralement, il peut s'agir de n'importe quel type de données qu'un serveur envoie à un client : fichier texte, image, MP3, vidéo, archive...
TCP, IP et Ethernet
Avant de répondre aux questions ci-dessous, consultez le CM8, en particulier le format des en-têtes TCP, IP et Ethernet.
Cliquez sur l'en-tête TCP de la requête HTTP pour dévoiler son contenu. Quel est le numéro de port utilisé par le navigateur web ? Cliquez dessus pour voir où il se situe dans la trame. Quelle est la valeur des octets sélectionnés visibles dans le bas de la fenêtre affichant tous les octets transportés par la trame ? Sachant que les octets sont affichés en hexadécimal, vérifiez que la valeur décimale du numéro de port est correcte. Quel est le numéro de port destinataire ? A quoi correspond t-il ?
Cliquez sur l'en-tête IP de la requête HTTP pour dévoiler son contenu. Quelle est la valeur de l'adresse IP source en hexadécimal ? Quelle est la taille de l'en-tête (Header Length) ? Quelle est la taille du paquet IP (Total Length) ? La fragmentation est-elle active ? Combien de sauts reste-t-il avant la destruction du paquet (Time to live) ?
Cliquez sur l'en-tête Ethernet de la requête HTTP pour dévoiler son contenu. Quelle est la valeur du champ Type ? A quoi cela correspond t-il ? Quelle est l'adresse MAC source ? A quoi cela correspond t-il ? Quelle est sa taille ? Vérifiez que l'adresse MAC est correcte en tapant la commande ip addr show dev eth0 dans le terminal du CLIENT.
GET et POST
Vous allez maintenant observer comment les données d'un formulaire sont envoyées au serveur web.
Actionnez le bouton +1 dans le navigateur de CLIENT pour incrémenter le compteur. Observez l'URL dans la barre d'adresse du navigateur. Que constatez-vous ?
Repérez dans wireshark le nouveau jeu de requête/réponse généré. Notez leurs numéros de paquets.
Trouvez, à l'aide de wireshark, la partie de la requête qui contient les informations transmises au serveur lors de la soumission du formulaire. Copiez la ligne commande de la requête GET dans votre fichier de réponses. Vous en aurez besoin ultérieurement. Incrémenter encore le compteur et copiez de nouveau la ligne commande de la requête GET.
La valeur du compteur avant incrémentation est stockée dans un champ caché du formulaire. Pour le voir, affichez le code source de la page dans le navigateur.
Vous allez refaire ces observations avec le compteur qui utilise la méthode POST plutôt que la méthode GET.
Ouvrez la page http://100.1.1.1/3-compteur-post.php dans le navigateur du CLIENT.
Il s'agit du même formulaire que précédemment sauf que les données soumises en cliquant sur +1 ne sont plus visibles directement dans l'URL.
Cliquez sur le bouton +1 dans le navigateur de CLIENT pour incrémenter le compteur.
Repérez dans wireshark le nouveau jeu de requête/réponse généré. Notez leurs numéros de paquets.
Trouvez, à l'aide de wireshark, où se trouvent les données en provenance du formulaire. Combien de champs sont transmis ? A quoi correspondent Key et Value pour chaque champ ? Quelle est la valeur du champ Content-Length de l'en-tête HTTP ?
telnet
Le programme telnet permet d'établir une connexion vers n'importe quel serveur. Une fois connecté au serveur, l'utilisateur peut alors envoyer des requêtes au serveur à condition de respecter le format imposé par le protocole applicatif.
Vous allez utiliser l'application telnet pour récupérer le contenu de la page 3-compteur-get.php hébergée par le serveur Web. Pour cela, il faut se connecter au port 80 utilisé par le serveur Web.
Ouvrez un terminal de CLIENT, et tapez la commande telnet 100.1.1.1 80 pour vous connecter au SERVEUR sur le port 80 du serveur Web.
Demandez la page 3-compteur-get.php en copiant depuis votre fichier de réponses la commande GET que vous aviez trouvée avec wireshark dans une question précédente. Pour vous aider, regardez la diapo 59 du CM4. La différence est que, dans ce TP, vous faites une requête en HTTP/1.1 au lieu de HTTP/1.0 ce qui impose d'ajouter l'en-tête host comme indiqué ci-après.
Appuyez sur ENTREE. Rien ne se passe pour l'instant car la requête n'est pas complète. En effet, il manque l'en-tête host indiquant quel serveur doit répondre à la requête. Ajoutez l'en-tête host: 100.1.1.1 dans le terminal. Appuyez deux fois sur ENTREE pour clôturer la requête.
Le contenu de la réponse du SERVEUR s'affiche alors sous forme de texte brut dans le terminal.
Comparez le corps de la réponse obtenue via telnet à celui de la réponse que vous aviez copié précédemment dans votre fichier de réponses.
Que constatez-vous ?
Dans wireshark, comparez la taille de la requête HTTP méthode GET envoyée par Firefox à celle envoyée par telnet (colonne Length).
Que constatez-vous ? Expliquez !
Vous allez maintenant suivre la même procédure pour envoyer les données du formulaire avec la méthode POST via telnet.
Utilisez telnet pour demander au serveur Web la page 3-compteur-post.php. Pour cela, vous devez copier/coller depuis votre fichier réponses, la requête en méthode POST capturée précédemment avec wireshark. Pour vous aider, regardez la diapo 60 du CM4. Après l'en-tête host, il faut bien préciser l'en-tête Content-Type et l'en-tête Content-Length Est-ce que la réponse qui s'affiche dans le terminal montre bien l'incrémentation du compteur ? Testez à nouveau en modifiant la valeur du compteur transmise dans la requête.
DNS avec wireshark
Jusqu'à présent, pour toutes les requêtes HTTP envoyées au SERVEUR Web, vous avez utilisé son adresse IP soit dans l'URL soit en argument de la commande telnet. Cependant, il est rare de connaître l'adresse IP du serveur. Généralement, on utilise le nom du serveur plutôt que son adresse IP pour le contacter. Néanmoins, la machine cliente doit obtenir l'adresse IP du serveur pour lui envoyer sa requête.
La correspondance nom_de_machine/adresse_ip est connue des serveurs DNS. Un client doit donc envoyer une requête à un serveur DNS pour récupérer l'adresse IP du serveur et ce, avant de pouvoir envoyer sa requête au serveur dont il connaît le nom mais pas l'adresse IP. Le serveur DNS interrogé peut soit connaître la réponse (adresse IP du serveur) soit faire suivre la requête DNS à d'autres serveurs DNS jusqu'à atteindre celui qui détient la réponse. Dans ce TP, pour simplifier, il y a un seul serveur DNS qui stocke tous les enregistrements nécessaires au TP.
Pour répondre aux questions de cette partie, relisez les diapositives du cours qui concernent le DNS dans le CM5.
En fait, notre SERVEUR Web 100.1.1.1 dispose bel et bien d'un nom : lifasr2.univ-lyon1.fr
Modifiez le filtre dans wireshark en http || dns pour n'afficher que les trames contenant des messages HTTP ou DNS.
Dans Firefox, sur la machine CLIENT, essayez de vous connecter à lifasr2.univ-lyon1.fr. Que constatez-vous ? Une activité réseau est-elle visible dans wireshark ?
La commande host permet de faire des résolutions de nom et donc d'interroger les serveurs DNS depuis un terminal.
Exécutez la commande host -a lifasr2.univ-lyon1.fr dans le terminal du CLIENT. Que se passe-t-il ?
Le comportement constaté est normal : pour l'instant, la machine CLIENT n' a pas de serveur DNS à disposition donc les résolutions de nom ne peuvent pas se faire.
DNS et démarrage du serveur
Sur la machine CLIENT, il faut indiquer quelle est l'adresse IP du serveur DNS (8.8.8.7) à qui les requêtes DNS vont être envoyées. Cela se configure dans le fichier /etc/resolv.conf de CLIENT.
Ouvrez le fichier /etc/resolv.conf de CLIENT en mode super-utilisateur (sudo), à l'aide d'un éditeur de texte : vim ou leafpad. Par exemple, tapez la commande sudo leafpad /etc/resolv.conf Pour renseigner un serveur DNS, il faut ajouter dans ce fichier la ligne nameserver [adresse IP de serveur DNS]. Y a-t-il déjà un serveur DNS renseigné ?
Sous les deux premières lignes de commentaires du fichier, ajoutez la ligne nameserver 8.8.8.7 et enregistrez vos modifications.
Sur la machine DNS, exécutez la commande sudo /etc/init.d/bind9 start pour démarrer le serveur DNS.
DNS
Utilisez à nouveau la commande host -a lifasr2.univ-lyon1.fr pour vous assurer que le serveur de noms fonctionne correctement. Obtenez-vous bien l'adresse du SERVEUR Web (100.1.1.1) en réponse ?
Essayez à nouveau de vous connecter à lifasr2.univ-lyon1.fr dans Firefox. Cela fonctionne-t-il ?
Dans wireshark, repérez les messages DNS échangés entre le CLIENT et le serveur DNS avant l'envoi de la requête HTTP à lifasr2.univ-lyon1.fr Notez leurs numéros de paquet.
Quels sont les numéros des ports source et destination utilisés dans la requête DNS ? Quel est le protocole de transport utilisé pour les messages DNS ?
Dans la colonne Info, repérez les "paquets DNS" dont la description contient lifasr2.univ-lyon1.fr Seules les requêtes de type A nous intéressent car elles concernent les adresses IPv4. Les requêtes de type AAAA concernent IPv6, nous les ignorerons pour ce TP.
DNS
Regardez l'échange de requête/réponse DNS en détail pour répondre aux questions suivantes.
Quelle section de la requête (et de la réponse) DNS contient la question posée par le CLIENT au serveur de noms DNS ?
Quelle section de la réponse DNS contient l'adresse IP recherchée ? Que contient la section AUTHORITY NAMESERVERS de la réponse ? Et la section ADDITIONAL RECORDS ?
Combien de temps le CLIENT a-t-il le droit de conserver cette réponse en cache, avant de demander une mise à jour au serveur de noms DNS ?
Recherchez le champ Time To Live qui se trouve dans la section Domain Name System -> Answers de la réponse DNS.
Le fichier /etc/bind/named.conf.local est le fichier de configuration du serveur DNS. Observez le contenu de ce fichier sur la machine DNS. Quel est le nom du fichier de la zone hébergée par ce serveur ? Affichez le contenu de ce fichier. Que contient t-il ?
Quelle option de la commande host permet d'afficher les correspondances DNS pour toutes machines de la zone DNS ? Utilisez cette commande et comparez la réponse au contenu du fichier de la zone vu précédemment. Que concluez-vous ?
Pour trouver l'option de la commande host, vous pouvez regarder la diapo 66 du CM5 ou utiliser la commande man host.
Aidez-vous des commandes suivantes pour répondre aux questions ci-dessous :
host -a univ-lyon1.fr host -a -l univ-lyon1.fr host ssh.univ-lyon1.fr host smtp.univ-lyon1.fr ssh ssh.univ-lyon1.frQuels sont les noms et adresses des serveurs DNS de la zone
univ-lyon1.fr ? A quel nom et quelle adresse sont envoyés les mails à destination de prenom.nom@univ-lyon1.fr ? Sur quel port destination et sur quelle adresse IP destination se fait la connexion à distance avec la commande ssh ssh.univ-lyon1.fr ? Pour confirmer votre réponse, observez-le dans wireshark.
UDP et TCP
Avant de répondre aux questions ci-dessous, consultez les diapositives du CM6 qui présentent les protocoles UDP et TCP. Ces deux protocoles sont appelés les protocoles de transport d'Internet. Leur premier rôle est d'identifier l'application qui communique sur Internet grâce aux numéros de port. C'est pourquoi l'en-tête UDP et l'en-tête TCP contiennent le numéro de port source et le numéro de port destinataire.
Une application utilise soit TCP soit UDP mais pas les deux. Le rôle de TCP est de faire la fiabilité c'est à dire de garantir que tout ce qui arrive au destinataire est exactement ce qu'il y avait sur l'émetteur avant envoi. La plupart des applications d'Internet utilise TCP car elles ont besoin de la fiabilité. UDP ne fait que l'identification de l'application grâce aux numéros de port. Il est plus rapide que TCP mais ne garantit pas la fiabilité du transport.
UDPParmi les protocoles applicatifs vus précédemment, lequel utilise UDP ? Pourquoi ?
Sur combien d'octets est codé un numéro de port ? Quelle est la valeur maximale d'un numéro de port en décimal ? Comment sont choisis les ports des serveurs ? Quelle est leur valeur maximale ? Comment sont choisis les ports des clients ? Quelle est leur valeur minimale ?
Regardez dans wireshark quel est le port source de la dernière requête DNS. Notez-le dans votre fichier réponses. Utiliser la commande host sur la machine CLIENT pour faire une nouvelle requête DNS. Quel est le port source utilisé par la commande host ? Est-ce le même que précédemment ? Commentez !
Dans le terminal de la machine CLIENT, exécutez la commande wget http://lifasr2.univ-lyon1.fr/index.html Quelles sont les nouvelles trames qui s'affichent dans wireshark ? Quels sont les ports source des nouvelles requêtes ? Commentez ! Que fait la commande wget ?
TCP
Pour faire la fiabilité, le protocole TCP a besoin du mode connecté. Parmi les protocoles vus en cours, c'est le seul protocole d'Internet qui est en mode connecté. Dans le mode connecté, le client fait une demande d'ouverture de connexion que le serveur accepte ou non. Après l'ouverture, les échanges sont possibles jusqu'à ce que l'une des parties demande la fermeture de la connexion. Cela fonctionne comme le téléphone !
Modifiez le filtre d'affichage wireshark en tcp pour n'afficher que les trames qui contiennent ce protocole. Cliquez sur le bouton
Dans le terminal de la machine CLIENT, exécutez la commande wget http://lifasr2.univ-lyon1.fr/img2.jpeg Regardez avec wireshark comment se passe l'ouverture de la connexion TCP. Combien de trames sont échangées pour faire l'ouverture de connexion ? Quels sont les Flags de l'en-tête TCP qui sont mis à 1 pour chacune de ces trames ?
Observez maintenant avec wireshark la fermeture de la connexion TCP juste après la réponse du serveur. Combien de trames ont été échangées pour faire la fermeture de la connexion ? Quels sont les Flags de l'en-tête TCP qui sont mis à 1 pour chacune de ces trames ? Est-ce le client ou le serveur qui a demandé la fermeture ?
Pour faire la fiabilité, TCP numérote les messages envoyés et utilise des acquittements (ACK) pour informer l'émetteur de la bonne réception des données. La numérotation des messages permet de garantir l'ordre à la réception et de détecter les données manquantes.
Observez avec wireshark l'en-tête TCP des trames qui vont du serveur vers le client et qui constituent la réponse HTTP. En effet, l'image étant volumineuse, elle est transmise en plusieurs morceaux dans plusieurs trames. Dans les trames qui vont du serveur vers le client, comment évolue Sequence number qui compte les octets envoyés ? Dans les trames qui vont du client vers le serveur, comment évolue Acknowledgment number qui compte les octets reçus ? Observez la trame allant du client vers le serveur et qui sert de dernier acquittement des données avant la phase de fermeture de la connexion. Quelle est la taille du paquet IP contenu dans cette trame ? Contient t-il des données venant du navigateur ou du serveur ? Commentez !
Vous allez maintenant observer que plusieurs requêtes HTTP sont nécessaires pour afficher la page index.html du serveur web comme cela est expliqué dans la diapositive 30 du CM4. En effet, le navigateur web doit faire une nouvelle requête HTTP pour chaque objet incorporé dans la page.
Supprimez le cache de Firefox dans CLIENT, pour vous assurer de récupérer tous les contenus de la page auprès de SERVER :
dans le terminal du CLIENT, tapez rm -Rf .cache/mozilla
Ouvrez http://lifasr2.univ-lyon1.fr dans le navigateur.
Combien de requêtes HTTP ont été effectuées par le navigateur ? Quel objet est demandé dans chacune des requêtes ? Combien d'ouverture/fermeture de connexion TCP ont eu lieu ? Une seule pour tous les objets ou bien une pour chaque objet ? Qui décide de fermer la connexion TCP ?
NAT et le protocole ARP
NAT : remplacer une adresse IP privée par l'adresse publique du routeur
La machine CLIENT utilise une adresse IP privée (192.168.0.1) pour communiquer avec la Box. Les adresses privées ne sont pas utilisables pour aller sur Internet. La Box doit donc remplacer l'adresse privée du CLIENT par son adresse publique 12.25.0.1 dès lors qu'un paquet traverse la Box pour aller sur Internet. Ce mécanisme s'appelle le NAT (Network Address Translation) et a été configuré sur la Box. Vous allez maintenant l'observer avec wireshark.
Sans fermer la fenêtre wireshark ouverte, retournez dans GNS3, cliquez droit sur le lien entre la Box et FAI-CLIENT, choisissez Start capture et sélectionnez Box port Serial1/0 (Cisco HDLC...) pour capturer les trames qui partent ou arrivent d'Internet.
Utilisez par exemple le filtre icmp dans les deux fenêtres wireshark et tapez ping lifasr2.univ-lyon1.fr depuis un terminal de la machine CLIENT. Comparez les adresses IP sources des requêtes ICMP dans le réseau local (interface FastEthernet de la Box) et sur Internet (interface Serial de la Box). Vérifiez que l'adresse IP source sur Internet est bien celle de la Box.
ARP
Le protocole ARP est présenté dans le CM8. Il permet, au sein d'un sous-réseau, de récupérer l'adresse physique ou adresse MAC de la carte réseau du destinataire lorsque l'on connaît son adresse IP. L'adresse MAC du destinataire est nécessaire pour envoyer une trame d'une carte réseau à une autre carte réseau. La requête ARP envoie une trame de diffusion à toutes les machines du réseau pour demander par exemple "Qui a l'adresse IP 192.168.0.254 ?". La machine qui a cette adresse IP répond en envoyant la réponse ARP qui contient l'adresse MAC de la carte réseau qui a cette adresse IP. Vous allez observer cela avec wireshark.
Dans les deux fenêtres wireshark, appliquez le filtre arp || icmp pour n'afficher que les trames contenant ces deux protocoles.
Dans le terminal de la machine CLIENT, exécutez la commande arp qui affiche la table arp de la machine. Si une entrée est présente, exécutez arp -d 192.168.0.254 qui supprime l'entrée correspondante. Exécutez à nouveau arp. Que constatez-vous ?
Exécutez maintenant ping -c 1 100.1.1.1 Observez les trames capturées sur l'interface Box FastEthernet0/0 et répondez aux questions ci-dessous :
A quelle adresse IP est envoyée la requête ICMP ?
A quelle adresse MAC destination est envoyée la requête ARP ? Que désigne cette adresse ?
Quelle est l'adresse IP contenue dans la requête ARP ? Pourquoi n'est-ce pas celle du serveur Web ?
Qui répond à la requête ARP ? Quelle est son adresse MAC ?
Quelle est la taille d'une requête/réponse ARP ? Pour le savoir, cliquez sur Adresse Resolution Protocol (request) dans la partie centrale de la fenêtre et comptez les octets affichés en surbrillance en bas de la fenêtre. Quelle est la taille de la trame Ethernet qui encapsule la requête ARP ? Y a t-il du bourrage dans la trame et si oui combien d'octets ? Pour le savoir, il faut compter les octets qui sont dans la trame Ethernet à la suite de la requête ARP. Quelle est la valeur du champ Type d'une trame Ethernet qui contient un paquet ARP ? Même question pour une trame Ethernet contenant un paquet IP ?