Share via

Problemen met de software-gedefinieerde netwerkstack van Windows Server oplossen

  • Artikel

In deze handleiding worden de veelvoorkomende SDN-fouten (Software Defined Networking) en foutscenario's onderzocht en wordt een werkstroom voor probleemoplossing beschreven die gebruikmaakt van de beschikbare diagnostische hulpprogramma's. Zie Software Defined Networking voor meer informatie over SDN.

Van toepassing op: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versies 21H2 en 20H2

Fouttypen

De volgende lijst vertegenwoordigt de klasse van problemen die het vaakst wordt gezien met Hyper-V-netwerkvirtualisatie (HNVv1) in Windows Server 2012 R2 van in-market productie-implementaties en valt op veel manieren samen met dezelfde soorten problemen die worden gezien in Windows Server 2016 HNVv2 met de nieuwe SDN-stack (Software Defined Network).

De meeste fouten kunnen worden geclassificeerd in een kleine set klassen:

  • Ongeldige of niet-ondersteunde configuratie

    Een gebruiker roept de NorthBound-API onjuist aan of met ongeldig beleid.

  • Fout in beleidstoepassing

    Het beleid van de netwerkcontroller is niet geleverd aan een Hyper-V-host, is vertraagd of niet bijgewerkt op alle Hyper-V-hosts (bijvoorbeeld na een livemigratie).

  • Configuratiedrift of softwarefout

    Problemen met gegevenspaden die resulteren in verwijderde pakketten.

  • Externe fout met betrekking tot NIC-hardware/-stuurprogramma's of de onderlaagnetwerkinfrastructuur

    Onjuiste taak offloads (zoals VMQ) of onjuist geconfigureerde underlay-netwerkinfrastructuur (zoals MTU)

    In deze handleiding voor probleemoplossing worden al deze foutcategorieën onderzocht en aanbevolen aanbevolen procedures en diagnostische hulpprogramma's die beschikbaar zijn om de fout te identificeren en op te lossen.

Diagnostische hulpprogramma's

Voordat we de werkstromen voor het oplossen van problemen voor elk van deze soorten fouten bespreken, bekijken we de beschikbare diagnostische hulpprogramma's.

Als u de diagnostische hulpprogramma's voor netwerkcontroller (control-path) wilt gebruiken, moet u eerst de RSAT-NetworkController functie installeren en de NetworkControllerDiagnostics module importeren:

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

Als u de diagnostische hulpprogramma's van HNV Diagnostics (data-path) wilt gebruiken, moet u de HNVDiagnostics module importeren:

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

Diagnostische gegevens van netwerkcontroller

Deze cmdlets worden beschreven op TechNet in de cmdlet Network Controller Diagnostics. Ze helpen bij het identificeren van problemen met de consistentie van netwerkbeleid in het besturingspad tussen netwerkcontrollerknooppunten en tussen de netwerkcontroller en de NC-hostagents die worden uitgevoerd op de Hyper-V-hosts.

De Debug-ServiceFabricNodeStatus cmdlets en Get-NetworkControllerReplica moeten worden uitgevoerd vanaf een van de virtuele machines van het netwerkcontrollerknooppunt. Alle andere nc diagnostische cmdlets kunnen worden uitgevoerd vanaf elke host, die verbinding heeft met de netwerkcontroller en zich in de netwerkcontrollerbeheerbeveiligingsgroep (Kerberos) bevindt of toegang heeft tot het X.509-certificaat voor het beheren van de netwerkcontroller.

Diagnose van Hyper-V-host

Deze cmdlets worden beschreven op TechNet in de cmdlet Diagnostische gegevens van Hyper-V-netwerkvirtualisatie (HNV). Ze helpen bij het identificeren van problemen in het gegevenspad tussen virtuele tenantmachines (oost/west) en inkomend verkeer via een SLB VIP (noord/zuid).

De Debug-VirtualMachineQueueOperation, Get-CustomerRoute, Get-PACAMapping, Get-ProviderAddress, Get-VMNetworkAdapterPortId, , Get-VMSwitchExternalPortId, en Test-EncapOverheadSettings zijn allemaal lokale tests die kunnen worden uitgevoerd vanaf elke Hyper-V-host. De andere cmdlets roepen gegevenspadtests aan via de netwerkcontroller en hebben daarom toegang nodig tot de netwerkcontroller, zoals hierboven beschreven.

GitHub

De Microsoft/SDN GitHub Repo heeft veel voorbeeldscripts en werkstromen die zijn gebaseerd op deze in-box cmdlets. Diagnostische scripts zijn met name te vinden in de map Diagnostische gegevens . Help ons bij te dragen aan deze scripts door pull-aanvragen in te dienen.

Problemen met werkstromen en handleidingen oplossen

[Hoster] Systeemstatus valideren

