Compartir vía

Solución de problemas de la pila de redes definida por software de Windows Server

  • Artículo

En esta guía se examinan los errores y escenarios de errores habituales de las Redes definidas por software (SDN) y se describe un flujo de trabajo de solución de problemas que usa las herramientas de diagnóstico disponibles. Para más información sobre las SDN, consulte Redes definidas por software.

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versiones 21H2 y 20H2

Tipos de errores

En la siguiente lista se representa el tipo de problemas que se ven con frecuencia con la Virtualización de red de Hyper-V (HNVv1) en Windows Server 2012 R2 a partir de implementaciones de producción en el mercado, y coincide de muchas maneras con los mismos tipos de problemas detectados en Windows Server 2016 HNVv2 con la nueva Pila de redes definidas por software (SDN).

La mayoría de los errores se pueden clasificar en un pequeño conjunto de clases:

  • Configuración no válida o no admitida

    Un usuario invoca la API NorthBound incorrectamente o con una directiva no válida.

  • Error en la aplicación de directiva

    La directiva de controladora de red no se entregó a un host de Hyper-V, se retrasó o no se actualizó en todos los hosts de Hyper-V (por ejemplo, después de una migración en vivo).

  • Desfase de configuración o error de software

    Problemas de ruta de acceso de datos que dan lugar a paquetes descartados.

  • Error externo relacionado con el hardware o los controladores de NIC o el tejido de red subyacente

    Descargas de tareas de comportamiento erróneo (como VMQ) o tejido de red subyacente mal configurado (como MTU)

    Esta guía de solución de problemas examina cada una de estas categorías de errores y ofrece procedimientos recomendados y herramientas de diagnóstico disponibles para identificar y corregir el error.

Herramientas de diagnóstico

Antes de analizar los flujos de trabajo de solución de problemas en cada uno de estos tipos de errores, vamos a examinar las herramientas de diagnóstico disponibles.

Para usar las herramientas de diagnóstico de controladora de red (ruta de control), primero debe instalar la RSAT-NetworkController característica e importar el NetworkControllerDiagnostics módulo:

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

Para usar las herramientas de diagnóstico del Diagnóstico de HNV (ruta de acceso de datos), debe importar el módulo HNVDiagnostics:

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

Diagnóstico de controladora de red

Estos cmdlets se documentan en TechNet en el cmdlet diagnóstico de controladora de red. Ayudan a identificar problemas con la coherencia de la directiva de red en la ruta de acceso de control entre los nodos de la Controladora de red y entre la Controladora de red y los Agentes del host de la NC que se ejecutan en los hosts de Hyper-V.

Los Debug-ServiceFabricNodeStatus cmdlets y Get-NetworkControllerReplica deben ejecutarse desde una de las máquinas virtuales del nodo controladora de red. Todos los demás cmdlets de Diagnóstico de NC se pueden ejecutar desde cualquier host, que tiene conectividad con la Controladora de red y se encuentra en el grupo de seguridad Administración de controladoras de red (Kerberos) o tiene acceso al certificado X.509 para administrar la Controladora de red.

Diagnóstico de host de Hyper-V

Estos cmdlets se documentan en TechNet en el cmdlet de diagnóstico de virtualización de red de Hyper-V (HNV). Ayudan a identificar problemas en la ruta de acceso de datos entre las máquinas virtuales de inquilino (Este/Oeste) y el tráfico de entrada a través de una VIP de SLB (Norte/Sur).

Los Debug-VirtualMachineQueueOperation, Get-CustomerRoute, Get-PACAMapping, Get-ProviderAddress, Get-VMNetworkAdapterPortId, Get-VMSwitchExternalPortIdy Test-EncapOverheadSettings son todas las pruebas locales que se pueden ejecutar desde cualquier host de Hyper-V. Los otros cmdlets invocan pruebas de ruta de acceso de datos a través de la Controladora de red y, por tanto, necesitan acceso a la Controladora de red, como se ha descrito anteriormente.

GitHub

El repositorio de GitHub de Microsoft/SDN tiene muchos scripts y flujos de trabajo de ejemplo que se basan en estos cmdlets incluidos. En concreto, los scripts de diagnóstico se pueden encontrar en la carpeta Diagnósticos. Ayúdenos a mejorar estos scripts enviando solicitudes de cambios.

Solución de problemas de flujos de trabajo y guías

[Hoster] Validar el estado del sistema

Hay un recurso integrado denominado Estado de configuración en varios de los recursos de la Controladora de red. El estado de configuración proporciona información sobre el estado del sistema, incluida la coherencia entre la configuración de la controladora de red y el estado en la práctica (en ejecución) en los hosts de Hyper-V.

