Problembehandlung für den softwaredefinierte Windows Server-Netzwerkstapel

  • Artikel

In diesem Leitfaden werden die allgemeinen SDN-Fehler und -Fehlerszenarien (Software Defined Networking) untersucht und ein Problembehandlungsworkflow beschrieben, der die verfügbaren Diagnosetools verwendet. Weitere Informationen zu SDN finden Sie unter Software Defined Networking.

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, Versionen 21H2 und 20H2

Fehlertypen

Die folgende Liste stellt die Klasse von Problemen dar, die am häufigsten bei der Hyper-V-Netzwerkvirtualisierung (HNVv1) in Windows Server 2012 R2 aus in-market-Produktionsbereitstellungen auftreten und in vielerlei Hinsicht mit den gleichen Arten von Problemen übereinstimmen, die in Windows Server 2016 HNVv2 mit dem neuen Software Defined Network (SDN)-Stapel (Software Defined Network) auftreten.

Die meisten Fehler können in eine kleine Gruppe von Klassen klassifiziert werden:

  • Ungültige oder nicht unterstützte Konfiguration

    Ein Benutzer ruft die NorthBound-API falsch oder mit einer ungültigen Richtlinie auf.

  • Fehler in der Richtlinienanwendung

    Die Richtlinie vom Netzwerkcontroller wurde nicht an einen Hyper-V-Host übermittelt, verzögert oder auf allen Hyper-V-Hosts nicht aktuell (z. B. nach einer Livemigration).

  • Konfigurationsdrift oder Softwarefehler

    Datenpfadprobleme, die zu verworfenen Paketen führen.

  • Externer Fehler im Zusammenhang mit NIC-Hardware/-Treibern oder dem zugrunde liegenden Netzwerkfabric

    Fehlverhalten bei Aufgabenauslagerungen (z. B. VMQ) oder falsch konfiguriertem Netzwerkfabric (z. B. MTU)

    Dieser Leitfaden zur Problembehandlung untersucht jede dieser Fehlerkategorien und empfiehlt bewährte Methoden und Diagnosetools, die zum Identifizieren und Beheben des Fehlers verfügbar sind.

Diagnosetools

Bevor wir die Problembehandlungsworkflows für jeden dieser Fehlertypen besprechen, sehen wir uns die verfügbaren Diagnosetools an.

Um die Diagnosetools des Netzwerkcontrollers (Steuerungspfad) verwenden zu können, müssen Sie zuerst das RSAT-NetworkController Feature installieren und das NetworkControllerDiagnostics Modul importieren:

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

Um die Diagnosetools für die HNV-Diagnose (Datenpfad) verwenden zu können, müssen Sie das HNVDiagnostics Modul importieren:

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

Netzwerkcontroller Diagnose

Diese Cmdlets sind auf TechNet im Cmdlet Netzwerkcontrollerdiagnose dokumentiert. Sie helfen dabei, Probleme mit der Netzwerkrichtlinienkonsistenz im Kontrollpfad zwischen Netzwerkcontrollerknoten und zwischen dem Netzwerkcontroller und den NC-Host-Agents zu identifizieren, die auf den Hyper-V-Hosts ausgeführt werden.

Die Debug-ServiceFabricNodeStatus Cmdlets und Get-NetworkControllerReplica müssen auf einem der virtuellen Computer des Netzwerkcontrollerknotens ausgeführt werden. Alle anderen NC-Diagnose-Cmdlets können von jedem Host ausgeführt werden, der über Eine Verbindung mit dem Netzwerkcontroller verfügt und sich entweder in der Sicherheitsgruppe Netzwerkcontrollerverwaltung (Kerberos) befindet oder zugriff auf das X.509-Zertifikat zum Verwalten des Netzwerkcontrollers hat.

Hyper-V-Host Diagnose

Diese Cmdlets sind auf TechNet im Cmdlet Hyper-V-Netzwerkvirtualisierung (HNV) Diagnostics dokumentiert. Sie helfen dabei, Probleme im Datenpfad zwischen virtuellen Mandantencomputern (Ost/West) und eingehendem Datenverkehr über eine SLB-VIP (Nord/Süd) zu identifizieren.

Die Debug-VirtualMachineQueueOperationTests , , Get-CustomerRouteGet-PACAMapping, Get-ProviderAddress, Get-VMSwitchExternalPortIdGet-VMNetworkAdapterPortId, und Test-EncapOverheadSettings sind alle lokalen Tests, die von jedem Hyper-V-Host ausgeführt werden können. Die anderen Cmdlets rufen Datenpfadtests über den Netzwerkcontroller auf und benötigen daher Zugriff auf den Netzwerkcontroller, wie oben beschrieben.

GitHub

Das Microsoft/SDN-GitHub-Repository enthält viele Beispielskripts und Workflows, die auf diesen vordefinierten Cmdlets aufbauen. Insbesondere Diagnoseskripts finden Sie im Ordner Diagnose . Helfen Sie uns, an diesen Skripts mitzuwirken, indem Sie Pull Requests übermitteln.

Problembehandlung bei Workflows und Leitfäden

[Hoster] Überprüfen der Systemintegrität

Es gibt eine eingebettete Ressource namens Konfigurationsstatus in mehreren netzwerkcontroller-Ressourcen. Der Konfigurationsstatus enthält Informationen zur Systemintegrität, einschließlich der Konsistenz zwischen der Konfiguration des Netzwerkcontrollers und dem tatsächlichen (ausgeführten) Zustand auf den Hyper-V-Hosts.

Um den Konfigurationsstatus zu überprüfen, führen Sie Folgendes von jedem Hyper-V-Host mit Konnektivität mit dem Netzwerkcontroller aus.

