Delen 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 besproken 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 met het meest toegepast met Hyper-V-Netwerkvirtualisatie (HNVv1) in Windows Server 2012 R2 uit in de markt productie-implementaties en in vele manieren overeenkomt met de dezelfde soort problemen in Windows Server 2016 HNVv2 met de nieuwe Software gedefinieerde netwerk (SDN)-Stack weergegeven.

De meeste fouten kunnen worden ingedeeld in een kleine set van klassen:

  • Ongeldige of niet-ondersteunde configuratie

    Een gebruiker roept de NorthBound API onjuist of ongeldig beleid.

  • Fout in de toepassing van beleid

    Beleid van de netwerkcontroller is niet geleverd aan een Hyper-V-host, vertraagd of niet up-to-date op alle Hyper-V-hosts (bijvoorbeeld na een livemigratie).

  • Configuratie drift of software-oplossingen

    Pad naar de Data problemen ertoe uitgevallen pakketten.

  • Externe fout gerelateerd aan NIC hardware / stuurprogramma's of het aan de basis liggen fabric-netwerk

    Zorgt taak verplaatst (zoals VMQ) of aan de basis liggen netwerk fabric onjuist geconfigureerd (zoals of MTU Genoemd)

    Deze handleiding voor probleemoplossing onderzoekt elk van deze foutcategorieën en aanbevolen procedures en diagnostische hulpprogramma's die beschikbaar is om te bepalen en corrigeer de fout.

Diagnostische hulpprogramma's

Voordat u de werkstromen voor probleemoplossing voor elk van deze typen fouten bespreekt, gaan we de beschikbare diagnostische hulpprogramma's bekijken.

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

U moet importeren voor het gebruik van de HNV Diagnostics (gegevenspad) diagnostische hulpprogramma's, de HNVDiagnostics module:

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

Controller-Netwerkdiagnose

Deze cmdlets worden gedocumenteerd op TechNet in de cmdlet Network Controller Diagnostics. Ze te identificeren van problemen met het netwerk beleid consistentie in het besturingselement-pad tussen knooppunten netwerkcontroller en tussen de netwerkcontroller en de NC-Host-Agents op de Hyper-V-hosts.

De Debug-ServiceFabricNodeStatus en Get-NetworkControllerReplica cmdlets moeten worden uitgevoerd vanaf een van de virtuele machines van het netwerkcontrollerknooppunt. Alle andere NC Diagnostic-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.

Diagnostische gegevens van Hyper-V-host

Deze cmdlets worden beschreven op TechNet in de cmdlet Diagnostische gegevens over Hyper-V-netwerkvirtualisatie (HNV). Ze te identificeren van problemen in het gegevenspad tussen virtuele machines van tenants (Oostelijke/Westelijke) en ingress verkeer via een SLB VIP (noordelijke/zuidelijke richting).

De Debug-VirtualMachineQueueOperation, Get-CustomerRoute, Get-PACAMapping, , Get-ProviderAddress, , Get-VMNetworkAdapterPortIden Test-EncapOverheadSettings Get-VMSwitchExternalPortIdzijn alle 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-opslagplaats bevat veel voorbeeldscripts en werkstromen die zijn gebaseerd op deze in-box cmdlets. In het bijzonder diagnostische scripts vindt u in de Diagnostics map. 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 bron met de naam Configuratiestatus in een aantal van de netwerkcontroller resources. Status van de configuratie bevat informatie over de systeemstatus, met inbegrip van de consistentie tussen de netwerkcontroller configuratie en de status van de werkelijke (lopende) op de Hyper-V-hosts.

Om configuratiestatus te controleren, voer de volgende van elke Hyper-V-host verbindingsproblemen met de netwerkcontroller.

Notitie

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

De Credential parameter hoeft alleen te worden opgegeven als de netwerkcontroller Kerberos-verificatie gebruikt (typisch in VMM-implementaties). De referentie moet voor een gebruiker die in de groep netwerkbeheer Controller beveiliging zijn.

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

Een voorbeeld configuratie statusbericht worden hieronder weergegeven:

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

