VMware NSX Container Plugin 3.1.1 | 4 février 2021 | Build 17559186 Vérifiez régulièrement les ajouts et les mises à jour apportées à ce document.

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

• Nouveautés
• Conditions de compatibilité
• Problèmes résolus
• Problèmes connus

Nouveautés

NSX Container Plugin (NCP) 3.1.1 comprend la nouvelle fonctionnalité suivante :

• Simplification du déploiement et de la gestion de NCP pour les clusters Kubernetes via Operator
• Définition de la condition NetworkUnavaialble du nœud lorsque nsx-node-agent n'est pas disponible sur le nœud (via Operator)
• Activation de la journalisation pour toutes les règles SNAT
• Partitionnement de routeur pour OCP4
• Multidiffusion vers niveau 1 pour un cluster Kubernetes
• Activation du journal d'accès sur le serveur virtuel d'entrée
• Activation du multiplexage TCP sur l'équilibreur de charge
• Prise en charge de l'accès à l'espace via hostPort

Avis d'obsolescence

L'annotation « ncp/whitelist-source-range » sera obsolète dans NCP 3.3. À partir de NCP 3.1.1, vous pouvez utiliser l'annotation « ncp/allowed-source-range » à la place.

Conditions de compatibilité

Produit	Version
Vignette NCP/NSX-T pour Tanzu Application Service (PCF)	3.1.1
NSX-T	3.0.2, 3.1.0, 3.1.1
vSphere	6.7, 7.0
Kubernetes	1.18 (P1), 1.19, 1.20
OpenShift 3	3.11 Remarque : la prise en charge d'OpenShift 3.x sera obsolète dans une version ultérieure.
OpenShift 4	RHCOS 4.5, 4.6
Système d'exploitation de VM sur hôte Kubernetes	Ubuntu 18.04, Ubuntu 20.04 CentOS 7.8, CentOS 7.9, CentOS 8.2 RHEL 7.8, RHEL 7.9, RHEL 8.3 (Remarque : la prise en charge de RHEL pour Kubernetes Vanilla sera obsolète dans une version ultérieure.) Consultez les remarques ci-dessous.
Système d'exploitation de VM sur hôte OpenShift	RHEL 7.7, RHEL 7.8 (Remarque : la prise en charge de RHEL pour Kubernetes Vanilla sera obsolète dans une version ultérieure.)
Tanzu Application Service (Pivotal Cloud Foundry)	Ops Manager 2.7 + PAS 2.7 (LTS) Ops Manager 2.9 + PAS 2.9 Ops Manager 2.10 + PAS 2.10
Tanzu Kubernetes Grid Integrated (TKGI)	1.10

Remarques :

L'installation du module de noyau nsx-ovs sur CentOS/RHEL nécessite une version de noyau spécifique. Les versions du noyau RHEL sont 1127, 1160 et 193, quelle que soit la version de RHEL. Notez que la version du noyau par défaut est 1127 pour RHEL 7.8, 1160 pour RHEL 7.9 et 193 pour RHEL 8.2. Si vous exécutez une version de noyau différente, vous pouvez ignorer l'installation du module de noyau nsx-ovs en définissant « use_nsx_ovs_kernel_module » sur « False » dans la section « nsx_node_agent » dans le mappage de configuration nsx-node-agent.

Pour exécuter le module de noyau nsx-ovs sur RHEL 8.2 (version de noyau 193), vous devez désactiver l'option « Démarrage sécurisé UEFI » sous « Options de démarrage » dans les paramètres de la VM dans vCenter Server.

Prise en charge de la mise à niveau vers cette version :

• NCP 3.1 et toutes les version de NCP 3.0.x

 

Problèmes résolus

• Problème 2671647 : des flux OVS sont perdus lors du redémarrage de la tâche de surveillance pour les démons ovsdb-server et ovs-vswitchd

  Les flux OVS créés par nsx-node-agent sont perdus si la tâche de surveillance des démons openvswitch est redémarrée à l'aide de la commande « monit restart <process-name> »

  Solution : effectuez un redémarrage de nsx-node-agent une fois que les démons openvswitch sont à nouveau dans l'état « En cours d'exécution » à l'aide de la commande « monit restart nsx-node-agent »

