Diagnostiquer et résoudre les problèmes de réseau sous Windows. Le processus de diagnostic des défauts dans les réseaux locaux

L'art du diagnostic réseaux locaux

Si les programmes fonctionnent périodiquement lentement, que les ordinateurs se bloquent ou se déconnectent du serveur et que les programmeurs disent que le réseau est responsable de tout et que l'administrateur réseau dit que les programmes sont responsables de tout, alors cet article s'adresse spécifiquement à vous.

Avant de commencer à décrire la méthodologie d'identification des « vices cachés », nous aimerions définir les termes : qu'entend-on en fait par réseau local, diagnostic d'un réseau local et quel type de réseau doit être considéré comme « bon ». .»

Très souvent, le diagnostic d'un réseau local consiste à tester uniquement son système de câblage. Ce n'est pas tout à fait vrai. Le système de câble est l'un des composants les plus importants d'un réseau local, mais il est loin d'être le seul et pas le plus difficile du point de vue du diagnostic. Outre l'état du système de câble, la qualité du fonctionnement du réseau est fortement influencée par l'état équipement actif (cartes réseau, hubs, commutateurs), qualité de l'équipement serveur et paramètres réseau système opérateur. De plus, le fonctionnement du réseau dépend largement des algorithmes de fonctionnement des logiciels d'application qui y sont utilisés.

Par le terme « réseau local », nous comprendrons l'ensemble du matériel ci-dessus et logiciel; et le terme « diagnostic du réseau local » est le processus de détermination des causes d'un fonctionnement insatisfaisant logiciel d'application en ligne. C'est la qualité des logiciels d'application sur le réseau qui est déterminante du point de vue des utilisateurs. Tous les autres critères, tels que le nombre d'erreurs de transmission de données, le degré d'encombrement des ressources du réseau, les performances des équipements, etc., sont secondaires. Un « bon réseau » est un réseau dont les utilisateurs ne remarquent pas son fonctionnement.

Il peut y avoir plusieurs raisons principales au fonctionnement insatisfaisant d'un logiciel d'application sur un réseau : dommages au système de câbles, défauts des équipements actifs, surcharge des ressources du réseau (canal de communication et serveur), erreurs dans le logiciel d'application lui-même. Souvent, certains défauts du réseau en masquent d’autres. Ainsi, afin de déterminer de manière fiable la raison du fonctionnement insatisfaisant du logiciel d'application, le réseau local doit être soumis à un diagnostic complet. Un diagnostic complet implique d'effectuer les travaux (étapes) suivants.

Détection des défauts niveau physique réseaux : système de câble, systèmes d'alimentation électrique pour équipements actifs ; présence de bruit provenant de sources externes.
Mesurer la charge actuelle du canal de communication réseau et déterminer l'influence de la valeur de charge du canal de communication sur le temps de réponse du logiciel d'application.
Mesurer le nombre de collisions dans le réseau et connaître les raisons de leur apparition.
Mesurer le nombre d'erreurs de transmission de données au niveau du canal de communication et identifier les causes de leur apparition.
Identification des défauts de l'architecture réseau.
Mesurer la charge actuelle du serveur et déterminer l'impact de sa charge sur le temps de réponse des logiciels d'application.
Identification des défauts des logiciels d'application, qui entraînent une utilisation inefficace de la bande passante du serveur et du réseau.

Dans cet article, nous considérerons les quatre premières étapes du diagnostic complexe d'un réseau local, à savoir : le diagnostic couche de liaison réseaux.

Nous ne décrirons pas en détail la méthodologie de test d'un système de câble réseau. Malgré l'importance de ce problème, sa solution est triviale et sans ambiguïté : un système de câble à part entière ne peut être testé qu'avec un appareil spécial - un scanner de câble. Il n'y a pas d'autre moyen. Il ne sert à rien de suivre la procédure fastidieuse d'identification des défauts du réseau s'ils peuvent être localisés en appuyant simplement sur la touche AUTOTEST du scanner de câbles. Dans ce cas, l'appareil effectuera une gamme complète de tests pour garantir que le système de câble réseau est conforme à la norme sélectionnée.

Je voudrais attirer votre attention sur deux points, d'autant plus qu'ils sont souvent oubliés lors du test d'un système de câble réseau à l'aide d'un scanner.

Le mode AUTOTEST ne permet pas de vérifier le niveau de bruit créé par une source externe dans le câble. Il peut s'agir du bruit d'une lampe fluorescente, d'un câblage électrique, d'un téléphone portable, d'une photocopieuse puissante, etc. Pour déterminer le niveau de bruit, les scanners de câbles disposent généralement fonction spéciale. Étant donné que le système de câblage réseau n'est entièrement testé qu'au stade de l'installation et que le bruit dans le câble peut se produire de manière imprévisible, il n'y a aucune garantie totale que du bruit apparaîtra lors d'un test de réseau à grande échelle au stade de l'installation.

Lors de la vérification d'un réseau avec un scanner de câble, au lieu d'un équipement actif, un scanner est connecté au câble à une extrémité et un injecteur à l'autre. Après vérification du câble, le scanner et l'injecteur sont éteints et les équipements actifs sont connectés : cartes réseau, hubs, commutateurs. Cependant, il n'existe aucune garantie totale que le contact entre l'équipement actif et le câble sera aussi bon qu'entre l'équipement du scanner et le câble. Nous avons rencontré à plusieurs reprises des cas où un défaut mineur de la fiche RJ-45 n'apparaissait pas lors du test du système de câble avec un scanner, mais était détecté lors du diagnostic du réseau avec un analyseur de protocole.

Dans le cadre de la méthodologie proposée, nous ne considérerons pas la méthode désormais classique de diagnostic proactif de réseau (voir encadré « Méthodologie de diagnostic proactif de réseau »). Sans remettre en cause l’importance du diagnostic proactif, notons seulement qu’en pratique il est rarement utilisé. Le plus souvent (bien que cela soit incorrect), le réseau n'est analysé que pendant les périodes où ses performances sont insatisfaisantes. Dans de tels cas, les défauts du réseau existants doivent être localisés et corrigés rapidement. La technique que nous proposons doit être considérée comme un cas particulier de la technique de diagnostic proactif de réseau.
Organisation du processus de diagnostic du réseau

Toute technique de test de réseau dépend considérablement des ressources disponibles administrateur du système fonds. À notre avis, dans la plupart des cas, un outil nécessaire et suffisant pour détecter les défauts du réseau (à l'exception d'un scanner de câbles) est un analyseur de protocole réseau. Il doit se connecter au domaine de collision où les pannes sont observées, à proximité maximale des stations ou serveurs les plus suspects (voir règle n°3.3).

Si le réseau a une architecture de base réduite et qu'un commutateur est utilisé comme structure principale, l'analyseur doit alors être connecté aux ports de commutateur par lesquels passe le trafic analysé. Certains programmes disposent d'agents ou de sondes spéciaux installés sur les ordinateurs connectés aux ports du commutateur distant. Les agents (à ne pas confondre avec les agents SNMP) sont généralement un service ou une tâche qui s'exécute dans arrière-plan sur l'ordinateur de l'utilisateur. En règle générale, les agents consomment peu de ressources informatiques et n'interfèrent pas avec le travail des utilisateurs sur les ordinateurs desquels ils sont installés. Les analyseurs et les agents peuvent être connectés au commutateur de deux manières.

Dans la première méthode (voir Figure 1a), l'analyseur est connecté à un port spécial (port de surveillance ou port miroir) du commutateur, s'il en existe un, et le trafic de tous les ports du commutateur d'intérêt lui est envoyé tour à tour.

Figure 1a. Le trafic miroir de tous les ports du commutateur est envoyé tour à tour au port du commutateur auquel l'analyseur de protocole est connecté.

Si le commutateur ne dispose pas de port spécial, alors l'analyseur (ou l'agent) doit être connecté aux ports des domaines réseau d'intérêt à proximité maximale des stations ou serveurs les plus suspects (voir Figure 1b). Parfois, cela peut nécessiter l’utilisation d’un hub supplémentaire. Selon la règle n° 3.3, cette méthode préférable au premier. L'exception est lorsque l'un des ports du commutateur fonctionne en mode duplex intégral. Si tel est le cas, le port doit d'abord être basculé en mode semi-duplex.

Figure 1b. L'analyseur de protocole et les agents distants surveillent les principaux domaines du réseau. Un hub supplémentaire est utilisé pour diagnostiquer le domaine du serveur.

Il existe de nombreux analyseurs de protocole différents sur le marché, du logiciel pur au micrologiciel. Malgré l'identité fonctionnelle de la plupart des analyseurs de protocole, chacun d'eux présente certains avantages et inconvénients. À cet égard, nous souhaitons attirer l'attention sur deux fonctions importantes, sans lesquelles il sera difficile d'effectuer un diagnostic de réseau efficace.

Premièrement, l'analyseur de protocole doit avoir une fonction de génération de trafic intégrée (voir la règle n° 3.4). Deuxièmement, l'analyseur de protocole doit être capable de « diluer » les trames reçues, c'est-à-dire de recevoir non pas toutes les trames d'affilée, mais, par exemple, toutes les cinquièmes ou toutes les dixièmes avec l'approximation ultérieure obligatoire des résultats obtenus. Si cette fonction manque, alors lorsque le réseau est fortement chargé, quelle que soit la puissance de l'ordinateur sur lequel l'analyseur est installé, celui-ci se bloquera et/ou perdra des images. Ceci est particulièrement important lors du diagnostic des réseaux rapides tels que Fast Ethernet et FDDI.

