Requisitos previos de pruebas de LAN
En el contenido de esta sección se describen los requisitos previos de prueba de LAN (Ethernet) que debe completar antes de probar el adaptador de red mediante el Kit de laboratorio de hardware de Windows (Windows HLK).
Nota
Este contenido se aplica tanto a adaptadores de red independientes como a dispositivos de red integrados.
Términos del documento
| Rol de dispositivo | Alias de interfaz |
|---|---|
Máquina de prueba, destino de prueba (DUT) |
No es necesario ningún nombre, los trabajos de HLK lo elegirán automáticamente. |
Máquina de prueba, dispositivo de mensaje |
MessageDevice |
Equipo de soporte técnico, dispositivo de soporte técnico |
SupportDevice0 |
Equipo de soporte técnico, dispositivo de mensaje |
MessageDevice |
Controlador LWF |
Controlador de filtro de peso ligero NDIS |
Topología de máquina
En el diagrama siguiente se muestra la topología de máquina recomendada. Las topologías que difieren de esto son muy desaconsejadas, ya que pueden requerir un esfuerzo adicional para que las pruebas se ejecuten correctamente.
Esta es la topología que se aplica a todos los dispositivos LAN (incluidos los que admiten QoS y Chimney).
Topología de máquina para pruebas de adaptador de red
Las pruebas HLK desarrolladas recientemente con el prefijo "[Adaptador de red]" o "[nombre de la prueba]" en el título son pruebas de máquina únicas y requieren 3 adaptadores de red en esa máquina. Los nombres de alias de interfaz son los siguientes:
- TestDevice: este es el dispositivo de red sometido a prueba.
- SupportDevice0: se necesita una tarjeta de red de soporte adicional, conectada de vuelta a atrás con TestDevice
- MessageDevice: se usa para comunicarse con el controlador HLK.
En el diagrama siguiente se muestra la topología recomendada:
Probar conexiones
La conexión back-to-back es preferida en general, ya que quita la posibilidad de que el conmutador interfiera con la prueba (VLAN misconfiguraciones, paquetes de control de flujo, etc.)
Se requiere una conexión back-to-back para las pruebas que un conmutador de red puede interferir con el resultado. Estas pruebas incluyen:
QoS (también conocido como QoS). DCB) (control de flujo de prioridad, interoperabilidad LLDP/DCBX, ETS (dado que algunos modificadores pueden quitar etiquetas de 802.1p)
Control de flujo tx
Pruebas que envían 802.1q-tagged (VlanSendRecv, VMQ, 1c_priority, tal vez otros)
Red backchannel/corporativa
Se recomienda que el conmutador backchannel sea la misma red que usarán las máquinas de prueba para comunicarse con el controlador HLK. Se recomienda que esta red esté habilitada para DHCP.
Requisitos de la máquina
Los requisitos de la máquina suelen ser dictados por las características que admite el destino de prueba. La certificación en las SKU de cliente requerirá 2 núcleos de procesamiento, mientras que la certificación en las SKU del servidor requerirá 4 núcleos de procesamiento.
Nota
El término núcleos hace referencia a núcleos de procesamiento físico (no núcleos virtuales o hiperprocesos). Si el dispositivo admite características avanzadas como las siguientes, se pueden aumentar los requisitos mínimos del sistema.
Wake-on-LAN: el sistema debe admitir la administración de energía (S3)
RSS: máximo de 4 núcleos físicos o el número predeterminado de colas RSS compatibles con el dispositivo.
Ejemplo: si una NIC 1G admite 2 colas, el número de núcleos necesarios sería 4.
Ejemplo: si una NIC 10G admite 8 colas, el número de núcleos necesarios sería 8.
Servidor/QoS: los sistemas deben ser capaces de saturar el 90 % de la velocidad máxima de vínculo
QoS: el destino de almacenamiento escribe en el 20 % de la velocidad máxima de vínculo.
Nota
Si los problemas de pérdida de paquetes de envío o recepción se producen con frecuencia y a lo largo de la prueba, es probable que no sea un problema de suspensión selectiva.
Nota
Para certificar el producto para su uso en servidores, el equipo de prueba debe admitir cuatro procesadores y un mínimo de 1 GB de RAM. Estas funcionalidades del sistema son necesarias para probar la funcionalidad Rebalance, D3 State y Multiple Processor Group del dispositivo y el controlador. No necesita un equipo que tenga más de 64 procesadores para probar el dispositivo. Además, los sistemas de servidor que se usan para las pruebas de dispositivos o controladores deben tener Server Core instalado antes de las pruebas. Para obtener más información, vea Opciones de instalación de Windows Server.
Si usa un grupo de equipos de prueba para probar dispositivos, al menos un equipo del grupo debe contener cuatro procesadores y un mínimo de 1 GB de RAM. Además, ese equipo debe contener el dispositivo y el controlador que desea probar. Si el controlador es el mismo en todos los equipos del grupo, el sistema crea una programación para ejecutarse en todos los equipos de prueba.
En el caso de las pruebas que no incluyen un controlador para probar, como las pruebas de unidad de disco duro, el programador de HLK de Windows restringe las pruebas que validan el reequilibrio del dispositivo y el controlador, el estado D3 y varias funciones de grupos de procesadores para ejecutarse en el equipo de prueba predeterminado. Debe configurar manualmente este equipo para que tenga varios grupos de procesadores. El equipo predeterminado es el primer equipo de prueba de la lista. El personal de pruebas debe asegurarse de que el primer equipo de prueba de la lista cumple los requisitos mínimos de hardware.
Nota
Excepto para los controladores de para-virtualization (tal y como se define en el documento de directivas y procesos de WHCP ), no puede usar ninguna forma de virtualización al probar dispositivos físicos y sus controladores asociados para la certificación o firma del servidor. Todos los productos de virtualización no admiten la funcionalidad subyacente necesaria para pasar las pruebas relacionadas con varios grupos de procesadores, la administración de energía de dispositivos, la funcionalidad PCI del dispositivo y otras pruebas.
Nota
Configuración de varios grupos de procesadores Debe establecer el valor para el tamaño del grupo de procesadores para las pruebas del Kit de laboratorio de hardware de Windows Server 2008 R2 y versiones posteriores para la certificación. Para ello, ejecute bcdedit en una ventana del símbolo del sistema con privilegios elevados mediante la opción /set.
Los comandos para agregar la configuración del grupo y reiniciar son los siguientes:
bcdedit.exe /set groupsize 2
bcdedit.exe /set groupaware on
shutdown.exe -r -t 0 -f
Los comandos para quitar la configuración del grupo y reiniciar son los siguientes:
bcdedit.exe /deletevalue groupsize
bcdedit.exe /deletevalue groupaware
shutdown.exe -r -t 0 -f
Nota
Configuración de integridad de código
La característica Seguridad basada en virtualización (VBS) de Windows Server 2016 debe habilitarse primero mediante Administrador del servidor.
Una vez que se haya producido, se debe crear y establecer la siguiente clave del Registro:
HKLM\System\CurrentControlSet\Control\DeviceGuard
HypervisorEnforcedCodeIntegrity:REG_DWORD
0 or 1 (disabled, enabled)
Configuración de la máquina
Algunas pruebas requieren una configuración única que no es o no se puede encargar automáticamente de los trabajos de prueba. En la lista siguiente se describen las pruebas que requieren configuraciones únicas.
QosStorageInterop
El destino de prueba en la máquina DUT debe tener conectividad con el almacenamiento basado en red mediante iSCSI o SMB. La topología de la máquina de prueba es tal que la red de prueba está de vuelta a atrás, lo que significa que la máquina de soporte técnico también debe servir como destino de almacenamiento. Esto significa que se debe configurar un destino iSCSI de software en el SUT o se debe compartir un recurso compartido SMB. La máquina DUT debe asignar el destino de almacenamiento a una letra de unidad y el usuario debe asegurarse de que esta conexión fluye a través de la red de prueba y no de la red backchannel. Una vez configurado, debe especificar dos parámetros adicionales para este trabajo en el momento de la programación:
Letra de unidad
Modo de almacenamiento (iSCSI o ND (Network Direct))
Suspensión selectiva
La característica Suspensión selectiva de NDIS puede tener un impacto negativo en los resultados de las pruebas. Muchas de las pruebas de certificación de red asumen que un dispositivo está en un estado encendido y listo para usar. Por lo tanto, muchas de las pruebas pueden enviar o recibir tráfico rápidamente y esperar que todos los paquetes se envíen o reciban correctamente. Si un dispositivo está en baja potencia (suspensión selectiva), el dispositivo puede tardar un poco en reanudarse, lo que puede provocar la pérdida de paquetes durante el período de reanudación.
Microsoft recomienda configurar *SelectiveSuspend en deshabilitado (para controladores NDIS) o *IdleRestriction en habilitado (para controladores NetAdapterCx 2.2+) si se cumple lo siguiente (nota: no cambie el valor predeterminado, solo el valor operativo mientras se ejecutan las pruebas de certificación):
Un cliente tiene un dispositivo compatible con suspensión selectiva
Las pruebas de envío y recepción están experimentando problemas de pérdida de paquetes
Los problemas de pérdida de paquetes de prueba de envío o recepción solo se encuentran en la variación FIRST de una prueba determinada.
Como alternativa, la opción "Permitir que el equipo desactive este dispositivo para ahorrar energía" se puede desactivar en la pestaña Administración de energía de las propiedades de Administrador de dispositivos de la miniporte.
Pruebas de QOS de HW
Las pruebas "QoS*" de HW requieren que SR-IOV esté activo, con vPorts VF disponibles. En algún hardware, Hyper-V debe instalarse para que el adaptador de red habilite SR-IOV y anuncie la disponibilidad vPort de VF. Por lo tanto, se recomienda instalar Hyper-V antes de ejecutar las pruebas de QoS de HW.
Información general sobre los cambios en la selección de dispositivos de red
En el caso de las pruebas de dispositivos LAN, los adaptadores de mensaje y soporte técnico ya no se seleccionan mediante una interfaz de usuario, ya que se detectan automáticamente en función de la topología de red. Si se produce un error en la detección automática porque la topología de red es diferente de la topología recomendada, es necesario cambiar el nombre de los dispositivos en las máquinas de prueba y admitirlas antes de ejecutar pruebas. Cambiar el nombre hace referencia al "ifAlias" del dispositivo, que es visible desde la ventana Conexiones de red entre otros lugares.
Si se requiere cambiar el nombre, es necesario cambiar el nombre del dispositivo de soporte técnico en el equipo de soporte técnico a "SupportDevice0". Los dispositivos de mensaje de las máquinas de prueba y de soporte técnico deben cambiar el nombre a "MessageDevice".
Criterios de selección automática de dispositivos
Las máquinas de prueba y soporte técnico deben configurarse en la misma configuración que la figura 4 y todos los demás dispositivos o puertos Ethernet no implicados en las pruebas deben desconectarse o deshabilitarse. Los trabajos de prueba usan los siguientes criterios para buscar el dispositivo de mensaje: dispositivo Ethernet, vínculo conectado, habilitado, enlazado TCP, dirección IP asignada mediante DHCP. La detección incluirá adaptadores con direcciones IP estáticas si no se encuentra ningún adaptador con direcciones asignadas por DHCP. Normalmente, el adaptador de mensajes está conectado al controlador HLK y a la red corporativa normal. Una vez que se encuentra el dispositivo de mensaje, el trabajo busca en los adaptadores restantes un dispositivo de soporte técnico que es un dispositivo Ethernet, un vínculo conectado y habilitado.
Ejecución de las pruebas LAN en HLK
Consulte la ayuda de HLK para obtener información sobre cómo configurar el controlador y las máquinas cliente. Este documento solo trata sobre la ejecución del contenido de LAN en el HLK.
Una vez configuradas las máquinas de controlador y cliente, siga estos pasos para ejecutar las pruebas LAN:
Cree un proyecto en HLK Studio.
Cree un nuevo grupo de máquinas y agregue las máquinas cliente que se configuraron en el grupo recién creado y marque el estado de la máquina como listo.
Asegúrese de que la máquina de prueba y la máquina de soporte técnico están conectadas como se describe en la sección Criterios de selección de dispositivos anterior.
Seleccione solo el dispositivo o controlador que se va a probar (por ejemplo, el administrador de dispositivos o el dispositivo de software), en la pestaña Selección de HLK Studio.
Seleccione los trabajos que aparecen en la lista en la pestaña Pruebas de HLK Studio.
Haga clic en Ejecutar seleccionado y elija la máquina de soporte técnico para la ejecución de pruebas y haga clic en Aceptar.
Ejecución de pruebas de logotipo de filtro
Siga estos pasos para ejecutar pruebas de logotipo de filtro ligero (LWF):
Configure el servidor DTM y las máquinas cliente DTM. Las pruebas de logotipo de filtro solo necesitan la máquina cliente.
Instale el controlador LWF en el equipo cliente.
Reinicia el equipo cliente.
Desde el servidor DTM, agregue el cliente en el que se instala LWF en un nuevo grupo de máquinas y cambie el estado de la máquina a "Listo".
En HLK Studio, cree un proyecto en la pestaña "Proyecto" de HLK Studio.
En la pestaña "Selección" de HLK Studio, seleccione el grupo de máquinas que se creó en los pasos anteriores en la lista desplegable.
Haga clic en el dispositivo de software y seleccione el controlador LWF instalado que desea probar.
Ejecute todas las pruebas (la prueba de logotipo de LWF "NDISTest 6.5 - LWF" comprueba todos los requisitos de LWF) que se enumeran en la pestaña Pruebas del controlador LWF.
NDISTest 6.5: prueba del logotipo LWF
Esta prueba tiene como destino LWF asegurándose de que el filtro puede procesar paquetes mayores que el tamaño de MTU de miniporte.
Esto también ejecuta una prueba de esfuerzo de filtro para hacer hincapié en las rutas de acceso de datos y PNP de los controladores de filtro NDIS. La prueba limitará los miniportes virtuales de prueba reciben descriptores de modo que se produzca un número significativo de indicaciones de recepción con la marca de recursos de recepción. A continuación, la prueba realizará las siguientes acciones de forma multiproceso:
El tráfico de esfuerzo del miniporte de soporte dirigido al miniporte de prueba.
Tráfico de esfuerzo del miniporte de prueba dirigido al miniporte de soporte
Detenga o inicie el miniporte de prueba (que desencadenará una pausa y las operaciones de reinicio posteriores).
Adaptador de prueba que indica medios desconectados o conectados.
Restablecer el adaptador de prueba.
Por último, se probará la conectividad básica de envío y recepción entre los adaptadores de prueba y soporte técnico.
NdkPerfLogoTests
Esta prueba garantiza que el tráfico RDMA se pueda enviar y recibir betweeen el DUT y la máquina de soporte técnico. Esta prueba requiere que la interfaz de red tanto en DUT como en compatibilidad con el tráfico RDMA esté habilitada.
La prueba se ejecuta NdkPerfCmd.exe tanto en el DUT como en la máquina compatible. Esto cargará el controlador ndkperf.sys que invocará las API de NDK para enviar tráfico RDMA desde el DUT al equipo de soporte técnico.
Parámetros:
| Parámetro | Descripción |
|---|---|
ClientIf |
El identificador de interfaz de la NIC habilitada para RDMA en el DUT. Uso de Get-NetAdapter para obtener el identificador |
ClientAddr |
Dirección IP de la NIC habilitada para RDMA en el DUT. Uso de ipconfig o Get-NetIpAddress para obtener la dirección IP |
SupportIf |
Identificador de interfaz de la NIC habilitada para RDMA en el equipo de soporte técnico. Uso de Get-NetAdapter para obtener el identificador |
SupportAddr |
La dirección IP de la NIC habilitada para RDMA en el equipo de soporte técnico. Uso de ipconfig o Get-NetIpAddress para obtener la dirección IP |
Sugerencias para invertir errores:
Asegúrese de que ambas nics están habilitadas para RDMA (Get-NetAdapterRdma)
Asegúrese de que los contadores de perfmon de actividad de RDMA aumentan al enviar tráfico RDMA.
Intente ejecutar NdkPerfCmd.exe manualmente en la máquina dut/support. Si se produce un error, es probable que haya un problema con los parámetros o con la implemanción del controlador de red de las API de NDK.