Er is een ingesloten resource met de naam Configuratiestatus in verschillende netwerkcontrollerresources. Configuratiestatus biedt informatie over de systeemstatus, waaronder de consistentie tussen de configuratie van de netwerkcontroller en de werkelijke (actieve) status op de Hyper-V-hosts.

Als u de configuratiestatus wilt controleren, voert u het volgende uit vanaf een Hyper-V-host met connectiviteit met de netwerkcontroller.

Opmerking

De waarde voor de NetworkController parameter moet de FQDN of het IP-adres zijn op basis van de onderwerpnaam van het X.509-certificaat >dat is gemaakt voor netwerkcontroller.

De Credential parameter hoeft alleen te worden opgegeven als de netwerkcontroller Kerberos-verificatie gebruikt (gebruikelijk in VMM-implementaties). De referentie moet voor een gebruiker zijn die zich in de beveiligingsgroep Netwerkcontrollerbeheer bevindt.

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

Hieronder ziet u een voorbeeld van een configuratiestatusbericht:

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

Opmerking

Er is een fout opgetreden in het systeem waarbij de netwerkinterfaceresources voor de SLB Mux Transit-VM-NIC een foutstatus hebben met de fout 'Virtuele switch - host niet verbonden met controller'. Deze fout kan veilig worden genegeerd als de IP-configuratie in de VM-NIC-resource is ingesteld op een IP-adres uit de IP-pool van het logische transitnetwerk.

Er is een tweede fout in het systeem waarbij de netwerkinterfaceresources voor de GATEWAY HNV Provider VM-NIC's een foutstatus hebben met de fout 'Virtuele switch - PortBlocked'. Deze fout kan ook veilig worden genegeerd als de IP-configuratie in de VM-NIC-resource is ingesteld op null (standaard).

In de onderstaande tabel ziet u de lijst met foutcodes, berichten en vervolgacties die moeten worden uitgevoerd op basis van de waargenomen configuratiestatus.

Code Bericht Actie
Unknown Onbekende fout
HostUnreachable De hostcomputer is niet bereikbaar Controleer de beheernetwerkverbinding tussen netwerkcontroller en host
PAIpAddressExhausted De PA IP-adressen zijn uitgeput De ip-poolgrootte van het logische subnet van de HNV-provider vergroten
PAMacAddressExhausted De PA Mac-adressen zijn uitgeput Het bereik van de Mac-pool vergroten
PAAddressConfigurationFailure Kan pa-adressen niet naar de host instellen Controleer de netwerkverbinding beheer tussen netwerkcontroller en host.
CertificateNotTrusted Certificaat wordt niet vertrouwd Herstel de certificaten die worden gebruikt voor communicatie met de host.
CertificateNotAuthorized Certificaat niet geautoriseerd Herstel de certificaten die worden gebruikt voor communicatie met de host.
PolicyConfigurationFailureOnVfp Fout bij het configureren van VFP-beleid Dit is een runtimefout. Geen definitieve tijdelijke oplossingen. Logboeken verzamelen.
PolicyConfigurationFailure Fout bij het pushen van beleid naar de hosts, vanwege communicatiefouten of andere fouten in de NetworkController. Geen duidelijke acties. Dit wordt veroorzaakt door een fout in de doelstatusverwerking in de netwerkcontrollermodules. Logboeken verzamelen.
HostNotConnectedToController De host is nog niet verbonden met de netwerkcontroller Poortprofiel niet toegepast op de host of de host is niet bereikbaar vanaf de netwerkcontroller. Controleer of de HostID-registersleutel overeenkomt met de exemplaar-id van de serverresource
MultipleVfpEnabledSwitches Er zijn meerdere switches met VFp ingeschakeld op de host Verwijder een van de switches, omdat de hostagent van de netwerkcontroller slechts één vSwitch ondersteunt waarvoor de VFP-extensie is ingeschakeld
PolicyConfigurationFailure Kan VNet-beleid voor een VmNic niet pushen vanwege certificaatfouten of connectiviteitsfouten Controleer of de juiste certificaten zijn geïmplementeerd (de onderwerpnaam van het certificaat moet overeenkomen met de FQDN van de host). Controleer ook de hostverbinding met de netwerkcontroller
PolicyConfigurationFailure Kan vSwitch-beleid voor een VmNic niet pushen vanwege certificaatfouten of connectiviteitsfouten Controleer of de juiste certificaten zijn geïmplementeerd (de onderwerpnaam van het certificaat moet overeenkomen met de FQDN van de host). Controleer ook de hostverbinding met de netwerkcontroller
PolicyConfigurationFailure Kan firewallbeleid voor een VmNic niet pushen vanwege certificaatfouten of connectiviteitsfouten Controleer of de juiste certificaten zijn geïmplementeerd (de onderwerpnaam van het certificaat moet overeenkomen met de FQDN van de host). Controleer ook de hostverbinding met de netwerkcontroller
DistributedRouterConfigurationFailure Kan de instellingen van de gedistribueerde router op de host-vNic niet configureren TCPIP-stackfout. Mogelijk moet de PA- en DR Host-vNIC's worden opgeschoond op de server waarop deze fout is gerapporteerd
DhcpAddressAllocationFailure DHCP-adrestoewijzing is mislukt voor een VMNic Controleer of het kenmerk statisch IP-adres is geconfigureerd op de NIC-resource
CertificateNotTrusted
CertificateNotAuthorized		 Kan geen verbinding maken met Mux vanwege netwerk- of certificaatfouten Controleer de numerieke code in de foutcode: dit komt overeen met de winsock-foutcode. Certificaatfouten zijn gedetailleerd (certificaat kan bijvoorbeeld niet worden geverifieerd, certificaat niet geautoriseerd, enzovoort)
HostUnreachable MUX is beschadigd (veelvoorkomend geval is dat de verbinding met BGPRouter is verbroken) BGP-peer op de RRAS-switch (virtuele BGP-machine) of ToR-switch (Top-of-Rack) is onbereikbaar of peering mislukt. BGP-instellingen controleren op zowel Software Load Balancer Multiplexer-resource als BGP-peer (ToR- of RRAS-virtuele machine)
HostNotConnectedToController SLB-hostagent is niet verbonden Controleer of de SLB Host Agent-service wordt uitgevoerd; Raadpleeg SLB-hostagentlogboeken (automatisch uitvoeren) om redenen waarom, in het geval SLBM (NC) heeft geweigerd, het certificaat dat wordt gepresenteerd door de status van de hostagent die wordt uitgevoerd, genuanceerde informatie weergeeft
PortBlocked De VFP-poort is geblokkeerd vanwege een gebrek aan VNET-/ACL-beleid Controleer of er andere fouten zijn, waardoor het beleid mogelijk niet wordt geconfigureerd.
Overbelast Loadbalancer MUX is overbelast Prestatieprobleem met MUX
RoutePublicationFailure Loadbalancer MUX is niet verbonden met een BGP-router Controleer of de MUX verbinding heeft met de BGP-routers en of BGP-peering correct is ingesteld
VirtualServerUnreachable Loadbalancer MUX is niet verbonden met SLB-manager Connectiviteit tussen SLBM en MUX controleren
QosConfigurationFailure Kan QOS-beleid niet configureren Controleren of er voldoende bandbreedte beschikbaar is voor alle VM's als QOS-reservering wordt gebruikt

