Solucionar problemas da pilha de rede definida pelo software do Windows Server

Este guia examina os erros da SDN (Rede Definida pelo Software) e cenários de falha comuns e descreve um fluxo de trabalho de solução de problemas que usa as ferramentas de diagnóstico disponíveis. Para obter mais informações sobre a SDN, confira Rede Definida por Software).

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versões 21H2 e 20H2

Tipos de erro

A lista a seguir representa a classe de problemas vistos com mais frequência com a HNVv1 (Virtualização de Rede Hyper-V) no Windows Server 2012 R2 de implantações de produção no mercado e coincide, de várias maneiras, com os mesmos tipos de problemas vistos na HNVv2 do Windows Server 2016 com a nova pilha da SDN (Rede Definida por Software).

A maioria dos erros pode ser classificada em um pequeno conjunto de classes:

• Configuração inválida ou sem suporte

  Um usuário invoca a API NorthBound incorretamente ou com política inválida.

• Erro na aplicação da política

  A política do Controlador de Rede não foi entregue a um Host Hyper-V, atrasada ou não atualizada em todos os hosts Hyper-V (por exemplo, após uma Migração Dinâmica).

• Desvio de configuração ou bug de software

  Problemas de caminho de dados resultando em pacotes descartados.

• Erro externo relacionado ao hardware/drivers da NIC ou à malha de rede subjacente

  Descarregamentos de tarefas com comportamento incorreto (como VMQ) ou malha de rede subjacente configurada incorretamente (como MTU)

  Este guia de solução de problemas examina cada uma dessas categorias de erro e recomenda as melhores práticas e as ferramentas de diagnóstico disponíveis para identificar e corrigir o erro.

Ferramentas de diagnóstico

Antes de discutir os fluxos de trabalho de solução de problemas para cada um desses tipos de erros, vamos examinar as ferramentas de diagnóstico disponíveis.

Para usar as ferramentas de diagnóstico do Controlador de Rede (caminho de controle), você deve primeiro instalar o RSAT-NetworkController recurso e importar o NetworkControllerDiagnostics módulo:

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

Para usar as ferramentas de Diagnóstico de HNV (caminho de dados), importe o módulo HNVDiagnostics:

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

Diagnóstico do controlador de rede

Esses cmdlets estão documentados no TechNet no cmdlet Diagnóstico do Controlador de Rede. Eles ajudam a identificar problemas com a consistência da política de rede no caminho de controle entre os nós do Controlador de Rede e entre o Controlador de Rede e os Agentes Host do NC em execução nos hosts Hyper-V.

Os Debug-ServiceFabricNodeStatus cmdlets e Get-NetworkControllerReplica devem ser executados em uma das máquinas virtuais do nó do Controlador de Rede. Todos os outros cmdlets de Diagnóstico do NC podem ser executados de qualquer host, que tem conectividade com o Controlador de Rede e está no grupo de segurança de Gerenciamento do Controlador de Rede (Kerberos) ou tem acesso ao certificado X.509 para gerenciar o Controlador de Rede.

Diagnóstico do host Hyper-V

Esses cmdlets estão documentados no TechNet no cmdlet de Diagnóstico de HNV (Virtualização de Rede Hyper-V). Eles ajudam a identificar problemas no caminho de dados entre máquinas virtuais de locatário (Leste/Oeste) e tráfego de entrada por meio de um VIP SLB (Norte/Sul).

Os Debug-VirtualMachineQueueOperationtestes , Get-CustomerRoute, , Get-ProviderAddressGet-PACAMapping, Get-VMNetworkAdapterPortId, Get-VMSwitchExternalPortId, e Test-EncapOverheadSettings são todos os testes locais que podem ser executados em qualquer host Hyper-V. Os outros cmdlets invocam testes de caminho de dados por meio do Controlador de Rede e, portanto, precisam de acesso ao Controlador de Rede, conforme descrito acima.

GitHub

O Repositório GitHub da Microsoft/SDN tem muitos scripts de exemplo e fluxos de trabalho que se baseiam nesses cmdlets prontos para uso. Em particular, os scripts de diagnóstico podem ser encontrados na pasta Diagnóstico. Ajude-nos a contribuir com esses scripts enviando solicitações de pull.