Nous illustrerons la méthodologie proposée à l'aide de l'exemple d'utilisation d'un analyseur de protocole purement logiciel, Observer, de Network Instruments, fonctionnant dans Environnement Windows 95 et Windows NT. De notre point de vue, ce produit dispose de toutes les fonctions nécessaires pour un diagnostic réseau efficace.

Supposons donc que le logiciel d'application sur votre réseau Ethernet soit devenu lent et que vous deviez rapidement isoler et éliminer le défaut.
Première étape
Mesurer l'utilisation du réseau et établir une corrélation entre le ralentissement du réseau et la congestion des canaux de communication.
L'utilisation d'un canal de communication réseau est le pourcentage de temps pendant lequel le canal de communication transmet des signaux, ou autrement - la proportion de la capacité du canal de communication occupée par des trames, des collisions et des interférences. Le paramètre « Utilisation du canal de communication » caractérise le degré de congestion du réseau.

Le canal de communication réseau est une ressource réseau partagée, sa charge affecte donc le temps de réponse du logiciel d'application. La première priorité est de déterminer s’il existe une interdépendance entre mauvais travail logiciel d'application et utilisation du canal de communication réseau.

Supposons que l'analyseur de protocole soit installé dans un domaine réseau (domaine de collision) où le logiciel d'application s'exécute lentement. L'utilisation moyenne du canal de communication est de 19%, le pic atteint 82%. Est-il possible de tirer une conclusion fiable sur la base de ces données que la cause travail lent programmes sur le réseau, le canal de communication est-il surchargé ? À peine.

On entend souvent parler de la norme de fait selon laquelle, pour un fonctionnement satisfaisant d'un réseau Ethernet, l'utilisation d'un canal de communication « en tendance » (valeur moyenne sur 15 minutes) ne doit pas dépasser 20 %, et « en pointe » (valeur moyenne sur 1 minute) - 35-40%. Les valeurs données s'expliquent par le fait que dans un réseau Ethernet, lorsque l'utilisation du canal de communication dépasse 40 %, le nombre de collisions et, par conséquent, le temps de réponse du logiciel d'application augmentent considérablement. Bien que ce raisonnement soit généralement correct, le respect inconditionnel de ces recommandations peut conduire à des conclusions erronées sur les raisons du lent fonctionnement des programmes sur le réseau. Ils ne prennent pas en compte les caractéristiques d'un réseau particulier, à savoir : le type de logiciel d'application, la longueur du domaine du réseau, le nombre de stations fonctionnant simultanément.

Pour déterminer quelle est l'utilisation maximale autorisée d'un canal de communication dans votre cas particulier, nous vous recommandons de suivre les règles ci-dessous.
Règle n°1.1.
Si, dans un réseau Ethernet, à un moment donné, l'échange de données se produit entre deux ordinateurs au maximum, toute utilisation arbitrairement élevée du réseau est acceptable.

Le réseau Ethernet est conçu de telle manière que si deux ordinateurs se font concurrence simultanément pour capturer un canal de communication, ils se synchronisent après un certain temps et commencent à accéder au canal de communication strictement à tour de rôle. Dans ce cas, il n'y a pratiquement aucune collision entre eux.

Si le poste de travail et le serveur ont des performances élevées et qu'une grande partie des données est échangée entre eux, l'utilisation du canal de communication peut atteindre 80 à 90 % (surtout en mode rafale). Cela ne ralentit pas du tout le réseau, mais indique au contraire utilisation efficace ses ressources logicielles d'application.

Ainsi, si votre réseau utilise beaucoup de bande passante, essayez de déterminer combien d’ordinateurs communiquent en même temps. Cela peut être réalisé, par exemple, en collectant et en décodant des paquets dans le canal d'intérêt pendant une période de forte utilisation.
Règle n°1.2.
L'utilisation élevée d'un canal de communication réseau ne ralentit le fonctionnement d'un logiciel d'application spécifique que lorsque le canal de communication constitue le « goulot d'étranglement » pour le fonctionnement de ce logiciel spécifique.

En plus du canal de communication, des goulots d'étranglement dans le système peuvent survenir en raison de performances insuffisantes ou de paramètres de serveur incorrects, de faibles performances des postes de travail ou d'algorithmes de fonctionnement inefficaces du logiciel d'application lui-même.

Dans quelle mesure le canal de communication est responsable des performances insuffisantes du système peut être découvert comme suit. Après avoir sélectionné l'opération la plus courante d'un logiciel d'application donné (par exemple, pour un logiciel bancaire, une telle opération peut consister à saisir un ordre de paiement), vous devez déterminer comment l'utilisation du canal de communication affecte le temps d'exécution d'une telle opération.

Le moyen le plus simple de procéder consiste à utiliser la fonction de génération de trafic disponible dans un certain nombre d'analyseurs de protocole (par exemple, Observer). À l'aide de cette fonction, l'intensité de la charge générée doit être augmentée progressivement et, dans ce contexte, le temps d'exécution de l'opération doit être mesuré. Il est conseillé d'augmenter la charge de fond de 0 à 50-60 % par incréments de 10 % maximum.

Si le temps d'exécution d'une opération ne change pas de manière significative sur une large plage de charges en arrière-plan, le goulot d'étranglement du système n'est pas le canal de communication. Si le temps d'exécution de l'opération varie considérablement en fonction de l'importance de la charge en arrière-plan (par exemple, avec 10 % et 20 % d'utilisation du canal de communication, le temps d'exécution de l'opération varie considérablement), alors c'est le canal de communication qui est très probablement responsable des faibles performances du système, et la valeur de sa charge de travail est critique pour le temps de réponse des logiciels d'application. Connaissant le temps de réponse souhaité du logiciel, vous pouvez facilement déterminer quelle utilisation du canal de communication correspond au temps de réponse souhaité du logiciel d'application.

Dans cette expérience, la charge de fond ne doit pas être définie à plus de 60 à 70 %. Même si le lien de communication ne constitue pas un goulot d'étranglement, sous de telles charges, le temps d'exécution peut augmenter en raison de la réduction du débit effectif du réseau.
Règle n°1.3.
L'utilisation maximale autorisée d'un canal de communication dépend de la longueur du réseau.

À mesure que la longueur du domaine réseau augmente, l'utilisation autorisée diminue. Plus le domaine réseau est long, plus les collisions seront détectées tardivement. Si la longueur du domaine réseau est faible, alors les collisions seront détectées par les stations en début de trame, au moment de la transmission du préambule. Si la longueur du réseau est grande, les collisions seront détectées plus tard, au moment de la transmission de la trame elle-même. En conséquence, la surcharge de transmission de paquets (IP ou IPX) augmente. Plus une collision est détectée tardivement, plus la surcharge est importante et plus la transmission du paquet prend du temps. En conséquence, le temps de réponse des logiciels d'application, bien que légèrement, augmente.

Conclusions. Si, à la suite d'un diagnostic réseau, vous déterminez que la raison du fonctionnement lent du logiciel d'application est due à une congestion du canal de communication, l'architecture du réseau doit alors être modifiée. Le nombre de stations dans les domaines réseau surchargés doit être réduit et les stations qui créent la plus grande charge sur le réseau doivent être connectées à des ports de commutation dédiés.
Seconde phase
Mesurer le nombre de collisions dans le réseau.

Si deux stations d'un domaine réseau transmettent simultanément des données, une collision se produit dans le domaine. Il existe trois types de collisions : locales, distantes, tardives.

Une collision locale est une collision détectée dans le domaine où le dispositif de mesure est connecté, au sein du préambule de transmission ou des 64 premiers octets de la trame lorsque la source de transmission est dans le domaine. Algorithmes de détection de collision locale pour réseau à paires torsadées (10BaseT) et câble coaxial(10Base2) sont différents les uns des autres.

Dans un réseau 10Base2, la station transmettant la trame détermine qu'une collision locale s'est produite en modifiant le niveau de tension dans le canal de communication (en le doublant). Après avoir détecté une collision, la station émettrice envoie une série de signaux de brouillage dans le canal de communication afin que toutes les autres stations du domaine sachent qu'une collision s'est produite. Le résultat de cette série de signaux est l'apparition sur le réseau de trames courtes et mal formatées de moins de 64 octets avec une séquence de contrôle CRC incorrecte. De telles trames sont appelées fragments de collision ou runts.

Dans un réseau 10BaseT, une station détermine qu'une collision locale s'est produite si elle détecte une activité sur la paire de réception (Rx) lors de la transmission d'une trame.

