Conditions préalables au test LAN

Le contenu de cette section décrit les prérequis de test LAN (Ethernet) que vous devez remplir avant de tester votre carte réseau à l’aide du kit Windows Hardware Lab Kit (Windows HLK).

Termes du document

Topologie de machine

Le diagramme suivant montre la topologie de machine recommandée. Les topologies qui diffèrent de ce sont fortement déconseillées, car elles peuvent nécessiter un effort supplémentaire pour que les tests s’exécutent correctement.

Il s’agit de la topologie qui s’applique à tous les appareils LAN (y compris les appareils qui prennent en charge QoS et Cheminée).

Topologie de machine pour les tests de carte réseau

Les tests HLK récemment développés avec le préfixe « [Carte réseau] » ou « [nom du test] » dans le titre sont des tests de machine unique et nécessitent 3 cartes réseau sur cet ordinateur. Les noms d’alias d’interface sont les suivants :

1. TestDevice : il s’agit du périphérique réseau testé.
2. SupportDevice0 : réseau de support supplémentaire carte nécessaire, connectés dos à dos avec TestDevice
3. MessageDevice : utilisé pour communiquer avec le contrôleur HLK.

Le diagramme suivant montre la topologie recommandée :

Tester les connexions

La connexion back-to-back est préférée en général, car elle empêche le commutateur d’interférer avec le test (configurations incorrectes du réseau local virtuel, paquets de contrôle de flux, et ainsi de suite)

Une connexion back-to-back est nécessaire pour les tests qui peuvent interférer avec le résultat d’un commutateur réseau. Ces tests sont les suivants :