Resolução de problemas de fluxos de trabalho e guias

[Refrão] Validar a integridade do sistema

Há um recurso inserido chamado Estado de Configuração em vários dos recursos do Controlador de Rede. O estado de configuração fornece informações sobre a integridade do sistema, incluindo a consistência entre a configuração do controlador de rede e o estado real (de execução) nos hosts Hyper-V.

Para verificar o estado de configuração, execute o indicado a seguir em qualquer host Hyper-V com conectividade com o Controlador de Rede.

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

Um exemplo de mensagem de Estado de Configuração é mostrado abaixo:

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.
----------------------------------------------------------------------------------------------------------

A tabela a seguir mostra a lista de códigos de erro, mensagens e ações de acompanhamento a serem executadas com base no estado de configuração observado.

Código	Mensagem	Ação
Unknown	Erro desconhecido
HostUnreachable	O computador host não está acessível	Verificar a conectividade da rede de gerenciamento entre o controlador de rede e o host
PAIpAddressExhausted	Os endereços IP do PA esgotados	Aumentar o tamanho do pool de IPs da sub-rede lógica do provedor de HNV
PAMacAddressExhausted	Os endereços Mac de PA foram esgotados	Aumentar o intervalo do pool de Macs
PAAddressConfigurationFailure	Falha ao encaminhar endereços PA ao host	Verificar a conectividade da rede de gerenciamento entre o controlador de rede e o host.
CertificateNotTrusted	O certificado não é confiável	Corrigir os certificados usados para comunicação com o host.
CertificateNotAuthorized	Certificado não autorizado	Corrigir os certificados usados para comunicação com o host.
PolicyConfigurationFailureOnVfp	Falha na configuração de políticas de VFP	Essa é uma falha de runtime. Não há uma solução alternativa definitiva. Coletar logs.
PolicyConfigurationFailure	Falha ao efetuar push de políticas para os hosts devido a falhas de comunicação ou outros erros no NetworkController.	Nenhuma ação definitiva. Isso ocorre devido a uma falha no processamento do estado meta nos módulos do Controlador de Rede. Coletar logs.
HostNotConnectedToController	O host ainda não está conectado ao Controlador de Rede	Perfil de Porta não aplicado ao host ou o host não pode ser acessado pelo Controlador de Rede. Validar se a chave do Registro da HostID corresponde à ID da Instância do recurso do servidor
MultipleVfpEnabledSwitches	Há vários comutadores habilitados para VFP no host	Excluir um dos comutadores, uma vez que o Agente Host do Controlador de Rede dá suporte apenas a um vSwitch com a extensão VFP habilitada
PolicyConfigurationFailure	Falha ao efetuar push de políticas de VNet para uma VmNic devido a erros de certificado ou de conectividade	Verificar se os certificados adequados foram implantados (o nome da entidade do certificado precisa corresponder ao FQDN do host). Verificar também a conectividade do host com o Controlador de Rede
PolicyConfigurationFailure	Falha ao efetuar push de políticas de vSwitch para uma VmNic devido a erros de certificado ou de conectividade	Verificar se os certificados adequados foram implantados (o nome da entidade do certificado precisa corresponder ao FQDN do host). Verificar também a conectividade do host com o Controlador de Rede
PolicyConfigurationFailure	Falha ao fazer push de políticas de firewall para uma VmNic devido a erros de certificado ou de conectividade	Verificar se os certificados adequados foram implantados (o nome da entidade do certificado precisa corresponder ao FQDN do host). Verificar também a conectividade do host com o Controlador de Rede
DistributedRouterConfigurationFailure	Falha ao configurar o roteador distribuído na vNic do host	Erro de pilha TCPIP. Pode exigir a limpeza das vNICs do host de PA e DR no servidor no qual o erro foi relatado
DhcpAddressAllocationFailure	Falha na alocação de endereço DHCP para uma VMNic	Verificar se o atributo de endereço IP estático está configurado no recurso de NIC
CertificateNotTrusted CertificateNotAuthorized	Falha ao se conectar ao Mux devido a erros de rede ou de certificado	Verificar o código numérico fornecido no código da mensagem de erro: ele corresponde ao código de erro winsock. Os erros de certificado são granulares (por exemplo, o certificado não pode ser verificado, certificado não autorizado etc.)
HostUnreachable	O MUX não está íntegro (o caso comum é o BGPRouter desconectado)	O par no nível de protocolo BGP na opção RRAS (máquina virtual BGP) ou ToR (Top-of-Rack) é inacessível ou não está emparelhando com êxito. Verificar as configurações de BGP no recurso multiplexador do Software Load Balancer e no par no nível de protocolo BGP (máquina virtual RRAS ou ToR)
HostNotConnectedToController	O agente host do SLB não está conectado	Verificar se o serviço do Agente Host do SLB está em execução; consultar os motivos nos logs do agente host do SLB (execução automática); caso o SLBM (NC) tenha rejeitado o certificado apresentado pelo agente host, o estado de execução mostrará informações com nuances
PortBlocked	A porta VFP está bloqueada devido à falta de políticas de VNET/ACL	Verificar se há outros erros que podem fazer com que as políticas não estejam configuradas.
Sobrecarregado	O MUX do balanceador de carga está sobrecarregado	Problema de desempenho com o MUX
RoutePublicationFailure	O MUX do balanceador de carga não está conectado a um roteador BGP	Verificar se o MUX tem conectividade com os roteadores BGP e se o emparelhamento BGP está configurado corretamente
VirtualServerUnreachable	O MUX do balanceador de carga não está conectado ao gerenciador do SLB	Verificar a conectividade entre o SLBM e o MUX
QosConfigurationFailure	Falha ao configurar políticas de QOS	Verificar se largura de banda suficiente está disponível para todas as VMs se a reserva de QOS for usada

