Vous êtes sur la page 1sur 36
Chapitre 8 – Dépannage du Réseau Page 1 sur 36 CCNA Exploration - Commutation de

Chapitre 8 – Dépannage du Réseau

Page 1 sur 36

CCNA Exploration - Commutation de réseau local et sans fil Chapitre 8 – Dépannage du Réseau

8.0-Présentation du Chapitre

Une fois qu’un réseau est opérationnel, les administrateurs doivent contrôler ses performances pour garantir la productivité de l’entreprise. Des pannes de réseau peuvent parfois se produire. Elles sont parfois prévues à l’avance et leur impact sur l’entreprise peut facilement être géré. Elles sont parfois imprévues et leur impact sur l’entreprise peut être important. Dans le cas d’une panne de réseau inattendue, les administrateurs doivent être capables de dépanner le réseau et de rétablir l’ensemble des fonctionnalités. Dans le présent chapitre, vous allez apprendre un processus méthodique qui vous permettra de résoudre les pannes de réseau.

qui vous permettra de résoudre les pannes de réseau. 8.1-Etablissement de la ligne de Base des

8.1-Etablissement de la ligne de Base des performances du Réseau

8.1.1-Documenter votre réseau

des performances du Réseau 8.1.1-Documenter votre réseau Documenter votre réseau Pour diagnostiquer et corriger des

Documenter votre réseau

Pour diagnostiquer et corriger des problèmes de réseau de façon efficace, un ingénieur réseau doit savoir comment un réseau a été conçu et doit connaître les performances attendues pour ce réseau dans des conditions d’utilisation normales. L’ensemble de ces informations s’appelle la ligne de base du réseau et se trouve dans la documentation telle que les tables de configuration et les diagrammes topologiques.

La documentation de la configuration du réseau offre un diagramme logique du réseau et contient des informations détaillées sur chaque composant. Ces informations doivent être regroupées en un lieu unique, que ce soit sous forme de copie papier ou sur le réseau ou sur un site Web protégé. La documentation réseau doit inclure les composants suivants :

la table de la configuration du réseau ;

la table de configuration du système d’extrémité ;

le diagramme topologique du réseau.

Table de la configuration du réseau

Elle contient des enregistrements précis et à jour du matériel et des logiciels utilisés sur un réseau. La table de la configuration du réseau doit fournir à l’ingénieur réseau toutes les informations nécessaires pour identifier et corriger l’incident réseau.

Chapitre 8 – Dépannage du Réseau Page 2 sur 36 Cliquez sur le bouton Documentation

Chapitre 8 – Dépannage du Réseau

Page 2 sur 36

Cliquez sur le bouton Documentation Routeur et commutateur dans la figure.

Le tableau de la figure illustre l’ensemble des données devant être incluses pour tous les composants :

le type de périphérique et la désignation du modèle ;

le nom de l’image IOS ;

le nom d’hôte du réseau du périphérique ;

l’emplacement du périphérique (bâtiment, étage, salle, bâti, panneau) ;

s’il s’agit d’un périphérique modulaire, tous les types de module et l’emplacement de module où ils se situent ;

les adresses de couche liaison de données ;

les adresses de couche réseau ;

toute information importante supplémentaire sur les aspects physiques du périphérique.

Cliquez sur le bouton Documentation Système d’extrémité dans la figure.

Documentation Système d’extrémité dans la figure. Table de configuration du système d’extrémité Elle

Table de configuration du système d’extrémité

Elle contient les enregistrements de la ligne de base pour le matériel et les logiciels utilisés sur des périphériques de système d’extrémité tels que des serveurs, des consoles d’administration de réseaux et des stations de travail. S’il n’est pas correctement configuré, un système d’extrémité peut avoir des conséquences négatives sur les performances globales d’un réseau.

À des fins de dépannage, les informations suivantes doivent être recueillies :

le nom du périphérique (fonction) ;

le système d’exploitation et la version ;

l’adresse IP ;

le masque de sous-réseau ;

les adresses de la passerelle par défaut, du serveur de noms de domaine (DNS) et du serveur WINS ;

toute application réseau à large bande passante exécutée par le système d’extrémité.

Cliquez sur le bouton Diagramme topologique du réseau dans la figure.

Diagramme topologique du réseau

Cette représentation graphique d’un réseau illustre comment chaque périphérique d’un réseau est connecté et son architecture logique. Un diagramme topologique compte de nombreux composants communs avec la table de configuration du réseau. Chaque périphérique réseau doit être représenté sur le diagramme en utilisant de manière cohérente une notation ou un symbole graphique. De plus, chaque connexion logique ou physique doit être représentée à l’aide d’un simple trait ou d’un autre symbole approprié. Il est également possible de faire apparaître les protocoles de routage.

Le diagramme topologique doit comporter au moins les éléments suivants :

les symboles de tous les périphériques et leurs connexions ;

les numéros et types d’interface ;

les adresses IP ;

les masques de sous-réseau.

les numéros et types d’interface ; ∑ les adresses IP ; ∑ les masques de sous-réseau.
Chapitre 8 – Dépannage du Réseau Page 3 sur 36 8.1.2-Documenter Votre Réseau Processus de

Chapitre 8 – Dépannage du Réseau

Page 3 sur 36

8.1.2-Documenter Votre Réseau

Processus de documentation du réseau

La figure illustre le processus de documentation du réseau.

Dans la figure, placez votre pointeur sur chaque étape pour obtenir plus d’informations sur le processus.

Lorsque vous documentez votre réseau, vous devrez peut- être recueillir des informations directement sur les routeurs et les commutateurs. Les commandes suivantes sont utiles au cours du processus de documentation du réseau :

utiles au cours du processus de documentation du réseau : ∑ La commande ping permet de

La commande ping permet de tester la connectivité avec les périphériques voisins avant de vous y connecter. Lorsque vous envoyez une requête ping à d’autres ordinateurs du réseau, le processus de détection automatique de l’adresse MAC est également lancé.

La commande telnet permet de se connecter à distance à un périphérique afin d’accéder à des informations de configuration.

La commande show ip interface brief permet d’afficher l’état actif ou inactif et l’adresse IP de toutes les interfaces d’un périphérique.

La commande show ip route permet d’afficher la table de routage dans un routeur afin de connaître les voisins connectés directement, de repérer plus de périphériques distants (via des routes apprises) et de connaître les protocoles de routage qui ont été configurés.

La commande show cdp neighbor detail permet d’obtenir des informations détaillées sur les périphériques voisins Cisco connectés directement.

8.1.3-Pourquoi est-il important d’établir une ligne de Base de Réseau

Pour établir une ligne de base des performances du réseau, vous devez recueillir des données de performances clés sur les ports et les périphériques qui sont essentiels à l’exploitation du réseau. Ces informations aident à déterminer la « personnalité » du réseau et apportent des réponses aux questions suivantes :

Quelles sont les performances du réseau dans un jour normal ou moyen ?

Quelles parties du réseau sont sous-utilisées et surutilisées ?

Où se produit la majorité des erreurs ?

Quels seuils doivent être définis pour les périphériques devant être surveillés ?

Le réseau peut-il permettre de mettre en place les stratégies identifiées ?

permettre de mettre en place les stratégies identifiées ? L’administrateur réseau peut mesurer les performances

L’administrateur réseau peut mesurer les performances initiales et la disponibilité des liaisons et des périphériques réseau critiques afin de déterminer la différence entre une situation anormale et des performances réseau standard alors que le réseau s’étend ou que les modèles de trafic changent. La ligne de base permet également de déterminer si la conception actuelle du réseau peut permettre de mettre en place les stratégies requises. Sans ligne de base, aucune norme ne permet de mesurer le niveau optimal du trafic réseau et les niveaux d’encombrement.

De plus, une analyse effectuée après une ligne de base initiale a tendance à révéler des problèmes cachés. Les données recueillies révèlent la vraie nature de l’encombrement (réel ou potentiel) d’un réseau. Elles peuvent également indiquer des parties du réseau qui sont sous- utilisées, ce qui peut déboucher sur une nouvelle conception du réseau basée sur les observations relatives à la qualité et à la capacité.

Chapitre 8 – Dépannage du Réseau 8.1.4-Etablissement de la ligne de Base des performances du

Chapitre 8 – Dépannage du Réseau

8.1.4-Etablissement de la ligne de Base des performances du Réseau

Page 4 sur 36

Page 1 :

Planification de la première ligne de base

Il est important de planifier soigneusement la première ligne de base des performances du réseau car elle prépare le terrain pour mesurer les effets des changements au niveau du réseau et les activités de dépannage qui en découlent. Il est conseillé de suivre les étapes suivantes lors de la planification de la première ligne de base :

Étape 1. Choix des types de données à collecter

Pour la première ligne de base, commencez par sélectionner quelques variables qui représentent les stratégies définies. Si vous sélectionnez trop de points de données, la quantité de données peut être trop importante, rendant difficile l’analyse des données recueillies. Commencez par quelques données seulement et affinez votre choix au fur et à mesure. L’utilisation de l’interface et l’utilisation de l’UC sont généralement des bonnes mesures de départ. La figure comprend des captures d’écran de données de l’utilisation de l’interface et de l’UC, telles qu’elles s’affichent dans un système d’administration de réseaux de Fluke Networks.

système d’administration de réseaux de Fluke Networks. Cliquez sur le bouton Périphériques et ports intéressants

Cliquez sur le bouton Périphériques et ports intéressants dans la figure.

Étape 2.

intéressants

Identification

des

périphériques

et

des

ports

Identification des périphériques et des ports L’étape suivante consiste à identifier les principaux

L’étape suivante consiste à identifier les principaux périphériques et ports pour lesquelles vous souhaitez mesurer les données de performances. Les périphériques et ports intéressants sont :

les ports des périphériques réseau qui se connectent à d’autres périphériques réseau ;

les serveurs ;

les utilisateurs principaux ;

tout élément considéré comme vital pour le bon fonctionnement des opérations.

La figure illustre une topologie dans laquelle l’administrateur réseau a mis en évidence les périphériques et les ports intéressants à contrôler lors du test de la ligne de base. Les routeurs R1, R2 et R3, PC1 (le terminal admin) et SRV1 (le serveur Web/TFTP) sont des périphériques intéressants. Les ports sur R1, R2 et R3 qui se connectent aux autres routeurs ou aux commutateurs et, sur le routeur R2, le port qui se connecte à SRV1 (Fa0/0) sont des ports intéressants.

En réduisant le nombre de ports analysés, les résultats sont plus concis et la charge d’administration des réseaux est réduite. Souvenez- vous qu’une interface sur un routeur ou un commutateur peut être une interface virtuelle, telle qu’une interface virtuelle de commutation (SVI).

Cette étape est plus simple si vous avez indiqué ce qui se connecte au port dans les champs de description du port du périphérique. Par exemple, pour un port de routeur qui se connecte au commutateur de distribution dans le groupe de travail Ingénierie, vous pouvez inclure la description « Commutateur de distribution réseau local Ingénierie ».

Chapitre 8 – Dépannage du Réseau Page 5 sur 36 Cliquez sur le bouton Durée

Chapitre 8 – Dépannage du Réseau

Page 5 sur 36

Cliquez sur le bouton Durée de la ligne de base dans la figure.

Étape 3. Durée de la ligne de base

La durée et les informations sur la ligne de base recueillies doivent être suffisantes pour définir une image type du réseau. Cette période doit couvrir au moins sept jours pour relever des tendances quotidiennes ou hebdomadaires. Les tendances hebdomadaires sont aussi importantes que les tendances quotidiennes ou horaires.

La figure contient des exemples de captures d’écran montrant des tendances de l’utilisation de l’UC recueillies sur un jour, une semaine, un mois et un an. Les tendances de la semaine de travail sont trop courtes pour révéler de façon précise la nature récurrente de l’augmentation d’utilisation qui se produit tous les samedis soir, au moment où une importante opération de sauvegarde des bases de données consomme de la bande passante réseau. Ce modèle récurrent est visible avec la tendance mensuelle. La tendance annuelle donnée en exemple est trop longue pour fournir des détails intéressants sur les performances de la ligne de base. Une ligne de base ne doit pas durer plus de six semaines, à moins que des tendances spécifiques à long terme doivent être mesurées. En règle générale, une ligne de base doit couvrir entre deux et quatre semaines.

ligne de base doit couvrir entre deux et quatre semaines. N’effectuez pas de mesure de ligne

N’effectuez pas de mesure de ligne de base lorsque le modèle de trafic est unique car les données ne fourniraient pas une image exacte des opérations normales sur le réseau. Vous obtiendriez une mesure inexacte des performances réseau si vous avez effectué une mesure de ligne de base pendant des jours fériés ou au cours d’un mois où la majorité des employés sont en vacances.

La ligne de base du réseau doit être régulièrement analysée. Analysez tous les ans l’ensemble du réseau ou déterminez la ligne de base de différentes sections du réseau les unes après les autres. Une analyse régulière permet de comprendre comment le réseau est affecté par la croissance et par d’autres changements.

Page 2 :

Mesure des données de performances réseau

Des logiciels sophistiqués d’administration des réseaux sont souvent utilisés pour déterminer la ligne de base des réseaux étendus et complexes. Par exemple, le module SuperAgent de Fluke Network permet aux administrateurs de créer et de revoir automatiquement des rapports grâce aux références intelligentes. Cette fonction compare les niveaux de performances actuels aux observations antérieures. En un coup d’œil, le service informatique peut automatiquement identifier les problèmes de performances et les applications qui ne fournissent pas les niveaux de service attendus.

Cliquez sur le bouton Commandes manuelles dans la figure.

