Share via

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

  • Artigo

Este guia examina os erros comuns de SDN (Software Defined Networking) e cenários de falha 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 o SDN, consulte 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 mais frequentemente vista com o HNVv1 (Hyper-V Network Virtualization) 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 em Windows Server 2016 HNVv2 com a nova Pilha de Rede Definida por Software (SDN).

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 a política inválida.

  • Erro no aplicativo de política

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

  • Deriva de configuração ou bug de software

    Problemas de caminho de dados que resultam em pacotes descartados.

  • Erro externo relacionado ao hardware/drivers nic ou ao tecido de rede de subposição

    Descarregamentos de tarefas mal comportados (como VMQ) ou malha de rede de subposição configuradas incorretamente (como MTU)

    Este guia de solução de problemas examina cada uma dessas categorias de erro e recomenda as melhores práticas e 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), primeiro instale o RSAT-NetworkController recurso e importe o NetworkControllerDiagnostics módulo:

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

Para usar as ferramentas de diagnóstico HNV Diagnostics (caminho de dados), você deve importar o HNVDiagnostics módulo:

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

Controlador de rede diagnóstico

Esses cmdlets sã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 NC em execução nos hosts do Hyper-V.

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

Diagnóstico de host do Hyper-V

Esses cmdlets são documentados no TechNet no cmdlet de Diagnóstico de Virtualização de Rede (HNV) do 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 do SLB (Norte/Sul).

Os Debug-VirtualMachineQueueOperationtestes , Get-CustomerRoute, Get-PACAMapping, Get-ProviderAddress, Get-VMNetworkAdapterPortId, Get-VMSwitchExternalPortIde Test-EncapOverheadSettings são todos os testes locais que podem ser executados de 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 em cima desses cmdlets in-box. Em particular, scripts de diagnóstico podem ser encontrados na pasta Diagnóstico . Ajude-nos a contribuir para esses scripts enviando Pull Requests.

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

[Hoster] Validar a integridade do sistema

Há um recurso inserido chamado Estado de Configuração em vários 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 (em execução) nos hosts do Hyper-V.

Para marcar estado de configuração, execute o seguinte de qualquer host Hyper-V com conectividade com o Controlador de Rede.

Observação

O valor do NetworkController parâmetro deve ser o endereço FQDN ou IP com base no nome do assunto do certificado X.509 >criado para o Controlador de Rede.

O Credential parâmetro só precisa ser especificado se o controlador de rede estiver usando a autenticação Kerberos (típica em implantações do VMM). A credencial deve ser para um usuário que está no Grupo de Segurança de Gerenciamento do 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

Uma mensagem de estado de configuração de exemplo é mostrada 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.
----------------------------------------------------------------------------------------------------------

Observação

Há um bug no sistema em que os recursos da Interface de Rede para a NIC da VM de Trânsito do SLB Mux estão em um estado de falha com o erro "Comutador Virtual – Host Não Conectado ao Controlador". Esse erro poderá ser ignorado com segurança se a configuração de IP no recurso NIC da VM estiver definida como um endereço IP do Pool de IP da Rede Lógica de Trânsito.

Há um segundo bug no sistema em que os recursos da Interface de Rede para as NICs de VM do Provedor HNV de Gateway estão em um estado de falha com o erro "Comutador Virtual – PortBlocked". Esse erro também pode ser ignorado com segurança se a configuração de IP no recurso NIC da VM estiver definida como nula (por design).