Verificar a conectividade de rede entre o controlador de rede e o Host Hyper-V (serviço do Agente Host do NC)

Execute o netstat comando abaixo para validar se há três ESTABLISHED conexões entre o NC Host Agent e os nós do Controlador de Rede e um LISTENING soquete no Host Hyper-V.

• ESCUTANDO ma porta TCP:6640 no Host Hyper-V (Serviço de Agente de Host do NC)
• Duas conexões estabelecidas do IP do host Hyper-V na porta 6640 com o IP do nó do NC em portas efêmeras (> 32000)
• Uma conexão estabelecida do IP do host Hyper-V na porta efêmera para o IP REST do controlador de rede na porta 6640

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

Verificar os serviços do agente de host

O controlador de rede se comunica com dois serviços de agente de host do Hyper-V: Agente de Host SLB e Agente de Host NC. É possível que um ou ambos os serviços não estejam em execução. Verifique o estado deles e reinicie-os se não estiverem em execução.

Get-Service SlbHostAgent
Get-Service NcHostAgent

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

Verificar a integridade do controlador de rede

Se não houver três ESTABLISHED conexões ou se o Controlador de Rede parecer não responder, verifique se todos os nós e módulos de serviço estão ativos e em execução usando os cmdlets a seguir.

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

Os módulos de serviço do controlador de rede são:

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

Verifique se ReplicaStatus é Ready e HealthState é Ok.

Em uma implantação de produção com um Controlador de Rede de vários nós, você também pode verificar em qual nó cada serviço é primário e seu status 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

Verifique se o Status de Réplica é Pronto para cada serviço.

Verifique se há HostIDs e certificados correspondentes entre o controlador de rede e cada host Hyper-V

Em um Host Hyper-V, execute os cmdlets a seguir para verificar se o HostID corresponde à ID da Instância de um recurso de servidor no Controlador de Rede

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

Remediação

Se estiver usando scripts SDNExpress ou implantação manual, atualize a chave HostId no Registro para corresponder à ID da instância do recurso do servidor. Reinicie o Agente Host do Controlador de Rede no host Hyper-V (servidor físico). Se estiver usando o VMM, exclua o Servidor Hyper-V do VMM e remova a chave do registro do HostId. Em seguida, adicione o servidor por meio do VMM novamente.