Dans le cas de réseaux plus simples, la détermination de la ligne de base peut demander à la fois un recueil manuel des données et l’utilisation de simples inspecteurs de protocole réseau. Des heures ou des jours de travail peuvent être nécessaires pour établir une ligne de base initiale ou pour analyser le suivi des performances si l’on souhaite refléter avec précision les performances réseau. Des logiciels d’administration des réseaux ou des sniffeurs et des inspecteurs de protocole peuvent être exécutés en continu pendant le recueil des données. Le recueil manuel des données à l’aide des commandes show sur chaque périphérique réseau prend beaucoup de temps et doit être réservé aux périphériques réseau vitaux.

réseau prend beaucoup de temps et doit être réservé aux périphériques réseau vitaux. CCNA 4 Version
réseau prend beaucoup de temps et doit être réservé aux périphériques réseau vitaux. CCNA 4 Version
8.2-Méthodologie et outils de dépannage Chapitre 8 – Dépannage du Réseau Page 6 sur 36

8.2-Méthodologie et outils de dépannage

Chapitre 8 – Dépannage du Réseau

Page 6 sur 36

8.2.1-Approche Générale du dépannage

Les ingénieurs réseau, les administrateurs et le personnel du support ont conscience que le dépannage est un processus qui occupe la majorité de leur temps. L’utilisation de techniques de dépannage efficaces permet de réduire le temps passé à dépanner un environnement de production.

Deux approches extrêmes du dépannage conduisent quasiment toujours à une déception, un retard ou un échec. D’un côté, l’approche à la Einstein, basée sur la théorie. De l’autre, l’approche de l’homme des cavernes, difficilement applicable.

Avec l’approche à la Einstein, vous ne cessez d’analyser la situation jusqu’à ce que la cause exacte du problème soit identifiée et corrigée avec une précision chirurgicale. Ce processus est certes assez fiable, mais peu d’entreprises peuvent se permettre une panne de réseau pendant des heures ou des jours pendant que l’analyse en profondeur a lieu.

ou des jours pendant que l’analyse en profondeur a lieu. La première idée de l’homme des

La première idée de l’homme des cavernes, c’est de commencer à changer les cartes, les câbles, le matériel et les logiciels jusqu’à ce que le réseau fonctionne de nouveau, comme par miracle. Même si le réseau fonctionne de nouveau, cela ne veut pas dire qu’il fonctionne correctement. Cette approche peut permettre de remédier rapidement aux symptômes, mais elle n’est pas très fiable et ne garantit pas la suppression de la cause principale du problème.

Ces deux approches représentant les extrêmes, la meilleure solution consiste à utiliser les éléments positifs de chaque. Il est important d’analyser le réseau dans son ensemble plutôt que de façon décousue. Une approche méthodique permet de limiter la confusion et de réduire le temps qui serait perdu à faire des essais et à analyser les erreurs.

8.2.2-Utilisation des Modèles en Couches pour le dépannage

Modèles en couches OSI et TCP/IP

Les modèles de réseau logiques, tels que les modèles OSI et TCP/IP, séparent les fonctionnalités réseau en couches modulaires. Au cours du dépannage, ces modèles en couches peuvent être appliqués au réseau physique afin d’isoler les problèmes réseau. Par exemple, si les symptômes font penser à un problème de connexion physique, le technicien réseau peut concentrer ses efforts sur le dépannage du circuit qui fonctionne au niveau de la couche physique. Si ce circuit fonctionne correctement, le technicien analyse d’autres éléments d’une autre couche qui pourraient être à l’origine du problème.

Modèle de référence OSI

à l’origine du problème. Modèle de référence OSI Le modèle OSI fournit aux ingénieurs réseau un

Le modèle OSI fournit aux ingénieurs réseau un langage commun ; il est souvent utilisé lors du dépannage des réseaux. Les problèmes sont généralement décrits en fonction d’une couche de modèle OSI donnée.

Le modèle de référence OSI décrit comment les informations issues d’une application logicielle d’un ordinateur se déplacent via un support réseau vers une application logicielle d’un autre ordinateur.