Para comprobar el estado de la configuración, ejecute lo siguiente desde cualquier host de Hyper-V con conectividad a la Controladora de red.

Nota

El valor del NetworkController parámetro debe ser el FQDN o la dirección IP en función del nombre del firmante del certificado X.509 >creado para controladora de red.

El Credential parámetro solo debe especificarse si la controladora de red usa la autenticación Kerberos (típica en las implementaciones de VMM). La credencial debe ser para un usuario que se encuentre en el Grupo de seguridad de administración de controladoras de red.

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

A continuación se muestra un mensaje de ejemplo de Estado de configuración:

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

Nota

Hay un error en el sistema que lleva a que los recursos de la Interfaz de red para SLB Mux Transit VM NIC estén en un estado de error con el error "Conmutador virtual: host no conectado a la controladora". Este error se puede omitir de forma segura si la configuración de IP del recurso NIC de la máquina virtual está establecida en una dirección IP del grupo de direcciones IP de la red lógica de tránsito.

Hay un segundo error en el sistema que lleva a que los recursos de la Interfaz de red para los NIC de máquina virtual del proveedor HNV de puerta de enlace estén en un estado de error con el error "Virtual Switch - PortBlocked". Este error también se puede omitir de forma segura si la configuración de IP en el recurso NIC de máquina virtual está establecida en NULL (por diseño).

En la siguiente tabla se muestra la lista de códigos de error, mensajes y acciones de seguimiento que se deben realizar en función del estado de configuración observado.

Código Message Action
Desconocido Error desconocido
HostUnreachable No se puede acceder a la máquina host Compruebe la conectividad de red de Administración entre la Controladora de red y el Host
PAIpAddressExhausted Direcciones IP de PA agotadas Aumente el tamaño del grupo de direcciones IP de la subred lógica del proveedor HNV
PAMacAddressExhausted Direcciones Mac de PA agotadas Aumente el intervalo de grupos de Mac
PAAddressConfigurationFailure No se pudieron asociar las direcciones PA con el host Compruebe la conectividad de red de Administración entre la Controladora de red y el Host.
CertificateNotTrusted El certificado no es de confianza Corrija los certificados que se usan para la comunicación con el host.
CertificateNotAuthorized Certificado no autorizado Corrija los certificados que se usan para la comunicación con el host.
PolicyConfigurationFailureOnVfp Error al configurar directivas de VFP Se trata de un error en tiempo de ejecución. No hay soluciones alternativas definitivas. Recopile los registros.
PolicyConfigurationFailure Error al insertar directivas en los hosts, debido a errores de comunicación u otros errores en NetworkController. No hay acciones definitivas. Esto se debe a un error en el procesamiento de estado objetivo en los módulos de la Controladora de red. Recopile los registros.
HostNotConnectedToController El Host aún no está conectado a la Controladora de red El perfil de puerto no se aplica en el host o el host no es accesible desde la Controladora de red. Valide que la clave del registro de HostID coincida con el id. de instancia del recurso del servidor
MultipleVfpEnabledSwitches Hay varios conmutadores habilitados para VFp en el host Elimine uno de los conmutadores, ya que el Agente de host de la Controladora de red solo admite un vSwitch con la extensión VFP habilitada
PolicyConfigurationFailure No se han podido insertar directivas VNet en un VmNic debido a errores del certificado o en la conectividad Compruebe si se han implementado los certificados adecuados (el nombre del firmante del certificado debe coincidir con el FQDN del host). Compruebe también la conectividad del host con la Controladora de red
PolicyConfigurationFailure No se han podido insertar directivas de firewall en un VmNic debido a errores del certificado o en la conectividad Compruebe si se han implementado los certificados adecuados (el nombre del firmante del certificado debe coincidir con el FQDN del host). Compruebe también la conectividad del host con la Controladora de red
PolicyConfigurationFailure Failed to push Firewall policies for a VmNic due to certificate errors or connectivity errors (No se pudieron insertar directivas de firewall para una VmNic debido a errores de certificado o errores de conectividad) Compruebe si se han implementado los certificados adecuados (el nombre del firmante del certificado debe coincidir con el FQDN del host). Compruebe también la conectividad del host con la Controladora de red
DistributedRouterConfigurationFailure No se han podido configurar los valores del enrutador distribuido en el vNic del host Error en la pila de TCPIP. Puede requerir la limpieza de los vNIC del host de DR y PA en el servidor en el que se notificó este error
DhcpAddressAllocationFailure Error de asignación de direcciones DHCP para un VMNic Compruebe si el atributo de dirección IP estática está configurado en el recurso de NIC
CertificateNotTrusted
CertificateNotAuthorized		 No se pudo conectar a Mux debido a errores de red o de certificado Compruebe el código numérico proporcionado en el código del mensaje de error: corresponde al código de error de winsock. Los errores de certificado son granulares (por ejemplo, el certificado no se puede comprobar, el certificado no está autorizado, etc.).
HostUnreachable El MUX es incorrecto (el caso habitual se da porque el BGPRouter está desconectado) El par BGP en el RRAS (máquina virtual BGP) o en el conmutador de la parte superior del rack (ToR) no es accesible o no se puede emparejar correctamente. Compruebe los ajustes de BGP tanto en el recurso Multiplexor de Software Load Balancer como en el par BGP (máquina virtual ToR o RRAS)
HostNotConnectedToController El agente del host de SLB no está conectado Compruebe que el servicio del agente del host de SLB se está ejecutando. Consulte los registros del agente del host de SLB (ejecución automática) para saber los motivos; en caso de que SLBM (NC) rechace el certificado presentado por el agente del host, el estado de ejecución mostrará información matizada
PortBlocked El puerto VFP está bloqueado, debido a la falta de directivas de red virtual o ACL Compruebe si hay otros errores que puedan hacer que las directivas no estén configuradas.
Sobrecargado El MUX del equilibrador de carga está sobrecargado Problema de rendimiento con el MUX
RoutePublicationFailure El MUX del equilibrador de carga no está conectado a un enrutador BGP Compruebe si el MUX tiene conectividad con los enrutadores BGP y que el emparejamiento BGP está configurado correctamente
VirtualServerUnreachable El MUX del equilibrador de carga no está conectado al administrador de SLB Compruebe la conectividad entre SLBM y MUX
QosConfigurationFailure No se han podido configurar las directivas de QOS Compruebe si hay suficiente ancho de banda disponible para todas las máquinas virtuales si se usa la reserva de QOS

