Prerequisiti di test LAN
Il contenuto di questa sezione descrive i prerequisiti di test LAN (Ethernet) che è necessario completare prima di testare la scheda di rete usando Windows Hardware Lab Kit (Windows HLK).
Nota
Questo contenuto si applica sia alle schede di rete autonome che ai dispositivi di rete integrati.
Termini documento
| Ruolo dispositivo | Alias interfaccia |
|---|---|
Computer di test, destinazione di test (DUT) |
Nessun nome necessario, i processi HLK lo sceglieranno automaticamente |
Testare il computer, il dispositivo di messaggio |
MessageDevice |
Computer di supporto, supporto del dispositivo |
SupportDevice0 |
Computer di supporto, dispositivo di messaggio |
MessageDevice |
Driver LWF |
Driver filtro NDIS leggero |
Topologia del computer
Il diagramma seguente illustra la topologia di computer consigliata. Le topologie che differiscono da questo sono altamente sconsigliate perché potrebbero richiedere sforzi aggiuntivi per ottenere correttamente i test.
Si tratta della topologia che si applica a tutti i dispositivi LAN (inclusi i dispositivi che supportano QoS e Camino).
Topologia di computer per i test della scheda di rete
I test HLK sviluppati di recente prefissi con "[Scheda di rete]" o "[nome del test]" nel titolo sono test di computer singoli e richiedono 3 schede di rete in tale computer. I nomi dell'alias dell'interfaccia sono i seguenti:
- TestDevice: si tratta del dispositivo di rete sottoposto a test.
- SupportDevice0: scheda di rete di supporto aggiuntiva necessaria, connessa da back-to-back con TestDevice
- MessageDevice: usato per comunicare con il controller HLK.
Il diagramma seguente illustra la topologia consigliata:
Testare le connessioni
La connessione back-to-back è preferibile in generale perché rimuove la possibilità di interferire con il test (misconfigurazioni VLAN, pacchetti di controllo del flusso e così via)
È necessaria una connessione back-to-back per i test che un commutatore di rete può interferire con il risultato. Questi test includono:
QoS (aka. DCB) (controllo del flusso di priorità, interoperabilità LLDP/DCBX, ETS( in quanto alcune opzioni possono eseguire lo striping di tag 802.1p)
Controllo flusso tx
Test che inviano 802.1q-tag (VlanSendRecv, VMQ, 1c_priority, forse altri)
Rete backchannel/aziendale
È consigliabile che il commutatore backchannel sia la stessa rete che i computer di test useranno per comunicare con il controller HLK. È consigliabile abilitare questa rete.
Requisiti del computer
I requisiti del computer sono spesso dettati dalle funzionalità supportate dalla destinazione di test. La certificazione sugli SKU client richiederà 2 core di elaborazione mentre la certificazione sugli SKU del server richiederà 4 core di elaborazione.
Nota
Il termine core si riferisce ai core di elaborazione fisica (non core virtuali o iper threaded). Se il dispositivo supporta funzionalità avanzate come quelle seguenti, è possibile aumentare i requisiti minimi di sistema.
Riattivazione LAN: il sistema deve supportare la gestione delle energia (S3)
RSS: massimo di 4 core fisici o il numero predefinito di code RSS supportate dal dispositivo
Esempio: se una scheda di interfaccia di rete 1G supporta 2 code, il numero di core necessari sarebbe 4
Esempio: se una scheda di interfaccia di rete 10G supporta 8 code, il numero di core necessari sarebbe 8
Server/QoS: i sistemi devono essere in grado di saturare il 90% della velocità massima di collegamento
QoS: la destinazione di archiviazione scrive al 20% della velocità massima di collegamento
Nota
Se i problemi di perdita dei pacchetti di invio/ricezione si verificano spesso e durante il test, non è probabile che si verifichi un problema di sospensione selettiva.
Nota
Per certificare il prodotto da usare nei server, il computer di test deve supportare quattro processori e almeno 1 GB di RAM. Queste funzionalità di sistema sono necessarie per testare la funzionalità Rebalance, D3 State e Multiple Processor Group del dispositivo e del driver. Non è necessario un computer con più di 64 processori per testare il dispositivo. Inoltre, i sistemi server usati per il test del dispositivo o del driver devono avere Server Core installato prima del test. Per altre informazioni, vedere Opzioni di installazione di Windows Server.
Se si usa un pool di computer di test per testare i dispositivi, almeno un computer nel pool deve contenere quattro processori e un minimo di 1 GB di RAM. Inoltre, tale computer deve contenere il dispositivo e il driver da testare. Se il driver è uguale a tutti i computer del pool, il sistema crea una pianificazione da eseguire su tutti i computer di test.
Per i test che non includono un driver da testare, ad esempio i test dell'unità disco rigido, l'utilità di pianificazione di Windows HLK limita i test che convalidano il bilanciamento del dispositivo e del driver, lo stato D3 e più gruppi di processori da eseguire nel computer di test predefinito. È necessario configurare manualmente questo computer per avere più gruppi di processori. Il computer predefinito è il primo computer di test nell'elenco. Il personale di test deve assicurarsi che il primo computer di test nell'elenco soddisfi i requisiti hardware minimi.
Nota
Ad eccezione dei driver di para-virtualizzazione (come definito dal documento Criteri e processi WHCP ), è possibile non usare alcuna forma di virtualizzazione quando si testano i dispositivi fisici e i driver associati per la certificazione o la firma del server. Tutti i prodotti di virtualizzazione non supportano le funzionalità sottostanti necessarie per superare i test correlati a più gruppi di processori, gestione energia del dispositivo, funzionalità PCI del dispositivo e altri test.
Nota
Impostazione Di più gruppi di processori è necessario impostare il valore per le dimensioni del gruppo di processori per i test di Hardware Lab Kit di Windows Server 2008 R2 e i driver di dispositivo successivi per la certificazione. Questa operazione viene eseguita eseguendo bcdedit in una finestra del prompt dei comandi con privilegi elevati usando l'opzione /set.
I comandi per aggiungere le impostazioni del gruppo e il riavvio sono i seguenti:
bcdedit.exe /set groupsize 2
bcdedit.exe /set groupaware on
shutdown.exe -r -t 0 -f
I comandi per rimuovere le impostazioni del gruppo e il riavvio sono i seguenti:
bcdedit.exe /deletevalue groupsize
bcdedit.exe /deletevalue groupaware
shutdown.exe -r -t 0 -f
Nota
Impostazione di integrità del codice
La funzionalità di sicurezza basata su virtualizzazione (VBS) di Windows Server 2016 deve essere abilitata prima usando Server Manager.
Dopo aver eseguito l'operazione, è necessario creare e impostare la chiave del Registro di sistema seguente:
HKLM\System\CurrentControlSet\Control\DeviceGuard
HypervisorEnforcedCodeIntegrity:REG_DWORD
0 or 1 (disabled, enabled)
Configurazione del computer
Alcuni test richiedono una configurazione univoca che non è o non può essere eseguita automaticamente dai processi di test. Nell'elenco seguente vengono descritti i test che richiedono configurazioni univoche.
QosStorageInterop
La destinazione di test nel computer DUT deve avere connettività all'archiviazione basata sulla rete usando iSCSI o SMB. La topologia del computer di test è tale che la rete di test è back-to-back, il che significa che il computer di supporto deve fungere anche da destinazione di archiviazione. Ciò significa che una destinazione iSCSI software deve essere configurata nel SUT o in una condivisione SMB deve essere condivisa. Il computer DUT deve eseguire il mapping della destinazione di archiviazione a una lettera di unità e l'utente deve assicurarsi che questa connessione venga eseguita sulla rete di test e non sulla rete backchannel. Dopo aver configurato, è necessario immettere due parametri aggiuntivi per questo processo in fase di pianificazione:
Lettera unità
Modalità di archiviazione (iSCSI o ND (Network Direct))
Sospensione selettiva
La funzionalità Sospensione selettiva NDIS potrebbe avere un impatto negativo sui risultati dei test. Molti dei test di certificazione di rete presuppongono che un dispositivo sia in uno stato attivo e pronto per l'uso. Pertanto, molti dei test possono inviare o ricevere rapidamente il traffico e aspettarsi che tutti i pacchetti vengano inviati o ricevuti in modo appropriato. Se un dispositivo è in bassa potenza (sospensione selettiva), potrebbe richiedere un breve periodo di tempo per il ripristino del dispositivo, che potrebbe causare la perdita di pacchetti durante il periodo di ripresa.
Microsoft consiglia di configurare *SelectiveSuspend in disabilitato (per i driver NDIS) o *IdleRestriction per abilitato (per i driver NetAdapterCx 2.2+) se il valore predefinito è true (nota: non modificare il valore predefinito, solo il valore operativo durante l'esecuzione dei test di certificazione):
Un cliente ha un dispositivo in grado di sospendere selettivo
I test di invio/ricezione riscontrano problemi di perdita di pacchetti
I problemi di perdita dei pacchetti di test di invio/ricezione sono solo nella variante FIRST di un determinato test
In alternativa, la scheda "Consenti al computer di disattivare questo dispositivo per risparmiare energia" può essere deselezionata nella scheda Gestione dispositivi proprietà del miniport.
Test QOS di HW
I test "HW QoS*" richiedono l'attività SR-IOV, con vPort VF disponibili. In alcuni hardware, Hyper-V deve essere installato per la scheda di rete per abilitare SR-IOV e annunciare la disponibilità vPort di VF. È quindi consigliabile installare Hyper-V prima di eseguire i test "HW QoS".
Panoramica delle modifiche apportate alla selezione dei dispositivi di rete
Per i test dei dispositivi LAN, i messaggi e le schede di supporto non sono più selezionati usando un'interfaccia utente, vengono rilevati automaticamente in base alla topologia di rete. Se il rilevamento automatico non riesce perché la topologia di rete è diversa dalla topologia consigliata, i dispositivi devono essere rinominati nei computer di test e supporto prima di eseguire test. La ridenominazione fa riferimento alla "ifAlias" del dispositivo visibile dalla finestra Connessioni di rete tra le altre posizioni.
Se è necessaria la ridenominazione, il dispositivo di supporto nel computer di supporto deve essere rinominato in "SupportDevice0". I dispositivi di messaggio nei computer di test e di supporto devono essere rinominati in "MessageDevice".
Criteri di selezione automatica dei dispositivi
I computer di test e supporto devono essere configurati nella stessa configurazione della figura 4 e tutti gli altri dispositivi/porte Ethernet non coinvolti nei test devono essere disconnessi o disabilitati. I processi di test usano i criteri seguenti per trovare il dispositivo messaggio: dispositivo Ethernet, collegamento connesso, abilitato, associato TCP, indirizzo IP assegnato tramite DHCP. Il rilevamento include adattatori con indirizzi IP statici se non vengono trovati adattatori con indirizzi assegnati DHCP. La scheda messaggi è in genere connessa al controller HLK e alla normale rete aziendale. Dopo aver trovato il dispositivo di messaggio, il processo cerca le schede rimanenti per un dispositivo di supporto che è un dispositivo Ethernet, collegare e abilitato.
Esecuzione dei test LAN in HLK
Per informazioni sulla configurazione del controller e sui computer client, vedere la Guida di HLK. Questo documento gestisce solo l'esecuzione del contenuto LAN in HLK.
Dopo aver configurato il controller e i computer client, seguire questa procedura per eseguire i test LAN:
Creare un progetto in HLK Studio.
Creare un nuovo pool di computer e aggiungere i computer client che sono stati configurati nel pool appena creato e contrassegnare lo stato del computer come pronto.
Assicurarsi che il computer di test e il computer di supporto siano connessi come descritto nella sezione Criteri di selezione dei dispositivi precedente.
Selezionare solo il dispositivo/driver da testare (ad esempio gestione dispositivi o dispositivo software), nella scheda Selezione di HLK Studio.
Selezionare i processi visualizzati nell'elenco nella scheda Test dello studio HLK.
Fare clic su Esegui selezionato e scegliere il computer di supporto per l'esecuzione del test e fare clic su OK.
Esecuzione di test del logo dei filtri
Per eseguire test di logo LWF (Lightweight Filter) seguire questa procedura:
Configurare/Configurare il server DTM e i computer client DTM. I test di filtro logo richiedono solo un computer client.
Installare il driver LWF nel computer client.
Riavviare il computer client.
Dal server DTM aggiungere il client in cui è installato LWF in un nuovo pool di computer e modificare lo stato del computer su "Pronto".
Da HLK Studio creare un nuovo progetto nella scheda 'Progetto' in HLK Studio.
Nella scheda "Selezione" dello studio HLK selezionare il pool di computer creato nei passaggi precedenti dall'elenco a discesa.
Fare clic sul dispositivo software e selezionare il driver LWF installato da testare.
Eseguire tutti i test (il test 'NDISTest 6.5 - Test logo LWF' controlla tutti i requisiti LWF) elencati nella scheda Test sul driver LWF.
Test del logo LWF NDISTest 6.5
Questo test è destinato a LWF assicurandosi che il filtro sia in grado di elaborare pacchetti più grandi delle dimensioni MTU del miniport.
In questo modo viene eseguito anche un test di stress del filtro per stressare i percorsi di datapath e PNP dei driver di filtro NDIS. Il test limiterà i miniport virtuali di test ricevono descrittori in modo che un numero significativo di indicazioni di ricezione si verificherà con il flag delle risorse di ricezione. Il test eseguirà quindi le azioni seguenti in modo multi thread:
Stressare il traffico dal miniport di supporto diretto al miniport di test.
Stress del traffico dal miniport di test diretto al miniport di supporto
Arrestare/avviare il miniport di test (che attiverà una pausa e le operazioni di riavvio successive).
Scheda di test che indica supporti disconnessi/connessi.
Reimpostazione dell'adattatore di test.
Infine, la connettività di trasmissione e ricezione di base verrà testata tra le schede di test/supporto.
NdkPerfLogoTests
Questo test garantisce che il traffico RDMA possa essere inviato e ricevuto betweeen la DUT e il computer di supporto. Questo test richiede che l'interfaccia di rete in DUT e il supporto siano abilitate per il traffico RDMA.
Il test esegue NdkPerfCmd.exe sia nel computer DUT che nel computer di supporto. Questo caricherà il driver ndkperf.sys che richiamerà le API NDK per inviare il traffico RDMA dalla DUT al computer di supporto.
Parametri
| Parametro | Descrizione |
|---|---|
ClientIf |
ID interfaccia della scheda di interfaccia di rete abilitata per RDMA nella DUT. Usare Get-NetAdapter per ottenere l'ID |
ClientAddr |
Indirizzo IP della scheda di interfaccia di rete abilitata per RDMA nella DUT. Usare ipconfig o Get-NetIpAddress per ottenere l'indirizzo IP |
SupportIf |
ID interfaccia della scheda di interfaccia di rete abilitata per RDMA nel computer di supporto. Usare Get-NetAdapter per ottenere l'ID |
SupportAddr |
Indirizzo IP della scheda di interfaccia di rete abilitata per RDMA nel computer di supporto. Usare ipconfig o Get-NetIpAddress per ottenere l'indirizzo IP |
Suggerimenti per gli errori di investimento:
Assicurarsi che entrambe le schede di interfaccia di rete siano abilitate per RDMA (Get-NetAdapterRdma)
Assicurarsi che i contatori attività RDMA incrementino durante l'invio del traffico RDMA
Provare a eseguire NdkPerfCmd.exe manualmente nel computer DUT/support. Se ha esito negativo, probabilmente si verifica un problema con i parametri o l'implemantion del driver di rete delle API NDK.