Verifique se as impressões digitais dos certificados X.509 usados pelo host Hyper-V (o nome do host será o Nome da Entidade do certificado) para comunicação (SouthBound) entre o Host Hyper-V (serviço do Agente Host do NC) e os nós do Controlador de Rede são os mesmos. Verifique também se o certificado REST do Controlador de Rede tem o nome da entidade .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**
...

Você também pode verificar os parâmetros a seguir de cada certificado para garantir que o nome da entidade seja o esperado (nome do host ou NC REST FQDN ou IP), que o certificado ainda não expirou e que todas as autoridades de certificação na cadeia de certificados estejam incluídas na autoridade raiz confiável.

• Nome do assunto
• Data de Validade
• Confiável para a autoridade raiz

Se vários certificados tiverem o mesmo nome de assunto no host Hyper-V, o Agente de Host do Controlador de Rede escolherá aleatoriamente um para apresentar ao Controlador de Rede. Isso pode não corresponder à impressão digital do recurso de servidor conhecido pelo Controlador de Rede. Nesse caso, exclua um dos certificados com o mesmo nome de entidade no host Hyper-V e reinicie o serviço do Agente Host do Controlador de Rede. Se uma conexão ainda não puder ser feita, exclua o outro certificado com o mesmo nome de entidade no Host Hyper-V e exclua o recurso de servidor correspondente no VMM. Em seguida, recrie o recurso de servidor no VMM, o que gerará um novo certificado X.509 e o instalará no host Hyper-V.

Verifique o estado de configuração do SLB

O Estado de Configuração do SLB pode ser determinado como parte da saída para o Debug-NetworkController cmdlet. Esse cmdlet também produzirá o conjunto atual de recursos do Controlador de Rede em arquivos JSON, todas as configurações de IP de cada host Hyper-V (servidor) e a política de rede local das tabelas de banco de dados do Agente Host.

Mais rastreamentos serão coletados por padrão. Para não coletar rastreamentos, adicione o -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

As informações do Estado de Configuração do SLB podem ser encontradas no arquivo diagnostics-slbstateResults.Json neste diretório.

Esse arquivo JSON pode ser dividido nas seguintes seções:

• Malha
  • SlbmVips – esta seção lista o endereço IP do endereço VIP do Gerenciador do SLB, que é usado pelo Controlador de Rede para coordenar a configuração e a integridade entre os Muxes do SLB e os Agentes Host do SLB.
  • MuxState – esta seção lista um valor para cada Mux do SLB implantado fornecendo o estado do Mux
  • Configuração do roteador – esta seção lista o ASN (Número de Sistema Autônomo) do Roteador Upstream (Par BGP), o Endereço IP de Trânsito e a ID. Ela também listará o ASN dos Muxes do SLB e o IP de Trânsito.
  • Informações do host conectado – esta seção lista o endereço IP de Gerenciamento de todos os hosts Hyper-V disponíveis para executar cargas de trabalho com balanceamento de carga.
  • Intervalos VIP – esta seção lista os intervalos de pools de IP VIP públicos e privados. O VIP do SLBM será incluído como um IP alocado de um desses intervalos.
  • Rotas do Mux – esta seção lista um valor para cada Mux do SLB implantado contendo todos os Anúncios de Rota para esse Mux específico.
• Locatário
  • VipConsolidatedState – esta seção lista o estado de conectividade para cada VIP de Locatário, incluindo o prefixo de rota anunciado, o Host Hyper-V e os pontos de extremidade de DIP.

Validação do gateway

Do controlador de rede:

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

Da VM do gateway:

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

Do switch superior do rack (ToR):

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

Roteador BGP do Windows:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Além desses, entre os problemas que vimos até agora (especialmente em implantações baseadas em SDNExpress), o motivo mais comum para o Compartimento de Locatário não ser configurado em VMs de GW parece ser o fato de que a Capacidade do GW em FabricConfig.psd1 é menor quando comparada ao que as pessoas tentam atribuir às Conexões de Rede (Túneis S2S) em TenantConfig.psd1. Isso pode ser verificado facilmente comparando as saídas dos seguintes 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