Comprobación de la conectividad de red entre la controladora de red y el host de Hyper-V (servicio del agente del host de la NC)

Ejecute el netstat comando siguiente para validar que hay tres ESTABLISHED conexiones entre el agente de host nc y los nodos de controlador de red y un LISTENING socket en el host de Hyper-V.

  • Puerto TCP:6640 en LISTENING en el host de Hyper-V (servicio de agente del host de la NC)
  • Dos conexiones establecidas desde la dirección IP del host de Hyper-V en el puerto 6640 a la dirección IP del nodo NC en puertos efímeros (> 32000)
  • Una conexión establecida desde la dirección IP del host de Hyper-V en el puerto efímero a la dirección IP de REST de la controladora de red en el puerto 6640

Nota

Solo puede haber dos conexiones establecidas en un host de Hyper-V si no hay ninguna máquina virtual de inquilino implementada en ese host determinado.

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

Comprobación de los servicios del agente de host

La controladora de red se comunica con dos servicios de agente de host en los hosts de Hyper-V: agente de host de SLB y agente de host de NC. Es posible que uno de estos servicios, o ambos, no se estén ejecutando. Compruebe su estado y reinícielos si no se están ejecutando.

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

Comprobación del estado de la controladora de red

Si no hay tres ESTABLISHED conexiones o si la controladora de red no responde, compruebe que todos los nodos y módulos de servicio están en funcionamiento mediante los siguientes cmdlets.

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

Los módulos de servicio de controladora de red son:

  • ControllerService
  • ApiService
  • SlbManagerService
  • ServiceInsertion
  • FirewallService
  • VSwitchService
  • GatewayManager
  • FnmService
  • HelperService
  • UpdateService

Compruebe que ReplicaStatus es Ready y HealthState es Ok.

En una implementación de producción se encuentra con una controladora de red de varios nodos, también puede comprobar en qué nodo cada servicio es principal y su estado de réplica individual.

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

Compruebe que el Estado de réplica sea Preparado en cada servicio.

Comprobación de los identificadores de host y los certificados correspondientes entre la controladora de red y cada host de Hyper-V

En un host de Hyper-V, ejecute los siguientes cmdlets para comprobar que hostID corresponde al identificador de instancia de un recurso de servidor en la controladora de red.

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties       : Microsoft.Windows.NetworkController.ServerProperties

Corrección

Si usa scripts SDNExpress o implementación manual, actualice la clave HostId del Registro para que coincida con el identificador de instancia del recurso del servidor. Reinicie el Agente del host de la Controladora de red en el host de Hyper-V (servidor físico). Si usa VMM, elimine el servidor de Hyper-V de VMM y quite la clave del registro de HostId. A continuación, vuelva a agregar el servidor a través de VMM.