• Problème 2674503 : nsx-ncp-bootstrap ne prend pas en charge l'installation des modules de noyau NSX OVS sur CentOS 7.8, 8.1, 8.2 ou RHEL 7.8, 8.1, 8.2

  Le conteneur nsx-ncp-bootstrap ne prend pas en charge l'installation de modules de noyau NSX OVS sur CentOS 7.8, 8.1, 8.2 ou RHEL 7.8, 8.1, 8.2.

  Solution : définissez use_nsx_ovs_kernel_module sur False dans le ConfigMap de l'agent de nœud NSX et utilisez le module Linux de noyau OVS en amont.

Problèmes connus

• Problème 2131494 : NGINX Kubernetes Ingress fonctionne toujours après la redéfinition de la classe Ingress nginx sur nsx

  Lorsque vous créez un objet NGINX Kubernetes Ingress, NGINX crée des règles de transfert du trafic. Si vous redéfinissez la classe Ingress sur une autre valeur, NGINX ne supprime pas les règles et continue à les appliquer, même si vous supprimez l'objet Kubernetes Ingress après la modification de la classe. Il s'agit d'une limitation de NGINX.

  Solution : pour supprimer les règles créées par NGINX, supprimez l'objet Kubernetes Ingress lorsque la valeur de classe est nginx. Recréez ensuite l'objet Kubernetes Ingress.

• Pour un service Kubernetes de type ClusterIP, l'affinité de session basée sur l'adresse IP du client n'est pas prise en charge

  NCP ne prend pas en charge l'affinité de session basée sur l'adresse IP du client pour un service Kubernetes de type ClusterIP.

  Solution : aucune

• Pour un service Kubernetes de type ClusterIP, l'indicateur de mode épingle n'est pas pris en charge

  NCP ne prend pas en charge l'indicateur de mode épingle pour un service Kubernetes de type ClusterIP.

  Solution : aucune

• Problème 2192489 : après la désactivation de « BOSH DNS server » dans PAS director config, le serveur DNS Bosh (169.254.0.2) figure toujours dans le fichier resolve.conf du conteneur.

  Dans un environnement PAS exécutant PAS 2.2, après que vous désactivez « BOSH DNS server » dans PAS director config, le serveur DNS Bosh (169.254.0.2) figure toujours dans le fichier resove.conf du conteneur. Dans ce cas, l'exécution d'une commande ping avec un nom de domaine complet est très longue. Ce problème n'existe pas avec PAS 2.1.

  Solution : aucune. Il s'agit d'un problème PAS.

• Problème 2224218 : après la suppression d'un service ou d’une application, la libération de l’adresse IP SNAT pour le pool IP dure 2 minutes

  Si vous supprimez un service ou une application et que vous le/la recréez en moins de 2 minutes, il/elle obtiendra une nouvelle IP SNAT du pool IP.

  Solution : après la suppression d'un service ou d’une application, patientez 2 minutes avant de le/la recréer si vous souhaitez réutiliser la même adresse IP.

• Problème 2404302 : si plusieurs profils d'application d'équilibreur de charge pour le même type de ressource (par exemple, HTTP) existent sur NSX-T, NCP choisira l'un d'entre eux à attacher aux serveurs virtuels.

  Si plusieurs profils d'application d'équilibreur de charge HTTP existent sur NSX-T, NCP choisira l'un d'entre eux avec la configuration x_forwarded_for appropriée à attacher au serveur virtuel HTTP et HTTPS. Si plusieurs profils d'application FastTCP et UDP existent sur NSX-T, NCP choisira l'un d'entre eux à attacher respectivement aux serveurs virtuels TCP et UDP. Les profils d'application d'équilibreur de charge peuvent avoir été créés par différentes applications avec des paramètres différents. Si NCP choisit d'attacher l'un de ces profils d'application d'équilibreur de charge aux serveurs virtuels créés par NCP, il peut interrompre le workflow d'autres applications.

  Solution : aucune

• Problème 2397621 : échec de l'installation d'OpenShift 3

  L'installation d'OpenShift 3 attend que l'état d'un nœud soit prêt, ce qui est possible après l'installation du plug-in CNI. Dans cette version, il n'existe pas de fichier de plug-in CNI distinct, ce qui provoque l'échec de l'installation d'OpenShift.

  Solution : créez le répertoire /etc/cni/net.d sur chaque nœud avant de démarrer l'installation.

