LAN-Testvoraussetzungen

Die Inhalte in diesem Abschnitt beschreiben die Voraussetzungen für LAN-Tests (Ethernet), die Sie ausführen sollten, bevor Sie Ihren Netzwerkadapter mithilfe des Windows Hardware Lab Kit (Windows HLK) testen.

Hinweis

Dieser Inhalt gilt sowohl für eigenständige Adapter als auch für integrierte Netzwerkgeräte.

Dokumentbedingungen

Geräterolle	Schnittstellenalias
Testcomputer, Testziel (DUT)	Kein Name erforderlich, HLK-Aufträge wählen ihn automatisch aus.
Testcomputer, Nachrichtengerät	MessageDevice
Supportcomputer, Supportgerät	SupportDevice0
Supportcomputer, Supportgerät	MessageDevice
LWF-Treiber	NDIS-Light Weight Filter-Treiber

Computertopologie

Das folgende Diagramm zeigt die empfohlene Computertopologie. Von anderen Topologien als dieser wird dringend abgeraten, da sie möglicherweise zusätzlichen Aufwand für eine ordnungsgemäße Durchführung der Tests erfordern.

Dies ist die Topologie, die für alle LAN-Geräte gilt (einschließlich Geräten, die QoS und Chimney unterstützen).

Computertopologie für Netzwerkadaptertests

Kürzlich entwickelte HLK-Tests mit dem Präfix „[Netzwerkadapter]“ oder „[Name des Tests]“ im Titel sind Einzelcomputertests und erfordern 3 Netzwerkadapter auf diesem Computer. Die Namen des Schnittstellenalias lauten folgendermaßen:

1. TestDevice: Dies ist das Netzwerkgerät, das getestet wird.
2. SupportDevice0: Zusätzliche unterstützende Netzwerkkarte erforderlich, die wieerholt mit TestDevice verbunden werden muss
3. MessageDevice: Wird verwendet, um mit dem HLK-Controller zu kommunizieren.

Das folgende Diagramm zeigt die empfohlene Topologie:

Verbindungen testen

Die wiederholte Verbindung wird im Allgemeinen bevorzugt, da sie die Möglichkeit verhindert, dass Schalter den Test beeinträchtigen (VLAN-Fehlkonfigurationen, Flusssteuerungspakete usw.)

Eine wiederholte Verbindung ist für Tests erforderlich, bei denen ein Netzwerkschalter das Ergebnis beeinträchtigen kann. Zu diesen Tests gehören:

• QoS (aka. DCB) (Prioritätsflusssteuerung, LLDP/DCBX-Interoperabilität, ETS (da einige Schalter 802.1p-Tags möglicherweise entfernen)

• Tx-Flusssteuerung

• Tests, die 802.1q-Tags versenden (VlanSendRecv, VMQ, 1c_priority, vielleicht andere)

Backchannel/Unternehmensnetzwerk

Es wird empfohlen, dass sich der Backchannel-Switch im selben Netzwerk befindet, das von den Testcomputern verwendet wird, um mit dem HLK-Controller zu kommunizieren. Es wird empfohlen, dass dieses Netzwerk DHCP-aktiviert ist.

Computeranforderungen

Die Computeranforderungen werden häufig von den Features bestimmt, die das Testziel unterstützt. Die Zertifizierung auf Client-SKUs erfordert 2 Verarbeitungskerne, während die Zertifizierung auf Server-SKUs 4 Verarbeitungskerne erfordert.

Hinweis

Der Begriff Kern bezieht sich auf physische Verarbeitungskerne (keine virtuellen oder Hyperthread-Kerne). Wenn Ihr Gerät erweiterte Features wie die nachstehenden unterstützt, können die Mindestsystemanforderungen steigen.

• Wake-on-LAN: System muss Power Management (S3) unterstützen

• RSS: Maximal 4 physische Kerne oder die Standardanzahl von RSS-Warteschlangen, die vom Gerät unterstützt werden

  • Beispiel: Wenn eine 1G-NIC 2 Warteschlangen unterstützt, beträgt die Anzahl der erforderlichen Kerne 4.

  • Beispiel: Wenn eine 10G-NIC 8 Warteschlangen unterstützt, beträgt die Anzahl der erforderlichen Kerne 8.

• Server/QoS: Systeme müssen in der Lage sein, 90 % der maximalen Linkrate zu sättigen.

• QoS: Speicherziel-Schreibvorgänge bei 20 % der maximalen Linkrate

Hinweis

Wenn beim Senden/Empfangen von Paketen und während des Tests häufig Verluste auftreten, handelt es sich wahrscheinlich um kein Problem mit selektivem Anhalten.

Hinweis

Um Ihr Produkt für die Verwendung auf Servern zu zertifizieren, muss der Testcomputer vier Prozessoren und mindestens 1 GB RAM unterstützen. Diese Systemfunktionen sind erforderlich, um die Funktionen Neuausgleich, D3-Status und mehrere Prozessorgruppen des Geräts und des Treibers zu testen. Sie brauchen keinen Computer, der tatsächlich mehr als 64 Prozessoren hat, um Ihr Gerät zu testen. Darüber hinaus muss Server Core auf den Serversystemen, die zum Testen von Geräten oder Treibern verwendet werden, vor dem Testen installiert sein. Weitere Informationen finden Sie unter Windows Server-Installationsoptionen.

Wenn Sie Geräte mit einem Pool von Testcomputern testen, muss mindestens einer dieser Computer vier Prozessoren und mindestens 1 GB RAM enthalten. Außerdem muss dieser Computer das Gerät und den Treiber enthalten, die Sie testen möchten. Wenn der Treiber auf allen Computern des Pools derselbe ist, erstellt das System einen Zeitplan für die Ausführung auf allen Testcomputern.

Bei Tests, die keinen zu testenden Treiber enthalten, wie z. B. Festplattentests, beschränkt der Windows HLK Zeitplaner die Tests, die das Rebalancing des Geräts und des Treibers, den D3-Status und die Funktionalität mehrerer Prozessorgruppen validieren, auf die Ausführung auf dem Standard-Testrechner. Sie müssen diesen Computer manuell so konfigurieren, dass er über mehrere Prozessorgruppen verfügt. Der Standardcomputer ist der erste Testcomputer in der Liste. Das Testpersonal muss sicherstellen, dass der erste Testcomputer auf der Liste die Mindesthardwareanforderungen erfüllt.

Hinweis

Mit Ausnahme von Paravirtualisierungstreibern (wie im Dokument zu WHCP-Richtlinien und -Prozesse definiert) können Sie keine Form der Virtualisierung verwenden, wenn Sie physische Geräte und die zugehörigen Treiber für die Serverzertifizierung oder -signatur testen. Nicht alle Virtualisierungsprodukte unterstützen die zugrunde liegende Funktionalität, die erforderlich ist, um jene Tests, die sich auf mehrere Prozessorgruppen, Geräteleistungsverwaltung, Geräte-PCI-Funktionalität beziehen, sowie andere Tests zu bestehen.

Hinweis

  Einstellung für mehrere Prozessorgruppen Sie müssen den Wert für die Prozessorgruppengröße für Hardware Lab Kit-Tests von Windows Server 2008 R2- und späteren Gerätetreibern für die Zertifizierung festlegen. Dies erfolgt durch Ausführen von bcdedit in einem Eingabeaufforderungsfenster mit erhöhten Rechten unter Verwendung der Option /set.

Die Befehle zum Hinzufügen der Gruppeneinstellungen und zum Neustart lauten wie folgt:

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

Die Befehle zum Entfernen der Gruppeneinstellungen und zum Neustart lauten wie folgt:

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

Hinweis

Codeintegritätseinstellung

Die Virtualization Based Security-Funktion (VBS) von Windows Server 2016 muss zuerst mit dem Server-Manager aktiviert werden.

Sobald dies erfolgt ist, muss der folgende Registry-Schlüssel erstellt und festgelegt werden:

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

Computerkonfiguration

Einige Tests erfordern eine eindeutige Konfiguration, die nicht oder nicht automatisch von Testaufträgen übernommen werden kann. In der folgenden Liste wird beschrieben, welche Tests eindeutige Konfigurationen erfordern.

QosStorageInterop

Das Testziel auf dem DUT-Computer muss über iSCSI oder SMB eine Verbindung mit netzwerkbasiertem Speicher besitzen. Die Testcomputertopologie muss über ein kaskadierendes Testnetzwerk verfügen, was bedeutet, dass der Supportcomputer auch als Speicherziel dienen muss. Dies bedeutet, dass ein Software-iSCSI-Ziel auf dem SUT konfiguriert oder eine SMB-Freigabe freigegeben werden muss. Der DUT-Computer muss das Speicherziel einem Laufwerkbuchstaben zuordnen, und der Benutzer muss sicherstellen, dass diese Verbindung über das Testnetzwerk und nicht über das Backchannel-Netzwerk erfolgt. Nach der Konfiguration müssen Sie zwei zusätzliche Parameter zu diesem Auftrag zur geplanten Zeit eingeben:

• Laufwerkbuchstabe

• Speichermodus (iSCSI oder ND (Network Direct))

Selektives Anhalten

Das Feature „Selektives Anhalten“ von NDIS hat möglicherweise negative Auswirkungen auf Testergebnisse. Viele der Netzwerkzertifizierungstests gehen davon aus, dass sich ein Gerät in einem eingeschalteten und einsatzbereiten Zustand befindet. Daher senden oder empfangen viele der Tests möglicherweise schnell Datenverkehr und erwarten, dass alle Pakete entsprechend gesendet oder empfangen werden. Wenn sich ein Gerät gerade im Energiesparmodus befindet (selektives Anhalten), kann es etwas dauern, bis das Gerät seine Aktivitäten wieder aufnimmt, was zu Paketverlusten während des Wiederaufnahmezeitraums führen kann.

Microsoft empfiehlt das Deaktivieren von „*SelectiveSuspend“ (für NDIS-Treiber) oder das Aktivieren von „*IdleRestriction“ (für NetAdapterCx 2.2+-Treiber), wenn für Folgende „true“ eingestellt ist (Hinweis: Ändern Sie beim Ausführen der Zertifizierungstests den Standardwert nicht, sondern nur den Betriebswert):

• Ein Kunde hat ein Gerät für selektives Anhalten

• Bei Sende-/Empfangstests treten Probleme mit Paketverlusten auf

• Probleme mit dem Verlust von Sende-/Empfangstestpaketen sind nur in der ERSTEN Variation eines bestimmten Tests aufgetreten

Alternativ kann der Computer in den Geräte-Manager-Eigenschaften des Miniports auf der Registerkarte „Energieverwaltung“ das Kontrollkästchen „Computer kann das Gerät ausschalten, um Energie zu sparen“ deaktivieren.

HW-QOS-Tests

Die „HW-QoS*“-Tests erfordern, dass SR-IOV aktiv ist und VF-vPorts verfügbar sind. Bei einigen Hardwaregeräten muss Hyper-V für den Netzwerkadapter installiert werden, um SR-IOV zu aktivieren und für die Verfügbarkeit von VF-vPort zu werben. Daher wird empfohlen, dass Hyper-V vor dem Ausführen der „HW QoS“-Tests installiert wird.

Übersicht über Änderungen an der Netzwerkgeräteauswahl

Bei LAN-Gerätetests werden Nachrichten- und Supportadapter nicht mehr mithilfe einer Benutzeroberfläche ausgewählt. Sie werden automatisch basierend auf der Netzwerktopologie erkannt. Wenn die automatische Erkennung fehlschlägt, da sich die Netzwerktopologie von der empfohlenen Topologie unterscheidet, müssen die Geräte vor dem Ausführen von Tests auf den Test- und Supportcomputern umbenannt werden. Die Umbenennung bezieht sich auf das „ifAlias“ des Geräts, das unter anderem im Fenster „Netzwerkverbindungen“ sichtbar ist.

Falls eine Umbenennung erforderlich ist, muss das Supportgerät auf dem Supportcomputer in „SupportDevice0“ umbenannt werden. Die Nachrichtengeräte auf den Test- und Supportcomputern müssen in „MessageDevice“ umbenannt werden.

Kriterien für die automatische Geräteauswahl

Die Test- und Supportcomputer müssen in derselben Konfiguration wie Abbildung 4 eingerichtet werden, und alle anderen Ethernet-Geräte/Ports, die nicht an Tests beteiligt sind, müssen getrennt oder deaktiviert werden. Die Testaufträge verwenden die folgenden Kriterien, um das Nachrichtengerät zu finden: Ethernet-Gerät, Link verbunden, aktiviert, TCP gebunden, IP-Adresse mit DHCP zugewiesen. Die Erkennung enthält Adapter mit statischen IP-Adressen, wenn keine Adapter mit DHCP zugewiesenen Adressen gefunden werden. Der Nachrichtenadapter ist in der Regel mit dem HLK-Controller und dem normalen Unternehmensnetzwerk verbunden. Wenn das Nachrichtengerät gefunden wird, durchsucht der Auftrag die verbleibenden Adapter nach einem Supportgerät, das ein aktives Ethernet-Gerät, per Link verbunden und aktiviert ist.

Ausführen der LAN-Tests im HLK

Weitere Informationen zum Einrichten des Controllers und der Clientcomputer finden Sie in der HLK-Hilfe. Dieses Dokument befasst sich nur mit der Ausführung von LAN-Inhalten im HLK.

Nachdem die Controller- und Clientcomputer eingerichtet wurden, führen Sie die folgenden Schritte aus, um die LAN-Tests auszuführen:

1. Erstellen Sie ein Projekt in HLK Studio.

2. Erstellen Sie einen neuen Computerpool, und fügen Sie die Clientcomputer hinzu, die im neu erstellten Pool eingerichtet wurden, und markieren Sie den Computerstatus als bereit.

3. Stellen Sie sicher, dass der Testcomputer und der Supportcomputer verbunden sind, wie im Abschnitt Geräteauswahlkriterien oben beschrieben.

4. Wählen Sie auf der Registerkarte Auswahl in HLK Studio nur Geräte/Treiber aus, die getestet werden sollen (z. B. Geräte-Manager oder Softwaregerät).

5. Wählen Sie die Aufträge aus, die in der Liste auf der Registerkarte Tests von HLK Studio angezeigt werden.

6. Klicken Sie auf Ausgewählte ausführen, wählen Sie den Supportcomputer für die Ausführung des Tests aus, und klicken Sie auf OK.

Ausführen von Filterlogotests

Führen Sie die folgenden Schritte zum Ausführen von LWF-Logotests (Lightweight Filter) aus:

1. Richten Sie den DTM-Server und den DTM-Clientcomputer ein, und konfigurieren Sie diese. Filterlogotests benötigen nur einen einzigen Clientcomputer.

2. Installieren Sie den LWF-Treiber auf dem Clientcomputer.

3. Starten Sie den Clientcomputer neu.

4. Fügen Sie auf dem DTM-Server den Client hinzu, auf dem der LWF in einem neuen Computerpool installiert worden ist, und ändern Sie den Computerstatus in „Ready“.

5. Erstellen Sie in HLK Studio auf der Registerkarte „Project“ ein neues Projekt.

6. Wählen Sie in HLK Studio auf der Registerkarte „Selection“ den Computerpool aus, der in den vorherigen Schritten im Dropdown erstellt worden ist.

7. Klicken Sie auf Softwaregerät, und wählen Sie den installierten LWF-Treiber aus, den Sie testen möchten.

   

8. Führen Sie alle Tests aus (der „NDISTest 6.5 - LWF Logo Test“ sucht nach allen LWF-Anforderungen), die auf der Registerkarte Tests für den LWF-Treiber aufgeführt sind.

NDISTest 6.5 – LWF – Logo-Test

Dieser Test ist auf LWF ausgerichtet und stellt sicher, dass der Filter Pakete verarbeiten kann, die größer als die MTU-Größe des Miniports sind.

Dazu wird auch ein Filterbelastungstest für den Datenpfad- und die PnP-Pfade von NDIS-Filtertreibern ausgeführt.  Der Test beschränkt die Empfangsdeskriptoren des virtuellen Miniports so, dass eine signifikante Anzahl von Empfangsanzeigen mit dem Empfangsressourcen-Tag erfolgt.  Der Test führt dann die folgenden Multithread-Aktionen aus:

• Stressdatenverkehr vom Support-Miniport, der zum Test-Miniport geleitet wird

• Stressverkehr vom Test-Miniport, der zum Support-Miniport geleitet wird

• Beenden/Starten des Test-Miniports (wodurch eine Pause und nachfolgende Neustartvorgänge ausgelöst werden)

• Testadapter, der angibt, dass Medien getrennt/verbunden werden.

• Zurücksetzen des Testadapters.

  Schließlich wird die grundlegende Sende- und Empfangskonnektivität zwischen den Test-/Supportadaptern getestet.

NdkPerfLogoTests

Dieser Test stellt sicher, dass RDMA-Datenverkehr zwischen DUT und dem Supportcomputer gesendet und empfangen werden kann. Dieser Test erfordert, dass die Netzwerkschnittstelle sowohl für DUT- als auch Supportcomputer für RDMA-Datenverkehr aktiviert ist.

Der Test führt NdkPerfCmd.exe sowohl auf dem DUT- als auch auf dem Supportcomputer aus. Dadurch wird der Treiber ndkperf.sys geladen, der die NDK-APIs aufruft, um RDMA-Datenverkehr vom DUT- an den Supportcomputer zu senden.

Parameter:

Parameter	Beschreibung
ClientIf	Die Schnittstellen-ID der für RDMA aktivierten NIC auf dem DUT. Verwenden von Get-NetAdapter zum Abrufen der ID
ClientAddr	Die IP-Adresse der für RDMA aktivierten NIC auf dem DUT. Verwenden von ipconfig oder Get-NetIpAddress zum Abrufen der IP-Adresse
SupportIf	Die Schnittstellen-ID der für RDMA aktivierten NIC auf dem Supportcomputer. Verwenden von Get-NetAdapter zum Abrufen der ID
SupportAddr	Die IP-Adresse der für RDMA aktivierten NIC auf dem Supportcomputer. Verwenden von ipconfig oder Get-NetIpAddress zum Abrufen der IP-Adresse

Tipps für Investitionsfehler:

• Sicherstellen, dass beide Nics für RDMA aktiviert sind (Get-NetAdapterRdma)

• Sicherstellen, dass die perfmon-Leistungsindikatoren der RDMA-Aktivität beim Senden von RDMA-Datenverkehr erhöht werden

• Versuchen, NdkPerfCmd.exe manuell auf dem DUT/Supportcomputer auszuführen. Wenn er ausfällt, besteht wahrscheinlich ein Problem mit den Parametern oder der Implementierung des Netzwerktreibers der NDK-APIs.

Verwandte Themen

Device.Network-Tests