Compruebe que las huellas digitales de los certificados X.509 usados por el host de Hyper-V (el nombre de host será el nombre del firmante del certificado) para la comunicación (SouthBound) entre el host de Hyper-V (servicio del agente del host de NC) y los nodos de la Controladora de red son las mismas. Compruebe también que el certificado REST de la controladora de red tiene el nombre del firmante de CN=<FQDN or IP>.

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

También puede comprobar los siguientes parámetros de cada certificado para asegurarse de que el nombre del firmante es lo que se espera (nombre de host o FQDN rest nc o IP), el certificado aún no ha expirado y que todas las entidades de certificación de la cadena de certificados se incluyen en la entidad raíz de confianza.

  • Nombre del firmante
  • Fecha de expiración
  • Tiene la confianza de la entidad raíz

Si varios certificados tienen el mismo nombre de sujeto en el host de Hyper-V, el Agente host de controladora de red elegirá aleatoriamente uno para presentarlo a la controladora de red. Esto podría no coincidir con la huella digital del recurso de servidor conocido por la controladora de red. En este caso, elimine uno de los certificados con el mismo nombre de sujeto en el host de Hyper-V y reinicie el servicio del Agente del host de la Controladora de red. Si todavía no se puede establecer una conexión, elimine el otro certificado con el mismo nombre de sujeto en el host de Hyper-V y elimine el recurso de servidor correspondiente en VMM. Después, vuelva a crear el recurso de servidor en VMM, que generará un nuevo certificado X.509 y lo instalará en el host de Hyper-V.

Comprobación del estado de configuración de SLB

El estado de configuración de SLB se puede determinar como parte de la salida del Debug-NetworkController cmdlet. Este cmdlet también generará el conjunto actual de recursos de Controladora de red en archivos JSON, todas las configuraciones IP de cada host de Hyper-V (servidor) y la directiva de red local de las tablas de base de datos del Agente de host.

Se recopilarán más seguimientos de manera predeterminada. Para no recopilar seguimientos, agregue el -IncludeTraces:$false parámetro .

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

Nota

La ubicación de salida predeterminada será <directorio_en_activo>\NCDiagnostics\ directorio. El directorio de salida predeterminado se puede cambiar mediante el parámetro -OutputDirectory.

La información de estado de configuración de SLB se puede encontrar en el archivo diagnostics-slbstateResults.Json de este directorio.

Este archivo JSON se puede dividir en las siguientes secciones:

  • Tejido
    • SlbmVips: en esta sección se muestra la dirección IP de la dirección VIP del administrador de SLB, utilizada por la Controladora de red para coordinar la configuración y el estado entre los Muxes de SLB y los Agentes del host de SLB.
    • MuxState: en esta sección se mostrará un valor para cada Mux de SLB implementado, lo que proporciona el estado del mux
    • Configuración del enrutador: esta sección enumerará el número de sistema autónomo (ASN) del enrutador ascendente (par BGP), la dirección IP de tránsito y el identificador. También enumerará el ASN de los Muxes de SLB y la dirección IP de tránsito.
    • Información del host conectado: en esta sección se mostrará la dirección IP de administración de todos los hosts de Hyper-V disponibles para ejecutar cargas de trabajo con equilibrio de carga.
    • Intervalos vip: en esta sección se mostrarán los intervalos de grupos de direcciones IP de VIP públicas y privadas. La VIP de SLBM se incluirá como una dirección IP asignada de uno de estos intervalos.
    • Rutas Mux: en esta sección se mostrará un valor para cada Mux de SLB implementado que contenga todos los anuncios de ruta para ese mux concreto.
  • Inquilino
    • VipConsolidatedState: en esta sección se enumerará el estado de conectividad de cada VIP de inquilino, incluido el prefijo de ruta anunciado, el host de Hyper-V y los puntos de conexión DIP.

Nota

El estado de SLB se puede determinar directamente mediante el script DumpSlbRestState disponible en el repositorio de GitHub de Microsoft SDN.

Validación de puerta de enlace

Desde la controladora de red:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

Desde la máquina virtual de puerta de enlace:

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

Desde la parte superior del conmutador de bastidor (ToR):

sh ip bgp summary (for 3rd party BGP Routers)