Controleer de netwerkverbinding tussen de netwerkcontroller en Hyper-V-host (NC Host Agent-service)

Voer de netstat onderstaande opdracht uit om te controleren of er drie ESTABLISHED verbindingen zijn tussen de NC-hostagent en de knooppunten van de netwerkcontroller en één LISTENING socket op de Hyper-V-host.

  • LUISTEREN op poort TCP:6640 op Hyper-V-host (NC Host Agent-service)
  • Twee tot stand gebrachte verbindingen van hyper-V-host-IP op poort 6640 naar NC-knooppunt-IP op tijdelijke poorten (> 32000)
  • Eén tot stand gebrachte verbinding van het IP-adres van de Hyper-V-host op de tijdelijke poort naar het REST-IP-adres van de netwerkcontroller op poort 6640

Opmerking

Er zijn mogelijk slechts twee tot stand gebrachte verbindingen op een Hyper-V-host als er geen virtuele tenantmachines op die specifieke host zijn geïmplementeerd.

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

Hostagentservices controleren

De netwerkcontroller communiceert met twee hostagentservices op de Hyper-V-hosts: SLB-hostagent en NC-hostagent. Het is mogelijk dat een of beide van deze services niet worden uitgevoerd. Controleer hun status en start opnieuw op als ze niet worden uitgevoerd.

Get-Service SlbHostAgent
Get-Service NcHostAgent

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

Status van netwerkcontroller controleren

Als er geen drie ESTABLISHED verbindingen zijn of als de netwerkcontroller niet reageert, controleert u of alle knooppunten en servicemodules actief zijn met behulp van de volgende cmdlets.

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

De servicemodules van de netwerkcontroller zijn:

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

Controleer of en ReplicaStatusReadyHealthState is.Ok

In een productie-implementatie met een netwerkcontroller met meerdere knooppunten kunt u ook controleren op welk knooppunt elke service primair is en de status van de afzonderlijke replica.

Get-NetworkControllerReplica

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

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

Controleer of de replicastatus Gereed is voor elke service.

Controleren op overeenkomende HostID's en certificaten tussen de netwerkcontroller en elke Hyper-V-host

Voer op een Hyper-V-host de volgende cmdlets uit om te controleren of de HostID overeenkomt met de exemplaar-id van een serverresource op de netwerkcontroller

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

Herstellen

Als u SDNExpress-scripts of handmatige implementatie gebruikt, werkt u de HostId-sleutel in het register bij zodat deze overeenkomt met de exemplaar-id van de serverresource. Start de hostagent van de netwerkcontroller opnieuw op de Hyper-V-host (fysieke server) Als u VMM gebruikt, verwijdert u de Hyper-V-server uit VMM en verwijdert u de registersleutel HostId. Voeg vervolgens de server opnieuw toe via VMM.

