Résoudre les problèmes de la pile de mise en réseau à définition logicielle Windows Server

  • Article

Ce guide examine les erreurs SDN (Software Defined Networking) et les scénarios d’échec courants, et décrit un workflow de résolution des problèmes qui utilise les outils de diagnostic disponibles. Pour plus d’informations sur SDN, consultez Software Defined Networking.

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versions 21H2 et 20H2

Types d’erreurs

La liste suivante représente la classe de problèmes les plus fréquemment rencontrés avec la virtualisation de réseau Hyper-V (HNVv1) dans Windows Server 2012 R2 à partir de déploiements de production sur le marché et coïncide à bien des égards avec les mêmes types de problèmes que dans Windows Server 2016 HNVv2 avec la nouvelle pile SDN (Software Defined Network).

La plupart des erreurs peuvent être classées dans un petit ensemble de classes :

  • Configuration non valide ou non prise en charge

    Un utilisateur appelle l’API NorthBound de manière incorrecte ou avec une stratégie non valide.

  • Erreur dans l’application de stratégie

    La stratégie du contrôleur de réseau n’a pas été remise à un hôte Hyper-V, retardée ou à jour sur tous les hôtes Hyper-V (par exemple, après une migration dynamique).

  • Dérive de la configuration ou bogue logiciel

    Problèmes de chemin d’accès aux données entraînant la suppression de paquets.

  • Erreur externe liée au matériel/pilotes de la carte réseau ou à l’infrastructure réseau sous-couche

    Déchargements de tâches (par exemple, VMQ) ou infrastructure réseau sous-couche mal configurée (par exemple, MTU)

    Ce guide de résolution des problèmes examine chacune de ces catégories d’erreurs et recommande les meilleures pratiques et les outils de diagnostic disponibles pour identifier et corriger l’erreur.

Outils de diagnostic

Avant de discuter des workflows de résolution des problèmes pour chacun de ces types d’erreurs, examinons les outils de diagnostic disponibles.

Pour utiliser les outils de diagnostic contrôleur de réseau (chemin de contrôle), vous devez d’abord installer la RSAT-NetworkController fonctionnalité et importer le NetworkControllerDiagnostics module :

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

Pour utiliser les outils de diagnostic HNV Diagnostics (chemin de données), vous devez importer le HNVDiagnostics module :

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

diagnostics du contrôleur de réseau

Ces applets de commande sont documentées sur TechNet dans l’applet de commande Diagnostics du contrôleur de réseau. Ils permettent d’identifier les problèmes de cohérence de la stratégie réseau dans le chemin de contrôle entre les nœuds du contrôleur de réseau et entre le contrôleur de réseau et les agents hôtes NC s’exécutant sur les hôtes Hyper-V.

Les Debug-ServiceFabricNodeStatus applets de commande et Get-NetworkControllerReplica doivent être exécutées à partir de l’une des machines virtuelles du nœud contrôleur de réseau. Toutes les autres applets de commande de diagnostic NC peuvent être exécutées à partir de n’importe quel hôte, qui dispose d’une connectivité au contrôleur de réseau et se trouve dans le groupe de sécurité de gestion du contrôleur de réseau (Kerberos) ou a accès au certificat X.509 pour la gestion du contrôleur de réseau.

diagnostics de l’hôte Hyper-V

Ces applets de commande sont documentées sur TechNet dans l’applet de commande Hyper-V Network Virtualization (HNV) Diagnostics. Ils permettent d’identifier les problèmes liés au chemin d’accès aux données entre les machines virtuelles clientes (Est/Ouest) et le trafic d’entrée via une adresse IP virtuelle SLB (Nord/Sud).

, Debug-VirtualMachineQueueOperationGet-CustomerRoute, Get-PACAMapping, Get-ProviderAddress, Get-VMNetworkAdapterPortId, Get-VMSwitchExternalPortId, et Test-EncapOverheadSettings sont tous des tests locaux qui peuvent être exécutés à partir de n’importe quel hôte Hyper-V. Les autres applets de commande appellent des tests de chemin de données via le contrôleur de réseau et ont donc besoin d’accéder au contrôleur de réseau comme décrit ci-dessus.

GitHub

Le référentiel GitHub Microsoft/SDN contient de nombreux exemples de scripts et de workflows qui s’appuient sur ces applets de commande intégrées. En particulier, les scripts de diagnostic se trouvent dans le dossier Diagnostics . Aidez-nous à contribuer à ces scripts en envoyant des demandes de tirage.

Résolution des problèmes liés aux workflows et aux guides

[Hébergeur] Valider l’intégrité du système

Il existe une ressource incorporée nommée État de configuration dans plusieurs ressources du contrôleur de réseau. L’état de configuration fournit des informations sur l’intégrité du système, notamment la cohérence entre la configuration du contrôleur de réseau et l’état réel (en cours d’exécution) sur les hôtes Hyper-V.

Pour case activée’état de configuration, exécutez la commande suivante à partir de n’importe quel hôte Hyper-V connecté au contrôleur de réseau.

Remarque

La valeur du NetworkController paramètre doit être le nom de domaine complet ou l’adresse IP en fonction du nom d’objet du certificat X.509 >créé pour le contrôleur de réseau.

Le Credential paramètre doit être spécifié uniquement si le contrôleur de réseau utilise l’authentification Kerberos (typique dans les déploiements VMM). Les informations d’identification doivent être destinées à un utilisateur qui se trouve dans le groupe de sécurité gestion du contrôleur de réseau.

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

Voici un exemple de message d’état de configuration :

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

Remarque

Il existe un bogue dans le système où les ressources d’interface réseau de la carte réseau de la carte réseau de la machine virtuelle Mux Transit SLB sont dans un état d’échec avec l’erreur « Commutateur virtuel - Hôte non connecté au contrôleur ». Cette erreur peut être ignorée en toute sécurité si la configuration IP dans la ressource de carte réseau de machine virtuelle est définie sur une adresse IP à partir du pool d’adresses IP du réseau logique de transit.

Il existe un deuxième bogue dans le système où les ressources d’interface réseau pour les cartes réseau des machines virtuelles du fournisseur HNV de passerelle sont dans un état d’échec avec l’erreur « Commutateur virtuel - PortBlocked ». Cette erreur peut également être ignorée en toute sécurité si la configuration IP dans la ressource de carte réseau de machine virtuelle est définie sur Null (par conception).

Le tableau ci-dessous présente la liste des codes d’erreur, des messages et des actions de suivi à effectuer en fonction de l’état de configuration observé.

Code Message Action
Inconnu Erreur inconnue
HostUnreachable L’ordinateur hôte n’est pas accessible Vérifier la connectivité réseau de gestion entre le contrôleur de réseau et l’hôte
PAIpAddressExhausted Adresses IP pa épuisées Augmenter la taille du pool d’adresses IP du sous-réseau logique du fournisseur HNV
PAMacAddressExhausted Les adresses Pa Mac épuisées Augmenter la plage de pools Mac
PAAddressConfigurationFailure Échec de l’aplomb des adresses PA à l’hôte Vérifiez la connectivité réseau de gestion entre le contrôleur de réseau et l’hôte.
CertificateNotTrusted Le certificat n’est pas approuvé Corrigez les certificats utilisés pour la communication avec l’hôte.
CertificateNotAuthorized Certificat non autorisé Corrigez les certificats utilisés pour la communication avec l’hôte.
PolicyConfigurationFailureOnVfp Échec de la configuration des stratégies VFP Il s’agit d’un échec d’exécution. Aucune solution de contournement définitive. Collectez les journaux.
PolicyConfigurationFailure Échec de l’envoi de stratégies aux hôtes, en raison d’échecs de communication ou d’autres erreurs dans le NetworkController. Pas d’actions précises. Cela est dû à l’échec du traitement de l’état d’objectif dans les modules du contrôleur de réseau. Collectez les journaux.
HostNotConnectedToController L’hôte n’est pas encore connecté au contrôleur de réseau Le profil de port n’est pas appliqué sur l’hôte ou l’hôte n’est pas accessible à partir du contrôleur de réseau. Vérifier que la clé de Registre HostID correspond à l’ID d’instance de la ressource serveur
MultipleVfpEnabledSwitches Il existe plusieurs commutateurs VFp activés sur l’hôte Supprimez l’un des commutateurs, car l’agent hôte du contrôleur de réseau ne prend en charge qu’un seul commutateur virtuel avec l’extension VFP activée
PolicyConfigurationFailure Échec de l’envoi de stratégies de réseau virtuel pour une machine virtuelle en raison d’erreurs de certificat ou d’erreurs de connectivité Vérifiez si les certificats appropriés ont été déployés (le nom du sujet du certificat doit correspondre au nom de domaine complet de l’hôte). Vérifiez également la connectivité de l’hôte avec le contrôleur de réseau
PolicyConfigurationFailure Échec de l’envoi de stratégies vSwitch pour une machine virtuelle en raison d’erreurs de certificat ou d’erreurs de connectivité Vérifiez si les certificats appropriés ont été déployés (le nom du sujet du certificat doit correspondre au nom de domaine complet de l’hôte). Vérifiez également la connectivité de l’hôte avec le contrôleur de réseau
PolicyConfigurationFailure Échec de l’envoi de stratégies de pare-feu pour une machine virtuelle en raison d’erreurs de certificat ou d’erreurs de connectivité Vérifiez si les certificats appropriés ont été déployés (le nom du sujet du certificat doit correspondre au nom de domaine complet de l’hôte). Vérifiez également la connectivité de l’hôte avec le contrôleur de réseau
DistributedRouterConfigurationFailure Échec de la configuration des paramètres du routeur distribué sur la carte réseau virtuelle de l’hôte Erreur de pile TCPIP. Peut nécessiter le nettoyage des cartes réseau virtuelles pa et hôte de récupération d’urgence sur le serveur sur lequel cette erreur a été signalée
DhcpAddressAllocationFailure Échec de l’allocation d’adresses DHCP pour une machine virtuelle Vérifier si l’attribut d’adresse IP statique est configuré sur la ressource de carte réseau
CertificateNotTrusted
CertificateNotAuthorized		 Échec de la connexion à Mux en raison d’erreurs de réseau ou de certificat Vérifiez le code numérique fourni dans le code du message d’erreur : cela correspond au code d’erreur winsock. Les erreurs de certificat sont granulaires (par exemple, le certificat ne peut pas être vérifié, le certificat n’est pas autorisé, etc.)
HostUnreachable L’expérience utilisateur MUX est non saine (le cas courant est BGPRouter déconnecté) L’homologue BGP sur le commutateur RRAS (machine virtuelle BGP) ou Top-of-Rack (ToR) est inaccessible ou n’est pas correctement appairé. Vérifiez les paramètres BGP sur la ressource de multiplexeur Software Load Balancer et sur l’homologue BGP (machine virtuelle ToR ou RRAS)
HostNotConnectedToController L’agent hôte SLB n’est pas connecté Vérifiez que le service Agent hôte SLB est en cours d’exécution ; Reportez-vous aux journaux de l’agent hôte SLB (en cours d’exécution automatique) pour connaître les raisons pour lesquelles, si LE SLBM (NC) rejette le certificat présenté par l’état d’exécution de l’agent hôte affiche des informations nuancées
PortBlocked Le port VFP est bloqué, en raison de l’absence de stratégies de réseau virtuel/ACL Vérifiez s’il existe d’autres erreurs, ce qui peut entraîner la non-configuration des stratégies.
Surchargé Loadbalancer MUX est surchargé Problème de performances avec MUX
RoutePublicationFailure Loadbalancer MUX n’est pas connecté à un routeur BGP Vérifiez si le MUX dispose d’une connectivité avec les routeurs BGP et que le peering BGP est correctement configuré
VirtualServerUnreachable Loadbalancer MUX n’est pas connecté au gestionnaire SLB Vérifier la connectivité entre SLBM et MUX
QosConfigurationFailure Échec de la configuration des stratégies QOS Voir si une bande passante suffisante est disponible pour toutes les machines virtuelles si la réservation QOS est utilisée

Vérifier la connectivité réseau entre le contrôleur de réseau et l’hôte Hyper-V (service agent hôte NC)

Exécutez la netstat commande ci-dessous pour vérifier qu’il existe trois ESTABLISHED connexions entre l’agent hôte NC et le ou les nœuds du contrôleur de réseau et un LISTENING socket sur l’hôte Hyper-V.

  • LISTENING sur le port TCP :6640 sur l’hôte Hyper-V (service agent hôte NC)
  • Deux connexions établies entre l’adresse IP de l’hôte Hyper-V sur le port 6640 et l’adresse IP du nœud NC sur les ports éphémères (> 32000)
  • Une connexion établie entre l’adresse IP de l’hôte Hyper-V sur le port éphémère et l’adresse IP REST du contrôleur de réseau sur le port 6640

Remarque

Il ne peut y avoir que deux connexions établies sur un hôte Hyper-V si aucune machine virtuelle locataire n’est déployée sur cet hôte particulier.

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

Vérifier les services de l’agent hôte

Le contrôleur de réseau communique avec deux services d’agent hôte sur les hôtes Hyper-V : Agent hôte SLB et Agent hôte NC. Il est possible que l’un de ces services ou les deux ne soient pas en cours d’exécution. Vérifiez leur état et redémarrez s’ils ne sont pas en cours d’exécution.

Get-Service SlbHostAgent
Get-Service NcHostAgent

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

Vérifier l’intégrité du contrôleur de réseau

S’il n’y a pas trois ESTABLISHED connexions ou si le contrôleur de réseau ne répond pas, case activée pour voir que tous les nœuds et modules de service sont opérationnels à l’aide des applets de commande suivantes.

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

Les modules de service du contrôleur de réseau sont les suivants :

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

Vérifiez que ReplicaStatus est Ready et HealthState est Ok.

Dans un déploiement de production avec un contrôleur de réseau à plusieurs nœuds, vous pouvez également case activée le nœud sur lequel chaque service est le principal et son réplica status individuel.

Get-NetworkControllerReplica

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

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

Vérifiez que l’état du réplica est Prêt pour chaque service.

Rechercher les Id d’hôte et les certificats correspondants entre le contrôleur de réseau et chaque hôte Hyper-V

Sur un hôte Hyper-V, exécutez les applets de commande suivantes pour case activée que l’ID d’hôte correspond à l’ID d’instance d’une ressource de serveur sur le contrôleur de réseau

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

Assainissement

Si vous utilisez des scripts SDNExpress ou un déploiement manuel, mettez à jour la clé HostId dans le Registre pour qu’elle corresponde à l’ID d’instance de la ressource serveur. Redémarrez l’agent hôte du contrôleur de réseau sur l’hôte Hyper-V (serveur physique) Si vous utilisez VMM, supprimez le serveur Hyper-V de VMM et supprimez la clé de Registre HostId. Ensuite, ajoutez à nouveau le serveur via VMM.

Vérifiez que les empreintes des certificats X.509 utilisés par l’hôte Hyper-V (le nom d’hôte sera le nom d’objet du certificat) pour la communication (southbound) entre l’hôte Hyper-V (service agent hôte NC) et les nœuds du contrôleur réseau sont identiques. Case activée également que le certificat REST du contrôleur de réseau a le nom d’objet .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**
...

Vous pouvez également case activée les paramètres suivants de chaque certificat pour vous assurer que le nom de l’objet correspond à ce qui est attendu (nom d’hôte ou nom de domaine complet rest nc ou adresse IP), que le certificat n’a pas encore expiré et que toutes les autorités de certification de la chaîne de certificats sont incluses dans l’autorité racine approuvée.

  • Nom de l’objet
  • Date d'expiration
  • Approuvé par l’autorité racine

Si plusieurs certificats ont le même nom d’objet sur l’hôte Hyper-V, l’agent hôte du contrôleur de réseau en choisit un au hasard à présenter au contrôleur de réseau. Cela peut ne pas correspondre à l’empreinte numérique de la ressource serveur connue du contrôleur de réseau. Dans ce cas, supprimez l’un des certificats portant le même nom d’objet sur l’hôte Hyper-V, puis redémarrez le service Agent hôte du contrôleur de réseau. Si une connexion ne peut toujours pas être établie, supprimez l’autre certificat portant le même nom d’objet sur l’hôte Hyper-V et supprimez la ressource serveur correspondante dans VMM. Ensuite, recréez la ressource serveur dans VMM, qui génère un nouveau certificat X.509 et l’installe sur l’hôte Hyper-V.

Vérifier l’état de configuration SLB

L’état de configuration SLB peut être déterminé dans le cadre de la sortie de l’applet de Debug-NetworkController commande. Cette applet de commande génère également l’ensemble actuel de ressources du contrôleur de réseau dans les fichiers JSON, toutes les configurations IP de chaque hôte Hyper-V (serveur) et la stratégie de réseau local à partir des tables de base de données de l’Agent hôte.

D’autres traces seront collectées par défaut. Pour ne pas collecter de traces, ajoutez le -IncludeTraces:$false paramètre .

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

Remarque

L’emplacement de sortie par défaut est le <répertoire working_directory>\NCDiagnostics\. Le répertoire de sortie par défaut peut être modifié à l’aide du -OutputDirectory paramètre .

Les informations sur l’état de configuration de l’équilibrage de charge réseau se trouvent dans le fichier diagnostics-slbstateResults.Json de ce répertoire.

Ce fichier JSON peut être divisé en sections suivantes :

  • Tissu
    • SlbmVips : cette section répertorie l’adresse IP de l’adresse IP IP du gestionnaire SLB, qui est utilisée par le contrôleur de réseau pour coordonner la configuration et l’intégrité entre les multiplexes SLB et les agents hôtes SLB.
    • MuxState : cette section répertorie une valeur pour chaque Mux SLB déployé, indiquant l’état du mux
    • Configuration du routeur : cette section répertorie le numéro de système autonome (ASN) du routeur en amont (pair BGP), l’adresse IP de transit et l’ID. Il répertorie également l’ASN SLB Muxes et l’ADRESSE IP de transit.
    • Informations sur l’hôte connecté : cette section répertorie l’adresse IP de gestion de tous les hôtes Hyper-V disponibles pour exécuter des charges de travail à charge équilibrée.
    • Plages d’adresses IP virtuelles : cette section répertorie les plages d’adresses IP virtuelles publiques et privées. L’adresse IP virtuelle SLBM sera incluse en tant qu’adresse IP allouée à partir de l’une de ces plages.
    • Itinéraires Mux : cette section répertorie une valeur pour chaque Mux SLB déployé contenant toutes les annonces de routage pour ce mux particulier.
  • Tenant
    • VipConsolidatedState : cette section répertorie l’état de connectivité pour chaque adresse IP virtuelle de locataire, y compris le préfixe de routage publié, l’hôte Hyper-V et les points de terminaison DIP.

Remarque

L’état SLB peut être déterminé directement à l’aide du script DumpSlbRestState disponible sur le référentiel GitHub Microsoft SDN.

Validation de la passerelle

À partir du contrôleur de réseau :

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

À partir d’une machine virtuelle de passerelle :

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

Commutateur à partir du haut du rack (ToR) :

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

Routeur BGP Windows :

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

En plus de ces problèmes, d’après les problèmes que nous avons rencontrés jusqu’à présent (en particulier sur les déploiements basés sur SDNExpress), la raison la plus courante pour laquelle le compartiment de locataire n’est pas configuré sur les machines virtuelles GW semblent être le fait que la capacité GW dans FabricConfig.psd1 est moins comparée à ce que les gens essaient d’attribuer au network Connections (tunnels S2S) dans TenantConfig.psd1. Cela peut être vérifié facilement en comparant les sorties des applets de commande suivantes :

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Hébergeur] Valider Data-Plane

Une fois que le contrôleur de réseau a été déployé, que les réseaux virtuels et sous-réseaux du locataire ont été créés et que les machines virtuelles ont été attachées aux sous-réseaux virtuels, des tests supplémentaires au niveau de la structure peuvent être effectués par l’hébergeur pour case activée la connectivité du locataire.

Vérifier la connectivité réseau logique du fournisseur HNV

Une fois que la première machine virtuelle invitée s’exécutant sur un hôte Hyper-V a été connectée à un réseau virtuel de locataire, le contrôleur de réseau affecte deux adresses IP du fournisseur HNV (ADRESSES IP PA) à l’hôte Hyper-V. Ces adresses IP proviennent du pool d’adresses IP du réseau logique du fournisseur HNV et sont gérées par le contrôleur de réseau. Pour savoir ce que sont ces deux adresses IP HNV :

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

Ces adresses IP du fournisseur HNV (PA) sont attribuées aux cartes Ethernet créées dans un compartiment réseau TCPIP distinct et ont un nom de carte VLANX où X est le réseau local virtuel affecté au réseau logique du fournisseur HNV (transport).

La connectivité entre deux hôtes Hyper-V à l’aide du réseau logique du fournisseur HNV peut être effectuée par un ping avec un paramètre de compartiment supplémentaire (-c Y) où Y est le compartiment réseau TCPIP dans lequel les cartes PAhostVNIC sont créées. Ce compartiment peut être déterminé en exécutant :

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

Remarque

Les adaptateurs de carte réseau virtuelle de l’hôte PA ne sont pas utilisés dans le chemin de données et n’ont donc pas d’adresse IP affectée à l'« adaptateur vEthernet (PAhostVNic) ».

Par instance, supposons que les hôtes Hyper-V 1 et 2 ont des adresses IP de fournisseur HNV (PA) :

Hôte Hyper-V Adresse IP du pa 1 Adresse IP 2 du pa
Hôte 1 10.10.182.64 10.10.182.65
Hôte 2 10.10.182.66 10.10.182.67

Nous pouvons effectuer un test ping entre les deux à l’aide de la commande suivante pour case activée connectivité réseau logique du fournisseur HNV.

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

Assainissement

Si le test ping du fournisseur HNV ne fonctionne pas, case activée votre connectivité réseau physique, y compris la configuration du réseau local virtuel. Les cartes réseau physiques sur chaque hôte Hyper-V doivent être en mode jonction sans réseau local virtuel spécifique affecté. La carte réseau virtuelle de l’hôte de gestion doit être isolée sur le réseau local virtuel du réseau logique de gestion.

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

Vérifier la prise en charge des trames MTU et Jumbo sur le réseau logique du fournisseur HNV

Un autre problème courant dans le réseau logique du fournisseur HNV est que les ports réseau physiques et/ou les carte Ethernet ne disposent pas d’une MTU suffisamment grande configurée pour gérer la surcharge de l’encapsulation VXLAN (ou NVGRE).

Remarque

Certaines cartes et pilotes Ethernet prennent en charge la nouvelle *EncapOverhead mot clé qui sera automatiquement définie par l’agent hôte du contrôleur de réseau sur la valeur 160. Cette valeur sera ensuite ajoutée à la valeur du *JumboPacket mot clé dont la somme est utilisée comme MTU annoncée.

Par exemple, *EncapOverhead = 160 et *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

Pour tester si le réseau logique du fournisseur HNV prend en charge la plus grande taille MTU de bout en bout, utilisez l’applet de Test-LogicalNetworkSupportsJumboPacket commande :

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

Assainissement

  • Ajustez la taille MTU sur les ports du commutateur physique pour qu’elle soit d’au moins 1674B (y compris l’en-tête Ethernet 14B et la remorque)
  • Si votre carte de carte réseau ne prend pas en charge le mot clé EncapOverhead, réglez la mot clé JumboPacket sur au moins 1674B.

Vérifier la connectivité de la carte réseau des machines virtuelles du locataire

Chaque carte réseau de machine virtuelle affectée à une machine virtuelle invitée a un mappage CA-PA entre l’adresse du client privé et l’espace d’adresse du fournisseur HNV. Ces mappages sont conservés dans les tables de serveur OVSDB sur chaque hôte Hyper-V et peuvent être trouvés en exécutant l’applet de commande suivante.

# 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

Remarque

Si les mappages CA-PA attendus ne sont pas générés pour une machine virtuelle cliente donnée, case activée les ressources de configuration IP et de carte réseau de machine virtuelle sur le contrôleur de réseau à l’aide de l’applet de Get-NetworkControllerNetworkInterface commande . En outre, case activée les connexions établies entre l’agent hôte NC et les nœuds du contrôleur de réseau.

Avec ces informations, un test ping de machine virtuelle client peut maintenant être lancé par l’hébergeur à partir du contrôleur de réseau à l’aide de l’applet de Test-VirtualNetworkConnection commande .

Scénarios de résolution des problèmes spécifiques

Les sections suivantes fournissent des conseils pour la résolution de scénarios spécifiques.

Aucune connectivité réseau entre deux machines virtuelles clientes

  1. [Locataire] Vérifiez que le Pare-feu Windows dans les machines virtuelles clientes ne bloque pas le trafic.
  2. [Locataire] Vérifiez que les adresses IP ont été attribuées à la machine virtuelle cliente en exécutant ipconfig.
  3. [Hébergeur] Exécutez Test-VirtualNetworkConnection à partir de l’hôte Hyper-V pour valider la connectivité entre les deux machines virtuelles clientes en question.

Remarque

Le VSID fait référence à l’ID de sous-réseau virtuel. Dans le cas de VXLAN, il s’agit de l’identificateur de réseau VXLAN (VNI). Vous pouvez trouver cette valeur en exécutant l’applet de Get-PACAMapping commande .

Exemple

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

Créez une ca-ping entre « Green Web VM 1 » avec l’adresse IP SenderCA 192.168.1.4 sur l’hôte « sa18n30-2.sa18.nttest.microsoft.com » avec l’adresse IP Mgmt 10.127.132.153 vers l’adresse IP ListenerCA de 192.168.1.5, toutes deux attachées au sous-réseau virtuel (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> ...

[Locataire] Vérifiez qu’aucune stratégie de pare-feu distribuée n’est spécifiée sur le sous-réseau virtuel ou les interfaces réseau de machine virtuelle qui bloquerait le trafic.

Interrogez l’API REST du contrôleur de réseau trouvée dans l’environnement de démonstration à l’adresse sa18n30nc dans le domaine sa18.nttest.microsoft.com.

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

Examiner la configuration IP et les sous-réseaux virtuels qui font référence à cette liste de contrôle d’accès

  1. [Hébergeur] Exécuter Get-ProviderAddress sur les deux hôtes Hyper-V hébergeant les deux machines virtuelles clientes en question, puis exécuter Test-LogicalNetworkConnection ou ping -c <compartment> à partir de l’hôte Hyper-V pour valider la connectivité sur le réseau logique du fournisseur HNV
  2. [Hébergeur] Assurez-vous que les paramètres MTU sont corrects sur les hôtes Hyper-V et tous les appareils de basculement de couche 2 entre les hôtes Hyper-V. Exécutez Test-EncapOverheadValue sur tous les hôtes Hyper-V en question. En outre, case activée que tous les commutateurs de couche 2 entre ont un MTU défini sur au moins 1674 octets pour tenir compte de la surcharge maximale de 160 octets.
  3. [Hébergeur] Si les adresses IP pa ne sont pas présentes et/ou si la connectivité de l’autorité de certification est interrompue, case activée pour vous assurer que la stratégie réseau a été reçue. Exécutez Get-PACAMapping pour voir si les règles d’encapsulation et les mappages CA-PA requis pour créer des réseaux virtuels de superposition sont correctement établis.
  4. [Hébergeur] Vérifiez que l’agent hôte du contrôleur de réseau est connecté au contrôleur de réseau. Pour ce faire, exécutez netstat -anp tcp |findstr 6640.
  5. [Hébergeur] Vérifiez que l’ID d’hôte dans HKLM/ correspond à l’ID d’instance des ressources serveur hébergeant les machines virtuelles du locataire.
  6. [Hébergeur] Vérifiez que l’ID de profil de port correspond à l’ID d’instance des interfaces réseau de machine virtuelle des machines virtuelles clientes.

Journalisation, suivi et diagnostics avancés

Les sections suivantes fournissent des informations sur les diagnostics avancées, la journalisation et le suivi.

Journalisation centralisée du contrôleur de réseau

Le contrôleur de réseau peut collecter automatiquement les journaux du débogueur et les stocker dans un emplacement centralisé. La collecte de journaux peut être activée lorsque vous déployez le contrôleur de réseau pour la première fois ou à tout moment ultérieurement. Les journaux sont collectés à partir du contrôleur de réseau et des éléments réseau gérés par le contrôleur de réseau : ordinateurs hôtes, équilibreurs de charge logiciels (SLB) et machines de passerelle.

Ces journaux incluent les journaux de débogage pour le cluster de contrôleur de réseau, l’application du contrôleur de réseau, les journaux de passerelle, l’équilibrage de charge réseau, la mise en réseau virtuelle et le pare-feu distribué. Chaque fois qu’un nouvel hôte/SLB/passerelle est ajouté au contrôleur de réseau, la journalisation est démarrée sur ces ordinateurs. De même, lorsqu’un hôte/SLB/passerelle est supprimé du contrôleur de réseau, la journalisation est arrêtée sur ces ordinateurs.

Activer la journalisation

La journalisation est automatiquement activée lorsque vous installez le cluster de contrôleur de réseau à l’aide de l’applet de Install-NetworkControllerCluster commande . Par défaut, les journaux sont collectés localement sur les nœuds du contrôleur de réseau à l’emplacement %systemdrive%\SDNDiagnostics. Il est recommandé de modifier cet emplacement pour qu’il s’agit d’un partage de fichiers distant (et non local).

Les journaux du cluster du contrôleur de réseau sont stockés dans %programData%\Windows Fabric\log\Traces. Vous pouvez spécifier un emplacement centralisé pour la collecte de journaux avec le DiagnosticLogLocation paramètre avec la recommandation qu’il s’agit également d’un partage de fichiers distant.

Si vous souhaitez restreindre l’accès à cet emplacement, vous pouvez fournir les informations d’identification d’accès avec le LogLocationCredential paramètre . Si vous fournissez les informations d’identification pour accéder à l’emplacement du journal, vous devez également fournir le CredentialEncryptionCertificate paramètre , qui est utilisé pour chiffrer les informations d’identification stockées localement sur les nœuds du contrôleur de réseau.

Avec les paramètres par défaut, il est recommandé de disposer d’au moins 75 Go d’espace libre à l’emplacement central et de 25 Go sur les nœuds locaux (si vous n’utilisez pas un emplacement central) pour un cluster contrôleur de réseau à trois nœuds.

Modifier les paramètres de journalisation

Vous pouvez modifier les paramètres de journalisation à tout moment à l’aide de l’applet de Set-NetworkControllerDiagnostic commande . Les paramètres suivants peuvent être modifiés :

  • Emplacement centralisé du journal.

    Vous pouvez modifier l’emplacement pour stocker tous les journaux, avec le DiagnosticLogLocation paramètre .

  • Informations d’identification pour accéder à l’emplacement du journal.

    Vous pouvez modifier les informations d’identification pour accéder à l’emplacement du journal, avec le LogLocationCredential paramètre .

  • Passer à la journalisation locale.

    Si vous avez fourni un emplacement centralisé pour stocker les journaux, vous pouvez revenir à la journalisation localement sur les nœuds du contrôleur de réseau avec le UseLocalLogLocation paramètre (non recommandé en raison d’un espace disque important).

  • Étendue de journalisation.

    Par défaut, tous les journaux sont collectés. Vous pouvez modifier l’étendue pour collecter uniquement les journaux du cluster du contrôleur de réseau.

  • Niveau de journalisation.

    Le niveau de journalisation par défaut est Information. Vous pouvez le remplacer par Erreur, Avertissement ou Verbose.

  • Temps de vieillissement des journaux.

    Les journaux sont stockés de manière circulaire. Vous disposez de trois jours de journalisation des données par défaut, que vous utilisiez la journalisation locale ou la journalisation centralisée. Vous pouvez modifier cette limite de temps avec le LogTimeLimitInDays paramètre .

  • Taille du vieillissement du journal.

    Par défaut, vous disposez d’un maximum de 75 Go de données de journalisation si vous utilisez la journalisation centralisée et de 25 Go si vous utilisez la journalisation locale. Vous pouvez modifier cette limite avec le LogSizeLimitInMBs paramètre .

Collecte des journaux et des traces

Les déploiements VMM utilisent la journalisation centralisée pour le contrôleur de réseau par défaut. L’emplacement de partage de fichiers pour ces journaux est spécifié lors du déploiement du modèle de service contrôleur de réseau.

Si aucun emplacement de fichier n’a été spécifié, la journalisation locale est utilisée sur chaque nœud du contrôleur de réseau avec les journaux enregistrés sous C :\Windows\tracing\SDNDiagnostics. Ces journaux sont enregistrés à l’aide de la hiérarchie suivante :

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Traces

Le contrôleur de réseau utilise (Azure) Service Fabric. Les journaux Service Fabric peuvent être nécessaires pour résoudre certains problèmes. Ces journaux se trouvent sur chaque nœud de contrôleur de réseau à l’adresse C :\ProgramData\Microsoft\Service Fabric.

Si un utilisateur a exécuté l’applet Debug-NetworkController de commande, d’autres journaux sont disponibles sur chaque hôte Hyper-V, qui a été spécifié avec une ressource de serveur dans le contrôleur de réseau. Ces journaux (et traces si activés) sont conservés sous C :\NCDiagnostics.

diagnostics SLB

Erreurs d’infrastructure SLBM (actions du fournisseur de services d’hébergement)

  1. Vérifiez que software Load Balancer Manager (SLBM) fonctionne et que les couches d’orchestration peuvent communiquer entre elles : SLBM -> SLB Mux et SLBM -> Agents hôtes SLB. Exécutez DumpSlbRestState à partir de n’importe quel nœud ayant accès au point de terminaison REST du contrôleur de réseau.
  2. Validez les SDNSLBMPerfCounters dans PerfMon sur l’une des machines virtuelles du nœud de contrôleur de réseau (de préférence le nœud principal du contrôleur de réseau ) Get-NetworkControllerReplica:
    1. Le moteur Load Balancer (LB) est-il connecté à SLBM ? (Nombre total > de configurations SLBM LBEngine 0)
    2. Le SLBM connaît-il au moins ses propres points de terminaison ? (Nombre total >de points de terminaison VIP = 2)
    3. Les hôtes Hyper-V (DIP) sont-ils connectés à SLBM ? (Clients HP connectés == serveurs num)
    4. SlBM est-il connecté à Muxes ? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes machines virtuelles).
  3. Vérifiez que le routeur BGP configuré est correctement appairé avec le MUX SLB.
    1. Si vous utilisez RRAS avec l’accès à distance (autrement dit, une machine virtuelle BGP) :
      1. Get-BgpPeer doit afficher connecté.
      2. Get-BgpRouteInformation doit afficher au moins un itinéraire pour l’adresse IP virtuelle autonome SLBM.
    2. Si vous utilisez un commutateur ToR (Top-of-Rack) physique en tant qu’homologue BGP, consultez votre documentation :
      1. Par exemple : # show bgp instance
  4. Validez les compteurs SlbMuxPerfCounters et SLBMUX dans PerfMon sur la machine virtuelle SLB Mux.
  5. Vérifiez l’état de configuration et les plages d’adresses IP virtuelles dans la ressource Software Load Balancer Manager.
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8(case activée des plages d’adresses IP virtuelles dans les pools d’adresses IP et assurez-vous que l’adresse IP virtuelle auto-IP SLBM (LoadBalanacerManagerIPAddress) et toutes les adresses IP virtuelles orientées client se trouvent dans ces plages)
      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 -

Si l’une des vérifications ci-dessus échoue, l’état SLB du locataire sera également en mode d’échec.

Assainissement

En fonction des informations de diagnostic suivantes présentées, corrigez les problèmes suivants :

  • Vérifier que les multiplexeurs SLB sont connectés
    • Résoudre les problèmes de certificat
    • Résoudre les problèmes de connectivité réseau
  • Vérifier que les informations de peering BGP sont correctement configurées
  • Vérifiez que l’ID d’hôte dans le Registre correspond à l’ID d’instance de serveur dans la ressource du serveur (annexe de référence pour le code d’erreur HostNotConnected )
  • Collecte des journaux

Erreurs de locataire SLBM (actions du fournisseur de services d’hébergement et du locataire)

  1. [Hébergeur] Vérifiez Debug-NetworkControllerConfigurationState si des ressources LoadBalancer sont dans un état d’erreur. Essayez d’atténuer les problèmes en suivant le tableau Des éléments d’action dans l’annexe.
    1. Vérifiez qu’un point de terminaison VIP et des itinéraires publicitaires sont présents.
    2. Vérifiez le nombre de points de terminaison DIP qui ont été découverts pour le point de terminaison VIP.
  2. [Locataire] Vérifiez Load Balancer ressources sont correctement spécifiées.
    1. Vérifiez que les points de terminaison DIP inscrits dans SLBM hébergent des machines virtuelles clientes, qui correspondent aux configurations IP du pool d’adresses principales LoadBalancer.
  3. [Hébergeur] Si les points de terminaison DIP ne sont pas découverts ou connectés :

    1. Vérifier Debug-NetworkControllerConfigurationState

      Vérifiez que l’agent hôte nc et SLB est correctement connecté au coordinateur d’événements du contrôleur de réseau à l’aide netstat -anp tcp |findstr 6640)de .

    2. La HostIdclé de registre d’archivage du service (code d’erreur de référence HostNotConnected dans l’annexe) correspond à l’ID de instance de la ressource serveur correspondante (Get-NCServer |convertto-json -depth 8).nchostagent

    3. Vérifiez que l’ID de profil de port de la machine virtuelle correspond à l’ID d’instance de la ressource de carte réseau de machine virtuelle correspondante.

  4. [Fournisseur d’hébergement] Collectez les journaux.

Suivi des Mux SLB

Les informations du software Load Balancer Muxes peuvent également être déterminées via observateur d'événements.

  1. Sélectionnez Afficher les journaux d’activité analytiques et de débogage dans le menu Affichage observateur d'événements.
  2. Accédez à Applications and Services Logs>Microsoft>Windows>SlbMuxDriver>Trace dans observateur d'événements.
  3. Cliquez dessus avec le bouton droit et sélectionnez Activer le journal.

Remarque

Il est recommandé de n’activer cette journalisation que pendant une courte période pendant que vous essayez de reproduire un problème.

Suivi VFP et vSwitch

À partir de n’importe quel hôte Hyper-V hébergeant une machine virtuelle invitée attachée à un réseau virtuel de locataire, vous pouvez collecter une trace VFP pour déterminer où se trouvent les problèmes.

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