• QoS (aka. DCB) (contrôle de flux de priorité, interopérabilité LLDP/DCBX, ETS (car certains commutateurs peuvent supprimer les balises 802.1p)

• Contrôle de flux Tx

• Tests qui envoient 802.1q-tagged (VlanSendRecv, VMQ, 1c_priority, peut-être d’autres)

Backchannel/réseau d’entreprise

Il est recommandé que le commutateur backchannel soit le même réseau que celui que les machines de test utiliseront pour communiquer avec le contrôleur HLK. Il est recommandé que ce réseau soit activé par DHCP.

Configuration requise pour la machine

Les exigences de la machine sont souvent dictées par les fonctionnalités prises en charge par la cible de test. La certification sur les références SKU client nécessite 2 cœurs de traitement, tandis que la certification sur les références SKU serveur nécessite 4 cœurs de traitement.

• Wake-on-LAN : le système doit prendre en charge la gestion de l’alimentation (S3)

• RSS : maximum de 4 cœurs physiques ou nombre par défaut de files d’attente RSS prises en charge par l’appareil

  • Exemple : si une carte réseau 1G prend en charge 2 files d’attente, le nombre de cœurs requis est de 4

  • Exemple : si une carte réseau 10G prend en charge 8 files d’attente, le nombre de cœurs requis est de 8

• Serveur/QoS : les systèmes doivent être capables de saturer 90 % du taux de liaison maximal

• QoS : la cible de stockage écrit à 20 % du taux de liaison maximal

Si vous utilisez un pool d’ordinateurs de test pour tester des appareils, au moins un ordinateur du pool doit contenir quatre processeurs et un minimum de 1 Go de RAM. En outre, cet ordinateur doit contenir le périphérique et le pilote que vous souhaitez tester. Si le pilote est le même sur tous les ordinateurs du pool, le système crée une planification à exécuter sur tous les ordinateurs de test.

Pour les tests qui n’incluent pas de pilote à tester, tels que les tests de disque dur, le planificateur Windows HLK limite les tests qui valident le rééquilibrage du périphérique et du pilote, l’état D3 et les fonctionnalités de groupes de processeurs multiples à exécuter sur l’ordinateur de test par défaut. Vous devez configurer manuellement cet ordinateur pour qu’il dispose de plusieurs groupes de processeurs. L’ordinateur par défaut est le premier ordinateur de test de la liste. Le personnel de test doit s’assurer que le premier ordinateur de test de la liste répond à la configuration matérielle minimale requise.

bcdedit.exe /set groupsize 2
bcdedit.exe /set groupaware on
shutdown.exe -r -t 0 -f

bcdedit.exe /deletevalue groupsize
bcdedit.exe /deletevalue groupaware
shutdown.exe -r -t 0 -f

HKLM\System\CurrentControlSet\Control\DeviceGuard
HypervisorEnforcedCodeIntegrity:REG_DWORD
0 or 1 (disabled, enabled)

Configuration de la machine

Certains tests nécessitent une configuration unique qui n’est pas ou ne peut pas être automatiquement prise en charge par les travaux de test. La liste ci-dessous décrit les tests qui nécessitent des configurations uniques.

QosStorageInterop

La cible de test sur la machine DUT doit être connectée au stockage réseau à l’aide d’iSCSI ou de SMB. La topologie de la machine de test est telle que le réseau de test est back-to-back, ce qui signifie que la machine de support doit également servir de cible de stockage. Cela signifie qu’une cible iSCSI logicielle doit être configurée sur le SUT ou qu’un partage SMB doit être partagé. L’ordinateur DUT doit mapper la cible de stockage à une lettre de lecteur et l’utilisateur doit s’assurer que cette connexion circule sur le réseau de test et non sur le réseau backchannel. Une fois configuré, vous devez entrer deux paramètres supplémentaires dans ce travail au moment de la planification :

• Lettre de lecteur

• Mode de stockage (iSCSI ou ND (réseau direct))

Suspension sélective

La fonctionnalité de suspension sélective NDIS peut avoir un impact négatif sur les résultats des tests. La plupart des tests de certification réseau supposent qu’un appareil est sous tension et prêt à l’emploi. Ainsi, la plupart des tests peuvent rapidement envoyer ou recevoir du trafic et s’attendre à ce que tous les paquets soient envoyés ou reçus de manière appropriée. Si un appareil est à faible consommation (suspension sélective), la reprise de l’appareil peut prendre un certain temps, ce qui peut entraîner une perte de paquets pendant la période de reprise.

Microsoft recommande de configurer *SelectiveSuspend sur désactivé (pour les pilotes NDIS) ou *IdleRestriction sur activé (pour les pilotes NetAdapterCx 2.2+ ) si les éléments suivants sont vrais (remarque : ne modifiez pas la valeur par défaut, uniquement la valeur opérationnelle lors de l’exécution des tests de certification) :

• Un client dispose d’un appareil prenant en charge la suspension sélective

• Les tests d’envoi/réception rencontrent des problèmes de perte de paquets

• Les problèmes de perte de paquets de test d’envoi/réception se trouvent uniquement dans la première variante d’un test donné

Vous pouvez également décocher l’option « Autoriser l’ordinateur à éteindre cet appareil pour économiser de l’alimentation » dans l’onglet Gestion de l’alimentation Gestionnaire de périphériques propriétés du miniport.

Tests QOS HW

Les tests « HW QoS* » nécessitent que SR-IOV soit actif, avec des vPorts VF disponibles. Sur certains matériels, Hyper-V doit être installé pour la carte réseau afin d’activer SR-IOV et de publier la disponibilité VF vPort. Il est donc recommandé d’installer Hyper-V avant d’exécuter les tests « HW QoS ».

Vue d’ensemble des modifications apportées à la sélection d’appareils réseau

Pour les tests d’appareil LAN, les cartes de message et de support ne sont plus sélectionnées à l’aide d’une interface utilisateur. Elles sont automatiquement détectées en fonction de la topologie du réseau. Si la détection automatique échoue parce que la topologie réseau est différente de la topologie recommandée, les appareils doivent être renommés sur les machines de test et de prise en charge avant d’exécuter des tests. Le renommage fait référence à « ifAlias » de l’appareil, qui est visible à partir de la fenêtre Connexions réseau, entre autres endroits.

Si un changement de nom est nécessaire, l’appareil de support sur l’ordinateur de support doit être renommé « SupportDevice0 ». Les appareils de messagerie sur les machines de test et de support doivent être renommés « MessageDevice ».

Critères de sélection automatique des appareils

Les machines de test et de support doivent être configurées dans la même configuration que la figure 4 et tous les autres périphériques/ports Ethernet non impliqués dans le test doivent être déconnectés ou désactivés. Les travaux de test utilisent les critères suivants pour rechercher l’appareil de message : appareil Ethernet, lien connecté, activé, lié TCP, adresse IP affectée à l’aide de DHCP. La détection inclut les cartes avec des adresses IP statiques si aucune carte n’est trouvée avec des adresses affectées DHCP. La carte de message est généralement connectée au contrôleur HLK et au réseau d’entreprise normal. Une fois l’appareil de message trouvé, le travail recherche dans les adaptateurs restants un appareil de prise en charge qui est un appareil Ethernet, reliez connecté et activé.

Exécution des tests LAN dans le HLK

Reportez-vous à l’aide de HLK pour plus d’informations sur la configuration du contrôleur et des ordinateurs clients. Ce document traite uniquement de l’exécution du contenu LAN dans le HLK.

Une fois les machines contrôleur et client configurées, procédez comme suit pour exécuter les tests LAN :

1. Créez un projet dans HLK Studio.

2. Créez un nouveau pool de machines, ajoutez les machines clientes qui ont été configurées au pool nouvellement créé, puis marquez l’ordinateur status comme étant prêt.

3. Assurez-vous que la machine de test et la machine de support sont connectées comme décrit dans la section Critères de sélection des appareils ci-dessus.

4. Sélectionnez uniquement le périphérique/pilote à tester (par exemple, le gestionnaire de périphériques ou le périphérique logiciel), sous l’onglet Sélection de HLK Studio.

5. Sélectionnez les travaux qui s’affichent dans la liste sous l’onglet Tests du studio HLK.

6. Cliquez sur Exécuter sélectionné, choisissez l’ordinateur de support pour la série de tests, puis cliquez sur OK.

Exécution de tests de logo de filtre

Procédez comme suit pour exécuter des tests de logo de filtre léger (LWF) :

1. Configurez le serveur DTM et les machines clientes DTM. Les tests de logo de filtre n’ont besoin que d’une seule machine cliente.

2. Installez le pilote LWF sur l’ordinateur client.

3. Redémarrez la machine cliente.

4. À partir du serveur DTM, ajoutez le client sur lequel le LWF est installé à un nouveau pool d’ordinateurs, puis remplacez l’ordinateur status par « Prêt ».

5. À partir de HLK Studio, créez un projet sous l’onglet « Projet » dans HLK Studio.

6. Dans l’onglet « Sélection » de HLK Studio, sélectionnez le pool d’ordinateurs créé aux étapes précédentes dans la liste déroulante.

7. Cliquez sur périphérique logiciel, puis sélectionnez le pilote LWF installé que vous souhaitez tester.

   

8. Exécutez tous les tests (les vérifications « NDISTest 6.5 - Test du logo LWF » pour toutes les exigences LWF) répertoriées dans l’onglet Tests par rapport au pilote LWF.

NDISTest 6.5 - Test du logo LWF

Ce test cible LWF en s’assurant que le filtre est en mesure de traiter des paquets supérieurs à la taille MTU de miniport.

Cela exécute également un test de contrainte de filtre pour stresser les chemins d’accès datapath et PNP des pilotes de filtre NDIS.  Le test limitera les descripteurs de réception de miniports virtuels de test, de sorte qu’un nombre important d’indications de réception se produisent avec l’indicateur de ressources de réception.  Le test effectue ensuite les actions suivantes de manière multithread :

• Stressez le trafic du miniport de support dirigé vers le miniport de test.

• Stresser le trafic du miniport de test dirigé vers le miniport de support

• Arrêtez/démarrez le miniport de test (ce qui déclenchera une pause et les opérations de redémarrage suivantes).

• Adaptateur de test indiquant que le média est déconnecté/connecté.

• Testez la réinitialisation de l’adaptateur.

  Enfin, la connectivité d’envoi et de réception de base sera testée entre les adaptateurs de test/support.

NdkPerfLogoTests

Ce test garantit que le trafic RDMA peut être envoyé et reçu entre le DUT et la machine de support. Ce test nécessite que l’interface réseau sur DUT et la prise en charge soient activées pour le trafic RDMA.

Le test s’exécute NdkPerfCmd.exe sur la machine DUT et sur la machine de support. Cela charge le pilote ndkperf.sys qui appelle les API NDK pour envoyer le trafic RDMA du DUT à l’ordinateur de support.

Paramètres :

Conseils pour investir les échecs :

• Vérifiez que les deux cartes réseau sont activées pour RDMA (Get-NetAdapterRdma)

• Vérifiez que les compteurs de perfmon d’activité RDMA sont incrémentés lors de l’envoi du trafic RDMA

• Essayez d’exécuter NdkPerfCmd.exe manuellement sur l’ordinateur DUT/support. En cas d’échec, il est probable qu’il y ait un problème avec les paramètres ou l’implemantion du pilote réseau des API NDK.

Rubriques connexes

Test device.network