Enrutador BGP de Windows:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Además de estos motivos, a partir de los problemas que hemos visto hasta ahora (especialmente en las implementaciones basadas en SDNExpress), la razón más habitual de que el Compartimiento de inquilinos no se configure en VM de GW parece ser el hecho de que la Capacidad de GW en FabricConfig.psd1 es inferior en comparación con lo que los usuarios intentan asignar a las Conexiones de red (túneles S2S) en TenantConfig.psd1. Esto se puede comprobar fácilmente comparando las salidas de los siguientes cmdlets:

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Proveedor de servicios de hosting] Validación del plano de datos

Una vez implementada la Controladora de red, creadas las subredes y redes virtuales de inquilinos y conectadas las VM a las subredes virtuales, el proveedor de servicios de hosting puede realizar pruebas adicionales a nivel de tejido para comprobar la conectividad del inquilino.

Comprobación de la conectividad de red lógica del proveedor de HNV

Después de que la primera máquina virtual invitada que se ejecuta en un host de Hyper-V se haya conectado a una red virtual de inquilino, la Controladora de red asignará dos direcciones IP del proveedor HNV (direcciones IP de PA) al host de Hyper-V. Estas direcciones IP provendrán del grupo de direcciones IP de la red lógica del proveedor HNV y serán administradas por la Controladora de red. Para averiguar cuáles son estas dos direcciones IP de HNV:

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

Estas direcciones IP del proveedor HNV (IP de PA) se asignan a adaptadores Ethernet creados en un compartimiento de red TCPIP independiente y tienen un nombre de adaptador de VLANX donde X es la VLAN asignada a la red lógica del proveedor HNV (transporte).

La conectividad entre dos hosts de Hyper-V mediante la red lógica del proveedor HNV se puede realizar mediante un ping con un parámetro de compartimiento adicional (-c Y), donde Y es el compartimiento de red TCPIP en el que se crean los PAhostVNIC. Este compartimiento se puede determinar ejecutando:

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

Nota

Los adaptadores de vNIC de host de PA no se usan en la ruta de acceso de datos y, por tanto, no tienen una dirección IP asignada al adaptador "vEthernet (PAhostVNic)".

Por ejemplo, supongamos que los hosts de Hyper-V 1 y 2 tienen direcciones IP del proveedor de HNV (PA):

Host de Hyper-V Dirección IP de PA 1 Dirección IP de PA 2
Host 1 10.10.182.64 10.10.182.65
Host 2 10.10.182.66 10.10.182.67

podemos hacer ping entre los dos mediante el siguiente comando para comprobar la conectividad de red lógica del proveedor HNV.

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

Corrección

Si el ping del proveedor de HNV no funciona, compruebe la conectividad de red física, incluida la configuración de VLAN. Los NIC físicos de cada host de Hyper-V deben estar en modo troncal sin ninguna VLAN específica asignada. El vNIC del host de Administración debe aislarse en la VLAN de la red lógica de Administración.

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

Comprobación de la compatibilidad de MTU y marco jumbo en la red lógica del proveedor HNV

Otro problema común en la red lógica del proveedor de HNV es que los puertos de red físicos o la tarjeta Ethernet no tienen una MTU suficientemente grande configurada para controlar la sobrecarga de la encapsulación de VXLAN (o NVGRE).

Nota

Algunas tarjetas Ethernet y controladores admiten la nueva *EncapOverhead palabra clave que establecerá automáticamente el agente host de controladora de red en un valor de 160. A continuación, este valor se agregará al valor de la palabra clave *JumboPacket, cuya suma se usa como el MTU anunciado.

Por ejemplo, *EncapOverhead = 160 y *JumboPacket = 1514 => MTU = 1674B

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

Para probar si la red lógica del proveedor de HNV admite o no el tamaño de MTU más grande de un extremo a otro, use el Test-LogicalNetworkSupportsJumboPacket cmdlet :

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

Corrección

  • Ajuste el tamaño del MTU en los puertos del conmutador físico para que sea al menos 1674B (incluido el encabezado Ethernet de 14B y el finalizador)
  • Si la tarjeta NIC no admite la palabra clave EncapOverhead, ajuste la palabra clave JumboPacket para que sea al menos 1674B

Comprobación de la conectividad de NIC de máquina virtual de inquilino

Cada NIC de VM que se asigna a una máquina virtual invitada tiene una asignación de CA-PA entre la dirección privada del cliente (CA) y el espacio de direcciones de proveedor (PA) de HNV. Estas asignaciones se mantienen en las tablas del servidor OVSDB en cada host de Hyper-V y se pueden encontrar ejecutando el siguiente cmdlet.

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

Nota

Si las asignaciones de CA-PA que espera no son salidas para una máquina virtual de inquilino determinada, compruebe los recursos de configuración de IP y NIC de máquina virtual en la controladora de red mediante el Get-NetworkControllerNetworkInterface cmdlet . Además, compruebe las conexiones establecidas entre el agente de host de NC y los nodos de la Controladora de red.