Controleer of de vingerafdruk van de X.509-certificaten die worden gebruikt door de Hyper-V-host (de hostnaam is de onderwerpnaam van het certificaat) voor (SouthBound) communicatie tussen de Hyper-V-host (NC Host Agent-service) en de netwerkcontrollerknooppunten hetzelfde zijn. Controleer ook of het REST-certificaat van de netwerkcontroller de onderwerpnaam heeft van 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**
...

U kunt ook de volgende parameters van elk certificaat controleren om ervoor te zorgen dat de onderwerpnaam is wat wordt verwacht (hostnaam of NC REST FQDN of IP), het certificaat nog niet is verlopen en of alle certificeringsinstanties in de certificaatketen zijn opgenomen in de vertrouwde basisinstantie.

  • Onderwerpnaam
  • Vervaldatum
  • Vertrouwd door basisinstantie

Als meerdere certificaten dezelfde onderwerpnaam hebben op de Hyper-V-host, kiest de hostagent van de netwerkcontroller er willekeurig een om aan de netwerkcontroller te presenteren. Dit komt mogelijk niet overeen met de vingerafdruk van de serverresource die bekend is bij de netwerkcontroller. In dit geval verwijdert u een van de certificaten met dezelfde onderwerpnaam op de Hyper-V-host en start u de hostagentservice van de netwerkcontroller opnieuw op. Als er nog steeds geen verbinding kan worden gemaakt, verwijdert u het andere certificaat met dezelfde onderwerpnaam op de Hyper-V-host en verwijdert u de bijbehorende serverresource in VMM. Maak vervolgens de serverresource opnieuw in VMM, waarmee een nieuw X.509-certificaat wordt gegenereerd en op de Hyper-V-host wordt geïnstalleerd.

De SLB-configuratiestatus controleren

De SLB-configuratiestatus kan worden bepaald als onderdeel van de uitvoer naar de Debug-NetworkController cmdlet. Deze cmdlet voert ook de huidige set netwerkcontrollerresources in JSON-bestanden uit, alle IP-configuraties van elke Hyper-V-host (server) en lokaal netwerkbeleid uit de databasetabellen van hostagent.

Er worden standaard meer traceringen verzameld. Als u geen traceringen wilt verzamelen, voegt u de -IncludeTraces:$false parameter toe.

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

Opmerking

De standaardlocatie voor uitvoer is de <map working_directory>\NCDiagnostics\. De standaarduitvoermap kan worden gewijzigd met behulp van de -OutputDirectory parameter.

De informatie over de SLB-configuratiestatus vindt u in het bestand diagnostics-slbstateResults.Json in deze map.

Dit JSON-bestand kan worden onderverdeeld in de volgende secties:

  • Stof
    • SlbmVips: in deze sectie wordt het IP-adres vermeld van het VIP-adres van SLB Manager, dat wordt gebruikt door de netwerkcontroller om de configuratie en status tussen de SLB Muxes en SLB-hostagents te coördineren.
    • MuxState - In deze sectie wordt één waarde weergegeven voor elke geïmplementeerde SLB Mux die de status van de mux geeft
    • Routerconfiguratie: in deze sectie vindt u een overzicht van het AUTONOME systeemnummer (ASN), het IP-adres en de id van de upstream-router (BGP-peer). Ook worden de SLB Muxes ASN en transit-IP weergegeven.
    • Informatie over verbonden host: in deze sectie vindt u het IP-adres van beheer van alle Hyper-V-hosts die beschikbaar zijn voor het uitvoeren van workloads met gelijke taakverdeling.
    • Vip-bereiken: in deze sectie worden de ip-adresbereiken voor openbare en privé-VIP-adressen vermeld. De SLBM VIP wordt opgenomen als een toegewezen IP-adres uit een van deze bereiken.
    • Mux-routes: in deze sectie wordt één waarde weergegeven voor elke geïmplementeerde SLB Mux met alle routeadvertenties voor die specifieke mux.
  • Tenant
    • VipConsolidatedState: in deze sectie wordt de connectiviteitsstatus voor elke tenant-VIP vermeld, inclusief geadverteerde routevoorvoegsel, Hyper-V-host en DIP-eindpunten.

Opmerking

De SLB-status kan rechtstreeks worden vastgesteld met behulp van het script DumpSlbRestState dat beschikbaar is in de Microsoft SDN GitHub-opslagplaats.

Gatewayvalidatie

Vanaf de netwerkcontroller:

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

Vanaf gateway-VM:

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

Vanaf de top van het rek (ToR) switch:

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

