Pré-requisitos de teste de LAN
O conteúdo desta seção descreve os pré-requisitos de teste de LAN (Ethernet) que você deve concluir antes de testar seu adaptador de rede usando o Windows Hardware Lab Kit (Windows HLK).
Observação
Esse conteúdo se aplica a adaptadores de rede autônomos e dispositivos de rede integrados.
Termos do Documento
| Função do dispositivo | Alias de Interface |
|---|---|
Computador de teste, destino de teste (DUT) |
Sem nome necessário, os trabalhos do HLK o escolherão automaticamente |
Computador de teste, dispositivo de mensagem |
MessageDevice |
Computador de suporte, dispositivo de suporte |
SupportDevice0 |
Computador de suporte, dispositivo de mensagem |
MessageDevice |
Driver LWF |
Driver de Filtro de Peso Leve do NDIS |
Topologia do computador
O diagrama a seguir mostra a topologia de computador recomendada. Topologias que diferem disso são altamente desencorajadas, pois podem exigir esforço extra para que os testes sejam executados corretamente.
Essa é a topologia que se aplica a todos os dispositivos LAN (incluindo dispositivos que dão suporte a QoS e Chaminé).
Topologia do computador para testes do Adaptador de Rede
Os testes HLK desenvolvidos recentemente prefixados com "[Adaptador de Rede]" ou "[nome do teste]" no título são testes de máquina única e exigem três adaptadores de rede nesse computador. Os nomes de alias da interface são os seguintes:
- TestDevice: esse é o dispositivo de rede em teste.
- SupportDevice0: rede de suporte adicional cartão necessária, conectada de volta para trás com TestDevice
- MessageDevice: usado para se comunicar com o controlador HLK.
O diagrama a seguir mostra a topologia recomendada:
Testar conexões
A conexão back-to-back é preferencial em geral, pois tira a possibilidade de o comutador interferir no teste (configurações incorretas de VLAN, pacotes de controle de fluxo e assim por diante)
Uma conexão back-to-back é necessária para testes que um comutador de rede pode interferir no resultado. Esses testes incluem:
QoS (também conhecido como . DCB) (controle de fluxo de prioridade, interoperabilidade LLDP/DCBX, ETS (como algumas opções podem remover marcas de 802,1p)
Controle de fluxo Tx
Testes que enviam 802.1q marcados (VlanSendRecv, VMQ, 1c_priority, talvez outros)
Rede backchannel/corporativa
É recomendável que a opção backchannel seja a mesma rede que os computadores de teste usarão para se comunicar com o controlador HLK. É recomendável que essa rede seja habilitada para DHCP.
Requisitos do computador
Os requisitos do computador geralmente são determinados pelos recursos aos quais o destino de teste dá suporte. A certificação em SKUs de cliente exigirá dois núcleos de processamento, enquanto a certificação em SKUs de servidor exigirá quatro núcleos de processamento.
Observação
O termo núcleos refere-se a núcleos de processamento físico (não núcleos virtuais ou hiper-threaded). Se o dispositivo der suporte a recursos avançados, como os abaixo, os requisitos mínimos do sistema poderão ser aumentados.
Wake-on-LAN: o sistema deve dar suporte ao gerenciamento de energia (S3)
RSS: máximo de 4 núcleos físicos ou o número padrão de filas RSS compatíveis com o dispositivo
Exemplo: se uma NIC 1G der suporte a 2 filas, o número de núcleos necessários será 4
Exemplo: se uma NIC de 10G der suporte a 8 filas, o número de núcleos necessários será 8
Servidor/QoS: os sistemas devem ser capazes de saturar 90% da taxa máxima de link
QoS: gravações de destino de armazenamento a 20% da taxa máxima de link
Observação
Se problemas de perda de pacote de envio/recebimento ocorrerem com frequência e durante todo o teste, provavelmente não será um problema de suspensão seletiva.
Observação
Para certificar seu produto para uso em servidores, o computador de teste deve dar suporte a quatro processadores e um mínimo de 1 GB de RAM. Esses recursos do sistema são necessários para testar a funcionalidade Rebalanceamento, Estado D3 e Grupo de Vários Processadores do dispositivo e do driver. Você não precisa de um computador com mais de 64 processadores para testar seu dispositivo. Além disso, os sistemas de servidor que estão sendo usados para teste de dispositivo ou driver devem ter o Server Core instalado antes do teste. Para obter mais informações, consulte Opções de instalação do Windows Server.
Se você usar um pool de computadores de teste para testar dispositivos, pelo menos um computador no pool deverá conter quatro processadores e um mínimo de 1 GB de RAM. Além disso, esse computador deve conter o dispositivo e o driver que você deseja testar. Se o driver for o mesmo em todos os computadores no pool, o sistema criará um agendamento para ser executado em todos os computadores de teste.
Para testes que não incluem um driver para testar, como testes de unidade de disco rígido, o agendador do Windows HLK restringe os testes que validam o rebalanceamento do dispositivo e do driver, o estado D3 e a funcionalidade de vários grupos de processadores a serem executados no computador de teste padrão. Você deve configurar manualmente este computador para ter vários grupos de processadores. O computador padrão é o primeiro computador de teste na lista. A equipe de teste deve verificar se o primeiro computador de teste na lista atende aos requisitos mínimos de hardware.
Observação
Exceto para drivers de para virtualização (conforme definido pelo documento Políticas e Processos whcp ), você pode não usar qualquer forma de virtualização ao testar dispositivos físicos e seus drivers associados para certificação ou assinatura de servidor. Todos os produtos de virtualização não dão suporte à funcionalidade subjacente necessária para passar nos testes relacionados a vários grupos de processadores, gerenciamento de energia do dispositivo, funcionalidade PCI do dispositivo e outros testes.
Observação
Configuração de vários grupos de processadores Você deve definir o valor para o tamanho do grupo de processadores para teste do Hardware Lab Kit do Windows Server 2008 R2 e drivers de dispositivo posteriores para certificação. Isso é feito executando bcdedit em uma janela de prompt de comandos com privilégios elevados, usando a opção /set.
Os comandos para adicionar as configurações de grupo e reiniciar são os seguintes:
bcdedit.exe /set groupsize 2
bcdedit.exe /set groupaware on
shutdown.exe -r -t 0 -f
Os comandos para remover as configurações de grupo e reinicialização são os seguintes:
bcdedit.exe /deletevalue groupsize
bcdedit.exe /deletevalue groupaware
shutdown.exe -r -t 0 -f
Observação
Configuração de integridade do código
O recurso de segurança baseada em virtualização (VBS) de Windows Server 2016 deve ser habilitado usando Gerenciador do Servidor primeiro.
Depois que isso ocorrer, a seguinte chave do Registro deverá ser criada e definida:
HKLM\System\CurrentControlSet\Control\DeviceGuard
HypervisorEnforcedCodeIntegrity:REG_DWORD
0 or 1 (disabled, enabled)
Configuração do computador
Alguns testes exigem uma configuração exclusiva que não é ou não pode ser cuidada automaticamente por trabalhos de teste. A lista abaixo descreve quais testes exigem configurações exclusivas.
QosStorageInterop
O destino de teste no computador DUT deve ter conectividade com o armazenamento baseado em rede usando iSCSI ou SMB. A topologia do computador de teste é tal que a rede de teste é back-to-back, o que significa que o computador de suporte também deve servir como um destino de armazenamento. Isso significa que um destino iSCSI de software deve ser configurado no SUT ou um compartilhamento SMB deve ser compartilhado. O computador DUT deve mapear o destino de armazenamento para uma letra de unidade e o usuário deve garantir que essa conexão flua pela rede de teste e não pela rede backchannel. Depois de configurado, você deve inserir dois parâmetros adicionais para esse trabalho no momento do agendamento:
Letra da unidade
Modo de armazenamento (iSCSI ou ND (Rede Direta))
Suspensão seletiva
O recurso de Suspensão Seletiva do NDIS pode ter um impacto negativo nos resultados do teste. Muitos dos testes de certificação de rede pressupõem que um dispositivo esteja em um estado ligado e pronto para uso. Portanto, muitos dos testes podem enviar ou receber tráfego rapidamente e esperar que todos os pacotes sejam enviados ou recebidos adequadamente. Se um dispositivo estiver em baixa potência (Suspensão Seletiva), poderá demorar um pouco para que o dispositivo seja retomado, o que pode resultar em perda de pacotes durante o período de retomada.
A Microsoft recomenda configurar *SelectiveSuspend para desabilitado (para drivers NDIS) ou *IdleRestriction para habilitado (para drivers NetAdapterCx 2.2+ se o seguinte for verdadeiro (observação: não altere o valor padrão, apenas o valor operacional durante a execução dos testes de certificação):
Um cliente tem um dispositivo com capacidade de suspensão seletiva
Os testes de envio/recebimento estão enfrentando problemas de perda de pacotes
Os problemas de perda de pacote de teste de envio/recebimento estão apenas na primeira variação de um determinado teste
Como alternativa, a opção "Permitir que o computador desative esse dispositivo para economizar energia" pode ser desmarcada na guia Gerenciamento de Energia das propriedades Gerenciador de Dispositivos do miniporto.
Testes de QOS do HW
Os testes "HW QoS*" exigem que o SR-IOV esteja ativo, com VF vPorts disponíveis. Em algum hardware, o Hyper-V precisa ser instalado para o adaptador de rede habilitar SR-IOV e anunciar a disponibilidade do VF vPort. Portanto, é recomendável que o Hyper-V seja instalado antes de executar os testes de "HW QoS".
Visão geral das alterações na seleção de dispositivo de rede
Para testes de dispositivo LAN, adaptadores de mensagem e suporte não são mais selecionados usando uma interface do usuário – eles são detectados automaticamente com base na topologia de rede. Se a detecção automática falhar porque a topologia de rede é diferente da topologia recomendada, os dispositivos precisam ser renomeados nos computadores de teste e suporte antes de executar testes. Renomear refere-se ao "ifAlias" do dispositivo, que é visível na janela Conexões de Rede, entre outros locais.
Se a renomeação for necessária, o dispositivo de suporte no computador de suporte precisará ser renomeado como "SupportDevice0". Os dispositivos de mensagem nos computadores de teste e suporte precisam ser renomeado como "MessageDevice".
Critérios de seleção automática de dispositivo
Os computadores de teste e suporte devem ser configurados na mesma configuração que a Figura 4 e todos os outros dispositivos/portas Ethernet não envolvidos no teste precisam ser desconectados ou desabilitados. Os trabalhos de teste usam os seguintes critérios para localizar o dispositivo de mensagem: dispositivo Ethernet, link conectado, habilitado, associado a TCP, endereço IP atribuído usando DHCP. A detecção incluirá adaptadores com endereços IP estáticos se nenhum adaptador estiver com endereços atribuídos a DHCP for encontrado. O adaptador de mensagem normalmente está conectado ao controlador HLK e à rede corporativa normal. Depois que o dispositivo de mensagem for encontrado, o trabalho pesquisa os adaptadores restantes para um dispositivo de suporte que seja um dispositivo Ethernet, um link conectado e habilitado.
Executando os testes de LAN no HLK
Consulte a ajuda do HLK para obter informações sobre como configurar o controlador e os computadores cliente. Este documento trata apenas da execução de conteúdo lan no HLK.
Depois que os computadores Controlador e Cliente estiverem configurados, siga estas etapas para executar os testes de LAN:
Crie um projeto no HLK Studio.
Crie um pool de computadores e adicione os computadores cliente que foram configurados para o pool recém-criado e marque o computador status como pronto.
Verifique se o computador de teste e o computador de suporte estão conectados conforme descrito na seção Critérios de Seleção de Dispositivo acima.
Selecione apenas o dispositivo/driver a ser testado (como o gerenciador de dispositivos ou o dispositivo de software), na guia Seleção do estúdio HLK.
Selecione os trabalhos que aparecem na lista na guia Testes do estúdio HLK.
Clique em Executar Selecionado, escolha o Computador de suporte para a execução de teste e clique em OK.
Executando testes de logotipo de filtro
Use as seguintes etapas para executar testes de logotipo de LWF (filtro leve):
Configure/configure o servidor DTM e os computadores cliente DTM. Os testes de logotipo de filtro precisam apenas de um computador cliente.
Instale o driver LWF no computador cliente.
Reiniciar o computador cliente.
No servidor DTM, adicione o cliente no qual o LWF está instalado em um novo pool de computadores e altere o computador status para "Pronto".
No HLK Studio, crie um novo projeto na guia "Projeto" no HLK Studio.
Na guia 'Seleção' do estúdio HLK, selecione o pool de computadores que foi criado nas etapas anteriores na lista suspensa.
Clique em dispositivo de software e selecione o driver LWF instalado que você deseja testar.
Execute todos os testes (o teste de logotipo 'NDISTest 6.5 – LWF' verifica todos os requisitos LWF) listados na guia Testes em relação ao driver LWF.
NDISTest 6.5 – Teste de logotipo LWF
Esse teste tem como destino o LWF, garantindo que o filtro seja capaz de processar pacotes maiores que o tamanho da MTU do miniporto.
Isso também executa um teste de estresse de filtro para enfatizar os caminhos de caminho de dados e PNP dos drivers de filtro NDIS. O teste limitará os miniportos virtuais de teste que recebem descritores de modo que um número significativo de indicações de recebimento ocorra com o sinalizador de recursos de recebimento. Em seguida, o teste realizará as seguintes ações de maneira multi-threaded:
Tráfego de estresse do miniporto de suporte direcionado para o miniporto de teste.
Tráfego de estresse do miniporto de teste direcionado para o miniporto de suporte
Pare/inicie o miniporto de teste (que disparará uma pausa e operações de reinicialização subsequentes).
Adaptador de teste que indica a mídia desconectada/conectada.
Testar a redefinição do adaptador.
Por fim, a conectividade básica de envio e recebimento será testada entre os adaptadores de teste/suporte.
NdkPerfLogoTests
Esse teste garante que o tráfego RDMA possa ser enviado e recebido no DUT e no computador de suporte. Esse teste requer que o adaptador de rede no DUT e o suporte sejam habilitados para tráfego RDMA.
O teste executa NdkPerfCmd.exe no DUT e no computador de suporte. Isso carregará o driver ndkperf.sys que invocará as APIs do NDK para enviar o tráfego RDMA do DUT para o computador de suporte.
Parâmetros:
| Parâmetro | Descrição |
|---|---|
ClientIf |
A ID da interface da NIC habilitada para RDMA no DUT. Use Get-NetAdapter para obter a ID |
ClientAddr |
O endereço IP da NIC habilitada para RDMA no DUT. Usar ipconfig ou Get-NetIpAddress para obter o endereço IP |
SupportIf |
A ID da interface da NIC habilitada para RDMA no computador de suporte. Use Get-NetAdapter para obter a ID |
SupportAddr |
O endereço IP da NIC habilitada para RDMA no computador de suporte. Usar ipconfig ou Get-NetIpAddress para obter o endereço IP |
Dicas para investir falhas:
Verifique se ambas as nics estão habilitadas para RDMA (Get-NetAdapterRdma)
Verifique se os contadores de perfmon da atividade RDMA são incrementados ao enviar tráfego RDMA
Tente executar NdkPerfCmd.exe manualmente no computador DUT/suporte. Se ele falhar, provavelmente haverá um problema com os parâmetros ou a implemanção do Driver de Rede das APIs NDK.