• Problème 2413383 : la mise à niveau d'OpenShift 3 échoue, car tous les nœuds ne sont pas prêts

  Par défaut, l'espace de démarrage NCP n'est pas planifié sur le nœud maître. Par conséquent, l'état du nœud maître est toujours Non prêt.

  Solution : attribuez au nœud maître le rôle « calcul » pour permettre aux DaemonSets nsx-ncp-bootstrap et nsx-node-agent de créer des espaces. L'état du nœud passe à « Prêt » une fois que nsx-ncp-bootstrap a installé NSX-CNI.

• Problème 2451442 : après le redémarrage répété de NCP et la recréation d'un espace de noms, NCP peut ne pas allouer d'adresses IP à des espaces

  Si vous supprimez et recréez plusieurs fois le même espace de noms lors du redémarrage de NCP, celui-ci peut ne pas allouer d'adresses IP à des espaces dans cet espace de noms.

  Solution : supprimez toutes les ressources NSX périmées (routeurs logiques, commutateurs logiques et ports logiques) associées à l'espace de noms, puis recréez-les.

• Problème 2460219 : la redirection HTTP ne fonctionne pas sans un pool de serveurs par défaut

  Si le serveur virtuel HTTP n'est pas lié à un pool de serveurs, la redirection HTTP échoue. Ce problème se produit dans NSX-T 2.5.0 et versions antérieures.

  Solution : créez un pool de serveurs par défaut ou effectuez une mise à niveau vers NSX-T 2.5.1.

• Problème 2518111 : NCP ne parvient pas à supprimer des ressources NSX-T qui ont été mises à jour à partir de NSX-T

  NCP crée des ressources NSX-T en fonction des configurations que vous spécifiez. Si vous effectuez des mises à jour de ces ressources NSX-T via NSX Manager ou l'API NSX-T, NCP peut ne pas parvenir à supprimer ces ressources et les recréer lorsque cela est nécessaire.

  Solution : ne mettez pas à jour des ressources NSX-T créées par NCP via NSX Manager ou l'API NSX-T.

• Problème 2524778 : NSX Manager indique que NCP est inactif ou défectueux après la suppression du nœud master NCP

  Après la suppression d'un nœud master NCP, par exemple, après un basculement réussi vers un nœud de sauvegarde, l'état de santé de NCP indique toujours inactif alors qu'il devrait être actif.

  Solution : utilisez l'API Gestionnaire DELETE /api/v1/systemhealth/container-cluster/<cluster-id>/ncp/status pour effacer manuellement l'état obsolète.

• Problème 2517201 : impossible de créer un espace sur un hôte ESXi

  Après la suppression d'un hôte ESXi d'un cluster vSphere et son rajout au cluster, la création d'un espace sur l'hôte échoue.

  Solution : redémarrez NCP.