[Hoster] Validar plano de dados

Após o Controlador de Rede ser implantado, as redes virtuais de locatário e as sub-redes serem criadas e as VMs serem anexadas às sub-redes virtuais, testes de nível de malha adicionais poderão ser executados pelo host para verificar a conectividade do locatário.

Verificar a conectividade de rede lógica do provedor de HNV

Depois que a primeira VM convidada em execução em um host Hyper-V tiver sido conectada a uma rede virtual de locatário, o Controlador de Rede atribuirá dois endereços IP do provedor de HNV (endereços IP de PA) ao Host Hyper-V. Esses IPs virão do pool de IPs da rede lógica do provedor de HNV e serão gerenciados pelo Controlador de Rede. Para descobrir quais são esses dois endereços 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

Esses endereços IP do Provedor de HNV (IPs de PA) são atribuídos aos Adaptadores Ethernet criados em um compartimento de rede TCPIP separado e têm um nome de adaptador VLANX, em que X é a VLAN atribuída à rede lógica do Provedor de HNV (transporte).

A conectividade entre dois hosts Hyper-V usando a rede lógica do Provedor de HNV pode ser estabelecida por um ping com um parâmetro de compartimento adicional (-c Y), em que Y é o compartimento de rede TCPIP no qual os PAhostVNICs são criados. Esse compartimento pode ser determinado executando:

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> ...

Por exemplo, suponha que os hosts Hyper-V 1 e 2 tenham os endereços IP do Provedor de HNV (PA):

Host do Hyper-V	Endereço IP de PA 1	Endereço 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 executar um ping entre os dois usando o comando a seguir para verificar a conectividade da rede lógica do Provedor de 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

Remediação

Se o ping do provedor de HNV não funcionar, verifique a conectividade de rede física, incluindo a configuração de VLAN. As NICs físicas em cada host Hyper-V devem estar no modo de tronco, sem nenhuma VLAN específica atribuída. A vNIC do Host de Gerenciamento deve ser isolada para a VLAN da Rede Lógica de Gerenciamento.

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> ...

Verificar o suporte a MTU e quadro jumbo na rede lógica do provedor de HNV

Outro problema comum na rede lógica do Provedor de HNV é que as portas de rede física e/ou a placa Ethernet não têm uma MTU grande o suficiente configurada para lidar com a sobrecarga do encapsulamento VXLAN (ou NVGRE).

# 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 testar se a rede lógica do Provedor de HNV dá suporte ou não ao tamanho maior de MTU de ponta a ponta, use o 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.

Remediação

• Ajuste o tamanho da MTU nas portas do comutador físico para ter pelo menos 1674B (incluindo o cabeçalho Ethernet de 14B e o trailer)
• Se sua placa NIC não der suporte à palavra-chave EncapOvered, ajuste a palavra-chave JumboPacket para ser pelo menos 1674B

Verificar a conectividade da NIC da VM do locatário

Cada NIC da VM atribuído a uma VM convidada tem um mapeamento de CA-PA entre o CA (endereço do cliente) privado e o espaço de PA (endereço do provedor) da HNV. Esses mapeamentos são mantidos nas tabelas do servidor OVSDB em cada host Hyper-V e podem ser encontrados executando o cmdlet a seguir.

# 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

Com essas informações, um ping de VM de locatário agora pode ser iniciado pelo Hoster do Controlador de Rede usando o Test-VirtualNetworkConnection cmdlet.

Cenários específicos de solução de problemas

As seções a seguir fornecem diretrizes para cenários específicos de solução de problemas.

Nenhuma conectividade de rede entre duas máquinas virtuais de locatário

1. [Locatário] Verifique se o Firewall do Windows nas máquinas virtuais de locatário não está bloqueando o tráfego.
2. [Inquilino] Verifique se os endereços IP foram atribuídos à máquina virtual do locatário executando ipconfigo .
3. [Refrão] Execute Test-VirtualNetworkConnection no host Hyper-V para validar a conectividade entre as duas máquinas virtuais de locatário em questão.

Exemplo

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

Crie um ping de CA entre "Green Web VM 1" com o IP de SenderCA 192.168.1.4 no Host "sa18n30-2.sa18.nttest.microsoft.com" com o IP de Mgmt de 10.127.132.153 para o IP do ListenerCA de 192.168.1.5 anexado à VSID (Sub-rede Virtual) 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> ...

[Locatário] Verifique se não há políticas de firewall distribuído especificadas na sub-rede virtual ou nos adaptadores de rede de VM que bloqueariam o tráfego.

Consulte a API REST do Controlador de Rede encontrada no ambiente de demonstração em sa18n30nc no domínio sa18.nttest.microsoft.com.

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

Examine a configuração de IP e as sub-redes virtuais que fazem referência a essa ACL

1. [Host] Execute Get-ProviderAddress nos dois hosts Hyper-V que hospedam as duas máquinas virtuais de locatário em questão e execute Test-LogicalNetworkConnection ou ping -c <compartment> no host Hyper-V para validar a conectividade na rede lógica do Provedor de HNV
2. [Host] Verifique se as configurações de MTU estão corretas nos hosts Hyper-V e nos dispositivos de alternância de Camada 2 que estão entre os Hosts Hyper-V. Execute Test-EncapOverheadValue em todos os hosts Hyper-V em questão. Verifique também se todos os comutadores de Camada 2 têm o MTU definido como pelo menos 1674 bytes para levar em consideração uma sobrecarga máxima de 160 bytes.
3. [Host] Se os endereços IP de PA não estiverem presentes e/ou se a conectividade da AC for interrompida, verifique se a política de rede foi recebida. Execute Get-PACAMapping para ver se as regras de encapsulamento e os mapeamentos de CA-PA necessários para criar redes virtuais de sobreposição estão estabelecidos corretamente.
4. [Host] Verifique se o Agente Host do Controlador de Rede está conectado ao Controlador de Rede. Para fazer isso, execute netstat -anp tcp |findstr 6640.
5. [Host] Verifique se a ID do Host no HKLM/ corresponde à ID da Instância dos recursos do servidor que hospedam as máquinas virtuais do locatário.
6. [Host] Verifique se a ID do Perfil de Porta corresponde à ID da Instância das Interfaces de Rede da VM das máquinas virtuais do locatário.

Registro, rastreamento e diagnóstico avançado

As seções a seguir fornecem informações sobre diagnóstico avançado, registro em log e rastreamento.

Registro em log centralizado do controlador de rede

O Controlador de Rede pode coletar automaticamente logs do depurador e armazená-los em um local centralizado. A coleta de logs pode ser habilitada quando você implanta o Controlador de Rede pela primeira vez ou a qualquer momento depois disso. Os logs são coletados do Controlador de Rede e dos elementos de rede gerenciados por ele: computadores host, SLBs (balanceadores de carga de software) e computadores de gateway.

Esses logs incluem logs de depuração para o cluster do Controlador de Rede, o aplicativo do Controlador de Rede, logs de gateway, SLB, rede virtual e o firewall distribuído. Sempre que um novo host/SLB/gateway é adicionado ao Controlador de Rede, o registro em log é iniciado nesses computadores. De maneira semelhante, quando um host/SLB/gateway é removido do Controlador de Rede, o registro em log é interrompido nesses computadores.

Habilitar o registro em log

O registro em log é habilitado automaticamente quando você instala o cluster do Controlador de Rede usando o Install-NetworkControllerCluster cmdlet. Por padrão, os logs são coletados localmente nos nós do Controlador de Rede em %systemdrive%\SDNDiagnostics. É recomendável que você altere esse local para ser um compartilhamento de arquivos remoto (não local).

Os logs do cluster do Controlador de Rede são armazenados em %programData%\Windows Fabric\log\Traces. Você pode especificar um local centralizado para a coleta de logs com o DiagnosticLogLocation parâmetro com a recomendação de que ele também seja um compartilhamento de arquivos remoto.

Se você quiser restringir o acesso a esse local, poderá fornecer as credenciais de acesso com o LogLocationCredential parâmetro. Se você fornecer as credenciais para acessar o local do log, também deverá fornecer o CredentialEncryptionCertificate parâmetro, que é usado para criptografar as credenciais armazenadas localmente nos nós do Controlador de Rede.

Com as configurações padrão, é recomendável que você tenha pelo menos 75 GB de espaço livre no local central e 25 GB nos nós locais (se não estiver usando um local central) para um cluster de três nós do Controlador de Rede.

Alterar configurações de registro em log

Você pode alterar as configurações de registro em log a qualquer momento usando o cmdlet Set-NetworkControllerDiagnostic. As seguintes configurações podem ser alteradas:

• Local de log centralizado.

  Você pode alterar o local para armazenar todos os logs com o parâmetro DiagnosticLogLocation.

• Credenciais para acessar o local de log.

  Você pode alterar as credenciais para acessar o local de log com o parâmetro LogLocationCredential.

• Mover para o registro em log local.

  Se você tiver fornecido um local centralizado para armazenar logs, poderá voltar ao registro em log localmente nos nós do Controlador de Rede com o parâmetro UseLocalLogLocation (não recomendado devido requisitos elevados de espaço em disco).

• Escopo do registro em log.

  Por padrão, todos os logs são coletados. Você pode alterar o escopo para coletar somente logs do cluster do Controlador de Rede.

• Nível de registro em log.

  O nível de registro em log padrão é Informativo. Você pode alterá-lo para Erro, Aviso ou Detalhado.

• Tempo de envelhecimento do log.

  Os logs são armazenados de maneira circular. Você tem três dias de registro em log por padrão, seja usando o registro em log local ou o registro em log centralizado. Você pode alterar esse limite de tempo com o LogTimeLimitInDays parâmetro.

• Tamanho do envelhecimento do log.

  Por padrão, você terá no máximo 75 GB de dados de registro em log se usar o registro em log centralizado e 25 GB se estiver usando o registro em log local. Você pode alterar esse limite com o LogSizeLimitInMBs parâmetro.

Coletando logs e rastreamentos

As implantações do VMM usam o registro em log centralizado para o Controlador de Rede por padrão. O local de compartilhamento de arquivo para esses logs é especificado ao implantar o modelo de serviço do Controlador de Rede.

Se um local de arquivo não tiver sido especificado, o log local será usado em cada nó do Controlador de Rede com logs salvos em C:\Windows\tracing\SDNDiagnostics. Esses logs são salvos usando a seguinte hierarquia:

• CrashDumps
• NCApplicationCrashDumps
• NCApplicationLogs
• PerfCounters
• SDNDiagnostics
• Rastreamentos

O Controlador de Rede usa o (Azure) Service Fabric. Os logs do Service Fabric podem ser necessários ao solucionar determinados problemas. Esses logs podem ser encontrados em cada nó do Controlador de Rede em C:\ProgramData\Microsoft\Service Fabric.

Se um usuário tiver executado o Debug-NetworkController cmdlet, mais logs estarão disponíveis em cada host Hyper-V, que foi especificado com um recurso de servidor no Controlador de Rede. Esses logs (e rastreamentos, se habilitados) são mantidos em C:\NCDiagnostics.

Diagnóstico SLB

Erros de malha SLBM (ações do provedor de serviços de hospedagem)

1. Verifique se o SLBM (Software Load Balancer Manager) está funcionando e se as camadas de orquestração podem conversar entre si: SLBM –> Mux do SLB e SLBM –> Agentes Host do SLB. Execute DumpSlbRestState de qualquer nó com acesso ao ponto de extremidade REST do Controlador de Rede.
2. Valide os SDNSLBMPerfCounters no PerfMon em uma das VMs do nó do Controlador de Rede (preferencialmente o nó primário do Controlador de Rede - Get-NetworkControllerReplica):
   1. O mecanismo do LB (Load Balancer) está conectado ao SLBM? (Configurações SLBM LBEngine Total > 0)
   2. O SLBM pelo menos sabe sobre os próprios pontos de extremidade? (Total de pontos de extremidade de VIP >= 2)
   3. Os hosts Hyper-V (DIP) estão conectados ao SLBM? (Clientes HP conectados == servidores num)
   4. O SLBM está conectado a Muxes? (Muxes Connected == Muxes Healthy on SLBM == Muxes relatando healthy = # SLB Muxes VMs).
3. Certifique-se de que o roteador BGP configurado esteja emparelhando com êxito com o SLB MUX.
   1. Se estiver usando o RRAS com o Acesso Remoto (ou seja, a máquina virtual do BGP):
      1. Get-BgpPeer deve mostrar conectado.
      2. Get-BgpRouteInformation deve mostrar pelo menos uma rota para o auto VIP do SLBM.
   2. Se estiver usando o switch Top-of-Rack (ToR) físico como BGP Peer, consulte sua documentação:
      1. Por exemplo: # show bgp instance
4. Valide os contadores SlbMuxPerfCounters e SLBMUX no PerfMon na VM SLB Mux.
5. Verifique o estado de configuração e os intervalos VIP em Recurso do Gerenciador do Balanceador de Carga de Software.
   1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (verifique os intervalos VIP em pools de IP e verifique se o SLBM auto-VIP (LoadBalanacerManagerIPAddress) e todos os VIPs voltados para o locatário estão dentro desses 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 -

Se qualquer uma das verificações acima falhar, o estado do SLB do locatário também estará no modo de falha.

Remediação

Com base nas seguintes informações de diagnóstico apresentadas, corrija o seguinte:

• Verifique se os multiplexadores SLB estão conectados
  • Corrija problemas de certificado
  • Corrigir problemas de conectividade de rede
• Verifique se as informações de emparelhamento via protocolo BGP foram configuradas com êxito
• Verifique se a ID do Host no registro corresponde à ID da Instância do Servidor no Recurso do Servidor (consulte o Apêndice para o código de erro HostNotConnected)
• Coletar logs

Erros de locatário SLBM (ações do provedor de serviços de hospedagem e do locatário)

1. [Refrão] Verifique Debug-NetworkControllerConfigurationState se algum recurso do LoadBalancer está em um estado de erro. Tente atenuar seguindo a Tabela de Itens de ação no Apêndice.
   1. Verifique se um endpoint VIP está presente e anunciando rotas.
   2. Verifique quantos pontos de extremidade DIP foram descobertos para o ponto de extremidade VIP.
2. [Inquilino] Validar recursos do balanceador de carga estão especificados corretamente.
   1. Valide se os pontos de extremidade DIP registrados no SLBM estão hospedando máquinas virtuais de locatário, que correspondem às configurações de IP do pool de endereços de back-end do LoadBalancer.
3. [Host] Se pontos de extremidade de DIP não forem descobertos ou não estiverem conectados:

   1. Confira Debug-NetworkControllerConfigurationState

      Valide se o Agente de Host NC e SLB está conectado com êxito ao Coordenador de Eventos do Controlador de Rede usando netstat -anp tcp |findstr 6640)o .

   2. A regkey de serviço de check-in HostIdnchostagent (código de erro de referência HostNotConnected no Apêndice) corresponde à ID da instância do recurso de servidor correspondente (Get-NCServer |convertto-json -depth 8).

   3. Verifique se a ID do perfil da porta da máquina virtual corresponde à ID da instância do recurso NIC da máquina virtual correspondente.

4. [Provedor de hospedagem] Colete logs.

Rastreamento SLB Mux

As informações do Muxes do Software Load Balancer também podem ser determinadas por meio de Visualizador de Eventos.

1. Selecione Mostrar Logs de Análise e Depuração no menu Exibição do Visualizador de Eventos.
2. Navegue até Logs de>Aplicativos e Serviços Rastreamento do Microsoft>Windows>SlbMuxDriver>no Visualizador de Eventos.
3. Clique com o botão direito do mouse e selecione Ativar log.

Rastreamento de VFP e vSwitch

Em qualquer host Hyper-V que esteja hospedando uma VM convidada anexada a uma rede virtual de locatário, você pode coletar um rastreamento de VFP para determinar onde os problemas podem estar.

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