Récemment une personne m’a posé la question sur laquelle il n’a pas su répondre pendant un examen blanc du CCNA.
La question ressemblait à celle-ci :
Une personne vient vous voir car elle n’arrive pas à surfer sur Internet, impossible d’aller même sur Google.com !
Vous accompagnez cette personne devant son ordinateur et vous regardez sa configuration IP via l’ouverture d’une fenêtre DOS et de la commande « ipconfig /all »
Cette commande sort les informations suivantes :
On regardant bien, la carte réseau a bien une adresse IP, un masque, une passerelle… tout semble normal.
Faisons un peu de troubleshooting (investigation) ensemble 🙂
Alors ce ne sont ici qu’une proposition de tests par rapport au problème de notre ami, bien sur on peut appréhender le problème de différentes manières, je dirais chacun a sa façon de cuisiner, idem pour le troubleshooting.
Test de la pile TCP/IP localement
Avant de savoir si on peut joindre l’autre coté de la planète, testons si la pile TCP/IP locale à l’ordinateur est opérationnelle.
Faisons un PING vers sa propre adresse IP. Si celle-ci répond alors la pile TCP/IP est opérationnelle, si ce n’est pas le cas alors on a un souci avec l’ordinateur : carte réseau morte, driver à relancer, redémarrage PC…
Allez c’est parti : ping 192.168.0.102
Ça fonctionne ! Si ça ne fonctionnait pas, il aurait fallu désactiver la carte réseau puis la réactiver pour relancer la pile TCP/IP et retester.
Test de sa passerelle
Maintenant que la pile TCP/IP est OK, testons si on peut joindre sa passerelle par défaut, celle-ci qui nous permet de sortir vers Internet.
Avec un simple « ipconfig » je récupère l’adresse IP de la passerelle : c’est la 192.168.0.1
C’est parti : ping 192.168.0.1
Ça fonctionne aussi ! Ah ça commence à se corser là car en ouvrant Internet Explorer (ou Firefox/Chrome/Safari…), toujours impossible de surfer…
On pourrait même aller plus loin et faire un ping d’une adresse publique se trouvant sur Internet comme l’adresse 8.8.8.8 qui est très facile à retenir et que j’utilise souvent pour faire des tests de connectivité.
On sait désormais que cet ordinateur fonctionne correctement, la couche réseau est validée de bout en bout donc ce n’est pas/plus un problème réseau.
Réfléchissons un peu… que nous faut-il pour surfer sur Internet ?
- une adresse IP –> ok
- une passerelle pour sortir –> ok
- et ?
Mais oui j’ai trouvé ! Lorsque je tape http://www.google.com , il faut bien que le browser fasse une conversion entre cette URL et l’adresse IP correspondante. Il manque donc la résolution de nom, le fameux serveur DNS !
Et en faisant un « ipconfig /all » on ne voit pas de serveur DNS configuré !!
Test de la résolution de nom
Testons en utilisant la commande « nslookup » : dans la fenêtre DOS je tape « nslookup www.google.com »
Et voila, on a trouvé notre problème : l’ordinateur n’a pas de serveur DNS configuré donc impossible de résoudre les URL dans les browsers.
Apres avoir configuré l’adresse du serveur DNS, la résolution des noms fonctionnera et lorsque l’utilisateur ira sur google.com ou sur cisco.com… ou sur reussisonccna.fr 🙂 ça fonctionnera parfaitement.
Conclusion sur le CCNA
N’oubliez pas que les questions du CCNA sont là pour mettre à contribution votre esprit critique et d’analyse. Et c’est typiquement le genre d’analyse que vous devez faire dans votre esprit car vous n’avez pas accès à la fenêtre DOS pour faire des tests. Regardez bien toutes les données de la question :
- impossible de surfer sur internet
- il a bien une adresse IP
- une passerelle
- le masque est cohérent
- …
Qu’est ce qu’il peut bien manquer ? A vous de jouer !
Bonjour Cyrill. Je suis du Québec Canada. Je suis entrain de suivre une formation CCNA dans un Cégep. On est rendu vers la fin du module un le chapitre 9 et il reste deux chapitre à faire Or. En faisant une recherche. J’ai trouvé ton site. Très bien fait et de très bonne information pour réussir notre certification ccna et de l’aide. Or j’ai lu que tu était entrain d’écrire des fiche d’aide mémoire sur ccna. Les avez-vous publié. Car je ne les ai pas trouvé. Ils sont peut-être pas terminé. Cependant si certain des chapitre ou module son terminé. Si tu peux les envoyé. Car beaucoup de difficulté avec le subnetting. Merci pour le super boulot que vous offrez.
Bonjour Jonathan,
A ce jour, mars 2014, je n’ai pas fini les fiches résumé mais j’espère les finir bientôt. De toute façon, ce sera publie directement sur ce site.
Bonsoir Cyril,
Ce problème de DNS est quand même un peu bizarre. Le host dont tu fourni l’ipconfig /all montre qu’il est configuré en DHCP.
Un serveur DHCP fournit normalement l’adresse IP d’un ou de plusieurs serveurs DNS.
Alors à une telle question je répondrai : « Insulte l’admin de ton entreprise qui te fournit un bail foireux ! »
Mais dans le genre des questions piège j’avoue que celle là est parfaite !
Bonjour Romuald,
En effet la carte est configurée en DHCP et « normalement » le DHCP fournit l’adresse du serveur DNS sauf si… cette option n’est pas configurée 🙂
Oui c’est une question piège comme Cisco les aimes
Bonjour Cyril.
Je ne sais pas si cela fait parti du CCNA, mais j’ai une petite question :
Quelle est la différence entre le rpvst et le spanning-tree uplinkfast ?
J’avoue ne pas savoir quoi activier sur mes switchs au final 🙂
Merci pour cette petite étude de cas et je penses que plusieurs seraient top.
Très bonne journée
Bonjour Yohan,
Le RPVST intègre en natif la fonction uplinkfast, tu n’as pas besoin de l’activer quand tu utilise cette version de Spanning-tree.
La fonction uplinkfast a été créée pour palier certaines lenteures du Spanning-tree classique le 802.1D. Pour rappel :
On active l’UplinkFast sur un lien dans l’état Blocking lorsqu’il n’y a que ce chemin secondaire pour accéder au Root. Cela permet de bypasser les états Listening et Learning lors d’un « link failure » sur le root port. Le port bloqué passera directement en état Forwarding.
Merci Cyril,
J’avoue que je ne pouvais pas penser à cela.
Tu viens de sauver une vie