Windows BGP-router:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Naast deze, van de problemen die we tot nu toe hebben gezien (met name op SDNExpress-implementaties), lijkt de meest voorkomende reden voor het niet configureren van tenantcompartiment op GW-VM's het feit te zijn dat de GW-capaciteit in FabricConfig.psd1 minder is in vergelijking met wat mensen proberen toe te wijzen aan de Netwerk Connections (S2S-tunnels) in TenantConfig.psd1. Dit kan eenvoudig worden gecontroleerd door de uitvoer van de volgende cmdlets te vergelijken:

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] Data-Plane valideren

Nadat de netwerkcontroller is geïmplementeerd, virtuele netwerken en subnetten van tenants zijn gemaakt en VM's zijn gekoppeld aan de virtuele subnetten, kunnen aanvullende tests op infrastructuurniveau door de hoster worden uitgevoerd om de tenantconnectiviteit te controleren.

Logische netwerkverbinding van de HNV-provider controleren

Nadat de eerste gast-VM die wordt uitgevoerd op een Hyper-V-host is verbonden met een virtueel tenantnetwerk, wijst de netwerkcontroller twee IP-adressen (PA-IP-adressen) van de HNV-provider toe aan de Hyper-V-host. Deze IP-adressen zijn afkomstig van de IP-pool van het logische HNV-providernetwerk en worden beheerd door de netwerkcontroller. Om erachter te komen wat deze twee HNV IP-adressen zijn:

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

Deze HNV Provider IP-adressen (PA IP-adressen) worden toegewezen aan Ethernet-adapters die zijn gemaakt in een afzonderlijk TCPIP-netwerkcompartiment en hebben de adapternaam VLANX , waarbij X het VLAN is dat is toegewezen aan het logische HNV-providernetwerk (transport).

Connectiviteit tussen twee Hyper-V-hosts met behulp van het logische netwerk van de HNV-provider kan worden uitgevoerd door een ping met een extra compartiment (-c Y) parameter, waarbij Y het TCPIP-netwerkcompartiment is waarin de PAhostVNI's worden gemaakt. Dit compartiment kan worden bepaald door het volgende uit te voeren:

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

Opmerking

De VNIC-adapters van de PA-host worden niet gebruikt in het gegevenspad en hebben dus geen IP-adres toegewezen aan de 'vEthernet(PAhostVNic)-adapter'.

Stel dat Hyper-V-hosts 1 en 2 IP-adressen van de HNV-provider (PA) hebben van:

Hyper-V-host PA IP-adres 1 PA IP-adres 2
Host 1 10.10.182.64 10.10.182.65
Host 2 10.10.182.66 10.10.182.67

we kunnen pingen tussen de twee met behulp van de volgende opdracht om de logische netwerkverbinding van de HNV-provider te controleren.

# 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

Herstellen

Als HNV Provider-ping niet werkt, controleert u uw fysieke netwerkverbinding, inclusief VLAN-configuratie. De fysieke NIC's op elke Hyper-V-host moeten zich in de trunkmodus bevinden zonder dat er een specifiek VLAN is toegewezen. De vNIC van de beheerhost moet worden geïsoleerd met het VLAN van het logische beheernetwerk.

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

Ondersteuning voor MTU en jumboframe controleren op het logische netwerk van de HNV-provider

Een ander veelvoorkomend probleem in het logische netwerk van de HNV-provider is dat de fysieke netwerkpoorten en/of Ethernet-kaart geen grote MTU hebben die is geconfigureerd om de overhead van VXLAN-inkapseling (of NVGRE) af te handelen.

Opmerking

Sommige Ethernet-kaarten en -stuurprogramma's ondersteunen het nieuwe *EncapOverhead trefwoord dat automatisch door de hostagent van de netwerkcontroller wordt ingesteld op de waarde 160. Deze waarde wordt vervolgens toegevoegd aan de waarde van het trefwoord *JumboPacket waarvan de optelsom wordt gebruikt als de geadverteerde MTU.

Bijvoorbeeld *EncapOverhead = 160 en *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

Als u wilt testen of het logische netwerk van de HNV-provider de grotere MTU-grootte end-to-end ondersteunt, gebruikt u de 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.

Herstellen

  • Pas de MTU-grootte op de fysieke switchpoorten aan op ten minste 1674B (inclusief 14B Ethernet-header en trailer)
  • Als uw NIC-kaart het trefwoord EncapOverhead niet ondersteunt, past u het sleutelwoord JumboPacket aan op ten minste 1674B

NIC-connectiviteit van tenant-VM's controleren

Elke VM-NIC die is toegewezen aan een gast-VM heeft een CA-PA-toewijzing tussen het privéadres van de klant (CA) en de HNV Provider Address (PA)-ruimte. Deze toewijzingen worden bewaard in de OVSDB-servertabellen op elke Hyper-V-host en kunnen worden gevonden door de volgende cmdlet uit te voeren.

# 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

Opmerking

