Sur cette page

Informations détaillées concernant l'implémentation de Microsoft Windows 2000 TCP/IP
Résumé
Introduction
Fonctionnalités
Présentation
Prise en charge des fonctions standard
Amélioration des performances
Services disponibles
Table de comparaison des fonctions des différentes versions de Microsoft TCP/IP
RFC Internet prises en charge par Microsoft Windows 2000 TCP/IP
Modèle d'architecture
Vue d'ensemble
Plug and Play
L'interface NDIS et les couches inférieures
NDIS (Network Driver Interface Specification) versions 3.1 à 5.0
Fonctionnalité de la couche liaison
Unité à transmission maximale (MTU)
Composants fondamentaux de la pile de protocole et interface TDI
ARP (Address Resolution Protocol)
Cache ARP
Vieillissement du cache ARP
Protocole Internet (IP)
Routage
Pour administrer le service de routage et d'accès distant
Détection des doublons d'adresses IP
Multi-hébergement
CIDR (Classless Interdomain Routing)
Multidiffusion IP
IP sur ATM
Résolution d'adresses ATM
ICMP (Internet Control Message Protocol)
Recherche du routeur ICMP
Gestion des tables d'itinéraires
Recherche de l'unité de parcours à transmission maximale (PMTU)
Utilisation d'ICMP pour diagnostiquer les problèmes
Qualité de service (QoS) et RSVP (Resource ReSerVation Protocol)
IPSec (IP Security)
IGMP (Internet Group Management Protocol)
Extensions IP/ARP pour multidiffusion IP
Extensions multidiffusion de Windows Sockets
Utilisation de IGMP par les composants de Windows
TCP (Transmission Control Protocol)
Calcul de la taille de la fenêtre de réception TCP et dimensionnement de la fenêtre (RFC 1323)
Accusés de réception (ACK) retardés
Accusé de réception TCP sélectif (RFC 2018)
Cachets TCP (RFC 1323)
Découverte du chemin MTU.
Détection de passerelle inactive
Comportement TCP de retransmission
Messages de maintien d'activité TCP
Algorithme de démarrage lent et contournement d'encombrement
Services client essentiels et composants de pile
Configuration automatique du client et détection du support
Client DNS de mise à jour dynamique
Service cache de résolution DNS
Outils et stratégies de dépannage TCP/IP
Outil IPConfig
Outil ping
Outil PathPing
Outil Arp
Outil Tracert
Outil Route
Netstat
Outil NBTStat
Outil Nslookup
Moniteur réseau Microsoft
MinimumFreeLowerConnections
Paramètres configurables à partir de l'interface utilisateur Connexions
Paramètres non configurables
Annexe C : paramètres de registre Windows Sockets et DNS
Paramètres de registre AFD
Paramètres d'enregistrement DNS dynamique
Paramètres de registre du service de résolution de cache DNS
Paramètres de résolution des noms
Annexe D : optimisation de la réponse TCP/IP à une attaque
Paramètres de sécurité TCP/IP

Informations détaillées concernant l'implémentation de Microsoft Windows 2000 TCP/IP

Par Dave MacDonald et Warren Barkley

Résumé

Ce livre blanc décrit en détail l'implémentation du protocole TCP/IP du système d'exploitation Microsoft® Windows® 2000 et constitue un complément des manuels de Microsoft Windows 2000 TCP/IP. Le protocole Microsoft TCP/IP est examiné de façon ascendante. Tout au long du livre, les traces réseau permettent d'illustrer les concepts clés. Ces traces ont été recueillies et formatées à l'aide du Moniteur réseau Microsoft, un outil logiciel d'analyse et de suivi du protocole réseau, inclus dans le produit Microsoft Systems Management Server. Ce livre s'adresse aux ingénieurs réseau et aux professionnels du support technique qui sont déjà familiarisés avec le protocole TCP/IP.

Introduction

Microsoft a adopté le protocole TCP/IP comme protocole de transport réseau stratégique d'entreprise pour ses plates-formes. Au début des années 90, Microsoft a lancé un projet ambitieux qui visait à créer des services et une pile TCP/IP, destinés à améliorer considérablement la flexibilité de la gestion réseau Microsoft. Avec la sortie du système d'exploitation Microsoft® Windows NT® 3.5, Microsoft a introduit une pile TCP/IP totalement réécrite. Cette nouvelle pile a été conçue pour intégrer les nombreux progrès réalisés au niveau des performances et de la simplicité d'administration obtenus au cours des dix dernières années. La pile est l'implémentation 32 bits portable hautes performances du protocole standard TCP/IP. Elle a évolué avec chaque version de Windows NT afin d'intégrer de nouvelles fonctionnalités et de nouveaux services qui améliorent ses performances et sa fiabilité.

Les objectifs poursuivis lors du développement de la pile TCP/IP étaient les suivants :

• conformité aux normes ;

• interopérabilité ;

• portabilité ;

• évolutivité ;

• performances élevées ;

• polyvalence ;

• mise au point automatique ;

• simplicité d'administration ;

• simplicité d'adaptation ;

Ce livre décrit en détail l'implémentation de Windows 2000 et constitue un complément aux manuels TCP/IP de Microsoft Windows 2000. Il décrit l'implémentation de Microsoft TCP/IP de manière ascendante et est destiné aux ingénieurs réseau et aux professionnels du support technique qui sont déjà familiarisés avec TCP/IP.