Hinweis

Der Wert für den NetworkController Parameter sollte entweder der FQDN oder die IP-Adresse sein, die auf dem Antragstellernamen des für den Netzwerkcontroller erstellten X.509-Zertifikats >basiert.

Der Credential Parameter muss nur angegeben werden, wenn der Netzwerkcontroller die Kerberos-Authentifizierung verwendet (typisch für VMM-Bereitstellungen). Die Anmeldeinformationen müssen für einen Benutzer gelten, der sich in der Sicherheitsgruppe "Netzwerkcontrollerverwaltung" befindet.

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

Unten sehen Sie eine Beispielmeldung zum Konfigurationsstatus:

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

Hinweis

Es gibt einen Fehler im System, bei dem sich die Netzwerkschnittstellenressourcen für die SLB-Mux Transit-VM-NIC im Fehlerzustand "Virtueller Switch – Host nicht mit Controller verbunden" befinden. Dieser Fehler kann ignoriert werden, wenn die IP-Konfiguration in der VM-NIC-Ressource auf eine IP-Adresse aus dem IP-Pool des logischen Transitnetzwerks festgelegt ist.

Es gibt einen zweiten Fehler im System, bei dem sich die Netzwerkschnittstellenressourcen für die Gateway-HNV-Anbieter-VM-NICs im Fehlerzustand "Virtual Switch – PortBlocked" befinden. Dieser Fehler kann auch ignoriert werden, wenn die IP-Konfiguration in der VM-NIC-Ressource (entwurfsbedingt) auf NULL festgelegt ist.

Die folgende Tabelle zeigt die Liste der Fehlercodes, Meldungen und Folgeaktionen, die basierend auf dem beobachteten Konfigurationszustand ausgeführt werden müssen.

Code Nachricht Aktion
Unbekannt Unbekannter Fehler
HostUnreachable Der Hostcomputer ist nicht erreichbar Überprüfen der Netzwerkkonnektivität der Verwaltung zwischen Netzwerkcontroller und Host
PAIpAddressExhausted Die PA-IP-Adressen sind erschöpft. Erhöhen der IP-Poolgröße des logischen Subnetzes des HNV-Anbieters
PAMacAddressExhausted Die PA-Mac-Adressen sind erschöpft Vergrößern des Mac-Poolbereichs
PAAddressConfigurationFailure Fehler beim Einfügen von PA-Adressen für den Host Überprüfen Sie die Verwaltungsnetzwerkkonnektivität zwischen Netzwerkcontroller und Host.
CertificateNotTrusted Zertifikat ist nicht vertrauenswürdig Korrigieren Sie die Zertifikate, die für die Kommunikation mit dem Host verwendet werden.
CertificateNotAuthorized Zertifikat nicht autorisiert Korrigieren Sie die Zertifikate, die für die Kommunikation mit dem Host verwendet werden.
PolicyConfigurationFailureOnVfp Fehler beim Konfigurieren von VFP-Richtlinien Dies ist ein Laufzeitfehler. Keine eindeutigen Problemumgehungen. Protokolle erfassen
PolicyConfigurationFailure Fehler beim Pushen von Richtlinien an die Hosts aufgrund von Kommunikationsfehlern oder anderen Fehlern im NetworkController. Keine eindeutigen Aktionen. Dies ist auf einen Fehler bei der Verarbeitung des Zielzustands in den Netzwerkcontrollermodulen zurückzuführen. Protokolle erfassen
HostNotConnectedToController Der Host ist noch nicht mit dem Netzwerkcontroller verbunden. Portprofil, das nicht auf dem Host oder dem Host angewendet wird, ist vom Netzwerkcontroller nicht erreichbar. Überprüfen Sie, ob der Registrierungsschlüssel HostID mit der Instanz-ID der Serverressource übereinstimmt.
MultipleVfpEnabledSwitches Auf dem Host sind mehrere VFp-fähige Switches vorhanden. Löschen Sie einen der Switches, da der Netzwerkcontrollerhost-Agent nur einen vSwitch mit aktivierter VFP-Erweiterung unterstützt.
PolicyConfigurationFailure Fehler beim Pushen von VNET-Richtlinien für eine VMNic aufgrund von Zertifikat- oder Konnektivitätsfehlern Überprüfen Sie, ob die richtigen Zertifikate bereitgestellt wurden (Name des Zertifikatantragstellers muss mit dem FQDN des Hosts übereinstimmen). Überprüfen Sie außerdem die Hostkonnektivität mit dem Netzwerkcontroller.
PolicyConfigurationFailure Fehler beim Pushen von vSwitch-Richtlinien für eine VMNic aufgrund von Zertifikat- oder Konnektivitätsfehlern Überprüfen Sie, ob die richtigen Zertifikate bereitgestellt wurden (Name des Zertifikatantragstellers muss mit dem FQDN des Hosts übereinstimmen). Überprüfen Sie außerdem die Hostkonnektivität mit dem Netzwerkcontroller.
PolicyConfigurationFailure Fehler beim Pushen von Firewallrichtlinien für eine VMNic aufgrund von Zertifikat- oder Konnektivitätsfehlern Überprüfen Sie, ob die richtigen Zertifikate bereitgestellt wurden (Name des Zertifikatantragstellers muss mit dem FQDN des Hosts übereinstimmen). Überprüfen Sie außerdem die Hostkonnektivität mit dem Netzwerkcontroller.
DistributedRouterConfigurationFailure Fehler beim Konfigurieren der Einstellungen des verteilten Routers auf der Host-vNic TCPIP-Stapelfehler. Möglicherweise ist die Bereinigung der PA- und DR-Host-VNICs auf dem Server erforderlich, auf dem dieser Fehler gemeldet wurde.
DhcpAddressAllocationFailure Fehler bei der DHCP-Adresszuordnung für eine VMNic Überprüfen Sie, ob das Attribut für die statische IP-Adresse für die NIC-Ressource konfiguriert ist.
CertificateNotTrusted
CertificateNotAuthorized		 Fehler beim Herstellen einer Verbindung mit Mux aufgrund von Netzwerk- oder Zertifikatfehlern Überprüfen Sie den numerischen Code, der im Fehlermeldungscode angegeben ist: Dies entspricht dem Winsock-Fehlercode. Zertifikatfehler sind präzise (z. B. Zertifikat kann nicht überprüft werden, Zertifikat nicht autorisiert usw.)
HostUnreachable MUX ist fehlerhaft (häufig ist BGPRouter getrennt) Der BGP-Peer auf dem RRAS-Switch (BGP-VM) oder top-of-Rack (ToR) ist nicht erreichbar oder das Peering nicht erfolgreich. Überprüfen Sie die BGP-Einstellungen sowohl für die Software- Load Balancer Multiplexer-Ressource als auch für den BGP-Peer (ToR- oder RRAS-VM)
HostNotConnectedToController Der SLB-Host-Agent ist nicht verbunden Überprüfen Sie, ob der SLB-Host-Agent-Dienst ausgeführt wird. Weitere Informationen finden Sie in den Protokollen des SLB-Host-Agents (automatisch ausgeführt), warum für den Fall, dass SLBM (NC) das vom Ausführungsstatus des Host-Agents dargestellte Zertifikat abgelehnt hat, nuancierte Informationen enthält.
PortBlocked Der VFP-Port ist aufgrund fehlender VNET-/ACL-Richtlinien blockiert. Überprüfen Sie, ob andere Fehler vorliegen, die dazu führen können, dass die Richtlinien nicht konfiguriert werden.
Überladene LoadBalancer MUX ist überladen Leistungsproblem mit MUX
RoutePublicationFailure LoadBalancer MUX ist nicht mit einem BGP-Router verbunden Überprüfen Sie, ob der MUX mit den BGP-Routern verbunden ist und ob das BGP-Peering ordnungsgemäß eingerichtet ist.
VirtualServerUnreachable LoadBalancer MUX ist nicht mit dem SLB-Manager verbunden Überprüfen der Konnektivität zwischen SLBM und MUX
QosConfigurationFailure Fehler beim Konfigurieren von QOS-Richtlinien Überprüfen Sie, ob ausreichend Bandbreite für alle virtuellen Computer verfügbar ist, wenn QOS-Reservierung verwendet wird.

Überprüfen der Netzwerkkonnektivität zwischen dem Netzwerkcontroller und dem Hyper-V-Host (NC-Host-Agent-Dienst)

Führen Sie den netstat folgenden Befehl aus, um zu überprüfen, ob drei ESTABLISHED Verbindungen zwischen dem NC-Host-Agent und den Netzwerkcontrollerknoten und einem LISTENING Socket auf dem Hyper-V-Host bestehen.

  • LISTENING on port TCP:6640 on Hyper-V Host (NC Host Agent Service)
  • Zwei hergestellte Verbindungen von der Hyper-V-Host-IP an Port 6640 zur NC-Knoten-IP an kurzlebigen Ports (> 32000)
  • Eine hergestellte Verbindung von der Hyper-V-Host-IP am kurzlebigen Port zur Netzwerkcontroller-REST-IP an Port 6640

Hinweis

Es können nur zwei Verbindungen auf einem Hyper-V-Host hergestellt werden, wenn keine virtuellen Mandantencomputer auf diesem bestimmten Host bereitgestellt werden.

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

Überprüfen der Host-Agent-Dienste

Der Netzwerkcontroller kommuniziert mit zwei Host-Agent-Diensten auf den Hyper-V-Hosts: SLB-Host-Agent und NC-Host-Agent. Es ist möglich, dass ein oder beide dieser Dienste nicht ausgeführt werden. Überprüfen Sie ihren Zustand, und starten Sie sie neu, wenn sie nicht ausgeführt werden.

Get-Service SlbHostAgent
Get-Service NcHostAgent

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

Überprüfen der Integrität des Netzwerkcontrollers

Wenn nicht drei ESTABLISHED Verbindungen vorhanden sind oder der Netzwerkcontroller nicht reagiert, überprüfen Sie mithilfe der folgenden Cmdlets, ob alle Knoten und Dienstmodule aktiv sind und ausgeführt werden.

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

Die Netzwerkcontroller-Dienstmodule sind:

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

Überprüfen Sie, ob ReplicaStatusReady und HealthState ist Ok.

In einer Produktionsbereitstellung mit einem Netzwerkcontroller mit mehreren Knoten können Sie auch überprüfen, auf welchem Knoten sich jeder Dienst primär befindet und auf welchem einzelnen Replikat status.

Get-NetworkControllerReplica

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

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

Überprüfen Sie, ob der Replikatstatus für jeden Dienst bereit ist.

Überprüfen auf entsprechende HostIDs und Zertifikate zwischen Netzwerkcontroller und jedem Hyper-V-Host

Führen Sie auf einem Hyper-V-Host die folgenden Cmdlets aus, um zu überprüfen, ob die HostID der Instanz-ID einer Serverressource auf dem Netzwerkcontroller entspricht.

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

Sanierung

Wenn Sie SDNExpress-Skripts oder eine manuelle Bereitstellung verwenden, aktualisieren Sie den HostId-Schlüssel in der Registrierung so, dass er mit der Instanz-ID der Serverressource übereinstimmt. Starten Sie den Netzwerkcontrollerhost-Agent auf dem Hyper-V-Host (physischer Server) neu, wenn Sie VMM verwenden, löschen Sie den Hyper-V-Server aus VMM, und entfernen Sie den Registrierungsschlüssel HostId. Fügen Sie dann den Server erneut über VMM hinzu.

Überprüfen Sie, ob die Fingerabdrücke der X.509-Zertifikate, die vom Hyper-V-Host verwendet werden (der Hostname ist der Antragstellername des Zertifikats) für die Kommunikation zwischen dem Hyper-V-Host (NC-Host-Agent-Dienst) und den Netzwerkcontrollerknoten identisch sind. Überprüfen Sie außerdem, ob das REST-Zertifikat des Netzwerkcontrollers den Antragstellernamen aufweist 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**
...

Sie können auch die folgenden Parameter jedes Zertifikats überprüfen, um sicherzustellen, dass der Antragstellername dem erwarteten Namen entspricht (Hostname oder NC-REST-FQDN oder IP), dass das Zertifikat noch nicht abgelaufen ist und dass alle Zertifizierungsstellen in der Zertifikatkette in der vertrauenswürdigen Stammzertifizierungsstelle enthalten sind.

  • Antragstellername
  • Ablaufdatum
  • Vertrauenswürdig durch Stammzertifizierungsstelle

Wenn mehrere Zertifikate denselben Antragstellernamen auf dem Hyper-V-Host haben, wählt der Netzwerkcontrollerhost-Agent nach dem Zufallsprinzip ein Zertifikat aus, das dem Netzwerkcontroller präsentiert werden soll. Dies entspricht möglicherweise nicht dem Fingerabdruck der Serverressource, die dem Netzwerkcontroller bekannt ist. Löschen Sie in diesem Fall eines der Zertifikate mit demselben Antragstellernamen auf dem Hyper-V-Host, und starten Sie dann den Netzwerkcontroller-Host-Agent-Dienst neu. Wenn immer noch keine Verbindung hergestellt werden kann, löschen Sie das andere Zertifikat mit demselben Antragstellernamen auf dem Hyper-V-Host, und löschen Sie die entsprechende Serverressource in VMM. Erstellen Sie dann die Serverressource in VMM neu, wodurch ein neues X.509-Zertifikat generiert und auf dem Hyper-V-Host installiert wird.

Überprüfen des SLB-Konfigurationsstatus

Der SLB-Konfigurationsstatus kann als Teil der Ausgabe an das Debug-NetworkController Cmdlet bestimmt werden. Dieses Cmdlet gibt auch den aktuellen Satz von Netzwerkcontrollerressourcen in JSON-Dateien, alle IP-Konfigurationen von jedem Hyper-V-Host (Server) und die lokale Netzwerkrichtlinie aus Host-Agent-Datenbanktabellen aus.

Standardmäßig werden weitere Ablaufverfolgungen erfasst. Um keine Ablaufverfolgungen zu sammeln, fügen Sie den -IncludeTraces:$false Parameter hinzu.

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

Hinweis

Der Standardausgabespeicherort ist das <Verzeichnis working_directory>\NCDiagnostics\. Das Standardausgabeverzeichnis kann mithilfe des -OutputDirectory Parameters geändert werden.

Die Informationen zum SLB-Konfigurationsstatus finden Sie in der Datei Diagnose-slbstateResults.Json in diesem Verzeichnis.

Diese JSON-Datei kann in die folgenden Abschnitte unterteilt werden:

  • Stoff
    • SlbmVips: In diesem Abschnitt wird die IP-Adresse der SLB-Manager-VIP-Adresse aufgeführt, die vom Netzwerkcontroller verwendet wird, um die Konfiguration und Integrität zwischen den SLB-Muxes und den SLB-Host-Agents zu koordinieren.
    • MuxState: In diesem Abschnitt wird ein Wert für jeden bereitgestellten SLB-Mux aufgelistet, der den Status des Mux angibt.
    • Routerkonfiguration: In diesem Abschnitt werden die autonome Systemnummer (ASN), die Transit-IP-Adresse und die ID des Upstreamrouters (BGP-Peer) aufgelistet. Außerdem werden die SLB-Muxes-ASN und die Transit-IP-Adresse aufgelistet.
    • Informationen zum verbundenen Host: In diesem Abschnitt werden die Verwaltungs-IP-Adressen aller Hyper-V-Hosts aufgelistet, die für die Ausführung von Workloads mit Lastenausgleich verfügbar sind.
    • VIP-Bereiche: In diesem Abschnitt werden die Bereiche des öffentlichen und privaten VIP-IP-Pools aufgelistet. Die SLBM-VIP wird als zugeordnete IP-Adresse aus einem dieser Bereiche eingeschlossen.
    • Mux-Routen: In diesem Abschnitt wird ein Wert für jeden bereitgestellten SLB-Mux aufgelistet, der alle Routenanzeigen für diesen bestimmten Mux enthält.
  • Mandant
    • VipConsolidatedState: In diesem Abschnitt wird der Konnektivitätsstatus für jede Mandanten-VIP aufgelistet, einschließlich angekündigtem Routenpräfix, Hyper-V-Host und DIP-Endpunkten.

Hinweis

Der SLB-Status kann direkt mithilfe des DumpSlbRestState-Skripts ermittelt werden, das im Microsoft SDN-GitHub-Repository verfügbar ist.

Gatewayüberprüfung

Vom Netzwerkcontroller:

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

Von gateway-VM:

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

Von der Oberseite des Racks (ToR)-Switch:

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

Windows BGP-Router:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Darüber hinaus scheint der häufigste Grund dafür zu sein, dass das Mandantendepot auf virtuellen GW-Computern aufgrund der bisher aufgetretenen Probleme (insbesondere bei SDNExpress-basierten Bereitstellungen) nicht konfiguriert wird, die Tatsache zu sein, dass die GW-Kapazität in FabricConfig.psd1 geringer ist als das, was die Benutzer dem Netzwerk-Connections (S2S Tunnels) in TenantConfig.psd1 zuweisen möchten. Dies kann einfach überprüft werden, indem die Ausgaben der folgenden Cmdlets verglichen werden:

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] Überprüfen von Data-Plane

Nachdem der Netzwerkcontroller bereitgestellt, virtuelle Mandantennetzwerke und Subnetze erstellt und VMs an die virtuellen Subnetze angefügt wurden, können zusätzliche Tests auf Fabricebene vom Hoster ausgeführt werden, um die Mandantenkonnektivität zu überprüfen.

Überprüfen der logischen Netzwerkkonnektivität des HNV-Anbieters

Nachdem die erste Gast-VM, die auf einem Hyper-V-Host ausgeführt wird, mit einem virtuellen Mandantennetzwerk verbunden wurde, weist der Netzwerkcontroller dem Hyper-V-Host zwei HNV-Anbieter-IP-Adressen (PA-IP-Adressen) zu. Diese IP-Adressen stammen aus dem IP-Pool des logischen HNV-Anbieters und werden vom Netzwerkcontroller verwaltet. So finden Sie heraus, was diese beiden HNV-IP-Adressen sind:

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

Diese IP-Adressen des HNV-Anbieters (PA IPs) werden Ethernet-Adaptern zugewiesen, die in einem separaten TCPIP-Netzwerkfach erstellt wurden, und haben den Adapternamen VLANX , wobei X das VLAN ist, das dem logischen Netzwerk des HNV-Anbieters (Transportnetzwerks) zugewiesen ist.

Die Konnektivität zwischen zwei Hyper-V-Hosts, die das logische Netzwerk des HNV-Anbieters verwenden, kann durch einen Ping mit einem zusätzlichen Depotparameter (-c Y) hergestellt werden, wobei Y das TCPIP-Netzwerkfach ist, in dem die PAhostVNICs erstellt werden. Dieses Depot kann bestimmt werden, indem Folgendes ausgeführt wird:

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

Hinweis

Die PA-Host-vNIC-Adapter werden nicht im Datenpfad verwendet und verfügen daher nicht über eine IP-Adresse, die dem "vEthernet (PAhostVNic)-Adapter" zugewiesen ist.

Gehen Sie für instance davon aus, dass die Hyper-V-Hosts 1 und 2 über die IP-Adressen des HNV-Anbieters (PA) verfügen:

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

Mit dem folgenden Befehl können sie zwischen den beiden Pings pingen, um die logische Netzwerkkonnektivität des HNV-Anbieters zu überprüfen.

# 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

Sanierung

Wenn der Ping des HNV-Anbieters nicht funktioniert, überprüfen Sie ihre physische Netzwerkkonnektivität einschließlich DER VLAN-Konfiguration. Die physischen NICs auf jedem Hyper-V-Host sollten sich im Trunkmodus befinden, ohne dass ein bestimmtes VLAN zugewiesen ist. Die vNIC des Verwaltungshosts sollte mit dem VLAN des logischen Verwaltungsnetzwerks isoliert werden.

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

Überprüfen der MTU- und Jumboframeunterstützung im logischen HNV-Anbieternetzwerk

Ein weiteres häufiges Problem im logischen Netzwerk des HNV-Anbieters besteht darin, dass für die physischen Netzwerkports und/oder Ethernet-Karte nicht genügend MTU konfiguriert ist, um den Mehraufwand durch die VXLAN-Kapselung (oder NVGRE) zu bewältigen.

Hinweis

Einige Ethernet-Karten und -Treiber unterstützen die neue *EncapOverhead Schlüsselwort (keyword) die automatisch vom Netzwerkcontrollerhost-Agent auf den Wert 160 festgelegt wird. Dieser Wert wird dann dem Wert des *JumboPacket-Schlüsselwort (keyword) hinzugefügt, dessen Summe als angekündigte MTU verwendet wird.

Beispiel *EncapOverhead : = 160 und *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

Verwenden Sie das Cmdlet, um zu testen, ob das logische Netzwerk des HNV-Anbieters Test-LogicalNetworkSupportsJumboPacket end-to-End die größere MTU-Größe unterstützt:

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

Sanierung

  • Passen Sie die MTU-Größe an den physischen Switchports auf mindestens 1674B an (einschließlich 14B Ethernet-Header und -Trailer).
  • Wenn Ihr NIC-Karte die EncapOverhead-Schlüsselwort (keyword) nicht unterstützt, passen Sie den JumboPacket-Schlüsselwort (keyword) auf mindestens 1674 B an.

Überprüfen der NIC-Konnektivität des virtuellen Mandantencomputers

Jede VM-NIC, die einer Gast-VM zugewiesen ist, weist eine CA-PA-Zuordnung zwischen der privaten Kundenadresse (CA) und dem HNV-Anbieteradressenbereich (PA) auf. Diese Zuordnungen werden in den OVSDB-Servertabellen auf jedem Hyper-V-Host gespeichert und können durch Ausführen des folgenden Cmdlets gefunden werden.

# 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

Hinweis

Wenn die erwarteten CA-PA-Zuordnungen für eine bestimmte Mandanten-VM nicht ausgegeben werden, überprüfen Sie die NIC- und IP-Konfigurationsressourcen des virtuellen Computers auf dem Netzwerkcontroller mithilfe des Get-NetworkControllerNetworkInterface Cmdlets. Überprüfen Sie außerdem die hergestellten Verbindungen zwischen dem NC-Host-Agent und den Netzwerkcontrollerknoten.

Mit diesen Informationen kann nun ein Ping für eine Mandanten-VM vom Hoster über den Netzwerkcontroller mithilfe des Test-VirtualNetworkConnection Cmdlets initiiert werden.

Spezifische Problembehandlungsszenarien

Die folgenden Abschnitte enthalten Anleitungen für die Problembehandlung bestimmter Szenarien.

Keine Netzwerkkonnektivität zwischen zwei virtuellen Mandantencomputern

  1. [Mandant] Stellen Sie sicher, dass die Windows-Firewall auf virtuellen Mandantencomputern den Datenverkehr nicht blockiert.
  2. [Mandant] Überprüfen Sie, ob dem virtuellen Mandantencomputer IP-Adressen zugewiesen wurden, indem Sie ausführen ipconfig.
  3. [Hoster] Führen Sie Test-VirtualNetworkConnection vom Hyper-V-Host aus, um die Konnektivität zwischen den beiden betreffenden virtuellen Mandantencomputern zu überprüfen.

Hinweis

Die VSID bezieht sich auf die ID des virtuellen Subnetzes. Im Fall von VXLAN ist dies der VXLAN-Netzwerkbezeichner (VNI). Sie finden diesen Wert, indem Sie das Get-PACAMapping Cmdlet ausführen.

Beispiel

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

Erstellen Sie ca-ping zwischen "Green Web VM 1" mit SenderCA-IP von 192.168.1.4 auf Host "sa18n30-2.sa18.nttest.microsoft.com" mit der Mgmt-IP von 10.127.132.153 zur ListenerCA-IP von 192.168.1.5, die beide an das virtuelle Subnetz (VSID) 4114 angefügt ist.

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

[Mandant] Vergewissern Sie sich, dass für das virtuelle Subnetz oder die VM-Netzwerkschnittstellen keine verteilten Firewallrichtlinien angegeben sind, die den Datenverkehr blockieren würden.

Fragen Sie die Netzwerkcontroller-REST-API in der Demoumgebung unter sa18n30nc in der domäne sa18.nttest.microsoft.com ab.

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

Sehen Sie sich die IP-Konfiguration und die virtuellen Subnetze an, die auf diese ACL verweisen.

  1. [Hoster] Führen Sie Get-ProviderAddress auf beiden Hyper-V-Hosts aus, die die beiden betreffenden virtuellen Mandantencomputer hosten, und führen Sie Test-LogicalNetworkConnection dann oder ping -c <compartment> vom Hyper-V-Host aus, um die Konnektivität im logischen Netzwerk des HNV-Anbieters zu überprüfen.
  2. [Hoster] Stellen Sie sicher, dass die MTU-Einstellungen auf den Hyper-V-Hosts und allen Layer-2-Switching-Geräten zwischen den Hyper-V-Hosts korrekt sind. Führen Sie auf allen betreffenden Hyper-V-Hosts aus Test-EncapOverheadValue . Überprüfen Sie außerdem, ob die MTU für alle Layer-2-Switches dazwischen auf mindestens 1674 Bytes festgelegt ist, um den maximalen Mehraufwand von 160 Bytes zu berücksichtigen.
  3. [Hoster] Wenn KEINE PA-IP-Adressen vorhanden sind und/oder die ZS-Konnektivität unterbrochen ist, überprüfen Sie, ob die Netzwerkrichtlinie empfangen wurde. Führen Sie aus Get-PACAMapping , um zu überprüfen, ob die Kapselungsregeln und CA-PA-Zuordnungen, die zum Erstellen von virtuellen Overlaynetzwerken erforderlich sind, ordnungsgemäß eingerichtet sind.
  4. [Hoster] Überprüfen Sie, ob der Host-Agent des Netzwerkcontrollers mit dem Netzwerkcontroller verbunden ist. Führen Sie dazu aus netstat -anp tcp |findstr 6640.
  5. [Hoster] Überprüfen Sie, ob die Host-ID in HKLM/ mit der Instanz-ID der Serverressourcen übereinstimmt, die die virtuellen Mandantencomputer hosten.
  6. [Hoster] Überprüfen Sie, ob die Portprofil-ID mit der Instanz-ID der VM-Netzwerkschnittstellen der virtuellen Mandantencomputer übereinstimmt.

Protokollierung, Ablaufverfolgung und erweiterte Diagnose

Die folgenden Abschnitte enthalten Informationen zu erweiterten Diagnose, Protokollierung und Ablaufverfolgung.

Zentrale Protokollierung des Netzwerkcontrollers

Der Netzwerkcontroller kann Debuggerprotokolle automatisch erfassen und an einem zentralen Ort speichern. Die Protokollsammlung kann aktiviert werden, wenn Sie den Netzwerkcontroller zum ersten Mal oder zu einem späteren Zeitpunkt bereitstellen. Die Protokolle werden vom Netzwerkcontroller und vom Netzwerkcontroller verwalteten Netzwerkelementen erfasst: Hostcomputer, Software Load Balancer (SLB) und Gatewaycomputer.

Diese Protokolle umfassen Debugprotokolle für den Netzwerkcontrollercluster, die Netzwerkcontrolleranwendung, Gatewayprotokolle, SLB, virtuelle Netzwerke und die verteilte Firewall. Wenn dem Netzwerkcontroller ein neuer Host/SLB/ein neues Gateway hinzugefügt wird, wird die Protokollierung auf diesen Computern gestartet. Ebenso wird die Protokollierung auf diesen Computern beendet, wenn ein Host/SLB/Gateway aus dem Netzwerkcontroller entfernt wird.

Aktivieren der Protokollierung

Die Protokollierung wird automatisch aktiviert, wenn Sie den Netzwerkcontrollercluster mithilfe des Install-NetworkControllerCluster Cmdlets installieren. Standardmäßig werden die Protokolle lokal auf den Netzwerkcontrollerknoten unter %systemdrive%\SDNDiagnostics gesammelt. Es wird empfohlen, diesen Speicherort in eine Remotedateifreigabe (nicht lokal) zu ändern.

Die Protokolle des Netzwerkcontrollerclusters werden unter %programData%\Windows Fabric\log\Traces gespeichert. Sie können einen zentralen Speicherort für die Protokollsammlung mit dem -Parameter mit der DiagnosticLogLocation Empfehlung angeben, dass es sich auch um eine Remotedateifreigabe handelt.

Wenn Sie den Zugriff auf diesen Speicherort einschränken möchten, können Sie die Anmeldeinformationen für den Zugriff mit dem LogLocationCredential Parameter angeben. Wenn Sie die Anmeldeinformationen für den Zugriff auf den Protokollspeicherort angeben, sollten Sie auch den CredentialEncryptionCertificate Parameter angeben, der zum Verschlüsseln der lokal auf den Netzwerkcontrollerknoten gespeicherten Anmeldeinformationen verwendet wird.

Bei den Standardeinstellungen wird empfohlen, dass Sie mindestens 75 GB freien Speicherplatz am zentralen Standort und 25 GB auf den lokalen Knoten (wenn sie keinen zentralen Standort verwenden) für einen Netzwerkcontrollercluster mit drei Knoten haben.

Ändern der Protokollierungseinstellungen

Sie können die Protokollierungseinstellungen jederzeit mithilfe des Cmdlets Set-NetworkControllerDiagnostic ändern. Die folgenden Einstellungen können geändert werden:

  • Zentralisierter Protokollspeicherort.

    Sie können den Speicherort ändern, um alle Protokolle mit dem DiagnosticLogLocation -Parameter zu speichern.

  • Anmeldeinformationen für den Zugriff auf den Protokollspeicherort.

    Sie können die Anmeldeinformationen ändern, um mit dem Parameter auf den LogLocationCredential Protokollspeicherort zuzugreifen.

  • Zur lokalen Protokollierung wechseln.

    Wenn Sie einen zentralen Speicherort zum Speichern von Protokollen angegeben haben, können Sie mit UseLocalLogLocation dem Parameter zurück zur lokalen Protokollierung auf den Netzwerkcontrollerknoten wechseln (aufgrund großer Speicherplatzanforderungen nicht empfohlen).

  • Protokollierungsbereich.

    Standardmäßig werden alle Protokolle gesammelt. Sie können den Bereich so ändern, dass nur Netzwerkcontroller-Clusterprotokolle erfasst werden.

  • Protokolliergrad.

    Der Standardprotokolliergrad ist Information. Sie können sie in Fehler, Warnung oder Ausführlich ändern.

  • Protokollalterungszeit.

    Die Protokolle werden kreisförmig gespeichert. Sie haben standardmäßig drei Tage Zeit für die Protokollierung von Daten, unabhängig davon, ob Sie die lokale Protokollierung oder die zentralisierte Protokollierung verwenden. Sie können dieses Zeitlimit mit dem LogTimeLimitInDays Parameter ändern.

  • Protokollalterungsgröße.

    Standardmäßig verfügen Sie über maximal 75 GB An Protokollierungsdaten, wenn Sie die zentrale Protokollierung verwenden, und 25 GB bei Verwendung der lokalen Protokollierung. Sie können diesen Grenzwert mit dem LogSizeLimitInMBs Parameter ändern.

Sammeln von Protokollen und Ablaufverfolgungen

VMM-Bereitstellungen verwenden standardmäßig eine zentralisierte Protokollierung für den Netzwerkcontroller. Der Dateifreigabespeicherort für diese Protokolle wird beim Bereitstellen der Netzwerkcontrollerdienstvorlage angegeben.

Wenn kein Dateispeicherort angegeben wurde, wird die lokale Protokollierung auf jedem Netzwerkcontrollerknoten mit Protokollen verwendet, die unter C:\Windows\tracing\SDNDiagnostics gespeichert sind. Diese Protokolle werden mithilfe der folgenden Hierarchie gespeichert:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Spuren

Der Netzwerkcontroller verwendet (Azure) Service Fabric. Bei der Behandlung bestimmter Probleme sind möglicherweise Service Fabric-Protokolle erforderlich. Diese Protokolle finden Sie auf jedem Netzwerkcontrollerknoten unter C:\ProgramData\Microsoft\Service Fabric.

Wenn ein Benutzer das Debug-NetworkController Cmdlet ausgeführt hat, sind weitere Protokolle auf jedem Hyper-V-Host verfügbar, der mit einer Serverressource im Netzwerkcontroller angegeben wurde. Diese Protokolle (und Ablaufverfolgungen, falls aktiviert) werden unter C:\NCDiagnostics gespeichert.

SLB-Diagnose

SLBM-Fabricfehler (Hostingdienstanbieteraktionen)

  1. Überprüfen Sie, ob Software Load Balancer Manager (SLBM) funktioniert und dass die Orchestrierungsebenen miteinander kommunizieren können: SLBM –> SLB Mux und SLBM –> SLB-Host-Agents. Führen Sie DumpSlbRestState von einem beliebigen Knoten mit Zugriff auf den Netzwerkcontroller-REST-Endpunkt aus.
  2. Überprüfen Sie die SDNSLBMPerfCounters in PerfMon auf einem der Netzwerkcontrollerknoten-VMs (vorzugsweise den primären Netzwerkcontrollerknoten - Get-NetworkControllerReplica):
    1. Ist Load Balancer -Engine (LB) mit SLBM verbunden? (SLBM LBEngine-Konfigurationen insgesamt > 0)
    2. Kennt SLBM zumindest seine eigenen Endpunkte? (VIP-Endpunkte gesamt>= 2)
    3. Sind Hyper-V-Hosts (DIP) mit SLBM verbunden? (HP-Clients verbunden == anzahl Server)
    4. Ist SLBM mit Muxes verbunden? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VMs).
  3. Stellen Sie sicher, dass der konfigurierte BGP-Router erfolgreich peering mit dem SLB MUX ist.
    1. Bei Verwendung von RRAS mit Remotezugriff (d. b. virtueller BGP-Computer):
      1. Get-BgpPeer sollte verbunden angezeigt werden.
      2. Get-BgpRouteInformation sollte mindestens eine Route für die SLBM-Selbst-VIP anzeigen.
    2. Wenn Sie einen physischen ToR-Switch (Top-of-Rack) als BGP-Peer verwenden, lesen Sie Ihre Dokumentation:
      1. Beispiel: # show bgp instance
  4. Überprüfen Sie die Leistungsindikatoren SlbMuxPerfCounters und SLBMUX in PerfMon auf der SLB-Mux-VM.
  5. Überprüfen Sie den Konfigurationsstatus und VIP-Bereiche in der Software Load Balancer Manager-Ressource.
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (Überprüfen Sie VIP-Bereiche in IP-Pools, und stellen Sie sicher, dass SLBM-Selbst-VIP (LoadBalanacerManagerIPAddress) und alle mandantenseitigen VIPs innerhalb dieser Bereiche liegen.
      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 -

Wenn eine der oben genannten Überprüfungen fehlschlägt, befindet sich auch der SLB-Zustand des Mandanten in einem Fehlermodus.

Sanierung

Beheben Sie basierend auf den folgenden Diagnoseinformationen Folgendes:

  • Sicherstellen, dass SLB-Multiplexer verbunden sind
    • Beheben von Zertifikatproblemen
    • Beheben von Netzwerkkonnektivitätsproblemen
  • Sicherstellen, dass BGP-Peeringinformationen erfolgreich konfiguriert wurden
  • Stellen Sie sicher, dass die Host-ID in der Registrierung mit der Serverinstanz-ID in der Serverressource übereinstimmt (Referenz anhang für HostNotConnected-Fehlercode ).
  • Erfassen von Protokollen

SLBM-Mandantenfehler (Hostingdienstanbieter und Mandantenaktionen)

  1. [Hoster] Überprüfen Sie Debug-NetworkControllerConfigurationState , ob sich LoadBalancer-Ressourcen in einem Fehlerzustand befinden. Versuchen Sie, dies zu beheben, indem Sie der Tabelle Aktionselemente im Anhang folgen.
    1. Überprüfen Sie, ob ein VIP-Endpunkt vorhanden ist und Werberouten angezeigt werden.
    2. Überprüfen Sie, wie viele DIP-Endpunkte für den VIP-Endpunkt ermittelt wurden.
  2. [Mandant] Überprüfen Sie Load Balancer Ressourcen richtig angegeben sind.
    1. Überprüfen Sie, ob DIP-Endpunkte, die in SLBM registriert sind, Mandanten-VMs hosten, die den IP-Konfigurationen des LoadBalancer-Back-End-Adresspools entsprechen.
  3. [Hoster] Wenn DIP-Endpunkte nicht ermittelt oder verbunden sind:

    1. Prüfen Debug-NetworkControllerConfigurationState

      Überprüfen Sie mithilfe von netstat -anp tcp |findstr 6640), ob nc- und SLB-Host-Agent erfolgreich mit dem Netzwerkcontroller-Ereigniskoordinator verbunden sind.

    2. Check HostIdin nchostagent service regkey (Verweisfehlercode HostNotConnected im Anhang) stimmt mit der instance-ID (Get-NCServer |convertto-json -depth 8) der entsprechenden Serverressource überein.

    3. Überprüfen Sie die Portprofil-ID für den Port des virtuellen Computers mit der Instanz-ID der entsprechenden NIC-Ressource des virtuellen Computers.

  4. [Hostinganbieter] Sammeln von Protokollen.

SLB-Mux-Ablaufverfolgung

Informationen aus der Software Load Balancer Muxes können auch durch Ereignisanzeige bestimmt werden.

  1. Wählen Sie im Menü Ansicht Ereignisanzeige die Option Analyse- und Debugprotokolle anzeigen aus.
  2. Navigieren Sie in Ereignisanzeige zu Anwendungs- und Dienstprotokolle>Microsoft>Windows>SlbMuxDriver-Ablaufverfolgung>.
  3. Klicken Sie mit der rechten Maustaste darauf, und wählen Sie Protokoll aktivieren aus.

Hinweis

Es wird empfohlen, diese Protokollierung nur für kurze Zeit zu aktivieren, während Sie versuchen, ein Problem zu reproduzieren.

VFP- und vSwitch-Ablaufverfolgung

Von jedem Hyper-V-Host, der eine Gast-VM hostet, die an ein virtuelles Mandantennetzwerk angefügt ist, können Sie eine VFP-Ablaufverfolgung sammeln, um zu ermitteln, wo Probleme liegen könnten.

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