Une collision à distance est une collision qui se produit sur un autre segment physique du réseau (c'est-à-dire derrière le répéteur). Une station sait qu'une collision à distance s'est produite si elle reçoit une trame courte mal formée avec une séquence de contrôle CRC incorrecte et que le niveau de tension de liaison reste dans les limites spécifiées (pour les réseaux 10Base2). Pour les réseaux 10BaseT/100BaseT, l'indicateur est l'absence d'activité simultanée sur les couples récepteur et émetteur (Tx et Rx).

Une collision tardive est une collision locale détectée après que la station a transmis les 64 premiers octets de la trame dans le canal de communication. Dans les réseaux 10BaseT, les collisions tardives sont souvent signalées comme des erreurs CRC par les appareils de mesure.

Si, en règle générale, la détection de collisions locales et distantes n'indique pas encore la présence de défauts dans le réseau, alors la détection de collisions tardives est une confirmation claire de la présence d'un défaut dans le domaine. Cela est le plus souvent dû à des lignes de communication trop longues ou à des équipements réseau de mauvaise qualité.

Outre le niveau élevé d'utilisation des canaux de communication, les collisions dans un réseau Ethernet peuvent être provoquées par des défauts du système de câblage et des équipements actifs, ainsi que par la présence de bruit.

Même si le canal de communication ne constitue pas le goulot d'étranglement du système, les collisions ne sont pas significatives, mais elles ralentissent le fonctionnement du logiciel d'application. De plus, le ralentissement principal n'est pas tant dû à la nécessité de retransmettre la trame, mais au fait que chaque ordinateur du réseau, après une collision, doit exécuter un algorithme d'interruption : avant la prochaine tentative d'entrée dans le canal de communication, il devra attendre une période de temps aléatoire, proportionnelle au nombre de tentatives précédentes infructueuses.

À cet égard, il est important de découvrir quelle est la cause des collisions : utilisation élevée du réseau ou défauts « cachés » du réseau. Pour le déterminer, nous vous recommandons de suivre les règles suivantes.
Règle n°2.1.

Tous les instruments de mesure ne déterminent pas correctement le nombre total de collisions sur le réseau.

Presque tous les analyseurs de protocole purement logiciels détectent la présence d'une collision uniquement s'ils détectent un fragment dans le réseau, c'est-à-dire le résultat d'une collision. Dans le même temps, les types de collisions les plus courants - ceux qui se produisent au moment de la transmission du préambule de trame (c'est-à-dire avant le délimiteur de trame initial (SFD)) - ne sont pas détectés par les outils de mesure logiciels, c'est ainsi que le chipset de Les cartes réseau Ethernet sont conçues. Les compteurs matériels tels que le LANMeter de Fluke détectent les collisions avec la plus grande précision.
Règle n°2.2.

Une utilisation élevée du canal de communication ne s'accompagne pas toujours d'un niveau élevé de collisions.

Le niveau de collisions sera faible s'il n'y a pas plus de deux stations fonctionnant sur le réseau en même temps (voir règle n° 1.1) ou si un petit nombre de stations échangent simultanément de longues trames (ce qui est particulièrement typique pour le mode rafale). . Dans ce cas, avant le début de la transmission de la trame, les stations « voient » la porteuse dans le canal de communication et les collisions sont rares.
Règle n°2.3.

Le signe d'un défaut dans le réseau est une situation dans laquelle une faible utilisation des canaux (moins de 30 %) s'accompagne d'un niveau élevé de collisions (plus de 5 %).

Si le système de câblage a été préalablement analysé, la cause la plus probable de l'augmentation du taux de collision est le bruit sur la ligne de communication provoqué par une source externe ou une carte réseau défectueuse qui n'implémente pas correctement l'algorithme CSMA/CD.

La société Network Instruments, dans l'analyseur de protocole Observer, a initialement résolu le problème de l'identification des collisions causées par des défauts du réseau. Le test intégré au programme provoque l'apparition de collisions : il envoie une série de paquets dans le canal de communication avec une intensité de 100 paquets par seconde et analyse le nombre de collisions survenues. Dans ce cas, le graphique combiné affiche la dépendance du nombre de collisions dans le réseau sur l'utilisation du canal de communication.

Il est logique d'analyser la part des collisions dans le nombre total de trames au moment de l'activité des stations suspectes (travaillant lentement) et uniquement dans le cas où l'utilisation du canal de communication dépasse 30 %. Si sur trois trames une collision se produit, cela ne signifie pas qu’il y a un défaut dans le réseau.

Dans Observer Protocol Analyser, le graphique présenté dans la figure 3 change de couleur en fonction du nombre de collisions et de l'utilisation observée du canal de communication.
Règle n°2.4.

Lors du diagnostic d'un réseau 10BaseT, toutes les collisions doivent être signalées comme supprimées si l'analyseur de protocole ne génère pas de trafic.

Si vous surveillez passivement (sans générer de trafic) le réseau 10BaseT et le segment physique où l'analyseur est connecté ( instrument de mesure) est correct, alors toutes les collisions doivent être enregistrées comme supprimées.

Si néanmoins vous constatez des collisions locales, cela peut signifier l'une des trois choses suivantes : le segment physique du réseau auquel l'appareil de mesure est connecté est défectueux ; Le hub ou le port du commutateur auquel le compteur est connecté est défectueux, ou le compteur est incapable de faire la distinction entre les collisions locales et distantes.
Règle n°2.5.

Les collisions dans le réseau peuvent être la conséquence d'une surcharge des tampons d'entrée du commutateur.

Rappelons que lorsque les buffers d'entrée sont surchargés, les switchs émulent des collisions afin de « ralentir » les postes du réseau. Ce mécanisme est appelé « contrôle de flux ».
Règle n°2.6.
La cause d'un grand nombre de collisions (et d'erreurs) dans le réseau peut être une mauvaise organisation de la mise à la terre des ordinateurs connectés au réseau local.

Si les ordinateurs connectés au réseau n'ont pas de point de mise à la terre commun (mise à la terre), alors une différence de potentiel peut apparaître entre les boîtiers des ordinateurs. Dans les ordinateurs personnels, le motif « protection » est combiné avec le motif « information ». Étant donné que les ordinateurs sont connectés par un canal de communication réseau local, la différence de potentiel entre eux conduit à la génération de courant via le canal de communication. Ce courant provoque une distorsion de l'information et est à l'origine de collisions et d'erreurs dans le réseau. Cet effet est appelé boucle de masse ou bruit inter-sol.

Un effet similaire se produit lorsqu'un segment de câble coaxial est mis à la terre en plusieurs points. Cela se produit souvent si le connecteur en T de la carte réseau entre en contact avec le boîtier de l'ordinateur.

Veuillez noter que l'installation d'une alimentation sans interruption ne supprime pas les difficultés décrites. Ces problèmes et les méthodes pour les résoudre sont discutés plus en détail dans les documents d'APC (American Power Conversion) dans le Power Protection Handbook.

Si un grand nombre de collisions et d'erreurs sont détectées dans les réseaux 10Base2, la première chose à faire est de vérifier la différence de potentiel entre la tresse du câble coaxial et les boîtiers de l'ordinateur. Si sa valeur pour un ordinateur du réseau est supérieure à un volt courant alternatif, alors le réseau ne convient pas à la topologie des lignes de mise à la terre de l'ordinateur.
Troisième étape
Mesurer le nombre d'erreurs au niveau de la couche liaison réseau.

Les types d'erreurs les plus courants dans les réseaux Ethernet sont :

Trame courte - une trame de moins de 64 octets (après le préambule de 8 octets) avec une séquence de vérification valide. La cause la plus probable des trames courtes est une carte réseau défectueuse ou un pilote réseau mal configuré ou corrompu.

Dernièrement, nous avons constaté un grand nombre d'erreurs de ce type à des niveaux relativement élevés. ordinateurs lents(486/SX) fonctionnant sous Windows 95 avec des cartes réseau NE2000. La raison nous est inconnue.

Trame longue : une trame de plus de 1 518 octets. Une trame longue peut avoir une séquence de contrôle correcte ou incorrecte. Dans ce dernier cas, ces trames sont généralement appelées jabber. L'enregistrement de longues images avec la séquence de contrôle correcte indique le plus souvent que le pilote réseau ne fonctionne pas correctement ; correction des erreurs de type jabber - en cas de dysfonctionnement de l'équipement actif ou de présence d'interférences externes.

Erreurs de séquence de contrôle (erreur CRC) - une trame correctement formatée d'une longueur acceptable (de 64 à 1518 octets), mais avec une séquence de contrôle incorrecte (erreur dans le champ CRC).

Erreur d'alignement - une trame contenant un nombre de bits qui n'est pas un multiple du nombre d'octets.

Les fantômes sont une séquence de signaux dont le format est différent de celui des trames Ethernet, ne contiennent pas de délimiteur (SFD) et font plus de 72 octets. D'abord ce terme a été introduit par Fluke pour différencier les différences entre les collisions à distance et le bruit dans le canal de communication.

Les reflets sont l'erreur la plus insidieuse, car ils ne sont pas reconnus par les analyseurs de protocole logiciels pour la même raison que les collisions au stade de la transmission du préambule. L'éblouissement peut être détecté à l'aide d'appareils spéciaux ou à l'aide de la méthode de test de résistance du réseau (nous prévoyons de parler de cette méthode dans des publications ultérieures).

Au risque de s’attirer les justes foudres des distributeurs de programmes la gestion du réseau En nous basant sur SNMP, nous osons néanmoins affirmer que le degré d'influence des erreurs de la couche liaison réseau sur le temps de réponse des logiciels d'application est fortement exagéré.

Conformément à la norme de facto généralement acceptée, le nombre d'erreurs au niveau de la liaison ne doit pas dépasser 1 % du nombre total de trames transmises sur le réseau. L'expérience montre que cette valeur n'est couverte qu'en présence de défauts évidents dans le système de câblage du réseau. Dans le même temps, de nombreux défauts graves des équipements actifs qui provoquent de nombreuses pannes de réseau n'apparaissent pas au niveau de la couche liaison de données du réseau (voir règle n° 3.8).
Règle n°3.1.

Avant d'analyser les erreurs réseau, découvrez quels types d'erreurs peuvent être identifiés carte réseau et le pilote de la carte sur l'ordinateur sur lequel s'exécute votre analyseur de protocole logiciel.

Le fonctionnement de tout analyseur de protocole est basé sur le fait que la carte réseau et le pilote sont commutés sur le mode de réception de toutes les trames réseau (mode promiscuité). Dans ce mode, la carte réseau reçoit toutes les trames transitant par le réseau, et pas seulement celles diffusées et celles qui lui sont directement adressées, comme dans mode normal. L'analyseur de protocole reçoit toutes les informations sur les événements sur le réseau du pilote de la carte réseau fonctionnant en mode de réception de toutes les trames.

Toutes les cartes réseau et tous les pilotes réseau ne fournissent pas à l'analyseur de protocole des informations identiques et informations complètes sur les erreurs de réseau. Les cartes réseau 3Com ne fournissent aucune information sur les erreurs. Si vous installez un analyseur de protocole sur une telle carte, alors les valeurs de tous les compteurs d'erreurs seront nulles.

EtherExpress Pro d'Intel ne signale que les erreurs de CRC et d'alignement. Les cartes réseau SMC fournissent des informations uniquement sur les trames courtes. NE2000 fournit des informations presque complètes, identifiant les erreurs CRC, les trames courtes, les erreurs d'alignement et les collisions.

Les cartes réseau D-Link (par exemple, DFE-500TX) et Kingstone (par exemple, KNE 100TX) présentent un rapport complet et, si un pilote spécial est disponible, des informations même détaillées sur les erreurs et les collisions sur le réseau.

Un certain nombre de développeurs d'analyseurs de protocole proposent leurs pilotes pour les cartes réseau les plus populaires.
Règle n°3.2.

Faites attention à la « liaison » des erreurs aux adresses MAC spécifiques des stations.

Lors de l'analyse d'un réseau local, vous avez probablement remarqué que les erreurs sont généralement « liées » à certaines adresses MAC des stations. Cependant, les collisions survenues dans la partie adresse de la trame, l'éblouissement, les situations non reconnues telles qu'une trame courte avec une longueur de données nulle ne peuvent pas être « liées » à des adresses MAC spécifiques.

S'il existe de nombreuses erreurs sur le réseau qui ne sont pas associées à des adresses MAC spécifiques, leur source n'est probablement pas un équipement actif. Très probablement, ces erreurs sont le résultat de collisions, de défauts dans le système de câblage réseau ou de fortes bruit extérieur. Ils peuvent également être provoqués par une mauvaise qualité ou des interruptions de la tension alimentant les équipements actifs.

Si la plupart des erreurs sont liées à des adresses MAC spécifiques des stations, essayez d'identifier un modèle entre l'emplacement des stations transmettant des trames erronées, l'emplacement de l'appareil de mesure (voir règles n° 3.3, n° 3.4) et la topologie du réseau.
Règle n°3.3.

Au sein d'un même domaine de réseau (domaine de collision), le type et le nombre d'erreurs enregistrées par un analyseur de protocole dépendent de l'endroit où l'appareil de mesure est connecté.

En d’autres termes, au sein d’un segment de câble coaxial, d’un hub ou d’une pile de hubs, le modèle de statistiques de liaison peut dépendre de l’endroit où le compteur est connecté.

Pour de nombreux administrateurs réseau, cette affirmation peut sembler absurde, car elle contredit les principes du modèle OSI à sept couches. Lorsque nous avons rencontré ce phénomène pour la première fois, nous n'avons pas non plus cru au résultat et avons décidé que l'appareil de mesure était défectueux. Nous avons testé ce phénomène avec différents instruments de mesure, du purement logiciel au logiciel et matériel. Le résultat était le même.

La même interférence peut provoquer une erreur CRC, un éclat, une collision à distance ou ne pas être détectée du tout, selon la position relative de la source d'interférence et de l'appareil de mesure. La même collision peut être enregistrée comme lointaine ou tardive, selon la position relative des stations en conflit et de l'appareil de mesure. Une trame contenant une erreur CRC sur un hub d'une pile peut ne pas être capturée sur un autre hub de la même pile.

Une conséquence de ce qui précède règle heuristique est le fait que les programmes de surveillance du réseau basés sur le protocole SNMP ne reflètent pas toujours de manière adéquate les statistiques d'erreurs dans le réseau. La raison en est que l'agent SNMP intégré à l'équipement actif surveille toujours l'état du réseau à partir d'un seul point. Ainsi, si le réseau est constitué de plusieurs piles de hubs « non intelligents » connectés à un commutateur « intelligent », alors l'agent SNMP du commutateur peut parfois ne pas voir certaines erreurs dans la pile de hubs.

La confirmation de cette règle peut être trouvée sur les serveurs Web de Fluke (www.fluke.com) et de Net3 Group (www.net3group.com).

Pour identifier les erreurs au niveau de la liaison de données du réseau, les mesures doivent être effectuées dans le contexte de l'analyseur générant ses propres protocoles de trafic.

Générer du trafic permet d'aggraver les problèmes existants et crée les conditions de leur manifestation. Le trafic doit être de faible intensité (pas plus de 100 images/s) et contribuer à la formation de collisions dans le réseau, c'est-à-dire contenir de courts (
Lors du choix d'un analyseur de protocole ou d'un autre outil de diagnostic, il convient tout d'abord de prêter attention au fait que l'outil sélectionné dispose d'une fonction intégrée permettant de générer un trafic d'une intensité spécifiée. Cette fonctionnalité est disponible, entre autres, dans les analyseurs NetXray de Network Instruments et de Cinco (maintenant Network Associates).
Règle n°3.5.

Si les statistiques observées dépendent de l'emplacement de l'appareil de mesure, alors la source des erreurs est très probablement située au niveau physique d'un domaine de réseau donné (la raison en est des défauts dans le système de câblage ou du bruit provenant d'une source externe). DANS sinon la source des erreurs est située au niveau de la couche liaison de données (ou supérieure) ou dans un autre domaine réseau adjacent.
Règle n°3.6.

Si la proportion d'erreurs CRC dans le nombre total d'erreurs est importante, alors la longueur des trames contenant ce type les erreurs.

Comme nous l'avons déjà noté, les erreurs CRC peuvent survenir à la suite de collisions, de défauts dans le système de câble, d'une source de bruit externe ou d'émetteurs-récepteurs défectueux. Une autre cause possible d'erreurs CRC pourrait être des ports de hub ou de commutateur défectueux qui ajoutent quelques octets factices à la fin de la trame.

S'il existe une proportion importante d'erreurs CRC dans le nombre total d'erreurs, il est conseillé de rechercher la raison de leur apparition. Pour ce faire, les trames erronées d’une série doivent être comparées à des trames similaires de bonne qualité de la même série. Si les images erronées sont nettement plus courtes que les bonnes, il s’agit probablement du résultat de collisions. Si les trames erronées ont presque la même longueur, la cause de la distorsion est très probablement une interférence externe. Si les mauvaises trames sont plus longues que les bonnes, la raison réside probablement dans un port défectueux sur le hub ou le commutateur, qui ajoute des octets « vides » à la fin de la trame.

Le moyen le plus simple de comparer la longueur des trames erronées et correctes consiste à collecter une série de trames avec une erreur CRC dans le tampon de l'analyseur.
Règle n°3.7.

Le tableau 1 systématise les causes d'erreurs et de collisions pour les étapes 2 et 3


Cause des erreurs	Collisions locales	Collisions supprimées	Collisions tardives	Tir court	Plan lointain	Jacasser	Erreur CRC
Carte réseau défectueuse	>5 % à U	>5 % à U	Manger	Manger	Manger	Manger	Manger
Pilote de carte défectueux				Manger	Manger	Manger	Manger
Hub, répéteur, émetteur-récepteur défectueux	>5 % à U	>5 % à U	Manger			Manger	Manger
Connexion incorrecte de l'équipement actif	>5 % à U	>5 % à U	Manger			Manger
Trop long câble			Manger				Manger
Plus de 4 répéteurs ou hubs en cascade			Manger
Mauvaise mise à la terre des ordinateurs ou du câble coaxial	>5 % à U	>5 % à U	Manger			Manger	Manger
Défauts dans le système de câblage et les équipements passifs	>5 % à U	>5 % à U	Manger			Manger	Manger
Source de bruit à proximité du système de câble	>5 % à U	>5 % à U	Manger			Manger	Manger
Note. U - utilisation du canal de communication

Si vous diagnostiquez votre réseau pour la première fois et rencontrez des problèmes, ne vous attendez pas à ce qu'un seul composant de votre réseau soit défectueux.

Le moyen le plus fiable de localiser les défauts consiste à éteindre un par un les stations, hubs et chemins de câbles suspects et à vérifier soigneusement la topologie des lignes de mise à la terre des ordinateurs (en particulier pour les réseaux 10Base2).

Si des pannes de réseau se produisent à des moments imprévisibles qui ne sont pas liés à l'activité de l'utilisateur, vérifiez le niveau de bruit dans le câble à l'aide d'un scanner de câble. Si vous ne disposez pas de scanner, assurez-vous visuellement que le câble ne passe pas à proximité de fortes sources de rayonnement électromagnétique : câbles haute tension ou courant fort, lampes fluorescentes, moteurs électriques, matériel de copie, etc.
Règle n°3.8.

L'absence d'erreurs au niveau de la couche liaison de données ne garantit pas que les informations sur votre réseau ne soient pas corrompues.

Il a déjà été mentionné au début de cette section que l'impact des erreurs de couche liaison sur le fonctionnement du réseau a été grandement exagéré. La conséquence des erreurs de bas niveau est la retransmission des trames. Grâce à la vitesse Ethernet élevée (en particulier Fast Ethernet) et aux hautes performances ordinateurs modernes Les erreurs de niveau inférieur n'ont pas d'impact significatif sur le temps de réponse du logiciel d'application.

Nous avons très rarement rencontré des cas où la suppression uniquement des erreurs aux niveaux inférieurs (canaux et physiques) du réseau permettait d'améliorer significativement le temps de réponse des logiciels applicatifs. Les problèmes étaient principalement liés à de graves défauts dans le système de câblage du réseau.

Des erreurs telles que la disparition ou la distorsion d'informations dans les cartes réseau, les routeurs ou les commutateurs en l'absence totale d'informations sur les erreurs aux niveaux inférieurs ont un impact beaucoup plus important sur le fonctionnement des logiciels d'application sur le réseau. Nous utilisons le mot « information » car au moment de la distorsion la donnée n’est pas encore cadrée.

La raison de ces défauts est la suivante. Les informations sont déformées (ou disparaissent) « dans les profondeurs » de l'équipement actif - une carte réseau, un routeur ou un commutateur. Dans ce cas, l'unité d'émission et de réception de cet équipement calcule la séquence de contrôle correcte (CRC) des informations précédemment corrompues, et la trame correctement formatée est transmise sur le réseau. Bien entendu, aucune erreur n’est enregistrée dans ce cas. Les agents SNMP intégrés aux équipements actifs ne peuvent pas aider ici.

Parfois, en plus de la distorsion, l'information disparaît. Le plus souvent, cela se produit sur des cartes réseau bon marché ou sur des commutateurs Ethernet-FDDI. Le mécanisme de disparition des informations dans ce dernier cas est clair. Dans un certain nombre de commutateurs Ethernet-FDDI, il n'y a pas de retour du port rapide vers le port lent (ou vice versa), par conséquent, l'autre port ne reçoit pas d'informations sur l'encombrement des tampons d'entrée/sortie du port rapide. port (lent). Dans ce cas, lors de trafic intense, les informations sur l'un des ports peuvent être perdues.

Un administrateur réseau expérimenté peut faire valoir qu'en plus de protéger les informations au niveau de la liaison dans les protocoles IPX et TCP/IP, il est possible de protéger les informations à l'aide d'une somme de contrôle.

La protection complète par somme de contrôle ne peut être invoquée que si le logiciel d'application utilise TCP ou UDP comme protocole de transport. Ce n'est que lorsqu'ils sont utilisés que l'ensemble du paquet est protégé par une somme de contrôle. Si IPX/SPX ou IP lui-même est utilisé comme « transport », alors seul l'en-tête du paquet est protégé par une somme de contrôle.

Même avec une protection par somme de contrôle, la distorsion ou la disparition d'informations décrite entraîne une augmentation significative du temps de réponse du logiciel d'application.

Si la protection n'est pas installée, le comportement du logiciel d'application peut être imprévisible.

En plus du remplacement (désactivation) des équipements suspects, ces défauts peuvent être identifiés de deux manières.

La première méthode consiste à capturer, décoder et analyser les trames provenant d’une station, d’un routeur ou d’un commutateur suspect. Un symptôme du défaut décrit est la retransmission d'un paquet IP ou IPX, qui n'est pas précédée d'une erreur de couche réseau inférieure. Certains analyseurs de protocole et systèmes experts simplifiez la tâche en effectuant une analyse de trace ou en calculant indépendamment la somme de contrôle des paquets.

La deuxième méthode est la méthode de test de résistance du réseau.

Conclusions. La tâche principale du diagnostic du niveau de liaison d'un réseau est d'identifier la présence d'un nombre accru de collisions et d'erreurs dans le réseau et de trouver la relation entre le nombre d'erreurs, le degré d'encombrement du canal de communication, la topologie du réseau et l'emplacement de l'appareil de mesure. Toutes les mesures doivent être effectuées dans le contexte de l'analyseur générant ses propres protocoles de trafic.

S'il est déterminé que l'augmentation du nombre d'erreurs et de collisions n'est pas une conséquence d'une surcharge du canal de communication, alors l'équipement de réseau, pendant le fonctionnement duquel un nombre accru d'erreurs est observé, doit être remplacé.

Si vous ne pouvez pas identifier la relation entre le fonctionnement d'un équipement spécifique et l'apparition d'erreurs, effectuez un test complet du système de câble, vérifiez le niveau de bruit dans le câble, la topologie des lignes de mise à la terre de l'ordinateur et la qualité de l'alimentation. tension.
Quels paramètres doivent être surveillés lors du diagnostic d’un réseau ?
Méthodologie de diagnostic réseau proactif
La technique de diagnostic proactif est la suivante. L'administrateur réseau doit surveiller le fonctionnement du réseau en continu ou sur une période prolongée. Il est conseillé d'effectuer ces observations dès son installation. Sur la base de ces observations, l'administrateur doit déterminer, d'une part, comment les valeurs des paramètres observés affectent le travail des utilisateurs du réseau et, d'autre part, comment elles évoluent sur une longue période de temps : un jour ouvrable, une semaine, un mois, un trimestre. , année, etc.

Les paramètres observables sont généralement :

paramètres de fonctionnement du canal de communication du réseau - utilisation du canal de communication, nombre de trames reçues et transmises par chaque station du réseau, nombre d'erreurs dans le réseau, nombre de trames de diffusion et de multidiffusion, etc.
paramètres de fonctionnement du serveur - utilisation du processeur du serveur, nombre de requêtes différées (en attente) sur le disque, nombre total de tampons de cache, nombre de tampons de cache "sales", etc.

Connaissant la relation entre le temps de réponse du logiciel d'application et les valeurs des paramètres observés, l'administrateur réseau doit déterminer les valeurs maximales de paramètres autorisées pour un réseau donné. Ces valeurs sont saisies sous forme de seuils dans l'outil de diagnostic. Si pendant le fonctionnement du réseau les valeurs des paramètres observés dépassent les valeurs seuils, l'outil de diagnostic informera l'administrateur réseau de cet événement. Cette situation indique qu'il y a un problème dans le réseau.

En observant le fonctionnement du canal de communication et du serveur pendant une période suffisamment longue, vous pouvez établir une tendance des valeurs de divers paramètres de fonctionnement du réseau (utilisation des ressources, nombre d'erreurs, etc.). Sur la base de ces observations, l'administrateur peut tirer des conclusions sur la nécessité de remplacer les équipements actifs ou de modifier l'architecture du réseau.

Si un problème apparaît sur le réseau, l'administrateur, au moment où il se manifeste, doit écrire un dump de la trace du canal dans un tampon ou un fichier spécial et, sur la base d'une analyse de son contenu, tirer des conclusions sur raisons possibles Problèmes.
Source: Bibliothèque spécialisée en informatique

http://inform.p-stone.ru/libr/nets/monitor/data/public14/#p1

Sous Diagnostique Il est généralement admis de comprendre la mesure des caractéristiques et le suivi des indicateurs de performance du réseau lors de son fonctionnement, sans interrompre le travail des utilisateurs.

Le diagnostic du réseau consiste notamment à mesurer le nombre d'erreurs de transmission de données, le degré de charge (utilisation) de ses ressources ou encore le temps de réponse des logiciels d'application.

Essai est un processus consistant à influencer activement un réseau afin de vérifier ses performances et de déterminer les opportunités potentielles de transmission du trafic réseau. En règle générale, elle est effectuée pour vérifier l'état du système de câble (conformité de la qualité aux exigences standard), connaître le débit maximal ou évaluer le temps de réponse du logiciel d'application lors de la modification des paramètres de l'équipement réseau ou de la configuration physique du réseau. .

Dépannage du réseau à l'aide du matériel.

Classiquement, les équipements de diagnostic, de dépannage et de certification des systèmes de câbles peuvent être divisés en quatre groupes principaux :

1. Instruments de certification des systèmes de câbles, effectuant tous les tests nécessaires à la certification réseaux câblés, y compris la détermination de l'atténuation, du rapport signal/bruit, de l'impédance, de la capacité et de la résistance.

2. Analyseurs de réseau sont des instruments de mesure de référence pour le diagnostic et la certification des câbles et systèmes de câbles. Les analyseurs de réseau contiennent un générateur de fréquence de haute précision et un récepteur à bande étroite. En transmettant des signaux de différentes fréquences dans la paire émettrice et en mesurant le signal dans la paire réceptrice, l'atténuation de la ligne et les caractéristiques de la ligne peuvent être mesurées.

3. Les scanners de câbles vous permettent de déterminer la longueur du câble, l'atténuation, l'impédance, le schéma de câblage, le niveau de bruit électrique et d'évaluer les résultats. Pour déterminer l'emplacement d'un défaut d'un système de câbles (rupture, court-circuit, etc.), la méthode du « radar câble », ou Time Domain Reflectometry (TDR), est utilisée. L'essence de cette méthode est que le scanner émet une courte impulsion électrique dans le câble et mesure le temps de retard avant l'arrivée du signal réfléchi. La polarité de l'impulsion réfléchie détermine la nature des dommages causés au câble ( court-circuit ou pause). Dans un câble correctement installé et connecté, il n'y a pas d'impulsion réfléchie.

4. Les testeurs (ohmmètres) sont les appareils les plus simples et les moins chers pour le diagnostic des câbles. Ils permettent de déterminer la continuité du câble, cependant, contrairement aux scanners de câbles, ils n'indiquent pas où la panne s'est produite. La vérification de l'intégrité des lignes de communication s'effectue par « numérotation » séquentielle paires torsadéesà l'aide d'un ohmmètre.

Connexion d'un ordinateur personnel à un réseau local

La première chose à faire est de vous assurer que la carte réseau de votre ordinateur/ordinateur portable fonctionne et qu'il y a pilotes installés. Un autre détail important requis pour un réseau local est un commutateur (commutateur) et le câble réseau lui-même. Au lieu d'un interrupteur, vous pouvez utiliser Routeur Wi-Fi. Mais le nombre de ports sera limité, mais en prime il y aura un accès à Internet.

La connexion au réseau local s'effectue dans l'ordre suivant.

Câble réseau connectez-vous à l'interrupteur et carte réseau ordinateur. Ensuite, l'ordinateur et l'interrupteur s'allument. Le système d'exploitation démarrera, à peu près au même moment, le commutateur-routeur clignotera et vous pourrez commencer la configuration. paramètres réseau: vous devez aller dans « Panneau de configuration » – « Afficher l'état et les tâches du réseau » – « Modifier les paramètres de l'adaptateur » – « RMB » – « Propriétés » – « Configurer l'adresse IP de l'ordinateur » – « Protocole Internet version 4 » – « Propriétés ». Saisissez l'adresse IP au format « 192.168.YYY.ХХХ ». Cliquez une fois sur le masque réseau, il sera installé automatiquement. Veuillez noter que les deux derniers blocs de chiffres et le masque réseau doivent correspondre aux adresses du réseau auquel la connexion est configurée. Par exemple, si le réseau est « 192.168.1.ХХХ », alors « 1 » est le numéro de sous-réseau et « ХХХ » est n'importe quel nombre compris entre 1 et 254. Après le réglage, vous devez cliquer sur « OK ».

Ensuite, vous devez définir le groupe de travail, cela est nécessaire pour afficher l'ordinateur dans le groupe approprié. Dans un bureau, par exemple, dans le groupe « Comptabilité », il n'y aura que des machines en état de marche du service « Comptabilité ». Ensuite, vous devez accéder aux propriétés de « Poste de travail » - « Modifier les paramètres ». Dans les propriétés du système, cliquez sur « Modifier » pour joindre l'ordinateur au groupe de travail. Entrez le nom de l'ordinateur et le groupe de travail. Cliquez sur « OK » et redémarrez le PC pour que les modifications prennent effet.

Une autre option de connexion est sans fil. Cette méthode ne convient que si vous disposez d'un routeur Wi-Fi. Pour cela vous aurez besoin Adaptateur Wi-Fi(pour installation à l'intérieur ou sur port USB) et routeur Wi-Fi. Vous devez connecter l'adaptateur. Le système le reconnaîtra automatiquement, installera les pilotes correspondants ou vous demandera d'insérer un disque de pilotes. Une icône sans fil apparaîtra dans la barre d'état système à côté de l'horloge. Ensuite, vous devez cliquer dessus, une liste de réseaux disponibles pour la connexion apparaîtra, dans laquelle vous devrez trouver le vôtre et vous connecter. Dans ce cas, il vous suffit d'installer groupe résidentiel, l'adresse IP sera attribuée automatiquement. L'ordinateur portable dispose déjà d'une carte réseau intégrée et d'un adaptateur Wi-Fi.

Connecter un ordinateur personnel à Internet

Pour connecter votre ordinateur à un PC, vous devez procéder comme suit : « Démarrer » – « Panneau de configuration » – « Réseau et Internet » – « Centre Réseau et partage » accès partagé" - "Changer les paramètres d'adaptation" - " Les connexions de réseau» – « Connexion au réseau local » – « RMB » – « Propriétés » – « Réseau » – « Protocole Internet version 4 (TCP/IPv4) » – « Propriétés ». Dans la fenêtre suivante, vous devez cocher les cases à côté des fonctions « Obtenir une adresse IP automatiquement » et « Obtenir automatiquement l'adresse du serveur DNS ».

Connecter votre ordinateur à un réseau sans fil Réseaux Wi-Fi, vous devez procéder comme suit : allez dans « Centre Réseau et partage » – « Se connecter à un réseau ». Une fenêtre apparaîtra sur la droite affichant les paramètres de connexion réseau. Vous devez vous assurer que le mode avion n'est pas actif - il doit être désactivé. Ci-dessous sera une liste connexions disponibles. Vous devez sélectionner un réseau et vous connecter. Vous pouvez également cocher la case à côté de « Se connecter automatiquement » - l'ordinateur se connectera automatiquement à ce réseau s'il est disponible. En règle générale, la vérification des exigences du réseau nécessite la saisie d'un mot de passe, mais il existe parfois une connexion Wi-Fi gratuite.

Étudier le système de contrôle automatisé d'entreprise

Système de contrôle automatisé(en abrégé ACS) est un complexe de matériel et de logiciels, ainsi que de personnel, conçu pour gérer divers processus dans le cadre d'un processus technologique, d'une production ou d'une entreprise. Les ACS sont utilisés dans diverses industries, énergie, transports, etc. Le terme « automatisé », contrairement au terme « automatique », met l'accent sur le maintien de certaines fonctions par l'opérateur humain, soit de nature la plus générale, orientée vers un objectif, soit ne se prêtant pas à l'automatisation. Les ACS dotés d'un système d'aide à la décision (DSS) sont le principal outil pour augmenter la validité des décisions de gestion.

La tâche la plus importante du système de contrôle automatisé est d'augmenter l'efficacité de la gestion des installations sur la base d'une productivité accrue du travail et de méthodes améliorées de planification du processus de gestion. Il existe des systèmes automatisés de gestion des installations ( processus technologiques- système de contrôle de processus automatisé, entreprise - système de contrôle automatisé, industrie - système de contrôle automatisé) et systèmes automatisés fonctionnels, par exemple, conception de calculs planifiés, logistique, etc.

En général, un système de gestion peut être considéré comme un ensemble de processus et d'objets de gestion interdépendants. L'objectif général de l'automatisation du contrôle est d'augmenter l'efficacité de l'utilisation des capacités potentielles de l'objet de contrôle. Ainsi, plusieurs objectifs peuvent être identifiés :

fournir au décideur (DM) des données pertinentes pour la prise de décision ;

accélération des opérations individuelles de collecte et de traitement des données ;

réduire le nombre de décisions que le décideur doit prendre ;

augmenter le niveau de contrôle et de discipline de performance ;

accroître l'efficacité de la gestion;

réduire les coûts des décideurs pour l'exécution des processus auxiliaires ;

augmenter le degré de validité des décisions prises.

L'ACS comprend les types de support suivants : informationnel, logiciel, technique, organisationnel, métrologique, juridique et linguistique.

Les principaux critères de classification qui déterminent le type de système de contrôle automatisé sont :

domaine d'exploitation de l'objet de contrôle (industrie, construction, transport, Agriculture, sphère non industrielle, etc.) ;

type de processus maîtrisé (technologique, organisationnel, économique, etc.) ;

niveau du système d’administration publique.

Les fonctions AC sont réglées sur Termes de référence créer un système de contrôle automatisé spécifique basé sur une analyse des objectifs de gestion, des ressources spécifiées pour les atteindre, de l'effet attendu de l'automatisation et conformément aux normes applicables à ce type de système de contrôle automatisé. Chaque fonction ACS est mise en œuvre par un ensemble de complexes de tâches, de tâches individuelles et d'opérations. Les fonctions du système de contrôle automatisé comprennent généralement les éléments (actions) suivants :

planification et (ou) prévision ;

comptabilité, contrôle, analyse;

coordination et (ou) régulation.

La composition requise des éléments est sélectionnée en fonction du type de système de contrôle automatisé spécifique. Les fonctions du système de contrôle automatisé peuvent être combinées en sous-systèmes selon des caractéristiques fonctionnelles et autres.

Cours 13 Diagnostic réseau

Conférence 13

Sujet : Diagnostic réseau

UN. Administrateurs réseau qui façonnent l’environnement réseau (la grande minorité).

b. Des utilisateurs du réseau contraints de maîtriser cet environnement et d'y vivre.

La deuxième catégorie, en raison de sa supériorité numérique, est capable de poser tant de questions auxquelles la première, même si nombreuse, ne pourrait répondre. Les questions peuvent être simples, par exemple : « Pourquoi la messagerie électronique ne fonctionne-t-elle pas ? (bien que l'on sache que le deuxième jour pour non-paiement, la totalité centre informatique). Il en existe aussi des plus complexes : « Comment réduire le délai de réponse si le canal est surchargé ?

Le nombre de réseaux informatiques augmente de façon exponentielle, le nombre de grands réseaux (>10 PC) et multiprotocoles (802.11, 802.16, 802.17, etc.) augmente. À mesure que le réseau se développe, sa maintenance et ses diagnostics deviennent plus compliqués, ce à quoi l'administrateur est confronté dès la première panne. Il est très difficile de diagnostiquer les réseaux multisegments dans lesquels les PC sont dispersés dans un grand nombre de locaux, très éloignés les uns des autres. Pour cette raison, l'administrateur réseau doit commencer à étudier les caractéristiques de son réseau dès la phase de sa formation et se préparer, ainsi que le réseau, aux réparations futures.

Si une situation d'urgence survient, l'administrateur doit être en mesure de répondre à un certain nombre de questions :

Il y a un problème matériel ou logiciel ;

L'échec est dû à une corruption du programme, à des choix de configuration incorrects ou à une erreur de l'opérateur.

Le diagnostic du réseau est le processus d'obtention et de traitement d'informations sur l'état du réseau.

Documenter le réseau

Vous devez commencer par une documentation complète du matériel et des logiciels du réseau. L'administrateur doit toujours avoir à portée de main un schéma de réseau correspondant à la situation actuelle et une description détaillée de la configuration du logiciel indiquant tous les paramètres (adresses physiques et IP de toutes les interfaces, masques, noms de PC, routeurs, MTU, MSS, TTL et autres). valeurs variables du système, valeurs RTT typiques et autres paramètres de réseau mesurés dans différents modes.).

Au sein d'un réseau local, le dépannage est possible en le divisant temporairement en parties. À mesure que le réseau s’intègre davantage à Internet, ces mesures simples deviennent insuffisantes, voire inacceptables. Mais nous ne devrions pas négliger ces par des moyens simples, comme la vérification d'une rupture ou d'un court-circuit dans le câble réseau.

Il ne faut pas oublier que les diagnostics réseau constituent la base de la sécurité des réseaux. Seul un administrateur connaissant tout ce qui se passe sur le réseau peut être sûr de sa sécurité.

Le cours supposera que le réseau au niveau physique utilise la norme Ethernet et, pour la communication inter-réseaux, le protocole TCP/IP (Internet). Cette liste n'épuise pas la variété des environnements réseau, mais de nombreuses techniques et outils de diagnostic logiciels peuvent être utilisés avec succès dans d'autres cas. La plupart des programmes considérés fonctionnent dans l'environnement UNIX, mais il existe des analogues pour d'autres systèmes d'exploitation.

La source des informations de diagnostic peut être un ordinateur, son processeur, son interface réseau, le système d'exploitation installé sur la machine, les commutateurs réseau, les routeurs, etc.

Le passage aux normes de transmission de 1 et surtout 10 Gbit/s pose des problèmes supplémentaires. Le traitement de ces flux à des fins de diagnostic peut ralentir considérablement la machine. Des problèmes similaires surviennent lors de la création de systèmes IPS/IDS, ainsi que de programmes antivirus. Cependant, ce problème devient également grave en raison de la croissance fantastique du nombre de signatures (millions) d'attaques et de virus. Une façon de résoudre le problème consiste à utiliser du matériel, ainsi qu'à organiser plusieurs threads de traitement, ce qui est tout à fait réaliste pour les machines équipées de plusieurs processeurs.

Logiciel de diagnostic

Il existe de nombreux logiciels de diagnostic spécialisés accessibles au public sur Internet : Etherfind, Tcpdump, netwatch, snmpman, netguard, ws_watch.

De tels outils sont également inclus dans la livraison de la plupart des packages réseau standard pour MS-DOS, UNIX, Windows NT, VMS et autres : ping, tracetoute, netstat, arp, snpi, dig (venera.isi.edu /pub), hosts, nslookup, ifconfig, ripquery. Les programmes de diagnostic répertoriés ci-dessus sont des outils essentiels pour déboguer les programmes qui envoient et reçoivent des paquets.

Commandes de diagnostic du système d'exploitation

Tableau 1.

Nom de l'équipe Objectif

arp Affiche ou modifie la table du protocole ARP (traduction d'adresse IP vers MAC)

chnamsv Utilisé pour modifier la configuration du service de noms sur un ordinateur (pour TCP/IP)

chprtsv Modifie la configuration du service d'impression sur un ordinateur client ou serveur

gettable Obtient les tables informatiques au format NIC

hostent Manipule directement les enregistrements de correspondance d'adresses d'ordinateur dans la base de données de configuration du système

hostid Définit ou affiche l'identifiant de cet ordinateur

hostname Définit ou affiche le nom de cet ordinateur

htable Convertit les fichiers informatiques dans un format utilisé par les programmes de bibliothèque réseau

ifconfig Configure ou affiche les paramètres des interfaces réseau informatiques (pour les protocoles TCP/IP)

ipreport Génère un rapport de route de paquets basé sur le fichier de route spécifié

iptrace Fournit le suivi de l'itinéraire des paquets au niveau de l'interface pour les protocoles Internet

lsnamsv Affiche les informations de la base de données DNS

lsprtsv Affiche les informations de la base de données du service d'impression réseau

mkhost Crée un fichier de table PC

mknamsv Configure le service de nom de client PC (pour TCP/IP)

mktcpip Définit les valeurs requises pour exécuter TCP/IP sur l'ordinateur

namerslv Manipule directement les enregistrements du serveur de noms pour un programme DNS local dans la base de données de configuration du système

netstat Affiche l'état du réseau

non Configure les options réseau

rmnamsv Supprime le service de noms TCP/IP de l'hôte

rmprtsv Supprime le service d'impression sur un ordinateur client ou serveur

route Utilisé pour la manipulation manuelle des tables de routage

ruptime Affiche l'état de chaque ordinateur sur le réseau

user Manipule directement les enregistrements dans trois bases de données système distinctes qui régulent l'accès des ordinateurs externes aux programmes

securetcpip Active la sécurité du réseau

setclock Définit l'heure et la date d'un ordinateur sur le réseau

slattach Connecte les canaux série en tant qu'interfaces réseau

timedc Envoie des informations sur le démon timed

trpt Effectue le suivi de la mise en œuvre du protocole pour les sockets TCP

Afin de diagnostiquer une situation de réseau, il est nécessaire de comprendre l'interaction de ses différentes parties dans le cadre des protocoles TCP/IP et d'avoir une certaine compréhension du fonctionnement d'Ethernet.

Réseaux, recommandations suivantes Internet, disposer d'un serveur de noms local (DNS, RFC-1912, -1886, -1713, -1706, -1611-12, -1536-37, -1183, -1101, -1034-35 ; les chiffres en gras correspondent aux codes de documents contenant des descriptions de normes), qui sert à convertir le nom symbolique d'un objet réseau en son adresse IP. Généralement, cette machine est basée sur le système d'exploitation UNIX.

Le serveur DNS gère une base de données correspondante qui stocke de nombreuses autres informations utiles. De nombreux PC ont des résidents SNMP (RFC-1901-7, -1446-5, -1418-20, -1353, -1270, -1157, -1098) desservant la base de données MIB de gestion (RFC-1792, -1748-49, - 1743, -1697, -1573, -1565-66, -1513-14, -1230, -1227, -1212-13), dont le contenu vous aidera également à apprendre beaucoup de choses intéressantes sur l'état de votre réseau . L'idéologie Internet elle-même présuppose des diagnostics riches (protocole ICMP, RFC-1256, 1885, -1788, -792).

Utilisation du protocole ICMP

Le protocole ICMP est utilisé dans le programme de diagnostic le plus populaire, ping (inclus dans presque tous les packages réseau). Une forme possible d'appel de ce programme est :

pinger<имя или адрес ЭВМ или другого объекта>[taille du colis] [nombre de colis]

Dans diverses implémentations, le programme ping dispose de nombreuses options différentes qui vous permettent de mesurer les caractéristiques statistiques du lien (par exemple, la perte), de déterminer le délai sur le lien (RTT), d'afficher les paquets envoyés et les réponses reçues et de déterminer le itinéraire jusqu'au point d'intérêt. Ping est utilisé pour déterminer la disponibilité du fournisseur de services, etc.

Ci-dessous un exemple d'utilisation de la commande tracetoute, qui est largement équivalente à ping (mais basée directement sur IP en utilisant les options appropriées) :

traceroute kirk.Bond.edu.au

Le programme traceroute envoie trois paquets avec des valeurs TTL croissantes ; si aucune réponse au paquet n'est reçue, le caractère * est imprimé. Les grands retards (RTT) dans l'exemple ci-dessus sont déterminés par les canaux de communication par satellite (temps de propagation du signal vers le satellite !).

Afin de répondre correctement aux situations d’urgence, vous devez bien comprendre comment le réseau devrait fonctionner dans des conditions normales. Pour ce faire, vous devez étudier le réseau, sa topologie, les connexions externes, la configuration logicielle des serveurs centraux et des PC périphériques. Il convient de garder à l'esprit que la modification de la configuration est généralement le privilège de l'administrateur système et qu'en cas de doute, vous devez le contacter. Des actions non qualifiées lors de la reconfiguration d'un système peuvent avoir des conséquences catastrophiques.

Utiliser DNS à des fins de diagnostic

Comme indiqué ci-dessus, l'un des éléments les plus importants de tout nœud Internet est le serveur de noms (DNS). La configuration du serveur DNS est déterminée par trois fichiers : nommé.boot, nommé.ca et nommé.local. Les informations sur la zone sont contenues dans le fichier nommé.rev et les informations sur le domaine local sont contenues dans le fichier nommé.hosts. Le débogage, la surveillance et le diagnostic du serveur DNS sont effectués à l'aide des programmes nslookup (ou dig).

Le serveur DNS est un objet nœud très important, la rapidité des demandes de service et la fiabilité du système dans son ensemble en dépendent. C'est pour cette raison qu'en plus du principal, tout nœud dispose de plusieurs serveurs DNS secondaires.

Le programme ifconfig est utilisé pour surveiller l'état des interfaces réseau, les configurer et les tester. Cette commande attribue une adresse IP, un masque de sous-réseau et une adresse de diffusion à l'interface.

Application de NETSTAT

L'une des commandes les plus informatives est netstat (pour une description complète des options et des méthodes d'application, je vous renvoie à la documentation de votre logiciel réseau).

Cette commande peut vous donner des informations sur l'état des interfaces du PC où elle est exécutée : netstat -i

Récemment, plusieurs packages de diagnostic complets (accessibles au public) sont apparus (NetWatch, WS_watch, SNMPMAN, Netguard, etc.). Certains de ces packages vous permettent de créer modèle graphique le réseau testé, en mettant en évidence les ordinateurs en état de marche en couleur ou en utilisant une variation d'images. Les programmes qui utilisent le protocole SNMP vérifient la disponibilité du démon SNMP via une requête spéciale, déterminent le fonctionnement de l'ordinateur à l'aide du protocole ICMP, puis affichent les variables et les tableaux de données de la base de données de contrôle MIB (si cette base de données a un niveau d'accès public ). Cela peut se faire automatiquement ou à la demande de l'opérateur. Le protocole SNMP permet de surveiller les variations de charge de segments individuels du réseau avec des paquets UDP, TCP, ICMP, etc., en enregistrant le nombre d'erreurs pour chacune des interfaces actives. Pour résoudre ce problème, vous pouvez utiliser un programme approprié qui interroge régulièrement la MIB des ordinateurs qui vous intéressent et les numéros résultants sont saisis dans la banque de données appropriée. En cas d'urgence, l'administrateur réseau peut visualiser les variations des flux dans les segments du réseau et identifier l'heure et la cause de la panne du système. Des données similaires peuvent être obtenues à l'aide d'un programme qui fait passer l'interface Ethernet en mode de réception de tous les paquets (mode=6). Un tel programme permet de recevoir des données sur tous types de paquets circulant dans un segment de câble donné.

Le programme de diagnostic ttcp peut être particulièrement intéressant, car il permet de mesurer certaines caractéristiques des échanges TCP ou UDP entre deux nœuds.

Lorsque les réseaux évoluent vers la plage de vitesse du gigabit, en particulier jusqu'à 10 Gbit/s, des difficultés surviennent dans la surveillance de l'état du réseau.

Très souvent, le diagnostic d'un réseau local consiste à tester uniquement son système de câblage. Ce n'est pas tout à fait vrai. Le système de câble est l'un des composants les plus importants d'un réseau local, mais il est loin d'être le seul et pas le plus difficile du point de vue du diagnostic. Outre l'état du système de câble, la qualité du fonctionnement du réseau est fortement influencée par l'état des équipements actifs (cartes réseau, hubs, commutateurs), la qualité de l'équipement du serveur et les paramètres du système d'exploitation réseau. De plus, le fonctionnement du réseau dépend largement des algorithmes de fonctionnement des logiciels d'application qui y sont utilisés.

Par le terme « réseau local », nous comprendrons l'ensemble du complexe matériel et logiciel ci-dessus ; et le terme « diagnostic du réseau local » est le processus de détermination des raisons du fonctionnement insatisfaisant du logiciel d'application sur le réseau. C'est la qualité des logiciels d'application sur le réseau qui est déterminante du point de vue des utilisateurs. Tous les autres critères, tels que le nombre d'erreurs de transmission de données, le degré d'encombrement des ressources du réseau, les performances des équipements, etc., sont secondaires. Un « bon réseau » est un réseau dont les utilisateurs ne remarquent pas son fonctionnement.

Détection de défauts dans la couche physique du réseau : système de câblage, système d'alimentation des équipements actifs ; présence de bruit provenant de sources externes.

Mesurer la charge actuelle du canal de communication réseau et déterminer l'influence de la valeur de charge du canal de communication sur le temps de réponse du logiciel d'application.

Mesurer le nombre de collisions dans le réseau et connaître les raisons de leur apparition.

Mesurer le nombre d'erreurs de transmission de données au niveau du canal de communication et identifier les causes de leur apparition.

Identification des défauts de l'architecture réseau.

Mesurer la charge actuelle du serveur et déterminer l'impact de sa charge sur le temps de réponse des logiciels d'application.

Identification des défauts des logiciels d'application, qui entraînent une utilisation inefficace de la bande passante du serveur et du réseau.

Dans cet article, nous considérerons les quatre premières étapes du diagnostic complexe d'un réseau local, à savoir : le diagnostic au niveau du lien réseau.

Je voudrais attirer votre attention sur deux points, d'autant plus qu'ils sont souvent oubliés lors du test d'un système de câble réseau à l'aide d'un scanner.

Le mode AUTOTEST ne permet pas de vérifier le niveau de bruit créé par une source externe dans le câble. Il peut s'agir du bruit d'une lampe fluorescente, d'un câblage électrique, d'un téléphone portable, d'une photocopieuse puissante, etc. Les scanners de câbles ont généralement une fonction spéciale pour déterminer le niveau de bruit. Étant donné que le système de câblage réseau n'est entièrement testé qu'au stade de l'installation et que le bruit dans le câble peut se produire de manière imprévisible, il n'y a aucune garantie totale que du bruit apparaîtra lors d'un test de réseau à grande échelle au stade de l'installation.

Avant d’écrire « rien ne fonctionne pour moi », essayez de découvrir ce qui ne fonctionne pas spécifiquement pour vous.

Si vous décidez de laisser un message sur le forum/VKontakte, veuillez noter que le message n'est pas considéré comme une demande officielle au service d'assistance technique ; les contacts du service d'assistance technique se trouvent sur la page principale du site.

Veuillez lire au moins quelques messages du fil de discussion avant de poster dernière page- il est possible que ce problème ait déjà été résolu ou soit déjà en cours de résolution !

Commandes de diagnostic :

*Exécuté dans une fenêtre de « ligne de commande » précédemment ouverte. (Démarrer -> Tous les programmes -> Accessoires -> Ligne de commande)
Pour Windows Vista/7 : Win+R ===> cmd ===> Entrée
Pour Windows NT/2000/XP/VISTA : "Démarrer" - "Exécuter" - "cmd"
Pour Windows 95/98 : "Démarrer" - "Exécuter" - "commande".

Copier le texte: clic-droit dans cette fenêtre - "éditer" - "sélectionner" et "éditer" - "copier".

ipconfig / tout
nslookup
ping [adresse de l'hôte (par exemple, ya.ru)] [-n 20]
chemin d'accès [adresse de l'hôte]
tracert [adresse de l'hôte]

ipconfig /all affiche les paramètres de l'interface réseau.
Tout ce qui y est indiqué doit être vérifié avec le mémo de l'utilisateur (si le mémo est ancien, alors vérifiez avec les données qui ont été émises soutien technique). Découvrez comment établir une connexion sur le site Web.

ping [-t] affiche le temps de réponse de l'hôte spécifié. Des retards importants peuvent indirectement servir d'indicateur d'une ressource lente (canal chargé, ressource matérielle faible, etc. problèmes similaires). La touche [-t] permet d'exécuter une commande avant que l'utilisateur ne l'interrompe en appuyant sur "Ctrl+C". Par défaut, sans cette clé, le ping ne sera exécuté que quatre fois, ce qui n'est pas toujours suffisant.

pathping Affiche le temps de réponse et le nombre de paquets manquants tout au long du parcours vers l'hôte.

tracer
Pour afficher graphiquement les problèmes, vous pouvez télécharger le programme PingPlotter depuis le réseau local

nslookup
Vérifier Opération DNS.

Algorithme de vérification : erreur "Le câble réseau n'est pas connecté"

1. Vérifiez la connexion du câble dans la carte réseau
2. Vérifiez l'intégrité du câble jusqu'au blindage.
3. Appelez le technicien. soutien.

Le câble réseau est connecté, mais il n'y a aucun paquet entrant.

1. Vérifiez la connexion du câble dans la carte réseau (vous pouvez retirer et insérer le câble dans la prise).
2. Désactivez tous les pare-feu (pare-feu), si vous en avez.
3. Pingez la passerelle (prenez l'adresse dans les paramètres de connexion ou dans les informations de connexion dans le panneau de configuration).
4. Appelez le technicien. soutien.

Le câble réseau est connecté, il y a des paquets entrants, mais vous ne pouvez pas accéder aux services internes :

1. Désactivez tous les pare-feu (pare-feu), si vous en avez.
2. Vérifiez le fonctionnement du DNS (nslookup).
3. Vérifiez la connexion avec ces serveurs (ping)
4. Vérifiez la connexion avec les serveurs centraux. (ping online.vo, ping 192.168.0.250, ping_your_gateway_address)
5. Vérifiez les paramètres de votre navigateur
5.1. Internet Explorer-> Menu "Outils" -> "Options Internet" -> "Connexion" -> "Paramètres réseau" -> vérifiez si la case "utiliser le serveur proxy" est désactivée
6. Appelez le technicien. soutien.

Vérification DNS :

La commande du serveur nslookup doit renvoyer l'adresse IP de ce serveur. Par exemple, la commande "nslookup vo47.ru" doit renvoyer l'adresse "193.106.108.68".

Commandes de diagnostic

Équipe	But	Format de lancement	Exemple
ipconfig	Affiche les paramètres de l'interface réseau	ipconfig / tout
netstat	Affiche la table de routage	netstat -n°
nslookup	Contacte le serveur DNS (s'il n'est pas spécifié, il est extrait des paramètres Windows) pour convertir le nom DNS de l'ordinateur en son adresse IP ou vice versa	nslookup DNS_name_or_IP_address Adresse IP du serveur_DNS	nslookup vo47.ru nslookup ya.ru 193.106.108.67
pinger	Vérifie la disponibilité de la communication avec un autre ordinateur et la vitesse de réponse. Ce n'est pas un moyen de mesurer la vitesse de connexion.	pinger Nom DNS_ou_adresse IP	ping www.vo47.ru ping 193.106.108.97
tracer	Identique au ping, mais avec sortie d'informations pour tous les nœuds intermédiaires	tracert -d Nom DNS_ou_adresse IP	tracert -d cs47.ru
cheminement	Identique à Tracert, mais en plus en détail et indiquant le pourcentage de pertes	cheminement Nom DNS_ou_adresse IP	chemin d'accès vk.com

Site sur l'informatique

Commandes de diagnostic

ARTICLES LIÉS