Lorsque je travaillais dans un rôle axé sur le réseau, l'un des plus grands défis consistait toujours à combler le fossé entre l'ingénierie réseau et système. Les administrateurs système, manquant de visibilité sur le réseau, accusaient souvent le réseau de pannes ou de problèmes étranges. Les administrateurs réseau, incapables de contrôler les serveurs et fatigués par l'attitude "coupable jusqu'à preuve du contraire" envers le réseau, blâmaient souvent les points de terminaison du réseau.
Bien sûr, le blâme ne résout pas les problèmes. Prendre le temps de comprendre les bases du domaine de quelqu'un peut grandement contribuer à améliorer les relations avec les autres équipes et à accélérer la résolution des problèmes. Ce fait est particulièrement vrai pour les administrateurs système. En ayant une compréhension de base du dépannage du réseau, nous pouvons apporter des preuves plus solides à nos collègues du réseau lorsque nous soupçonnons que le réseau peut être défectueux. De même, nous pouvons souvent gagner du temps en effectuant nous-mêmes un dépannage initial.
Dans cet article, nous aborderons les bases du dépannage réseau via la ligne de commande Linux.
Un examen rapide du modèle TCP/IP
Tout d'abord, prenons un moment pour passer en revue les principes fondamentaux du modèle de réseau TCP/IP. Alors que la plupart des gens utilisent le modèle d'interconnexion de systèmes ouverts (OSI) pour discuter de la théorie des réseaux, le modèle TCP/IP représente plus précisément la suite de protocoles déployés dans les réseaux modernes.
Les couches du modèle de réseau TCP/IP incluent, dans l'ordre :
- Couche 5 : Candidature
- Couche 4 : Transport
- Couche 3 : Réseau/Internet
- Couche 2 : Lien de données
- Couche 1 : Physique
Je suppose que vous connaissez ce modèle et je vais continuer en discutant des moyens de résoudre les problèmes au niveau des couches de pile 1 à 4. Où commencer le dépannage dépend de la situation. Par exemple, si vous pouvez vous connecter en SSH à un serveur, mais que le serveur ne peut pas se connecter à une base de données MySQL, il est peu probable que le problème provienne des couches physiques ou de liaison de données sur le serveur local. En général, c'est une bonne idée de travailler votre chemin vers le bas de la pile. Commencez par l'application, puis dépannez progressivement chaque couche inférieure jusqu'à ce que vous ayez isolé le problème.
Avec cet arrière-plan à l'écart, passons à la ligne de commande et commençons le dépannage.
Couche 1 :la couche physique
Nous prenons souvent la couche physique pour acquise ("vous êtes-vous assuré que le câble est branché ?"), mais nous pouvons facilement résoudre les problèmes de couche physique à partir de la ligne de commande Linux. C'est-à-dire si vous disposez d'une connectivité console à l'hôte, ce qui peut ne pas être le cas pour certains systèmes distants.
Commençons par la question la plus fondamentale :notre interface physique est-elle opérationnelle ? Le ip link show commande nous dit :
# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:82:d6:6e brd ff:ff:ff:ff:ff:ff
Notez l'indication de DOWN dans la sortie ci-dessus pour l'interface eth0. Ce résultat signifie que la couche 1 n'apparaît pas. Nous pouvons essayer de résoudre les problèmes en vérifiant le câblage ou l'extrémité distante de la connexion (par exemple, le commutateur).
Avant de commencer à vérifier les câbles, cependant, c'est une bonne idée de s'assurer que l'interface n'est pas simplement désactivée. L'émission d'une commande pour afficher l'interface peut résoudre ce problème :
# ip link set eth0 up
La sortie de ip link show peut être difficile à analyser en un coup d'œil. Heureusement, le -br switch imprime cette sortie dans un format de tableau beaucoup plus lisible :
# ip -br link show
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0 UP 52:54:00:82:d6:6e <BROADCAST,MULTICAST,UP,LOWER_UP>
Il ressemble à ip link set eth0 up a fait le tour, et eth0 est de retour dans les affaires.
Ces commandes sont idéales pour résoudre des problèmes physiques évidents, mais qu'en est-il des problèmes plus insidieux ? Les interfaces peuvent négocier à une vitesse incorrecte, ou des collisions et des problèmes de couche physique peuvent entraîner une perte ou une corruption de paquets entraînant des retransmissions coûteuses. Comment commencer à résoudre ces problèmes ?
Nous pouvons utiliser le -s drapeau avec l'ip commande pour imprimer des statistiques supplémentaires sur une interface. La sortie ci-dessous montre une interface essentiellement propre, avec seulement quelques paquets de réception abandonnés et aucun autre signe de problème de couche physique :
# ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:82:d6:6e brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
34107919 5808 0 6 0 0
TX: bytes packets errors dropped carrier collsns
434573 4487 0 0 0 0
Pour un dépannage plus avancé de la couche 1, le ethtool utilitaire est une excellente option. Un cas d'utilisation particulièrement intéressant pour cette commande consiste à vérifier si une interface a négocié la bonne vitesse. Une interface qui a négocié la mauvaise vitesse (par exemple, une interface de 10 Gbit/s qui ne signale que des vitesses de 1 Gbit/s) peut être un indicateur d'un problème de matériel/câblage, ou d'une mauvaise configuration de négociation d'un côté de la liaison (par exemple, un port de commutateur mal configuré).
Nos résultats pourraient ressembler à ceci :
# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: on (auto)
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
Notez que la sortie ci-dessus montre un lien qui a correctement négocié à une vitesse de 1000 Mbps et en duplex intégral.
Couche 2 :la couche de liaison de données
La couche liaison de données est responsable de local connectivité réseau ; essentiellement, la communication de trames entre hôtes sur le même domaine de couche 2 (communément appelé réseau local). Le protocole de couche 2 le plus pertinent pour la plupart des administrateurs système est le protocole de résolution d'adresse (ARP), qui mappe les adresses IP de couche 3 aux adresses MAC Ethernet de couche 2. Lorsqu'un hôte essaie de contacter un autre hôte sur son réseau local (comme la passerelle par défaut), il a probablement l'adresse IP de l'autre hôte, mais il ne connaît pas l'adresse MAC de l'autre hôte. ARP résout ce problème et calcule l'adresse MAC pour nous.
Un problème courant que vous pourriez rencontrer est une entrée ARP qui ne se remplira pas, en particulier pour la passerelle par défaut de votre hôte. Si votre hôte local ne peut pas résoudre avec succès l'adresse MAC de couche 2 de sa passerelle, il ne pourra pas envoyer de trafic vers des réseaux distants. Ce problème peut être causé par une mauvaise adresse IP configurée pour la passerelle, ou il peut s'agir d'un autre problème, tel qu'un port de commutateur mal configuré.
Nous pouvons vérifier les entrées de notre table ARP avec le ip neighbor commande :
# ip neighbor show
192.168.122.1 dev eth0 lladdr 52:54:00:11:23:84 REACHABLE
Notez que l'adresse MAC de la passerelle est renseignée (nous parlerons plus en détail de la façon de trouver votre passerelle dans la section suivante). S'il y avait un problème avec ARP, alors nous verrions un échec de résolution :
# ip neighbor show
192.168.122.1 dev eth0 FAILED
Une autre utilisation courante du ip neighbor La commande implique la manipulation de la table ARP. Imaginez que votre équipe réseau vient de remplacer le routeur en amont (qui est la passerelle par défaut de votre serveur). L'adresse MAC peut également avoir changé puisque les adresses MAC sont des adresses matérielles attribuées en usine.
Remarque : Bien que des adresses MAC uniques soient attribuées aux appareils en usine, il est possible de les modifier ou de les usurper. De nombreux réseaux modernes utilisent également des protocoles tels que le protocole VRRP (Virtual Router Redundancy Protocol), qui utilisent une adresse MAC générée.
Linux met en cache l'entrée ARP pendant un certain temps, de sorte que vous ne pourrez peut-être pas envoyer de trafic vers votre passerelle par défaut tant que l'entrée ARP de votre passerelle n'aura pas expiré. Pour les systèmes très importants, ce résultat n'est pas souhaitable. Heureusement, vous pouvez supprimer manuellement une entrée ARP, ce qui forcera un nouveau processus de découverte ARP :
# ip neighbor show
192.168.122.170 dev eth0 lladdr 52:54:00:04:2c:5d REACHABLE
192.168.122.1 dev eth0 lladdr 52:54:00:11:23:84 REACHABLE
# ip neighbor delete 192.168.122.170 dev eth0
# ip neighbor show
192.168.122.1 dev eth0 lladdr 52:54:00:11:23:84 REACHABLE
Dans l'exemple ci-dessus, nous voyons une entrée ARP remplie pour 192.168.122.70 sur eth0. Nous supprimons ensuite l'entrée ARP et pouvons voir qu'elle a été supprimée de la table.
Couche 3 :la couche réseau/internet
La couche 3 implique de travailler avec des adresses IP, qui devraient être familières à tout administrateur système. L'adressage IP fournit aux hôtes un moyen d'atteindre d'autres hôtes qui se trouvent en dehors de leur réseau local (bien que nous les utilisions souvent également sur les réseaux locaux). L'une des premières étapes du dépannage consiste à vérifier l'adresse IP locale d'une machine, ce qui peut être fait avec l'ip address commande, en utilisant à nouveau le -br drapeau pour simplifier la sortie :
# ip -br address show
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 192.168.122.135/24 fe80::184e:a34d:1d37:441a/64 fe80::c52f:d96e:a4a2:743/64
Nous pouvons voir que notre interface eth0 a une adresse IPv4 de 192.168.122.135. Si nous n'avions pas d'adresse IP, nous voudrions résoudre ce problème. L'absence d'adresse IP peut être causée par une mauvaise configuration locale, comme un fichier de configuration d'interface réseau incorrect, ou par des problèmes avec DHCP.
L'outil de première ligne le plus courant que la plupart des administrateurs système utilisent pour dépanner la couche 3 est le ping utilitaire. Ping envoie un paquet de demande d'écho ICMP à un hôte distant et attend une réponse d'écho ICMP en retour. Si vous rencontrez des problèmes de connectivité avec un hôte distant, ping est un utilitaire commun pour commencer votre dépannage. L'exécution d'un simple ping depuis la ligne de commande envoie indéfiniment des échos ICMP à l'hôte distant; vous aurez besoin de CTRL+C pour terminer le ping ou passer le -c <num pings> drapeau, comme ceci :
# ping www.google.com
PING www.google.com (172.217.165.4) 56(84) bytes of data.
64 bytes from yyz12s06-in-f4.1e100.net (172.217.165.4): icmp_seq=1 ttl=54 time=12.5 ms
64 bytes from yyz12s06-in-f4.1e100.net (172.217.165.4): icmp_seq=2 ttl=54 time=12.6 ms
64 bytes from yyz12s06-in-f4.1e100.net (172.217.165.4): icmp_seq=3 ttl=54 time=12.5 ms
^C
--- www.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 12.527/12.567/12.615/0.036 ms
Notez que chaque ping inclut le temps qu'il a fallu pour recevoir une réponse. Pendant le ping peut être un moyen facile de savoir si un hôte est vivant et répond, ce n'est en aucun cas définitif. De nombreux opérateurs de réseau bloquent les paquets ICMP par mesure de sécurité, bien que de nombreux autres ne soient pas d'accord avec cette pratique. Un autre piège courant consiste à s'appuyer sur le champ temporel comme indicateur précis de la latence du réseau. Les paquets ICMP peuvent être limités en débit par un équipement réseau intermédiaire, et ils ne doivent pas être utilisés pour fournir de véritables représentations de la latence des applications.
L'outil suivant dans la ceinture d'outils de dépannage de la couche 3 est le traceroute commande. Traceroute tire parti du champ Time to Live (TTL) dans les paquets IP pour déterminer le chemin emprunté par le trafic jusqu'à sa destination. Traceroute enverra un paquet à la fois, en commençant par un TTL de un. Comme le paquet expire en transit, le routeur en amont renvoie un paquet ICMP Time-to-Live Exceeded. Traceroute incrémente ensuite le TTL pour déterminer le saut suivant. La sortie résultante est une liste de routeurs intermédiaires qu'un paquet a traversés sur son chemin vers la destination :
# traceroute www.google.com
traceroute to www.google.com (172.217.10.36), 30 hops max, 60 byte packets
1 acritelli-laptop (192.168.122.1) 0.103 ms 0.057 ms 0.027 ms
2 192.168.1.1 (192.168.1.1) 5.302 ms 8.024 ms 8.021 ms
3 142.254.218.133 (142.254.218.133) 20.754 ms 25.862 ms 25.826 ms
4 agg58.rochnyei01h.northeast.rr.com (24.58.233.117) 35.770 ms 35.772 ms 35.754 ms
5 agg62.hnrtnyaf02r.northeast.rr.com (24.58.52.46) 25.983 ms 32.833 ms 32.864 ms
6 be28.albynyyf01r.northeast.rr.com (24.58.32.70) 43.963 ms 43.067 ms 43.084 ms
7 bu-ether16.nycmny837aw-bcr00.tbone.rr.com (66.109.6.74) 47.566 ms 32.169 ms 32.995 ms
8 0.ae1.pr0.nyc20.tbone.rr.com (66.109.6.163) 27.277 ms * 0.ae4.pr0.nyc20.tbone.rr.com (66.109.1.35) 32.270 ms
9 ix-ae-6-0.tcore1.n75-new-york.as6453.net (66.110.96.53) 32.224 ms ix-ae-10-0.tcore1.n75-new-york.as6453.net (66.110.96.13) 36.775 ms 36.701 ms
10 72.14.195.232 (72.14.195.232) 32.041 ms 31.935 ms 31.843 ms
11 * * *
12 216.239.62.20 (216.239.62.20) 70.011 ms 172.253.69.220 (172.253.69.220) 83.370 ms lga34s13-in-f4.1e100.net (172.217.10.36) 38.067 ms
Traceroute semble être un excellent outil, mais il est important de comprendre ses limites. Comme avec ICMP, les routeurs intermédiaires peuvent filtrer les paquets qui traceroute dépend, comme le message ICMP Time-to-Live Exceeded. Mais plus important encore, le chemin emprunté par le trafic vers et depuis une destination n'est pas nécessairement symétrique, et ce n'est pas toujours le même. Traceroute peut vous induire en erreur en pensant que votre trafic emprunte un beau chemin linéaire vers et depuis sa destination. Cependant, cette situation est rarement le cas. Le trafic peut suivre un chemin de retour différent, et les chemins peuvent changer dynamiquement pour de nombreuses raisons. Tandis que traceroute peut fournir des représentations de chemin précises dans les petits réseaux d'entreprise, il n'est souvent pas précis lorsque vous essayez de tracer sur de grands réseaux ou sur Internet.
Un autre problème courant que vous rencontrerez probablement est l'absence d'une passerelle en amont pour une route particulière ou l'absence d'une route par défaut. Lorsqu'un paquet IP est envoyé à un réseau différent, il doit être envoyé à une passerelle pour un traitement ultérieur. La passerelle doit savoir comment acheminer le paquet vers sa destination finale. La liste des passerelles pour les différentes routes est stockée dans une table de routage , qui peut être inspecté et manipulé à l'aide de ip route commandes.
Nous pouvons imprimer la table de routage en utilisant le ip route show commande :
# ip route show
default via 192.168.122.1 dev eth0 proto dhcp metric 100
192.168.122.0/24 dev eth0 proto kernel scope link src 192.168.122.135 metric 100
Les topologies simples n'ont souvent qu'une passerelle par défaut configurée, représentée par l'entrée "par défaut" en haut du tableau. Une passerelle par défaut manquante ou incorrecte est un problème courant.
Si notre topologie est plus complexe et que nous avons besoin de routes différentes pour différents réseaux, nous pouvons vérifier la route pour un préfixe spécifique :
# ip route show 10.0.0.0/8
10.0.0.0/8 via 192.168.122.200 dev eth0
Dans l'exemple ci-dessus, nous envoyons tout le trafic destiné au réseau 10.0.0.0/8 vers une passerelle différente (192.168.122.200).
Bien qu'il ne s'agisse pas d'un protocole de couche 3, il convient de mentionner DNS lorsque nous parlons d'adressage IP. Entre autres choses, le système de noms de domaine (DNS) traduit les adresses IP en noms lisibles par l'homme, tels que www.redhat.com . Les problèmes de DNS sont extrêmement courants et ils sont parfois difficiles à résoudre. De nombreux livres et guides en ligne ont été écrits sur le DNS, mais nous nous concentrerons ici sur les bases.
Un signe révélateur de problèmes DNS est la possibilité de se connecter à un hôte distant par adresse IP mais pas par son nom d'hôte. Effectuer un rapide nslookup sur le nom d'hôte peut nous en dire beaucoup (nslookup fait partie des bind-utils sur les systèmes basés sur Red Hat Enterprise Linux) :
# nslookup www.google.com
Server: 192.168.122.1
Address: 192.168.122.1#53
Non-authoritative answer:
Name: www.google.com
Address: 172.217.3.100
La sortie ci-dessus montre au serveur que la recherche a été effectuée sur 192.168.122.1 et que l'adresse IP résultante était 172.217.3.100.
Si vous effectuez un nslookup pour un hôte mais ping ou traceroute essayez d'utiliser une adresse IP différente, vous êtes probablement confronté à un problème d'entrée de fichier hôte. Par conséquent, inspectez le fichier hôte à la recherche de problèmes :
# nslookup www.google.com
Server: 192.168.122.1
Address: 192.168.122.1#53
Non-authoritative answer:
Name: www.google.com
Address: 172.217.12.132
# ping -c 1 www.google.com
PING www.google.com (1.2.3.4) 56(84) bytes of data.
^C
--- www.google.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
1.2.3.4 www.google.com
Notez que dans l'exemple ci-dessus, l'adresse de www.google.com résolu à 172.217.12.132. Cependant, lorsque nous avons essayé de cingler l'hôte, le trafic était envoyé à 1.2.3.4. Jetez un œil au /etc/hosts fichier, nous pouvons voir un remplacement que quelqu'un a dû ajouter par inadvertance. Les problèmes de remplacement du fichier hôte sont extrêmement courant, surtout si vous travaillez avec des développeurs d'applications qui ont souvent besoin d'effectuer ces remplacements pour tester leur code pendant le développement.
Couche 4 :la couche de transport
La couche de transport comprend les protocoles TCP et UDP, TCP étant un protocole orienté connexion et UDP étant sans connexion. Les applications écoutent sur sockets , qui se composent d'une adresse IP et d'un port. Le trafic destiné à une adresse IP sur un port spécifique sera dirigé vers l'application d'écoute par le noyau. Une discussion complète de ces protocoles dépasse le cadre de cet article, nous allons donc nous concentrer sur la façon de résoudre les problèmes de connectivité au niveau de ces couches.
La première chose que vous voudrez peut-être faire est de voir quels ports écoutent sur l'hôte local. Le résultat peut être utile si vous ne pouvez pas vous connecter à un service particulier sur la machine, comme un serveur Web ou SSH. Un autre problème courant se produit lorsqu'un démon ou un service ne démarre pas à cause de quelque chose d'autre qui écoute sur un port. Le ss La commande est inestimable pour effectuer ces types d'actions :
# ss -tunlp4
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
udp UNCONN 0 0 *:68 *:* users:(("dhclient",pid=3167,fd=6))
udp UNCONN 0 0 127.0.0.1:323 *:* users:(("chronyd",pid=2821,fd=1))
tcp LISTEN 0 128 *:22 *:* users:(("sshd",pid=3366,fd=3))
tcp LISTEN 0 100 127.0.0.1:25 *:* users:(("master",pid=3600,fd=13))
Décomposons ces drapeaux :
- -t - Afficher les ports TCP.
- -u - Afficher les ports UDP.
- -n - N'essayez pas de résoudre les noms d'hôte.
- -l - Afficher uniquement les ports d'écoute.
- -p - Afficher les processus qui utilisent un socket particulier.
- -4 - Afficher uniquement les sockets IPv4.
En regardant la sortie, nous pouvons voir plusieurs services d'écoute. Le sshd l'application écoute sur le port 22 sur toutes les adresses IP, indiquées par le *:22 sortie.
Le ss La commande est un outil puissant, et un examen de sa brève page de manuel peut vous aider à localiser les drapeaux et les options pour trouver ce que vous cherchez.
Un autre scénario de dépannage courant implique la connectivité à distance. Imaginez que votre ordinateur local ne puisse pas se connecter à un port distant, tel que MySQL sur le port 3306. Un outil peu probable, mais couramment installé, peut être votre ami lors du dépannage de ces types de problèmes :telnet . Le telnet La commande tente d'établir une connexion TCP avec l'hôte et le port que vous lui attribuez. Cette fonctionnalité est parfaite pour tester la connectivité TCP à distance :
# telnet database.example.com 3306
Trying 192.168.1.10...
^C
Dans la sortie ci-dessus, telnet pend jusqu'à ce que nous le tuions. Ce résultat nous indique que nous ne pouvons pas accéder au port 3306 sur la machine distante. Peut-être que l'application n'écoute pas, et nous devons utiliser les étapes de dépannage précédentes en utilisant ss sur l'hôte distant, si nous y avons accès. Une autre possibilité est un pare-feu hôte ou intermédiaire qui filtre le trafic. Nous devrons peut-être travailler avec l'équipe réseau pour vérifier la connectivité de la couche 4 sur le chemin.
Telnet fonctionne bien pour TCP, mais qu'en est-il d'UDP ? Le netcat outil fournit un moyen simple de vérifier un port UDP distant :
# nc 192.168.122.1 -u 80
test
Ncat: Connection refused.
Le netcat L'utilitaire peut être utilisé pour de nombreuses autres choses, y compris le test de la connectivité TCP. Notez que netcat peut ne pas être installé sur votre système, et il est souvent considéré comme un risque pour la sécurité de le laisser traîner. Vous voudrez peut-être envisager de le désinstaller lorsque vous aurez terminé le dépannage.
Les exemples ci-dessus traitent d'utilitaires simples et courants. Cependant, un outil beaucoup plus puissant est nmap . Des livres entiers ont été consacrés à nmap fonctionnalité, nous ne la couvrirons donc pas dans cet article pour débutant, mais vous devez connaître certaines des choses qu'elle est capable de faire :
- Analyse des ports TCP et UDP sur les machines distantes
- Empreintes du système d'exploitation
- Déterminer si les ports distants sont fermés ou simplement filtrés.
Conclusion
Nous avons couvert beaucoup de terrain d'introduction au réseau dans cet article, en remontant la pile réseau des câbles et des commutateurs aux adresses IP et aux ports. Les outils présentés ici devraient vous donner un bon point de départ pour résoudre les problèmes de connectivité réseau de base, et ils devraient s'avérer utiles lorsque vous essayez de fournir autant de détails que possible à votre équipe réseau.
Au fur et à mesure que vous progressez dans votre parcours de dépannage réseau, vous rencontrerez sans aucun doute des indicateurs de commande jusque-là inconnus, des lignes simples fantaisistes et de nouveaux outils puissants (tcpdump et Wireshark sont mes favoris) pour approfondir les causes de vos problèmes de réseau. Amusez-vous et rappelez-vous :les paquets ne mentent pas !