Chapitre 8 – Dépannage du Réseau Page 7 sur 36 Les couches supérieures (de 5

Chapitre 8 – Dépannage du Réseau

Page 7 sur 36

Les couches supérieures (de 5 à 7) du modèle OSI concernent les problèmes d’application et ne sont généralement mises en œuvre que dans les logiciels. La couche application est la plus proche de l’utilisateur final. Les utilisateurs et les processus de la couche application interagissent avec les applications logicielles qui contiennent un composant de communications.

Les couches inférieures (de 1 à 4) du modèle OSI gèrent les problèmes de transport des données. Les couches 3 et 4 ne sont généralement mises en œuvre que dans les logiciels. La couche physique (couche 1) et la couche liaison de données (couche 2) sont mises en œuvre dans le matériel et les logiciels. La couche physique est la plus proche du support réseau physique, le câblage réseau par exemple, et est chargée de placer les informations sur le support.

Modèle TCP/IP

Semblable au modèle réseau OSI, le modèle réseau TCP/IP divise également l’architecture de réseau en couches modulaires. La figure illustre la correspondance entre le modèle réseau TCP/IP et les couches du modèle réseau OSI. C’est grâce à cette proche correspondance que la suite TCP/IP de protocoles peut communiquer avec autant de technologies réseau.

La couche application de la suite TCP/IP combine en fait les fonctions de trois couches du modèle OSI : session, présentation et application. La couche application assure la communication entre les applications telles que FTP, HTTP et SMTP sur des hôtes distincts.

Les couches transport de TCP/IP et d’OSI ont la même fonction. La couche transport est chargée de l’échange des segments entre périphériques sur un réseau TCP/IP.

La couche Internet du modèle TCP/IP correspond à la couche réseau du modèle OSI. La couche Internet est chargée de mettre les messages dans un format donné afin que les périphériques puissent les gérer.

La couche accès réseau du modèle TCP/IP correspond à la couche physique et à la couche liaison de données du modèle OSI. La couche accès réseau communique directement avec le support réseau et offre une interface entre l’architecture du réseau et la couche Internet.

Cliquez sur le bouton Périphériques - Couches OSI dans la figure.

Placez votre pointeur sur chaque périphérique pour voir les couches OSI que vous devez souvent dépanner pour ce type de périphérique.

vous devez souvent dépanner pour ce type de périphérique. 8.2.3-Procédures générales de dépannage Le suivantes :

8.2.3-Procédures générales de dépannage

Le

suivantes :

processus

général

de

dépannage

comporte

les

étapes

Étape 1 : recueil des symptômes. La première étape du dépannage consiste à recueillir et à documenter les symptômes sur le réseau, les systèmes d’extrémité et auprès des utilisateurs. L’administrateur réseau détermine également les composants du réseau qui ont été affectés et compare la nouvelle fonctionnalité du réseau avec la ligne de base. Les symptômes peuvent prendre différentes formes, notamment des alertes d’un système d’administration de réseaux, des messages de la console et des plaintes des utilisateurs.

des messages de la console et des plaintes des utilisateurs. Lorsque vous recueillez les symptômes, vous

Lorsque vous recueillez les symptômes, vous devez poser des questions afin de réduire le nombre des problèmes possibles.

Chapitre 8 – Dépannage du Réseau Page 8 sur 36 Étape 2 : isolation du

Chapitre 8 – Dépannage du Réseau

Page 8 sur 36

Étape 2 : isolation du problème. Le problème n’est pas réellement isolé tant qu’un seul problème, ou un ensemble de problèmes associés, n’est pas identifié. Pour ce faire, l’administrateur réseau analyse les caractéristiques des problèmes au niveau des couches logiques du réseau afin de pouvoir sélectionner la cause la plus probable. À ce moment-là, l’administrateur réseau peut recueillir et documenter d’autres symptômes en fonction des caractéristiques identifiées.

Étape 3 : correction du problème. Une fois que l’administrateur réseau a isolé et identifié la cause du problème, il essaie de corriger ce problème en mettant en œuvre, en testant et en documentant une solution. Si l’administrateur réseau détermine que l’action corrective a créé un autre problème, il documente la solution essayée, annule les modifications et recommence à recueillir les symptômes et à isoler le problème.

Ces étapes ne s’excluent pas mutuellement. En effet, l’administrateur peut à tout moment être amené à revenir à l’une des étapes précédentes. Il peut par exemple être obligé de recueillir d’autres symptômes pendant qu’il isole un problème. De plus, pendant qu’il essaye de corriger un problème, il est possible qu’un autre problème non identifié soit créé. Il deviendrait ainsi nécessaire de recueillir les symptômes, d’isoler le nouveau problème et de le corriger.

Une stratégie de dépannage doit être établie pour chaque étape. Cette stratégie permet de définir le mode d’action pour chaque étape. Elle doit notamment indiquer que chaque information importante doit être documentée.

8.2.4-Méthodes de dépannage

Page 1 :

Méthodes de dépannage

Il existe trois principales méthodes de dépannage des réseaux :

Ascendante

Descendante

Diviser et conquérir

Chaque approche présente des avantages et des inconvénients. Cette rubrique décrit ces trois méthodes et vous aide à choisir la meilleure méthode selon la situation.

Méthode de dépannage ascendante

selon la situation. Méthode de dépannage ascendante Avec cette méthode, vous commencez par les composants

Avec cette méthode, vous commencez par les composants physiques du réseau et remontez une à une les couches du modèle OSI jusqu’à ce que vous identifiiez la cause du problème. Cette approche est conseillée lorsque vous pensez que le problème est physique. La majorité des problèmes de réseau se situent à des niveaux inférieurs ; l’utilisation de l’approche ascendante offre donc souvent de bons résultats. La figure illustre l’approche ascendante du dépannage.

L’inconvénient de l’approche ascendante du dépannage est qu’elle vous oblige à vérifier chaque périphérique et interface du réseau jusqu’à ce que vous trouviez la cause du problème. N’oubliez pas que chaque conclusion et possibilité doit être documentée ; cela peut donc représenter un travail administratif important. Il n’est pas non plus facile de déterminer les périphériques que vous devez analyser en premier.

Cliquez sur le bouton Méthode descendante dans la figure.

que vous devez analyser en premier. Cliquez sur le bouton Méthode descendante dans la figure. CCNA
Méthode de dépannage descendante Chapitre 8 – Dépannage du Réseau Page 9 sur 36 Avec

Méthode de dépannage descendante

Chapitre 8 – Dépannage du Réseau

Page 9 sur 36

Avec cette méthode, vous commencez par les applications de l’utilisateur final et descendez une à une les couches du modèle OSI jusqu’à ce que vous identifiiez la cause du problème. Les applications de l’utilisateur final d’un système d’extrémité sont testées avant de s’attaquer à des éléments plus précis du réseau. Utilisez cette approche pour des problèmes simples ou lorsque vous pensez que le problème vient d’un logiciel.

L’inconvénient de l’approche descendante est qu’elle vous oblige à vérifier chaque application du réseau jusqu’à ce que vous trouviez la cause du problème. Chaque conclusion et possibilité doit être documentée. Il n’est pas facile de déterminer l’application que vous devez analyser en premier.

Cliquez sur le bouton Méthode Diviser et conquérir dans la figure.

Méthode de dépannage Diviser et conquérir

Lorsque vous appliquez la méthode Diviser et conquérir pour dépanner un problème réseau, vous sélectionnez une couche et testez dans les deux directions à partir de la couche de départ.

Avec cette méthode, vous commencez par recueillir des informations auprès de l’utilisateur ayant eu le problème, vous documentez les symptômes, puis grâce à ces informations, vous décidez de la couche OSI qui constituera le point de départ de votre investigation. Si vous pouvez vérifier qu’une couche fonctionne correctement, vous pouvez généralement supposer que les couches inférieures fonctionnent. Remontez alors une à une les couches du modèle OSI. Si une couche OSI ne fonctionne pas correctement, analysez une à une les couches inférieures du modèle en couches OSI.

à une les couches inférieures du modèle en couches OSI. Par exemple, si des utilisateurs ne

Par exemple, si des utilisateurs ne peuvent pas accéder au serveur Web et que vous réussissez à envoyer une requête ping au serveur, vous savez que le problème se trouve au-dessus de la couche 3. Si vous ne pouvez pas envoyer de requête ping au serveur, vous savez que le problème se situe sans doute au niveau d’une couche OSI inférieure.

Page 2 :

Instructions pour choisir une méthode de dépannage

Pour résoudre rapidement des problèmes de réseau, prenez le temps de sélectionner la méthode de dépannage réseau la plus efficace. Étudiez la figure. Utilisez le processus illustré dans la figure pour vous aider à sélectionner la méthode de dépannage la plus efficace.

Voici par exemple comment choisir une méthode de dépannage pour un problème spécifique. Deux routeurs IP n’échangent pas d’informations de routage. La dernière fois que ce type de problème a eu lieu, il s’agissait d’un problème de protocole. Vous choisissez donc la méthode de dépannage Diviser et conquérir. Grâce à votre analyse, vous savez que la connectivité est correcte entre les routeurs ; vous commencez donc le dépannage au niveau de la couche physique ou liaison de données, vous confirmez la connectivité et vous commencez à tester les fonctions liées au TCP/IP au niveau de la couche supérieure suivante du modèle OSI, à savoir la couche réseau.

au niveau de la couche supérieure suivante du modèle OSI, à savoir la couche réseau. CCNA
8.2.5- Recueil des symptômes Recueil des symptômes Pour déterminer l’étendue du problème, recueillez et documentez

8.2.5- Recueil des symptômes

Recueil des symptômes

Pour déterminer l’étendue du problème, recueillez et documentez les symptômes. Le diagramme de la figure illustre ce processus. Voici une rapide description de chacune des étapes de ce processus :

Étape 1. Analyse des symptômes existants. Analysez les symptômes recueillis grâce au rapport d’incident, auprès des utilisateurs ou sur les systèmes d’extrémité affectés par le problème afin de définir ce problème.

Étape 2. Détermination de la propriété. Si le problème se trouve dans votre système, passez à l’étape suivante. Si le problème n’est pas de votre ressort, par exemple en cas de perte de connectivité Internet en dehors du système autonome, contactez un administrateur du système externe avant de recueillir d’autres symptômes.

Chapitre 8 – Dépannage du Réseau

Page 10 sur 36

Chapitre 8 – Dépannage du Réseau Page 10 sur 36 Étape 3. Réduction de l’étendue. Déterminez

Étape 3. Réduction de l’étendue. Déterminez si le problème se trouve au niveau de la couche cœur de réseau, de distribution ou d’accès du réseau. Au niveau de la couche que vous venez d’identifier, analysez les symptômes existants et servez-vous de vos connaissances de la topologie du réseau pour déterminer les éléments matériels les plus susceptibles d’être la cause du problème.

Étape 4. Recueil des symptômes sur les périphériques suspects. En suivant une approche de dépannage par couche, recueillez les symptômes matériels et logiciels sur les périphériques suspects. Commencez par la cause la plus probable et servez-vous de vos connaissances et de votre expérience pour déterminer si le problème est sans doute plus un problème de configuration matérielle ou logicielle.

Étape 5. Documentation des symptômes. Le problème peut parfois être résolu à l’aide de symptômes documentés. Si ce n’est pas le cas, commencez la phase d’isolation du processus général du dépannage.

Cliquez sur le bouton Commandes dans la figure.

Utilisez les commandes Cisco IOS pour recueillir des symptômes sur le réseau. Le tableau de la figure décrit les commandes Cisco IOS couramment utilisées pour recueillir les informations système d’un problème de réseau.

Bien que la commande debug soit un outil important pour le recueil de symptômes, elle génère une grande quantité de trafic de messages sur la console, ce qui peut affecter les performances d’un périphérique réseau. N’oubliez pas de prévenir les utilisateurs du réseau que vous effectuez un dépannage et que les performances réseau peuvent être affectées. N’oubliez pas de désactiver le débogage lorsque vous avez terminé.

être affectées. N’oubliez pas de désactiver le débogage lorsque vous avez terminé. CCNA 4 Version 4.0
Chapitre 8 – Dépannage du Réseau Page 11 sur 36 Page 2 : Questions aux

Chapitre 8 – Dépannage du Réseau

Page 11 sur 36

Page 2 :

Questions aux utilisateurs finaux

Lorsque vous posez des questions aux utilisateurs finaux à propos d’un problème réseau, utilisez des techniques de questionnement efficaces. Cela vous permettra d’obtenir les informations dont vous avez besoin pour documenter de façon efficace les symptômes d’un problème. Le tableau de la figure offre des instructions et des exemples de questions aux utilisateurs finaux.

et des exemples de questions aux utilisateurs finaux. 8.2.6- Outils de dépannage Page 1 : Outils
et des exemples de questions aux utilisateurs finaux. 8.2.6- Outils de dépannage Page 1 : Outils

8.2.6- Outils de dépannage

Page 1 :

Outils logiciels de dépannage

De nombreux outils logiciels et matériels facilitent le dépannage. Ces outils permettent de recueillir et d’analyser les symptômes de problèmes réseau et sont souvent dotés de fonctions de contrôle et de rapport qui permettent d’établir la ligne de base du réseau.

Outils NMS

Le système d’administration de réseaux (NMS) comprend des outils de contrôle des périphériques, de configuration et de gestion des pannes. La figure illustre un exemple d’écran du logiciel NMS WhatsUp Gold. Ces outils permettent d’analyser et de corriger des problèmes réseau. Le logiciel de surveillance du réseau affiche de façon graphique une vue physique des périphériques réseau, permettant aux administrateurs réseau de surveiller les périphériques distants sans les contrôler physiquement. Les logiciels de gestion des périphériques offrent des informations dynamiques sur l’état, les statistiques et la configuration des produits commutés. CiscoView, HP Openview, Solar Winds et WhatsUp Gold sont des exemples d’outils d’administration de réseaux couramment utilisés.

d’administration de réseaux couramment utilisés. Cliquez sur le bouton Base de connaissances dans la figure

Cliquez sur le bouton Base de connaissances dans la figure pour afficher un exemple de site Web de base de connaissances.

Bases de connaissances

Les bases de connaissances en ligne des fabricants de périphériques réseau sont devenues une source d’informations indispensable. En associant les bases de connaissances des fabricants aux moteurs de recherche sur Internet, tels que Google, un administrateur réseau a accès à de nombreuses informations basées sur l’expérience.

La figure montre la page Tools & Resources (Outils & Ressources) qui se trouve sur le site Web de Cisco à l’adresse http://www.cisco.com. Cet outil gratuit offre en anglais des informations sur le matériel et les logiciels Cisco. Il contient des procédures de dépannage, des guides de mise en œuvre et des livres blancs sur la plupart des aspects de la technologie des réseaux.

Chapitre 8 – Dépannage du Réseau Page 12 sur 36 Cliquez sur le bouton Outils

Chapitre 8 – Dépannage du Réseau

Page 12 sur 36

Chapitre 8 – Dépannage du Réseau Page 12 sur 36 Cliquez sur le bouton Outils de
Chapitre 8 – Dépannage du Réseau Page 12 sur 36 Cliquez sur le bouton Outils de

Cliquez sur le bouton Outils de création d’une ligne de base dans la figure pour voir des exemples d’outils de création d’une ligne de base.

Outils de création d’une ligne de base

De nombreux outils permettent d’automatiser la documentation du réseau et le processus de création d’une ligne de base. Ces outils sont disponibles sous Windows, Linux et AUX. La figure montre un écran des logiciels SolarWinds LANsurveyor et CyberGauge. Les outils de création d’une ligne de base vous assistent dans les tâches courantes de documentation de la ligne de base. Ils peuvent par exemple vous aider à dessiner le diagramme du réseau, à mettre à jour la documentation du matériel et des logiciels réseau et à mesurer de façon rentable l’utilisation de la bande passante sur le réseau.

Cliquez sur le bouton Analyseur de protocole dans la figure pour voir un exemple type d’application d’analyseur de protocole.

Analyseurs de protocole

Un analyseur de protocole décode les différentes couches de protocole dans une trame enregistrée et présente ces informations sous un format relativement facile à utiliser. La figure montre une capture d’écran de l’analyseur de protocole Wireshark. Un analyseur de protocole affiche diverses informations, notamment l’aspect physique, la liaison de données, le protocole et les descriptions de chaque trame. La plupart des analyseurs de protocole peuvent filtrer le trafic répondant à certains critères ; par exemple, l’ensemble du trafic depuis et vers un certain périphérique peut être capturé.

Page 2 :

Outils matériels de dépannage

Cliquez sur les boutons dans la figure pour voir des exemples d’outils matériels de dépannage.

Module d’analyse réseau

Un module d’analyse réseau (NAM) peut être installé sur les commutateurs Cisco Catalyst 6500 et les routeurs Cisco 7600 afin d’obtenir une représentation graphique du trafic provenant de commutateurs et de routeurs locaux et distants. Le module NAM est une interface intégrée basée sur un navigateur qui génère des rapports sur le trafic qui consomme des ressources réseau critiques. De plus, le module NAM peut capturer et décoder des paquets et surveiller les temps de réponse afin d’identifier un problème d’application sur le réseau ou le serveur.

de réponse afin d’identifier un problème d’application sur le réseau ou le serveur. CCNA 4 Version
Multimètres numériques Chapitre 8 – Dépannage du Réseau Les multimètres numériques sont des instruments qui

Multimètres numériques

Chapitre 8 – Dépannage du Réseau

Les multimètres numériques sont des instruments qui permettent de mesurer directement les valeurs électriques de la tension, du courant et de la résistance. Dans le cas d’un dépannage réseau, la majorité des tests multimédia implique la vérification de la tension d’alimentation et la vérification que les périphériques réseau sont bien alimentés.

Testeurs de câble

Les testeurs de câble sont des appareils portables spécialisés qui permettent de tester différents types de câblage de communication de données. Les testeurs de câble peuvent être utilisés pour détecter des câbles rompus ou croisés et des connexions court-circuitées ou mal jumelées. Ces appareils peuvent être des

Page 13 sur 36

jumelées. Ces appareils peuvent être des Page 13 sur 36 dispositifs d’essai de la continuité électrique

dispositifs d’essai de la continuité électrique peu onéreux, des testeurs de câblage moyennement onéreux ou des réflectomètres temporels plus coûteux (TDR).

Les TDR permettent de mesurer la distance qui les sépare d’une coupure d’un câble. Ces appareils émettent des signaux le long du câble et attendent qu’ils soient réfléchis. Le temps entre l’émission du signal et sa réception est ensuite converti en distance. La fonction d’un TDR est traditionnellement associée à des testeurs de câble. Les TDR utilisés pour tester les fibres optiques s’appellent des réflectomètres optiques temporels (OTDR).

des réflectomètres optiques temporels (OTDR). Analyseurs de câble Les analyseurs de câble sont des

Analyseurs de câble

Les analyseurs de câble sont des appareils portables multifonctions qui permettent de tester et de certifier les câbles en cuivre et à fibre optique pour différents services et différentes normes. Les outils les plus perfectionnés comprennent des diagnostics de dépannage avancés qui mesurent la distance entre l’appareil et le point de défaillance (NEXT, RL), identifient les actions correctives et affichent de façon graphique la diaphonie et l’impédance. Les analyseurs de câble comprennent également généralement des logiciels pour PC. Une fois les données recueillies sur le terrain, l’appareil portable peut télécharger les données et des rapports précis et à jour peuvent être créés.

et des rapports précis et à jour peuvent être créés. Analyseurs réseau portables Ces appareils portables

Analyseurs réseau portables

Ces appareils portables permettent de dépanner des réseaux commutés et des réseaux locaux virtuels. En branchant l’analyseur réseau sur le réseau, un ingénieur réseau peut déterminer le port de commutateur auquel le périphérique est connecté ainsi que les utilisations moyenne et maximale. L’analyseur peut également détecter la configuration de réseau local virtuel, identifier les principaux émetteurs, analyser le trafic sur le réseau et afficher les détails de l’interface. L’appareil peut généralement être connecté à un ordinateur sur lequel un logiciel de surveillance du réseau est installé afin d’améliorer l’analyse et le dépannage.

surveillance du réseau est installé afin d’améliorer l’analyse et le dépannage. Page 3 CCNA 4 Version

Page 3

Chapitre 8 – Dépannage du Réseau 8.3-Problèmes Courant avec la mise en œuvre d’un Réseau

Chapitre 8 – Dépannage du Réseau

8.3-Problèmes Courant avec la mise en œuvre d’un Réseau étendu

Page 14 sur 36

8.3.1-Communications dans un Réseau Etendu

Un fournisseur d’accès ou un opérateur télécom est généralement propriétaire des liaisons de données qui constituent un réseau étendu. Les liaisons sont mises à la disposition des abonnés contre paiement et sont utilisées pour interconnecter les réseaux locaux ou se connecter à des réseaux distants. La vitesse de transfert des données (bande passante) d’un réseau étendu est beaucoup plus lente que la bande passante habituelle des réseaux locaux. Les frais de mise en œuvre des liaisons constituent le coût le plus important ; la mise en œuvre d’un réseau étendu doit donc avoir pour objectif de fournir une bande passante maximale à un prix raisonnable. Du fait de la pression exercée par les utilisateurs souhaitant obtenir davantage d’accès à des débits plus élevés et de celle exercée par la direction qui souhaite réduire les coûts, il n’est pas aisé de déterminer la configuration optimale du réseau étendu.

de déterminer la configuration optimale du réseau étendu. Les réseaux étendus transportent divers types de trafic,

Les réseaux étendus transportent divers types de trafic, notamment les données, la voix et la vidéo. La conception sélectionnée doit fournir la capacité et les temps de transfert correspondant aux besoins de l’entreprise. Entre autres spécifications, il faut tenir compte de la topologie des connexions entre les différents sites, de la nature de ces connexions et de la bande passante.

Auparavant, les réseaux étendus consistaient souvent en des liaisons de données assurant la connexion à des ordinateurs centraux distants. De nos jours, les réseaux étendus relient des réseaux locaux séparés géographiquement. Les technologies de réseau étendu fonctionnent au niveau des trois couches inférieures du modèle de référence OSI : les stations des utilisateurs finaux, les serveurs et les routeurs communiquent sur des réseaux locaux et les liaisons de données de réseau étendu se terminent au niveau des routeurs locaux.

Les routeurs déterminent le chemin le plus approprié vers la destination des données à partir des en-têtes de la couche réseau et transfèrent les paquets à la connexion à la liaison de données appropriée en vue de les livrer sur la connexion physique. Les routeurs peuvent également effectuer une gestion par qualité de service (QS), qui alloue des priorités aux différents flux de trafic.

8.3.2-Etapes de la Conception d’un Réseau étendu

Les entreprises utilisent la connectivité de réseau étendu pour répondre aux besoins stratégiques de déplacer des données entre plusieurs filiales. Étant donné que la connectivité de réseau étendu est importante pour l’entreprise et qu’elle est coûteuse, vous devez concevoir le réseau étendu en suivant une approche méthodique. Cette figure illustre les étapes de la conception d’un réseau étendu.

Chaque fois que vous envisagez de modifier un réseau étendu, vous devez suivre ces étapes. Cependant, de nombreux réseaux étendus ayant évolué dans le temps, il se peut que certaines des directives présentées ici n’aient pas été prises en compte. Les modifications d’un réseau étendu peuvent survenir suite au développement des serveurs de réseau étendu de l’entreprise ou l’adoption de nouvelles pratiques ou méthodes de travail.

La conception ou la modification d’un réseau étendu comporte les étapes suivantes :

Étape 1. Localisation des réseaux locaux. Établissez les points d’extrémité source et de destination qui se connecteront via le réseau étendu.

Étape 2. Analyse du trafic. Déterminez quel trafic de données doit être acheminé, son origine et sa destination. Les réseaux étendus acheminent différents types de trafic, avec des besoins différents en termes de bande passante, latence et gigue. Pour chaque paire de points d’extrémité et pour chaque type de trafic, il est nécessaire d’obtenir des informations sur les diverses caractéristiques du trafic.

il est nécessaire d’obtenir des informations sur les diverses caractéristiques du trafic. CCNA 4 Version 4.0
Chapitre 8 – Dépannage du Réseau Page 15 sur 36 Étape 3. Planification de la

Chapitre 8 – Dépannage du Réseau

Page 15 sur 36

Étape 3. Planification de la topologie. La topologie est influencée par des considérations géographiques, mais également par d’autres besoins, tels que la disponibilité. Une grande disponibilité demande des liaisons supplémentaires offrant des chemins de données supplémentaires pour la redondance et l’équilibrage de la charge.

Étape 4. Estimation de la bande passante requise. Le trafic sur les liaisons peut présenter divers besoins en matière de latence et de gigue.

Étape 5. Choix de la technologie de réseau étendu. Vous devez sélectionner les technologies de liaison adéquates.

Étape 6. Évaluation des coûts. Une fois que vous avez déterminé toutes les conditions requises, vous pouvez déterminer les coûts d’installation et d’exploitation du réseau étendu et les comparer aux besoins de l’entreprise à l’origine de la mise en œuvre du réseau étendu.

Comme l’illustre la figure, les étapes de la conception décrites ici ne constituent pas un processus linéaire. Il peut être nécessaire de répéter ces étapes avant de finaliser une conception. Afin de maintenir des performances optimales sur le réseau étendu, il est nécessaire d’effectuer une surveillance et une réévaluation constantes.

8.3.3-Considérations sur le trafic d’un Réseau Local

Le tableau de la figure illustre la grande variété de types de trafic et les besoins relatifs à la bande passante, la latence et la gigue.

Pour déterminer les conditions du flux de trafic et la durée d’une liaison de réseau étendu, vous devez analyser les caractéristiques du trafic spécifiques à chaque réseau local connecté au réseau étendu. Pour déterminer ces caractéristiques, vous pouvez être amené à consulter les utilisateurs du réseau et à évaluer leurs besoins.

les utilisateurs du réseau et à évaluer leurs besoins. 8.3.4-Considérations sur la Topologie du réseau étendu

8.3.4-Considérations sur la Topologie du réseau étendu

Page 1 :

Une fois que vous avez établi les points d’extrémité du réseau local et les caractéristiques du trafic, l’étape suivante de la mise en œuvre d’un réseau étendu consiste à concevoir une topologie appropriée. Pour concevoir la topologie d’un réseau étendu, vous devez effectuer les opérations suivantes :

Sélectionner un motif ou une configuration d’interconnexion pour les liaisons entre les divers sites

Sélectionner les technologies permettant à ces liaisons de répondre aux besoins de l’entreprise à un coût raisonnable

Cliquez sur les boutons dans la figure pour voir un exemple de chaque type de topologie de réseau étendu.

Chapitre 8 – Dépannage du Réseau Page 16 sur 36 De nombreux réseaux étendus s’appuient

Chapitre 8 – Dépannage du Réseau

Page 16 sur 36

De nombreux réseaux étendus s’appuient sur une topologie en étoile. Lorsque l’entreprise se développe et que de nouvelles filiales apparaissent, ces dernières sont connectées au siège pour produire une topologie en étoile traditionnelle. Les points d’extrémité de l’étoile sont parfois interconnectés, créant une topologie à maillage global ou partiel. Ceci offre de nombreuses combinaisons possibles d’interconnexion. Lors de la conception, de la réévaluation ou de la modification d’un réseau étendu, il est nécessaire de sélectionner une topologie répondant aux besoins de la conception.

Lors de la sélection d’une configuration, plusieurs facteurs doivent

sélection d’une configuration, plusieurs facteurs doivent être pris en compte. Un nombre plus important de liaisons

être pris en compte. Un nombre plus important de liaisons augmente le coût des services de réseau, alors que plusieurs chemins entre les destinations augmentent la fiabilité. En revanche, l’ajout de périphériques réseau sur le chemin des données augmente la latence et réduit la fiabilité. En général, chaque paquet doit être entièrement reçu par un nœud avant d’être transmis au suivant.

Cliquez sur le bouton Hiérarchique dans la figure.

La solution hiérarchique est recommandée lorsque de nombreux sites doivent être reliés. Imaginons par exemple une entreprise dont l’activité s’étend à chaque pays de l’Union Européenne et disposant d’une filiale dans chaque ville de plus de 10 000 habitants. Chaque filiale a un réseau local et il a été décidé d’interconnecter les filiales. Un réseau maillé n’est évidemment pas réalisable car il faudrait des centaines de milliers de liaisons.

La solution consiste donc à mettre en œuvre une topologie hiérarchique. Regroupez les réseaux locaux dans chaque zone et créez des interconnexions entre elles pour former une région ; créez des interconnexions entre les diverses régions pour former le cœur du réseau étendu. La zone peut être basée sur le nombre de sites à connecter, avec une limite supérieure située entre 30 et 50. La zone peut adopter une topologie en étoile, les concentrateurs des étoiles étant reliés pour former la région. Les régions peuvent être géographiques et compter entre trois et 10 zones, le concentrateur de chaque région pouvant être relié en point à point.

de chaque région pouvant être relié en point à point. Une hiérarchie à trois couches s’avère
de chaque région pouvant être relié en point à point. Une hiérarchie à trois couches s’avère

Une hiérarchie à trois couches s’avère souvent utile lorsque le trafic du réseau reproduit la structure de filiales de l’entreprise et est divisé en régions, zones et filiales. Elle est également utile lorsqu’il existe un service central auquel toutes les filiales doivent avoir accès, mais que les niveaux de trafic sont insuffisants pour justifier la connexion directe d’une filiale au service.

Le réseau local situé au centre de la zone peut disposer de nombreux serveurs fournissant des services au niveau de la zone et au niveau local. En fonction des volumes et des types de trafic, les connexions d’accès peuvent être commutées, louées ou de type relais de trames. Le relais de trames (Frame Relay) facilite le maillage pour la redondance, sans demander l’ajout de connexions physiques supplémentaires. Les liaisons de distribution peuvent être de type Frame Relay ou ATM et le cœur du réseau peut être une ligne louée ou ATM.

être de type Frame Relay ou ATM et le cœur du réseau peut être une ligne
Chapitre 8 – Dépannage du Réseau Page 17 sur 36 Lors de la planification de

Chapitre 8 – Dépannage du Réseau

Page 17 sur 36

Lors de la planification de réseaux plus simples, une topologie hiérarchique doit toujours être envisagée car elle offre une meilleure évolutivité au réseau. Le concentrateur situé au centre d’un modèle à deux couches constitue également un cœur, mais sans que d’autres routeurs de cœur de réseau n’y soient connectés. De même, avec une solution à une seule couche, le concentrateur de la zone sert de concentrateur régional et de concentrateur cœur. Cela permet une croissance future facile et rapide, la conception de base pouvant être répliquée pour y ajouter de nouvelles zones de service.

Page 2 :

Technologies des connexions WAN

Un réseau étendu privé typique utilise une combinaison de technologies généralement choisies en fonction du type et du volume de trafic. Les technologies RNIS, DSL, Frame Relay ou les lignes louées sont utilisés pour connecter les filiales individuelles à une zone. Frame Relay, ATM ou les lignes louées permettent de reconnecter les zones externes au réseau fédérateur. ATM ou les lignes louées constituent le réseau fédérateur du réseau étendu. Les technologies qui demandent l’établissement d’une connexion avant que les données ne puissent être transmises, tels que le téléphone analogique, le RNIS ou X.25, ne sont pas adaptées aux réseaux étendus qui nécessitent des temps de réponse rapides ou une faible latence.

des temps de réponse rapides ou une faible latence. Les différentes parties d’une entreprise peuvent être

Les différentes parties d’une entreprise peuvent être connectées directement au moyen de lignes louées ou être connectées à l’aide d’une liaison d’accès au point de présence le plus proche d’un réseau partagé. Frame Relay et ATM sont des exemples de réseaux partagés. Les lignes louées sont généralement plus coûteuses que les liaisons d’accès, mais peuvent offrir pratiquement n’importe quel débit et présentent des niveaux très faibles de latence et de gigue.

Les réseaux ATM et Frame Relay peuvent transporter du trafic provenant de plusieurs clients sur les mêmes liaisons internes. L’entreprise n’a aucun contrôle sur le nombre de liaisons ou de sauts que les données doivent traverser sur le réseau partagé. Elle ne peut pas contrôler la durée d’attente des données au niveau de chaque nœud avant le passage à la liaison suivante. Ces niveaux incertains de latence et de gigue rendent ces technologies peu adaptées à certains types de trafic réseau. Toutefois, les inconvénients d’un réseau partagé sont souvent compensés par ses coûts réduits. Comme plusieurs clients partagent la liaison, les coûts qui incombent à chacun sont généralement inférieurs à ceux d’une liaison directe de même capacité.

Bien qu’ATM soit un réseau partagé, il a été conçu pour produire des niveaux minimes de latence et de gigue grâce à des liaisons internes à haute vitesse permettant de transférer des unités de données faciles à gérer, les cellules. Les cellules ATM ont une longueur fixe de 53 octets, 48 pour les données et 5 pour l’en-tête. ATM est très utilisé pour transporter du trafic urgent.

Frame Relay peut également être utilisé pour le trafic urgent ; il est alors souvent associé à des mécanismes QS afin de donner la priorité aux données les plus sensibles.

Page 3 :

De nombreux réseaux étendus d’entreprise disposent de connexions Internet. Bien qu’Internet puisse poser des problèmes de sécurité, il offre également d’autres possibilités pour le trafic inter-filiales. La partie du trafic qui doit être prise en compte lors de la conception se dirige vers Internet ou en provient. Traditionnellement, la mise en œuvre se fait de sorte que chaque réseau de la société se connecte à un FAI différent ou que tous les réseaux de la société se connectent à un même FAI à partir d’une connexion de couche cœur de réseau.

se connectent à un même FAI à partir d’une connexion de couche cœur de réseau. CCNA
Chapitre 8 – Dépannage du Réseau Page 18 sur 36 8.3.5-Considération sur la Bande Passante

Chapitre 8 – Dépannage du Réseau

Page 18 sur 36

Chapitre 8 – Dépannage du Réseau Page 18 sur 36 8.3.5-Considération sur la Bande Passante des

8.3.5-Considération sur la Bande Passante des Réseaux Etendus

Souvenez-vous qu’un réseau doit répondre aux besoins d’une entreprise. De nombreuses sociétés comptent sur le transfert de données à haut débit entre des sites distants. Par conséquent, elles doivent impérativement disposer d’une large bande passante car cela leur permet de transmettre des données plus rapidement. Lorsque la bande passante ne répond pas aux besoins, la concurrence entre différents types de trafic provoque l’augmentation des temps de réponse, ce qui réduit la productivité des employés et ralentit les processus métier Web critiques.

La figure indique comment les liaisons de réseau étendu sont traditionnellement réparties entre haut débit et bas débit.

8.3.6-Problèmes Courants avec la mise en œuvre d’un réseau étendu

La figure résume les problèmes qui se produisent couramment lors de la mise en œuvre d’un réseau étendu et les questions auxquelles vous devez répondre avant de pouvoir mettre en œuvre de façon efficace un réseau étendu.

mettre en œuvre de façon efficace un réseau étendu. 8.3.7-Etude de cas : dépannage d’un réseau

8.3.7-Etude de cas : dépannage d’un réseau étendu du point de vue d’un FAI

Le tableau contient les questions qu’un technicien d’assistance d’un FAI devrait poser à un client appelant pour obtenir de l’aide.

Une grande partie des appels d’assistance reçus par un FAI concernent la lenteur du réseau. Pour résoudre efficacement ce problème, vous devez isoler les composants individuels et les tester comme ceci :

Hôte d’un ordinateur individuel : la lenteur attribuée au réseau peut être due au fait que de nombreuses applications sont ouvertes simultanément sur l’ordinateur. Des outils tels que le Gestionnaire des tâches Windows peuvent aider à déterminer l’utilisation de l’UC.

Réseau local : si le réseau local du client est équipé d’un logiciel de surveillance du réseau, l’administrateur réseau doit être capable d’indiquer si la bande passante du réseau local atteint souvent les 100 % d’utilisation. Ce problème devrait être résolu en interne par la société du client. C’est pourquoi une ligne de base du réseau et une surveillance permanente sont si importantes.

Liaison entre la périphérie du réseau de l’utilisateur et la périphérie du FAI : testez la liaison entre le routeur de périphérie du client et le routeur de périphérie du FAI en demandant au client de se connecter à leur routeur et d’envoyer cent requêtes ping avec 1 500 octets de données à l’adresse IP du routeur de périphérie du FAI. Ce problème ne peut pas être résolu par le client ; il incombe au FAI de demander au fournisseur de liaisons de le corriger.

Réseau fédérateur du FAI : le représentant du service clientèle du FAI peut exécuter des requêtes ping avec 1 500 octets de données depuis le routeur de périphérie du FAI vers le routeur de périphérie

octets de données depuis le routeur de périphérie du FAI vers le routeur de périphérie CCNA
Chapitre 8 – Dépannage du Réseau Page 19 sur 36 du client. Il peut également

Chapitre 8 – Dépannage du Réseau

Page 19 sur 36

du client. Il peut également exécuter ces mêmes requêtes ping sur chaque liaison utilisée par le trafic du client. En isolant et en testant chaque liaison, le FAI peut déterminer quelle liaison est à l’origine du problème.

Serveur accédé : dans certains cas, la lenteur attribuée au réseau est en fait due à l’encombrement du serveur. Ce problème est le plus difficile à diagnostiquer ; il doit s’agir de la dernière option envisagée, une fois que toutes les autres options ont été éliminées.

8.4-Dépannage du Réseau

8.4.1-Interprétation des Diagrammes de Réseau pour identifier des problèmes

Il est quasiment impossible de dépanner n’importe quel type de problème de connectivité réseau sans avoir recours à un diagramme du réseau qui indique notamment les adresses IP, les routes IP et les périphériques tels que les pare-feu et les commutateurs. En règle générale, les topologies logiques et physiques sont utiles au dépannage.

Diagramme physique du réseau

Un diagramme physique du réseau indique la disposition physique des périphériques connectés au réseau. Vous devez savoir comment les périphériques sont physiquement connectés pour pouvoir résoudre des problèmes au niveau de la couche physique, notamment les problèmes de câblage ou de matériel. Ce diagramme comprend généralement les informations suivantes :

comprend généralement les informations suivantes : ∑ le type de périphérique ; ∑ le modèle et

le type de périphérique ;

le modèle et le fabricant ;

la version du système d’exploitation ;

le type et l’identificateur de câble ;

les spécifications du câble ;

le type de connecteur ;

les points d’extrémité de câblage.

La figure présente un exemple de diagramme physique du réseau qui fournit des informations sur l’emplacement physique des périphériques réseau, sur les types de câble entre eux et sur les numéros d’identification des câbles. Ces informations sont essentiellement utilisées pour la résolution de problèmes physiques au niveau des périphériques ou des câbles. En plus du diagramme physique du réseau, certains administrateurs ajoutent des photos des locaux techniques à la documentation du réseau.

Diagramme logique du réseau

Un diagramme logique du réseau indique comment les données sont transférées sur le réseau. Les éléments tels que les routeurs, les serveurs, les concentrateurs, les hôtes, les concentrateurs VPN et les périphériques de sécurité sont représentés par des symboles. Un diagramme logique de réseau peut comprendre les informations suivantes :

les identificateurs de périphériques ;

l’adresse IP et le sous-réseau ;

les identificateurs d’interfaces ;

le type de connexion ;

le DLCI pour les circuits virtuels ;

les réseaux privés virtuels de site à site ;

les protocoles de routage ;

les routes statiques ;

virtuels de site à site ; ∑ les protocoles de routage ; ∑ les routes statiques
∑ les protocoles liaison de données ; ∑ les technologies de réseau étendu utilisées. Chapitre

les protocoles liaison de données ;

les technologies de réseau étendu utilisées.

Chapitre 8 – Dépannage du Réseau

Page 20 sur 36

Cliquez sur le bouton Logique dans la figure pour afficher un exemple de diagramme logique d’un réseau.

La figure illustre le même réseau, mais elle fournit cette fois des informations logiques telles que l’adresse IP de périphériques spécifiques, les numéros de réseau et de port, les types de signal et les affectations DCE pour les liaisons série. Ces informations peuvent être utiles pour la résolution de tous les problèmes, quelle que soit la couche OSI.

8.4.2-Dépannage de la couche physique

Page 1 :

Symptômes des problèmes au niveau de la couche physique

La couche physique transmet des bits d’un ordinateur à un autre et régule la transmission d’un flux de bits sur le support physique. La couche physique est la seule couche avec des propriétés physiquement concrètes, par exemple les câbles, les cartes et les antennes.

Des pannes et des conditions non optimales au niveau de la couche physique sont gênantes pour les utilisateurs et peuvent avoir des conséquences sur la productivité de l’ensemble de l’entreprise. Les réseaux confrontés à ce type de conditions s’arrêtent souvent brusquement. Les couches supérieures du modèle OSI dépendant de la couche physique pour fonctionner, un technicien réseau doit être capable d’isoler et de corriger de façon efficace les problèmes au niveau de cette couche.

de façon efficace les problèmes au niveau de cette couche. Un problème se produit au niveau

Un problème se produit au niveau de la couche physique lorsque les propriétés physiques de la connexion sont inférieures à la norme, provoquant le transfert des données à une vitesse constamment inférieure à la vitesse du flux de données établie dans la ligne de base. Si un problème d’exploitation non optimale se situe au niveau de la couche physique, le réseau peut être opérationnel, mais les performances sont inférieures au niveau spécifié dans la ligne de base, de façon constante ou par intermittence.

Les problèmes réseau au niveau de la couche physique peuvent avoir les symptômes courants suivants :

Performances inférieures à la ligne de base : si les performances ne sont jamais satisfaisantes, le problème est probablement lié à une mauvaise configuration, à une capacité inadéquate ou à un autre problème au niveau du système. Si les performances varient et qu’elles sont parfois satisfaisantes, le problème est probablement lié à une erreur ou à l’effet du trafic provenant d’autres sources. Des serveurs surchargés ou sous-alimentés, des configurations de commutateur ou de routeur inadéquates, l’encombrement du trafic sur une liaison à faible capacité et la perte chronique de trames sont les raisons les plus courantes de faibles performances.

Perte de connectivité : si un câble ou un périphérique est défaillant, le symptôme le plus évident est la perte de connectivité entre les périphériques qui communiquent sur cette liaison ou avec le périphérique ou l’interface en échec, comme peut le montrer un simple test de requête ping. La perte intermittente de connectivité pourrait indiquer qu’une connexion est lâche ou oxydée.

Nombre de collisions élevé : les problèmes de domaine de collision affectent le support local et gênent les communications avec les périphériques d’infrastructure de couche 2 ou 3, les serveurs locaux ou les services. Les collisions sont normalement un problème plus important sur les supports partagés que sur les ports du commutateur. La moyenne du nombre de collisions sur un support partagé doit généralement être inférieure à 5 %, bien que ce nombre soit dans la moyenne basse. Assurez-vous que les décisions soient prises en fonction de la moyenne du nombre de collisions et non d’une pointe. Avec les problèmes liés aux collisions, il est souvent possible de remonter à une source unique. Il peut s’agir d’un câble défectueux sur une station donnée, d’un câble de liaison montante défectueux sur un concentrateur ou un port sur un concentrateur ou d’une liaison exposée à une interférence électrique externe. Une source d’interférence à proximité d’un câble ou d’un concentrateur peut provoquer des collisions même s’il n’y a pas de trafic apparent pour les provoquer. Si les collisions s’aggravent en corrélation avec le niveau du trafic, si la quantité de collisions approche les 100 % ou s’il n’y a pas du tout de trafic correct, le système de câblage est peut-être défaillant.

Chapitre 8 – Dépannage du Réseau Page 21 sur 36 ∑ Goulots d’étranglement sur le

Chapitre 8 – Dépannage du Réseau

Page 21 sur 36

Goulots d’étranglement sur le réseau ou encombrement : si un routeur, une interface ou un câble connaît une défaillance, les protocoles de routage peuvent rediriger le trafic vers d’autres routes qui ne sont pas conçues pour supporter la capacité supplémentaire. Cela peut provoquer un encombrement ou des goulots d’étranglements au niveau de ces éléments du réseau.

Forte utilisation de l’UC : une forte utilisation de l’UC indique qu’un périphérique, par exemple un routeur, un commutateur ou un serveur, fonctionne à la limite autorisée par sa conception ou la dépasse. Si le problème n’est pas rapidement résolu, la surcharge de l’UC peut entraîner une défaillance ou la panne du périphérique.

Messages d’erreur sur la console : les messages d’erreur qui apparaissent sur la console du périphérique indiquent un problème de couche physique.

Page 2 :

Causes des problèmes au niveau de la couche physique

Les problèmes réseau au niveau de la couche physique sont souvent dus aux problèmes suivants :

Problèmes d’alimentation

Les problèmes d’alimentation sont la principale source des problèmes réseau. L’alimentation en courant alternatif arrive dans un module (externe ou interne) de conversion de courant alternatif en courant continu qui se trouve dans un périphérique. Le transformateur fournit un courant continu correctement modulé, qui alimente les circuits, les connecteurs, les ports et les ventilateurs du périphérique. Si vous pensez que le problème vient de l’alimentation, vous pouvez inspecter le module d’alimentation. Assurez-vous que les ventilateurs fonctionnent correctement et que l’arrivée et la sortie d’air du châssis sont dégagées. Si d’autres unités voisines se sont également mises hors tension, une panne de courant s’est peut-être produite.

Défauts matériels

Des cartes réseau défectueuses peuvent être la cause des erreurs de transmission réseau en raison de collisions tardives, de trames courtes et d’émissions incontrôlées (ou jabber). Une émission incontrôlée est souvent définie comme une condition au cours de laquelle un périphérique réseau transmet continuellement et de façon aléatoire des données vides de sens sur le réseau. Une émission incontrôlée peut également être due à des fichiers du pilote de la carte réseau défectueux ou corrompus ou des problèmes de câbles ou de mise à la terre.

Défauts de câblage

De nombreux problèmes peuvent être résolus en débranchant et en rebranchant les câbles qui se sont légèrement déconnectés. Lorsque vous inspectez les câbles, assurez-vous qu’ils sont en bon état, que les types de câble sont adéquats et que les câbles RJ-45 sont correctement sertis. Les câbles suspects doivent être testés ou remplacés par des câbles qui fonctionnent.

Assurez-vous que les câbles croisés sont correctement utilisés et que des ports de concentrateur et de commutateur ne sont pas par mégarde configurés comme ports de croisement. Si les paires sont séparées, les câbles fonctionneront mal ou pas du tout, selon la vitesse Ethernet utilisée, la longueur du segment séparé et la distance par rapport aux extrémités.

Les problèmes de câbles à fibre optique peuvent être provoqués par des connecteurs sales, des courbures trop serrées et des connexions RX/TX permutées lorsqu’elles sont polarisées.

Des problèmes de câble coaxial se produisent souvent au niveau des connecteurs. Lorsque le conducteur central de l’extrémité du câble coaxial n’est pas droit et que sa longueur n’est pas correcte, la connexion obtenue ne sera pas bonne.

Atténuation

Un flux de données atténué se produit lorsque l’amplitude des bits est réduite lors de la circulation sur un câble. Si l’atténuation est grave, le périphérique récepteur ne parvient pas toujours à faire la distinction entre chaque bit de composant du flux. À cause de cela, la transmission est altérée et le périphérique récepteur doit demander à l’expéditeur de transmettre de nouveau le trafic qui n’est pas passé. L’atténuation peut se produire lorsque la longueur d’un câble dépasse la limite de conception pour ce support (par exemple, un câble Ethernet est limité à 100 mètres pour que les performances soient bonnes) ou lorsqu’une connexion est faible à cause d’un câble lâche ou de contacts sales ou oxydés.

Bruit Chapitre 8 – Dépannage du Réseau Page 22 sur 36 On désigne souvent par

Bruit

Chapitre 8 – Dépannage du Réseau

Page 22 sur 36

On désigne souvent par « bruit » l’ensemble des perturbations électromagnétiques (ou EMI) locales. Il existe quatre types de bruit qui s’appliquent particulièrement aux réseaux de données :

Le bruit impulsif est provoqué par les fluctuations ou les pointes de tension sur les câbles.

Le bruit blanc ou aléatoire est généré par de nombreuses sources, notamment les stations de radio FM, la radio de la police, la sécurité d’un bâtiment et l’électronique aéronautique pour les atterrissages automatiques.

La paradiaphonie étrangère est le bruit produit par d’autres câbles adjacents.

La paradiaphonie (ou diaphonie locale) est le bruit produit par la diaphonie de câbles adjacents ou le bruit des câbles électriques voisins, des périphériques équipés de gros moteurs électriques ou de tout matériel comprenant un émetteur plus puissant qu’un téléphone portable.

Erreurs de configuration de l’interface

portable. Erreurs de configuration de l’interface De nombreux éléments peuvent être mal configurés sur une

De nombreux éléments peuvent être mal configurés sur une interface, ce qui peut entraîner sa panne suite à la perte de la connectivité avec des segments réseau liés. Les erreurs suivantes sont des exemples de problèmes de configuration qui affectent la couche physique :

Liaisons série reconfigurées comme asynchrones plutôt que synchrones

Fréquence d’horloge incorrecte

Source d’horloge incorrecte

Interface non activée

Dépassement des limites de conception

Un composant peut ne pas fonctionner de façon optimale au niveau de la couche physique car il est utilisé à un débit moyen supérieur au maximum autorisé par la configuration. Lorsque vous dépannez ce type de problème, il devient évident que les ressources du périphérique fonctionnent au maximum de sa capacité (ou s’en approchent) et le nombre d’erreurs d’interface augmente.

Surcharge de l’UC

Des processus avec un fort pourcentage d’utilisation de l’UC, des abandons dans la file d’attente d’entrée, des faibles performances, des services de routeur tels que Telnet et ping qui sont lents ou qui ne répondent pas et l’absence de mise à jour de routage sont des exemples de symptômes. L’une des causes de la surcharge de l’UC dans un routeur est le volume du trafic. Si certaines interfaces sont régulièrement surchargées à cause du trafic, pensez à modifier le flux du trafic dans le réseau ou à améliorer le matériel.

Page 3 :

Pour isoler les problèmes au niveau des couches physiques, procédez comme suit :

Vérifiez que les câbles ou les connexions sont corrects

Vérifiez que le câble de l’interface source est correctement connecté et est en bon état. Votre testeur de câble permet de vérifier si le câblage est ouvert. Par exemple, dans la figure, le testeur CableIQ de Fluke Networks a détecté que les câbles 7 et 8 sont défectueux. Si l’intégrité d’un câble est suspecte, remplacez le câble en question par un câble qui fonctionne. En cas de doute sur la connexion, retirez le câble, inspectez le câble et l’interface, puis rebranchez le câble. Si ce câble est connecté à une prise murale suspecte, utilisez un testeur de câble pour vérifier que la prise est correctement raccordée.

Vérifiez que la norme de câblage en vigueur est respectée sur l’ensemble du réseau

Vérifiez que le câble utilisé est approprié. Un câble croisé peut être requis pour des connexions directes entre certains périphériques. Assurez-vous que le câblage est correct. Par exemple, dans la figure, le testeur CableIQ de Fluke Networks a détecté que bien qu’un câble

Chapitre 8 – Dépannage du Réseau Page 23 sur 36 soit correct pour Fast Ethernet,

Chapitre 8 – Dépannage du Réseau

Page 23 sur 36

soit correct pour Fast Ethernet, il ne peut pas prendre en charge 1000BASE-T car les fils 7 et 8 ne sont pas correctement connectés. Ces fils ne sont pas requis pour Fast Ethernet, mais ils le sont dans Gigabit Ethernet.

Vérifiez que le câblage des périphériques est correct

Vérifiez que tous les câbles sont bien branchés aux ports ou aux interfaces adéquats. Vérifiez que toutes les interconnexions sont raccordées au bon emplacement. Si vos locaux techniques sont rangés et organisés, cela vous permettra de gagner beaucoup de temps.

Vérifiez que les configurations d’interfaces sont correctes

Vérifiez que tous les ports de commutateur sont définis dans le bon réseau local virtuel et que les paramètres de Spanning Tree, de vitesse et d’option bidirectionnelle sont correctement configurés. Confirmez qu’aucune interface ou port actif n’est arrêté.

Consultez les statistiques d’utilisation et les taux d’erreurs des données

Utilisez les commandes show de Cisco pour analyser des statistiques telles que les collisions et les erreurs d’entrée et de sortie. Les caractéristiques de ces statistiques dépendent des protocoles utilisés sur le réseau.

dépendent des protocoles utilisés sur le réseau. 8.4.3-Dépannage de la couche liaison de données Page 1

8.4.3-Dépannage de la couche liaison de données

Page 1 :

Symptômes des problèmes sur la couche liaison de données

Le dépannage de problèmes sur la couche 2 peut s’avérer difficile. La configuration et le fonctionnement de ces protocoles sont indispensables à la création d’un réseau fonctionnel et adapté.

Les symptômes relevés couramment en cas de problèmes sur la couche liaison de données vous aident à identifier les problèmes de couche 2. Si vous parvenez à reconnaître ces symptômes, vous pourrez limiter le nombre de causes possibles. Les problèmes réseau au niveau de la couche liaison de données peuvent avoir les symptômes courants suivants :

Pas de fonctionnalité ni de connectivité au niveau de la couche réseau ou à un niveau supérieur

Certains problèmes de couche 2 peuvent empêcher l’échange de trames sur une liaison alors que d’autres problèmes ne font que diminuer les performances réseau.

Les performances réseau sont inférieures à la ligne de base

performances réseau sont inférieures à la ligne de base Deux types de fonctionnement non optimal au

Deux types de fonctionnement non optimal au niveau de la couche 2 peuvent se produire sur un réseau :

Les trames suivent un chemin non logique vers leur destination mais elles arrivent. Une topologie Spanning Tree de couche 2 mal conçue est un exemple de problème qui pourrait amener les trames à suivre un chemin non optimal. Dans ce cas, une utilisation élevée de la bande passante peut être relevée sur des liaisons qui ne devraient pas connaître ce niveau de trafic.

Certaines trames sont abandonnées. Ces problèmes peuvent être identifiés via des statistiques sur le nombre d’erreurs et des messages d’erreur sur la console qui apparaissent sur le commutateur ou le routeur. Dans un environnement Ethernet, une requête ping étendue ou continue indique également si des trames sont abandonnées.

Nombre excessif de diffusions Chapitre 8 – Dépannage du Réseau Page 24 sur 36 Les

Nombre excessif de diffusions

Chapitre 8 – Dépannage du Réseau

Page 24 sur 36

Les systèmes d’exploitation les plus récents utilisent largement les diffusions pour détecter les services réseau et les autres hôtes. Dans le cas d’un nombre excessif de diffusions, il est important d’identifier la source des diffusions. En règle générale, un nombre excessif de diffusions se produit dans les situations suivantes :

applications mal programmées ou mal configurées ;

importants domaines de diffusion de couche 2 ;

problèmes réseau sous-jacents, tels que des boucles STP ou des routes en battement.

Messages sur la console

Un routeur reconnaît parfois qu’un problème s’est produit au niveau de la couche 2 ; il envoie alors un message d’alerte sur la console. Un routeur envoie généralement ce message lorsqu’il détecte un problème lors de l’interprétation des trames entrantes (problèmes d’encapsulation ou de tramage) ou lorsque des messages de test d’activité sont attendus mais qu’ils n’arrivent pas. Le message qui apparaît le plus souvent sur la console pour signaler un problème de couche 2 est le message de panne du protocole de ligne.

Page 2 :

Causes des problèmes sur la couche liaison de données

Les problèmes suivants au niveau de la couche liaison de données provoquent généralement des problèmes de connectivité ou de performances réseau :

Erreurs d’encapsulation

Une erreur d’encapsulation se produit lorsque les bits placés par l’émetteur dans un champ donné ne correspondent pas aux attentes du récepteur. Ce cas se produit lorsque les encapsulations à chaque extrémité d’une liaison de réseau étendu sont configurées différemment.

Erreurs de mappage d’adresses

Dans des topologies de type point à multipoint, Frame Relay ou Ethernet de diffusion, il est essentiel qu’une adresse de destination de couche 2 adéquate soit attribuée à la trame. Elle arrivera ainsi à la bonne destination. Pour ce faire, le périphérique réseau doit faire correspondre une adresse de destination de couche 3 à la bonne adresse de couche 2 à l’aide de cartes statiques ou dynamiques.

de couche 2 à l’aide de cartes statiques ou dynamiques. Lorsque des cartes statiques sont utilisées

Lorsque des cartes statiques sont utilisées dans le relais de trames, l’utilisation d’une carte incorrecte constitue une erreur courante. De simples erreurs de configuration peuvent empêcher la correspondance des informations d’adressage des couches 2 et 3.

Dans un environnement dynamique, le mappage des informations des couches 2 et 3 peut échouer pour les raisons suivantes :

des périphériques peuvent avoir été spécialement configurés pour ne pas répondre aux requêtes ARP (normales ou inverses) ;

les informations de la couche 2 ou 3 mises en mémoire cache peuvent avoir physiquement changées ;

des réponses ARP non valides sont reçues en raison d’une mauvaise configuration ou d’une attaque de sécurité.

Erreurs de trames

Les trames fonctionnent généralement par groupe d’octets de 8 bits. Une erreur se produit lorsqu’une trame ne se termine pas par une limite d’octets de 8 bits. Lorsque cela se produit, le récepteur peut éprouver des difficultés à déterminer où se termine une trame et où commence une autre. Selon la gravité de ce problème, l’interface peut arriver à interpréter certaines trames. S’il y a trop de trames non valides, les messages de test d’activité valides ne peuvent pas être échangés.

Les erreurs de trames peuvent être dues à une ligne série perturbée, un câble mal conçu (trop long ou avec un blindage inadéquat) ou une horloge de ligne CSU mal configurée.

Échecs ou boucles STP Chapitre 8 – Dépannage du Réseau Page 25 sur 36 Le

Échecs ou boucles STP

Chapitre 8 – Dépannage du Réseau

Page 25 sur 36

Le but du protocole STP est de résoudre une topologie physique redondante en topologie arborescente en bloquant les ports redondants. La plupart des problèmes de STP sont relatifs aux problèmes suivants :

Des boucles d’acheminement qui se produisent lorsque dans une topologie redondante, aucun port n’est bloqué et le trafic est transmis indéfiniment en boucles. Lorsque la boucle d’acheminement commence, elle encombre généralement les liaisons présentant la plus faible bande passante le long du chemin. Si toutes les liaisons sont associées à la même bande passante, toutes les liaisons sont encombrées. Cet encombrement provoque la perte de paquets et conduit à l’arrêt du réseau dans le domaine L2 affecté.

Inondation excessive en raison de nombreuses modifications de la topologie STP. Le rôle du mécanisme de modification de la topologie est de corriger les tables d’acheminement de couche 2 une fois que la topologie d’acheminement a changé. Cette opération est nécessaire pour éviter une panne de connectivité car après une modification de topologie, certaines adresses MAC qui étaient auparavant accessibles via certains ports peuvent devenir accessibles via d’autres ports. Une modification de topologie ne devrait pas souvent se produire si le réseau est bien configuré. Lorsqu’une liaison sur un port de commutateur devient active ou inactive, une modification de topologie peut se produire lorsque l’état STP du port est ou était défini sur l’acheminement. Cependant, lorsqu’un port est en battement (c’est-à-dire lorsqu’il oscille entre l’état actif et l’état inactif), cela provoque des modifications répétées de la topologie et des inondations.

La lenteur de la convergence ou de la reconvergence STP, qui peut être due à des différences entre la topologie réelle et la topologie documentée, une erreur de configuration, par exemple une configuration non homogène des compteurs STP, une UC de commutateur surchargée au cours de la convergence ou un défaut logiciel.

Page 3 :

Dépannage de la couche 2 - PPP

défaut logiciel. Page 3 : Dépannage de la couche 2 - PPP Le dépannage des technologies
défaut logiciel. Page 3 : Dépannage de la couche 2 - PPP Le dépannage des technologies

Le dépannage des technologies de la couche 2, telles que les protocoles PPP et Frame Relay, est difficile car les outils habituels de dépannage de la couche 3 ne sont pas disponibles, notamment la requête ping, pour vous aider au-delà de la confirmation que le réseau est en panne. Seule une parfaite compréhension des protocoles et de leur fonctionnement peut permettre à un technicien réseau de choisir la méthodologie de dépannage et les commandes Cisco IOS qui lui permettront de résoudre rapidement le problème.

La plupart des problèmes qui se produisent avec le protocole PPP sont liés à la négociation de liaison. Les étapes suivantes permettent de dépanner le protocole PPP :

Étape 1. Vérifiez que l’encapsulation utilisée aux deux extrémités est correcte à l’aide de la commande show interfaces serial. Dans la figure, à l’étape 1, le résultat de la commande indique que R2 a été faussement configuré pour utiliser l’encapsulation HDLC.

Étape 2. Confirmez que les négociations LCP (Link Control Protocol) ont abouti en recherchant dans le résultat le message LCP Open.

Cliquez sur le bouton Étape 2 dans la figure.

Dans la figure, l’encapsulation sur R2 a été changée en PPP. Le résultat de la commande show interfaces serial affiche le message LCP Open, ce qui indique que les négociations LCP ont abouti.

Chapitre 8 – Dépannage du Réseau Page 26 sur 36 Étape 3. Vérifiez l’authentification aux

Chapitre 8 – Dépannage du Réseau

Page 26 sur 36

Chapitre 8 – Dépannage du Réseau Page 26 sur 36 Étape 3. Vérifiez l’authentification aux deux

Étape 3. Vérifiez l’authentification aux deux extrémités de la liaison à l’aide de la commande debug ppp authentication.

Cliquez sur le bouton Étape 3 dans la figure.

Dans la figure, le résultat de la commande debug ppp authentication indique que R1 ne peut pas authentifier R2 à l’aide du protocole CHAP car le nom d’utilisateur et le mot de passe de R2 n’ont pas été configurés sur R1.

Pour plus d’informations sur le dépannage des mises en œuvre PPP, reportez-vous au chapitre 2, « Protocole PPP ».

Page 4 :

Dépannage de la couche 2 - Frame Relay

Le dépannage des problèmes réseau Frame Relay se décompose en quatre étapes :

Étape 1. Vérifiez la connexion physique entre l’unité CSU/DSU et le routeur. Dans la figure, les connexions physiques entre les routeurs R1 et R2 et leur CSU/DSU correspondant peuvent être vérifiées à l’aide d’un testeur de câble et en vérifiant que tous les LED d’état de l’unité CSU/DSU sont verts. Dans la figure, certains voyants d’état du CSU/DSU au niveau de R3 sont rouges, ce qui indique un possible problème de connectivité entre le CSU/DSU et le routeur R3.

de connectivité entre le CSU/DSU et le routeur R3. Étape 2. Vérifiez à l’aide de la

Étape 2. Vérifiez à l’aide de la commande show frame-relay lmi que le routeur et le fournisseur de relais de trames échangent correctement les informations LMI.

Cliquez sur le bouton Étape 2 dans la figure.

Dans la figure, le résultat de la commande show frame-relay lmi au niveau de R2 ne signale aucune erreur et aucun message perdu. R2 et le commutateur du fournisseur de relais de trames échangent donc correctement les informations LMI.

du fournisseur de relais de trames échangent donc correctement les informations LMI. CCNA 4 Version 4.0
Chapitre 8 – Dépannage du Réseau Page 27 sur 36 Étape 3. Vérifiez à l’aide

Chapitre 8 – Dépannage du Réseau

Page 27 sur 36

Chapitre 8 – Dépannage du Réseau Page 27 sur 36 Étape 3. Vérifiez à l’aide de

Étape 3. Vérifiez à l’aide de la commande show frame-relay pvc que l’état du circuit virtuel permanent est actif.

Cliquez sur le bouton Étape 3 dans la figure.

Dans la figure, le résultat de la commande show frame-relay pvc au niveau de R2 permet de vérifier que l’état du circuit virtuel permanent est actif.

Étape 4. Vérifiez à l’aide de la commande show interfaces serial que l’encapsulation Frame Relay est la même sur les deux routeurs.

Cliquez sur le bouton Étape 4 dans la figure.

Dans la figure, le résultat de la commande show interfaces serial au niveau des routeurs R2 et R3 indique qu’il y a une différence d’encapsulation. Une erreur de configuration fait que R3 utilise l’encapsulation HDLC au lieu de Frame Relay.

Pour plus d’informations sur le dépannage des mises en œuvre de Frame Relay, reportez-vous au chapitre 3, « Protocole Frame Relay ».

Page 5 :

au chapitre 3, « Protocole Frame Relay ». Page 5 : Dépannage de la couche 2
au chapitre 3, « Protocole Frame Relay ». Page 5 : Dépannage de la couche 2

Dépannage de la couche 2 - Boucles STP

Si vous pensez qu’une boucle STP est à l’origine d’un problème de couche 2, vérifiez si le protocole STP est exécuté sur chaque commutateur. Le protocole STP ne doit être désactivé que si le commutateur ne fait pas partie d’une topologie en boucle. Pour vérifier le fonctionnement du protocole STP, utilisez la commande show spanning-tree sur chaque commutateur. Si vous vous rendez compte que le protocole STP ne fonctionne pas, vous pouvez l’activer à l’aide de la commande spanning-treeid-vlan.

Les étapes suivantes vous permettent de dépanner les boucles d’acheminement :

Étape 1. Déterminez l’existence d’une boucle STP.

Lorsqu’une boucle d’acheminement s’est développée sur un réseau, les symptômes suivants apparaissent généralement :

perte de connectivité depuis, vers et via des zones du réseau affectées ;

forte utilisation de l’UC sur les routeurs connectés aux segments ou aux réseaux locaux virtuels affectés ;

forte utilisation des liaisons (souvent 100 %) ;

forte utilisation du fond de panier du commutateur, comparée à l’utilisation de la ligne de base ;

messages syslog indiquant des paquets en boucle sur le réseau (par exemple, des messages d’adresse IP en double du protocole de routeur de secours automatique HSRP) ;

messages syslog indiquant la réacquisition constante des adresses ou les messages de battement des adresses MAC ;

augmentation du nombre d’échecs de sortie sur de nombreuses interfaces.

Chapitre 8 – Dépannage du Réseau Étape 2. Identifiez la topologie (étendue) de la boucle.

Chapitre 8 – Dépannage du Réseau

Étape 2. Identifiez la topologie (étendue) de la boucle.

Page 28 sur 36

La première priorité est d’arrêter la boucle et de restaurer la fonctionnalité du réseau. Pour arrêter la boucle, vous devez connaître les ports qui sont impliqués. Recherchez les ports dont l’utilisation de liaison est la plus forte (en paquets par seconde). La commande show interface indique l’utilisation pour chaque interface. Assurez-vous de noter cette information avant de passer à l’étape suivante. Si vous ne le faites pas, il pourrait vous être difficile plus tard de déterminer la cause de la boucle.

Étape 3. Cassez la boucle.

Arrêtez ou déconnectez les ports impliqués les uns après les autres. Une fois que vous avez désactivé ou déconnecté chaque port, regardez si l’utilisation du fond de panier du commutateur est revenue à un niveau normal. Notez vos conclusions. N’oubliez pas que certains ports n’entretiennent peut-être pas la boucle, mais inondent le trafic arrivant avec la boucle. Lorsque vous désactivez les ports à l’origine des inondations, vous ne réduisez qu’un peu l’utilisation du fond de panier ; vous n’arrêtez pas la boucle.

Étape 4. Déterminez et corrigez la cause de la boucle.

Comprendre pourquoi la boucle a commencé constitue souvent la partie la plus difficile du processus car les raisons sont diverses. Il est également difficile d’établir une procédure qui s’adaptera à tous les cas de figure. Commencez par étudier le diagramme topologique afin de trouver un chemin redondant.

Pour chaque commutateur sur le chemin redondant, recherchez les problèmes suivants :

Le commutateur connaît-il la bonne racine STP ?

Le port racine est-il correctement identifié ?

Les unités Bridge Protocol Data Unit (BPDU) sont-elles reçues régulièrement sur le port racine et sur les ports qui sont censés assurer le blocage ?

Les unités BPDU sont-elles envoyées régulièrement sur des ports non racine désignés ?

Étape 5. Restaurez la redondance.

Une fois que le périphérique ou la liaison à l’origine de la boucle a été trouvé et que le problème a été résolu, vous devez restaurer les liaisons redondantes qui ont été déconnectées.

Nous n’avons traité du dépannage des boucles STP que superficiellement. Le dépannage des boucles et d’autres problèmes de STP est complexe ; une discussion détaillée à ce sujet dépasse le cadre de ce cours. Cependant, si vous voulez en savoir plus sur le dépannage des problèmes de STP.

8.4.4-Dépannage de la couche réseau

Page 1 :

Symptômes des problèmes de couche réseau

Les problèmes de couche réseau englobent tous les problèmes relatifs à un protocole de couche 3, qu’il soit routé ou de routage. Cette rubrique traite principalement des protocoles de routage IP.

Des problèmes au niveau de la couche réseau peuvent entraîner une panne du réseau ou des performances non satisfaisantes. On parle de panne de réseau lorsque le réseau est non fonctionnel (entièrement ou en très grande partie), affectant tous les utilisateurs et toutes les applications du réseau. Ces pannes sont généralement constatées rapidement par les utilisateurs et les administrateurs réseau ; elles ont un impact énorme sur la productivité de l’entreprise. Les problèmes d’optimisation du réseau concernent généralement un ensemble d’utilisateurs, d’applications, de destinations ou un certain type de trafic. Les problèmes d’optimisation sont souvent plus difficiles à détecter et encore plus difficiles à isoler et à diagnostiquer car elles concernent souvent plusieurs couches, voire l’ordinateur hôte lui-même. Déterminer que tel problème est un problème de couche réseau peut prendre du temps.

Déterminer que tel problème est un problème de couche réseau peut prendre du temps. CCNA 4
Chapitre 8 – Dépannage du Réseau Page 29 sur 36 Page 2 : Dépannage de

Chapitre 8 – Dépannage du Réseau

Page 29 sur 36

Page 2 :

Chapitre 8 – Dépannage du Réseau Page 29 sur 36 Page 2 : Dépannage de problèmes

Dépannage de problèmes sur la couche 3

Dans la majorité des réseaux, les routes statiques sont utilisées en conjonction avec les protocoles de routage dynamique. Une mauvaise configuration des routes statiques peut entraîner un routage non optimal ; dans certaines situations, des boucles de routage peuvent même être créées ou des parties du réseau peuvent devenir inaccessibles.

Pour pouvoir dépanner des protocoles de routage dynamique, vous devez parfaitement comprendre comment ils fonctionnent. Certains problèmes sont communs à tous les protocoles de routage tandis que d’autres sont spécifiques à chaque protocole.

Il n’existe pas de modèle unique permettant de résoudre les problèmes de couche 3. Pour résoudre les problèmes de routage, il convient de suivre un processus méthodique en utilisant une série de commandes afin d’isoler et de diagnostiquer le problème.

Vous devez analyser les domaines suivants lorsque vous diagnostiquez un possible problème relatif aux protocoles de routage :

Problèmes généraux de réseau

Une modification de la topologie, par exemple la panne d’une liaison, peut souvent avoir des effets sur d’autres zones du réseau auxquels vous n’auriez pas immédiatement pensés. Il peut s’agir notamment de l’installation de nouvelles routes, statiques ou dynamiques, ou de la suppression d’autres routes.

Les éléments suivants sont à prendre en compte :

Y a-t-il eu récemment une quelconque modification sur le réseau ?

Quelqu’un travaille-t-il actuellement sur l’infrastructure du réseau ?

Problèmes de connectivité

Recherchez d’éventuels problèmes d’équipement et de connectivité, notamment des problèmes d’alimentation tels que des pannes de courant et des problèmes au niveau de l’environnement, par exemple une surchauffe. Recherchez également d’éventuels problèmes de couche 1, notamment des problèmes de câblage, des ports défectueux et des problèmes de FAI.

Problèmes de voisinage

Si le protocole de routage établit une contiguïté avec un voisin, recherchez d’éventuels problèmes avec les routeurs formant la relation de voisinage.

Base de données topologique

Si le protocole de routage utilise une table ou une base de données topologique, assurez-vous que la table est correcte et, par exemple, que des entrées ne sont pas manquantes ou inattendues.

Table de routage

Assurez-vous que la table de routage est correcte et, par exemple, que des routes ne sont pas manquantes ou inattendues. Utilisez les commandes debug pour afficher les mises à jour de routage et la maintenance de la table de routage.

Chapitre 8 – Dépannage du Réseau Page 30 sur 36 8.4.5-Dépannage de la couche Transport

Chapitre 8 – Dépannage du Réseau

Page 30 sur 36

8.4.5-Dépannage de la couche Transport

Page 1 :

Problèmes courants de liste d’accès

Des problèmes réseau peuvent se produire à cause de problèmes de couche transport sur le routeur, particulièrement en périphérie du réseau où les technologies de sécurité analysent et modifient le trafic. Cette rubrique traite de deux des technologies de sécurité de la couche transport les plus souvent mises en œuvre : les listes de contrôle d’accès et la traduction d’adresses de réseau (NAT).

Cliquez sur le bouton Problèmes de liste d’accès dans la figure.

Les problèmes les plus courants avec les listes de contrôle d’accès sont dus à une mauvaise configuration. Ces problèmes de configuration se produisent souvent dans l’un des huit domaines suivants :

Sélection du flux de trafic

L’erreur de configuration la plus courante sur un routeur consiste à appliquer la liste de contrôle d’accès au mauvais trafic. Le trafic est défini par l’interface de routeur via laquelle le trafic est acheminé et par la direction du flux de trafic. Une liste de contrôle d’accès doit être appliquée à la bonne interface et la bonne direction du trafic doit être sélectionnée pour que la liste fonctionne correctement.

Ordre des éléments du contrôle d’accès

Les éléments d’une liste de contrôle d’accès doivent aller du plus spécifique au plus général. Même si une liste de contrôle d’accès dispose d’un élément qui autorise de façon spécifique un certain flux de trafic, les paquets ne correspondront jamais à cet élément s’ils sont refusés par un autre élément situé plus haut dans la liste.

par un autre élément situé plus haut dans la liste. Instruction implicite « deny all »
par un autre élément situé plus haut dans la liste. Instruction implicite « deny all »

Instruction implicite « deny all »

Lorsqu’un niveau élevé de sécurité n’est pas requis sur la liste de contrôle d’accès, l’oubli de cet élément implicite de contrôle d’accès peut être la cause d’une mauvaise configuration de la liste de contrôle d’accès.

Adresses et masques génériques

Si le routeur exécute à la fois des listes de contrôle d’accès et la fonction NAT, l’ordre dans lequel chacune de ces technologies est appliquée à un flux de trafic a de l’importance :

Le trafic entrant est traité par la liste de contrôle d’accès entrante avant d’être traité par la fonction NAT de l’extérieur vers l’intérieur.

Le trafic sortant est traité par la liste de contrôle d’accès sortante après avoir été traité par la fonction NAT de l’intérieur vers l’extérieur.

Les masques génériques complexes permettent d’améliorer l’efficacité de façon significative, mais le risque d’erreurs de configuration est plus grand. Un masque générique complexe peut par exemple consister à utiliser l’adresse 10.0.32.0 et le masque générique 0.0.32.15 pour sélectionner les 15 premières adresses d’hôte dans le réseau 10.0.0.0 ou le réseau 10.0.32.0.

Sélection du protocole de couche transport Chapitre 8 – Dépannage du Réseau Page 31 sur

Sélection du protocole de couche transport

Chapitre 8 – Dépannage du Réseau

Page 31 sur 36

Lorsque vous configurez des listes de contrôle d’accès, il est important de ne spécifier que les bons protocoles de couche transport. Lorsqu’ils ne savent pas si un certain flux de trafic utilise un port TCP ou UDP, de nombreux ingénieurs réseau configurent les deux. Lorsque les deux ports sont spécifiés, un trou se crée dans le pare-feu, laissant la possibilité aux pirates d’accéder au réseau. Cela ajoute également un élément supplémentaire à la liste de contrôle d’accès, ce qui rallonge son temps de traitement et introduit plus de latence dans les communications sur le réseau.

Ports source et de destination

Pour contrôler correctement le trafic entre deux hôtes, des éléments de contrôle d’accès symétriques sont requis pour les listes de contrôle d’accès entrantes et sortantes. L’adresse et les informations de port pour le trafic généré par un hôte correspondent à l’adresse et aux informations de port pour le trafic généré par l’hôte d’origine.

Utilisation du mot clé established

Le mot clé established permet de renforcer la sécurité fournie par une liste de contrôle d’accès. Cependant, si le mot clé est appliqué à une liste de contrôle d’accès sortante, des résultats inattendus peuvent se produire.

Protocoles rares

Des listes de contrôle d’accès mal configurées provoquent souvent des problèmes pour des protocoles moins habituels que TCP et UDP. Les protocoles de réseau privé virtuel et de chiffrement sont des protocoles rares qui gagnent en popularité.

Dépannage des listes de contrôle d’accès

Le mot clé log utilisé sur les entrées de liste de contrôle d’accès permet d’afficher les opérations de cette liste. Ce mot clé demande au routeur de placer une entrée dans le journal du système chaque fois que cette condition d’entrée est satisfaite. L’événement consigné comprend des détails sur le paquet correspondant à l’élément de la liste de contrôle d’accès.

Le mot clé log est particulièrement utile pour le dépannage et fournit également des informations sur les tentatives d’intrusion qui sont bloquées par la liste de contrôle d’accès.

Page 2 :

bloquées par la liste de contrôle d’accès. Page 2 : Problèmes courants de NAT Le problème

Problèmes courants de NAT

Le problème le plus important avec toutes les technologies NAT est l’interopérabilité avec les autres technologies réseau, spécialement celles qui contiennent ou qui récupèrent des informations depuis l’adressage réseau hôte dans le paquet. Les technologies suivantes sont concernées :

BOOTP et DHCP : ces deux protocoles gèrent l’attribution automatique d’adresses IP aux clients. Souvenez-vous que le premier paquet envoyé par un nouveau client est un paquet IP de diffusion de requête DHCP. L’adresse IP source du paquet de requête DHCP est 0.0.0.0. La fonction NAT nécessitant à la fois une adresse IP source et une adresse IP de destination valides, il peut être difficile pour les protocoles BOOTP et DHCP de fonctionner sur un routeur exécutant une fonction NAT statique ou dynamique. Pour résoudre ce problème, vous pouvez configurer la fonction IP Helper.

DNS et WINS : étant donné qu’un routeur exécutant la fonction NAT dynamique modifie régulièrement la relation entre les adresses internes et externes lorsque les entrées de table expirent et sont recréées, un serveur de noms de domaine (DNS) ou un serveur WINS externe à la fonction NAT ne dispose pas d’une représentation exacte du réseau à l’intérieur du routeur. Pour résoudre ce problème, vous pouvez configurer la fonction IP Helper.

SNMP : à l’image des paquets DNS, la fonction NAT ne peut pas modifier les informations d’adressage stockées dans les données utiles du paquet. À cause de cela, il est possible qu’une station d’administration SNMP située d’un côté d’un routeur NAT ne

Chapitre 8 – Dépannage du Réseau Page 32 sur 36 puisse pas contacter les agents

Chapitre 8 – Dépannage du Réseau

Page 32 sur 36

puisse pas contacter les agents SNMP de l’autre côté du routeur NAT. Pour résoudre ce problème, vous pouvez configurer la fonction IP Helper.

Protocoles de transmission tunnel et de chiffrement : les protocoles de transmission tunnel et de chiffrement nécessitent souvent que le trafic soit issu d’un port UDP ou TCP spécifique ou l’utilisation d’un protocole au niveau de la couche transport qui ne puisse pas être traité par la fonction NAT. Par exemple, les protocoles de transmission tunnel IPsec et les protocoles d’encapsulation de routage générique utilisés par les implémentations de réseau privé virtuel ne peuvent pas être traités par la fonction NAT.

Si les protocoles de chiffrement ou de transmission tunnel doivent être exécutés via un routeur NAT, l’administrateur réseau peut créer une entrée NAT statique pour le port requis pour une seule adresse IP à l’intérieur du routeur NAT.

L’une des erreurs de configuration NAT les plus courantes est d’oublier que la fonction NAT affecte à la fois le trafic entrant et sortant. Un administrateur réseau sans expérience pourrait configurer une entrée NAT statique pour rediriger le trafic entrant vers un hôte de sauvegarde interne donné. Cette instruction NAT statique modifie également l’adresse source du trafic de cet hôte, ce qui peut provoquer des résultats inattendus ou un fonctionnement non optimal.

Des compteurs mal configurés peuvent également provoquer des résultats inattendus sur le réseau et un fonctionnement non optimal de la fonction NAT dynamique. Si les compteurs NAT sont trop courts, les entrées de la table NAT peuvent expirer avant que les réponses ne soient reçues ; les paquets sont alors ignorés. La perte de paquets provoque des retransmissions, ce qui consomme plus de bande passante. Si les compteurs sont trop longs, les entrées risquent de rester dans la table NAT plus longtemps que nécessaire, consommant ainsi le pool des connexions disponibles. Si le trafic est dense sur ces réseaux, des problèmes de mémoire peuvent survenir sur le routeur et les hôtes risquent de ne pas pouvoir établir de connexions si la table NAT dynamique est pleine.

Pour plus d’informations sur le dépannage de la configuration NAT, reportez-vous au chapitre 7, « Services d’adressage IP ».

8.4.6-Dépannage de la Couche Application

Page 1 :

IP ». 8.4.6-Dépannage de la Couche Application Page 1 : Présentation de la couche application La

Présentation de la couche application

La plupart des protocoles de couche application fournissent des services aux utilisateurs. Les protocoles de couche application sont généralement utilisés pour l’administration de réseaux, le transfert de fichiers, les services de fichiers distribués, l’émulation de terminal et le courriel. Cependant, de nouveaux services aux utilisateurs sont souvent ajoutés, tels que les réseaux privés virtuels et la voix sur IP.

Les protocoles suivants font partie des protocoles de couche application TCP/IP les plus connus et les plus mis en œuvre :

Telnet : permet aux utilisateurs d’établir des connexions de session de terminal avec des hôtes distants.

HTTP : prend en charge l’échange sur le Web de fichiers texte, image, son, vidéo et d’autres fichiers multimédia.

FTP : assure le transfert interactif de fichiers entre des hôtes.

TFTP : assure le simple transfert interactif de fichiers, généralement entre des hôtes et des périphériques réseau.

SMTP : prend en charge les services de base de livraison des messages.

POP : se connecte aux serveurs de messagerie et télécharge le courriel.

SNMP (Simple Network Management Protocol) : recueille des informations de gestion auprès des périphériques réseau.

DNS : associe les adresses IP aux noms attribués aux périphériques réseau.

Système de fichiers en réseau (NFS) : permet aux ordinateurs d’accéder aux lecteurs sur des hôtes distants et de les utiliser comme s’il s’agissait de lecteurs locaux. Développé à l’origine par Sun Microsystems, ce système se combine à deux autres protocoles de couche application, la représentation externe des données (XDR) et l’appel de procédure distant (RPC), pour permettre un accès transparent aux ressources réseau distantes.

Chapitre 8 – Dépannage du Réseau Page 33 sur 36 Cliquez sur le bouton Protocoles

Chapitre 8 – Dépannage du Réseau

Page 33 sur 36

Chapitre 8 – Dépannage du Réseau Page 33 sur 36 Cliquez sur le bouton Protocoles d’application

Cliquez sur le bouton Protocoles d’application et ports dans la figure pour afficher une liste des protocoles d’application et leur port associé.

Page 2 :

Symptômes des problèmes de couche application

Les problèmes de couche application empêchent les programmes d’application d’accéder aux services. Un problème au niveau de la couche application peut empêcher l’accès ou l’utilisation des ressources alors que les couches physique, liaison de données, réseau et transport sont fonctionnelles. Il est possible que la connectivité réseau soit totale mais que l’application ne puisse simplement pas fournir de données.

Un autre type de problème se produit au niveau de la couche application lorsque les couches physique, liaison de données, réseau et transport sont fonctionnelles mais que le transfert de données et les requêtes de services réseau à partir d’une application ou d’un service réseau unique ne répondent pas aux attentes d’un utilisateur.

Un problème au niveau de la couche application peut amener des utilisateurs à se plaindre de la lenteur du réseau ou de l’application qu’ils utilisent lorsqu’ils transfèrent des données ou lorsqu’ils demandent des services réseau.

des données ou lorsqu’ils demandent des services réseau. La figure illustre certains des symptômes possibles des

La figure illustre certains des symptômes possibles des problèmes de couche application.

Page 3 :

Dépannage des problèmes de couche application

Le processus général de dépannage utilisé pour isoler les problèmes au niveau des couches inférieures peut également être utilisé pour isoler les problèmes au niveau de la couche application. Les concepts sont identiques, mais l’attention se porte plus particulièrement sur des éléments tels que les connexions refusées ou expirées, les listes d’accès et les problèmes de DNS.

Les étapes suivantes permettent de dépanner les problèmes de couche application :

Étape 1. Envoyez une requête ping à la passerelle par défaut.

Si la requête aboutit, les services des couches 1 et 2 fonctionnent correctement.

Étape 2. Vérifiez la connectivité de bout en bout.

Utilisez une requête ping étendue si vous essayez d’envoyer la requête ping depuis un

Utilisez une requête ping étendue si vous essayez d’envoyer la requête ping depuis un CCNA 4
Chapitre 8 – Dépannage du Réseau Page 34 sur 36 routeur Cisco. Si la requête

Chapitre 8 – Dépannage du Réseau

Page 34 sur 36

routeur Cisco. Si la requête aboutit, la couche 3 fonctionne correctement. Si les couches 1 à 3 fonctionnent correctement, le problème doit se situer au niveau d’une couche supérieure.

Étape 3. Vérifiez le fonctionnement de la liste d’accès et de la traduction NAT.

Pour dépanner les listes de contrôle d’accès, procédez comme suit :

Utilisez la commande show access-list. Des listes de contrôle d’accès arrêteraient-elles le trafic ? Notez les listes d’accès qui ont des correspondances.

Réinitialisez les compteurs des listes d’accès à l’aide de la commande clear access-list counters et essayez d’établir à nouveau une connexion.

Vérifiez les compteurs des listes d’accès. Certains compteurs ont-ils augmenté ? Devraient-ils augmenter ?

Pour dépanner la fonction NAT, procédez comme suit :

Utilisez la commande show ip nat translations. Existe-t-il des traductions ? Les traductions sont-elles conformes aux attentes ?

Effacez les traductions NAT à l’aide de la commande clear ip nat translation * et essayez à nouveau d’accéder aux ressources externes.

Utilisez la commande debug ip nat et analysez le résultat.

Analysez le fichier de la configuration courante. Les commandes ip nat inside et ip nat outside sont-elles situées sur les bonnes interfaces ? Le pool NAT est-il correctement configuré ? La liste de contrôle d’accès identifie-t-elle correctement les hôtes ?

Si les listes de contrôle d’accès et la traduction NAT fonctionnent normalement, le problème doit se situer au niveau d’une couche supérieure.

Étape 4. Dépannez la connectivité des protocoles de couche supérieure.

Même si une connectivité IP existe entre une source et une destination, des problèmes peuvent toujours exister pour un protocole de couche supérieure spécifique, tel que FTP, HTTP ou Telnet. Ces protocoles utilisent le transport IP de base mais sont sujets à des problèmes spécifiques aux protocoles et relatifs aux filtres de paquets et aux pare-feu. Il est possible que seul le courriel ne fonctionne pas entre une source et une destination.

Pour pouvoir dépanner un problème de connectivité au niveau du protocole de la couche supérieure, vous devez comprendre le fonctionnement du protocole. Ces informations se trouvent généralement dans le dernier document RFC relatif au protocole ou sur la page Web des développeurs.

relatif au protocole ou sur la page Web des développeurs. Page 4 : Résolution des problèmes

Page 4 :

Résolution des problèmes de couche application

Les étapes suivantes permettent de résoudre les problèmes de couche application :

Étape 1 : création d’une copie de sauvegarde. Avant de poursuivre, assurez-vous qu’une configuration valide a été enregistrée pour tous les périphériques sur lesquels la configuration peut être modifiée. Cela vous permettra de revenir à un état initial connu.

Étape 2 : première modification de la configuration matérielle ou logicielle. Si la correction nécessite plusieurs modifications, n’apportez qu’une modification à la fois.

Étape 3 : évaluation et documentation de chaque modification et de son résultat. Si le résultat d’une étape visant à résoudre le problème n’est pas satisfaisant, annulez immédiatement les modifications. Si le problème est intermittent, attendez de voir si le problème se produit de nouveau avant d’évaluer l’effet de la modification.

Chapitre 8 – Dépannage du Réseau Page 35 sur 36 Étape 4 : déterminer si

Chapitre 8 – Dépannage du Réseau

Page 35 sur 36

Étape 4 : déterminer si la modification résout le problème. Assurez-vous que la modification résout bien le problème sans en créer de nouveaux. Le réseau doit revenir à un fonctionnement conforme à la ligne de base et aucun symptôme (nouveau ou existant) ne doit exister. Si le problème n’est pas résolu, annulez toutes les modifications. Si de nouveaux problèmes ou des problèmes supplémentaires sont détectés, modifiez le plan de correction.

Étape 5 : arrêt lorsque le problème est résolu. N’apportez plus de modifications dès que le problème d’origine semble résolu.

Étape 6 : recours à une aide externe, si nécessaire. Il peut s’agir d’un collègue, d’un consultant ou du centre d’assistance technique (TAC) de Cisco. En de rares occasions, une image mémoire peut être nécessaire ; celle-ci peut être analysée par un spécialiste de Cisco Systems.

Étape 7 : documentation. Une fois le problème résolu, documentez la solution.

8.6-Résumé Chapitre 8 – Dépannage du Réseau Page 36 sur 36 Dans le présent chapitre,

8.6-Résumé

Chapitre 8 – Dépannage du Réseau

Page 36 sur 36

Dans le présent chapitre, vous avez appris qu’une ligne de base du réseau est requise pour effectuer un dépannage efficace. La première étape de la création d’une ligne de base consiste à s’assurer que la documentation réseau est à jour et exacte. Une bonne documentation réseau doit inclure une table de configuration réseau pour tous les périphériques et un diagramme topologique qui indique l’état actuel du réseau. Lorsque le réseau a été entièrement documenté, une mesure de ligne de base des performances réseau doit être prise sur une période allant de plusieurs semaines à un mois afin d’établir la personnalité du réseau. La première ligne de base est créée au moment où le fonctionnement est stable et normal.

Le meilleur moyen de dépanner consiste à suivre une approche méthodique en utilisant un modèle en couches, tels que les modèles OSI ou TCP/IP. Les trois méthodes couramment utilisées pour le dépannage sont les méthodes ascendante, descendante et diviser et conquérir. Chaque méthode présente des avantages et des inconvénients ; vous avez appris à choisir la méthode à appliquer. Vous avez également étudié les différents outils matériels et logiciels qui permettent aux professionnels des réseaux de recueillir des symptômes et de dépanner des problèmes réseau.

Bien qu’ils fonctionnent principalement sur les trois premières couches OSI, les réseaux étendus font l’objet de problèmes de mise en œuvre qui peuvent affecter le fonctionnement du reste du réseau. Vous avez étudié certaines considérations à prendre en compte lors de la mise en œuvre de réseaux étendus et les problèmes qu’introduisent souvent les réseaux étendus dans les réseaux, par exemple les menaces de sécurité, les problèmes de bande passante, la latence et les problèmes de qualité de service (QS).

Enfin, vous avez analysé les symptômes et les causes des problèmes se produisant couramment au niveau de chaque couche OSI et vous avez étudié les étapes menant à leur résolution.

au niveau de chaque couche OSI et vous avez étudié les étapes menant à leur résolution.