Dépannage de la connectivité TCP/IP dans Windows 2000 ou Windows NT

Traductions disponibles Traductions disponibles
Numéro d'article: 102908 - Voir les produits auxquels s'applique cet article
Ancien nº de publication de cet article : F102908
Pour vous procurer une version Microsoft Windows XP de cet article, reportez-vous à l'article 314067.
Agrandir tout | Réduire tout

Résumé

Les utilitaires ARP, PING, FTP, NETSTAT et NBTSTAT peuvent fournir des informations utiles quand vous essayez de déterminer la cause de problèmes de mise en réseau TCP/IP avec Windows. Voici une liste des problèmes TCP/IP possibles et les recommandations pour utiliser ces utilitaires afin de diagnostiquer les problèmes. Bien que cette liste ne soit pas complète, voici des exemples de la façon dont vous pouvez utiliser ces utilitaires pour retrouver les problèmes sur le réseau.

Plus d'informations

Q : Comment savoir si TCP/IP est correctement installé sur un système Windows ?

R : En tentant d'utiliser PING sur le système local en tapant l'adresse de retour de boucle IP de 127.0.0.1 à l'invite de commande :
ping 127.0.0.1


Le système devrait répondre immédiatement. Si PING est introuvable ou si la commande échoue, vérifiez le journal des événements avec l'Observateur d'événements et recherchez les problèmes indiqués par le programme d'installation ou le service TCP/IP. Vous devriez également tenter d'utiliser PING avec les adresses IP de votre/vos interface(s) locale(s) pour déterminer si vous avez configuré IP correctement. Une utilisation réussie de PING indique que la couche IP sur le système cible est probablement fonctionnelle.

Q : Comment savoir si le serveur FTP est correctement installé sur un système Windows ?

R : En tentant d'utiliser FTP sur le système local en tapant l'adresse de retour de boucle IP à l'invite de commande :
ftp 127.0.0.1


L'interaction avec le serveur local est identique à celle attendue avec d'autres clients Windows (et la plupart des clients UNIX). Cette commande peut également servir à déterminer si les répertoires, autorisations et autres du service du serveur FTP sont configurés correctement.

Q : Qu'est-ce qui provoque une erreur 53 quand je me connecte à un serveur Windows NT, Windows pour Workgroups, ou Microsoft LAN Manager ?

R : L'erreur 53 est renvoyée quand le nomd'ordinateur spécifié ne peut pas être résolu. Si l'ordinateur se trouve sur un sous-réseau local, confirmez que le nom est correctement épelé et que le système cible exécute également TCP/IP. Si l'ordinateur n'est pas sur le sous-réseau local, assurez-vous que son nom et le mappage de l'adresse IP sont disponibles dans le fichier LMHOSTS. Si tout semble être correctement installé, essayez d'utiliser PING avec le système distant pour vérifier que son logiciel TCP/IP est fonctionnel.

Q : Après avoir ajouté un nouveau mappage au fichier LMHOSTS, que puis-je faire si le temps de connexion au serveur est anormalement long ?

R : Un fichier LMHOSTS de taille importante avec une entrée à la fin du fichier, sans doute après quelques #INCLUDEs, peut être à l'origine de ce comportement. Vous pouvez faire deux choses pour accélérer le temps de connexion : marquer l'entrée comme entrée pré-chargée en faisant suivre le mappage de la balise #PRE et utilise la commande NBTSTAT -R pour mettre à jour immédiatement le cache de nom local, ou placer le mappage plus haut dans le fichier LMHOSTS.

le fichier LMHOSTS est analysé de façon séquentielle pour rechercher les entrées non #PRÉchargées. Par conséquent, vous devez placer les entrées fréquemment utilisées près du haut du fichier et les entrées #PRE près du bas.

Q : Que faire si des utilisateurs ont des difficultés pour se connecter à un serveur particulier, même en spécifiant le nom ?

R : Utilisez la commande NBTSTAT -N pour déterminer (de façon autoritaire) le nom que le serveur a enregistré sur le réseau. Le résultat de cette commande énumère plusieurs noms que le système a enregistré à l'aide de NetBIOS sur TCP/IP. Un nom ressemblant au nom d'ordinateur du système devrait figurer dans la liste. Si ce n'est pas le cas, essayez un des autres noms uniques affichés. La commande NBTSTAT peut également afficher les entrées cachés pour les systèmes distants soit #PREchargés à partir de LMHOSTS soit les noms récemment résolus du fait de l'activité réseau. Si le nom que les utilisateurs à distance utilisent sont les mêmes, et que les autres systèmes se trouvent sur un sous-réseau distant, assurez-vous qu'ils possèdent le mappage du système dans leur fichier LMHOSTS.

Q : Que faire quand je ne peux pas me connecter à des systèmes étrangers avec des noms d'hôte en utilisant TELNET, FTP, et autres, mais je peux me connecter uniquement avec les adresses IP ?

R : En vous servant de l'icône Réseau du Panneau de configuration, vérifiez la configuration de la résolution du nomd'hôte (sous l'option Connectivité TCP/IP) pour vous assurer que la configuration HOSTS et DNS appropriée a été configurée pour le système. Si vous utilisez le fichier HOSTS, assurez-vous que le système distant s'écrit de façon identique dans le fichier utilisé par l'application. Si vous utilisez DNS, assurez-vous que les adresses IP des serveurs DNS sont correctes et qu'elles sont dans le bon ordre. Pour déterminer si le nom d'hôte est résolu correctement, utilisez PING avec le système à distance en tapant le nom d'hôte et l'adresse IP.

Q : La bannière affichée quand j'utilise TELNET avec un ordinateur particulier identifie un ordinateur différent de celui auquel je souhaite me connecter, même si je spécifie l'adresse IP correcte. Comment cela est-il possible ?

R : Ce type de situation se produit en général quand deux systèmes sur un même réseau sont configurés (par erreur) avec la même adresse IP. Le mappage d'Ethernet et de l'adresse IP est effectué par le module ARP (address resolution protocol), lequel prend la première réponse qu'il reçoit comme la bonne. Ainsi, la réponse de l'ordinateur imposteur revient parfois avant celle de l'ordinateur prévu. Ces problèmes sont difficiles à isoler et à remonter. La commande ARP -g affiche les mappages dans le cache ARP. Si vous connaissez l'adresse Ethernet du système à distance prévu, vous pouvez facilement déterminer si les deux correspondent. Si ce n'est pas le cas, utilisez ARP D pour supprimer l'entrée, puis testez la même adresse (en forçant un nouveau mappage ARP) et vérifiez l'adresse Ethernet dans le cache en vous servant une nouvelle fois de ARP -g. Il y des chances que si les deux systèmes se trouvent sur le même réseau, vous finirez par obtenir une réponse différente. Si ce n'est pas la cas, vous devrez filtrer le trafil à partir de l'hôte imposteur pour déterminer le propriétaire du système ou son emplacement.

Q : Que faire quand une connexion TCP/IP à un système distant semble être bloquée ?

R : La commande NETSTAT -a indique le statut de toute les activités sur les ports TCP et UDP sur le système local. L'état d'une bonne connexion TCP est en général établie avec 0 octets dans les files d'envoi et de réception. Si des données sont bloquées dans une des deux files, ou si l'état est irrégulier, il y a sans doute un problème de connexion. Si ce n'est pas le cas, vous avez sans doute un retard de réseau ou d'application.

Q : Que faire quand la boîte de dialogue de configuration TCP/IP indique : "Votre passerelle par défaut n'appartient pas à une des interfaces configurées. Voulez-vous changer cela ?

R : Cette erreur indique que la passerelle par défaut n'est pas située sur le même réseau logique que les autres interfaces installées sur le système. Cela est déterminé par la comparaison entre la portion ID réseau de la passerelle par défaut (en calculant une opération AND en bits entre le masque de sous réseau et la passerelle par défaut) et l'ID/les ID réseau d'une des interfaces installées. Par exemple, un système ayant une seule interface configurée avec une adresse IP de 102.54.0.1 et un masque de sous-réseau de 255.255.0.0 impliquerait que la passerelle par défaut soit de la forme 102.54.a.b car la portion d'ID réseau de l'interface IP est 102.54.

Propriétés

Numéro d'article: 102908 - Dernière mise à jour: dimanche 26 septembre 2004 - Version: 4.1
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Windows 2000 Professionel
  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
  • Microsoft Windows NT Advanced Server 3.1
  • Microsoft Windows NT Server 4.0 Standard Edition
  • Microsoft Windows NT Workstation 3.1
  • Microsoft Windows NT Workstation 4.0 Édition Développeur
  • Microsoft Windows NT Advanced Server 3.1
Mots-clés : 
kbtshoot kbnetwork KB102908
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com