Ce livre utilise des traces réseau afin d'illustrer les concepts. Ces analyses ont été recueillies et mises en forme à l'aide du Moniteur réseau Microsoft version 2.0, un outil logiciel d'analyse et de suivi de protocole inclus dans le produit Microsoft Systems Management Server. Windows 2000 Server inclut une version du Moniteur réseau sans certaines des fonctionnalités. La différence fondamentale entre cette version et celle de Systems Management Server est que la version limitée peut uniquement capturer les trames qui sont normalement vues par l'ordinateur sur lequel elle est installée, et non toutes les trames qui passent sur le réseau (ce qui nécessite que l'adaptateur soit configuré en mode de proximité). Il ne prend pas non plus en charge la connexion à des agents distants du Moniteur réseau.

Fonctionnalités

Présentation

La suite TCP/IP pour Windows 2000 a été conçue afin de simplifier l'intégration des systèmes Microsoft au sein de réseaux d'entreprise, gouvernementaux et publics à grande échelle et de permettre l'exploitation en toute sécurité de ces réseaux. Windows 2000 est un système d'exploitation prêt pour Internet.

Prise en charge des fonctions standard

Windows 2000 prend en charge les fonctions standard suivantes :

• possibilité de se connecter à de multiples cartes réseau avec différents types de supports ;

• multi-hébergement physique et logique ;

• fonction interne de routage IP ;

• IGMP (Internet Group Management Protocol) version 2 (Multidiffusion IP) ;

• détection des doublons d'adresse IP ;

• passerelles par défaut multiples ;

• détection de passerelle inactive ;

• recherche automatique de l'unité de parcours à transmission maximale (PMTU  : Path Maximum Transmission Unit) ;

• sécurité IP (IPSec) ;

• qualité de service (QoS) ;

• services ATM ;

• réseaux privés virtuels (VPN) ;

• protocole de tunneling de couche 2 (L2TP).

Amélioration des performances

Windows 2000 présente en outre les améliorations suivantes en termes de performances :

• mise au point de la pile du protocole, comprenant l'agrandissement de la taille par défaut des fenêtres et de nouveaux algorithmes de traitement des liaisons à délai élevé, ce qui augmente le débit

• fenêtres pouvant être dimensionnées par l'intermédiaire de TCP (pris en charge par la RFC 1323)

• accusés de réception sélectifs (SACK)

• renvoi rapide TCP

• amélioration du calcul du temps de transmission aller-retour (RTT, Round Trip Time) et du délai d'attente de retransmission (RTO, Retransmission Timeout)

• amélioration des performances pour la gestion d'un grand nombre de connexions

• mécanismes matériels de déchargement des tâches

Services disponibles

La gamme des systèmes d'exploitation Windows 2000 Server assure les services suivants :

• client et service DHCP (Dynamic Host Configuration Protocol) ;

• WINS (Windows Internet Name Service), un client et serveur de nom NetBIOS ;

• DNS dynamique (DDNS) ;

• prise en charge de l'accès à distance (PPP/SLIP) ;

• protocole de tunneling point-à-point (PPTP) et protocole de tunneling de couche 2 (L2TP), utilisé pour les réseaux privés virtuels distants ;

• impression réseau TCP/IP (lpr/lpd) ;

• agent SNMP ;

• interface NetBIOS ;

• interface Windows Sockets version 2 (Winsock2) ;

• prise en charge des appels de procédure à distance (RPC, Remote Procedure Call) ;

• Network Dynamic Data Exchange (NetDDE) ;

• prise en charge de la navigation sur réseau étendu (WAN) ;

• Services Microsoft IIS (Internet Information Services) hautes performances ;

• utilitaires de connexion TCP/IP essentielles, comportant : finger, ftp, rcp, rexec, rsh, telnet, et tftp ;

• logiciel serveur pour protocoles réseau simples, comportant : Générateur de caractères, Heure du jour, Ignorer, Écho et Citation du jour ;

• Outils de diagnostic et de gestion TCP/IP, comportant : arp, ipconfig, nbtstat, netstat, ping, pathping, route, nslookup et tracert ;

Table de comparaison des fonctions des différentes versions de Microsoft TCP/IP

Le tableau ci-dessous, qui sert de référence, dresse la liste des fonctions ainsi que des versions des systèmes d'exploitation dans lesquelles elles sont présentes. Les fonctions sont décrites plus en détail tout au long de ce document.

Tableau 1 : N=Non, O=Oui et D=Désactivé par défaut

RFC Internet prises en charge par Microsoft Windows 2000 TCP/IP

Les requêtes de commentaires (RFC, Requests for Comments) sont constituées d'une série en évolution constante de rapports, de propositions et de normes de protocole, utilisés par la communauté de l'Internet. Il est possible d'utiliser FTP pour obtenir les RFC à partir des sites suivants :

• nis.nsf.net ;

• nisc.jvnc.net ;

• wuarchive.wustl.edu ;

• src.doc.ic.ac.uk ;

• normos.org.

Tableau 2 : les RFC prises en charge par cette version de Microsoft TCP/IP

Modèle d'architecture

Vue d'ensemble

La suite Microsoft TCP/IP contient des éléments de protocole fondamentaux, des services et leurs interfaces. Les interfaces TDI (Transport Driver Interface) et NDIS (Network Device Interface Specification) sont publiques et leurs spécifications sont mises à disposition par Microsoft sur le site 1 Microsoft France. Il existe en outre un certain nombre d'interfaces de niveau supérieur disponibles pour les applications en mode utilisateur. Les plus communément utilisées sont Windows Sockets, les appels de procédure à distance (RPC) et NetBIOS.

Figure 1 : le modèle de réseau TCP/IP Windows 2000

Plug and Play

Windows 2000 introduit la prise en charge de Plug and Play, qui présente les fonctionnalités suivantes :

• Reconnaissance automatique et dynamique du matériel installé. Ceci inclut l'installation initiale du système, la reconnaissance des changements statiques de matériel qui peuvent avoir lieu entre deux amorçages et la réponse aux événements matériels en cours d'exécution, tels que l'installation ou l'extraction et l'insertion ou la suppression de cartes.

• Configuration efficace du matériel en réponse à sa reconnaissance automatique et dynamique, comportant l'activation dynamique du matériel, l'arbitrage des ressources, le chargement des pilotes de périphérique, le montage des unités, etc.

• Prise en charge de types de bus particuliers et d'autres normes matérielles qui facilitent la reconnaissance dynamique et automatique du matériel, ainsi qu'une configuration efficace du matériel, notamment Plug and Play ISA, PCI, PCMCIA, PC Card/CardBus, USB et 1394. Ceci comprend également la promulgation de normes et de recommandations sur le comportement du matériel.

• Une structure Plug and Play ordonnée permettant le fonctionnement de programmes d'écriture de pilotes. Il s'agit d'une infrastructure comportant des éléments tels que les interfaces d'informations (INF) sur l'unité, les API, les notifications en mode noyau, les interfaces d'exécution, etc.

• Des mécanismes qui permettent au code et aux applications en mode utilisateur de prendre connaissance des changements d'environnement matériel afin de prendre les mesures appropriées.

Le fonctionnement Plug and Play ne requiert pas nécessairement un matériel Plug and Play. Dans la mesure du possible, les deux premiers points ci-dessus s'appliquent au matériel d'origine ainsi qu'au matériel Plug and Play. Dans certains cas, l'énumération ordonnée des périphériques d'origine n'est pas possible en raison des méthodes de détection qui sont destructives ou qui nécessitent du temps.

L'impact principal de la prise en charge Plug and Play sur les piles du protocole est que les interfaces réseau sont susceptibles d'être extraites et introduites à tout moment. La pile TCP/IP de Windows 2000 et les composants associés ont été adaptés pour permettre la prise en charge Plug and Play.

L'interface NDIS et les couches inférieures

Les protocoles de gestion réseau Microsoft utilisent la spécification NDIS (Network Device Interface Specification) pour communiquer avec les pilotes de carte réseau. La plupart des fonctions de la couche de liaison du modèle OSI sont implémentées dans la pile du protocole. De cette manière, le développement des pilotes de carte réseau est grandement simplifié.

NDIS (Network Driver Interface Specification) versions 3.1 à 5.0

NDIS 3.1 prend en charge les services fondamentaux qui permettent à un module de protocole d'envoyer des paquets bruts sur un périphérique réseau et d'être également averti des paquets entrants reçus par un périphérique réseau.

NDIS 4.0 présente les fonctions supplémentaires suivantes par rapport à NDIS 3.1 :

• Prise en charge des données hors-bande (requis pour Broadcast PC).

• Extension de support pour réseau étendu sans fil.

• Envoi et réception de paquets à haute vitesse (une amélioration significative des performances).

• Extension de support IrDa rapide.

• détection du support (nécessaire pour l'obtention du logo Conçu pour Windows dans le Guide de conception du matériel PC versions 97 et ultérieures). La pile TCP/IP de Microsoft Windows 2000 utilise les informations de détection de support ; ces informations sont décrites dans la section "Configuration automatique du client" de ce livre blanc.

• Tous les filtres de paquets locaux (empêchent le Moniteur réseau de monopoliser le processeur)

• De nombreuses nouvelles fonctions du système NDIS (nécessaires à la compatibilité binaire de miniports dans Windows 95, Windows 98, Windows NT et Windows 2000)

NDIS 5.0 comporte toutes les fonctions définies dans NDIS 4.0 ainsi que les extensions suivantes :

• Gestion NDIS de l'alimentation (requise pour la gestion de l'alimentation réseau et la fonction d'éveil réseau)

• Plug and Play (NDIS pour Windows 95 prenait déjà en charge la fonction Plug and Play ; ce changement s'applique par conséquent uniquement aux pilotes de réseau Windows 2000.)

• Prise en charge de WMI (Windows Management Instrumentation), permettant l'instrumentation compatible WBEM (Web-based Enterprise Management) des miniports NDIS et des cartes correspondantes.

• Prise en charge d'un format INF unique pour tous les systèmes d'exploitation Windows. Le nouveau format INF est basé sur le format INF de Windows 98.

• Miniport désérialisé pour améliorer les performances.

• Mécanismes de déchargement de tâches, tels que le total de contrôle UDP et TCP et la transmission rapide de paquets (Fast Packet Forwarding).

• Extension du support de diffusion (requis par les services de diffusion pour Windows).

• NDIS orienté connexion (requis pour la prise en charge du mode de transfert asynchrone [ATM], d'ADSL [Asymmetric Digital Subscriber Line] et de WDM-CSA [Windows Driver Model–connexion Streaming Architecture].

• Prise en charge de QoS (Quality of Service).

• Prise en charge de pilote intermédiaire (requise pour Broadcast PC, les réseaux locaux virtuels, la planification de paquets pour QoS et la prise en charge NDIS des périphériques réseau IEEE 1394).

NDIS peut couper l'alimentation des cartes réseau lorsque le système demande un changement de niveau de l'alimentation. Tant l'utilisateur que le système peuvent émettre cette requête. L'utilisateur peut par exemple mettre l'ordinateur en mode veille ou le système peut demander un changement de niveau d'alimentation en raison de l'inactivité de la souris ou du clavier. En outre, la déconnexion du câble réseau peut initier une demande de mise hors tension si la carte d'interface réseau (NIC) permet la prise en charge de cette fonction. Dans ce cas, le système attendra pendant un intervalle de temps à déterminer avant de mettre la carte réseau hors tension, étant donné que la déconnexion peut être due à des changements de câblage temporaires sur le réseau plutôt qu'à la déconnexion d'un câble du périphérique réseau lui-même.

La stratégie de gestion de l'alimentation NDIS est basée sur l'absence d'activité réseau. Cela signifie que tous les autres composants réseau doivent être d'accord avec la requête pour que la carte réseau puisse être mise hors tension. Dans le cas de sessions actives quelconques ou de fichiers ouverts sur le réseau, la demande de mise hors tension peut être refusée par l'ensemble ou par un seul des composants impliqués.

L'ordinateur peut également sortir d'un état de faible alimentation, en fonction d'événements qui se produisent sur le réseau. Un signal de réveil peut être provoqué par :

• la détection d'un changement de l'état de la liaison réseau (par exemple, la reconnexion d'un câble) ;

• la réception d'une trame de réveil réseau ;

• la réception d'un paquet magique (Magic Packet). Pour en savoir plus, consultez le site Microsoft.

Lors de l'initialisation du pilote, NDIS interroge la capacité du miniport à déterminer s'il prend en charge des éléments tels que les paquets magiques, la correspondance au modèle ou les réveils pour changement de liaison, ainsi qu'à déterminer la condition d'alimentation minimale requise par chaque méthode de réveil. Les protocoles réseau demandent ensuite les capacités du miniport. Au moment de l'exécution, le protocole établit la stratégie de réveil, à l'aide d'identificateurs d'objets (OID), tels que Enable Wakeup (Autoriser réveil), Set Packet Pattern (Définir modèle de paquet) et Remove Packet Pattern (Supprimer modèle de paquet).

Actuellement, Microsoft TCP/IP est la seule pile de protocole Microsoft qui permette la gestion d'alimentation réseau. À l'initialisation du miniport, la pile enregistre les modèles de paquets suivants :

• paquet IP dirigé ;

• diffusion ARP pour l'adresse IP de la station ;

• diffusion NetBIOS à l'aide de TCP/IP pour le nom d'ordinateur attribué à la station.

Des pilotes compatibles NDIS sont disponibles pour un large choix de cartes réseau de nombreux fabricants. L'interface NDIS permet la liaison entre plusieurs protocoles de différents types et un pilote réseau unique ; elle permet également la liaison entre un protocole unique et plusieurs pilotes réseau. La spécification NDIS décrit le mécanisme de multiplexage utilisé pour exécuter cette fonction. Les liaisons peuvent être visualisées ou modifiées à partir du dossier Windows Network connexions.

Windows 2000 TCP/IP permet la prise en charge de :

• Ethernet (et 802.3 SNAP)

• FDDI

• Token Ring (802.5)

• ATM (LANE et CLIP)

• ARCnet

• Liaisons dédiées de réseau étendu (WAN), telles que DDS (Dataphone Digital Service) et T-carrier (Fractional T1, T2 et T3)

• Services de réseau étendu commuté permanent ou à distance, tels que les téléphones analogiques, les réseaux RNIS et xDSL

• Services de réseau étendu à commutation de paquets, tels que X.25, Frame Relay et ATM

Les objectifs de ces nouvelles fonctionnalités sont les suivants :

• faciliter l'utilisation et réduire le coût total de propriété (TCO) ;

• améliorer les performances ;

• autoriser de nouveaux types de supports, de services et d'applications ;

• augmenter la souplesse de l'architecture des pilotes.

Fonctionnalité de la couche liaison

La fonctionnalité de la couche liaison est répartie entre la combinaison pilote/carte d'interface réseau et le pilote de pile de protocole de bas niveau. Les filtres de la combinaison pilote/carte réseau sont basés sur l'adresse du contrôle d'accès du support de destination (MAC) de chaque trame.

Normalement, le matériel filtre toutes les trames entrantes, à l'exception de celles contenant une des adresses de destination suivantes :

• l'adresse de la carte ;

• l'adresse de diffusion constituée uniquement de 1 (FF-FF-FF-FF-FF-FF) ;

• les adresses de multidiffusion qui intéressent un pilote de protocole sur l'hôte, à l'aide d'une primitive NDIS.

Cette première décision de filtrage étant effectuée par le matériel, la carte réseau ignore toutes les trames qui ne répondent pas aux critères de filtrage sans nécessiter de traitement par le processeur. Toutes les trames (y compris les diffusions) qui passent le filtre matériel sont ensuite passées au pilote de la carte réseau par le biais d'une interruption matérielle.2Le pilote réseau est un logiciel qui s'exécute sur l'ordinateur ; par conséquent, toutes les trames qui arrivent jusque là nécessitent un certain temps processeur pour être traitées. Le pilote réseau fait passer la trame de la carte d'interface à la mémoire du système, puis la carte est passée au(x) pilote(s) de transport approprié(s). La spécification NDIS 5.0 offre plus de détails à propos de ce processus.

Les trames sont passées à tous les pilotes de transport liés dans l'ordre des liaisons.

Lors du passage d'un paquet à travers le réseau ou une série de réseaux, l'adresse du contrôle d'accès du support (MAC) source correspond toujours à celle de la carte réseau qui a placé le paquet sur le support, tandis que l'adresse MAC du support de destination correspond à celle de la carte réseau qui devra l'extraire du support. En d'autres termes, dans un réseau à routage, les adresses MAC des supports source et de destination changent à chaque passage par un périphérique de couche réseau (routeur ou commutateur de couche 3).

Unité à transmission maximale (MTU)

Chaque type de support présente une taille de trame maximale qui ne peut être dépassée. La couche liaison est responsable de la recherche de cette unité MTU et de son signalement aux protocoles susmentionnés. La pile de protocole peut interroger les pilotes NDOS pour connaître l'unité MTU locale. La connaissance de l'unité MTU d'une interface est utilisée par les protocoles des couches supérieures, tels que TCP, qui optimisent automatiquement la taille des paquets destinés à chaque support. Pour en savoir plus, consultez l'exposé sur la recherche de l'unité de parcours à transmission maximale TCP (PMTU) dans la section "TCP (Transmission Control Protocol)" de ce livre.

Si un pilote réseau (tel qu'un pilote ATM) utilise un mode d'émulation LAN, il peut signaler qu'il possède une MTU supérieure à celle prévue pour ce type de support. Par exemple, il peut émuler Ethernet, mais indiquer une MTU de 9180 octets. Windows NT et Windows 2000 acceptent et utilisent la taille MTU indiquée par la carte, même si elle dépasse la MTU normale pour un type de support donné.

Parfois, la MTU signalée à la pile de protocole peut être inférieure à ce qu'on pourrait prévoir pour un type de support donné. Par exemple, l'utilisation de la norme 802.1p pour QoS sur Ethernet réduit souvent (cela dépend du matériel) de 4 octets la MTU signalée, en raison de la présence d'en-têtes de couche de liaison plus larges.

Composants fondamentaux de la pile de protocole et interface TDI

Les composants fondamentaux de la pile de protocole sont ceux indiqués entre les interfaces TDI et NDIS à la figure 1. Ils sont implémentés dans le pilote Tcpip.sys de Windows 2000. Il est possible d'accéder à la pile Microsoft à travers les interfaces TDI et NDIS. L'interface Winsock2 permet également de pouvoir accéder directement à la pile de protocole.

ARP (Address Resolution Protocol)

Le protocole ARP effectue la résolution de l'adresse IP vers l'adresse MAC pour tous les paquets sortants. Étant donné que chaque datagramme IP sortant est encapsulé dans une trame, les adresses MAC source et de destination doivent être ajoutées. La détermination de l'adresse MAC de destination pour chaque trame est exécutée par le protocole ARP.

ARP compare l'adresse IP de destination de tous les datagrammes IP sortants au cache ARP de la carte réseau par laquelle la trame sera transmise. En présence d'une entrée correspondante, l'adresse MAC est extraite du cache. Dans le cas contraire, ARP diffuse un paquet de requête ARP sur le sous-réseau local afin de demander au propriétaire de l'adresse IP en question de répondre avec son adresse MAC. Si le paquet passe à travers un routeur, ARP procède à la résolution de l'adresse MAC pour le routeur du tronçon suivant plutôt que pour l'hôte de destination finale. Lors de la réception d'une réponse ARP, le cache ARP est mis à jour sur la base de la nouvelle information qui est utilisée pour adresser le paquet à la couche de liaison.

Cache ARP

Vous pouvez utiliser l'utilitaire ARP pour visualiser, ajouter ou supprimer des entrées dans le cache ARP. Des exemples sont présentés ci-dessous. Les entrées ajoutées manuellement sont statiques et ne sont pas automatiquement supprimées du cache, à l'inverse des entrées dynamiques (consultez la section "Vieillissement du cache ARP" pour en savoir plus).

La commande arp peut être utilisée pour visualiser le cache ARP, de la manière indiquée ci-dessous :

C:\>arp –a
    Interface: 199.199.40.123
     Internet Address Physical Address Type
     199.199.40.1 00-00-0c-1a-eb-c5 dynamic
     199.199.40.124 00-dd-01-07-57-15 dynamic
    Interface: 10.57.8.190
     Internet Address Physical Address Type
     10.57.9.138 00-20-af-1d-2b-91 dynamic

L'ordinateur de cet exemple est multi-hébergement (il a plus d'une carte réseau) ; c'est la raison pour laquelle il y a un cache ARP distinct pour chaque interface.

Dans l'exemple suivant, la commande arp –s est utilisée pour ajouter une entrée statique au cache ARP utilisé par la deuxième interface pour l'hôte dont l'adresse IP est 10.57.10.32 et dont l'adresse réseau est 00608C0E6C6A :

C:\>arp -s 10.57.10.32 00-60-8c-0e-6c-6a
    10.57.8.190
    C:\>arp -a
    Interface: 199.199.40.123
     Internet Address Physical Address Type
     199.199.40.1 00-00-0c-1a-eb-c5 dynamic
     199.199.40.124 00-dd-01-07-57-15 dynamic
    Interface: 10.57.8.190
     Internet Address Physical Address Type
     10.57.9.138 00-20-af-1d-2b-91 dynamic
     10.57.10.32 00-60-8c-0e-6c-6a static

Vieillissement du cache ARP

Windows NT et Windows 2000 règlent automatiquement la taille du cache ARP afin de répondre aux besoins du système. Si une entrée n'est utilisée par aucun datagramme sortant pendant deux minutes, l'entrée est supprimée du cache ARP. Les entrées qui sont actuellement en cours de consultation sont supprimées du cache ARP après dix minutes. Les entrées ajoutées manuellement ne sont pas supprimées automatiquement du cache. Un nouveau paramètre de registre, ArpCacheLife, a été ajouté dans Windows NT 3.51 Service Pack 4 afin de permettre davantage de contrôle administratif sur le vieillissement. Ce paramètre est décrit à l'annexe A.

Utilisez la commande arp –d pour supprimer des entrées du cache, de la manière décrite ci-dessous :

C:\>arp -d 10.57.10.32
    C:\>arp -a
    Interface: 199.199.40.123
     Internet Address Physical Address Type
     199.199.40.1 00-00-0c-1a-eb-c5 dynamic
     199.199.40.124 00-dd-01-07-57-15 dynamic
    Interface: 10.57.8.190
     Internet Address Physical Address Type
     10.57.9.138 00-20-af-1d-2b-91 dynamic
ARP met en file d'attente un seul datagramme IP sortant
    pour une adresse de destination spécifiée, tandis que
    l'adresse IP est résolue en une adresse MAC. Si une
    application basée sur le protocole UDP (User Datagram
    Protocol) envoie des datagrammes IP multiples vers une
    adresse de destination unique sans aucun intervalle entre eux,
    certains des datagrammes peuvent être perdus si aucune
    entrée de cache ARP n'est déjà présente.
    Une application peut compenser cette situation en faisant appel
    à la routine iphlpapi.dll SendArp() pour
    établir une entrée de cache ARP avant d'envoyer le
    flux de paquets.

Protocole Internet (IP)

IP est la chambre de réception de la pile TCP/IP, où se font le tri et la livraison des paquets. Au niveau de cette couche, chaque paquet entrant ou sortant est appelé un datagramme. Chaque datagramme IP porte l'adresse IP source de l'expéditeur et l'adresse IP de destination du destinataire choisi. Contrairement aux adresses MAC, les adresses IP d'un datagramme restent identiques tout au long du séjour du paquet à travers un réseau d'interconnexion. Les fonctions de la couche IP sont décrites ci-dessous.

Routage

Le routage est une fonction fondamentale de IP. Les datagrammes sont envoyés vers IP à partir de UDP et TCP au-dessus, de la ou des cartes réseau ci-dessous. Chaque datagramme est étiqueté avec une adresse IP source et de destination. IP examine l'adresse de destination de chaque datagramme, la compare à une table de routage locale et décide de l'action à prendre. Il existe trois possibilités pour chaque datagramme :

• Il peut être passé à une couche de protocole au-dessus de IP sur l'hôte local.

• Il peut être transféré à l'aide de l'une des cartes réseau connectées localement.

• Il peut être supprimé.

La table de routage conserve quatre types d'itinéraires différents. Ils sont répertoriés ci-dessous dans l'ordre de consultation appliqué lors de la recherche de correspondance :

1. hôte (un itinéraire vers une adresse IP de destination unique et spécifique) ;

2. sous-réseau (un itinéraire vers un sous-réseau) ;

3. réseau (un itinéraire vers un réseau complet) ;

4. par défaut (utilisé en l'absence de correspondance) ;

Pour déterminer un itinéraire unique à utiliser pour transférer un datagramme IP, le protocole IP utilise la procédure suivante :

1. Pour chaque itinéraire présent dans la table de routage, le protocole IP exécute un ET logique au niveau du bit entre l'adresse IP de destination et le masque de réseau. Il compare le résultat avec la destination réseau afin d'essayer de trouver une correspondance. S'ils correspondent, le protocole IP marque l'itinéraire de manière à indiquer qu'il correspond à l'adresse IP de destination.

2. Dans la liste des itinéraires correspondants, le protocole IP détermine l'itinéraire qui possède le plus de bits dans le masque de réseau. Il s'agit de l'itinéraire avec le plus grand nombre de bits correspondant à l'adresse IP de destination ; il constitue par conséquent l'itinéraire le plus spécifique pour le datagramme IP. Cette procédure est connue comme la procédure de recherche de l'itinéraire le plus court ou le plus long.

3. Si plusieurs itinéraires les plus courts sont trouvés, le protocole IP utilise celui correspondant à la métrique la plus faible. Si plusieurs itinéraires les plus courts avec les métriques les plus faibles sont trouvés, le protocole IP peut choisir d'utiliser un quelconque des itinéraires trouvés.

Grâce à la commande route print, vous pouvez visualiser la table de routage à partir de l'invite de commande, tel que décrit ci-dessous :

C:\>route print
    =========================================================================

     Interface List
    0x1 ........................... MS TCP Loopback interface
    0x2 ...00 a0 24 e9 cf 45 ...... 3Com 3C90x Ethernet
    Adapter
    0x3 ...00 53 45 00 00 00 ...... NDISWAN Miniport
    0x4 ...00 53 45 00 00 00 ...... NDISWAN Miniport
    0x5 ...00 53 45 00 00 00 ...... NDISWAN Miniport
    0x6 ...00 53 45 00 00 00 ...... NDISWAN Miniport

    Active Routes:
    Network Destination Netmask Gateway Interface Metric
    0.0.0.0 0.0.0.0 10.99.99.254 10.99.99.1 1
    10.99.99.0 255.255.255.0 10.99.99.1 10.99.99.1 1
    10.99.99.1 255.255.255.255 127.0.0.1 127.0.0.1 1
    10.255.255.255 255.255.255.255 10.99.99.1 10.99.99.1 1
    127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
    224.0.0.0 224.0.0.0 10.99.99.1 10.99.99.1 1
    255.255.255.255 255.255.255.255 10.99.99.1 10.99.99.1 1
    Default Gateway: 10.99.99.254

La table de routage illustrée ci-dessus concerne un ordinateur ayant l'adresse IP classe A 10.99.99.1, le masque de sous-réseau 255.255.255.0 et la passerelle par défaut 10.99.99.254. Elle contient les huit entrées suivantes :

• La première entrée, à l'adresse 0.0.0.0, représente l'itinéraire par défaut.

• La deuxième entrée représente le masque de sous-réseau 10.99.99.0, sur lequel se trouve l'ordinateur.

• La troisième entrée, à l'adresse 10.99.99.1, est un itinéraire hôte pour l'hôte local. Elle détermine l'adresse de bouclage, ce qui a un sens, car un datagramme lié à l'hôte local doit être bouclé en interne.

• La quatrième entrée représente l'adresse de diffusion du réseau.

• La cinquième entrée représente l'adresse de bouclage, 127.0.0.0.

• La sixième entrée sert à la multidiffusion IP qui sera traitée plus loin dans ce document.

• La dernière entrée représente l'adresse de diffusion limite (comportant uniquement des 1).

La Passerelle par défaut représente la passerelle par défaut actuellement active. Il est utile de savoir si plusieurs passerelles par défaut sont configurées.

Sur cet hôte, lorsqu'un paquet est envoyé à l'adresse 10.99.99.40, l'itinéraire le plus proche correspond à l'itinéraire local de sous-réseau (10.99.99.0 avec le masque 255.255.255.0). Le paquet est envoyé par le biais de l'interface locale 10.99.99.1. Si un paquet est envoyé à l'adresse 10.200.1.1, l'itinéraire le plus proche correspond à l'itinéraire par défaut. Dans ce cas, le paquet est transmis à la passerelle par défaut.

Dans la plupart des cas, la table de routage est gérée automatiquement. Lors de l'initialisation d'un hôte, des entrées relatives aux réseaux locaux, au bouclage, à la multidiffusion et à la passerelle configurée par défaut sont ajoutées. Davantage d'itinéraires peuvent apparaître dans la table au fur et à mesure que la couche IP en apprend l'existence. Par exemple, la passerelle par défaut peut informer l'hôte de l'existence d'un meilleur itinéraire vers un réseau, un sous-réseau ou un hôte spécifique avec le protocole ICMP (expliqué plus loin dans ce livre blanc). Il est également possible d'ajouter des itinéraires manuellement à l'aide de la commande route ou avec un protocole de routage. Pour indiquer les itinéraires permanents, utilisez l'option -p (permanent) de la commande route. Les itinéraires permanents sont stockés dans le registre sous la clé de registre

HKEY_LOCAL_MACHINE
     \SYSTEM
     \CurrentControlSet
     \Services
     \Tcpip
     \Parameters
     \PersistentRoutes
	 

Windows 2000 TCP/IP introduit une nouvelle option de configuration métrique pour les passerelles par défaut. Grâce à cette métrique, vous pouvez mieux contrôler, à tout instant, quelle est la passerelle par défaut actuellement active. La valeur par défaut de la métrique est 1 ; un itinéraire avec une valeur inférieure est préféré aux autres. Dans le cas des passerelles par défaut, l'ordinateur optera pour celle dont la valeur de la métrique est la plus faible, à moins qu'elle soit inactive ; dans ce cas, le mécanisme de détection d'inactivité des passerelles peut déclencher le basculement vers la passerelle par défaut suivante dans la liste (avec la métrique la plus faible). Les métriques des passerelles par défaut peuvent être définies dans la boîte de dialogue Propriétés TCP/IP avancés. Les serveurs DHCP fournissent une métrique de base et une liste de passerelles par défaut. Si un serveur DHCP fournit une valeur de base égale à 100 et une liste de trois passerelles par défaut, les passerelles seront respectivement configurées avec les métriques 100, 101 et 102. Une valeur de base fournie par un serveur DHCP ne s'applique pas aux passerelles par défaut configurées de manière statique.

La plupart des routeurs de systèmes autonomes (AS) se servent d'un protocole tel que RIP (Routing Information Protocol) ou OSPF (Open Shortest Path First) pour échanger les tables de routage. Ces protocoles sont pris en charge par Windows 2000 Server. Windows 2000 Professionnel inclut la prise en charge de RIP silencieux.

Par conséquent, les systèmes Windows n'agissent pas en tant que routeurs et ne transmettent pas les datagrammes IP entre interfaces. Toutefois, Windows 2000 Server inclut les services de routage et d'accès distant. Celui-ci peut être activé et configuré pour fournir tous les services de routage multi-protocole.

Pour administrer le service de routage et d'accès distant

1. Dans le menu Démarrer, pointez sur Programmes.

2. Pointez sur Outils d'administration, puis cliquez sur Routage et accès distant.

Lors de l'exécution de plusieurs sous-réseaux logiques sur le même réseau physique, utilisez la commande suivante pour ordonner au protocole IP de traiter tous les sous-réseaux en local et d'utiliser directement ARP pour la destination :

route add 0.0.0.0 MASK 0.0.0.0 <my local ip
    address>

Ainsi, les paquets destinés aux sous-réseaux non locaux sont directement transmis sur le média local au lieu d'être envoyés à un routeur. Par essence, la carte d'interface locale peut être désignée comme passerelle par défaut. Ceci peut être utile dans le cas où plusieurs réseaux de classe C sont exploités sur un seul réseau physique en absence de routeur vers le monde extérieur ou dans un environnement proxy-ARP.

Détection des doublons d'adresses IP

La détection des doublons d'adresse IP est une fonctionnalité importante. À la première initialisation de la pile ou lors de l'ajout d'une nouvelle adresse IP, des requêtes ARP gratuites sont diffusées aux adresses IP de l'hôte local. Le nombre d'ARP à envoyer est commandé par le paramètre de registre ArpRetryCount, qui est de 3 par défaut. Si un autre hôte répond à une quelconque de ces ARP, cela signifie que l'adresse IP est déjà utilisée. Dans ce cas, l'ordinateur Windows démarre encore, mais l'interface qui contient l'adresse fautive est désactivée, une entrée est générée dans le journal système et un message d'erreur s'affiche. Si l'hôte qui a émis l'adresse fautive est également un ordinateur Windows, une entrée est également générée dans le journal système et un message d'erreur s'affiche sur cet ordinateur. Pour réparer les éventuels dommages occasionnés sur les caches ARP des autres ordinateurs, l'ordinateur fautif rediffuse une autre ARP et rétablit les valeurs d'origine des caches ARP des autres ordinateurs.

Un ordinateur qui utilise un doublon d'adresse IP peut démarrer s'il n'est pas connecté au réseau, auquel cas aucun conflit n'est détecté. En revanche, s'il est ensuite connecté au réseau, la première fois qu'il envoie une requête ARP pour obtenir une autre adresse IP, tous les ordinateurs Windows NT présentant un conflit d'adresses détecteront ce conflit. L'ordinateur qui détecte le conflit affiche un message d'erreur et enregistre un événement détaillé dans le journal système. Un exemple d'entrée dans le journal des événements est illustré ci-après.

Le système a détecté un conflit sur l'adresse IP 199.199.40.123 avec le système ayant l'adresse réseau matérielle 00:DD:01:0F:7A:B5. Par conséquent, les opérations réseau sur ce système peuvent être perturbées.

Les clients sur lesquels DHCP est activé informent le serveur DHCP qu'un conflit d'adresse IP a été détecté et, au lieu d'invalider la pile, ils demandent au serveur DHCP de signaler l'adresse conflictuelle et de leur en donner une nouvelle. Cette fonctionnalité est couramment appelée traitement des refus DHCP.

Multi-hébergement

Quand un ordinateur est configuré avec plusieurs adresses IP, on l'appelle système multi-hôtes. Le multi-hébergement est pris en charge de trois manières différentes :

• Plusieurs adresses IP par carte réseau

  • Pour ajouter des adresses pour une carte réseau, dans le menu Démarrer, pointez sur Paramètres, puis cliquez sur Connexions réseau et accès à distance. Cliquez avec le bouton droit de la souris sur Connexion au réseau local, puis cliquez sur Propriétés. Sélectionnez Protocole Internet (TCP/IP), cliquez sur Propriétés, puis sur Avancé. Dans la boîte de dialogue Paramètres TCP/IP avancés, cliquez sur Ajouter sous l'onglet Paramètres IP pour ajouter des adresses IP.

  • NetBIOS sur TCP/IP (NetBT) se lie à une seule adresse IP par carte réseau. Quand un enregistrement de nom NetBIOS est émis, une seule adresse IP est enregistrée par interface. L'enregistrement se fait sur la première adresse IP répertoriée dans l'interface utilisateur (UI).

• Plusieurs cartes réseau par réseau physique. Les seules restrictions concernent le matériel.

• Plusieurs réseaux et types de support. Les seules restrictions concernent le matériel et le support. Consultez la section intitulée "L'interface NDIS et les couches inférieures" pour connaître les types de support pris en charge.

Quand un datagramme IP est envoyé par un ordinateur multi-hôtes, il est transmis à la carte réseau avec le meilleur itinéraire apparent vers sa destination. Par conséquent, le datagramme peut contenir l'adresse IP source d'une des interfaces installées sur l'ordinateur multi-hôtes, même s'il a été placé sur le support par une autre carte réseau. L'adresse de contrôle de l'accès au support source (MAC) présente sur la trame correspond à celle de la carte réseau qui a effectivement transmis la trame au support et l'adresse IP source est celle émise par l'application qui l'envoie ; donc, l'adresse n'est pas nécessairement une des adresses IP associées à l'interface d'envoi définie dans l'interface utilisateur Connexions réseaux.

Quand un ordinateur multi-hôtes possède des cartes réseau liées à des réseaux indépendants (réseaux qui sont séparés les uns des autres, comme par exemple un réseau connecté par accès à distance et une connexion locale), il se peut que des problèmes de routage surviennent. Il est souvent nécessaire, dans cette situation, d'établir des itinéraires statiques vers des réseaux distants.

Quand vous devez configurer un ordinateur multi-hôtes sur deux réseaux séparés, la meilleure méthode consiste à placer la passerelle par défaut sur le réseau principal ou sur le plus grand et le moins connu. Ensuite, vous pouvez soit ajouter des itinéraires statiques, soit utiliser un protocole de routage pour assurer la connexion avec les hôtes placés sur le réseau plus petit ou mieux connu. Évitez de configurer une passerelle par défaut différente de chaque côté, car cela pourrait entraîner l'instabilité des réseaux et la perte de connexion.

Remarque Seule une passerelle par défaut peut être active par ordinateur à un instant donné.

Vous pouvez trouver plus d'informations sur l'enregistrement de noms, la résolution et le choix des cartes réseaux sur les datagrammes sortants avec les ordinateurs multi-hôtes dans les sections intitulées "TCP (Transmission Control Protocol)", "NetBios sur TCP/IP" et "Windows Sockets" de ce livre.

CIDR (Classless Interdomain Routing)

Le routage CIDR, décrit dans les RFC 1518 et 1519, supprime le concept de classe dans les processus de gestion et d'attribution des adresses IP. Au lieu d'attribuer les adresses dans des limites préfixées et bien connues, CIDR alloue les adresses définies par une adresse de départ et une plage ; ce mode d'allocation permet une gestion plus efficace de l'espace disponible. La plage définit la partie réseau de l'adresse. Par exemple, une attribution donnée à une société client par un ISP pourrait être 10.57.1.128 /25. Cela signifie qu'un bloc de 128 adresses est destiné à usage local, les 25 bits plus significatifs étant la partie d'identification réseau de l'adresse. Une allocation traditionnelle sur classe entière serait <net> .0.0.0 /8, <net> <net> .0.0 /16 ou bien <net>.<net>.<net>.0 /24. Au fur et à mesure que ces adresses sont récupérées, elles sont réallouées à l'aide des techniques CIDR de routage sans classes.

Étant donné la base installée de systèmes classe entière, l'implémentation initiale du routage CDIR consistait à construire une chaîne de morceaux d'espace de classe C. Ce processus a été appelé supernetting. Le supernetting peut être utilisé pour regrouper plusieurs adresses réseau de classe C en un seul réseau logique. Pour utiliser le supernetting, les adresses réseau IP à combiner doivent partager les mêmes bits plus significatifs et le masque de sous-réseau est raccourci afin d'éliminer des bits de la partie réseau de l'adresse et de les ajouter à la partie hôte. Par exemple, les adresses réseau de classe C 199.199.4.0, 199.199.5.0, 199.199.6.0 et 199.199.7.0 peuvent être combinées au moyen du masque de sous-réseau 255.255.252.0 pour chacun :

NET 199.199.4 (1100 0111.1100 0111.0000 0100.0000 0000) NET 199.199.5 (1100 0111.1100 0111.0000 0101.0000 0000) NET 199.199.6 (1100 0111.1100 0111.0000 0110.0000 0000) NET 199.199.7 (1100 0111.1100 0111.0000 0111.0000 0000) MASK 255.255.252.0 (1111 1111.1111 1111.1111 1100.0000 0000)

Quand les décisions de routage sont prises, seuls les bits couverts par le masque de sous-réseau sont utilisés ; par conséquent, toutes les adresses semblent faire partie du même réseau du point de vue du routage. Tous les routeurs en fonction doivent également prendre en charge le routage CIDR et nécessiter pour cela une configuration spéciale.Windows 2000 TCP/IP permet la prise en charge des sous-réseaux de 0 et 1, comme cela est indiqué dans la RFC 1878.

Multidiffusion IP

La multidiffusion IP assure des services de multidiffusion efficaces pour les clients qui ne peuvent pas être placés sur le même segment de réseau. Par exemple, les applications Windows Sockets peuvent joindre un groupe de multidiffusion pour participer à une conférence étendue.

Windows 2000 est conforme au niveau 2 (envoi et réception) à la RFC 1112. Le protocole IGMP, décrit plus loin dans ce document, est utilisé dans la gestion de la multidiffusion IP.

IP sur ATM

Windows 2000 introduit la prise en charge du protocole IP sur ATM. Les documents RFC 1577 (et successifs) définissent le fonctionnement de base du protocole IP sur réseau ATM, ou plus précisément d'un sous-réseau IP logique sur un réseau ATM. Un sous-réseau IP logique (LIS) est un ensemble d'hôtes IP susceptibles de communiquer directement entre eux. Deux hôtes qui appartiennent à des sous-réseaux IP logiques différents ne peuvent communiquer que par l'intermédiaire d'un routeur IP membre des deux sous-réseaux.

Résolution d'adresses ATM

Étant donné que les réseaux ATM ne permettent pas la diffusion, les diffusions ARP (utilisées par Ethernet ou Token Ring) ne constituent pas une bonne solution. Par conséquent, la résolution des adresses IP vers ATM est assurée par un serveur ARP (Address Resolution Protocol) dédié.

L'une des stations d'un LIS est désignée comme serveur ARP (et le logiciel serveur ARP est chargé dans sa mémoire). Les stations qui utilisent les services du serveur ARP sont appelées clients ARP. Toutes les stations IP au sein d'un LIS sont des clients ARP. Chaque client ARP est configuré avec l'adresse ATM du serveur ARP. Au démarrage, un client ARP établit une connexion ATM avec le serveur ARP et lui envoie un paquet contenant ses adresses IP et ATM. Le serveur ARP construit une table de mappage des adresses IP vers ATM. Quand un client doit envoyer un paquet IP à un autre client (dont l'adresse IP est connue, mais dont l'adresse ATM n'est pas connue), il demande d'abord au serveur ARP l'adresse ATM du client désiré. À la réception de la réponse avec l'adresse requise, le client établit une connexion ATM directe avec le client destinataire et lui envoie les paquets IP.

Les clients ferment toute connexion ATM, y compris la connexion avec le serveur, si ces connexions sont inactives. Tous les clients actualisent régulièrement les adresses IP et ATM avec le serveur (la période par défaut est de 15 minutes). Une entrée qui n'a pas été actualisée pendant 20 minutes (par défaut) est éliminée par le serveur. Le client ARP ATM et le serveur ARP permettent tous deux le réglage d'un certain nombre de paramètres de registre qui sont énumérés dans l'Annexe A.

ICMP (Internet Control Message Protocol)

Le protocole ICMP est un protocole de maintenance spécifié dans la RFC 792 et qui fait normalement partie de la couche IP. Les messages ICMP sont encapsulés dans des datagrammes IP, de sorte qu'ils puissent être routés par le biais d'un réseau d'interconnexion. Windows NT et Windows 2000 s'appuient sur le protocole ICMP pour :

• construire et gérer les tables d'itinéraires ;

• rechercher des routeurs ;

• fournir une aide dans la recherche de l'unité de parcours à transmission maximale (PMTU) ;

• diagnostiquer les problèmes (ping, tracert, pathping) ;

• régler le contrôle du flux pour éviter la saturation de la liaison ou du routeur.

Recherche du routeur ICMP

Windows 2000 assure la recherche du routeur comme cela est spécifié dans la RFC 1256. Cette fonction constitue une bonne méthode de configuration et détection des passerelles par défaut. Plutôt que d'utiliser les passerelles par défaut configurées manuellement ou par DHCP, les ordinateurs hôtes ont la possibilité de rechercher dynamiquement les routeurs dans leur sous-réseau. En cas de défaillance du routeur principal ou de modification des préférences du routeur par les administrateurs réseau, les hôtes peuvent basculer automatiquement sur un routeur de réserve.

À l'initialisation, un hôte qui effectue la recherche du routeur réunit le groupe de multidiffusion IP de tous les systèmes (224.0.0.1), puis il attend les annonces de routeur que les routeurs envoient à ce groupe. Les hôtes sont également susceptibles d'envoyer des messages de sollicitation à l'adresse de multidiffusion IP de tous les routeurs (224.0.0.2) quand une interface s'initialise pour éviter tout retard dû à la configuration. Windows 2000 envoie un maximum de trois sollicitations à des intervalles d'environ 600 millièmes de seconde.

La fonction de recherche du routeur est gérée par les paramètres de registre PerformRouterDiscovery et SolicitationAddressBCast et prend, par défaut, la valeur "DHCP controlled" dans Windows 2000.

Quand le paramètre SolicitationAddressBCast est configuré sur 1, les sollicitations du routeur sont diffusées plutôt que multidiffusées, comme cela est décrit dans la RFC.

Gestion des tables d'itinéraires

Quand un ordinateur Windows est initialisé, la table d'itinéraires ne contient d'ordinaire que peu d'entrées. L'une d'entre elles spécifie une passerelle par défaut. Les datagrammes qui n'ont pas de meilleure correspondance d'adresse IP de destination dans la table d'itinéraires sont envoyés à la passerelle par défaut. Cependant, étant donné que les routeurs partagent des informations sur la topologie du réseau, la passerelle par défaut peut connaître un meilleur itinéraire vers une adresse donnée. Dans ce cas, quand le routeur reçoit un datagramme qui pourrait prendre le meilleur chemin, il le transmet normalement. Il communique ensuite à l'expéditeur le meilleur itinéraire, à l'aide d'un message ICMP Redirect. Ces messages peuvent spécifier la redirection d'un hôte, d'un sous-réseau ou d'un réseau entier. À la réception d'un message de redirection ICMP, un ordinateur Windows exécute un contrôle de validité afin de s'assurer qu'il provient de la passerelle de premier tronçon sur l'itinéraire actuel et que la passerelle se trouve sur un réseau à connexion directe. Si tel est le cas, un itinéraire hôte avec une durée de vie de 10 minutes est ajouté à la table d'itinéraires pour cette adresse IP de destination. Si le message de redirection ICMP n'est pas issu de la passerelle de premier tronçon sur l'itinéraire actuel ou si cette passerelle ne se trouve pas sur un réseau directement connecté, le message de redirection ICMP est ignoré.

Recherche de l'unité de parcours à transmission maximale (PMTU)

Le protocole TCP utilise la recherche de l'unité de parcours à transmission maximale (PMTU), comme cela est décrit plus loin dans la section intitulée "TCP (Transmission Control Protocol)" de ce livre. Le mécanisme repose sur les messages ICMP Destination inaccessible.

Utilisation d'ICMP pour diagnostiquer les problèmes

• L'utilitaire de ligne de commande ping permet d'envoyer des requêtes d'écho ICMP à une adresse IP et d'attendre les réponses d'écho ICMP. Ping indique le nombre de réponses reçues et l'intervalle de temps écoulé entre l'envoi de la requête et la réception de la réponse. La commande Ping permet la sélection de plusieurs options différentes. Cette commande est étudiée de manière plus approfondie dans la section de dépannage de ce livre.

• Tracert est un utilitaire de traçage d'itinéraire qui peut être extrêmement utile. L'utilitaire Tracert envoie des requêtes d'écho ICMP à une adresse IP, incrémente le champ Durée de vie (TTL) dans l'en-tête IP en partant de 1 et analyse les erreurs ICMP qui lui sont renvoyées. Chaque requête d'écho successive doit parcourir un tronçon supplémentaire dans le réseau avant que le champ TTL n'atteigne zéro et le routeur qui essaie de le transmettre renvoie un message d'erreur ICMP Temps dépassé. Tracert produit l'imprimé d'une liste ordonnée des routeurs du parcours qui ont renvoyé ces messages d'erreur. Si vous utilisez l'option -d (ne faites pas une requête DNS inverse sur chaque adresse IP), l'adresse IP de l'interface la plus proche de chaque routeur sera indiquée. L'exemple cité ci-après illustre l'utilisation de tracert pour trouver l'itinéraire à l'aide d'accès à distance allant d'un ordinateur connecté sur protocole PPP à un fournisseur Internet de Seattle, vers le site de la Maison Blanche.

          
  
  C:\>tracert www.whitehouse.gov
          Tracing route to www.whitehouse.gov [128.102.252.1]
          over a maximum of 30 hops:
           1 300 ms 281 ms 280 ms roto.seanet.com
          [199.181.164.100]
           2 300 ms 301 ms 310 ms sl-stk-1-S12-T1.sprintlink.net
          [144.228.192.65]
           3 300 ms 311 ms 320 ms sl-stk-5-F0/0.sprintlink.net
          [144.228.40.5]
           4 380 ms 311 ms 340 ms icm-fix-w-H2/0-T3.icp.net
          [144.228.10.22]
           5 310 ms 301 ms 320 ms arc-nas-gw.arc.nasa.gov
          [192.203.230.3]
           6 300 ms 321 ms 320 ms n254-ed-cisco7010.arc.nasa.gov
          [128.102.64.254]
           7 360 ms 361 ms 371 ms www.whitehouse.gov
          [128.102.252.1]

• Pathping est une commande qui combine les fonctions de ping et tracert tout en introduisant de nouvelles fonctionnalités. Tout en assurant la fonction de traçage de tracert, pathping exécute une commande ping tout au long de l'itinéraire pendant une durée définie et indique les retards et les pertes de paquets ; ceci vous aide à déterminer s'il existe des liaisons défectueuses dans le parcours.

Qualité de service (QoS) et RSVP (Resource ReSerVation Protocol)

La prise en charge de QoS est une nouvelle fonctionnalité de Windows 2000. Windows 2000 prend en charge l'exécution de plusieurs mécanismes QoS, tels que RSVP (Resource reServation Protocol), DiffServ (Differentiated Services), IEEE 802.1p, QoS ATM, etc. Les mécanismes QoS pris en charge par Windows 2000 sont réalisés par l'intermédiaire d'une simple API GqoS (Generic QoS). Une description générale de la prise en charge de QoS par la pile et les composants système associés est présentée ci-après.

L'API GqoS est une extension de l'interface de programmation Winsock. Elle contient les API et les composants système qui permettent aux applications de réserver une bande passante réseau entre le client et le serveur. Windows 2000 mappe automatiquement les requêtes GqoS sur les mécanismes QoS tels que RSVP, Diffserv, 802.1p ou ATM QoS. RSVP est un protocole de signalisation de couche 3 utilisé pour réserver une bande passante aux flux individuels d'un réseau. Il s'agit donc d'un mécanisme QoS par flux, car il établit une réservation pour chaque flux. Diffserv est un autre mécanisme QoS de couche 3. Il définit dans l'en-tête IP 6 bits qui déterminent la priorité donnée au paquet IP 3. Le trafic Diffserv peut être réparti en 64 classes de priorité appelées PHB (Per Hop Behaviors, comportements par tronçon). D'autre part, 802.1p est un mécanisme QoS de couche 2 qui indique comment les périphériques de couche 2, tels que les commutateurs Ethernet, doivent établir les priorités de trafic. Le mécanisme 802.1p définit 8 classes de priorité allant de 0 à 7. Diffserv et 802.1p sont appelés mécanismes QoS agrégés, car ils répartissent tout le trafic en un nombre fini de classes de priorité.

Les séquences d'événements suivantes sont typiques de l'interaction entre une application et GqoS :

1. L'application effectue une requête QoS en résumé par le biais de GQoS.

2. La requête est convertie en messages de signalisation RSVP. Ces messages RSVP se propagent dans le réseau et réservent une bande passante sur tous les nœuds compatibles RSVP qui se trouvent sur le parcours du réseau.

3. Outre l'établissement des réservations, les messages RSVP sont strictement surveillés par les serveurs stratégiques du réseau, qui peuvent rejeter la requête RSVP en cas de violation de la stratégie du réseau. De cette manière, l'administrateur réseau dispose des moyens pour imposer qui reçoit la requête QoS.

4. Après avoir installé la réservation RSVP, Windows 2000 commence à attribuer à tous les paquets sortants du flux impliqué la classe DiffServ et la priorité 802.1p appropriées.

5. Tout le long de son parcours à travers le réseau, le trafic du flux bénéficie de la priorité 802.1p dans les commutateurs Ethernet configurés pour 802.1p, des réservations RSVP dans les routeurs configurés pour RSVP et de la priorité de DiffServ dans les nuages configurés pour DiffServ du réseau.

Il existe plusieurs autres mécanismes QoS, tels que les Services intégrés sur ATM (ISATM), qui mappent automatiquement les requêtes GqoS sur ATM QoS sur Classical IP pour les réseaux ATM. Les services intégrés ISSLOW (Integrated Services Over Low Bit Rate) représentent un autre mécanisme QoS qui améliore les temps de latence des trafics à priorité sur les liaisons WAN lentes. En plus de l'API GqoS, une application de contrôle ou de gestion peut accéder aux fonctions de contrôle du trafic par le biais de l'API TC (Traffic Control). Cette API permet à une application de contrôle ou de gestion de participer à la qualité du service pour les applications non configurées pour QoS. Windows 2000 comporte également un serveur de stratégie appelé QoS ACS (QoS Admission Control Service). Celui-ci permet aux administrateurs réseau de contrôler qui bénéficie de QoS dans le réseau. En outre, le service QoS ACS comporte une API appelée LPM (Local Policy Module), qui permet aux ISV de construire des modules de stratégie personnalisés qui améliorent la fonctionnalité d'imposition de stratégie du mécanisme QoS ACS.

La figure 2 ci-dessous illustre les composants du système impliqués dans les services QoS et RSVP. Le service GqoS est un fournisseur QoS susceptible d'invoquer la signalisation RSVP, de déclencher le contrôle du trafic et d'assurer la notification d'événements à l'application. L'utilitaire Rsvp.exe est chargé de la signalisation RSVP issue du réseau ou destinée au réseau et de l'exécution de l'utilitaire Traffic.dll pour ajouter des flux et des filtres à la pile. Le classeur de paquets est chargé de répartir les paquets conformément aux filtres de paquets indiqués par Traffic.dll. Le planificateur de paquets gère des files d'attente séparées pour chaque classification du trafic et comporte un analyseur de conformité, un modélisateur et un séquenceur de paquets. Le modélisateur gère les flux dans les files d'attente de paquets suivant le débit préfixé et le séquenceur passe les paquets à la carte réseau en ordre de priorité, à partir des files d'attente qu'il gère. Le trafic qui n'a aucune spécification QoS est dirigé vers la file d'attente d'effort optimal, qui présente la priorité la plus faible.

Figure 2 : Architecture QoS/RSVP

L'organigramme de la figure 2 montre comment une application utilise QoS RSVP pour remettre un flux de données à un ou plusieurs clients. L'application concernée est un serveur audio qui demande une bande passante fiable de 1 mégabit par seconde pour assurer à un client une qualité audio acceptable. Le mécanisme RSVP prend en charge les flux mono et multidiffusion. Cet exemple utilise un flux monodiffusion vers un seul client.

L'application initialise et complète une structure à fournir au service GQoS. Cette structure comprend la spécification des flux d'envoi et de réception, qui inclut des paramètres tels que la bande passante de crête, la latence, la variation du retard, le type de service, etc. Meilleur effort et Garanti sont des exemples de types de service.

L'application appelle ensuite la routine WSAConnect pour se connecter au client. L'appel de cette fonction déclenche un certain nombre d'événements. RSVP est invoqué pour signaler le réseau en envoyant des messages de parcours spéciaux. Un message de parcours est envoyé à la même adresse IP de destination que celle du flux ; cependant, son objectif est de configurer les routeurs du flux et d'identifier le flux. Un routeur qui reçoit un message de parcours insère sa propre adresse IP dans le dernier tronçon du message de parcours et le transmet au routeur suivant, jusqu'à ce qu'il atteigne le client. Le client a ainsi la possibilité de comprendre quel est le parcours entre l'expéditeur et lui-même et de réserver à l'application la bande passante nécessaire sur ce parcours. Le client renvoie une requête de réservation (en décrivant de nouveau le flux désiré) en empruntant le même parcours. Les routeurs tout le long du parcours sont responsables d'analyser les ressources disponibles et de déterminer s'ils sont en mesure d'accepter la réservation. Si tous les routeurs présents le long du parcours acceptent la réservation, l'application peut compter sur la disponibilité de la bande passante réseau et des autres caractéristiques souhaitées.

Étant donné que les réseaux sont dynamiques et que le serveur ou le client est susceptible d'abandonner, par erreur, ses ressources sans en informer le réseau, les messages de parcours et les requêtes de réservation doivent être fréquemment renouvelées. Si aucune modification n'a été apportée au réseau, les messages de parcours et les réservations supplémentaires ne font que renouveler le parcours existant. Toutefois, si un nouvel itinéraire apparaît, le parcours entrepris par le flux peut changer instantanément tandis que le réseau effectue des réglages.

Quand une application serveur est utilisée pour effectuer une multidiffusion vers plusieurs clients, il se produit une séquence d'événements semblable. Une différence intéressante est que, au moment où les routeurs reçoivent des requêtes de réservation de divers clients se rapportant au même flux, ils peuvent les fusionner plutôt que de préserver des réservations individuelles pour le même flux d'informations.

IPSec (IP Security)

IPSec (IP Security) est une autre nouvelle fonctionnalité de Windows 2000. Les détails relatifs à l'implémentation et aux caractéristiques de IPSec sont très complexes et sont décrits de façon précise dans une série de RFC, de brouillons IETF et de livres blancs Microsoft. IPSec fait appel à la sécurité cryptographique afin d'assurer le contrôle d'accès, l'intégrité sans connexion, l'authentification de l'origine des données, la protection contre les répétitions, la confidentialité et la confidentialité limitée au flux de trafic. Puisque la sécurité IPSec est assurée au niveau de la couche IP, ses services sont disponibles pour les protocoles de niveau supérieur dans la pile et, en conséquence, pour les applications existantes.

La sécurité IPSec permet à un système de sélectionner des protocoles de sécurité, de décider quels sont les algorithmes à utiliser pour les services, d'établir et de gérer des clés cryptographiques pour chaque relation de sécurité. IPSec est en mesure de protéger les parcours entre hôtes, entre passerelles de sécurité ou encore entre hôtes et passerelles de sécurité. Les services disponibles et requis pour le trafic sont configurés à l'aide de la stratégie IPSec. La stratégie IPSec peut être configurée localement sur un ordinateur ou peut être assignée par le biais de mécanismes de stratégie de groupe de Windows 2000 à l'aide des services Active Directory™. Lors de l'utilisation d'Active Directory, les hôtes détectent au démarrage l'affectation de la stratégie, la récupèrent, puis vérifient régulièrement l'existence de mises à jour. La stratégie IPSec indique comment les ordinateurs se font confiance. IPSec peut utiliser soit des certificats, soit Kerberos comme technique d'authentification. La relation de confidentialité la plus simple à utiliser est l'approbation de domaines Windows 2000 basée sur Kerberos. Les stratégies IPSec prédéfinies sont configurées pour faire confiance aux ordinateurs présents dans le même domaine ou dans d'autres domaines approuvés de Windows 2000.

Chaque datagramme IP traité au niveau de la couche IP est comparé à un ensemble de filtres fournis par la stratégie de sécurité, qui est gérée par un administrateur pour un ordinateur appartenant à un domaine. Le protocole IP peut exécuter une des trois opérations suivantes avec un datagramme :

• lui fournir les services IPSec ;

• le faire passer sans modifications ;

• l'annuler.

Une stratégie IPSec contient un filtre, une action de filtrage, l'authentification, la configuration du tunnel et le type de connexion. Par exemple, deux ordinateurs autonomes d'un même domaine Windows 2000 peuvent être configurés pour utiliser IPSec entre eux et activer la stratégie du serveur sécurisé. Si les deux ordinateurs ne sont pas membres du même domaine ou d'un domaine approuvé, l'approbation doit être configurée au moyen d'un certificat ou d'une clé prépartagée en mode serveur sécurisé, par :

• la mise en place d'un filtre qui définit tout le trafic entre les deux hôtes ;

• le choix d'une méthode d'authentification ;

• la sélection d'une stratégie de négociation (serveur sécurisé dans ce cas, indiquant que tout le trafic qui correspond au(x) filtre(s) doit utiliser IPSec) ;

• l'indication d'un type de connexion (LAN, accès distant ou les deux).

Une fois la stratégie en place, le trafic qui correspond aux filtres utilise les services fournis par IPSec. Quand un hôte dirige un trafic IP (même une commande simple telle que ping) vers un autre, une association de sécurité (SA) est établie par le biais d'une brève conversation sur le port UDP 500, à l'aide du service IKE (Internet Key Exchange), puis le trafic commence à s'écouler. La trace réseau suivante montre l'établissement d'une connexion TCP entre deux hôtes configurés pour IPSec. Les seules parties du datagramme IP qui ne sont pas cryptées et qui sont visibles par Netmon après l'établissement de l'association de sécurité sont l'adresse MAC et les en-têtes IP :

Source IP Dest IP Prot Description
    davemac-ipsec calvin-ipsec UDP Src Port: ISAKMP, (500); Dst
    Port: ISAKMP (500); Length = 216 (0xD8)
    calvin-ipsec davemac-ipsec UDP Src Port: ISAKMP, (500); Dst
    Port: ISAKMP (500); Length = 216 (0xD8)
    davemac-ipsec calvin-ipsec UDP Src Port: ISAKMP, (500); Dst
    Port: ISAKMP (500); Length = 128 (0x80)
    calvin-ipsec davemac-ipsec UDP Src Port: ISAKMP, (500); Dst
    Port: ISAKMP (500); Length = 128 (0x80)
    davemac-ipsec calvin-ipsec UDP Src Port: ISAKMP, (500); Dst
    Port: ISAKMP (500); Length = 76 (0x4C)
    calvin-ipsec davemac-ipsec UDP Src Port: ISAKMP, (500); Dst
    Port: ISAKMP (500); Length = 76 (0x4C)
    davemac-ipsec calvin-ipsec UDP Src Port: ISAKMP, (500); Dst
    Port: ISAKMP (500); Length = 212 (0xD4)
    calvin-ipsec davemac-ipsec UDP Src Port: ISAKMP, (500); Dst
    Port: ISAKMP (500); Length = 172 (0xAC)
    davemac-ipsec calvin-ipsec UDP Src Port: ISAKMP, (500); Dst
    Port: ISAKMP (500); Length = 84 (0x54)
    calvin-ipsec davemac-ipsec UDP Src Port: ISAKMP, (500); Dst
    Port: ISAKMP (500); Length = 92 (0x5C)
    davemac-ipsec calvin-ipsec IP ID = 0xC906; Proto = 0x32; Len:
    96
    calvin-ipsec davemac-ipsec IP ID = 0xA202; Proto = 0x32; Len:
    96
    davemac-ipsec calvin-ipsec IP ID = 0xCA06; Proto = 0x32; Len:
    88
	

L'ouverture d'un des datagrammes IP envoyé après l'établissement de l'association de sécurité révèle bien peu de ce qui se trouve actuellement dans le datagramme (un SYN TCP ou une requête de connexion). Les seules parties évidentes du paquet sont les en-têtes Ethernet et IP. En cas d'utilisation d'ESP, l'en-tête TCP est également crypté et ne peut être analysé par Netmon.

Src IP Dest IP Protoc Description
    ===================================================
    davemac-ipsec calvin-ipsec IP ID = 0xC906; Proto = 0x32; Len:
    96
    + FRAME: Base frame properties
    + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet
    Protocol
     IP: ID = 0xC906; Proto = 0x32; Len: 96
     IP: Version = 4 (0x4)
     IP: Header Length = 20 (0x14)
     IP: Precedence = Routine
     IP: Type of Service = Normal Service
     IP: Total Length = 96 (0x60)
     IP: Identification = 51462 (0xC906)
     + IP: Flags Summary = 2 (0x2)
     IP: Fragment Offset = 0 (0x0) bytes
     IP: Time to Live = 128 (0x80)
     IP: Protocol = 0x32
     IP: Checksum = 0xD55A
     IP: Source Address = 172.30.250.139
     IP: Destination Address = 157.59.24.37
     IP: Data: Number of data bytes remaining = 76 (0x004C)
    00000: 52 A4 68 7B 94 80 00 00 90 1D 84 80 08 00 45 00
    R.h{..........E.
    00010: 00 60 C9 06 40 00 80 32 D5 5A AC 1E FA 8B 9D 3B
    .`..@..2.Z.....;
    00020: 18 25 18 D9 03 E8 00 00 00 01 F6 EF D0 23 1C 59
    .%...........#.Y
    00030: BD 01 78 BE 69 24 D6 EB AE 4F 08 DA 0F D4 6C 04
    ..x.i$...O....l.
    00040: 5F BC A6 E0 8D BE 5C 89 2D 56 60 80 FA 8B CC 5E
    _.....\.-V`....^
    00050: 4E 61 3D 46 75 B9 D1 5B 52 45 79 7D 1E 36 1F 01
    Na=Fu..[REy}.6..
    00060: FF 25 E5 BA 48 AF D7 7A D5 9A 34 3E 5D 7D
    .%..H..z..4>]}
	

L'utilisation d'une stratégie de serveur sécurisé empêche également à tout autre type de trafic d'atteindre des destinations qui n'interprètent pas IPSec ou qui ne font pas partie du même groupe d'approbation. La stratégie Initiateur sécurisé offre des paramètres qui s'appliquent mieux aux serveurs ; une tentative de sécurisation du trafic est effectuée, mais si le client n'interprète pas IPSec, la négociation cesse et le serveur envoie des paquets de texte en clair.

En général, quand le cryptage des données se fait avec IPSec, le niveau des performances réseau diminue, en raison du temps de traitement consacré au cryptage. Une méthode possible pour réduire l'impact de cette surcharge sur les performances est de passer le traitement à un périphérique matériel. Étant donné que NDIS 5.0 permet d'effectuer le déchargement des tâches, il est possible d'inclure du matériel de cryptage sur les cartes réseau. Des cartes réseau prenant en charge le déchargement matériel IPSec sont disponibles auprès de plusieurs fournisseurs.

IPSec sera sans doute très populaire pour la protection du trafic réseau public et du trafic réseau interne des entreprises et/ou des administrations gouvernementales, pour qui les données traitées sont confidentielles. Une implémentation courante consiste à appliquer les stratégies IPSec de serveur sécurisé uniquement aux serveurs utilisés pour le stockage et/ou la diffusion d'informations confidentielles.

IGMP (Internet Group Management Protocol)

Windows 2000 prend en charge la multidiffusion IP (IGMP version 2) de niveau 2 (complet), telle qu'elle est décrite dans les RFC 1112 et RFC 2236. L'initiation à la RFC 1112 présente un bon résumé de la multidiffusion IP. Le texte contient notamment les passages suivants :

"La multidiffusion IP est la transmission d'un datagramme IP à un groupe d'hôtes, c'est-à-dire un ensemble de zéro ou de plusieurs hôtes identifiés par une adresse de destination IP unique. Un datagramme de multidiffusion est remis à tous les membres de son groupe d'hôtes de destination avec le même effort optimal de fiabilité que les datagrammes IP monodiffusion normaux ; cela signifie que le datagramme n'est pas garanti d'arriver intact à tous les membres du groupe de destination ou dans le même ordre par rapport aux autres datagrammes.

L'appartenance à un groupe d'hôtes est dynamique ; cela signifie que les hôtes peuvent rejoindre ou quitter les groupes à tout instant. Aucune restriction ne se fait sur l'emplacement ou le nombre de membres d'un groupe d'hôtes. Un hôte peut également être membre de plus d'un groupe simultanément. Un hôte ne doit pas nécessairement être membre d'un groupe pour lui envoyer des datagrammes.

Un groupe d'hôtes peut être permanent ou transitoire. Un groupe permanent comporte une adresse IP bien connue, attribuée par l'administrateur. Il s'agit de l'adresse (et non l'appartenance au groupe) qui est permanente ; à tout instant, un groupe permanent peut avoir un nombre quelconque de membres, voire aucun. Ces adresses de multidiffusion IP qui ne sont pas réservées aux groupes permanents sont disponibles pour l'attribution dynamique aux groupes transitoires qui n'existent que s'ils possèdent des membres.

La transmission sur réseau d'interconnexion des datagrammes IP de multidiffusion est gérée par des routeurs multidiffusion qui cohabitent avec les passerelles Internet ou qui en sont séparés. Un hôte transmet un datagramme IP de multidiffusion en tant que multidiffusion de réseau local qui atteint tous les membres voisins du groupe hôte de destination. Si le datagramme présente une durée de vie IP supérieure à 1, les routeurs de multidiffusion connectés au réseau local le transmettent vers tous les autres réseaux qui possèdent des membres du groupe de destination. Sur ces autres réseaux membre accessibles dans la limite de durée de vie IP, un routeur multidiffusion connecté achève la remise en transmettant le datagramme en tant que multidiffusion locale."

Extensions IP/ARP pour multidiffusion IP

Pour la prise en charge de la multidiffusion IP, un itinéraire supplémentaire est défini sur l'hôte. L'itinéraire (ajouté par défaut) indique que, si un datagramme doit être envoyé à un groupe d'hôtes de multidiffusion, il doit l'être à l'adresse IP du groupe d'hôtes par le biais de la carte d'interface locale et ne doit pas être transmis à la passerelle par défaut. L'itinéraire suivant (que vous pouvez trouver grâce à la commande route print) illustre cela :

Network Address Netmask Gateway Address Interface
    Metric224.0.0.0 224.0.0.0 10.99.99.1 10.99.99.1 1

Les adresses de groupes d'hôtes se reconnaissent facilement, car elles se trouvent dans la plage de classe D, de 224.0.0.0 à 239.255.255.255. Les quatre bits les plus significatifs de ces toutes adresses IP sont 1110.

Pour envoyer un paquet à un groupe d'hôtes par le biais de l'interface locale, l'adresse IP doit être résolue en une adresse MAC. Selon les indications données dans les RFC :

"L'adresse IP d'un groupe d'hôtes est mappée sur une adresse de multidiffusion Ethernet en plaçant les 23 bits les moins significatifs de l'adresse IP dans les 23 bits les moins significatifs de l'adresse de multidiffusion Ethernet 01-00-5E-00-00-00 (hexa). Étant donné que l'adresse IP d'un groupe d'hôtes comporte 28 bits significatifs, plusieurs adresses de groupe d'hôtes peuvent être mappées sur la même adresse de multidiffusion Ethernet."

Par exemple, un datagramme adressé à l'adresse de multidiffusion 225.0.0.5 serait envoyé à l'adresse de contrôle d'accès MAC (Ethernet) 01-00-5E-00-00-05. Cette adresse est composée de la jonction de 01-00-5E et des 23 bits les moins significatifs de 225.0.0.5 (00-00-05).

Étant donné que plusieurs adresses de groupes d'hôtes sont susceptibles d'être mappées sur la même adresse de multidiffusion Ethernet, l'interface peut indiquer des multidiffusions pour un groupe d'hôtes pour lequel aucune application locale n'a un manifesté son intérêt. Ces multidiffusions supplémentaires sont ignorées par le protocole TCP/IP.

Extensions multidiffusion de Windows Sockets

Actuellement, la multidiffusion IP (Internet Protocol) est prise en charge uniquement sur les sockets AF_INET de type SOCK_DGRAM et SOCK_RAW. Les datagrammes de multidiffusion IP sont envoyés par défaut avec une durée de vie (TTL) égale à 1. Les applications ont la possibilité de définir cette valeur à l'aide de la fonction setsockopt. Par convention, les routeurs de multidiffusion utilisent les seuils TTL pour déterminer la distance à laquelle doivent être transférés les datagrammes. Ces seuils TTL sont définis de la manière suivante :

• Les datagrammes de multidiffusion comportant une durée de vie (TTL) initiale égale à 0 sont limités au même hôte.

• Les datagrammes de multidiffusion comportant une durée de vie (TTL) initiale égale à 1 sont limités au même sous-réseau.

• Les datagrammes de multidiffusion comportant une durée de vie (TTL) initiale égale à 32 sont limités au même site.

• Les datagrammes de multidiffusion comportant une durée de vie (TTL) initiale égale à 64 sont limités à la même région.

• Les datagrammes de multidiffusion comportant une durée de vie (TTL) initiale égale à 128 sont limités au même continent.

• Les datagrammes de multidiffusion comportant une durée de vie (TTL) initiale égale à 255 ne sont soumis à aucune restriction de portée.

Utilisation de IGMP par les composants de Windows

Certains composants de Windows NT et de Windows 2000 utilisent IGMP. Par exemple, la fonction de recherche des routeurs utilise, par défaut, les multidiffusions. Les serveurs WINS font appel à la multidiffusion lors des tentatives de localisation des partenaires de réplication.

TCP (Transmission Control Protocol)

TCP offre aux applications un service de connexion fiable au niveau du flux d'octets. La gestion réseau Microsoft se base sur le transfert TCP pour la connexion, le partage des fichiers et des imprimantes, la réplication des informations entre les contrôleurs de domaine, le transfert des listes de navigation et pour d'autres fonctions courantes. TCP ne peut être utilisé que dans les communications de type un à un.

À l'aide d'un total de vérification tant sur les en-têtes que sur le transport de chaque segment, le protocole TCP augmente les chances de détecter une corruption du réseau. NDIS 5.0 offre la prise en charge du déchargement des tâches et Windows 2000 TCP en tire parti en faisant calculer le total de vérification TCP par la carte réseau si son pilote dispose de cette fonction. La possibilité de faire calculer le total de vérification par le matériel peut conduire à une amélioration des performances dans les environnements à débits extrêmement élevés. Windows 2000 TCP a été également rendu plus robuste contre diverses attaques qui ont été publiées au cours des deux dernières années et a été soumis à un examen sur la sécurité interne dans le but de réduire une éventuelle faiblesse envers de futures attaques. Par exemple, l'algorithme du numéro de séquence initial a été modifié de sorte que les ISN croissent par incréments aléatoires, cela au moyen d'un générateur de nombres aléatoires RC4 initialisé par une clé aléatoire de 2048 bits au démarrage du système.

Calcul de la taille de la fenêtre de réception TCP et dimensionnement de la fenêtre (RFC 1323)

La taille de la fenêtre de réception TCP est la quantité de données reçues (en octets) susceptibles d'être transférées par tampon en une seule fois sur une connexion. L'hôte expéditeur ne peut envoyer que cette quantité de données, puis il doit attendre un accusé de réception et une mise à jour de la fenêtre de la part de l'hôte receveur. La conception de la pile Windows 2000 TCP/IP permet sa mise au point automatique dans la plupart des environnements et l'utilisation de fenêtres par défaut plus grandes par rapport aux versions précédentes. Au lieu d'utiliser une taille de fenêtre de réception par défaut fixée au niveau matériel, TCP la dimensionne par des incréments pairs de la taille de segment maximale (MSS) négociés lors de la configuration de la connexion. La correspondance de la fenêtre de réception avec les incréments pairs du MSS fait augmenter le pourcentage des segments TCP pleine taille utilisés au cours d'une transmission importante de données.

La valeur par défaut de la taille de la fenêtre de réception est calculée de la manière suivante :

1. La première requête de connexion envoyée à un hôte distant annonce une taille de fenêtre de réception de 16 Ko (16 384 octets).

2. Lors de l'établissement de la connexion, la taille de fenêtre de réception est arrondie à un incrément de la taille de segment maximal TCP (MSS) qui avait été négociée lors de la configuration de la connexion.

3. Si elle n'est pas au moins égale à quatre fois la valeur MSS, elle est configurée sur 4 * MSS avec une taille maximale de 64 Ko, à moins qu'une option de dimensionnement de fenêtre (RFC 1323) ait été sélectionnée.

Pour Ethernet, la fenêtre est normalement configurée sur 17 520 octets (16 Ko arrondis à douze segments de 1460 octets). Il existe deux méthodes de configuration de la taille de la fenêtre de réception sur des valeurs spécifiques :

• le paramètre de registre TcpWindowSize (voir Annexe A) ;

• la fonction Windows Sockets setsockopt (par socket).

Pour améliorer les performances des réseaux à bande passante élevée et à retard élevé, Windows 2000 a introduit la prise en charge des fenêtres dimensionnables (RFC 1323). Cette RFC décrit une méthode de prise en charge des fenêtres dimensionnables en permettant à TCP de négocier un facteur d'échelle de la taille des fenêtres lors de l'établissement de la connexion. Cette technique est à même d'offrir une fenêtre de réception effective de 1 gigaoctet (Go) au maximum. La section 2.2 de la RFC 1323 en donne une bonne description :

"L'option de dimensionnement de fenêtre à trois octets peut être envoyée dans un segment SYN par un TCP. Elle comporte deux objectifs : 1. indiquer que le protocole TCP est prêt pour le dimensionnement des fenêtres de réception et d'envoi et 2. communiquer un facteur d'échelle à appliquer à sa fenêtre de réception. En conséquence, un protocole TCP qui est prêt pour le dimensionnement des fenêtres doit envoyer l'option, même si son propre facteur d'échelle est de 1. Le facteur d'échelle est limité à une puissance de deux et est codé de manière logarithmique ; son implémentation peut donc se faire par des opérations de décalage binaire.

TCP Window Scale Option (WSopt):
     Kind: 3 Length: 3 bytes
     +---------+---------+---------+
     | Kind=3 |Length=3 |shift.cnt|
     +---------+---------+---------+

Cette option est une proposition, pas une promesse ; les deux côtés doivent envoyer des options de dimensionnement de fenêtre dans leurs segments SYN pour activer le dimensionnement dans les deux directions. Lorsque le dimensionnement est activé, le protocole TCP qui envoie cette option décale à droite de "shift.cnt" bits ses valeurs réelles de la fenêtre de réception pour la transmission dans SEG.WND. La valeur shift.cnt peut être zéro (proposition de redimensionnement, tout en appliquant un facteur d'échelle de 1 à la fenêtre de réception).

Cette option peut être envoyée dans un segment <SYN> initial, en d'autres termes, un segment avec le bit SYN à 1 (on) et le bit ACK à 0 (off). Elle peut également être envoyée dans un segment <SYN,ACK>, mais uniquement si l'option Window Scale a été reçue dans le segment <SYN> initial. Une option Window Scale dans un segment sans bit SYN doit être ignorée.

Le champ Window d'un segment SYN (en d'autres termes, un <SYN> ou un <SYN,ACK>) n'est jamais ajusté."

Quand vous examinez les traces réseau d'une connexion établie entre deux ordinateurs qui prennent en charge le dimensionnement des fenêtres, rappelez-vous que la taille des fenêtres annoncée dans la trace doit être redimensionnée avec le facteur d'échelle négocié. Le facteur d'échelle peut être observé dans les paquets d'établissement de la connexion (protocole de transfert à trois voies), comme indiqué dans la saisie du Moniteur réseau ci-dessous :

Src Addr Dst Addr Protocol Description
    THEMACS1 NTBUILDS TCP ....S., len:0, seq:725163-725163,
    ack:0, win:65535, src:1217 dst:139
    + FRAME: Base frame properties
    + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD
    Internet
    Protocol
    + IP: ID = 0xB908; Proto = TCP; Len: 64
     TCP: ....S., len:0, seq:725163-725163, ack:0, win:65535,
    src:1217 dst:139 (NBT Session)
     TCP: Source Port = 0x04C1
     TCP: Destination Port = NETBIOS Session Service
     TCP: Sequence Number = 725163 (0xB10AB)
     TCP: Acknowledgement Number = 0 (0x0)
     TCP: Data Offset = 44 (0x2C)
     TCP: Reserved = 0 (0x0000)
     + TCP: Flags = 0x02 : ....S.
     TCP: Window = 65535 (0xFFFF)
     TCP: Checksum = 0x8565
     TCP: Urgent Pointer = 0 (0x0)
     TCP: Options
     + TCP: Maximum Segment Size Option
     TCP: Option Nop = 1 (0x1)
     TCP: Window Scale Option
     TCP: Option Type = Window Scale
     TCP: Option Length = 3 (0x3)
     TCP: Window Scale = 5 (0x5)
     TCP: Option Nop = 1 (0x1)
     TCP: Option Nop = 1 (0x1)
     + TCP: Timestamps Option
     TCP: Option Nop = 1 (0x1)
     TCP: Option Nop = 1 (0x1)
     + TCP: SACK Permitted Option
    00000: 8C 04 C8 BD A3 82 00 00 50 7D 83 80 08 00 45 00
    ........P}....E.
    00010: 00 40 B9 08 40 00 80 06 A7 1A 9D 36 15 FD AC 1F
    .@..@......6....
    00020: 3B 42 04 C1 00 8B 00 0B 10 AB 00 00 00 00 B0 02
     ;B..............
    00030: FF FF 85 65 00 00 02 04 05 B4 01 03 03 05 01 01
    ...e............
    00040: 08 0A 00 00 00 00 00 00 00 00 01 01 04 02
    ..............
    *************************************************************************

    **************************

L'ordinateur qui envoie le paquet ci-dessus offre une option Window Scale avec un facteur de 5. Si l'ordinateur cible répond et accepte l'option Window Scale dans SYN-ACK, alors il est entendu que toute fenêtre TCP annoncée par cet ordinateur doit être dorénavant décalée à gauche de 5 bits à partir de ce point (SYN n'est pas ajusté). Par exemple, si l'ordinateur annonce une fenêtre de 32 ko dans son premier envoi de données, cette valeur doit être décalée à gauche de 5 bits (en mettant des 0 à partir de la droite), comme indiqué ci-dessous :

32Kbytes = 0x7fff = 111 1111 1111 1111
    Left-shift 5 bits = 1111 1111 1111 1110 0000 = 0xffffe
    (1,048,544
    bytes)

Le facteur d'échelle n'est pas nécessairement symétrique, il peut donc être différent dans les deux directions du flux des données.

Windows 2000 effectue automatiquement le dimensionnement si la valeur TcpWindowSize est configuré sur une valeur supérieure à 64 ko et que le paramètre de registre Tcp1323Opts est correctement configuré. Reportez-vous à l'Annexe A pour plus d'informations sur la configuration de ce paramètre.

Accusés de réception (ACK) retardés

Comme indiqué dans la RFC 1122, TCP réduit le nombre de paquets envoyés sur le support grâce aux accusés de réception (ACK) retardés. La pile Microsoft TCP/IP adopte une approche courante de l'implémentation des ACK retardés. À mesure que le protocole TCP reçoit les données sur une connexion, il renvoie un accusé de réception uniquement si l'une des conditions suivantes est remplie :

• Aucun ACK n'a été envoyé à la réception du segment précédent.

• Un segment a été reçu, mais aucun autre n'est arrivé dans les 200 millièmes de seconde pour cette connexion.

En résumé, normalement un ACK est envoyé pour chaque autre segment TCP reçu sur la connexion, à moins que le compteur ACK retardé (200 millièmes de seconde) n'expire. Le compteur ACK retardé peut être réglé par l'intermédiaire du nouveau paramètre de registre TcpDelAckTicks de Windows 2000.

Accusé de réception TCP sélectif (RFC 2018)

Windows 2000 introduit la prise en charge d'une importante fonctionnalité qui améliore les performances, à savoir Accusé de réception sélectif (SACK). La fonction SACK est particulièrement importante pour les connexions caractérisées par des grandes dimensions de fenêtres TCP. Avant SACK, un récepteur pouvait seulement accuser réception du dernier numéro de séquence de données contiguës reçues, ou du bord gauche de la fenêtre de réception. Quand la fonction SACK est activée, le récepteur continue d'utiliser le numéro ACK pour accuser la réception du bord gauche de la fenêtre de réception, mais il peut également accuser réception individuellement d'autres blocs de données non contigus. La fonction SACK utilise les options d'en-tête TCP, comme indiqué ci-dessous. Ce texte a été directement extrait de la RFC 2018 :

Option Sack-Permitted

Cette option de deux octets est susceptible d'être envoyée dans un SYN par un protocole TCP à même de recevoir (et probablement de traiter) l'option SACK après l'ouverture de la connexion. Elle NE DOIT PAS être envoyée sur des segments autres que SYN.

Option TCP Sack-Permitted :
     Kind: 4
     +---------+---------+
     | Kind=4 | Length=2|
     +---------+---------+

Format de l'option SACK

L'option SACK doit être utilisée pour convoyer de grandes quantités d'accusés de réception entre un récepteur et un expéditeur sur une connexion TCP active.

TCP SACK Option:
     Kind: 5
     Length: Variable
     +--------+--------+
     | Kind=5 | Length |
     +--------+--------+--------+--------+
     | Left Edge of 1st Block |
     +--------+--------+--------+--------+
     | Right Edge of 1st Block |
     +--------+--------+--------+--------+
     | |
     / . . . /
     | |
     +--------+--------+--------+--------+
     | Left Edge of nth Block |
     +--------+--------+--------+--------+
     | Right Edge of nth Block |
     +--------+--------+--------+--------+

Quand l'option SACK est activée (par défaut), un ou plusieurs paquets peuvent être perdus et le récepteur est à même d'informer l'expéditeur sur les données exactes qui ont été reçues et donc sur les données manquantes. L'expéditeur peut ensuite retransmettre de manière sélective les données manquantes, sans besoin de retransmettre les blocs de données qui ont déjà été reçus avec succès. L'option SACK est gérée par le paramètre de registre SackOpts. La capture d'écran du Moniteur réseau ci-dessous montre un hôte qui accuse réception de toutes les données jusqu'à la séquence 54857341, ainsi que les données de la séquence 54858789-54861685.

+ FRAME: Base frame properties
    + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet
    Protocol
    + IP: ID = 0x1A0D; Proto = TCP; Len: 64
     TCP: .A...., len:0, seq:925104-925104, ack:54857341,
    win:32722,
     src:1242 dst:139
     TCP: Source Port = 0x04DA
     TCP: Destination Port = NETBIOS Session Service
     TCP: Sequence Number = 925104 (0xE1DB0)
     TCP: Acknowledgement Number = 54857341 (0x3450E7D)
     TCP: Data Offset = 44 (0x2C)
     TCP: Reserved = 0 (0x0000)
     + TCP: Flags = 0x10 : .A....
     TCP: Window = 32722 (0x7FD2)
     TCP: Checksum = 0x4A72
     TCP: Urgent Pointer = 0 (0x0)
     TCP: Options
     TCP: Option Nop = 1 (0x1)
     TCP: Option Nop = 1 (0x1)
     + TCP: Timestamps Option
     TCP: Option Nop = 1 (0x1)
     TCP: Option Nop = 1 (0x1)
     TCP: SACK Option
     TCP: Option Type = 0x05
     TCP: Option Length = 10 (0xA)
     TCP: Left Edge of Block = 54858789 (0x3451425)
     TCP: Right Edge of Block = 54861685 (0x3451F75)

Cachets TCP (RFC 1323)

Windows 2000 introduit une autre fonction RFC 1323 qui est l'implémentation des cachets TCP. Comme l'option SACK, les cachets sont importants pour les connexions caractérisées par des grandes dimensions de fenêtres TCP. Ils ont été conçus afin d'aider le protocole TCP dans la mesure précise du temps de transmission aller-retour (RTT) pour régler les délais de retransmission. Voici l'option d'en-tête TCP pour les cachets, extraite de la RFC 1323 :

Option Cachets TCP (TSopt) :

Kind: 8
     Length: 10 bytes
     +-------+-------+---------------------+---------------------+

     |Kind=8 | 10 | TS Value (TSval) |TS Echo Reply (TSecr)|
     +-------+-------+---------------------+---------------------+

     1 1 4 4

L'option Cachets comporte deux champs d'horodatage de quatre octets. Le champ valeur (TSval) contient la valeur actuelle de l'horloge d'horodatage du protocole TCP qui envoie l'option.

Le champ Timestamp Echo Reply (Tsecr) n'est valide que si le bit ACK est configuré dans l'en-tête TCP ; s'il est valide, il émet en retour une valeur de cachet envoyée par le protocole TCP distant dans le champ TSval d'une option Cachets. Quand le champ TSecr n'est pas valide, sa valeur doit être zéro. La valeur TSecr sera, en général, celle de l'option Cachet la plus récemment reçue ; cependant, des exceptions existent, expliquées ci-dessous.

Un protocole TCP peut envoyer l'option Cachets (TSopt) dans un segment <SYN> initial (par exemple, segment contenant un bit SYN et pas de bit ACK) et un TSopt dans d'autres segments uniquement s'il a reçu un TSopt dans le segment <SYN> initial de la connexion."

Le champ d'option Cachets peut être visualisé dans une capture du Moniteur réseau par l'expansion du champ des options TCP, comme illustré ci-dessous :

TCP: Timestamps Option
     TCP: Option Type = Timestamps
     TCP: Option Length = 10 (0xA)
     TCP: Timestamp = 2525186 (0x268802)
     TCP: Reply Timestamp = 1823192 (0x1BD1D8)

L'utilisation des cachets est désactivée par défaut. Elle peut être activée à l'aide du paramètre de registre Tcp1323Opts, traité dans l'Annexe A.

Découverte du chemin MTU.

La découverte du chemin MTU est traitée dans la RFC 1191. À l'établissement d'une connexion, les deux hôtes impliqués échangent les valeurs maximales TCP des tailles de leurs segments (MSS). La plus petite valeur parmi les deux valeurs MSS est utilisée pour la connexion. Dans le passé, la taille MSS d'un hôte correspondait à l'unité MTU au niveau de la couche de liaison moins 40 octets pour les en-têtes IP et TCP. Cependant, la prise en charge d'options TCP supplémentaires, telles que les cachets, a augmenté la dimension de l'en-tête TCP+IP typique à 52 octets ou plus.

Figure 3 : comparaison de MTU et MSS

Quand les segments TCP sont destinés à un réseau non local, le bit Ne pas fragmenter est configuré dans l'en-tête IP. Les routeurs ou les supports tout au long du parcours peuvent présenter un MTU différent de celui des deux hôtes. Si un segment de support présente un MTU trop faible pour le datagramme IP qui doit être routé, le routeur tente de le fragmenter de manière adéquate. Il découvre ensuite que le bit Ne pas fragmenter est configuré dans l'en-tête IP. À ce moment-là, le routeur doit informer l'hôte expéditeur que le datagramme ne peut plus être transmis sans fragmentation. Ceci se fait par un message "ICMP Destination Unreachable Fragmentation Needed and DF Set" (Destination ICMP inaccessible fragmentation obligatoire et DF configuré). La plupart des routeurs spécifient également le MTU pour le prochain tronçon en plaçant sa valeur dans les 16 bits les moins significatifs du champ d'en-tête ICMP, qui est inutilisé dans la RFC 792. Consultez la RFC 1191, section 4, pour connaître le format de ce message. À la réception de ce message d'erreur ICMP, le protocole TCP ajuste son MSS pour la connexion à la valeur MTU spécifiée moins la taille de l'en-tête IP et TCP, de sorte que tous les paquets successifs envoyés sur la connexion ne soient pas supérieurs à la taille maximale et qu'ils puissent passer le parcours sans fragmentation.

Remarque : le MTU minimal admis est de 88 octets et Windows 2000 TCP impose cette limite.

Certains routeurs non compatibles peuvent discrètement éliminer des datagrammes IP ne pouvant pas être fragmentés ou risquent de ne pas rapporter correctement le MTU du tronçon suivant. Quand cela se produit, il peut être nécessaire de modifier la configuration de l'algorithme de détection du PMTU. Il existe deux possibilités de modification du registre dans la pile TCP/IP de Windows 2000 pour contourner ces périphériques qui posent problème. Ces entrées de registre sont décrites en détail dans l'Annexe A :

• EnablePMTUBHDetect : ajuste l'algorithme de recherche PMTU pour tenter de détecter les routeurs de type "trou noir". La détection des trous noirs est désactivée par défaut.

• EnablePMTUDiscovery : active ou désactive entièrement le mécanisme de recherche PMTU. Quand la recherche MTU est désactivée, un MSS de 536 octets est utilisé pour toutes les adresses de destination non locales. La recherche PMTU est activée par défaut.

Il est possible de rechercher manuellement le PMTU entre deux hôtes à l'aide de la commande ping avec l'option -f (ne pas fragmenter), de la manière suivante :

ping -f -n <nombre de ping>
    -l<taille> <adresse ip de
    destination>

Comme cela est illustré dans l'exemple ci-dessous, le paramètre taille est susceptible d'être modifié jusqu'à ce que le MTU soit trouvé. Le paramètre taille utilisé par ping représente la taille du tampon de données à envoyer, sans inclure les en-têtes. L'en-tête ICMP consomme 8 octets et l'en-tête IP est normalement de 20 octets. Dans le cas exposé ci-dessous (Ethernet), le MTU de la couche de liaison est le tampon ping maximal plus 28 ou 1500 octets :

C:\>ping -f -n 1 -l 1472 10.99.99.10

Ping sur 10.99.99.10 avec 1472 octets de données :

Reply from 10.99.99.10: bytes=1472 time<10ms
    TTL=128

Statistiques de la commande ping pour 10.99.99.10 :

Packets: Sent = 1, Received = 1, Lost = 0 (0%
    loss),

Temps de transmission aller-retour approximatif en millièmes de seconde :

Minimum = 0ms, Maximum = 0ms, Average = 0ms
    C:\>ping -f -n 1 -l 1473 10.99.99.10

Ping sur 10.99.99.10 avec 1473 octets de données :

Packet needs to be fragmented but DF set.

Statistiques de la commande ping pour 10.99.99.10 :

Packets: Sent = 1, Received = 0, Lost = 1 (100%
    loss),

Temps de transmission aller-retour approximatif en millièmes de seconde :

Minimum = 0ms, Maximum = 0ms, Average = 0ms

Dans l'exemple illustré ci-dessus, la couche IP renvoie un message d'erreur ICMP que la commande ping interprète. Si le routeur avait été de type trou noir, la commande ping n'aurait simplement reçu aucune réponse quand sa taille aurait dépassé le MTU que le routeur était en mesure de gérer. Grâce à la commande ping, il est possible de détecter un tel routeur.

Un exemple de message d'erreur ICMP de Destination inaccessible est illustré ci-après :

******************************************************************************

    Src Addr Dst Addr Protocol Description
    10.99.99.10 10.99.99.9 ICMP Destination Unreachable:
    10.99.99.10
     See frame 3
    + FRAME: Base frame properties
    + ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet
    Protocol
    + IP: ID = 0x4401; Proto = ICMP; Len: 56
     ICMP: Destination Unreachable: 10.99.99.10 See frame 3
     ICMP: Packet Type = Destination Unreachable
     ICMP: Unreachable Code = Fragmentation Needed, DF Flag
    Set
     ICMP: Checksum = 0xA05B
     ICMP: Next Hop MTU = 576 (0x240)
     ICMP: Data: Number of data bytes remaining = 28 (0x001C)
     ICMP: Description of original IP frame
     ICMP: (IP) Version = 4 (0x4)
     ICMP: (IP) Header Length = 20 (0x14)
     ICMP: (IP) Service Type = 0 (0x0)
     ICMP: Precedence = Routine
     ICMP: ...0.... = Normal Delay
     ICMP: ....0... = Normal Throughput
     ICMP: .....0.. = Normal Reliability
     ICMP: (IP) Total Length = 1028 (0x404)
     ICMP: (IP) Identification = 45825 (0xB301)
     ICMP: Flags Summary = 2 (0x2)
     ICMP: .......0 = Last fragment in datagram
     ICMP: ......1. = Cannot fragment datagram
     ICMP: (IP) Fragment Offset = 0 (0x0) bytes
     ICMP: (IP) Time to Live = 32 (0x20)
     ICMP: (IP) Protocol = ICMP - Internet Control Message
     ICMP: (IP) Checksum = 0xC91E
     ICMP: (IP) Source Address = 10.99.99.9
     ICMP: (IP) Destination Address = 10.99.99.10
     ICMP: (IP) Data: Number of data bytes remaining = 8
    (0x0008)
     ICMP: Description of original ICMP frame
     ICMP: Checksum = 0xBC5F
     ICMP: Identifier = 256 (0x100)
     ICMP: Sequence Number = 38144 (0x9500)
    00000: 00 AA 00 4B B1 47 00 AA 00 3E 52 EF 08 00 45 00
    ...K.G...>R...E.
    00010: 00 38 44 01 00 00 80 01 1B EB 0A 63 63 0A 0A 63
    .8D........cc..c
    00020: 63 09 03 04 A0 5B 00 00 02 40 45 00 04 04 B3 01
    c....[...@E.....
    00030: 40 00 20 01 C9 1E 0A 63 63 09 0A 63 63 0A 08 00 @.
    ....cc..cc...
    00040: BC 5F 01 00 95 00

Cette erreur a été générée par la commande ping -f –n 1 -l 1000 sur un hôte Ethernet pour envoyer un grand datagramme à travers une interface routeur qui ne prend en charge qu'un MTU de 576 octets. Quand le routeur a tenté de placer la grande trame sur le réseau avec le MTU inférieur, il a déterminé que la fragmentation n'était pas permise. Il a alors renvoyé un message d'erreur pour avertir que le datagramme le plus grand pouvant être transmis est de 0x240 ou de 576 octets.

Détection de passerelle inactive

Grâce à la détection de passerelle inactive, TCP détecte les défaillances de la passerelle par défaut et ajuste la table d'itinéraire IP afin d'utiliser une autre passerelle par défaut. La pile Microsoft TCP/IP fait appel à la méthode de resélection déclenchée décrite dans la RFC 816, avec quelques légères modifications basées sur les expériences et les suggestions des clients.

Quand une connexion TCP routée à travers la passerelle par défaut essaie d'envoyer un paquet TCP à une destination un certain nombre de fois (égal à la moitié de la valeur de registre TcpMaxDataRetransmissions) sans recevoir de réponse, l'algorithme modifie l'entrée du cache d'itinéraire (RCE) relative à cette adresse IP distante et utilise la prochaine passerelle par défaut dans la liste. Quand 25 % des connexions TCP ont été passées sur la passerelle par défaut suivante, l'algorithme avise au protocole IP de remplacer la passerelle par défaut de l'ordinateur par celle actuellement utilisée par les connexions.

Par exemple, supposez qu'il y ait actuellement des connexions TCP vers 11 différentes adresses IP qui sont routées par la passerelle par défaut. Supposez maintenant que la passerelle par défaut connaisse une défaillance, qu'une deuxième passerelle par défaut soit configurée et que la valeur par défaut de TcpMaxDataRetransmissions soit de 5.

Quand la première connexion TCP tente d'envoyer des données, elle ne reçoit aucun accusé de réception. Après la troisième retransmission, l'entrée RCE de cette adresse IP est basculée sur la passerelle par défaut suivante dans la liste. À ce moment-là, toutes les connexions TCP vers cette adresse IP distante ont été basculées, mais les connexions restantes essaient toujours d'utiliser la passerelle par défaut d'origine.

Quand la deuxième connexion TCP tente d'envoyer des données, la même chose se produit. Maintenant, deux des 11 entrées RCE pointent vers la nouvelle passerelle.

Quand la troisième connexion TCP tente d'envoyer des données, après la troisième retransmission, trois des 11 RCE ont été basculées sur la deuxième passerelle par défaut. Dans la mesure où, à ce moment-là, plus de 25 % des entrées RCE ont été déplacées, la passerelle par défaut de tout l'ordinateur est déplacée vers la nouvelle passerelle.

La passerelle par défaut reste la principale pour l'ordinateur jusqu'à ce que des problèmes ne surviennent (déclenchant ainsi l'algorithme de détection de passerelle inactive qui essaie la passerelle suivante dans la liste) ou jusqu'à ce que l'ordinateur soit redémarré.

Quand la recherche atteint la dernière passerelle par défaut, elle revient au début de la liste.

Comportement TCP de retransmission

TCP lance un minuteur de retransmission quand tous les segments sortants sont passés au protocole IP. Si aucun accusé de réception n'a été reçu pour les données d'un segment donné avant que le minuteur n'expire, le segment est retransmis. Pour les nouvelles requêtes de connexion, le minuteur de retransmission est initialisé à 3 secondes (réglable à l'aide du paramètre de registre par carte TcpInitialRtt) et la requête (SYN) est renvoyée jusqu'à la valeur spécifiée dans TcpMaxConnectRetransmissions (2 fois est la valeur par défaut dans Windows 2000). Sur les connexions existantes, le nombre de retransmissions est commandé par le paramètre de registre TcpMaxDataRetransmissions (5 par défaut). Le délai de retransmission est réglé instantanément afin de correspondre aux caractéristiques de la connexion, grâce aux calculs du temps d'aller-retour arrondi SRTT (Smoothed Round Trip Time), tel qu'il est décrit dans le livre de Van Jacobson, intitulé en anglais "Congestion Avoidance and Control". Le minuteur d'un segment donné est doublé après chaque retransmissiom de ce segment. Avec cet algorithme, TCP se règle automatiquement sur le retard normal d'une connexion. Le dépassement de délai des connexions TCP prend beaucoup plus de temps sur les liaisons à retard élevé que sur celles à faible retard.

La trace suivante montre l'algorithme de retransmission pour deux hôtes connectés par le biais d'Ethernet sur le même sous-réseau. Un transfert de fichiers à l'aide de FTP était en cours quand l'hôte récepteur a été déconnecté du réseau. Étant donné que le SRTT de cette connexion était très court, la première retransmission a été envoyée après une demi-seconde environ. Le minuteur a ensuite été doublé à chaque retransmission qui a suivi. Après la cinquième retransmission, le minuteur a été doublé une fois de plus. Si aucun accusé de réception n'a été reçu avant qu'il n'expire, la connexion a été interrompue.

delta source ip dest ip pro flags description
    0.000 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq:
    8043781, ack: 8153124, win: 8760
    0.521 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq:
    8043781, ack: 8153124, win: 8760
    1.001 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq:
    8043781, ack: 8153124, win: 8760
    2.003 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq:
    8043781, ack: 8153124, win: 8760
    4.007 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq:
    8043781, ack: 8153124, win: 8760
    8.130 10.57.10.32 10.57.9.138 TCP .A.., len: 1460, seq:
    8043781, ack: 8153124, win: 8760

Dans certaines circonstances, TCP retransmet les données avant que le minuteur de retransmission n'expire. Cela se produit le plus souvent à cause d'une fonction appelée retransmission rapide. Quand un récepteur prenant en charge la retransmission rapide reçoit des données avec un numéro de séquence au-dessus du numéro prévu actuel, il suppose que certaines données ont été perdues. Pour aider l'expéditeur à prendre connaissance de cet événement, le récepteur envoie immédiatement un ACK avec un numéro égal au numéro de séquence qu'il s'attendait à recevoir. Il continue d'envoyer ces ACK pour chaque segment TCP entrant supplémentaire contenant des données qui suivent les données manquantes du flux entrant. Quand l'expéditeur commence à recevoir un flux d'ACK avec le même numéro de séquence et que ce numéro est antérieur au numéro actuellement envoyé, il peut présumer qu'un ou plusieurs segments ont été perdus. Les expéditeurs qui prennent en charge l'algorithme de retransmission rapide renvoient aussitôt le segment que le receveur attend pour remplir le trou de données, sans attendre que le minuteur de retransmission n'expire pour ce segment. Cette optimisation améliore sensiblement les performances dans un environnement réseau occupé.

Par défaut, Windows 2000 renvoie un segment s'il reçoit trois ACK relatifs au même numéro de séquence et que ce numéro de séquence est inférieur à l'actuel. Cette situation est contrôlable à l'aide du paramètre de registre TcpMaxDupAcks. Reportez-vous également à la section "Accusé de réception TCP sélectif (RFC 2018)" de ce livre.

Messages de maintien d'activité TCP

Un paquet de maintien d'activité TCP est simplement un ACK portant un numéro d'ordre égal au numéro actuel de la connexion moins un. Un hôte qui reçoit un de ces ACK répond par un ACK avec le numéro d'ordre actuel. Les maintiens d'activité peuvent être utilisés pour vérifier que l'ordinateur distant à l'extrémité d'une connexion est toujours disponible. Les maintiens d'activité TCP peuvent être envoyés toutes les KeepAliveTime millièmes de seconde (ou par défaut toutes les 7 200 000 millièmes de seconde, soit deux heures) si aucune autre donnée ou maintien d'activité de niveau supérieur n'a été transmis sur la connexion TCP. Si aucune réponse n'est donnée à un maintien d'activité, il est répété une fois toutes les KeepAliveInterval secondes. La valeur par défaut de KeepAliveInterval est de 1 seconde. Les connexions NetBT, telles que celles utilisées par de nombreux composants réseau Microsoft, envoient plus fréquemment des messages de maintien d'activité NetBIOS ; ainsi, aucun message de maintien d'activité TCP n'est normalement envoyé sur une connexion NetBIOS. Les messages de maintien d'activité TCP sont désactivés par défaut, mais les applications Windows Sockets ont la possibilité de les activer grâce à la fonction setsockopt.

Algorithme de démarrage lent et contournement d'encombrement

Services client essentiels et composants de pile

Ce livre se concentre principalement sur les composants fondamentaux de la pile TCP/IP et non sur les nombreux services disponibles qui l'utilisent. Cependant, la pile elle-même est basée sur un petit nombre de services pour les informations de configuration et la résolution de noms et d'adresses. Quelques-uns de ces services client essentiels sont présentés ici.

Configuration automatique du client et détection du support

Un des services clients les plus importants est le client DHCP (Dynamic Host Configuration Protocol). Le client DHCP possède un rôle étendu dans Windows 2000. Sa principale nouvelle fonctionnalité est sa capacité à configurer automatiquement une adresse IP et le masque sous-réseau lorsque le client est démarré sur un petit réseau privé sans qu'un serveur DHCP ne soit disponible pour assigner des adresses (comme c'est le cas d'un réseau domestique). Une autre nouvelle fonctionnalité est la prise en charge de la détection de support, qui permet d'améliorer le confort de travail itinérant des utilisateurs de périphériques portables.

1. Si un client Microsoft TCP/IP est installé et défini pour obtenir de façon dynamique des informations de configuration du protocole TCP/IP auprès d'un serveur DHCP (plutôt que d'être configuré manuellement avec une adresse IP et d'autres paramètres), le service client DHCP est mis à contribution à chaque redémarrage de l'ordinateur. Le service client DHCP utilise désormais un processus en deux étapes pour configurer le client avec une adresse IP et d'autres informations de configuration.

2. Lorsque le client est installé, il tente de localiser un serveur DHCP et d'obtenir de lui une configuration. De nombreux réseaux TCP/IP utilisent des serveurs DHCP qui sont configurés de façon administrative pour distribuer les informations aux clients sur le réseau. Si cette tentative de localisation d'un serveur DHCP échoue, le client DHCP Windows 2000 configure automatiquement sa pile avec une adresse IP sélectionnée à partir du réseau 169.254.0.0 de classe B réservé IANA, avec le masque de sous-réseau 255.255.0.08. Le client DHCP procède à un test (à l'aide d'un ARP gratuit) pour s'assurer que l'adresse IP choisie n'est pas déjà utilisée. Dans le cas contraire, il sélectionne une autre adresse IP (il peut le faire pour un maximum de 10 adresses). Dès que le client DHCP a sélectionné une adresse qui, d'après le test, n'est pas en cours d'utilisation, il configure l'interface avec cette adresse. Il continue à rechercher un serveur DHCP en arrière-plan toutes les 5 minutes. Si un serveur DHCP est identifié, les informations de configuration automatique sont supprimées et la configuration offerte par le serveur DHCP les remplace. Cette fonction de configuration automatique est connue sous le nom de APIPA (Automatic Private IP Adressing) et permet à des réseaux de bureau de petite taille ou comportant un seul sous-réseau d'utiliser TCP/IP sans configuration statique ou sans l'administration d'un serveur DHCP.

Si le client DHCP a préalablement obtenu une allocation auprès d'un serveur DHCP, la séquence modifiée d'événements suivante se produit :

1. Si l'allocation du client est encore valide (c'est-à-dire qu'elle n'a pas expiré) au moment de l'amorçage, le client tente de renouveler son allocation avec le serveur DHCP. S'il ne parvient pas à localiser un serveur DHCP lors de la tentative de renouvellement, il tente d'exécuter une commande ping sur la passerelle par défaut désignée dans l'allocation. Si la tentative d'exécution de la commande ping sur la passerelle par défaut aboutit, le client DHCP considère qu'il se trouve toujours sur le réseau sur lequel il a obtenu son allocation actuelle ; il continue donc à l'utiliser. Par défaut, le client tente de renouveler son allocation en arrière-plan lorsque la moitié du temps d'allocation assigné s'est écoulé.

2. Si la tentative de commande ping de la passerelle par défaut échoue, le client en conclut qu'il a été déplacé vers un réseau ne disposant pas actuellement des services DHCP (un réseau domestique, par exemple) et procède à sa propre configuration de la manière décrite ci-dessus. Après avoir procédé à son autoconfiguration, il poursuit la tentative de localisation d'un serveur DHCP toutes les 5 minutes, en arrière-plan.

La prise en charge de la détection de support a été ajoutée à NDIS 5.0. Elle offre un mécanisme permettant à la carte réseau d'informer la pile de protocole des événements de connexion et de déconnexion du support. Windows 2000 TCP/IP utilise ces notifications pour assister la configuration automatique. Par exemple, dans Windows NT 4.0, lorsqu'un ordinateur portable était localisé et que DHCP était configuré sur un sous-réseau Ethernet, puis déplacé vers un autre sous-réseau sans réinitialisation, la pile de protocole ne recevait aucune indication du déplacement. Cela signifiait que les paramètres de configuration étaient périmés et qu'ils n'étaient pas significatifs pour le nouveau réseau. En outre, si l'ordinateur était éteint, qu'il était ramené à la maison et qu'il était redémarré, la pile de protocole n'était pas consciente que la carte réseau n'était plus connectée à un réseau, et là encore les paramètres de configuration périmés étaient conservés. Cette situation peut être problématique, étant donné que les itinéraires de sous-réseau, les passerelles par défaut, etc. peuvent entrer en conflit avec les paramètres d'accès à distance.

La prise en charge de la détection du support permet à la pile de protocole de réagir aux événements et d'invalider les paramètres périmés. Par exemple, si un ordinateur exécutant Windows 2000 est déconnecté du réseau (en supposant que la carte réseau prenne en charge la détection du support), après une période d'isolement implémentée dans la pile (généralement 3 secondes), TCP/IP invalide les paramètres associés au réseau qui a été déconnecté. La ou les adresses IP ne permettent plus les envois et tous les itinéraires associés à l'interface sont invalidés. Il est possible de visualiser l'état de la connexion réseau sur la barre des tâches en sélectionnant une connexion, en cliquant dessus avec le bouton droit de la souris, en cliquant sur Propriétés, puis en activant la case à cocher Afficher une icône dans la Barre des tâches une fois connecté. L'icône de connexion au réseau apparaît automatiquement avec un "X" rouge lorsque la carte présente un problème de connexion.

Si une application est liée à un socket qui utilise une adresse invalidée, elle doit traiter l'événement et restaurer correctement le système, en essayant par exemple d'utiliser une autre adresse IP sur le système ou en informant l'utilisateur de la déconnexion.

Client DNS de mise à jour dynamique

Windows 2000 inclut la prise en charge des mises à jour dynamiques de DNS, selon les indications de la RFC 2136. À chaque événement d'adresse (nouvelle adresse ou renouvellement), le client DHCP envoie l'option 81 et son nom complet au serveur DHCP, puis il demande au serveur DHCP d'inscrire, de sa part, un enregistrement RR PTR de ressource de pointeur DNS. Le client de mise à jour dynamique traite l'enregistrement A RR par lui-même. Ceci est dû au fait que seul le client connaît les adresses IP de l'hôte qui sont mappées sur ce nom. Le serveur DHCP n'est pas toujours en mesure de procéder correctement à l'enregistrement A RR, car il ne possède que des informations incomplètes. Le serveur DHCP peut toutefois être configuré pour ordonner au client de permettre au serveur d'inscrire les deux enregistrements avec le DNS. Les paramètres d'enregistrement associés au client DNS de mise à jour dynamique sont documentés à l'Annexe C.

Le serveur DHCP de Windows 2000 traite les requêtes de l'option 81 de la façon spécifiée dans le brouillon de la RFC9. Si un client DHCP Windows 2000 dialogue avec un serveur DHCP de niveau inférieur qui ne traite pas l'option 81, il enregistre lui-même un PTR RR. Le serveur DNS de Windows 2000 est en mesure de traiter les mises à jour dynamiques.

Les clients (non DHCP) configurés de façon statique enregistrent eux-mêmes le A RR et le PTR RR avec le serveur DNS.

Service cache de résolution DNS

Windows 2000 comporte un service de cache de résolution DNS qui est activé par défaut. Pour les besoins du dépannage, ce service peut être visualisé, arrêté et démarré comme tout autre service Windows. Le cache de résolution réduit le trafic réseau DNS et accélère la résolution de noms en fournissant un cache local pour les requêtes DNS. Les réponses aux requêtes de noms sont mises en cache pour le TTL spécifié dans la réponse (pour ne pas excéder la valeur spécifiée dans le paramètre MaxCacheEntryTtlLimit) et les requêtes à venir sont résolues à partir du cache dans la mesure du possible. Une fonction intéressante du service de cache de résolution DNS est la prise en charge de la mise en cache négative. Par exemple, si une requête est faite vers un serveur DNS pour un nom d'hôte donné et que la réponse est négative, les requêtes successives pour le même nom obtiennent une réponse (négative) du cache pendant NegativeCacheTime secondes (la valeur par défaut est de 300). Autre exemple de mise en cache négative : si tous les serveurs DNS sont interrogés et qu'aucun d'eux n'est disponible, pendant NetFailureCacheTime secondes (la valeur par défaut est de 30), toutes les requêtes suivantes échouent instantanément, au lieu d'expirer. Cette fonction peut économiser du temps pour les services qui interrogent le DNS durant la procédure d'amorçage, en particulier lorsque le client est initialisé à partir du réseau.

Le service cache de résolution DNS présente un certain nombre d'autres paramètres d'enregistrement réglables, qui sont documentés à l'Annexe C.

Outils et stratégies de dépannage TCP/IP

De nombreux outils de dépannage réseau sont disponibles pour Windows. La plupart sont inclus dans le produit ou dans le kit de ressources techniques de Windows 2000 Server. Le Moniteur réseau Microsoft est un excellent outil de traçage réseau. La version complète fait partie du produit Microsoft Systems Management Server, tandis qu'une version plus limitée est incluse dans le produit Windows 2000 Server.

Lors du dépannage d'un problème quelconque, il est utile d'adopter une approche logique. Voici quelques-unes des questions à poser :

• Qu'est-ce qui fonctionne ?

• Qu'est-ce qui ne fonctionne pas ?

• Quel lien existe entre les éléments qui fonctionnent et ceux qui ne fonctionnent pas ?

• Les éléments qui ne fonctionnent pas ont-ils jamais fonctionné sur cet ordinateur/réseau ?

• Dans ce cas, qu'est-ce qui a changé depuis le dernier fonctionnement ?

Le dépannage d'un problème de façon ascendante constitue souvent un bon moyen d'isoler rapidement le problème. Les outils indiqués ci-dessous sont conçus pour cette approche.

Outil IPConfig

IPConfig est un utilitaire de ligne de commande qui imprime la configuration liée à TCP/IP d'un hôte. En cas d'utilisation avec l'option /all, il génère un rapport de configuration détaillé pour toutes les interfaces, y compris les ports sériels configurés (RAS). La sortie peut être réacheminée vers un fichier et collé dans d'autres documents.

C:\>ipconfig /allWindows 2000 IP
    configuration:
     Host Name . . . . . . . . . . . . : DAVEMAC2
     Primary DNS Suffix . . . . . . . : mytest.microsoft.com
     Node Type . . . . . . . . . . . . : Hybrid
     IP Routing Enabled. . . . . . . . : No
     WINS Proxy Enabled. . . . . . . . : No
     DNS Suffix Search List. . . . . . : microsoft.com
    Ethernet adapter Local Area connexion 2:
     connexion-specific DNS Suffix . :
     Description . . . . . . . . . . . : 3Com EtherLink III EISA
    (3C579-TP)
     Physical Address. . . . . . . . . : 00-20-AF-1D-2B-91
     DHCP Enabled. . . . . . . . . . . : No
     Autoconfiguration Enabled . . . . : Yes
     IP Address. . . . . . . . . . . . : 10.57.8.190
     Subnet Mask . . . . . . . . . . . : 255.255.255.0
     Default Gateway . . . . . . . . . :
     DNS Servers . . . . . . . . . . . : 10.57.9.254
     Primary WINS Server . . . . . . . : 10.57.9.254
    Ethernet adapter Local Area connexion:
     connexion-specific DNS Suffix . :
     Description . . . . . . . . . . . : AMD Family PCI Ethernet
    Adapter
     Physical Address. . . . . . . . . : 00-80-5F-88-60-9A
     DHCP Enabled. . . . . . . . . . . : No
     IP Address. . . . . . . . . . . . : 199.199.40.22
     Autoconfiguration Enabled . . . . : Yes
     Subnet Mask . . . . . . . . . . . : 255.255.255.0
     Default Gateway . . . . . . . . . : 199.199.40.1
     DNS Servers . . . . . . . . . . . : 199.199.40.254
     Primary WINS Server . . . . . . . : 199.199.40.254

Outil ping

Ping est un outil qui aide à vérifier l'accessibilité au niveau IP. La commande ping peut être utilisée pour envoyer une requête d'écho ICMP vers un nom ou une adresse IP cible. Exécutez d'abord la commande ping sur l'adresse IP de l'hôte cible afin de voir s'il répond, car il s'agit du test le plus simple. En cas de succès, appliquez la commande ping sur le nom. Ping utilise la résolution de noms de type Windows Sockets pour résoudre le nom en une adresse ; par conséquent, si l'exécution de la commande ping réussit pour l'adresse et pas pour le nom, le problème se situe au niveau de la résolution du nom et non au niveau de la connectivité au réseau.

Tapez ping -? pour afficher les options de ligne de commande disponibles. Ping vous permet de spécifier la taille des paquets à utiliser, le nombre de paquets à envoyer, la nécessité ou non d'enregistrer la route utilisée, la valeur TLL à utiliser et la configuration ou non de l'indicateur Ne pas fragmenter. Consultez la section Découverte PMTU de ce document pour en savoir plus sur l'utilisation de la commande ping permettant de déterminer manuellement le PMTU entre deux ordinateurs.

L'exemple suivant illustre la modalité d'envoi de deux commandes ping, chacune d'une taille de 1450 octets, vers l'adresse 10.99.99.2 :

C:\>ping -n 2 -l 1450 10.99.99.2

Commande ping sur 10.99.990.2 avec 1450 octets de données :

Reply from 10.99.99.2: bytes=1450 time<10ms TTL=32
Reply from 10.99.99.2: bytes=1450 time<10ms TTL=32
    

Statistiques de la commande ping pour 10.99.990.2 :

Packets: Sent = 2, Received = 2, Lost = 0 (0%
    loss),

Temps de transmission aller-retour approximatif en millièmes de seconde :

Minimum = 0ms, Maximum = 0ms, Average = 0ms

Par défaut, la commande ping attend pendant une seconde le retour de chaque réponse avant l'expiration. Si le système distant soumis à la commande ping est connecté par le biais d'une liaison à retard élevé, telle qu'une liaison par satellite, les réponses peuvent nécessiter plus de temps pour être renvoyées. L'option -w (attente) peut être utilisée pour spécifier un temps d'attente plus long. Les ordinateurs qui utilisent IPSec peuvent nécessiter plusieurs secondes pour configurer une association de sécurité avant de répondre à une commande ping.

Outil PathPing

La commande Pathping est un outil de traçage de route qui combine les fonctions des commandes ping et tracert avec des informations supplémentaires qu'aucun de ces outils ne fournit. La commande Pathping envoie des paquets à chaque routeur sur l'itinéraire d'une destination finale pendant une période donnée, puis elle calcule les résultats en fonction des paquets renvoyés par chaque tronçon. Étant donné que la commande indique le degré de perte de paquets au niveau de n'importe quel routeur ou liaison, il est facile de déterminer les routeurs ou liaisons à l'origine des problèmes de réseau. Les options –R –T peuvent être utilisées avec Pathping pour déterminer si les périphériques du parcours sont compatibles 802.1p et s'ils reconnaissent RSVP.

L'exemple suivant illustre la sortie par défaut lors du traçage de la route vers le site www.sectur.gov.ar [200.1.247.2] sur un maximum de 30 tronçons.

0 warren.microsoft.com [163.15.2.217]
     1 tnt2.seattle2.wa.da.uu.net [206.115.150.106]
     2 206.115.169.217
     3 119.ATM1-0-0.HR2.SEA1.ALTER.NET [152.63.104.38]
     4 412.atm11-0.gw1.sea1.ALTER.NET [137.39.13.73]
     5 teleglobe2-gw.customer.ALTER.NET [157.130.177.222]
     6 if-0-3.core1.Seattle.Teleglobe.net [207.45.222.37]
     7 if-1-3.core1.Burnaby.Teleglobe.net [207.45.223.113]
     8 if-1-2.core1.Scarborough.Teleglobe.net
    [207.45.222.189]
     9 if-2-1.core1.Montreal.Teleglobe.net [207.45.222.121]
     10 if-3-1.core1.PennantPoint.Teleglobe.net
    [207.45.223.41]
     11 if-5-0-0.bb1.PennantPoint.Teleglobe.net
    [207.45.222.94]
     12 BOSQUE-aragorn.tecoint.net [200.43.189.230]
     13 ARAGORN-bosque.tecoint.net [200.43.189.229]
     14 GANDALF-aragorn.tecoint.net [200.43.189.225]
     15 Startel.tecoint.net [200.43.189.18]
     16 200.26.9.245
     17 200.26.9.26
     18 200.1.247.2

Calcul des statistiques pour 450 secondes :

Source to Here This Node/Link
    Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
     0 warren.microsoft.com [63.15.2.217]
     0/ 100 = 0% |
     1 115ms 0/ 100 = 0% 0/ 100 = 0% tnt2.seattle2.wa.da.uu.net
    [206.115.150.106]
     0/ 100 = 0% |
     2 121ms 0/ 100 = 0% 0/ 100 = 0% 206.115.169.217
     0/ 100 = 0% |
     3 122ms 0/ 100 = 0% 0/ 100 = 0% 119.ATM.ALTER.NET
    [152.63.104.38]
     0/ 100 = 0% |
     4 124ms 0/ 100 = 0% 0/ 100 = 0% 412.atm.sea1.ALTER.NET
    [137.39.13.73]
     0/ 100 = 0% |
     5 157ms 0/ 100 = 0% 0/ 100 = 0% teleglobe2-gw.ALTER.NET
    [157.130.177.222]
     0/ 100 = 0% |
     6 156ms 0/ 100 = 0% 0/ 100 = 0% if-0-3.Teleglobe.net
    [207.45.222.37]
     0/ 100 = 0% |
     7 198ms 0/ 100 = 0% 0/ 100 = 0% if-1-3.core1.Teleglobe.net
    [207.45.223.113]
     0/ 100 = 0% |
     8 216ms 0/ 100 = 0% 0/ 100 = 0% if-1-2.core1. Teleglobe.net
    [207.45.222.189]
     0/ 100 = 0% |
     9 207ms 0/ 100 = 0% 0/ 100 = 0% if-2-1.Teleglobe.net
    [207.45.222.121]
     0/ 100 = 0% |
     10 220ms 0/ 100 = 0% 0/ 100 = 0% if-3-1.core1.Teleglobe.net
    [207.45.223.41]
     0/ 100 = 0% |
     11 240ms 0/ 100 = 0% 0/ 100 = 0% if-5-0-0.bb1.Teleglobe.net
    [207.45.222.94]
     0/ 100 = 0% |
     12 423ms 1/ 100 = 1% 1/ 100 = 1% BOSQUE-aragorn.tecoint.net
    [200.43.189.230]
     0/ 100 = 0% |
     13 412ms 0/ 100 = 0% 0/ 100 = 0% ARAGORN-bosque.tecoint.net
    [200.43.189.229]
     0/ 100 = 0% |
     14 415ms 1/ 100 = 1% 1/ 100 = 1% GANDALF-aragorn.tecoint.net
    [200.43.189.225]
     0/ 100 = 0% |
     15 578ms 0/ 100 = 0% 0/ 100 = 0% Startel.tecoint.net
    [200.43.189.18]
     2/ 100 = 2% |
     16 735ms 2/ 100 = 2% 0/ 100 = 0% 200.26.9.245
     5/ 100 = 5% |
     17 1005ms 8/ 100 = 8% 1/ 100 = 1% 200.26.9.26
     0/ 100 = 0% |
     18 1089ms 7/ 100 = 7% 0/ 100 = 0% 200.1.247.2

Itinéraire déterminé

Lorsque la commande Pathping est exécutée, vous visualisez d'abord les résultats de l'itinéraire au fur et à mesure qu'il est testé à la recherche de problèmes. Il s'agit du même itinéraire que celui illustré par la commande tracert. La commande Pathping affiche ensuite un message d'occupation pour les 450 secondes suivantes (ce temps varie en fonction du nombre de tronçons). Pendant ce temps, Pathping recueille des informations auprès de tous les routeurs répertoriés précédemment et à partir des liaisons entre eux. Au terme de cette période, il affiche les résultats du test.

Les deux colonnes à l'extrême droite (This Node/Link Lost/Sent=Pct et Address) contiennent les informations les plus utiles. La liaison entre 200.26.9.245 (tronçon 16) et 200.26.9.26 (tronçon 17) perd 8 % des paquets.

Les taux de perte affichés pour les liaisons (indiqués par une barre oblique | dans la colonne à l'extrême droite) indiquent les pertes de paquets tout au long du parcours. Cette perte indique un encombrement de la liaison. Les taux de perte affichés pour les routeurs (indiqués par leurs adresses IP dans la colonne à l'extrême droite) indiquent que les processeurs de ces routeurs sont peut-être surchargés. Les routeurs encombrés peuvent également être un facteur déterminant dans les problèmes entre terminaux.

Outil Arp

La commande arp est utile pour visualiser le cache ARP. Si deux hôtes du même sous-réseau ne peuvent exécuter avec succès la commande ping l'un vers l'autre, essayez d'exécuter la commande arp -a sur chaque ordinateur afin de déterminer si, sur les deux ordinateurs, les adresses MAC répertoriées pour l'autre ordinateur sont correctes. Utilisez la commande IPConfig pour déterminer l'adresse de contrôle d'accès du support d'un hôte. Si un autre hôte avec une adresse IP dupliquée existe sur le réseau, cela peut signifier que le cache ARP comporte l'adresse MAC de l'autre ordinateur. Utilisez la commande arp -d pour supprimer une entrée qui pourrait être incorrecte. Ajoutez des entrées à l'aide de la commande arp -s.

Outil Tracert

Tracert est un utilitaire de traçage d'itinéraire. Tracert utilise le champ TTL IP et les messages d'erreur ICMP pour déterminer l'itinéraire d'un hôte à l'autre sur un réseau. Un exemple de résultat obtenu à partir de la commande tracert est présenté dans la section ICMP de ce document.

Outil Route

Route permet de visualiser ou de modifier la table d'itinéraires. Route print affiche une liste d'itinéraires courants de l'hôte, connus par le protocole IP. Un exemple du résultat obtenu est présenté dans la section IP de ce document. Remarquez que dans Windows 2000, la passerelle actuellement active par défaut est répertoriée à la fin de la liste des itinéraires. Route add ajoute des itinéraires à la table. Route delete supprime des itinéraires de la table.

Les itinéraires ajoutés à la table ne sont pas rendus permanents, à moins que l'option -p ne soit spécifiée. Les itinéraires non permanents ne durent que jusqu'au redémarrage de l'ordinateur.

Pour que deux hôtes échangent des datagrammes IP, ils doivent tous deux posséder un itinéraire les reliant ou ils doivent utiliser une passerelle par défaut connaissant un itinéraire. Les routeurs utilisent normalement un protocole tel que RIP (Routing Information Protocol) ou OSPF (Open Shortest Path First) pour échanger des informations. Le protocole RIP silencieux est disponible pour Windows 2000 Professionnel et les protocoles de routage complet sont pris en charge par Windows 2000 Server dans le service de routage et d'accès distant.

Netstat

Netstat affiche les statistiques de protocole et les connexions TCP/IP actuelles. Netstat -a affiche toutes les connexions et netstat -r affiche la table d'itinéraires ainsi que toutes les connexions actives. L'option -n indique à netstat de ne pas convertir les adresses et les numéros de port en noms, ce qui accélère l'exécution. L'option -e affiche les statistiques Ethernet et peut être combinée à l'option -s, laquelle affiche les statistiques de protocole. Un exemple de résultat est présenté ici :

C:\>netstat -e

Statistiques de l'interface :

Received Sent
    Bytes 372959625 123567086
    Unicast packets 134302 145204
    Non-unicast packets 55937 886
    Discards 0 0
    Errors 0 0
    Unknown protocols 1757381
    C:\>netstat -an

Connexions actives :

Proto Local Address Foreign Address State
     TCP 0.0.0.0:42 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:88 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:389 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:593 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:1038 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:1041 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:1048 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:1054 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:1077 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:1080 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:1088 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:1092 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:1723 0.0.0.0:0 LISTENING
     TCP 0.0.0.0:3268 0.0.0.0:0 LISTENING
     TCP 10.99.99.1:53 0.0.0.0:0 LISTENING
     TCP 10.99.99.1:139 0.0.0.0:0 LISTENING
     TCP 10.99.99.1:389 10.99.99.1:1092 ESTABLISHED
     TCP 10.99.99.1:1092 10.99.99.1:389 ESTABLISHED
     TCP 10.99.99.1:3604 10.99.99.1:135 TIME_WAIT
     TCP 10.99.99.1:3605 10.99.99.1:1077 TIME_WAIT
     UDP 0.0.0.0:42 *:*
     UDP 0.0.0.0:88 *:*
     UDP 0.0.0.0:123 *:*
     UDP 0.0.0.0:135 *:*
     UDP 0.0.0.0:389 *:*
     UDP 0.0.0.0:445 *:*
     UDP 0.0.0.0:1073 *:*
     UDP 0.0.0.0:1076 *:*
     UDP 0.0.0.0:1087 *:*
     UDP 10.99.99.1:53 *:*
     UDP 10.99.99.1:67 *:*
     UDP 10.99.99.1:137 *:*
     UDP 10.99.99.1:138 *:*
     UDP 127.0.0.1:1052 *:*
    D:\>netstat -s

Statistiques IP :

Packets Received = 3175996
     Received Header Errors = 0
     Received Address Errors = 38054
     Datagrams Forwarded = 0
     Unknown Protocols Received = 0
     Received Packets Discarded = 0
     Received Packets Delivered = 3142564
     Output Requests = 3523906
     Routing Discards = 0
     Discarded Output Packets = 0
     Output Packet No Route = 0
     Reassembly Required = 0
     Reassembly Successful = 0
     Reassembly Failures = 0
     Datagrams Successfully Fragmented = 0
     Datagrams Failing Fragmentation = 0
     Fragments Created = 0

Statistiques ICMP :

Received Sent
     Messages 462 33
     Errors 0 0
     Destination Unreachable 392 4
     Time Exceeded 0 0
     Parameter Problems 0 0
     Source Quenchs 0 0
     Redirects 0 0
     Echos 1 22
     Echo Replies 12 1
     Timestamps 0 0
     Timestamp Replies 0 0
     Address Masks 0 0
     Address Mask Replies 0 0

Statistiques TCP :

Active Opens = 12164
     Passive Opens = 12
     Failed connexion Attempts = 79
     Reset connexions = 11923
     Current connexions = 1
     Segments Received = 2970519
     Segments Sent = 3505992
     Segments Retransmitted = 18

Statistiques UDP :

Datagrams Received = 155620
     No Ports = 16578
     Receive Errors = 0
     Datagrams Sent = 17822

Outil NBTStat

NBTStat est un outil utile pour le dépannage des problèmes de résolution de noms NetBIOS. NBTStat -n affiche les noms que les applications, telles que le serveur et le redirecteur, enregistrent localement sur le système. NBTStat -c montre le cache de nom NetBIOS, qui contient les correspondances entre nom et adresse pour les autres ordinateurs. NBTStat -R vide le cache de nom et le recharge à partir du fichier Lmhosts. NBTStat –RR (nouveau dans Windows 2000 et NT 4.0 SP5) ré-enregistre tous les noms avec le serveur de noms. NBTStat -a name exécute une commande d'état de la carte NetBIOS contre l'ordinateur qui est spécifié par name. La commande d'état de la carte renvoie la table de noms NetBIOS locale de cet ordinateur ainsi que l'adresse MAC de la carte. NBTStat -s répertorie les sessions NetBIOS actuelles ainsi que leur état, y compris les statistiques.

Outil Nslookup

Nslookup, nouveauté de Windows NT 4.0, est un outil utile permettant de résoudre les problèmes de DNS, tels que ceux qui touchent à la résolution de noms d'hôte. Lors du démarrage de la commande nslookup, elle affiche le nom d'hôte et l'adresse IP du serveur DNS qui est configuré pour le système local, puis elle affiche une invite de commande. Si vous tapez un point d'interrogation (?), nslookup affiche les différentes commandes disponibles.

Pour examiner les adresses IP d'un hôte, à l'aide du DNS, tapez le nom de l'hôte et appuyez sur Entrée. Nslookup se concentre par défaut sur le serveur DNS qui est configuré pour l'ordinateur sur lequel il s'exécute, mais vous pouvez le focaliser sur un autre serveur DNS en tapant server nom (nom étant le nom d'hôte du serveur que vous souhaitez utiliser pour les recherches futures).

Lors de l'utilisation de Nslookup, vous devez connaître la méthode d'attribution du nom de domaine. Si vous saisissez uniquement un nom hôte et que vous appuyez sur Entrée, nslookup ajoute le suffixe du domaine de l'ordinateur (tel que cswatcp.microsoft.com) au nom de l'hôte avant d'interroger le DNS. Si le nom est introuvable, le suffixe de domaine est attribué par une étiquette (dans ce cas, cswatcp est supprimé et le suffixe devient microsoft.com). La requête est ensuite répétée. Les ordinateurs Windows 2000 assignent uniquement des noms au domaine de second niveau (microsoft.com dans cet exemple) ; de cette façon, si la requête échoue, aucune autre tentative ne sera effectuée pour résoudre le nom. Si un nom de domaine complet est saisi (indiqué par un point final), le serveur DNS est uniquement interrogé pour ce nom et aucune assignation n'est effectuée. Pour rechercher un nom d'hôte se trouvant complètement à l'extérieur de votre domaine, vous devez saisir un nom complet.

Le mode de débogage est une fonction de dépannage particulièrement utile, que vous pouvez utiliser en tapant set debug (ou set d2 pour obtenir encore plus de détails). En mode débogage, nslookup répertorie les étapes permettant l'exécution de ses commandes, comme le montre l'exemple ci-après :

C:\>nslookup
    (null) davemac3.cswatcp.microsoft.com
    Address: 10.57.8.190
    > set d2
    > rain-city
    (null) davemac3.cswatcp.microsoft.com
    Address: 10.57.8.190
    ------------
    SendRequest(), len 49
     HEADER:
     opcode = QUERY, id = 2, rcode = NOERROR
     header flags: query, want recursion
     questions = 1, answers = 0, authority records = 0, additional
    = 0
     QUESTIONS:
     rain-city.cswatcp.microsoft.com, type = A, class = IN
    ------------
    Got answer (108 bytes):
     HEADER:
     opcode = QUERY, id = 2, rcode = NOERROR
     header flags: response, auth. answer, want recursion,
    recursion avail.
     questions = 1, answers = 2, authority records = 0, additional
    = 0
     QUESTIONS:
     rain-city.cswatcp.microsoft.com, type = A, class = IN
     ANSWERS:
     -> rain-city.cswatcp.microsoft.com
     type = CNAME, class = IN, dlen = 31
     canonical name = seattle.cswatcp.microsoft.com
     ttl = 86400 (1 day)
     -> seattle.cswatcp.microsoft.com
     type = A, class = IN, dlen = 4
     internet address = 10.1.2.3
     ttl = 86400 (1 day)
    ------------
    (null) seattle.cswatcp.microsoft.com
    Address: 10.1.2.3
    Aliases: rain-city.cswatcp.microsoft.com

Dans cet exemple, la commande set d2 a été exécutée pour configurer nslookup en mode débogage, puis la recherche d'adresse a été utilisée pour le nom d'hôterain-city. Les deux premières lignes du résultat affichent le nom de l'hôte et l'adresse IP du serveur DNS auquel la recherche était destinée. Comme illustré dans le paragraphe suivant, le suffixe de domaine de la machine locale (cswatcp.microsoft.com) a été ajouté au nom rain-city et nslookup a envoyé cette question au serveur DNS. Le paragraphe suivant montre que nslookup a reçu une réponse du DNS et que la question unique a généré deux enregistrements de réponse. La question est répétée dans la réponse avec les deux enregistrements de réponse. Dans ce cas, la première réponse indique que le nom rain-city.cswatcp.microsoft.com est en réalité un nom canonique (alias, ou cname) du nom d'hôte seattle.cswatcp.microsoft.com. Le deuxième enregistrement de réponse indique l'adresse IP de cet hôte, à savoir 10.1.2.3.

Moniteur réseau Microsoft

Le Moniteur réseau Microsoft est un outil développé par Microsoft qui permet de simplifier et de diminuer les coûts liés aux opérations de dépannage des problèmes réseau complexes. Cet outil fait partie du produit Microsoft Systems Management Server, mais il peut également être utilisé en tant que moniteur réseau autonome. De plus, Windows NT et Windows 95 comportent le logiciel Agent du moniteur réseau et en outre, Windows NT Server et Windows 2000 incluent une version limitée du Moniteur réseau. Les postes qui exécutent le Moniteur réseau ont la possibilité de se connecter aux postes qui exécutent le logiciel agent, par le biais du réseau ou au moyen d'un accès à distance, afin de procéder au contrôle ou au traçage des segments réseau distants. Ceci peut se révéler un outil de dépannage extrêmement utile.

Le Moniteur réseau fonctionne en plaçant la carte réseau sur l'hôte de saisie en mode de proximité, de sorte qu'il puisse transmettre à l'instrument de traçage toutes les trames qui passent sur la liaison. (La version limitée du Moniteur réseau livrée avec Windows 2000 Server permet uniquement le traçage du trafic entrant et sortant de l'ordinateur.) Les filtres de capture peuvent être définis de manière à ne sauvegarder que certaines trames pour l'analyse. Les filtres peuvent être définis sur la base des adresses de carte réseau source et de destination, des adresses de protocole source et de destination, ainsi que des correspondances de modèle. Une fois les trames capturées, le filtrage de l'affichage peut être utilisé pour mieux cibler le problème. Le filtrage de l'affichage permet également la sélection de protocoles spécifiques.

Les ordinateurs Windows NT utilisent le protocole SMB (Server Message Block) pour plusieurs fonctions, telles que le partage de fichiers et d'impression. Le fichier smb.hlp du répertoire d'analyse Netmon est une bonne référence pour l'interprétation de ce protocole.

MinimumFreeLowerConnections

NameServerPort

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : numéro de port UDP

Plage valide : 0–0xFFFF

Par défaut : 0x89

Description : ce paramètre indique le numéro du port de destination auquel NetBT envoie au serveur WINS des paquets liés à un service de nom, tels que les requêtes de nom ou les enregistrements de nom. Le serveur Microsoft WINS est à l'écoute sur le port 0x89 (138 décimal). Les serveurs de noms NetBIOS d'autres fournisseurs peuvent être à l'écoute sur des ports différents.

NameSrvQueryCount

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : nombre

Plage valide : 0–0xFFFF

Par défaut : 3

Description : cette valeur détermine le nombre de fois que NetBT envoie une demande de nom spécifique à un serveur WINS sans recevoir de réponse.

NameSrvQueryTimeout

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : durée en millièmes de seconde

Plage valide : 100–0xFFFFFFFF

Par défaut : 1500 (1,5 secondes)

Description : cette valeur détermine l'intervalle de temps entre deux demandes successives d'un nom spécifique à WINS.

NodeType

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : nombre

Plage valide : 1, 2, 4, 8 (nœud-b, nœud-p, nœud-m, nœud-h)

Par défaut : 1 ou 8, selon la configuration du serveur WINS

Description : ce paramètre détermine la méthode utilisée par NetBT pour enregistrer et résoudre les noms. Un système nœud-b emploie les diffusions. Un système nœud-p utilise uniquement les requêtes de nom point-à-point vers un serveur de noms (WINS). Un système nœud-m utilise d'abord les diffusions, puis il interroge le serveur de noms. Un système nœud-h interroge d'abord le serveur de noms, puis il envoie des diffusions. La résolution par Lmhosts et DNS, quand elle est activée, utilise ces méthodes. Si cette clé est présente, elle remplace la clé DhcpNodeType. Si aucune des clés n'est présente, le système devient nœud-b par défaut lorsqu'aucun serveur WINS n'est configuré pour le client. Le système devient nœud-h par défaut si au moins un serveur WINS a été configuré.

NoNameReleaseOnDemand

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0 (faux)

Description : ce paramètre détermine si l'ordinateur publie son nom NetBIOS lorsqu'il reçoit une requête de publication de nom provenant du réseau. Il a été ajouté pour permettre à l'administrateur de protéger la machine des attaques destinées à découvrir les noms.

RandomAdapter

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0 (faux)

Description : ce paramètre s'applique uniquement aux hôtes multi-hébergement. S'il est configuré sur 1 (vrai), NetBT choisit de façon aléatoire l'adresse IP à placer dans une réponse à une requête de nom à partir de toutes les interfaces auxquelles il est lié. Normalement, la réponse contient l'adresse de l'interface qui a reçu la requête. Cette fonctionnalité serait utilisée pour équilibrer la charge sur un serveur avec deux interfaces sur le même réseau.

RefreshOpCode

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : nombre

Plage valide : 8, 9

Par défaut : 8

Description : ce paramètre force NetBT à utiliser un champ opcode spécifique dans les paquets de rafraîchissement des noms. La spécification du protocole NetBT est assez ambiguë dans ce domaine. Bien que la valeur 8 par défaut utilisée par les implémentations Microsoft semble être la valeur prévue, d'autres implémentations, telles que celles de Ungermann-Bass, adoptent la valeur 9. Deux implémentations doivent utiliser le même champ opcode pour pouvoir fonctionner ensemble.

ScopeId

Clé : Netbt\Parameters

Type de valeur : REG_SZ : chaîne de caractères

Plage valide : tout nom de domaine DNS valide constitué d'un astérisque (*) ou de deux parties séparées par un point.

Par défaut : aucune

Description : ce paramètre spécifie la portée du nom NetBIOS au niveau du nœud. Cette valeur ne doit pas commencer par un point. Si ce paramètre contient une valeur valide, celle-ci remplace le paramètre DHCP du même nom. Une valeur vierge (chaîne vide) est ignorée. La configuration de ce paramètre sur la valeur "*" indique une portée nulle et remplace le paramètre DHCP.

SessionKeepAlive

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : durée en millièmes de seconde

Plage valide : 60 000–0xFFFFFFFF

Par défaut : 3 600 000 (1 heure)

Description : cette valeur détermine l'intervalle de temps entre les transmissions de maintien d'activité sur une session. Si cette valeur est configurée sur 0xFFFFFFF, les maintiens d'activité sont désactivés.

SingleResponse

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0 (faux)

Description : ce paramètre s'applique uniquement aux hôtes multi-hébergement. Si ce paramètre est configuré sur 1 (vrai), NetBT fournit, dans ses réponses aux demandes de nom, uniquement l'adresse IP de l'une des interfaces auxquelles il est lié. Les adresses de toutes les interfaces liées sont incluses par défaut.

Size/Small/Medium/Large

Clé : Netbt\Parameters

Type de valeur : REG_DWORD

Plage valide : 1, 2, 3 (petit, moyen, grand)

Par défaut : 1 (petit)

Description : cette valeur détermine la taille des tables de noms utilisées pour stocker les noms locaux et distants. En général, une valeur de 1 (petit) est appropriée. Si le système agit en tant que serveur de noms proxy, la valeur est automatiquement configurée sur 3 (grand) afin d'augmenter la taille de la table de hachage du cache de nom. Les compartiments de la table de hachage sont dimensionnés comme suit :

• Petit : 16

• Moyen : 128

• Grand : 256

SMBDeviceEnabled

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 1 (vrai)

Description : Windows 2000 prend en charge un nouveau protocole de transport réseau appelé Périphérique SMB, activé par défaut. Ce paramètre permet de désactiver le périphérique SMB pour le dépannage. Consultez la section "Améliorations de NetBT Internet/DNS et périphérique SMB" de ce livre pour en savoir plus.

TryAllNameServers

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0 (faux)

Description : ce paramètre détermine si le client continue de demander des serveurs de noms supplémentaires dans la liste des serveurs configurés lors de l'échec d'une requête d'établissement de session NetBIOS vers une des adresses IP. Si ce paramètre est activé, des tentatives sont effectuées pour interroger tous les serveurs WINS de la liste et pour se connecter à toutes les adresses IP fournies avant l'échec de la requête de l'utilisateur.

TryAllIPAddrs

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 1 (vrai)

Description : quand un serveur WINS renvoie une liste d'adresses IP en réponse à une requête de nom, la liste est classée par ordre de préférence, la préférence étant donnée aux adresses qui se trouvent sur le même sous-réseau qu'une interface appartenant au client. Ce paramètre détermine si le client exécute une commande ping sur les adresses IP de la liste et s'il tente de se connecter à la première adresse qui répond, ou bien s'il essaie de se connecter à la première adresse IP de la liste (ordonnée) et s'il échoue en cas d'échec de la tentative de connexion. Par défaut, le client exécute une commande ping sur chaque adresse de la liste et tente de se connecter à la première qui répond.

UseDnsOnlyForNameResolutions

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0 (faux)

Description : ce paramètre permet de désactiver toutes les requêtes de nom NetBIOS. Les enregistrements et les réactualisations de noms NetBIOS sont toujours utilisés et les sessions NetBIOS sont toujours autorisées. Pour désactiver complètement NetBIOS sur une interface, voir le paramètre NetbiosOptions.

WinsDownTimeout

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : durée en millièmes de seconde

Plage valide : 1000–0xFFFFFFFF

Par défaut : 15 000 (15 secondes)

Description : ce paramètre détermine la durée pendant laquelle NetBIOS attend avant d'essayer d'utiliser de nouveau WINS après l'impossibilité de contacter un serveur WINS. Cette fonctionnalité permet essentiellement aux ordinateurs qui sont temporairement déconnectés du réseau, comme les portables, de procéder au redémarrage sans attendre la fin des délais des requêtes ou enregistrements de nom WINS individuels.

Paramètres configurables à partir de l'interface utilisateur Connexions

Les paramètres suivants peuvent être configurés à l'aide de l'outil Réseau du Panneau de configuration (NCPA). Il n'est en principe pas nécessaire de les configurer directement.

EnableLmhosts

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 1 (vrai)

Description : si cette valeur est configurée sur 1 (vrai), NetBT recherche dans le fichier Lmhosts, s'il existe, des noms qui ne peuvent pas être résolus par WINS ou par la diffusion. Par défaut, il n'existe aucun répertoire de base de données contenant le fichier Lmhosts (spécifié par Tcpip\Parameters\DatabasePath) ; par conséquent aucune action n'est entreprise. Cette valeur est écrite par la boîte de dialogue Advanced TCP/IP Configuration de l'outil NCPA.

EnableProxy

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0 (faux)

Description : si cette valeur est configurée sur 1 (vrai), le système se comporte comme serveur de noms proxy pour les réseaux auxquels NetBT est lié. Un serveur de noms proxy répond aux demandes de diffusion des noms qu'il a résolus à l'aide de WINS. Un serveur de noms proxy permet à un réseau d'implémentations nœud-b de se connecter à des serveurs sur d'autres sous-réseaux qui sont enregistrés avec WINS.

NameServerList

Clé : Netbt\Parameters\Interfaces\interface

Type de valeur : REG_MULTI_SZ : adresse IP décimale avec des points, séparée par des espaces (c'est-à-dire, 10.101.1.200)

Plage valide : toute liste d'adresses IP valides du serveur WINS.

Par défaut : vide (aucune adresse)

Description : ce paramètre spécifie les adresses IP de la liste des serveurs WINS configurés pour l'ordinateur. Si ce paramètre contient une valeur valide, il remplace le paramètre DHCP du même nom. Ce paramètre remplace les paramètres Windows NT 4.0 NameServer et NameServerBackup, qui ne sont plus utilisés.

NetbiosOptions

Clé : Netbt\Parameters\Interfaces\interface

Type de valeur : REG_DWORD : nombre

Plage valide : 1, 2

Par défaut : 1

Description : ce paramètre détermine si NetBIOS est activé carte par carte. Dans le menu Démarrer, pointez sur Paramètres, puis cliquez sur Connexion réseau et accès à distance. Cliquez avec le bouton droit sur Connexion au réseau local, puis cliquez sur Propriétés. Sélectionnez Protocole Internet (TCP/IP), cliquez sur Propriétés, puis sur Avancé. Sélectionnez l'onglet WINS. Les options NetBIOS sont Activer NetBIOS avec TCP/IP, Désactiver NetBIOS avec TCP/IP ouUtiliser le paramètre NetBIOS du serveur DHCP, qui est l'option par défaut. Quand il est activé, sa valeur est 1 ; lorsqu'il est désactivé, sa valeur est 2. Si cette clé n'existe pas, la clé DHCPNetbiosOptions est lue. Si cette clé existe, la clé DHCPNetbiosOptions est ignorée.

Paramètres non configurables

Les paramètres qui suivent sont créés et utilisés en interne par les composants NetBT. Ils ne doivent jamais être modifiés par le biais de l'Éditeur du Registre, car cela pourrait rendre le composant instable. Ils sont indiqués ici uniquement à titre de référence.

DHCPNameServerList

Clé : Netbt\Parameters\Interfaces\interface

Type de valeur : REG_MULTI_SZ : adresse IP décimale avec des points, séparée par des espaces (c'est-à-dire, 10.101.1.200)

Plage valide : toute liste d'adresses IP valides du serveur WINS.

Par défaut : vide (aucune adresse)

Description : ce paramètre spécifie les adresses IP de la liste des serveurs WINS, telle qu'elle est fournie par le service DHCP. Il remplace les paramètres Windows NT 4.0 DHCPNameServer et DHCPNameServerBackup, qui ne sont plus utilisés. Voir aussi NameServerList, qui remplace ce paramètre s'il est présent.

DHCPNetbiosOptions

Clé : Netbt\Parameters\Interfaces\interface

Type de valeur : REG_DWORD : nombre

Plage valide : 1, 2

Par défaut : 1

Description : ce paramètre est écrit par le service client DHCP. Voir le paramètre NetbiosOptions pour en savoir plus.

DhcpNodeType

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : nombre

Plage valide : 1–8

Par défaut : 1

Description : ce paramètre spécifie le type de nœud NetBT. Il est écrit par le service client DHCP, s'il est activé. Une valeur valide de NodeType remplace ce paramètre. Voir l'entrée NodeType pour avoir une description complète.

DhcpScopeId

Clé : Netbt\Parameters

Type de valeur : REG_SZ : chaîne de caractères

Plage valide : une chaîne de nom séparée par des points, comme par exemple microsoft.com

Par défaut : aucune

Description : ce paramètre indique la portée du nom NetBIOS au niveau du nœud. Il est écrit par le service client DHCP, s'il est activé. Cette valeur ne doit pas commencer par un point. Voir le paramètre ScopeId pour en savoir plus.

NbProvider

Clé : Netbt\Parameters

Type de valeur : REG_SZ : chaîne de caractères

Plage valide : _tcp

Par défaut : _tcp

Description : ce paramètre est utilisé en interne par le composant RPC. La valeur par défaut ne doit pas être modifiée.

TransportBindName

Clé : Netbt\Parameters

Type de valeur : REG_SZ : chaîne de caractères

Plage valide : S/O

Par défaut : \Device\

Description : ce paramètre est utilisé en interne au cours du développement du produit. La valeur par défaut ne doit pas être modifiée.

Annexe C : paramètres de registre Windows Sockets et DNS

Paramètres de registre AFD

Afd.sys est le pilote en mode noyau utilisé pour la prise en charge des applications Windows Sockets. Lorsqu'il y a trois valeurs par défaut, la valeur définitive est calculée à partir de la quantité de mémoire détectée dans le système :

• La première valeur est la valeur par défaut pour les ordinateurs plus petits (moins de 19 Mo).

• La deuxième valeur est la valeur par défaut pour les ordinateurs moyens (<32 Mo sur Windows 2000 Professionnel, <64 Mo sur Windows 2000 Server).

• La troisième valeur est la valeur par défaut pour les grands ordinateurs (>32 Mo sur Windows 2000 Professionnel, >64 Mo sur Windows 2000 Server).

Par exemple, si la valeur par défaut est donnée sous la forme 0/2/10, un système contenant de 12,5 à 20 Mo de RAM aurait une valeur par défaut de 2.

Les valeurs suivantes peuvent être définies sous :

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Afd \Parameters:

DefaultReceiveWindow

Type de valeur : REG_DWORD

Par défaut : 4096/8192/8192

Description : e nombre d'octets reçus que AFD met en mémoire tampon sur une connexion avant d'imposer le contrôle de flux. Pour certaines applications, une valeur plus grande améliore légèrement les performances aux dépens d'une utilisation plus importante des ressources. Les applications peuvent modifier cette valeur pour chaque socket grâce à l'option de socket SO_RCVBUF.

DefaultSendWindow

Type de valeur : REG_DWORD

Par défaut : 4096/8192/8192

Description : emblable à DefaultReceiveWindow, mais pour le côté envoi de la connexion.

DisableAddressSharing

Type de valeur : REG_DWORD

Par défaut : 0

Plage : 0, 1

Description : e paramètre permet d'éviter le partage d'adresses (SO_REUSEADDR) entre processus, de sorte que si un processus ouvre un socket, aucun autre ne peut lui emprunter des données. Un effet similaire peut être obtenu lorsqu'une application utilise la nouvelle option de socket SO_EXCLUSIVEADDRUSE. Grâce à ce paramètre, les administrateurs peuvent sécuriser les applications plus anciennes qui ne reconnaissent pas cette option.

DisableRawSecurity

Type de valeur : REG_DWORD

Par défaut : 0

Plage : 0, 1

Description : désactive le contrôle des privilèges administratifs lors d'une tentative d'ouverture d'un socket brut. Il n'est pas utilisé pour les protocoles de transport Windows 2000 (tels que TCP/IP, qui gère sa propre sécurité pour les sockets bruts) ; ceux-ci configurent le paramètre TDI_SERVICE_FORCE_ACCESS_CHECK. Voir le paramètre de registre TCP/IP AllowUserRawAccess.

DynamicBacklogGrowthDelta

Type de valeur : REG_DWORD

Plage valide : 0–0xFFFFFFFF

Par défaut : 0

Description : contrôle le nombre de connexions libres à créer lorsque des connexions supplémentaires sont requises. Prenez garde, car une valeur trop importante peut entraîner une augmentation considérable du nombre d'allocations de connexion libres. (Bien que ce paramètre existe toujours, la pile TCP elle-même a été renforcée contre les attaques SYN-ATTACK dans Windows 2000 ; par conséquent, il n'est a priori pas nécessaire d'utiliser cette fonctionnalité de AFD.)

FastCopyReceiveThreshold

Type de valeur : REG_DWORD

Par défaut : 1024

Description : lorsqu'une application publie une réception avec un tampon plus petit que le paquet actuel à mémoriser par Winsock, AFD peut soit faire une copie supplémentaire du paquet, puis copier les données directement sur les tampons de l'application (ce qui implique une copie en deux phases, car les tampons des applications ne sont pas directement accessibles sous le verrou), soit verrouiller et mapper les tampons de l'application, puis copier les données une fois seulement. Cette valeur représente un compromis entre l'exécution de code supplémentaire pour la copie de données et l'exécution de code supplémentaire dans le sous-système d'E/S et le gestionnaire de la mémoire. La valeur par défaut a été qualifiée, par des tests, comme étant la meilleure du point de vue des performances. La modification de cette valeur est généralement déconseillée.

FastSendDatagramThreshold

Type de valeur : REG_DWORD

Par défaut : 1024

Description : les datagrammes plus petits que la valeur de ce paramètre passent par le chemin d'E/S rapide ou sont mis en mémoire tampon lors de l'envoi. Les plus grands sont conservés jusqu'à ce que le datagramme soit effectivement envoyé. La valeur par défaut a été qualifiée, par des tests, comme étant la meilleure du point de vue des performances. Par E/S rapide, on entend la copie des données et le contournement du sous-système d'E/S, plutôt que le mappage de la mémoire et le passage par le sous-système d'E/S. Ceci est avantageux pour les petites quantités de données. La modification de cette valeur est généralement déconseillée.

IgnorePushBitOnReceives

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0 (faux)

Description : normalement, Windows 2000 effectue une opération de réception Windows Socket lorsqu'une de ces conditions est vérifiée :

• les données arrivent avec le bit PUSH configuré ;

• la mémoire tampon utilisateur recv est pleine ;

• 0,5 secondes se sont écoulées depuis l'arrivée des dernières données.

Quand ce paramètre est configuré sur 1, Afd.sys traite tous les paquets entrants comme si le bit push était configuré. Ceci ne doit se faire que lorsqu'il est nécessaire de contourner les implémentations client TCP/IP qui ne gèrent pas correctement les données de type push.

IrpStackSize

Type de valeur : REG_DWORD

Plage valide : 1–255

Par défaut : 4

Description : le nombre des emplacements de pile IRP utilisés par défaut pour AFD. La modification de cette valeur est déconseillée.

LargeBufferSize

Type de valeur : REG_DWORD

Par défaut : PAGE_SIZE (4096 octets sur processeur i386, 8192 octets sur processeur Alpha)

Description : la taille, en octets, des grands tampons utilisés par AFD. Les valeurs inférieures utilisent moins de mémoire et les valeurs supérieures peuvent améliorer les performances.

LargeBufferListDepth

Type de valeur : REG_DWORD

Par défaut : 0/2/10

Description : taille de la liste look-aside des tampons de grande taille.

MaxActiveTransmitFileCount

Type de valeur : REG_DWORD

Plage valide : 0–0xffff (serveur), 2 (station de travail)

Par défaut : 0 (serveur), 2 (station de travail)

Description : permet de configurer le nombre maximal de requêtes TransmitFile simultanées en instance. La valeur 0 signifie que le nombre n'est limité que par les ressources du système. Cette valeur n'est pas configurable dans Windows 2000 Professionnel.

MaxFastTransmit

Type de valeur : REG_DWORD

Plage valide : 0–0xffffffff

Par défaut : 64 ko

Description : ce paramètre détermine la quantité maximale de données transférées dans une requête TransmitFile sur chemin rapide. Par E/S rapide, on entend essentiellement la copie des données et le contournement du sous-système d'E/S, plutôt que le mappage de la mémoire et le passage par le sous-système d'E/S. Ceci est avantageux pour les petites quantités de données. La modification de cette valeur est généralement déconseillée.

MaxFastCopyTransmit

Type de valeur : REG_DWORD

Plage valide : 0–0xFFFFFFFF

Par défaut : 128

Description : ce paramètre contrôle la taille maximale des données qui utilisent la copie plutôt que la mémoire cache sur chemin rapide. Par E/S rapide, on entend essentiellement la copie des données et le contournement du sous-système d'E/S, plutôt que le mappage de la mémoire et le passage par le sous-système d'E/S. Ceci est avantageux pour les petites quantités de données. La modification de cette valeur est généralement déconseillée.

MediumBufferSize

Type de valeur : REG_DWORD

Par défaut : 1504

Description : taille, en octets, des tampons moyens utilisés par AFD.

MediumBufferListDepth

Type de valeur : REG_DWORD

Par défaut : 4/8/24

Description : taille de la liste look-aside des tampons de taille moyenne.

OverheadChargeGranularity

Type de valeur : REG_DWORD

Par défaut : 1 page

Plage valide : une puissance de 2

Description : ce paramètre détermine selon quels incréments la surcharge est effectivement obtenue. La valeur par défaut est d'une page et l'intention est d'obtenir une charge correcte et de contenir les applications de type attaque, qui tentent de saturer la mémoire du système.

PriorityBoost

Type de valeur : REG_DWORD

Par défaut : 2

Plage valide : 0–16

Description : priorité donnée par AFD à une thread lorsque les E/S sont terminées pour cette thread. Si une application multi-thread est confrontée à l'abandon de certaines threads, il est possible de remédier au problème en réduisant cette valeur.

SmallBufferListDepth

Type de valeur : REG_DWORD

Par défaut : 8/16/32

Description : taille de la liste look-aside des tampons de petite taille.

SmallBufferSize

Type de valeur : REG_DWORD

Par défaut : 128

Description : taille, en octets, des petits tampons utilisés par AFD.

StandardAddressLength

Type de valeur : REG_DWORD

Par défaut : 22

Description : longueur des adresses TDI normalement utilisées pour l'ordinateur. Lorsque vous utilisez un autre protocole de transport, tel que TP4, qui utilise de très longues adresses, l'augmentation de cette valeur entraîne une légère amélioration des performances.

TransmitIoLength

Type de valeur : REG_DWORD

Par défaut : PAGE_SIZE/PAGE_SIZE*2/65536

Description : taille par défaut des E/S (lectures et envois) effectuées par TransmitFile(). Pour Windows 2000 Professionnel, la taille E/S par défaut est exactement d'une page.

TransmitWorker

Type de valeur : REG_DWORD

Par défaut : 0x10

Plage valide : 0x10, 0x20

Description : ce paramètre détermine comment Afd.sys utilise les threads système. Quand cette valeur est configurée sur 0x10, AFD utilise les threads système pour effectuer des E/S qui résultent d'une longue requête TransmitFile (l'équivalent d'une quantité de données de plus de 2 fois SendPacketLength). Quand elle est configurée sur 0x20, AFD utilise APC en mode noyau pour les E/S et exécute tout dans le contexte de la même thread. Ce paramètre est nouveau dans Windows 2000 et permet d'améliorer les performances grâce à la réduction du nombre de changements de contexte dans les longues requêtes TransmitFile.

Paramètres d'enregistrement DNS dynamique

Ces paramètres contrôlent le comportement du client d'enregistrement DNS dynamique. Si un paramètre est absent, la valeur par défaut est utilisée.

DNSQueryTimeouts

Clé : Tcpip\Parameters

Type de valeur : REG_MULTI_SZ : liste des délais, suivis d'un zéro

Plage valide : liste valide de nombres

Par défaut : 1 2 2 4 8 0 (remarque sur le format : après avoir entré chaque nombre, appuyez sur Entrée et terminez la liste par un zéro)

Description : ce paramètre peut être utilisé pour modifier les délais des requêtes DNS utilisés par le client DNS. Dans un environnement contrôlé non Internet ou avec des retards faibles, ce paramètre peut être utilisé pour réduire la durée de la requête avant échec.

DefaultRegistrationTTL

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD : secondes

Par défaut : 0x4B0 (1200 décimal ou 20 minutes)

Plage valide : 0–0xFFFFFFFF

Description : ce paramètre peut être utilisé pour contrôler la valeur TTL envoyée avec les enregistrements DNS dynamiques.

EnableAdapterDomainNameRegistration

Clé : Tcpip\Parameters\Interfaces\interface

Type de valeur : REG_DWORD : Booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0 (faux)

Description : ce paramètre permet d'activer l'enregistrement de la mise à jour DNS dynamique des informations de nom de domaine d'une carte spécifique. Ce paramètre est utile lorsqu'il est nécessaire d'enregistrer la ou les adresses de la carte sous le nom de domaine de la carte. Quand cette clé est configurée sur Vrai et que le paramètre DisableDynamicUpdate est configuré sur Faux, la ou les adresses de la carte donnée sont enregistrées sous le nom de domaine de la carte et sous le nom de domaine principal du système.

DisableDynamicUpdate

Clé : Tcpip\Parameters, Tcpip\Parameters\Interfaces\interface

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0 (faux ; DNS dynamique activé)

Description : ce paramètre permet de désactiver complètement l'enregistrement de mise à jour dynamique DNS. Il est défini tant au niveau de l'interface que du système, en fonction de l'emplacement de la clé de registre. Si la valeur au niveau Tcpip\Parameters est configurée sur 1, la mise à jour dynamique est désactivée pour tout le système. Si la valeur au niveau Tcpip\Parameters est configurée sur 0, les mises à jour dynamiques peuvent être désactivées au niveau de la carte.

DisableReplaceAddressesInConflicts

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0 (faux)

Description : ce paramètre permet de désactiver la règle qui régit les conflits d'enregistrement des adresses et selon laquelle la dernière écriture est prioritaire. Par défaut, un ordinateur ne remplace sur le serveur DNS aucun enregistrement en cours qui ne semble pas avoir été le sien à un instant donné.

DisableReverseAddressRegistrations

Clé : Tcpip\Parameters\Interfaces\interface

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0 (faux ; inscription d'enregistrements PTR activée)

Description : ce paramètre permet de désactiver l'inscription des enregistrements d'adresse inverse (PTR) de mise à jour dynamique DNS. Si le serveur DHCP qui configure cet ordinateur fonctionne sous Windows 2000 Server, il est en mesure d'enregistrer l'enregistrement PTR avec le protocole de mise à jour dynamique DNS. Cependant, si le serveur DHCP n'est pas en mesure d'effectuer les enregistrements PTR de mise à jour dynamique DNS et que vous ne souhaitez pas inscrire les enregistrements PTR avec le protocole de mise à jour dynamique DNS, configurez ce paramètre sur 1.

UpdateSecurityLevel

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD : indicateurs

Par défaut : 0

Plage valide : 0,0x00000010, 0x00000020, 0x00000100

Description : ce paramètre permet de contrôler la sécurité utilisée pour les mises à jour DNS dynamiques. Sa valeur par défaut est de 0 pour tenter la mise à jour non sécurisée et, en cas de refus, pour envoyer des mises à jour dynamiques sécurisées Windows 2000. Les valeurs valides sont répertoriées ci-dessous :

• 0x00000000 : par défaut, mises à jour non sécurisées

• 0x00000010 : sécurité désactivée

• 0x00000100 : sécurité activée uniquement

Paramètres de registre du service de résolution de cache DNS

Windows 2000 inclut un service de résolution de cache DNS. Ce service effectue la mise en cache des réponses DNS de sorte que le serveur DNS n'ait pas besoin d'être continuellement consulté pour les mêmes informations. Le service peut être interrompu à l'aide du composant logiciel enfichable MMC Service Control Manager. Les paramètres de registre relatifs à ce service sont placés sous la clé \System\CurrentControlSet\Services\Dnscache\Parameters.

AdapterTimeoutCacheTime

Type de valeur : REG_DWORD : secondes

Plage valide : 0–0xFFFFFFFF

Par défaut : 300 (5 minutes)

Description : la durée pendant laquelle une carte donnée sur une machine multi-hébergement est désactivée lorsqu'une tentative de requête DNS échoue (expiration du délai) pour tous les serveurs DNS de la carte en question. Par exemple, si vous avez deux cartes et que les serveurs DNS sur un des réseaux ne sont pas accessibles, signalez que la carte est inutilisable pendant cette période. (Un événement Plug-and-Play ou l'expiration du délai de cache force le module de résolution à réessayer cette interface et à la signaler comme désactivée, si nécessaire.)

CacheHashTableSize

Type de valeur : REG_DWORD : nombre

Par défaut : 0xD3 (211 décimal)

Plage valide : tout nombre premier supérieur à zéro

Description : ce paramètre permet de contrôler le nombre maximal de lignes de la table de hachage utilisée par le service de résolution de cache DNS. Il n'est a priori pas nécessaire de modifier ce paramètre.

CacheHashTableBucketSize

Type de valeur : REG_DWORD : nombre

Par défaut : 0xa (10 décimal)

Plage : 0–0x32 (50 décimal)

Description : ce paramètre permet de contrôler le nombre maximal de colonnes de la table de hachage utilisée par le service de résolution de cache DNS. Il n'est a priori pas nécessaire de modifier ce paramètre.

DefaultRegistrationRefreshInterval

Type de valeur : REG_DWORD : durée en secondes

Par défaut : 0x15180 (86400 décimal ou 24 heures)

Plage : 0–0xFFFFFFFF

Description : ce paramètre permet de contrôler l'intervalle de rafraîchissement de l'enregistrement DNS dynamique.

MaxCacheEntryTtlLimit

Type de valeur : REG_DWORD : durée en secondes

Par défaut : 0x15180 (86400 décimal)

Plage valide : 0–0xFFFFFFFF (valeur conseillée inférieure à un jour, afin d'éviter les enregistrements périmés)

Description : ce paramètre peut être utilisé pour contrôler la valeur maximale de la durée de vie (TTL) d'une entrée de cache. Il remplace toute valeur supérieure éventuellement définie sur un enregistrement spécifique.

MaxSOACacheEntryTtlLimit

Type de valeur : REG_DWORD : durée en secondes

Plage valide : 0–0xFFFFFFFF

Par défaut : 120 (2 minutes)

Description : nombre maximum de secondes pendant lesquelles le cache de résolution conserve en mémoire cache tous les enregistrements SOA. Cette valeur remplace toute valeur TTL supérieure à elle-même pour un enregistrement SOA spécifique renvoyé par une requête DNS. Les enregistrements SOA sont essentiels pour les mises à jour dynamiques ; ils ne sont donc pas conservés en mémoire cache pendant longtemps, afin assurer la disponibilité pour la source de noms DNS des données des enregistrements les récents.

NegativeCacheTime

Type de valeur : REG_DWORD : durée en secondes

Par défaut : 0x12c (300 décimal ou 5 minutes)

Plage valide : 0–0xFFFFFFFF (valeur conseillée inférieure à un jour, afin d'éviter les enregistrements périmés)

Description : ce paramètre permet de contrôler la durée de mise en cache des enregistrements négatifs.

NegativeSOACacheTime

Type de valeur : REG_DWORD : durée en secondes

Par défaut : 0x78 (120 décimal ou 2 minutes)

Plage valide : 0–0xFFFFFFFF (la valeur conseillée est inférieure à cinq minutes)

Description : ce paramètre permet de contrôler la durée de mise en cache pour les enregistrements de source de noms (SOA) négatifs. Les enregistrements DNS qui échouent sont retentés après cinq et dix minutes ; par conséquent, si cette valeur est configurée sur cinq minutes ou plus, les nouvelles tentatives reçoivent une réponse négative du cache, plutôt que du serveur, qui peut être disponible.

NetFailureErrorPopupLimit

Type de valeur : REG_DWORD : Booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0 (faux)

Description : ce paramètre permet à l'interface utilisateur d'indiquer par l'intermédiaire d'un message qu'à plusieurs reprises, la résolution DNS n'a pas pu interroger (atteindre) les serveurs DNS configurés.

NetFailureCacheTime

Type de valeur : REG_DWORD : durée en secondes

Par défaut : 0x1e (30 décimal)

Plage valide : 0–0xFFFFFFFF (la valeur conseillée est inférieure à cinq minutes)

Description : ce paramètre permet de contrôler la durée de mise en cache des défaillances générales du réseau. Il évite que le module de résolution n'envoie des requêtes pendant un certain temps lorsqu'une erreur de délai a été détectée pour des requêtes sur tous les serveurs DNS connus. Ceci évite les lenteurs (provoquées par les délais) lorsque le réseau ne répond pas.

Paramètres de résolution des noms

La liste de paramètres ci-dessous est utilisée par le service de résolution des noms de domaine.

AllowUnqualifiedQue ry

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0

Description : ce paramètre détermine si le module de résolution des noms de domaine interroge ou non le ou les serveurs de noms de domaine en leur envoyant le nom de l'hôte suivi d'un point (.) uniquement (requête incomplète). Par exemple, si l'ordinateur se trouve dans mondomaine.com et vous exécutez la commande ping cible, le DNS est interrogé par défaut uniquement pour cible.mondomaine.com. Quand ce paramètre est configuré sur 1, cible fait également l'objet d'une requête.

DisjointNameSpace

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 1

Description : ce paramètre ordonne au DNR de traiter chaque interface comme un espace de nom séparé. Sur un ordinateur multi-hôtes, une requête adressée au(x) serveur(s) DNS configuré(s) pour une interface peut provoquer une erreur de nom. Ce paramètre est utilisé pour ordonner au module de résolution d'essayer d'envoyer la requête aux serveurs DNS qui sont configurés pour d'autres interfaces avant de renvoyer les résultats.

PrioritizeRecordData

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 1

Description : ce paramètre détermine si le DNR trie ou non les adresses renvoyées en réponse à une requête d'un hôte multi-hébergement. Par défaut, le DNR trie et place au sommet de la liste les adresses qui se trouvent sur le même sous-réseau qu'une des interfaces de l'ordinateur qui émet la requête. Cela permet de donner la préférence à une adresse IP de sous-réseau commun (non routé), lorsque cela est possible.

QueryIpMatching

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0

Description : ce paramètre détermine si l'adresse IP du serveur DNS interrogé correspond ou non à l'adresse IP du serveur qui a envoyé la réponse DNS. Il peut être utilisé comme fonctionnalité de sécurité primitive pour garantir que le module de résolution n'est pas dupé par la réponse à une requête aléatoire provenant d'un autre ordinateur que le serveur DNS prévu.

UseDomainNameDevolution

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD : binaire

Plage valide : 0, 1 (faux, vrai)

Par défaut : 1 (vrai)

Description : ce paramètre permet de désactiver l'attribution des noms de domaine pour les requêtes DNS incomplètes. L'attribution décrit le processus de tentative de localisation d'un hôte dans le DNS en ajoutant d'abord le suffixe de domaine du client au nom de l'hôte, puis en interrogeant le serveur pour obtenir la chaîne complète. Si cette requête échoue, une étiquette est supprimée et la requête est renvoyée. Par exemple, si une application ou un utilisateur de l'ordinateur ordinateur.support.microsoft.com tente d'accéder à un hôte nommé cible, le DNR essaie par défaut cible.support.microsoft.com et cible.microsoft.com, puis si possible cible, en fonction de la valeur du paramètre AllowUnqualifiedQuery.

Annexe D : optimisation de la réponse TCP/IP à une attaque

Paramètres de sécurité TCP/IP

Outre les paramètres répertoriés ci-dessus, les clés suivantes peuvent être modifiées pour aider le système à faire face aux attaques de façon plus efficace. Il est important de remarquer que ces conseils n'immunisent en aucun cas le système contre les attaques ; ils se contentent simplement d'optimiser la réponse de la pile TCP/IP à une attaque. La configuration de ces clés ne s'adresse à aucun des nombreux autres composants du système, lesquels pourraient être utilisés pour attaquer le système. Comme pour toute modification du registre, l'administrateur doit bien comprendre les conséquences de ces modifications sur le fonctionnement par défaut du système et leur adaptation ou non à leur environnement.

SynAttackProtect

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD

Plage valide : 0, 1, 2

0 (aucune protection synattack) 1 (nombre limité de tentatives de retransmission et création retardée des RCE (entrées de cache de routage) si les paramètres TcpMaxHalfOpen et TcpMaxHalfOpenRetried sont appropriés.) 2 (en plus de 1, une indication retardée de Winsock est effectuée.)

Remarque Quand le système est soumis à une attaque, les options suivantes ne peuvent plus être activées sur aucun socket : les fenêtres dimensionnables (RFC 1323) et paramètres TCP configurés par carte (RTT initial, taille de la fenêtre). Ceci est dû au fait que, quand la protection fonctionne, l'entrée du cache de routage n'est pas interrogée avant l'envoi de SYN-ACK et les options Winsock ne sont pas disponibles à ce stade de la connexion.

Par défaut : 0 (faux)

Conseil : 2

Description : La protection Synattack implique la réduction de la quantité de retransmissions des SYN-ACKS, ce qui réduit aussi la période pendant laquelle les ressources doivent rester allouées. L'allocation des ressources d'entrée de cache de routage est retardée jusqu'à l'établissement d'une connexion. Si synattackprotect = 2, l'indication de la connexion vers AFD est retardée jusqu'à ce que le protocole de transfert à trois voies soit terminé. Remarquez que les actions entreprises par le mécanisme de protection ne le sont que si les paramètres TcpMaxHalfOpen et TcpMaxHalfOpenRetried sont dépassés.

TcpMaxHalfOpen

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD : nombre

Plage valide : 100–0xFFFF

Par défaut : 100 (Professionnel, Server), 500 (Advanced Server)

Description : ce paramètre définit le nombre de connexions autorisées dans l'état SYN-RCVD avant que la protection SYN-ATTACK n'entre en fonction. Si le paramètre SynAttackProtect est mis à 1, vérifiez que cette valeur est inférieure au journal d'écoute AFD sur le port que vous souhaitez protéger (voir les paramètres du journal dans l'Annexe C, plus loin, pour en savoir plus). Voir le paramètre SynAttackProtect pour en savoir plus.

TcpMaxHalfOpenRetried

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD : nombre

Plage valide : 80–0xFFFF

Par défaut : 80 (Professionnel, Server), 400 (Advanced Server)

Description : ce paramètre définit le nombre de connexions dans l'état SYN-RCVD pour lesquelles il y a eu au moins une retransmission du SYN envoyé avant que la protection SYN-ATTACK n'entre en fonction. Voir le paramètre SynAttackProtect pour en savoir plus.

EnablePMTUDiscovery

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 1 (vrai)

Conseil : 0

Description : quand la valeur de ce paramètre est définie à 1 (vrai), TCP essaie de trouver l'unité de transmission maximale (MTU ou dimension maximale du paquet) sur le parcours vers un hôte distant. En recherchant le parcours MTU et en limitant les segments TCP à cette taille, TCP est en mesure d'éliminer la fragmentation au niveau des routeurs tout au long du parcours qui relie les réseaux aux divers MTU. En revanche, la fragmentation a un impact négatif sur le débit TCP et sur l'encombrement du réseau. Quand ce paramètre est à 0, un MTU de 576 octets est utilisé pour toutes les connexions qui ne relient pas les hôtes du sous-réseau local.

NoNameReleaseOnDemand

Clé : Netbt\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 0 (faux)

Conseil : 1

Description : ce paramètre détermine si l'ordinateur publie son nom NetBIOS lorsqu'il reçoit une requête de publication de nom provenant du réseau. Il a été ajouté pour permettre à l'administrateur de protéger la machine des attaques destinées à découvrir les noms.

EnableDeadGWDetect

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD : booléen

Plage valide : 0, 1 (faux, vrai)

Par défaut : 1 (vrai)

Conseil : 0

Description : quand ce paramètre est à 1, TCP est autorisé à effectuer la détection de passerelles inactives. Quand cette fonction est activée, TCP demande au protocole IP de basculer sur une passerelle de réserve si certaines connexions connaissent des difficultés. Les passerelles de réserve peuvent être définies dans la section Avancé de la boîte de dialogue de configuration TCP/IP de l'application Réseau du Panneau de configuration. Consultez la section "Détection de passerelle inactive" dans ce livre pour en savoir plus.

KeepAliveTime

Clé : Tcpip\Parameters

Type de valeur : REG_DWORD : durée en millièmes de seconde

Plage valide : 1–0xFFFFFFFF

Par défaut : 7 200 000 (deux heures)

Conseil : 300 000

Description : ce paramètre contrôle à quelle fréquence le protocole TCP tente de vérifier qu'une connexion inactive est toujours intacte par l'envoi d'un paquet de maintien d'activité. Si le système distant est toujours accessible et en fonctionnement, il accuse réception de la transmission de maintien d'activité. Les paquets de maintien d'activité ne sont pas envoyés par défaut. Cette fonction peut être activée sur une connexion par une application.

PerformRouterDiscovery

Clé : Tcpip\Parameters\Interfaces\interface

Type de valeur : REG_DWORD

Plage valide : 0, 1, 2

0 (désactivé) 1 (activé) 2 (activé uniquement si DHCP envoie l'option de recherche de routeur)

Par défaut : 2, commandé par DHCP, mais désactivé par défaut.

Conseil : 0

Description : ce paramètre détermine si Windows 2000 essaie d'exécuter la recherche du routeur par interface, selon la RFC 1256. Voir aussi SolicitationAddressBcast.

Les informations contenues dans ce document représentent l'opinion actuelle de Microsoft sur les points cités à la date de publication. Microsoft s'adapte aux conditions fluctuantes du marché et cette opinion ne doit pas être interprétée comme un engagement de la part de Microsoft ; de plus, Microsoft ne peut pas garantir la véracité de toute information présentée après la date de publication. Ce livre blanc est fourni pour information uniquement. MICROSOFT N'OFFRE AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, DANS CE DOCUMENT. Microsoft, Windows et Windows NT sont soit des marques de Microsoft Corporation, soit des marques déposées de Microsoft Corporation aux États-Unis d'Amérique et/ou dans d'autres pays. Les autres noms de produits ou de sociétés mentionnés dans ce document sont des marques de leurs propriétaires respectifs. Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • États-Unis 02/00

1 Des spécifications et des informations de programmation figurent dans le Device Driver Kit de Windows NT. Certaines informations sont également disponibles sur le site Internet de Microsoft.

2 La plupart des cartes réseau peuvent être placées dans un mode où elles n'effectuent aucun filtrage d'adresse sur les trames qui apparaissent sur le support. En revanche, elles passent chaque trame au niveau supérieur, afin de procéder au contrôle de redondance cyclique (CRC). Cette fonction est utilisée par certains logiciels d'analyse de protocole, tels que le Moniteur réseau Microsoft.

3 Les 6 bits définis par Diffserv étaient précédemment appelés bits TOS. DiffServ rend obsolète l'utilisation précédente de TOS. Ainsi, la configuration des bits TOS par l'intermédiaire de Winsock n'est pas prise en charge. Toutes les requêtes TOS IP doivent être effectuées par le biais de l'API GQoS, à moins que le paramètre de registre DisableUserTOSSetting (Annexe A) n'ait été modifié.

4 Plutôt que d'envoyer un segment TCP au démarrage, Windows NT/Windows 2000 TCP démarre avec deux. Cela permet d'éviter d'avoir à attendre que le minuteur ACK retardé n'expire sur le premier envoi vers l'ordinateur cible, ce qui améliore les performances de certaines applications.

5 Consultez le Kit de ressources techniques de Microsoft Windows NT/Windows 2000 ou la Librairie d'Informations Techniques de Microsoft pour connaître les paramètres de registre du redirecteur.

6 Stevens, Richard. TCP/IP Illustrated, Volume 1: The Protocols. Reading, MA: Addison-Wesley Publishing Co., 1993.

7 Les deux spécifications sont disponibles sur le site Internet de Microsoft aux adresses www.microsoft.com et ftp.microsoft.com.

8 L'autoconfiguration IP peut être désactivée à l'aide de la clé de registre IPAutoconfigurationEnabled. Le sous-réseau et le masque de sous-réseau utilisés peuvent être contrôlés à l'aide des clés de registre IPAutoconfigurationSubnet et IPAutoconfigurationMask. Ces clés sont décrites à l'annexe A.

9 Voir "draft-ietf-dhc-dhcp-dns-*.txt"

Dernière mise à jour le mardi 28 novembre 2000

Pour en savoir plus

• Comment configurer le connecteur dynamique RAS sur TCP/IP

• Aperçu rapide de la programmation d'un espace de noms DNS

• Le site français Windows 2000 Server

• Toutes les infos de TechNet sur Windows 2000