Con esta información, ahora el hoster puede iniciar un ping de máquina virtual de inquilino desde la controladora de red mediante el Test-VirtualNetworkConnection cmdlet .

Escenarios de solución de problemas específicos

En las siguientes secciones se proporcionan instrucciones para solucionar problemas de escenarios específicos.

No hay conectividad de red entre dos máquinas virtuales de inquilino

  1. [Inquilino] Asegúrese de que el Firewall de Windows en máquinas virtuales de inquilino no bloquea el tráfico.
  2. [Inquilino] Compruebe que las direcciones IP se han asignado a la máquina virtual del inquilino mediante la ejecución ipconfigde .
  3. [Hoster] Ejecute Test-VirtualNetworkConnection desde el host de Hyper-V para validar la conectividad entre las dos máquinas virtuales de inquilino en cuestión.

Nota

El VSID hace referencia al id. de subred virtual. En el caso de VXLAN, este es el Identificador de red VXLAN (VNI). Para encontrar este valor, ejecute el Get-PACAMapping cmdlet .

Ejemplo

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

Cree CA-ping entre "Green Web VM 1" con una IP de SenderCA de 192.168.1.4 en el Host "sa18n30-2.sa18.nttest.microsoft.com" con una IP de Mgmt de 10.127.132.153 a una IP de ListenerCA de 192.168.1.5, ambas conectadas a la Subred virtual (VSID) 4114.

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[Inquilino] Compruebe que no hay ninguna directiva de firewall distribuida especificada en la subred virtual o en las interfaces de red de máquina virtual que bloquearían el tráfico.

Consulte la API de REST de la Controladora de red que se encuentra en el entorno de demostración de sa18n30nc en el dominio sa18.nttest.microsoft.com.

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

Examine la configuración de IP y las subredes virtuales que hacen referencia a esta ACL.

  1. [Proveedor de servicios de hosting] Ejecute Get-ProviderAddress en los hosts de Hyper-V que hospedan las dos máquinas virtuales de inquilino en cuestión y, después, ejecute Test-LogicalNetworkConnection o ping -c <compartment> desde el host de Hyper-V para validar la conectividad en la red lógica del proveedor HNV
  2. [Proveedor de servicios de hosting] Asegúrese de que la configuración de MTU sea correcta en los hosts de Hyper-V y en los dispositivos de conmutación de nivel 2 que se encuentran entre los hosts de Hyper-V. Ejecute Test-EncapOverheadValue en todos los hosts de Hyper-V en cuestión. Compruebe también si todos los conmutadores de nivel 2 de ese intervalo tienen el MTU establecido en al menos 1674 bytes para aguantar una sobrecarga máxima de 160 bytes.
  3. [Proveedor de servicios de hosting] Si las direcciones IP de PA no están presentes o se interrumpe la conectividad de CA, compruebe para asegurarse de que se ha recibido la directiva de red. Ejecute Get-PACAMapping para ver si las reglas de encapsulación y las asignaciones de CA-PA necesarias para crear redes virtuales superpuestas están establecidas correctamente.
  4. [Proveedor de servicios de hosting] Compruebe que el agente de host de la Controladora de red esté conectado a la Controladora de red. Para ello, ejecute netstat -anp tcp |findstr 6640.
  5. [Proveedor de servicios de hosting] Compruebe que el id. de host de HKLM/ coincide con el id. de instancia de los recursos del servidor que hospedan las máquinas virtuales del inquilino.
  6. [Proveedor de servicios de hosting] Compruebe que el id. de perfil de puerto coincide con el id. de instancia de las interfaces de red de VM de las máquinas virtuales del inquilino.

Registro, seguimiento y diagnóstico avanzado

En las siguientes secciones se proporciona información sobre diagnósticos avanzados, registro y seguimiento.

Registro centralizado de la controladora de red

La Controladora de red puede recopilar automáticamente los registros del depurador y almacenarlos en una ubicación centralizada. La recopilación de registros se puede habilitar al implementar la Controladora de red por primera vez o en cualquier momento posterior. Los registros se recopilan de la Controladora de red y los elementos de red administrados por la Controladora de red: equipos host, equilibradores de carga de software (SLB) y máquinas de puerta de enlace.

Estos registros incluyen registros de depuración para el clúster de Controladora de red, la aplicación de la Controladora de red, los registros de puerta de enlace, el SLB, las redes virtuales y el firewall distribuido. Cada vez que se agrega un nuevo host, SLB o puerta de enlace a la Controladora de red, se inicia el registro en esas máquinas. De forma similar, cuando se quita un host, SLB o puerta de enlace de la Controladora de red, se detiene el registro en esas máquinas.