• Problème 2416376 : NCP ne parvient pas à traiter un PAS ASG (groupe de sécurité d'application) qui se lie à plus de 128 espaces

  En raison d'une limite dans le pare-feu distribué de NSX-T, NCP ne peut pas traiter un PAS ASG qui se lie à plus de 128 espaces.

  Solution : créez plusieurs ASG et liez chacun d'eux à 128 espaces au maximum.

• Problème 2534726 : si la mise à niveau vers NCP 3.0.1 via NSX-T Tile échoue, l'utilisation de la ligne de commande BOSH pour rétablir la mise à niveau entraîne des problèmes de performances

  Lors de la mise à niveau vers NCP 3.0.1 via NSX-T Tile sur OpsMgr, le processus de mise à niveau marquera les profils de commutation HA dans NSX Manager utilisés par NCP comme étant inactifs. Les profils de commutation seront supprimés lors du redémarrage de NCP. Si la mise à niveau échoue et que vous utilisez une commande BOSH telle que « bosh deploy -d <deployment-id> -n <deployment>.yml » pour rétablir la mise à niveau, les profils de commutation HA ne seront pas supprimés. NCP continuera à s'exécuter mais les performances seront dégradées.

  Solution : mettez toujours à niveau NCP via OpsMgr et non par la ligne de commande BOSH.

• Problème 2537221 : après la mise à niveau de NSX-T vers 3.0, l'état de la mise en réseau des objets liés au conteneur dans l'interface utilisateur de NSX Manager est indiqué comme Inconnu

  Dans l'interface utilisateur de NSX Manager, l'onglet Inventaire > Conteneurs affiche les objets liés au conteneur et leur état. Dans un environnement PKS, après la mise à niveau de NSX-T vers 3.0, l'état de la mise en réseau des objets liés au conteneur est indiqué comme Inconnu. Ce problème est dû au fait que PKS ne détecte pas le changement de version de NSX-T. Ce problème ne se produit pas si NCP s'exécute en tant qu'espace et que la sonde de réactivité est active.

  Solution : après la mise à niveau de NSX-T, redémarrez progressivement les instances NCP (pas plus de 10 en même temps) afin de ne pas surcharger NSX Manager.

• Problème 2550474 : dans un environnement OpenShift, la modification d'une route HTTPS vers HTTP peut entraîner un dysfonctionnement de la route HTTP

  Si vous modifiez une route HTTPS et que vous supprimez les données liées à TLS pour la convertir en route HTTP, il se peut que la route HTTP ne fonctionne pas comme prévu.

  Solution : supprimez la route HTTPS et créez une nouvelle route HTTP.

• Problème 2552573 : dans un environnement OpenShift 4.3, l'installation du cluster peut échouer si le protocole DHCP est configuré à l'aide de l'interface utilisateur de Stratégie

  Dans un environnement OpenShift 4.3, l'installation du cluster requiert qu'un serveur DHCP soit disponible pour fournir des adresses IP et des informations DNS. Si vous utilisez le serveur DHCP configuré dans NSX-T à l'aide de l'interface utilisateur de Stratégie, l'installation du cluster peut échouer.

  Solution : configurez un serveur DHCP à l'aide de l'interface utilisateur de Gestionnaire, supprimez le cluster qui n'a pas pu être installé et recréez-le.

• Problème 2552564 : dans un environnement OpenShift 4.3, le redirecteur DNS peut cesser de fonctionner en cas de chevauchement d'adresse

  Dans un environnement OpenShift 4.3, l'installation du cluster nécessite la configuration d'un serveur DNS. Si vous utilisez NSX-T pour configurer un redirecteur DNS et que l'adresse IP chevauche le service DNS, le redirecteur DNS cessera de fonctionner et l'installation du cluster échouera.

  Solution : configurez un service DNS externe, supprimez le cluster qui n'a pas pu être installé et recréez-le.

• Problème 2483242 : trafic IPv6 des conteneurs bloqué par NSX-T SpoofGuard

  L'adresse locale de lien IPv6 n'est pas mise automatiquement sur liste blanche lorsque SpooGuard est activé.

  Solution : désactivez SpoofGuard en définissant nsx_v3.enable_spoofguard = False dans la configuration NCP.

• Problème 2552609 : données X-Forwarded-For (XFF) et X-Forwarded-Port incorrectes

  Si vous configurez XFF avec INSERT ou REPLACE pour les règles d'entrée HTTPS (Kubernetes) ou les routes HTTPS (OpenShift), vous pouvez voir des valeurs X-Forwarded-For et X-Forwarded-Port incorrectes dans les en-têtes XFF.

  Solution : aucune.

• Problème 2555336 : le trafic d'espaces ne fonctionne pas en raison de ports logiques en double créés en mode Gestionnaire

  Ce problème est plus susceptible de se produire lorsqu'il existe de nombreux espaces dans plusieurs clusters. Lorsque vous créez un espace, le trafic vers l'espace ne fonctionne pas. NSX-T affiche plusieurs ports logiques créés pour le même conteneur. Dans le journal NCP, seul l'ID de l'un des ports logiques est disponible. 

  Solution : supprimez l'espace et recréez-le. Les ports obsolètes sur NSX-T seront supprimés lors du redémarrage de NCP.

• Problème 2554357 : la mise à l'échelle automatique de l'équilibrage de charge ne fonctionne pas pour IPv6

  Dans un environnement IPv6, un service Kubernetes de type LoadBalancer ne sera pas actif lorsque l'échelle d'équilibreur de charge existante sera atteinte.

  Solution : définissez nsx_v3.lb_segment_subnet = FE80::/10 dans /var/vcap/jobs/ncp/config/ncp.ini pour les déploiements PKS et dans nsx-ncp-configmap pour les autres. Puis redémarrez NCP.

• Problème 2597423 : lors de l'importation d'objets de gestionnaire dans la stratégie, une restauration entraîne la perte des balises de certaines ressources

  Lors de l'importation d'objets de gestionnaire dans la stratégie, si une restauration est nécessaire, les balises des objets suivants ne seront pas restaurées :

  • Profils Spoofguard (partie des ressources partagées et de cluster)
  • BgpneighbourConfig (partie des ressources partagées)
  • BgpRoutingConfig (partie des ressources partagées)
  • StaticRoute BfdPeer (partie des ressources partagées)

  Solution : pour les ressources qui font partie des ressources partagées, restaurez manuellement les balises. Utilisez la fonctionnalité de sauvegarde et de restauration pour restaurer les ressources qui font partie des ressources du cluster.

• Problème 2579968 : lorsque des modifications sont apportées aux services Kubernetes de type LoadBalancer à une fréquence élevée, certains serveurs virtuels et pools de serveurs ne sont pas supprimés comme prévu

  Lorsque des modifications sont apportées aux services Kubernetes de type LoadBalancer à une fréquence élevée, certains serveurs virtuels et pools de serveurs peuvent rester dans l'environnement NSX-T lorsqu'ils doivent être supprimés.

  Solution : redémarrez NCP. Vous pouvez également supprimer manuellement les serveurs virtuels périmés et les ressources qui leur sont associées. Un serveur virtuel est périmé si aucun service Kubernetes de type LoadBalancer n'a l'identifiant du serveur virtuel dans la balise external_id.

• Problème 2536383 : après la mise à niveau de NSX-T vers 3.0 ou version ultérieure, l'interface utilisateur de NSX-T n'affiche pas correctement les informations liées à NCP

  Après la mise à niveau de NSX-T vers 3.0 ou version ultérieure, l'onglet Inventaire > Conteneurs dans l'interface utilisateur de NSX-T indique que l'état de mise en réseau des objets liés au conteneur est inconnu. De plus, les clusters NCP ne s'affichent pas dans l'onglet Système > Infrastructure > Nœuds > Clusters NCP. Ce problème se produit généralement dans un environnement PKS.

  Solution : après la mise à niveau de NSX-T, redémarrez progressivement les instances NCP (pas plus de 10 en même temps).

• Problème 2622099 : le service Kubernetes de type Initialisation LoadBalancer échoue avec le code d'erreur NCP00113 et le message d'erreur « L'objet a été modifié par un autre utilisateur »

  Dans un déploiement à un seul niveau avec une API de stratégie, si vous utilisez une passerelle de niveau 1 existante comme passerelle de niveau supérieur et que la taille d'allocation de pool de la passerelle est le ROUTAGE, un service Kubernetes de type LoadBalancer peut ne pas parvenir à s'initialiser avec le code d'erreur NCP00113 et le message d'erreur «L'objet a été modifié par un autre utilisateur. Veuillez réessayer.»

  Solution : lorsque le problème apparaît, patientez 5 minutes. Puis redémarrez NCP. Le problème sera résolu.

• Problème 2633679 : NCP Operator ne prend pas en charge les nœuds OpenShift attachés à un segment de niveau 1 créé à l'aide de l'API /policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id>

  NCP Operator ne prend pas en charge les nœuds OpenShift attachés à un segment de niveau 1 créé à l'aide de l'API /policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id>.

  Solution : utilisez l'API /policy/api/v1/infra/segments/<segment-id> pour créer le segment.

• NCP ne parvient pas à démarrer lorsque l'option « Connexion au fichier » est activée lors de l'installation de Kubernetes

  Ce problème se produit lorsque uid:gid=1000:1000 sur l'hôte de conteneur n'est pas autorisé à accéder au dossier du journal.

  Solution : utilisez l'une des méthodes suivantes :

  • Modifiez le mode du dossier de journaux sur 777 sur les hôtes de conteneur.
  • Accordez l'autorisation « rwx » du dossier de journaux à uid:gid=1000:1000 sur les hôtes de conteneur.
  • Désactivez la fonctionnalité « Journalisation dans le fichier ».
• Problème 2653214 : erreur lors de la recherche du port de segment pour un nœud après la modification de l'adresse IP du nœud

  Après la modification de l'adresse IP d'un nœud, si vous mettez à niveau NCP ou si l'espace de NCP Operator est redémarré, la vérification de l'état de NCP Operator à l'aide de la commande « oc describe co nsx-ncp » affiche le message d'erreur « Erreur lors de la recherche du port de segment pour le nœud ... »

  Solution : aucune. L'ajout d'une adresse IP statique sur une interface de nœud qui a également la configuration DHCP n'est pas pris en charge.

• Problème 2664457 : lors de l'utilisation de DHCP dans OpenShift, la connectivité peut être temporairement perdue lorsque nsx-node-agent démarre ou redémarre

  nsx-ovs crée et active 5 profils de connexion temporaires pour configurer ovs_bridge mais leur activation peut échouer temporairement dans NetworkManager. Ainsi, aucune adresse IP (connectivité) n'est présente sur la machine virtuelle sur ovs_uplink_port et/ou ovs_bridge.

  Solution : Redémarrez la VM ou attendez que NetworkManager active tous les profils.

• Problème 2672677 : un nœud peut cesser de répondre dans un environnement OpenShift 4 fortement contraint

  Dans un environnement OpenShift 4 présentant un niveau élevé de densité d'espace par nœud et une fréquence élevée d'espaces supprimés et créés, il est possible qu'un nœud RHCOS passe à l'état « Non prêt ». Les espaces exécutés sur le nœud affecté, à l'exception des membres daemonset, seront supprimés et recréés sur d'autres nœuds de l'environnement.

  Solution : redémarrez le nœud impacté.

• Problème 2706551 : l'installation automatisée de pile complète d'OpenShift (appelée IPI) échoue, car les nœuds ne sont plus prêts pendant l'installation

  L'espace de survie ajoute le VIP Kubernetes au ovs_bridge sur les nœuds maîtres avant que le serveur d'API Kubernetes ne commence à s'exécuter. Par conséquent, toutes les demandes au serveur d'API Kubernetes échouent et l'installation ne peut pas se terminer.

  Solution : aucune

• Problème 2707883 : nsx-ncp-operator ne crée pas de ressource Kubernetes liée à NCP si la ressource a été supprimée lorsque nsx-ncp-operator n'était pas en cours d'exécution

  Par exemple, si vous supprimez nsx-node-agent ou nsx-ncp-bootstrap DaemonSet lorsque nsx-ncp-operator n'est pas en cours d'exécution, il n'est pas recréé lorsque nsx-ncp-operator est à nouveau en cours d'exécution.

  Solution : mettez à jour n'importe quel champ dans nsx-ncp-operator ConfigMap, par exemple, log_level dans la section [Default], lorsque nsx-ncp-operator est à nouveau en cours d'exécution.

• Problème 2697547 : HostPort non pris en charge sur les nœuds RHEL/CentOS/RHCOS

  Vous pouvez spécifier des hostPorts sur Kubernetes et PKS natifs sur des nœuds Ubuntu en spécifiant « enable_hostport_snat » sur True dans nsx-node-agent ConfigMap. Cependant, sur les nœuds RHEL/CentOS/RHCOS hostPort n'est pas pris en charge et le paramètre « enable_hostport_snat » est ignoré.

  Solution : aucune

• Problème 2707174 : un espace supprimé et recréé avec le même espace de noms et le même nom n'a pas de connectivité réseau

  Si un espace est supprimé et recréé avec les mêmes espace de noms et nom lorsque NCP n'est pas en cours d'exécution et que nsx-ncp-agents sont en cours d'exécution, l'espace peut obtenir des configurations réseau erronées et ne pas pouvoir accéder au réseau.

  Solution : supprimez l'espace et recréez-le lorsque NCP est en cours d'exécution.

• Problème 2713782 : les appels NSX API échouent avec l'erreur « SSL : DECRYPTION_FAILED_OR_BAD_RECORD_MAC »

  Parfois, au démarrage de NCP, ce dernier peut redémarrer ou ne pas initialiser les services d'équilibreur de charge. En outre, lorsque NCP est en cours d'exécution, un point de terminaison NSX peut être signalé comme étant INACTIF pendant une courte période (moins d'une seconde). Si l'initialisation de l'équilibreur de charge échoue, le journal NCP indiquera le message « Échec de l'initialisation des services d'équilibreur de charge ».

  Solution : augmentez la valeur du paramètre nsx_v3.conn_idle_timeout. Notez que cela peut entraîner un temps d'attente plus long pour que les points de terminaison soient détectés comme étant disponibles après une déconnexion temporaire lors de l'utilisation de l'équilibreur de charge côté client.

• Problème 3033821 : après la migration Gestionnaire vers Stratégie, les règles de pare-feu distribué ne sont pas appliquées correctement

  Après une migration Gestionnaire vers Stratégie, les règles de pare-feu distribué (DFW) liées aux stratégies réseau récemment créées auront une priorité plus élevée que les règles DFW migrées.

  Solution : utilisez l'API de stratégie pour modifier la séquence de règles DFW si nécessaire.