Aujourd'hui, nous allons examiner 3 concepts: le protocole propriétaire Cisco CDP, le journal système Syslog et le protocole de temps réseau NTP. Nous continuerons également à discuter du sujet des problèmes et à examiner quelques outils pour les diagnostiquer, puis à examiner Syslog et NTP et à la fin de la leçon à discuter CDP et LLDP.
Dans la leçon précédente, nous avons examiné la méthodologie de dépannage, et maintenant je vais parler de plusieurs outils intégrés au système d'exploitation et aux périphériques Cisco qui peuvent vous aider à résoudre les problèmes de réseau.
Le premier outil est la commande ipconfig, et puisque la plupart des gens utilisent Windows 10, nous examinerons cette commande en utilisant cet OS comme exemple. Si vous accédez au terminal de ligne de commande de votre ordinateur et entrez la commande ipconfig, vous pouvez voir les paramètres de configuration de toutes les interfaces réseau disponibles sur votre ordinateur.
Vous verrez une interface virtuelle logicielle VPN Ethernet Adapter et plusieurs autres interfaces logicielles, dont le nombre dépend des pilotes disponibles dans le système. Voici mon adaptateur LAN sans fil Wi-Fi, avec lequel je suis maintenant connecté à Internet, les données sur l'adaptateur virtuel WMware Network WMnet1 sont situées un peu plus haut. L'adaptateur de tunnel est illustré ci-dessous, c'est-à-dire que tous les adaptateurs installés par le logiciel VPN sont affichés ici.
Le sujet du cours CCNA nécessite que vous connaissiez deux adaptateurs: un adaptateur Wi-Fi sans fil et un adaptateur Ethernet.
Pour un réseau de bureau, l'adaptateur sans fil est plus important, et si l'un des utilisateurs vous contacte avec un problème, vous devez d'abord utiliser la commande ipconfig et regarder l'adresse IP du périphérique. Vous devez vérifier si cette adresse est dans la plage d'adresses DHCP. L'utilisateur a peut-être désactivé la dynamique et activé l'IP statique, qui ne fait pas partie de DHCP, ou le périphérique est configuré pour obtenir automatiquement une adresse IP et ne peut pas, pour une raison quelconque, contacter le serveur DHCP.
Si vous avez besoin d'informations plus complètes, utilisez la commande ipconfig / all. Vous recevrez les mêmes données, mais sous une forme plus détaillée, avec la description de la marque de l'adaptateur, les paramètres DHCP, l'adresse locale du lien, l'adresse IP, la période de validité du bail du serveur, l'adresse de la passerelle par défaut, etc.
Si, à la suite de la vérification de ces informations, il s'avère que tout va bien avec l'adresse IP et que les paramètres d'interface ne sont pas la cause du problème, vous devez utiliser d'autres outils de diagnostic, tels que NSLookup. Il s'agit d'un utilitaire qui vous permet d'accéder au système DNS via la ligne de commande. Si cela ne résout pas le problème, utilisez ping. J'utilise la commande ping 8.8.8.8, c'est-à-dire que j'effectue une commande ping au DNS public de Google. Si le ping réussit, alors tout est en ordre avec la connexion et la raison doit être cherchée ailleurs.
Si le ping ne passe pas, vous devez utiliser un outil appelé Trace Route, ou tracert. Il s'agit d'une commande Windows pour tracer la route vers un hôte donné. Si vous tapez tracert 8.8.8.8 sur la ligne de commande, vous obtiendrez ping avec une valeur de TTL = 1 avec une trace de route de jusqu'à 30 nœuds. Comme vous pouvez le voir, le premier nœud est mon routeur, le système a montré son micrologiciel DD-WRT et son adresse IP 192.168.1.1, le second est le serveur de mon fournisseur avec l'adresse IP 192.168.100.1, via laquelle je vais sur Internet, puis je pings sur d'autres nœuds et atteint le serveur Google. Dans notre cas, il s'est avéré 14 espoirs, mais si, par exemple, un problème survenait du côté de mon fournisseur, la trace s'arrêterait après le 3ème nœud caractérisant le serveur ISP.
Ainsi, Trace Route est un excellent outil pour identifier les problèmes le long de la route du trafic.
Examinons de plus près ce qu'est NSLookup. Il s'agit d'une commande qui parle de votre serveur DNS. Si vous tapez nslookup, j'obtiens deux lignes: le serveur par défaut est DD-WRT, c'est-à-dire mon routeur, et son adresse est 192.168.1.1. Si je spécifie un serveur DNS spécifique avec la commande server 8.8.8.8, le système me donnera sa description et son adresse IP. De cette façon, vous pouvez vérifier n'importe quel serveur DNS donné. De la même manière, je peux obtenir des données sur un domaine spécifique en tapant, par exemple,
www.cisco.com .
Comme vous pouvez le voir, Cisco utilise deux versions de l'adresse IP, et si je tape google.com, nous verrons de nombreuses adresses IP utilisées par ce serveur. Il s'agit d'un service énorme auquel tant de personnes accèdent qu'une seule adresse IP peut ne pas suffire.
Il y a une blague selon laquelle lorsque les gens veulent savoir si Internet fonctionne, ils tapent simplement google.com. En plus des utilisateurs de PC, les propriétaires de smartphones sous Android accèdent constamment à ce service, il y a donc simplement un trafic énorme passant par les serveurs de cette société.
Ainsi, la commande nslookup vous permet de connaître l'adresse IP d'un nom de domaine spécifique. Tous les outils mentionnés ci-dessus ne résolvent pas les problèmes, mais servent à les diagnostiquer. Plus vous pratiquez dans l'industrie informatique, plus vous pourrez utiliser ces outils efficacement, car seules la pratique et l'expérience peuvent vous apprendre à diagnostiquer et à résoudre rapidement les problèmes de réseau. La pratique vous donnera l'occasion de comprendre quel est le problème, en un coup d'œil aux paramètres réseau de la console de l'ordinateur. Par conséquent, après avoir terminé l'étude du sujet de l'ICND1, je publierai des travaux pratiques de laboratoire sur le site afin que vous puissiez appliquer les connaissances théoriques.
Avant de parler du syslog, je veux parler de la commande Terminal Monitor du système d'exploitation Cisco IOS. Je vais entrer dans le programme Packet Tracer (si vous ne l'avez pas déjà installé, vous pouvez vous inscrire auprès de Network Academy et télécharger ce programme), prendre deux routeurs et les connecter avec un câble.
Ensuite, je vais passer en mode de configuration globale et configurer à tour de rôle ces routeurs, en leur donnant les noms R0 et R1.
Ensuite, dans les paramètres R1, j'entrerai la commande enable password enable pour définir le mot de passe et configurer l'interface g0 / 0 en utilisant l'ip add 10.1.1.2 255.255.255.0 et aucune commande de fermeture. De la même manière, je configurerai le routeur R0 en lui attribuant l'adresse IP 10.1.1.1. Ensuite, j'active le protocole Telnet avec la commande line vty 0 4 et définit le mot de passe pour entrer Telnet avec les commandes telnet de connexion et de mot de passe. Ensuite, je vais aller dans les paramètres de R0 et utiliser la commande telnet 10.1.1.2 pour établir une connexion avec le routeur R1. Après cela, le système demandera un mot de passe pour établir une connexion et j'entrerai le mot telnet, que j'ai défini comme mot de passe pour R1. Comme vous pouvez le voir, après cela, sur la ligne de commande, le nom du routeur R0 est devenu R1 - cela signifie que je suis passé par le routeur R0 pour les paramètres du routeur R1.
Passons maintenant à l'interface g0 / 1 et je vais vous montrer quelques choses. Tout d'abord, j'utilise la commande no shut pour cela. Vous voyez que le message de journal est apparu dans la fenêtre CLI du deuxième routeur, que l'état de l'interface g0 / 1 a changé pour up.
Depuis que j'ai entré les paramètres R1 à partir du routeur R0, il s'est avéré que j'avais connecté un ordinateur portable ordinaire au deuxième routeur avec un câble et que je l'avais contrôlé à distance. Cependant, ce message de journal est apparu uniquement dans la fenêtre R1, car j'étais connecté au deuxième routeur uniquement via le canal Telnet et il n'était pas dupliqué dans la fenêtre CLI du premier routeur. Le fait est que si vous avez entré à distance les paramètres d'un appareil situé, par exemple, dans un autre bâtiment, par défaut, les messages de journal de cet appareil ne seront pas affichés sur votre écran.
Pour que ces messages de journal s'affichent sur l'écran de votre appareil, vous devez utiliser la commande Terminal Monitor. En fait, cela signifie que si des messages du journal des événements apparaissent sur l'écran d'un autre appareil, ils doivent être envoyés sous forme de paquets via le protocole Telnet à l'adresse IP de votre appareil. Par défaut, les messages de journal ne sont pas envoyés à l'adresse IP, mais après avoir entré la commande de surveillance du terminal, cela commencera à se produire. Si j'entre maintenant la commande d'arrêt dans la fenêtre des paramètres du routeur R1, un message de journal sur la modification de l'état de l'interface apparaîtra simultanément sur les deux écrans.
Maintenant, je vais entrer dans le mode de paramètres globaux R1 dans la première fenêtre et commencer à taper une commande, par exemple, int g0 / 0. Supposons que j'ai réussi à imprimer uniquement int g0 /, et à ce moment une sorte de message de journal est apparu. Mon équipe sera déchirée par ce message, donc 0 sera sur la ligne suivante, et l'appareil peut ne pas le comprendre. Cela est particulièrement gênant si je tape une commande longue ou si les messages du journal se composent de plusieurs lignes, car je ne saurai pas où arrêter de taper pour que mon équipe ne se déchire pas, ou je peux oublier où je me suis arrêté.
Pour éviter cela, la synchronisation des journaux est utilisée. Je tape la commande line vty 0 4 dans la fenêtre de droite pour accéder aux paramètres Telnet, après quoi l'en-tête de ligne de commande passe de R1 (config-if) à R1 (config-line). Ensuite, j'entre la commande logging synchronous et retourne à la fenêtre de gauche.
Maintenant, je répète la même situation - tapez int g0 / et pause, au cours de laquelle le message de journal apparaît à nouveau. Il apparaît également sur les deux écrans, mais maintenant son texte ne rompt pas ma commande, et en dessous il répète simplement ce que j'ai commencé à taper. Maintenant, je peux tranquillement continuer à taper l'équipe que j'ai commencée, sans craindre qu'elle ne soit divisée en morceaux par les journaux qui apparaissent. Pour moi, en tant qu'utilisateur, cela est très pratique, car vous n'avez pas besoin de réfléchir à la manière de taper une commande plus rapidement, jusqu'à ce que soudainement un message du journal des événements apparaisse. C'est ce que fait la commande logging synchronous, ou «synchroniser les journaux».
Chacun des messages de journal a un certain niveau de priorité, dans notre exemple c'est le niveau 5. Plus la valeur du niveau de journalisation est basse, plus le message est important. Il existe au total 8 niveaux de priorité des journaux Cisco.
0 - urgence, le système n'est pas pleinement opérationnel,
1 - une situation alarmante, une intervention urgente est nécessaire,
2 - événements critiques, le système peut tomber en panne,
3 - messages d'erreur,
4 - toutes sortes d'avertissements
5 - diverses notifications importantes,
6 - messages d'information,
7 - messages de débogage.
Les trois premiers niveaux signalent des conditions dangereuses du système, le niveau 3 indique des problèmes dans le système, le quatrième niveau avertit que l'état du système peut devenir instable, mais il fonctionne toujours. Le niveau 5 informe sur divers événements, par exemple, sur un changement de l'état du lien, comme dans notre exemple. Si vous utilisez le mode débogage, l'écran affichera des messages de débogage du 7e niveau. Si vous êtes une personne occupée et que vous ne souhaitez pas lire tous les journaux, vous pouvez choisir le niveau de messages de danger à afficher à l'écran.
Par exemple, je veux voir uniquement les messages du journal jusqu'au 3e niveau de danger. Dans ce cas, le système n'affichera que les messages des niveaux 0, 1, 2 et 3, en ignorant les messages des niveaux 4 à 7. Par défaut, le niveau 7 est défini, vous verrez donc les journaux de tous les niveaux, de zéro à septième.
Nous avons examiné ce qu'est le moniteur de terminal et passons maintenant à Syslog. Si des messages de journal importants apparaissent sur votre écran, vous voudrez peut-être les enregistrer d'une manière ou d'une autre sur le serveur Syslog, car généralement ces messages sont stockés uniquement dans la mémoire du routeur et vous ne pourrez pas les analyser après un certain temps.
Revenons à Packet Tracer et ajoutons un serveur au circuit qui est directement connecté au premier routeur. Dans la pratique, le commutateur doit être situé entre eux, mais nous utilisons ce schéma à des fins de formation, afin que nous puissions nous passer du commutateur. Je vais dans les paramètres réseau du serveur et je lui attribue une adresse IP statique 10.1.2.10, un masque de sous-réseau de 255.255.255.0 et une adresse de passerelle par défaut de 10.1.2.1. Cette adresse n'existe pas encore, mais je la configurerai lorsque je procéderai à la configuration de l'interface du routeur R0.
Ensuite, je vais aller dans les paramètres de R0, utiliser la commande g0 / 1 et lui attribuer l'adresse 10.1.2.1 avec un masque de sous-réseau de 255.255.255.0. Ainsi, le serveur et le routeur seront sur le même réseau. Ensuite, je dois entrer dans les paramètres du deuxième routeur R1 et configurer la connexion avec le premier routeur. Vous pouvez configurer un RIP ou une route statique, dans ce cas, je choisis ce dernier.
Pour ce faire, j'entre la commande ip route 0.0.0.0 0.0.0.0 10.1.1.1, c'est-à-dire que j'indique que tout le trafic est envoyé à l'adresse 10.1.1.1. J'entre alors dans do show ip route et je vois que la passerelle de la dernière file d'attente Gateway of last resort a l'adresse 10.1.1.1 pour le réseau 0.0.0.0.
Je vais maintenant vérifier s'il est possible d'envoyer une requête ping à l'appareil au 10.1.2.10. Si vous vous en souvenez, le ping est un outil de diagnostic, et comme vous pouvez le voir, le ping a réussi. Ensuite, j'active le mode débogage avec la commande debug ip icmp, cela signifie que chaque fois que le routeur cingle, un message correspondant apparaît dans la fenêtre de la console.
Si je ping R1 à partir du routeur gauche R0 à l'aide de la commande ping 10.1.1.2, les messages de journal apparaîtront dans la fenêtre CLI du routeur droit, par défaut, niveau de priorité 7. Je veux que tous les messages de journal qui apparaissent pendant le processus de configuration soient envoyés au serveur Syslog. Pour ce faire, je vais dans l'onglet Services du panneau des paramètres du serveur et je vois que le paramètre Syslog est activé par défaut. Eh bien, maintenant je dois dire à R1: "chaque fois qu'un message de log apparaît, veuillez l'envoyer au serveur Syslog au 10.1.2.10!". Pour ce faire, j'entre la commande logging 10.1.2.10. Tous les messages du journal seront désormais envoyés au serveur. Voyons comment cela se produit.
J'entre dans les paramètres de R0 et encore une fois je ping le routeur R1. Dans la fenêtre CLI du serveur de droite, un message de débogage apparaît, qui doit être transmis au serveur Syslog. Je vais dans l'onglet Syslog du serveur et je vois que tous ces messages y sont apparus.
Ainsi, si des événements se sont produits pendant le week-end, alors que vous êtes arrivé au travail le lundi, vous pourrez consulter tous les messages de journal dans lesquels ces événements sont enregistrés. Si vous avez des problèmes, vous pouvez analyser ce qui s'est passé et appliquer des mesures pour les éliminer.
Cependant, si vous regardez attentivement les messages Syslog, vous verrez une erreur: ils ont tous un horodatage le 1er janvier de zéro heure. Cela signifie que je ne peux pas savoir quand les événements enregistrés se sont réellement produits. Cela s'est produit parce que l'horloge système du routeur R1 affiche la mauvaise heure. Si j'entre la commande show clock dans les paramètres de ce routeur, je verrai le message 0: 26: 9.539 UTC lun 1 mars 1993. Cela signifie que 26 minutes 9 secondes se sont écoulées depuis que le routeur a été allumé, et l'horloge par défaut commence à compter à partir du 1er mars 1993 années.
Je peux régler manuellement l'heure correcte et commencer à le faire avec le routeur R0. J'entre la commande de réglage de l'horloge, puis je règle l'heure correcte au format hh: mm: ss. Après avoir entré 22:05:00, le système vous invite à saisir le jour du mois de 1 à 31 et le nom du mois. J'imprime le 14 mars et je dois maintenant entrer l'année dans la plage de 1993 à 2035. Par conséquent, je tape la ligne 22:05:00 le 14 mars 2017, après quoi j'appuie sur Entrée. Si vous tapez maintenant show clock, le système affichera l'heure correcte.
Vous pouvez vous demander pourquoi j'ai réglé l'heure sur le routeur R0, et non sur R1. C'est parce que je veux vous montrer le réglage automatique de l'heure du deuxième routeur. Ensuite, j'entre les commandes debug ip icmp et logging 10.1.2.10 dans les paramètres R0 afin que les journaux soient envoyés au serveur Syslog.
Ensuite, je désactive le débogage du routeur R1 avec la commande un all et envoie une requête ping à l'appareil 10.1.1.1. Le ping a réussi, et si vous regardez maintenant les journaux du serveur, vous pouvez voir que de nouveaux messages ont été ajoutés ici, mais pour une raison inconnue, avec une heure et une date zéro incorrectes. C'est étrange, car l'heure correcte est également indiquée dans les paramètres du routeur R1. J'ai de nouveau cinglé le routeur R0 à partir du routeur R1, les messages de journal apparaissent à l'écran et dans le journal du serveur, mais à nouveau avec la mauvaise date. Les informations n'ont probablement pas encore été mises à jour et je vais essayer de savoir pourquoi.
Je vais dans les paramètres du routeur R0 et j'éteins les messages de débogage avec la commande un all, après quoi je vais dans les paramètres du routeur R1 et j'entre la commande de service timestamps, qui met un horodatage sur les messages de débogage ou les messages de journal. Dans notre cas, j'utilise le service horodatages log datetime ms.
Ensuite, je reviens aux paramètres de R0 et ping R1. Vous voyez maintenant que les messages sont apparus sur le serveur avec la date et l'heure: 1er mars, 00:31:02 avec millisecondes. Mais ce n'est pas la bonne date, puisque je n'ai pas fixé le 1er mars, mais le 14 mars! Je m'excuse d'avoir fait des erreurs dans ce didacticiel vidéo, je vais maintenant les corriger.
Je vais essayer de régler l'heure correcte d'une manière différente. Le fait est que jusqu'à ce que j'active le service d'horodatage, les messages sont arrivés avec l'heure et la date par défaut. Ensuite, j'ai activé le service d'horodatage, mais après cela, je n'ai pas configuré l'heure et la date correctes, c'est pourquoi l'horodatage dans les messages du journal s'est avéré incorrect.
Le problème avec le réglage manuel de l'heure est que si vous avez des centaines d'appareils, vous devez entrer dans les paramètres de chaque appareil et régler l'heure et la date. Pour éviter cela, il existe un mécanisme NTP automatique, ou protocole d'heure réseau, qui synchronise l'heure d'un ordinateur avec l'heure des périphériques réseau. Vous pouvez sélectionner un périphérique réseau en tant que maître NTP et régler l'heure souhaitée. L'étude de ce protocole dépasse le cadre du cours CCNA, et je ne suis pas sûr que la commande ntp master soit prise en charge par Packet Tracer. Mais j'essaie toujours de régler l'heure correcte, pour laquelle j'ajouterai un autre serveur à notre réseau et lui assignerai un serveur NTP.
Pour ce faire, je vais entrer dans ses paramètres et vérifier l'onglet NTP. Comme vous pouvez le voir, la date et l'heure correctes sont définies ici et la fonction NTP est activée.
Ensuite, je vais dans les paramètres réseau de Server1 et je lui attribue une adresse IP 10.1.3.10, un masque de sous-réseau de 255.255.255.0 et une passerelle par défaut de 10.1.3.1. Comme je l'ai mentionné plus tôt, cette passerelle n'est pas configurée, donc j'entre dans les paramètres du routeur R1 et configure l'interface g0 / 1 pour communiquer avec le serveur en émettant l'ip add 10.1.3.1 255.255.255.0 et aucune commande de fermeture.
Ensuite, dans les paramètres du routeur, j'entre la commande ntp server 10.1.3.10, après quoi le routeur R1 pourra recevoir l'heure correcte du serveur NTP. Comme vous pouvez le voir, nous avons maintenant des messages de journal de niveau 5 avec le bon horodatage.
show clock, , . ntp association, , Packet Tracer, ntp.
ntp status , . , Stratum 2 – , NTP-, R2 , 1. , R1, stratum 3 (NTP- + R1 + ), R1 NTP- 2. , .
R0 R1 10.1.1.2, , Server0 , .
, NTP Syslog. – CDP, Cisco Discovery Protocol. .
, , , , . Cisco, , , IP-. , LLDP, Link Layer Discovery Protocol, , CDP, .
CDP Cisco . LLDP, Cisco . , LLDP, Cisco, CDP.
, , Packet Tracer. , , CDP , Server0 R0. , , .
CLI R0 show cdp. , cdp- 60 , 180 , – CDPv2.
CDP , , , . 60 . show cdp neighbors, , R0 CDP-.
, R0 – R1 . R1 R 1900 R0 g0/0, g0/0 R0.
, show cdp neighbors , , , . , .
R0 – 2960, g0/1. , , , , , Capability, : R – , S – , H- .. R0 FastEthernet 0/1.
, CDP . , , – CDP . , , . CDP? config t cdp run. , cdp . cdp no cdp run. , cdp, show cdp – , CDP is not enable.
, cdp , . , , cdp cdp run, , , int g0/1, cdp enable, , no cdp enable, . no cdp enable cdp , . , / cdp run, – enable.
show cdp neighbors, , R0 – R1. cdp g0/1, «».
LLDP , CDP, lldp run/no lldp run. , Cisco CDP , LLDP – . LLDP , , g0/1, lldp receive, , lldp transmit, LLDP -.
, no lldp receive, – no lldp transmit. CDP LLDP , , – , LLDP -.
Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? ,
30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
Dell R730xd 2 fois moins cher? Nous avons seulement
2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! Pour en savoir plus sur la
création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?