A tabela abaixo 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
Desconhecido Erro desconhecido
HostUnreachable O computador host não é acessível Verificar a conectividade de rede de gerenciamento entre o Controlador de Rede e o Host
PAIpAddressExhausted Os endereços IP pa esgotados Aumentar o tamanho do pool de IP da sub-rede lógica do provedor HNV
PAMacAddressExhausted Os endereços Mac pa esgotados Aumentar o Intervalo de Pool do Mac
PAAddressConfigurationFailure Falha ao canalizar endereços pa para o host Verifique a conectividade de rede de gerenciamento entre o Controlador de Rede e o Host.
CertificateNotTrusted O certificado não é confiável Corrija os certificados usados para comunicação com o host.
CertificateNotAuthorized Certificado não autorizado Corrija os certificados usados para comunicação com o host.
PolicyConfigurationFailureOnVfp Falha na configuração de políticas VFP Isso é uma falha de runtime. Nenhuma solução alternativa definitiva. Colete os logs.
PolicyConfigurationFailure Falha no envio 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 de estado de meta nos módulos do Controlador de Rede. Colete os logs.
HostNotConnectedToController O Host ainda não está conectado ao Controlador de Rede O Perfil de Porta não aplicado no host ou no host não é acessível do Controlador de Rede. Validar que a chave do registro HostID corresponde à ID da instância do recurso do servidor
MultipleVfpEnabledSwitches Há vários Switches habilitados para VFp no host Excluir um dos comutadores, já que o Agente host do Controlador de Rede só dá suporte a um vSwitch com a extensão VFP habilitada
PolicyConfigurationFailure Falha ao enviar push de políticas de VNet para um VmNic devido a erros de certificado ou de conectividade Verifique se os certificados adequados foram implantados (o nome da entidade do certificado deve corresponder ao FQDN do host). Verifique também a conectividade do host com o Controlador de Rede
PolicyConfigurationFailure Falha ao enviar push de políticas vSwitch para um VmNic devido a erros de certificado ou conectividade Verifique se os certificados adequados foram implantados (o nome da entidade do certificado deve corresponder ao FQDN do host). Verifique também a conectividade do host com o Controlador de Rede
PolicyConfigurationFailure Falha ao enviar push de políticas de firewall para um VmNic devido a erros de certificado ou conectividade Verifique se os certificados adequados foram implantados (o nome da entidade do certificado deve corresponder ao FQDN do host). Verifique também a conectividade do host com o Controlador de Rede
DistributedRouterConfigurationFailure Falha ao configurar as configurações do roteador distribuído no host vNic Erro de pilha TCPIP. Pode exigir a limpeza dos vNICs de host de PA e DR no servidor no qual esse erro foi relatado
DhcpAddressAllocationFailure Falha na alocação de endereço DHCP para uma VMNic Verifique se o atributo de endereço IP estático está configurado no recurso NIC
CertificateNotTrusted
CertificateNotAuthorized		 Falha ao se conectar ao Mux devido a erros de rede ou certificação Verifique o código numérico fornecido no código da mensagem de erro: isso corresponde ao código de erro winsock. Os erros de certificado são granulares (por exemplo, o certificado não pode ser verificado, o certificado não autorizado etc.)
HostUnreachable O MUX não é íntegro (o caso comum é desconectado do BGPRouter) O par BGP na opção RRAS (máquina virtual BGP) ou Top-of-Rack (ToR) é inacessível ou não está emparelhando com êxito. Verifique as configurações do BGP em software Load Balancer recurso Multiplexer e no par BGP (máquina virtual ToR ou RRAS)
HostNotConnectedToController O agente host do SLB não está conectado Verifique se o serviço do Agente de Host do SLB está em execução; Consulte logs do agente host do SLB (execução automática) por motivos pelos quais, caso o SLBM (NC) rejeitasse o certificado apresentado pelo estado de execução do agente host mostrará informações com nuances
PortBlocked A porta VFP está bloqueada devido à falta de políticas de VNET/ACL Verifique se há outros erros, o que pode fazer com que as políticas não sejam configuradas.
Sobrecarregado O MUX do Loadbalancer está sobrecarregado Problema de desempenho com MUX
RoutePublicationFailure O MUX do loadbalancer não está conectado a um roteador BGP Verifique se o MUX tem conectividade com os roteadores BGP e se o emparelhamento BGP está configurado corretamente
VirtualServerUnreachable O MUX do Loadbalancer 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 Veja se a largura de banda suficiente está disponível para todas as VMs se a reserva QOS for usada

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

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

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

Observação

Só poderá haver duas conexões estabelecidas em um host Hyper-V se não houver máquinas virtuais de locatário implantadas nesse host específico.

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 serviços de agente de host

O controlador de rede se comunica com dois serviços de agente host nos hosts 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 se eles 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 aparecer sem resposta, marcar para ver se todos os nós e módulos de serviço estão 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 está com um Controlador de Rede de vários nós, você também pode marcar em qual nó cada serviço é primário e seu réplica status 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 da Réplica está pronto para cada serviço.

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