Als de CA-PA-toewijzingen die u verwacht niet worden uitgevoerd voor een bepaalde tenant-VM, controleert u de VM-NIC en IP-configuratieresources op de netwerkcontroller met behulp van de Get-NetworkControllerNetworkInterface cmdlet. Controleer ook de tot stand gebrachte verbindingen tussen de NC-hostagent en de netwerkcontrollerknooppunten.

Met deze informatie kan nu een tenant-VM-ping worden gestart door de hoster vanaf de netwerkcontroller met behulp van de Test-VirtualNetworkConnection cmdlet.

Specifieke scenario's voor probleemoplossing

De volgende secties bevatten richtlijnen voor het oplossen van specifieke scenario's.

Geen netwerkverbinding tussen twee virtuele tenantmachines

  1. [Tenant] Zorg ervoor dat Windows Firewall op virtuele tenantmachines geen verkeer blokkeert.
  2. [Tenant] Controleer of IP-adressen zijn toegewezen aan de virtuele tenantmachine door uit te voeren ipconfig.
  3. [Hoster] Voer uit Test-VirtualNetworkConnection vanaf de Hyper-V-host om de connectiviteit tussen de twee virtuele tenantmachines in kwestie te valideren.

Opmerking

De VSID verwijst naar de id van het virtuele subnet. In het geval van VXLAN is dit de VXLAN-netwerk-id (VNI). U kunt deze waarde vinden door de Get-PACAMapping cmdlet uit te voeren.

Voorbeeld

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