Habilitar registro

El registro se habilita automáticamente al instalar el clúster de Controladora de red mediante el Install-NetworkControllerCluster cmdlet . De manera predeterminada, los registros se recopilan localmente en los nodos de la Controladora de red en %systemdrive%\SDNDiagnostics. Se recomienda cambiar esta ubicación para que sea un recurso compartido de archivos remoto (no local).

Los registros del clúster de la Controladora de red se almacenan en %programData%\Windows Fabric\log\Traces. Puede especificar una ubicación centralizada para la recopilación de registros con el parámetro con la DiagnosticLogLocation recomendación de que también sea un recurso compartido de archivos remoto.

Si desea restringir el acceso a esta ubicación, puede proporcionar las credenciales de acceso con el LogLocationCredential parámetro . Si proporciona las credenciales para acceder a la ubicación del registro, también debe proporcionar el CredentialEncryptionCertificate parámetro , que se usa para cifrar las credenciales almacenadas localmente en los nodos de controlador de red.

Con la configuración predeterminada, se recomienda tener al menos 75 GB de espacio libre en la ubicación central y 25 GB en los nodos locales (si no se usa una ubicación central) para un clúster de Controladora de red de tres nodos.

Cambio de la configuración del registro

Puede cambiar la configuración del registro en cualquier momento mediante el cmdlet Set-NetworkControllerDiagnostic. Se pueden cambiar los siguientes valores:

  • Ubicación de registro centralizada.

    Puede cambiar la ubicación para almacenar todos los registros, con el parámetro DiagnosticLogLocation.

  • Credenciales para acceder a la ubicación del registro.

    Puede cambiar las credenciales para acceder a la ubicación del registro, con el parámetro LogLocationCredential.

  • Pase a un registro local.

    Si ha proporcionado una ubicación centralizada para almacenar los registros, puede volver al registro local en los nodos de la Controladora de red con el parámetro UseLocalLogLocation (no se recomienda debido a los requisitos de que haya un gran espacio en disco).

  • Ámbito del registro.

    De manera predeterminada, se recopilan todos los registros. Puede cambiar el ámbito para recopilar solo los registros del clúster de Controladora de red.

  • Nivel del registro.

    El nivel del registro predeterminado es Informativo. Puede cambiarlo a Error, Advertencia o Detallado.

  • Tiempo de antigüedad del registro.

    Los registros se almacenan de forma circular. De manera predeterminada, tiene tres días de datos de registro, tanto si usa el registro local como el centralizado. Puede cambiar este límite de tiempo con el LogTimeLimitInDays parámetro .

  • Tamaño de antigüedad del registro.

    De manera predeterminada, tendrá un máximo de 75 GB de datos de registro si usa el registro centralizado y 25 GB si usa el registro local. Puede cambiar este límite con el LogSizeLimitInMBs parámetro .

Recopilación de registros y seguimientos

Las implementaciones de VMM usan el registro centralizado para la Controladora de red de manera predeterminada. La ubicación del recurso compartido de archivos para estos registros se especifica al implementar la plantilla de servicio de la Controladora de red.

Si no se ha especificado una ubicación de archivo, el registro local se usará en cada nodo de controlador de red con registros guardados en C:\Windows\tracing\SDNDiagnostics. Estos registros se guardan con la siguiente jerarquía:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Traces

La Controladora de red usa Service Fabric (de Azure). Es posible que se necesiten registros de Service Fabric al solucionar determinados problemas. Estos registros se pueden encontrar en cada nodo de controladora de red en C:\ProgramData\Microsoft\Service Fabric.

Si un usuario ha ejecutado el Debug-NetworkController cmdlet, habrá más registros disponibles en cada host de Hyper-V, que se ha especificado con un recurso de servidor en la controladora de red. Estos registros (y seguimientos si están habilitados) se mantienen en C:\NCDiagnostics.

Diagnósticos de SLB