Em um host do Hyper-V, execute os cmdlets a seguir para marcar que o HostID corresponda à 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 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 do Assunto do certificado) para comunicação (SouthBound) entre os nós host do Hyper-V (NC Host Agent) e controlador de rede são iguais. Também marcar que o certificado REST do Controlador de Rede tenha 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 marcar os seguintes parâmetros de cada certificado para garantir que o nome do assunto seja o esperado (nome do host ou NC REST FQDN ou IP), o certificado ainda não expirou e que todas as autoridades de certificado na cadeia de certificados estão incluídas na autoridade raiz confiável.

  • Nome da entidade
  • Data de validade
  • Confiável por 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 do servidor conhecido como Controlador de Rede. Nesse caso, exclua um dos certificados com o mesmo nome de assunto no host Hyper-V e reinicie o serviço do Agente de Host do Controlador de Rede. Se uma conexão ainda não puder ser feita, exclua o outro certificado com o mesmo nome de assunto no Host Hyper-V e exclua o recurso de servidor correspondente no VMM. Em seguida, recrie o recurso do servidor no VMM, que gerará um novo certificado X.509 e o instalará no host Hyper-V.

Verificar 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 do Hyper-V (servidor) e política de rede local das tabelas de banco de dados do Host Agent.

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

Observação

O local de saída padrão será o <diretório working_directory>\NCDiagnostics\. O diretório de saída padrão pode ser alterado usando o -OutputDirectory parâmetro.

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

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

  • Tecido
    • SlbmVips – Esta seção lista o endereço IP do endereço VIP do SLB Manager, que é usado pelo Controlador de Rede para coordenar a configuração e a integridade entre os Muxes SLB e os Agentes host do SLB.
    • MuxState – Esta seção listará um valor para cada SLB Mux implantado dando o estado do mux
    • Configuração do roteador – esta seção listará o ASN (número do sistema autônomo) do roteador upstream (par BGP), endereço IP de trânsito e ID. Ele também listará o ASN do SLB Muxes e o IP de trânsito.
    • Informações do Host Conectado – esta seção listará o endereço IP de gerenciamento de todos os hosts do Hyper-V disponíveis para executar cargas de trabalho balanceadas por cargas de trabalho.
    • Intervalos VIP – esta seção listará os intervalos de pool 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 listará um valor para cada SLB Mux implantado contendo todos os Anúncios de Rota para esse mux específico.
  • Tenant
    • VipConsolidatedState – Esta seção listará o estado de conectividade para cada VIP de Locatário, incluindo prefixo de rota anunciado, Host Hyper-V e pontos de extremidade DIP.

Observação

O Estado do SLB pode ser apurado diretamente usando o script DumpSlbRestState disponível no repositório GitHub do Microsoft SDN.

Validação de gateway

Do controlador de rede:

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

Na VM do gateway:

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

Na parte superior do comutador de rack (ToR):

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

Roteador BGP do Windows:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Além deles, pelos problemas que vimos até agora (especialmente em implantações baseadas no SDNExpress), a razão mais comum para o Compartimento de Locatários não ser configurado em VMs GW parece ser o fato de que a Capacidade GW em FabricConfig.psd1 é menor em comparação com o que as pessoas tentam atribuir ao Connections 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 Data-Plane

Depois que o Controlador de Rede tiver sido implantado, as redes virtuais de locatário e as sub-redes foram criadas e as VMs foram anexadas às sub-redes virtuais, testes adicionais de nível de malha podem ser realizados pelo host para marcar conectividade do locatário.

Verificar a conectividade de rede lógica do provedor 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 HNV (Endereços IP pa) ao Host Hyper-V. Esses IPs virão do Pool de IP da rede lógica do Provedor HNV e serão gerenciados pelo Controlador de Rede. Para descobrir quais são esses dois endereços IP 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 IPs de IP do Provedor HNV são atribuídos aos Adaptadores Ethernet criados em um compartimento de rede TCPIP separado e têm um nome adaptador de VLANX , onde X é o VLAN atribuído à rede lógica HNV Provider (transporte).

A conectividade entre dois hosts Hyper-V usando a rede lógica do Provedor HNV pode ser feita 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> ...

Observação

Os Adaptadores vNIC do Host pa não são usados no caminho de dados e, portanto, não têm um IP atribuído ao adaptador "vEthernet (PAhostVNic)".

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