Notitie

Er is een fout in het systeem waar de Network Interface-resources voor de Netwerkkaart SLB Mux doorvoer op VM in een foutstatus met de fout "Virtuele Switch – niet verbonden aan hostcontroller zijn". Deze fout kan veilig worden genegeerd als de IP-adresconfiguratie in de VM NIC-bron is ingesteld op een IP-adres uit het logische netwerk van IP-adresgroep.

Er is een tweede fout in het systeem waar de Network Interface-resources voor de Gateway HNV Provider VM NIC's in een foutstatus met de fout "Virtuele Switch – PortBlocked zijn". Deze fout kan ook veilig worden genegeerd als de IP-adresconfiguratie in de VM NIC-bron is ingesteld op null (standaard).

De volgende tabel bevat een lijst met foutcodes, berichten en vervolgacties onderneemt op basis van de configuratiestatus waargenomen.

Code Bericht Actie
Onbekend Onbekende fout
HostUnreachable De hostmachine is niet bereikbaar Controleer de netwerkverbinding Management tussen netwerkcontroller en Host
PAIpAddressExhausted De IP-adressen van de PA zijn uitgeput Vergroot de HNV-Provider logische-subnet IP-adresgroep
PAMacAddressExhausted De uitgeput PA Mac-adressen Vergroot het bereik van de Mac-adresgroep
PAAddressConfigurationFailure Leegmaken PA-adressen naar de host is mislukt. Controleer de netwerkverbinding Management tussen netwerkcontroller en Host.
CertificateNotTrusted Certificaat wordt niet vertrouwd Corrigeer de certificaten gebruikt voor communicatie met de host.
CertificateNotAuthorized Certificaat is niet geautoriseerd Corrigeer de certificaten gebruikt voor communicatie met de host.
PolicyConfigurationFailureOnVfp Fout bij het configureren van VFP beleid Dit is een runtime-fout. Geen definitieve tijdelijke oplossingen. Logboeken te verzamelen.
PolicyConfigurationFailure Fout in het beleid voor de hosts, vanwege communicatiefouten of anderen pushen fout in de NetworkController. Geen goede acties. Dit is vanwege fout in doel staat in de modules netwerkcontroller verwerken. Logboeken te verzamelen.
HostNotConnectedToController De Host is nog niet verbonden met de netwerkcontroller Poortprofiel niet worden toegepast op de host of de host is niet bereikbaar is vanaf de netwerkcontroller. Valideren dat de registersleutel host-id overeenkomt met de exemplaar-ID van de server-bron
MultipleVfpEnabledSwitches Er zijn meerdere VFp Switches ingeschakeld op de host Een van de switches worden verwijderd omdat netwerk Controller Hostagent biedt alleen ondersteuning voor één vSwitch de VFP uitbreiding is ingeschakeld
PolicyConfigurationFailure VNet-beleid voor een VmNic vanwege certificaatfouten of fouten in de basisnetwerkverbinding push is mislukt. Controleer of de juiste certificaten zijn is geïmplementeerd (naam van de certificaathouder moet overeenkomen met FQDN-NAAM van de host). Controleer ook of de host verbonden is met de netwerkcontroller
PolicyConfigurationFailure Kan geen push vSwitch beleid voor een VmNic vanwege certificaatfouten of connectiviteitsfouten Controleer of de juiste certificaten zijn is geïmplementeerd (naam van de certificaathouder moet overeenkomen met FQDN-NAAM van de host). Controleer ook of de host verbonden is met de netwerkcontroller
PolicyConfigurationFailure Kan geen push-Firewall-beleid voor een VmNic vanwege certificaatfouten of connectiviteitsfouten Controleer of de juiste certificaten zijn is geïmplementeerd (naam van de certificaathouder moet overeenkomen met FQDN-NAAM van de host). Controleer ook of de host verbonden is met de netwerkcontroller
DistributedRouterConfigurationFailure De gedistribueerde router-instellingen configureren op de host vNic is mislukt TCP/IP-stack-fout. Opruimen van de vNICs PA en DR-Host op de server waarop deze fout kan vereisen
DhcpAddressAllocationFailure DHCP-adrestoewijzing is mislukt voor een VMNic Als het kenmerk statische IP-adres is geconfigureerd op de bron NIC controleren
CertificateNotTrusted
CertificateNotAuthorized		 Kan geen verbinding met Mux als gevolg van fouten van netwerk- of certificaat Controleer de numerieke code die is opgegeven in de bericht-foutcode: dit komt overeen met de winsock-foutcode. Certificaatfouten worden gedetailleerd (bijvoorbeeld: certificaat kan niet worden geverifieerd, certificaat niet is gemachtigd, enz.)
HostUnreachable MUX is niet in orde (de meeste gevallen is BGPRouter verbroken) BGP-peer op de RRAS (BGP virtuele machine) of switch Top of Rack (ToR) is niet bereikbaar is of niet peering is. Controleer BGP-instellingen op Software Load Balancer Multiplexer resource en BGP-peer (ToR of RRAS virtuele machine)
HostNotConnectedToController SLB hostagent is niet verbonden Controleer of de SLB Host Agent-service wordt uitgevoerd. Raadpleeg SLB host agent Logboeken (automatisch uitgevoerd) om redenen waarom, in het geval SLBM (NC) het certificaat dat wordt aangeboden door het hostagent die wordt uitgevoerd afgewezen status nuanced gegevens weergegeven
PortBlocked De VFP-poort is geblokkeerd vanwege een gebrek aan VNET / ACL-beleid Controleer of er andere fouten, wat leiden tot het beleid zijn kunnen kan niet worden geconfigureerd.
Overbelast Loadbalancer MUX is overbelast Prestatieprobleem met MUX
RoutePublicationFailure Loadbalancer MUX niet is verbonden met een BGP-router Controleer of de MUX verbonden met de BGP-routers en die BGP peering is is juist geconfigureerd
VirtualServerUnreachable Loadbalancer MUX niet is verbonden met SLB manager Controleer de verbinding tussen SLBM en MUX
QosConfigurationFailure Configureren van QoS-beleid is mislukt Of er voldoende bandbreedte beschikbaar is voor alle virtuele Machine 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)
  • Een verbinding tot stand gebracht van Hyper-V-host IP-Adres op de tijdelijke poort netwerk Controller REST IP-Adres op poort 6640

Notitie

Er kan alleen worden twee tot stand gebrachte verbindingen op Hyper-V-host als er geen virtuele machines van tenants op die bepaalde host is 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 host agent-services op de Hyper-V-hosts: SLB Hostagent en Host-NC-Agent. Het is mogelijk dat een of beide services niet worden uitgevoerd. Hun status controleren en opnieuw starten als ze niet wordt uitgevoerd.

Get-Service SlbHostAgent
Get-Service NcHostAgent

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

Controleer de status van de netwerkcontroller

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 netwerk-controller service-modules zijn:

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

Controleer of dat ReplicaStatus het is Ready en HealthState is Ok.

In een productie-implementatie is met een netwerkcontroller met meerdere knooppunten kunt u ook controleren welk knooppunt elke service op primaire is en de status van 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 Status van Replica 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

Herstel

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 Controller Host-Agent op de Hyper-V-host (fysieke server) als de Hyper-V-Server met VMM, verwijderen uit VMM en verwijder de registersleutel host-id. Voeg vervolgens de server opnieuw toe via VMM.

Controleer of de vingerafdrukken van de X.509-certificaten door de Hyper-V-host (de hostnaam worden onderwerpnaam van het certificaat) gebruikt voor communicatie tussen de Hyper-V-Host (NC Host Agent-service) en de netwerkcontroller knooppunten (SouthBound) hetzelfde zijn. Controleer ook of het REST-certificaat van de netwerkcontroller de onderwerpnaam heeft.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 er wordt verwacht (hostnaam of NC REST FQDN of IP), het certificaat is nog niet verlopen en dat alle certificeringsinstanties in de certificaatketen zijn opgenomen in de vertrouwde basisinstantie.

  • Onderwerpnaam
  • Verloopdatum
  • Vertrouwd door de basiscertificeringsinstantie

Als meerdere certificaten dezelfde onderwerpnaam hebben op de Hyper-V-host, kiest de hostagent voor 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. Verwijder in dit geval een van de certificaten met dezelfde onderwerpnaam op de Hyper-V-host en start de hostagentservice voor 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 geïnstalleerd op de Hyper-V-host.

De SLB-configuratiestatus controleren

De SLB-configuratiestatus kan worden bepaald als onderdeel van de uitvoer voor de Debug-NetworkController cmdlet. Met deze cmdlet wordt ook de huidige set met resources in JSON-bestanden, alle IP-configuraties van elke Hyper-V-host (server) en het lokale netwerkbeleid van de Hostagent databasetabellen netwerkcontroller uitvoeren.

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

Notitie

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

De status van de configuratie SLB kunt u vinden de diagnostics slbstateResults.Json bestand in deze map.

Deze JSON-bestand kan worden opgesplitst in de volgende secties:

  • Stof
    • SlbmVips - Deze sectie bevat het IP-adres van het VIP-adres van SLB Manager, dat wordt gebruikt door de netwerkcontroller om de configuratie en status tussen de SLB Muxes en SLB Host Agents te coördineren.
    • MuxState - in deze sectie vindt u een waarde voor elke SLB Mux geïmplementeerd geeft de status van de mux
    • Routerconfiguratie - in deze sectie wordt een lijst met Upstream van de Router (BGP-Peer) Autonomous System Number (ASN), doorvoer IP-adres en -ID. Dit wordt ook een lijst SLB Muxes ASN en IP-overdracht.
    • Verbonden Host Info - in deze sectie heeft lijst het beheer van IP-Adres betrekking op alle Hyper-V-hosts beschikbaar voor uitvoering van netwerktaakverdeling werkbelastingen.
    • De openbare en persoonlijke adresgroepbereiken VIP IP-adresbereiken VIP - in deze sectie wordt een lijst. Het VIP SLBM worden opgenomen als een toegewezen IP-uit een van deze bereiken.
    • Mux Routes - in deze sectie wordt een lijst één waarde voor elke SLB Mux geïmplementeerd die alle van de Route advertenties voor die specifieke mux.
  • Huurder
    • VipConsolidatedState: in deze sectie wordt de connectiviteitsstatus vermeld voor elke tenant-VIP, inclusief geadverteerd routevoorvoegsel, Hyper-V-host en DIP-eindpunten.

Notitie

Status SLB toegankelijk zijn via de DumpSlbRestState script beschikbaar is op de Microsoft SDN GitHub-opslagplaats.

Gatewayvalidatie

Vanaf 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 tor-switch (Top of Rack):

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

Windows BGP-router:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Naast deze informatie wordt van de problemen die we tot nu toe hebben gezien (met name op SDNExpress op basis van implementaties), de meest voorkomende reden voor Tenant compartiment niet ophalen van geconfigureerd op virtuele machines GW lijken te zijn van het feit dat de capaciteit van de GW in FabricConfig.psd1 kleiner vergeleken is met mensen probeer toewijzen aan de netwerkverbindingen (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] Gegevens vlak valideren

Nadat de netwerkcontroller is geïmplementeerd, virtuele tenantnetwerken en subnetten zijn gemaakt en VM's zijn gekoppeld aan de virtuele subnetten, kunnen aanvullende fabric niveau tests worden uitgevoerd door de hoster om te controleren van de huurder verbinding.

De logische netwerkconnectiviteit van de HNV-provider controleren

Na de eerste Gast VM wordt uitgevoerd op een Hyper-V-host is verbonden met een virtueel tenantnetwerk, wordt de netwerkcontroller twee HNV Provider IP-adressen (PA IP-adressen) toewijzen aan de Hyper-V-Host. Deze IP-adressen afkomstig is van het HNV-Provider logische-netwerk-IP-adresgroep en worden beheerd door de netwerkcontroller. Ga als volgt te werk 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 IP-adressen voor HNV-Provider (PA IP's) zijn toegewezen aan Ethernet-Adapters die zijn gemaakt in een apart gedeelte van de TCP/IP-netwerk en de adapternaam van een van VLANX waarbij X staat voor het VLAN toegewezen aan het logische netwerk van HNV-Provider (transport).

Verbinding tussen twee Hyper-V-hosts met de HNV-Provider logisch netwerk kan worden uitgevoerd door een ping met een extra compartiment (-c Y) parameter waar Y is de TCP/IP-netwerk bevinden waarin de PAhostVNICs worden gemaakt. Deze ruimte kan worden bepaald door 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> ...

Notitie

De PA Host vNIC Adapters worden niet gebruikt in het gegevenspad en dus niet een Integratiepakket toegewezen aan 'vEthernet (PAhostVNic)-netwerkadapter' hebben.

Bijvoorbeeld, wordt ervan uitgegaan dat Hyper-V-hosts 1 en 2 HNV-Provider (PA) IP-adressen 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 ping tussen de twee met de volgende opdracht om te controleren van de verbinding met het logische netwerk HNV-Provider.

# 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

Herstel

Als ping van HNV-provider niet werkt, controleert u de fysieke netwerkconnectiviteit, inclusief de VLAN-configuratie. De fysieke netwerkadapters op elke Hyper-V-host moet in de trunkmodus waarbij geen specifieke VLAN toegewezen. De Management Host vNIC moet geïsoleerd voor het beheer van logische netwerk van VLAN.

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

Controleer de ondersteuning voor MTU- en jumboframes in het logische netwerk van de HNV-provider

Een ander veelvoorkomend probleem in het logische HNV Provider-netwerk is dat de fysieke netwerkpoorten en/of Ethernet-kaart geen groot genoeg MTU hebben geconfigureerd voor het afhandelen van de overhead van VXLAN (of NVGRE) inkapseling.

Notitie

Sommige Ethernet-kaarten en -stuurprogramma's ondersteunen het nieuwe *EncapOverhead trefwoord dat automatisch door de netwerkcontrollerhostagent wordt ingesteld op een waarde van 160. Deze waarde wordt vervolgens toegevoegd aan de waarde van het trefwoord *JumboPacket waarvan de som wordt gebruikt als de aangekondigde 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

Gebruik de Test-LogicalNetworkSupportsJumboPacket cmdlet om te testen of het logische HNV Provider-netwerk ondersteuning biedt voor de grotere MTU-grootte:

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

Herstel

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

Controleer de NIC-connectiviteit van tenant-VM's

Elke VM-NIC toegewezen aan een gast-VM heeft een CA-PA-toewijzing tussen de persoonlijke klantadres (CA) en de HNV Provideradres (PA) ruimte. Deze toewijzingen worden bewaard in de tabellen OVSDB server op elke Hyper-V-host en vindt u de volgende cmdlet wordt uitgevoerd.

# 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

Notitie

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

Met deze informatie kan een tenant-VM-ping nu 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.

Er is geen netwerkverbinding tussen de twee virtuele machines van tenants

  1. [Tenant] Zorg ervoor dat het verkeer niet door Windows Firewall in virtuele machines van tenants wordt geblokkeerd.
  2. [Tenant] Controleer of IP-adressen zijn toegewezen aan de virtuele tenantmachine door deze uit te voeren ipconfig.
  3. [Hoster] Voer Test-VirtualNetworkConnection van de Hyper-V-host verbinding tussen de twee virtuele tenantmachines in het geding valideren.

Notitie

De VSID verwijst naar de virtuele Subnet-ID. 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)

Maak CA-ping 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 in het virtuele subnet of VM-netwerkinterfaces die verkeer zouden blokkeren.

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

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

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

  1. [Hoster] Voer Get-ProviderAddress op beide Hyper-V hosts die als host fungeert de twee virtuele machines in vraag tenant en voer vervolgens Test-LogicalNetworkConnection of ping -c <compartment> van de Hyper-V-host te valideren in het logische netwerk van HNV-Provider
  2. [Hoster] Zorg ervoor dat de MTU-instellingen correct op de Hyper-V-hosts zijn en een Layer 2 overschakelen apparaten Between Hyper-V-Hosts. Voer Test-EncapOverheadValue op alle Hyper-V-hosts in het geding. Controleer ook of alle Layer 2-switches in tussen MTU ingesteld op minimaal 1674 bytes ter compensatie van maximale overhead van 160 bytes hebben.
  3. [Hoster] Als PA IP-adressen niet aanwezig is zijn en/of CA-verbinding verbroken is, controleert u netwerkbeleid is ontvangen. Voer Get-PACAMapping om te zien als de inkapseling regels en CA-PA-toewijzingen die zijn vereist voor het maken van virtuele overlaynetwerken correct is gemaakt.
  4. [Hoster] Controleer dat de Agent Controller Host is verbonden met de netwerkcontroller. U kunt dit doen netstat -anp tcp |findstr 6640.
  5. [Hoster] Controleer of de Host-ID in HKLM / komt overeen met de exemplaar-ID van de bronnen van de server die als host fungeert voor de virtuele machines van tenants.
  6. [Hoster] Controleer of de poort profiel-ID overeenkomt met de exemplaar-ID van de VM-netwerkinterfaces van de virtuele machines van tenants.

Logboekregistratie, tracering en geavanceerde diagnostische gegevens

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

Netwerkcontroller gecentraliseerde logboekregistratie

De netwerkcontroller automatisch foutopsporingsprogramma logboeken te verzamelen en deze opslaan op een centrale locatie. Logboekverzameling kan worden ingeschakeld wanneer u de netwerkcontroller voor het eerst of op elk gewenst moment later implementeert. De logboeken worden verzameld van de netwerkcontroller, en elementen die worden beheerd door netwerkcontroller netwerk: computers, software netwerktaakverdelers (SLB) en gateway-machines te hosten.

Deze logboeken omvatten foutopsporingslogboeken voor het netwerkcontrollercluster, de netwerkcontrollertoepassing, gatewaylogboeken, SLB, virtuele netwerken en de gedistribueerde firewall. Telkens wanneer een nieuwe host/SLB/gateway wordt toegevoegd aan de netwerkcontroller, wordt logboekregistratie gestart op deze computers. Op dezelfde manier als een host/SLB/gateway van de netwerkcontroller is verwijderd, wordt logboekregistratie gestopt op deze computers.

Logboekregistratie inschakelen

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

De netwerkcontroller cluster logboeken worden opgeslagen op %programData%\Windows Fabric\log\Traces. U kunt een gecentraliseerde locatie opgeven voor logboekverzameling met de DiagnosticLogLocation parameter met de aanbeveling dat dit ook een externe bestandsshare is.

Als u beperken van toegang tot deze locatie wilt, kunt u opgeven met de referenties voor toegang met de LogLocationCredential parameter. Als u de referenties voor toegang tot de locatie van het logboekbestand opgeeft, moet u ook opgeven de CredentialEncryptionCertificate parameter, die wordt gebruikt om de lokaal opgeslagen op de knooppunten netwerkcontroller referenties te versleutelen.

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.

Logboekinstellingen wijzigen

Kunt u instellingen voor logboekregistratie op elk moment met behulp van de Set-NetworkControllerDiagnostic cmdlet. De volgende instellingen kunnen worden gewijzigd:

  • Gecentraliseerde logboeklocatie.

    Kunt u de locatie voor het opslaan van de logboeken met de DiagnosticLogLocation parameter.

  • Referenties voor toegang tot logboeklocatie.

    Kunt u de referenties voor toegang tot de locatie van het logboek met de LogLocationCredential parameter.

  • Naar lokale logboekregistratie gaan.

    Als u hebt opgegeven centrale locatie voor het opslaan van Logboeken, kunt u terug verplaatsen naar lokaal aanmelden netwerkcontroller knooppunten met de UseLocalLogLocation parameter (niet aanbevolen vanwege de grote schijfruimtevereisten).

  • Bereik voor logboekregistratie.

    Standaard worden alle logboeken worden verzameld. U kunt het bereik voor het verzamelen van Logboeken van de cluster alleen netwerkcontroller wijzigen.

  • Niveau van logboekregistratie.

    Het standaard logboekregistratieniveau is een informatief bericht. U kunt deze fout, waarschuwing of uitgebreid wijzigen.

  • Logboekverouderingstijd.

    De logboeken worden opgeslagen in een circulaire gestart. 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 een maximale 75 GB aan gegevens van de logboekregistratie als gecentraliseerde logboekregistratie en 25 GB gebruikt als het gebruik van de lokale logboekregistratie. Kunt u deze limiet met de LogSizeLimitInMBs parameter.

