Vidéo: Linux Tutorial for Beginners: Introduction to Linux Operating System 2024
Les problèmes de couche 3 concernent bien entendu les paquets. En règle générale, plus le problème se situe au-dessus de la pile de protocoles, plus il y a de risques de problèmes. Au niveau de la couche de routage (un ancien nom pour le niveau 3), les routes vers une destination donnée peuvent être absentes, peuvent être en boucle ou envoyer des paquets dans un trou noir.
Dans le réseau du routeur, il existe des outils permettant d'examiner le fonctionnement des protocoles eux-mêmes, tels que les commandes de mode opérationnel show show protocol ospf ou show bgp. Vous pouvez utiliser ces commandes pour avoir un aperçu du fonctionnement des protocoles de routage OSPF et BGP, respectivement.
Cependant, comme vous l'avez déjà vu, les problèmes de couche 3 sont souvent causés par des événements de couche 2. Même ainsi, vous pouvez compter sur l'interrogation et les interruptions SNMP et Ethernet OAM pour capturer les problèmes au niveau de la liaison du routeur réseau. Maintenant, jetez un oeil à un problème qui est en fait un problème au niveau de la couche paquets. Ici, vous utilisez un outil utilisateur final typique - traceroute - pour isoler le routeur à l'origine du problème.
Traceroute envoie un paquet saut par saut d'un routeur à un autre jusqu'à ce que l'hôte de destination soit atteint. Si un paquet arrive sur un routeur qui n'a pas d'itinéraire vers la destination, un message ICMP destination inaccessible est renvoyé à l'expéditeur.
Lors de l'utilisation de traceroute, rappelez-vous que le problème est généralement et non au dernier saut pour répondre au traceroute, mais au delà de le dernier périphérique répondant.
Quand tout va bien, la destination est normalement à cinq bonds de l'hôte source. Une modification de l'adresse réseau du répondeur indique que le paquet est passé d'une partie importante du réseau à une autre (du réseau du client au réseau du fournisseur de services, par exemple).
Dans ce qui suit, notez comment les routeurs répondent normalement à un traceroute sur le chemin de Dest-Host:
user @ host> traceroute 10. 2. 2. 1 traceroute à 10. 2. 2. 1 (10 2. 2. 1), 30 sauts maximum, paquets de 40 octets 1 192. 168. 10. 1 (192. 168. 10. 1) 2. 617 ms 1. 690 ms 2. 851 ms (Cust-Router1) 2 192. 168. 10. 6 (192. 168. 10. 6) 3. 386 ms 3. 370 ms 5. 570 ms (Cust-Router2) 3 172. 16. 11. 1 (172. 16. 11. 1) 13. 513 ms 3. 905 ms 5. 060 ms (Prov-Rtr1) 4 172. 16. 44. 2 (172. 16. 44. 2) 3. 778 ms 5. 237 ms 5. 413 ms (Prov-Rtr2) 5 172. 16. 44. 27 (172. 16. 44. 27) 10. 867 ms 12. 568 ms 5. 991 ms (Dest-Host)
Maintenant, regardez ce qui se passe si le lien - le seul lien, d'ailleurs - entre le routeur du client (Cust-Router2) et le routeur du fournisseur de services (Prov-Rtr1) échoue:
utilisateur @ hôte> traceroute 10.2. 2. 1 traceroute à 10. 2. 2. 1 (10. 2. 2. 1), 30 bonds maximum, 40 paquets d'octets 1 192. 168. 10. 1 (192. 168. 10. 1) 1. 983 ms 2. 440 ms 2. 414 ms (Cust-Router1) 2 192. 168. 10. 6 (192. 168. 10. 6) 2. 883 ms! H 4. 136 ms ! H 2. 114 ms! H
Le! H indique que vous recevez des messages d'hôte ICMP inaccessibles du second routeur. Il peut sembler que ce périphérique Cust-Router2 est le problème, mais notez que les paquets ont fait leur chemin vers Cust-Router2 et vice versa sans aucun problème.
Non, le problème est au-delà de ce dernier saut, sur le lien entre le client et le fournisseur de services. Il n'y a pas de route vers la destination sur Cust-Router2, donc le! H est émis.