Hyper-V Host Endereço IP pa 1 Endereço IP pa 2
Host 1 10.10.182.64 10.10.182.65
Host 2 10.10.182.66 10.10.182.67

podemos fazer ping entre os dois usando o comando a seguir para marcar conectividade de rede lógica do Provedor 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 HNV não funcionar, marcar sua conectividade de rede física, incluindo a configuração de VLAN. Os NICs físicos em cada host Hyper-V devem estar no modo tronco sem uma VLAN específica atribuída. O vNIC do Host de Gerenciamento deve ser isolado para o 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 quadros MTU e jumbo na rede lógica do provedor HNV

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

Observação

Alguns cartões Ethernet e drivers dão suporte ao novo *EncapOverhead palavra-chave que será definido automaticamente pelo Agente de Host do Controlador de Rede como um valor de 160. Esse valor será adicionado ao valor do *JumboPacket palavra-chave cuja soma é usada como a MTU anunciada.

Por exemplo, *EncapOverhead = 160 e *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 testar se a rede lógica do Provedor HNV dá suporte ou não ao tamanho maior do 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 do MTU nas portas de comutador físico para ter pelo menos 1674B (incluindo cabeçalho Ethernet 14B e trailer)
  • Se o cartão nic não dá suporte ao palavra-chave EncapOverhead, ajuste o jumboPacket palavra-chave para ter pelo menos 1674B

Verificar a conectividade nic da VM do locatário

Cada NIC de VM atribuída a uma VM convidada tem um mapeamento de CA-PA entre a AC (Endereço do Cliente) privado e o espaço de PA (Endereço do Provedor HNV). Esses mapeamentos são mantidos nas tabelas do servidor OVSDB em cada host do 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

Observação

Se os mapeamentos de CA-PA esperados não forem saída para uma determinada VM de locatário, marcar os recursos de Configuração de IP e NIC da VM no Controlador de Rede usando o Get-NetworkControllerNetworkInterface cmdlet. Além disso, marcar as conexões estabelecidas entre o agente host NC e os nós do Controlador de Rede.

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 solucionar problemas de cenários específicos.

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

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

Observação

O VSID refere-se à ID da Sub-rede Virtual. No caso do VXLAN, este é o VNI (Identificador de Rede VXLAN). Você pode encontrar esse valor executando o Get-PACAMapping cmdlet.

Exemplo

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

Crie CA-ping entre "VM da Web Verde 1" com IP SenderCA de 192.168.1.4 no Host "sa18n30-2.sa18.nttest.microsoft.com" com IP Mgmt de 10.127.132.153 para IP ListenerCA de 192.168.1.5 ambos anexados à Sub-rede 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> ...

[Locatário] Verifique se não há políticas de firewall distribuídas especificadas na sub-rede virtual ou nas interfaces 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 estão fazendo referência a essa ACL

  1. [Hoster] Execute Get-ProviderAddress em ambos os hosts do 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 HNV
  2. [Hoster] Verifique se as configurações de MTU estão corretas nos hosts do Hyper-V e em qualquer dispositivo de comutação de Camada 2 entre os Hosts do Hyper-V. Execute Test-EncapOverheadValue em todos os hosts do Hyper-V em questão. Também marcar que todas as opções de Camada 2 entre elas tenham o MTU definido como pelo menos 1674 bytes para responder por sobrecarga máxima de 160 bytes.
  3. [Hoster] Se os endereços IP pa não estiverem presentes e/ou a conectividade de AC estiver quebrada, marcar para garantir que a política de rede tenha sido 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 corretamente estabelecidos.
  4. [Hoster] Verifique se o Agente de Host do Controlador de Rede está conectado ao Controlador de Rede. Para fazer isso, execute netstat -anp tcp |findstr 6640.
  5. [Hoster] 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. [Hoster] Verifique se a ID do Perfil da Porta corresponde à ID da Instância das Interfaces de Rede de VM das máquinas virtuais de locatário.

Log, rastreamento e diagnóstico avançados

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

Log centralizado do controlador de rede

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

Esses logs incluem logs de depuração para o cluster controlador de rede, o aplicativo 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. Da mesma forma, 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 de cluster do Controlador de Rede são armazenados em %programData%\Windows Fabric\log\Traces. Você pode especificar um local centralizado para a coleção de logs com o DiagnosticLogLocation parâmetro com a recomendação de que este 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 do Controlador de Rede de três nós.

Alterar configurações de log

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

  • Local de log centralizado.

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

  • Credenciais para acessar o local do log.

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

  • Mova para o registro em log local.

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

  • Escopo de log.

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

  • Nível de registro em log.

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

  • Tempo de envelhecimento do log.

    Os logs são armazenados de forma circular. Você tem três dias de registro em log por padrão, quer use log local ou 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á um máximo de 75 GB de dados de log se usar o log centralizado e 25 GB se estiver usando o log local. Você pode alterar esse limite com o LogSizeLimitInMBs parâmetro.

Coletando logs e rastreamentos

As implantações do VMM usam log centralizado para o Controlador de Rede por padrão. O local de compartilhamento de arquivos desses 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ó 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
  • Traços

O Controlador de Rede usa o Service Fabric (Azure). Os logs do Service Fabric podem ser necessários ao solucionar problemas de determinados problemas. Esses logs podem ser encontrados em cada nó 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.

SLB diagnóstico

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 –> SLB Mux e SLBM –> Agentes host SLB. Execute DumpSlbRestState de qualquer nó com acesso ao ponto de extremidade REST do Controlador de Rede.
  2. Valide o SDNSLBMPerfCounters no PerfMon em uma das VMs do nó controlador de rede (preferencialmente o nó principal do Controlador de Rede - Get-NetworkControllerReplica):
    1. O mecanismo de Load Balancer (LB) está conectado ao SLBM? (Configurações do SLBM LBEngine Total > 0)
    2. O SLBM pelo menos sabe sobre seus próprios pontos de extremidade? (Pontos de extremidade VIP Total>= 2)
    3. Os hosts DIP (Hyper-V) estão conectados ao SLBM? (Clientes HP conectados == servidores num)
    4. O SLBM está conectado a Muxes? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VMs).
  3. Verifique se o roteador BGP configurado está emparelhando com êxito com o MUX do SLB.
    1. Se estiver usando o RRAS com Acesso Remoto (ou seja, máquina virtual BGP):
      1. Get-BgpPeer deve mostrar conectado.
      2. Get-BgpRouteInformation deve mostrar pelo menos uma rota para o auto VIP do SLBM.
    2. Se usar o ToR (Top-of-Rack) físico alternar como PAR BGP, consulte sua documentação:
      1. Por exemplo: # show bgp instance
  4. Valide os contadores SlbMuxPerfCounters e SLBMUX no PerfMon na VM do SLB Mux.
  5. Verifique o estado de configuração e os intervalos VIP no Software Load Balancer Manager Resource.
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8(marcar intervalos VIP em Pools de IP e verifique se o auto VIP do SLBM (LoadBalanacerManagerIPAddress) e quaisquer VIPs voltados para locatários 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 alguma das verificações acima falhar, o estado SLB do locatário também estará em um modo de falha.

Remediação

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

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

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

  1. [Hoster] Verifique Debug-NetworkControllerConfigurationState se algum recurso loadbalancer está em um estado de erro. Tente atenuar seguindo a Tabela de itens de ação no Apêndice.
    1. Verifique se um ponto de extremidade VIP está presente e rotas de publicidade.
    2. Verifique quantos pontos de extremidade DIP foram descobertos para o ponto de extremidade VIP.
  2. [Locatário] Validar Load Balancer Recursos são especificados corretamente.
    1. Validar 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 back-end do LoadBalancer.
  3. [Hoster] Se os pontos de extremidade DIP não forem descobertos ou conectados:

    1. Verificar Debug-NetworkControllerConfigurationState

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

    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 a ID do perfil da porta para que a porta da máquina virtual corresponda à ID da Instância do recurso nic da máquina virtual correspondente.

  4. [Provedor de hospedagem] Coletar logs.

Rastreamento do SLB Mux

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

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

Observação

É recomendável que você tenha esse log habilitado por pouco tempo enquanto tenta reproduzir um problema.

Rastreamento VFP e vSwitch

Em qualquer host do Hyper-V que esteja hospedando uma VM convidada anexada a uma rede virtual de locatário, você pode coletar um rastreamento 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