Ca-ping maken tussen 'Green Web VM 1' met SenderCA IP van 192.168.1.4 op host 'sa18n30-2.sa18.nttest.microsoft.com' met Mgmt IP van 10.127.132.153 naar ListenerCA IP van 192.168.1.5 beide gekoppeld aan Virtual Subnet (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> ...

[Tenant] Controleer of er geen gedistribueerd firewallbeleid is opgegeven op het virtuele subnet of vm-netwerkinterfaces die verkeer blokkeren.

Voer een query uit op de REST API van de netwerkcontroller in de demo-omgeving op sa18n30nc in het domein sa18.nttest.microsoft.com.

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

Bekijk de IP-configuratie en virtuele subnetten die verwijzen naar deze ACL

  1. [Hoster] Voer Get-ProviderAddress uit op beide Hyper-V-hosts die als host fungeren voor de twee betreffende virtuele tenantmachines en voer Test-LogicalNetworkConnection vervolgens of ping -c <compartment> uit vanaf de Hyper-V-host om de connectiviteit op het logische netwerk van de HNV-provider te valideren
  2. [Hoster] Zorg ervoor dat de MTU-instellingen juist zijn op de Hyper-V-hosts en eventuele Layer-2-schakelapparaten tussen de Hyper-V-hosts. Uitvoeren Test-EncapOverheadValue op alle Hyper-V-hosts in kwestie. Controleer ook of voor alle Layer-2-schakelopties tussen de schakelopties MTU is ingesteld op minimaal 1674 bytes om rekening te houden met de maximale overhead van 160 bytes.
  3. [Hoster] Als PA IP-adressen niet aanwezig zijn en/of de CA-connectiviteit is verbroken, controleert u of het netwerkbeleid is ontvangen. Voer uit Get-PACAMapping om te zien of de inkapselingsregels en CA-PA-toewijzingen die zijn vereist voor het maken van overlay-virtuele netwerken correct zijn ingesteld.
  4. [Hoster] Controleer of de hostagent van de netwerkcontroller is verbonden met de netwerkcontroller. Voer hiervoor uit netstat -anp tcp |findstr 6640.
  5. [Hoster] Controleer of de host-id in HKLM/ overeenkomt met de instantie-id van de serverresources die als host fungeren voor de virtuele machines van de tenant.
  6. [Hoster] Controleer of de poortprofiel-id overeenkomt met de instantie-id van de VM-netwerkinterfaces van de virtuele machines van de tenant.

Logboekregistratie, tracering en geavanceerde diagnostische gegevens

De volgende secties bevatten informatie over geavanceerde diagnostische gegevens, logboekregistratie en tracering.

Gecentraliseerde logboekregistratie van netwerkcontroller

De netwerkcontroller kan automatisch foutopsporingslogboeken verzamelen en deze opslaan op een centrale locatie. Logboekverzameling kan worden ingeschakeld wanneer u de netwerkcontroller voor het eerst of later implementeert. De logboeken worden verzameld van de netwerkcontroller en netwerkelementen die worden beheerd door netwerkcontroller: hostmachines, software load balancers (SLB) en gatewaymachines.

Deze logboeken bevatten foutopsporingslogboeken voor het netwerkcontrollercluster, de toepassing Netwerkcontroller, gatewaylogboeken, SLB, virtuele netwerken en de gedistribueerde firewall. Wanneer een nieuwe host/SLB/gateway wordt toegevoegd aan de netwerkcontroller, wordt logboekregistratie op deze computers gestart. Wanneer een host/SLB/gateway van de netwerkcontroller wordt verwijderd, wordt logboekregistratie op die computers gestopt.

Logboekregistratie inschakelen

Logboekregistratie wordt automatisch ingeschakeld wanneer u het netwerkcontrollercluster installeert met behulp van de Install-NetworkControllerCluster cmdlet. Standaard worden de logboeken lokaal verzameld op de netwerkcontrollerknooppunten op %systemdrive%\SDNDiagnostics. U wordt aangeraden deze locatie te wijzigen in een externe bestandsshare (niet lokaal).

De clusterlogboeken van de netwerkcontroller worden opgeslagen in %programData%\Windows Fabric\log\Traces. U kunt een centrale locatie voor logboekverzameling opgeven met de DiagnosticLogLocation parameter met de aanbeveling dat dit ook een externe bestandsshare is.

Als u de toegang tot deze locatie wilt beperken, kunt u de toegangsreferenties opgeven met de LogLocationCredential parameter. Als u de referenties opgeeft voor toegang tot de logboeklocatie, moet u ook de CredentialEncryptionCertificate parameter opgeven, die wordt gebruikt voor het versleutelen van de referenties die lokaal zijn opgeslagen op de netwerkcontrollerknooppunten.

Met de standaardinstellingen wordt aanbevolen dat u ten minste 75 GB vrije ruimte hebt op de centrale locatie en 25 GB op de lokale knooppunten (als u geen centrale locatie gebruikt) voor een netwerkcontrollercluster met drie knooppunten.

Instellingen voor logboekregistratie wijzigen

U kunt instellingen voor logboekregistratie op elk gewenst moment wijzigen met behulp van de Set-NetworkControllerDiagnostic cmdlet. De volgende instellingen kunnen worden gewijzigd:

  • Gecentraliseerde logboeklocatie.

    U kunt de locatie wijzigen om alle logboeken op te slaan, met de DiagnosticLogLocation parameter.

  • Referenties voor toegang tot logboeklocatie.

    U kunt de referenties wijzigen voor toegang tot de logboeklocatie, met de LogLocationCredential parameter.

  • Naar lokale logboekregistratie gaan.

    Als u een gecentraliseerde locatie hebt opgegeven voor het opslaan van logboeken, kunt u teruggaan naar de lokale logboekregistratie op de netwerkcontrollerknooppunten met de UseLocalLogLocation parameter (niet aanbevolen vanwege grote schijfruimtevereisten).

  • Logboekregistratiebereik.

    Standaard worden alle logboeken verzameld. U kunt het bereik wijzigen zodat alleen netwerkcontrollerclusterlogboeken worden verzameld.

  • Logboekregistratieniveau.

    Het standaardniveau voor logboekregistratie is Informatief. U kunt dit wijzigen in Fout, Waarschuwing of Uitgebreid.

  • Verouderingstijd registreren.

    De logboeken worden circulair opgeslagen. U hebt standaard drie dagen aan logboekregistratiegegevens, ongeacht of u lokale logboekregistratie of gecentraliseerde logboekregistratie gebruikt. U kunt deze tijdslimiet wijzigen met de LogTimeLimitInDays parameter.

  • Grootte van logboekveroudering.

    Standaard hebt u maximaal 75 GB aan logboekgegevens als u gecentraliseerde logboekregistratie gebruikt en 25 GB als u lokale logboekregistratie gebruikt. U kunt deze limiet wijzigen met de LogSizeLimitInMBs parameter.

Logboeken en traceringen verzamelen

VMM-implementaties maken standaard gebruik van gecentraliseerde logboekregistratie voor de netwerkcontroller. De locatie van de bestandsshare voor deze logboeken wordt opgegeven bij het implementeren van de servicesjabloon voor de netwerkcontroller.

Als er geen bestandslocatie is opgegeven, wordt lokale logboekregistratie gebruikt op elk netwerkcontrollerknooppunt met logboeken die zijn opgeslagen onder C:\Windows\tracing\SDNDiagnostics. Deze logboeken worden opgeslagen met behulp van de volgende hiërarchie:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Sporen

De netwerkcontroller maakt gebruik van (Azure) Service Fabric. Service Fabric-logboeken zijn mogelijk vereist bij het oplossen van bepaalde problemen. Deze logboeken vindt u op elk netwerkcontrollerknooppunt op C:\ProgramData\Microsoft\Service Fabric.

Als een gebruiker de Debug-NetworkController cmdlet heeft uitgevoerd, zijn er meer logboeken beschikbaar op elke Hyper-V-host, die is opgegeven met een serverresource in de netwerkcontroller. Deze logboeken (en traceringen indien ingeschakeld) worden bewaard onder C:\NCDiagnostics.

Diagnostische gegevens van SLB

SLBM-infrastructuurfouten (acties van hostingserviceprovider)

  1. Controleer of Software Load Balancer Manager (SLBM) werkt en of de indelingslagen met elkaar kunnen communiceren: SLBM -> SLB Mux en SLBM -> SLB-hostagents. Voer DumpSlbRestState uit vanaf een knooppunt met toegang tot het REST-eindpunt van de netwerkcontroller.
  2. Valideer de SDNSLBMPerfCounters in PerfMon op een van de netwerkcontrollerknooppunt-VM's (bij voorkeur het primaire netwerkcontrollerknooppunt - Get-NetworkControllerReplica):
    1. Is Load Balancer -engine (LB) verbonden met SLBM? (Totaal > SLBM LBEngine-configuraties 0)
    2. Weet SLBM ten minste over de eigen eindpunten? (Totaal vip-eindpunten>= 2)
    3. Zijn Hyper-V-hosts (DIP) verbonden met SLBM? (HP-clients verbonden == aantal servers)
    4. Is SLBM verbonden met Muxes? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VM's).
  3. Zorg ervoor dat de geconfigureerde BGP-router is peering met de SLB MUX.
    1. Als u RRAS gebruikt met externe toegang (dat wil gezegd, virtuele BGP-machine):
      1. Get-BgpPeer moet verbonden worden weergegeven.
      2. Get-BgpRouteInformation moet ten minste een route voor de zelf-VIP van SLBM weergeven.
    2. Als u een fysieke ToR-switch (Top-of-Rack) gebruikt als BGP-peer, raadpleegt u uw documentatie:
      1. Bijvoorbeeld:# show bgp instance
  4. Valideer de SlbMuxPerfCounters- en SLBMUX-tellers in PerfMon op de SLB Mux-VM.
  5. Controleer de configuratiestatus en VIP-bereiken in Software Load Balancer Manager-resource.
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (controleer vip-bereiken in IP-pools en zorg ervoor dat SLBM self-VIP (LoadBalanacerManagerIPAddress) en eventuele tenantgerichte VIP's binnen deze bereiken vallen)
      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 -

Als een van de bovenstaande controles mislukt, bevindt de status van de tenant-SLB zich ook in een foutmodus.

Herstellen

Los het volgende op op basis van de volgende diagnostische informatie:

  • Zorg ervoor dat SLB-multiplexers zijn verbonden
    • Certificaatproblemen oplossen
    • Netwerkverbindingsproblemen oplossen
  • Zorg ervoor dat BGP-peeringgegevens zijn geconfigureerd
  • Zorg ervoor dat de host-id in het register overeenkomt met de serverexemplaren-id in serverbron (referentie-bijlage voor HostNotConnected-foutcode )
  • Logboeken verzamelen

SLBM-tenantfouten (hostingserviceprovider- en tenantacties)

  1. [Hoster] Controleer Debug-NetworkControllerConfigurationState of loadbalancer-resources een foutstatus hebben. Probeer dit te verhelpen door de tabel Actie-items in de bijlage te volgen.
    1. Controleer of er een VIP-eindpunt aanwezig is en of er reclameroutes zijn.
    2. Controleer hoeveel DIP-eindpunten zijn gedetecteerd voor het VIP-eindpunt.
  2. [Tenant] Controleer Load Balancer resources correct zijn opgegeven.
    1. Controleer of DIP-eindpunten die zijn geregistreerd in SLBM als host fungeren voor virtuele tenantmachines, die overeenkomen met de IP-configuraties van de LoadBalancer-back-endadresgroep.
  3. [Hoster] Als DIP-eindpunten niet worden gedetecteerd of verbonden:

    1. Controleren Debug-NetworkControllerConfigurationState

      Controleer of de NC- en SLB-hostagent is verbonden met de gebeurteniscoördinator van de netwerkcontroller met behulp van netstat -anp tcp |findstr 6640).

    2. Service-regkey HostId(referentiefoutcode HostNotConnected in de bijlage) komt overeen met de instantie-id van de bijbehorende serverresource (Get-NCServer |convertto-json -depth 8).nchostagent

    3. Controleer de poortprofiel-id voor de poort van de virtuele machine die overeenkomt met de instantie-id van de NIC-resource van de virtuele machine.

  4. [Hostingprovider] Logboeken verzamelen.

SLB Mux-tracering

Informatie van de Software Load Balancer Muxes kan ook worden bepaald via Logboeken.

  1. Selecteer Analyse- en foutopsporingslogboeken weergeven in het menu Logboeken Weergave.
  2. Navigeer in Logboeken naar Logboeken > voor toepassingen en servicesmicrosoft>Windows>SlbMuxDriver>Trace.
  3. Klik er met de rechtermuisknop op en selecteer Logboek inschakelen.

Opmerking

Het is raadzaam dat u deze logboekregistratie alleen voor een korte tijd hebt ingeschakeld terwijl u een probleem probeert te reproduceren.

VFP- en vSwitch-tracering

Vanaf elke Hyper-V-host die als host fungeert voor een gast-VM die is gekoppeld aan een virtueel tenantnetwerk, kunt u een VFP-tracering verzamelen om te bepalen waar zich problemen kunnen voordoen.

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