Logboeken en traceringen verzamelen

VMM-implementaties gebruiken standaard centrale logboekregistratie voor de netwerkcontroller. De bestandslocatie voor de share voor deze logboeken is opgegeven bij het implementeren van de servicesjabloon 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 de volgende hiërarchie:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Traceringen

De netwerkcontroller gebruikt (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-fabricfouten (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 Host Agents. Voer DumpSlbRestState op elk knooppunt met toegang tot de REST van de netwerkeindpunt Controller.
  2. Valideer de SDNSLBMPerfCounters in PerfMon op een van de netwerkcontrollerknooppunt-VM's (bij voorkeur het primaire netwerkcontrollerknooppunt - Get-NetworkControllerReplica):
    1. Load Balancer (LB)-engine met is verbonden SLBM? (SLBM LBEngine-configuraties totaal > 0)
    2. SLBM ten minste kent een eigen eindpunten? (TOTAAL VAN VIP-eindpunten>= 2)
    3. Hyper-V (DIP) hosts met zijn verbonden SLBM? (HP-clients die zijn verbonden == num servers)
    4. Is SLBM verbonden met Muxes? (Muxes Connected == Muxes Healthy op SLBM == Muxes reporting healthy = # SLB Muxes VM's).
  3. Zorg ervoor dat de geconfigureerde BGP-router peering heeft 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 weergeven voor de self-VIP van SLBM.
    2. Als u een fysieke ToR-switch (Top-of-Rack) gebruikt als BGP-peer, raadpleegt u de volgende 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-adresgroepen en zorg ervoor dat SLBM self-VIP (LoadBalanacerManagerIPAddress) en alle 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 controles hierboven mislukken, worden de tenant SLB staat ook in een modus fout.

Herstel

Op basis van de volgende diagnostische informatie weergegeven, herstel het volgende:

  • Zorg ervoor dat SLB Multiplexers zijn verbonden
    • Certificaatproblemen corrigeren
    • Los problemen met de netwerkverbinding
  • Zorg ervoor dat BGP peering informatie correct is geconfigureerd
  • Zorg ervoor dat Host-ID in het register komt overeen met de Server-exemplaar-ID in Serverresource (verwijzen naar bijlage voor HostNotConnected foutcode)
  • Logboeken verzamelen

SLBM-tenantfouten (hostingserviceprovider en tenantacties)

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

    1. Cheque Debug-NetworkControllerConfigurationState

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

    2. Check HostIdin nchostagent service regkey (referentiefoutcode HostNotConnected in de bijlage) komt overeen met de bijbehorende exemplaar-id (Get-NCServer |convertto-json -depth 8) van de serverresource.

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

  4. [Hostingprovider] Logboeken verzamelen.

SLB Mux-tracering

Informatie van de Software Load Balancer Muxes kan ook worden bepaald door de Event Viewer.

  1. Selecteer Analyse- en foutopsporingslogboeken weergeven in het menu Logboeken Weergave.
  2. Navigeer in Logboeken naar Toepassingen en Services-logboeken van>Microsoft>Windows>SlbMuxDriver>Trace.
  3. Klik er met de rechtermuisknop op en selecteer Logboek inschakelen.

Notitie

Het wordt aanbevolen om deze logboekregistratie slechts een korte tijd in te schakelen 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-trace verzamelen om te bepalen waar problemen kunnen liggen.

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