Errores de tejido de SLBM (acciones del proveedor de servicios de hospedaje)

  1. Compruebe que Software Load Balancer Manager (SLBM) funciona y que las capas de orquestación pueden comunicarse entre sí: SLBM -> SLB Mux y SLBM -> Agentes host de SLB. Ejecute DumpSlbRestState desde cualquier nodo con acceso al punto de conexión REST de la Controladora de red.
  2. Valide los SDNSLBMPerfCounters en PerfMon en una de las máquinas virtuales del nodo controladora de red (preferiblemente el nodo de controladora de red principal: Get-NetworkControllerReplica):
    1. ¿Está conectado el motor del Equilibrador de carga (LB) a SLBM? (Configuraciones de LBEngine de SLBM Total > 0)
    2. ¿SLBM conoce al menos sus propios puntos de conexión? (Total de puntos de conexión VIP>= 2)
    3. ¿Los hosts de Hyper-V (DIP) están conectados a SLBM? (Clientes hp conectados == servidores numéricos)
    4. ¿SLBM está conectado a Muxes? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VMs).
  3. Asegúrese de que el enrutador BGP configurado está emparejando correctamente con el MUX de SLB.
    1. Si usa RRAS con acceso remoto (es decir, máquina virtual BGP):
      1. Get-BgpPeer debe mostrarse conectado.
      2. Get-BgpRouteInformation debe mostrar al menos una ruta para la dirección VIP de SLBM.
    2. Si usa el conmutador superior de bastidor (ToR) físico como BGP Peer, consulte la documentación:
      1. Por ejemplo: # show bgp instance
  4. Valide los contadores SlbMuxPerfCounters y SLBMUX en PerfMon en la máquina virtual de SLB Mux.
  5. Compruebe el estado de configuración y los intervalos de VIP en el recurso de Administrador de equilibrador de carga de software.
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (compruebe los intervalos vip en grupos de DIRECCIONES IP y asegúrese de que SLBM self-VIP (LoadBalanacerManagerIPAddress) y de que las DIRECCIONES VIP orientadas al inquilino estén dentro de estos intervalos).
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
    2. Debug-NetworkControllerConfigurationState -

Si se produce un error en alguna de las comprobaciones anteriores, el estado del SLB del inquilino también estará en modo de error.

Corrección

En función de la siguiente información de diagnóstico presentada, corrija lo siguiente:

  • Asegúrese de que los multiplexores de SLB están conectados
    • Corrija los problemas de certificado
    • Corregir problemas de conectividad de la red
  • Asegúrese de que la información de emparejamiento BGP está configurada correctamente
  • Asegúrese de que el id. de host del registro coincide con el id. de instancia del servidor en el recurso del servidor (consulte el apéndice para el código de error HostNotConnected)
  • Recopilación de registros

Errores de inquilino de SLBM (acciones de inquilino y proveedor de servicios de hospedaje)

  1. [Hoster] Compruebe Debug-NetworkControllerConfigurationState si algún recurso de LoadBalancer está en estado de error. Intente arreglarlo siguiendo la información de la tabla Acciones en el Apéndice.
    1. Compruebe que un punto de conexión vip está presente y anunciando rutas.
    2. Compruebe cuántos puntos de conexión DIP se han detectado para el punto de conexión VIP.
  2. [Inquilino] Valide que los recursos del equilibrador de carga se especifican correctamente.
    1. Valide los puntos de conexión DIP registrados en SLBM que hospedan máquinas virtuales de inquilino, que corresponden a las configuraciones ip del grupo de direcciones de back-end de LoadBalancer.
  3. [Proveedor de servicios de hosting] Si los puntos de conexión DIP no se detectan o conectan:

    1. Comprobar Debug-NetworkControllerConfigurationState

      Compruebe que nc y agente host SLB están conectados correctamente al coordinador de eventos de controladora de red mediante netstat -anp tcp |findstr 6640).

    2. La HostIdclave de registro del servicio (código de error de referencia HostNotConnected en el apéndice) coincide con el identificador de instancia del recurso de servidor correspondiente (Get-NCServer |convertto-json -depth 8).nchostagent

    3. Compruebe el identificador de perfil de puerto para el puerto de máquina virtual que coincida con el identificador de instancia del recurso de NIC de la máquina virtual correspondiente.

  4. [Proveedor de hospedaje] Recopilar registros.

Seguimiento de mux de SLB

La información de los Muxes de Software Load Balancer también se puede concretar a través del Visor de eventos.

  1. Seleccione Mostrar registros analíticos y de depuración en el menú Ver de Visor de eventos.
  2. Vaya a Registros>de aplicaciones y servicios de Microsoft>Windows>SlbMuxDriver>Trace en Visor de eventos.
  3. Haga clic con el botón derecho en él y seleccione Habilitar registro.

Nota

Se recomienda que solo tenga habilitado este registro durante un breve tiempo mientras intenta reproducir un problema.

Seguimiento de VFP y vSwitch

Desde cualquier host de Hyper-V que hospede una VM invitada conectada a una red virtual de inquilino, puede recopilar un seguimiento de VFP para concretar dónde pueden estar los problemas.

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes