Résoudre les problèmes de la pile de mise en réseau SDN (Software Defined Networking) dans Windows Server

  • Article
  • 32 minutes de lecture

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

Ce guide examine les scénarios courants d’erreurs et de défaillances SDN (Software Defined Networking) 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.

Types d’erreurs

La liste suivante représente la classe des problèmes les plus souvent rencontrés avec Virtualisation de réseau Hyper-V (HNVv1) dans Windows Server 2012 R2 à partir de déploiements de production sur le marché et coïncide de nombreuses façons avec les mêmes types de problèmes observés 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 non à jour sur tous les hôtes Hyper-V (par exemple, après une migration dynamique).

  • Dérive de configuration ou bogue logiciel Problèmes de chemin d’accès aux données entraînant des paquets supprimés.

  • Erreur externe liée au matériel/pilotes de carte réseau ou à l’infrastructure réseau de sous-couche Déchargements de tâches mal gérés (par exemple, VMQ) ou structure réseau mal configurée (par exemple, MTU)

    Ce guide de dépannage 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 du contrôleur de réseau (chemin de contrôle), vous devez d’abord installer la fonctionnalité RSAT-NetworkController et importer le NetworkControllerDiagnostics module :

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

Pour utiliser les outils de diagnostic HNV Diagnostics (chemin d’accès aux 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 la rubrique d’applet de commande Diagnostics du contrôleur de réseau. Ils permettent d’identifier les problèmes liés à la 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 applets de commande Debug-ServiceFabricNodeStatus 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 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 gérer le contrôleur de réseau.

Diagnostics de l’hôte Hyper-V

Ces applets de commande sont documentées sur TechNet dans la rubrique d’applets de commande de diagnostic Virtualisation de réseau Hyper-V (HNV). Ils permettent d’identifier les problèmes dans le chemin d’accès aux données entre les machines virtuelles client (Est/Ouest) et le trafic d’entrée via une adresse IP virtuelle SLB (nord/sud).

Debug-VirtualMachineQueueOperation, Get-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 d’accès aux 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 dépôt microsoft/SDN GitHub contient de nombreux exemples de scripts et flux de travail qui s’appuient sur ces applets de commande in-box. En particulier, les scripts de diagnostic se trouvent dans le dossier Diagnostics . Aidez-nous à contribuer à ces scripts en envoyant des demandes de tirage.

Dépannage des flux de travail et des guides

[Hôte] 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 vérifier l’état de configuration, exécutez ce qui suit à partir d’un hôte Hyper-V avec une connectivité au contrôleur de réseau.

Notes

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

Le paramètre Credential doit uniquement être spécifié si le contrôleur de réseau utilise l’authentification Kerberos (généralement dans les déploiements VMM). Les informations d’identification doivent être pour un utilisateur qui se trouve dans le groupe de sécurité de 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

Un exemple de message d’état de configuration est illustré ci-dessous :

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

Notes

Il existe un bogue dans le système où les ressources de l’interface réseau pour la carte réseau de la machine virtuelle SLB Mux Transit 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 de la ressource de carte réseau de machine virtuelle est définie sur une adresse IP du pool 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 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
Unknown 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 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 la plomberie des adresses PA sur 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. Collecter les journaux.
PolicyConfigurationFailure Échec lors de l’envoi de stratégies aux hôtes, en raison d’échecs de communication ou d’autres erreurs dans NetworkController. Pas d’actions précises. Cela est dû à l’échec du traitement de l’état de l’objectif dans les modules du contrôleur de réseau. Collecter 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érifiez que la clé de Registre HostID correspond à l’ID d’instance de la ressource de serveur
MultipleVfpEnabledSwitches Plusieurs commutateurs VFp sont 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 commutateur virtuel avec l’extension VFP activée
PolicyConfigurationFailure Échec de l’envoi de stratégies de réseau virtuel pour une carte réseau 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 carte réseau 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 (push) de stratégies de pare-feu pour un VmNic en raison d’erreurs de certificat ou 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 hôte Erreur de pile TCPIP. Peut nécessiter le nettoyage des cartes réseau réseau de l’hôte pa et de la 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 carte réseau de machine virtuelle Vérifiez 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 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 ne peut pas être appairé correctement. Vérifiez les paramètres BGP sur les deux logiciels Load Balancer ressource multiplexeur et pair 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 (exécution automatique) pour des raisons pour lesquelles, dans le cas où SLBM (NC) a rejeté le certificat présenté par l’état d’exécution de l’agent hôte affiche des informations nuances
PortBlocked Le port VFP est bloqué, en raison d’un manque de stratégies de réseau virtuel /ACL Vérifiez s’il existe d’autres erreurs, ce qui peut entraîner la 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 l’expérience utilisateur 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 Vérifiez 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 commande netstat ci-dessous pour vérifier qu’il existe trois connexions ÉTABLIES entre l’agent hôte NC et le ou les nœuds du contrôleur de réseau et un socket LISTENING sur l’hôte Hyper-V

  • LISTENING on port TCP:6640 on Hyper-V Host (NC Host Agent Service)
  • 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

Notes

Il se peut qu’il n’y ait que deux connexions établies sur un hôte Hyper-V s’il n’y a pas de machines virtuelles de locataire déployées 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 d’agent hôte

Le contrôleur de réseau communique avec deux services d’agent hôte sur les ordinateurs hôtes Hyper-V : agent hôte SLB et agent hôte NC. Il est possible qu’un ou les deux services 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 connexions ESTABLISHED ou si le contrôleur de réseau ne répond pas, vérifiez 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 de contrôleur de réseau sont les suivants :

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

Check that ReplicaStatus is **Ready** and HealthState is **Ok**.

In a production deployment is with a multi-node Network Controller, you can also check which node each service is primary on and its individual replica status.

```powershell
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 hostID 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 commandes suivantes pour vérifier que l’HostID 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 de 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, rajoutez 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 de réseau sont identiques. Vérifiez également que le certificat REST du contrôleur de réseau a le nom d’objet CN=<FQDN ou 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 vérifier les paramètres suivants de chaque certificat pour vous assurer que le nom de l’objet est ce qui est attendu (nom d’hôte ou nom de domaine complet REST NC), 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 sujet
  • Date d'expiration
  • Approuvé par l’autorité racine

Assainissement 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 choisit de façon aléatoire une pour 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 de serveur correspondante dans VMM. Ensuite, recréez la ressource de 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 commande Debug-NetworkController. 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.

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

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

Notes

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 d’état de configuration SLB se trouvent dans le fichier diagnostics-slbstateResults.Json de ce répertoire.

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

  • Structure
    • SlbmVips : cette section répertorie l’adresse IP de l’adresse IP virtuelle du gestionnaire SLB, qui est utilisée par le contrôleur de réseau pour coordonner la configuration et l’intégrité entre les Muxes SLB et les agents hôtes SLB.
    • MuxState - Cette section répertorie une valeur pour chaque Mux SLB déployée en donnant l’état du mux
    • Configuration du routeur : cette section répertorie le numéro de système autonome (ASN) du routeur en amont, l’adresse IP de transit et l’ID. Il répertorie également l’asn et l’adresse IP de transit SLB Muxes.
    • 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 de pools d’adresses IP ip virtuelles publiques et privées. L’adresse IP virtuelle SGBD 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ée contenant toutes les annonces de routage pour ce mux particulier.
  • Locataire
    • VipConsolidatedState : cette section répertorie l’état de connectivité de chaque adresse IP virtuelle de locataire, y compris le préfixe de routage annoncé, l’hôte Hyper-V et les points de terminaison DIP.

Notes

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

Validation de la passerelle

À partir du contrôleur de réseau :

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

À partir de la machine virtuelle de passerelle :

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

À partir du commutateur Top of 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, nous avons vu jusqu’à présent (en particulier sur les déploiements basés sur SDNExpress), la raison la plus courante pour le compartiment client qui n’est pas configuré sur les machines virtuelles GW semble être le fait que la capacité GW dans FabricConfig.psd1 est moins comparée à ce que les gens essaient d’attribuer aux connexions réseau (tunnels S2S) dans TenantConfig.psd1. Cela peut être vérifié facilement en comparant les sorties des commandes 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ôte] Valider Data-Plane

Une fois le contrôleur de réseau déployé, les réseaux virtuels de locataire et les sous-réseaux ont été créés et les machines virtuelles ont été attachées aux sous-réseaux virtuels, des tests de niveau infrastructure supplémentaires peuvent être effectués par l’hôte pour vérifier 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 client, 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 quelles 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 sont affectées aux cartes Ethernet créées dans un compartiment réseau TCPIP distinct et ont un nom de carte de VLANX où X est le 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 test ping avec un paramètre de compartiment supplémentaire (-c Y) où Y est le compartiment réseau TCPIP dans lequel les PAhostVNICs sont créés. 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> ...

Notes

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

Par exemple, supposons que les hôtes Hyper-V 1 et 2 disposent d’adresses IP du fournisseur HNV (PA) :

Ordinateur hôte Hyper-V Adresse IP pa 1 Adresse IP pa 2
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 vérifier la 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, vérifiez votre connectivité réseau physique, y compris la configuration du réseau 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 réseau virtuelle hôte de gestion doit être isolée du réseau 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 images 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 la carte Ethernet n’ont pas suffisamment de MTU configuré pour gérer la surcharge à partir de l’encapsulation VXLAN (ou NVGRE).

Notes

Certaines cartes Et pilotes Ethernet prennent en charge le nouveau mot clé *EncapOverhead qui sera automatiquement défini par l’Agent hôte du contrôleur de réseau sur une valeur de 160. Cette valeur sera ensuite ajoutée à la valeur du mot clé *JumboPacket dont la somme est utilisée comme MTU annoncé. 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 taille MTU supérieure de bout en bout, utilisez l’applet de commande Test-LogicalNetworkSupportsJumboPacket :

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

Correction

  • Ajustez la taille MTU sur les ports de commutateur physique pour qu’ils soient au moins 1674B (y compris 14B en-tête et bande-annonce Ethernet)
  • Si votre carte de carte de carte réseau ne prend pas en charge le mot clé EncapOverhead, ajustez le mot clé JumboPacket sur au moins 1674B

Vérifier la connectivité de la carte réseau de machine virtuelle du locataire

Chaque carte réseau de machine virtuelle affectée à une machine virtuelle invitée dispose d’un mappage d’autorité de certification entre l’adresse client privée (CA) et l’espace d’adressage du fournisseur HNV (PA). Ces mappages sont conservés dans les tables de serveur OVSDB sur chaque hôte Hyper-V et sont disponibles 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

Notes

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

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

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

Les sections suivantes fournissent des conseils pour résoudre des problèmes spécifiques.

Aucune connectivité réseau entre deux machines virtuelles clientes

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

Notes

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 commande Get-PACAMapping .

Exemple

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

Créez une autorité de certification ping entre « Machine virtuelle web verte 1 » avec l’adresse IP SenderCA de 192.168.1.4 sur l’hôte « sa18n30-2.sa18.nttest.microsoft.com » avec l’adresse IP Mgmt de 10.127.132.153 vers l’ip listenerCA de 192.168.1.5 attachée 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> ...
  1. [Locataire] Vérifiez qu’il n’existe aucune stratégie de pare-feu distribuée spécifiée sur le sous-réseau virtuel ou les interfaces réseau de machines virtuelles qui bloquent le trafic.

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

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

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

  1. [Hôte] Exécuter Get-ProviderAddress sur les deux hôtes Hyper-V hébergeant les deux machines virtuelles client 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ôte] Vérifiez 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 tous les hôtes Hyper-V en question. Vérifiez également que tous les commutateurs de couche 2 entre eux ont défini sur 1674 octets au moins pour tenir compte d’une surcharge maximale de 160 octets.
  3. [Hôte] Si les adresses IP pa ne sont pas présentes et/ou si la connectivité de l’autorité de certification est interrompue, vérifiez 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ôte] Vérifiez que l’agent hôte du contrôleur de réseau est connecté au contrôleur de réseau. Exécuter netstat -anp tcp |findstr 6640 pour voir si
  5. [Hôte] Vérifiez que l’ID d’hôte dans HKLM/ correspond à l’ID d’instance des ressources serveur hébergeant les machines virtuelles clientes.
  6. [Hôte] 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és, 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 collection 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 logicielle (SLB) et machines de passerelle.

Ces journaux incluent des journaux de débogage pour le cluster Contrôleur de réseau, l’application du contrôleur de réseau, les journaux de passerelle, SLB, 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 machines. 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 machines.

Activation de la journalisation

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

Les journaux de cluster du contrôleur de réseau sont stockés à l’emplacement %programData%\Windows Fabric\log\Traces. Vous pouvez spécifier un emplacement centralisé pour la collection de journaux avec le paramètre DiagnosticLogLocation 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 paramètre LogLocationCredential . Si vous fournissez les informations d’identification pour accéder à l’emplacement du journal, vous devez également fournir le paramètre CredentialEncryptionCertificate , 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 (s’il n’utilise pas d’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 du journal centralisé. 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.
  • Passez à 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 des exigences d’espace disque volumineux).
  • Étendue de journalisation. Par défaut, tous les journaux sont collectés. Vous pouvez modifier l’étendue pour collecter uniquement les journaux de cluster du contrôleur de réseau.
  • Niveau de journalisation. Le niveau de journalisation par défaut est Informational. Vous pouvez le modifier en erreur, avertissement ou détaillé.
  • Temps de vieillissement des journaux. Les journaux sont stockés de manière circulaire. Vous avez trois jours de journalisation par défaut, que vous utilisiez la journalisation locale ou la journalisation centralisée. Vous pouvez modifier cette limite de temps avec le paramètre LogTimeLimitInDays .
  • Taille du vieillissement des journaux. Par défaut, vous disposez d’un maximum de 75 Go de données de journalisation si vous utilisez la journalisation centralisée et 25 Go si vous utilisez la journalisation locale. Vous pouvez modifier cette limite avec le paramètre LogSizeLimitInMBs .

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 du partage de fichiers pour ces journaux est spécifié lors du déploiement du modèle de service contrôleur de réseau.

Si un emplacement de fichier n’a pas été spécifié, la journalisation locale est utilisée sur chaque nœud du contrôleur de réseau avec des 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. Service Fabric journaux peuvent être requis lors de la résolution de certains problèmes. Ces journaux sont disponibles 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 de commande Debug-NetworkController , d’autres journaux seront 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

SLB Diagnostics

Erreurs SLBM Fabric (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 avec 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 contrôleur de réseau (de préférence le nœud de contrôleur de réseau principal - Get-NetworkControllerReplica) :
    1. Le moteur Load Balancer (LB) est-il connecté à SLBM ? (Configurations LBEngine SLBM total> 0)
    2. SGBD connaît-il au moins ses propres points de terminaison ? (Total >des points de terminaison VIP = 2)
    3. Les hôtes Hyper-V (DIP) sont-ils connectés à SLBM ? (Clients HP connectés == serveurs num)
    4. SGBS est-il connecté à Muxes ? (Muxes connectés == Muxes healthy on SLBM == Muxes signalant sain = # SLB Muxes machines virtuelles).
  3. Vérifiez que le routeur BGP configuré est correctement appairé avec l’expérience MUX SLB
    1. Si vous utilisez RRAS avec l’accès à distance (autrement dit, machine virtuelle BGP) :
      1. Get-BgpPeer doit afficher connecté
      2. Get-BgpRouteInformation doit afficher au moins un itinéraire pour l’adresse IP virtuelle auto-SGB
    2. Si vous utilisez le commutateur Top-of-Rack (ToR) physique en tant que pair BGP, consultez votre documentation
      1. Par exemple : # show bgp instance
  4. Valider les compteurs SlbMuxPerfCounters et SLBMUX dans PerfMon sur la machine virtuelle SLB Mux
  5. Vérifier l’état de configuration et les plages d’adresses IP virtuelles dans la ressource Software Load Balancer Manager
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://< FQDN ou IP>| convertto-json -depth 8 (vérifiez les plages d’adresses IP virtuelles dans les pools IP et vérifiez que les adresses IP virtuelles SGB (LoadBalanacerManagerIPAddress) et les adresses IP virtuelles accessibles par le locataire se trouvent dans ces plages)
      1. Get-NetworkControllerIpPool -NetworkId «< ID> de ressource de réseau logique ip ip virtuelle publique/privée » -SubnetId «< ID> de ressource de sous-réseau logique IP/privé » -ResourceId «< ID> de ressource du pool IP » -ConnectionUri $uri |convertto-json -depth 8
    2. Debug-NetworkControllerConfigurationState -

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

Assainissement En fonction des informations de diagnostic suivantes présentées, corrigez les éléments 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érifiez 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 de serveur (annexe de référence pour le code d’erreur HostNotConnected )
  • Collecter les journaux d’activité

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

  1. [Hôte] Vérifiez Debug-NetworkControllerConfigurationState pour voir si des ressources LoadBalancer sont dans un état d’erreur. Essayez d’atténuer en suivant le tableau des éléments d’action de l’Annexe.
    1. Vérifier qu’un point de terminaison d’adresse IP virtuelle est présent et que les itinéraires publicitaires
    2. Vérifiez le nombre de points de terminaison DIP découverts pour le point de terminaison d’adresse IP virtuelle
  2. [Locataire] Valider que les ressources Load Balancer sont correctement spécifiées
    1. Valider les points de terminaison DIP inscrits dans SLBM hébergent des machines virtuelles clientes, qui correspondent aux configurations IP du pool d’adresses back-end LoadBalancer
  3. [Hôte] Si les points de terminaison DIP ne sont pas détectés ou connectés :
    1. Vérifier Debug-NetworkControllerConfigurationState
      1. 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 de netstat -anp tcp |findstr 6640)
    2. Vérifier HostId dans nchostagent service regkey (référencer le code d’erreur HostNotConnected dans l’Annexe) correspond à l’ID d’instance de la ressource de serveur correspondante (Get-NCServer |convertto-json -depth 8)
    3. Vérifier l’ID de profil de port pour le port de machine virtuelle correspond à l’ID d’instance de la ressource de carte réseau de machine virtuelle correspondante
  4. [Fournisseur d’hébergement] Collecter les journaux

Suivi SLB Mux

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

  1. Cliquez sur « Afficher les journaux d’activité d’analyse et de débogage » sous le menu Affichage observateur d'événements
  2. Accédez à « Journaux des applications et des services » > Microsoft > Windows > Trace SlbMuxDriver > dans observateur d'événements
  3. Cliquez avec le bouton droit sur celui-ci et sélectionnez « Activer le journal »

Notes

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 d’un hôte Hyper-V qui héberge une machine virtuelle invitée attachée à un réseau virtuel client, vous pouvez collecter une trace VFP pour déterminer où les problèmes peuvent se trouver.

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