VMware NSX 4.1.0 | 28 février 2023 | Build 21332672

Vérifiez les compléments et les mises à jour de ces notes de mise à jour.

Nouveautés

NSX 4.1.0 inclut un grand nombre de nouvelles fonctionnalités destinées à la virtualisation de la mise en réseau et de la sécurité pour les clouds privés, publics et multiples. Parmi celles-ci, mentionnons de nouvelles fonctionnalités et améliorations dans les domaines suivants :

  • Prise en charge d'IPv6 pour la communication des plans de contrôle et de gestion internes de NSX : cette version introduit la prise en charge de la communication de plan de contrôle et de plan de gestion entre les nœuds de transport et les instances de NSX Manager sur IPv6. Dans cette version, le cluster de NSX Manager doit toujours être déployé en mode double pile (IPv4 et IPv6) et pourra communiquer avec les nœuds de transport (hôtes ESXi et nœuds Edge) sur IPv4 ou IPv6. Lorsque le nœud de transport est configuré avec une double pile (IPv4 et IPv6), les communications sur IPv6 sont toujours préférées.

  • Locataires multiples disponibles dans l'interface utilisateur, l'API et l'infrastructure d'alarme : cette version étend le modèle de consommation de NSX en introduisant la prise en charge de locataires multiples, permettant ainsi à plusieurs utilisateurs dans NSX de consommer leurs propres objets, de voir leurs propres alarmes et de surveiller leurs machines virtuelles avec Traceflow. Cela est possible via la capacité de l'administrateur d'entreprise de segmenter la plate-forme en projets, en donnant différents espaces à différents utilisateurs tout en maintenant la visibilité et le contrôle.

  • Améliorations apportées à l'intégration entre Antrea et NSX : avec NSX 4.1, vous pouvez créer des règles de pare-feu avec des objets K8s et NSX. Des groupes dynamiques peuvent également être créés en fonction des balises NSX et des étiquettes K8s. Cela améliore la convivialité et la fonctionnalité de l'utilisation de NSX pour gérer les clusters Antrea.

  • Système de diagnostic en ligne : fournit des runbooks prédéfinis qui contiennent des étapes de débogage pour résoudre un problème spécifique. Ces runbooks peuvent être appelés par l'API et déclenchent les étapes de débogage à l'aide de l'interface de ligne de commande, de l'API et des scripts. Les actions recommandées seront fournies après le débogage pour résoudre le problème et les artefacts générés liés au débogage peuvent être téléchargés pour une analyse plus approfondie. Le système de diagnostic en ligne permet d'automatiser le débogage et de simplifier le dépannage. 

Outre ces fonctionnalités, de nombreuses autres capacités ont été ajoutées dans tous les domaines du produit. Vous trouverez plus d'informations ci-dessous dans la description détaillée des fonctionnalités ajoutées.

Mise en réseau de couche 2

  • Haute disponibilité pour plusieurs TEP d'ESXi : lorsque plusieurs TEP sont configurés sur un hyperviseur, NSX effectue le suivi de l'état des adresses IP TEP et des sessions BFD pour basculer le trafic de superposition vers une autre liaison montante. Cette fonctionnalité fournit une haute disponibilité contre les problèmes de commutateur physique, par exemple, lorsqu'un port de commutateur physique est actif, mais que le transfert ne fonctionne pas correctement.

Mise en réseau de couche 3

  • Distance administrative BGP : cette version introduit la prise en charge de la définition de valeurs de distance administrative BGP autres que celles par défaut. La distance administrative est une valeur arbitraire attribuée à chaque protocole de routage et utilisée pour la sélection de route. La possibilité de manipuler la distance administrative des routes BGP fournit un contrôle supplémentaire de sélection des routes.

  • Nombre de systèmes autonomes (AS) BGP par passerelle VRF de niveau 0 et voisin BGP : cette version introduit la prise en charge de la configuration d'un numéro de système autonome (ASN) BGP différent par passerelle VRF de niveau 0 et également par voisin BGP. La définition d'un ASN distinct par VRF et par homologue BGP est une fonctionnalité importante pour les topologies de fournisseur de services et de locataires multiples dans lesquelles les clients finaux apportent leur propre ASN BGP aux topologies de mise en réseau.

  • Routage inter-VRF : cette version introduit un modèle plus avancé d'interconnexion VRF et de fuite de routes. Avec cette fonctionnalité, les utilisateurs peuvent configurer le routage inter-VRF à l'aide de workflows plus faciles et de contrôles précis en important et en exportant dynamiquement des routes entre les VRF.

  • Identifiant BGP autonome à l'échelle du système - RFC6286 : cette version introduit la prise en charge de la définition de l'ID du routeur BGP pour qu'elle soit un entier de 4 octets, non signé et non nul, et assouplit l'exigence d'« unicité » pour les homologues eBGP, conformément à la norme RFC 6286.

  • Prise en charge d'IPv6 pour la communication des plans de contrôle et de gestion internes de NSX : cette version introduit la prise en charge de la communication de plan de contrôle et de plan de gestion entre les nœuds de transport et les instances de NSX Manager sur IPv6. Dans cette version, le cluster NSX Manager doit toujours être déployé en mode double pile (IPv4 et IPv6) et pourra communiquer avec les nœuds de transport (hôtes ESXi et nœuds Edge) sur IPv4 ou IPv6. Lorsque le nœud de transport est configuré avec une double pile (IPv4 et IPv6), les communications sur IPv6 sont toujours préférées.

DPU-based Acceleration (Accélération basée sur DPU)

  • UPT V2 est prêt pour la production pour NVIDIA Bluefield-2.

  • Sécurité

    • NSX Distributed Firewall (pare-feu L2 et L3 avec état) est disponible pour le déploiement de production avec accélération de DPU.

    • NSX Distributed IDS/IPS (Tech Preview)

Plate-forme de nœud Edge

  • Prise en charge des paramètres du nœud Edge dans l'API du nœud de transport

    • L'API de nœud Edge vous permet de définir les paramètres suivants : Priorité de redémarrage (VM du nœud Edge) ; coalescingScheme et coalescingParams. Avec cette fonctionnalité, les clients peuvent régler les paramètres de performances et la priorité de redémarrage via NSX Manager. Cela permet d'assurer la cohérence des paramètres d'objets NSX à exécuter via NSX Manager.

  • Mettre à niveau le système d'exploitation du nœud Edge vers Ubuntu 20.04

    • Le système d'exploitation du nœud Edge a été mis à niveau vers Ubuntu 20.04, ce qui offre une meilleure prise en charge matérielle du dispositif Edge bare metal.

  • Plate-forme Edge : Mise à niveau de la version matérielle

    • Lors de la mise à niveau vers NSX 4.1.0, le système met automatiquement à niveau les machines virtuelles Edge vers la dernière version matérielle prise en charge offrant les meilleures performances.

Détection et réponse du réseau (NDR, Network Detection and Response)

  • Prise en charge des événements IDPS à partir du pare-feu de passerelle : à partir de NSX 4.1.0, les événements IDPS du pare-feu de passerelle/Edge sont utilisés par NDR dans les corrélations et les campagnes d'intrusion.

Mise en réseau et sécurité de conteneur

  • Améliorations de l'intégration entre Antrea et NSX : NSX 4.1.0 vous permet de créer des règles de pare-feu avec des objets K8s et NSX. Des groupes dynamiques peuvent également être créés en fonction des balises NSX et des étiquettes K8s. Cela améliore la convivialité et la fonctionnalité de l'utilisation de NSX pour gérer les clusters Antrea. Vous pouvez désormais créer des stratégies de pare-feu qui autorisent/bloquent le trafic entre les machines virtuelles et les espaces K8s dans une règle unique. Un nouveau point d'application est également introduit pour inclure tous les points de terminaison et l'application correcte est déterminée en fonction des cibles des membres du groupe source et de destination. Les stratégies réseau et les niveaux K8s créés dans le cluster Antrea peuvent désormais être affichés dans l'ensemble de règles de stratégie NSX. Parallèlement à cela, NSX 4.1.0 inclut également des améliorations apportées à Traceflow et à l'interface utilisateur qui permettent de mieux dépanner et gérer les stratégies réseau K8s, ce qui offre une véritable gestion centralisée des stratégies réseau K8s via NSX.

Installation et mise à niveau

  • Récupération rapide suite à des échecs de mise à niveau : l'une des méthodes permettant de récupérer rapidement après un échec d'une mise à niveau NSX consiste à effectuer une restauration vers une sauvegarde. Cependant, l'indisponibilité d'une sauvegarde viable peut parfois retarder ce processus, nécessitant une longue intervention manuelle. Avec NSX 4.1, une sauvegarde automatique de NSX sera effectuée implicitement et stockée sur le dispositif lui-même. Cela signifie qu'en cas d'échec, le support VMware peut restaurer rapidement NSX à un état de fonctionnement à l'aide de cette sauvegarde intégrée. 

Opérations et surveillance

  • Système de diagnostics en ligne : fournit des runbooks prédéfinis, qui contiennent des étapes de débogage pour résoudre un problème spécifique. Ces runbooks peuvent être appelés par l'API et déclenchent les étapes de débogage à l'aide de l'interface de ligne de commande, de l'API et des scripts. Les actions recommandées seront fournies après le débogage pour résoudre le problème et les artefacts générés liés au débogage peuvent être téléchargés pour une analyse plus approfondie. Le système de diagnostic en ligne permet d'automatiser le débogage et de simplifier le dépannage.

Les runbooks prédéfinis suivants sont disponibles pour résoudre des problèmes de nœud de transport de l'hôte ESXi, et peuvent être appelés à l'aide de NSX API.

  • Les runbooks permettent de diagnostiquer les problèmes de tunnel de superposition, de connectivité du contrôleur, de blocage de port et de performances de pNIC.

VPN

  • Prise en charge d'IPv6 pour VPN IPsec : les adresses IPv6 peuvent désormais être utilisées pour la terminaison VPN IPsec, offrant un mécanisme de tunnel sécurisé sur les réseaux IPv6. Sur le VPN IPv6, NSX peut transporter des données IPv4 et IPv6.

Guest Introspection

  • Prise en charge des pilotes GI sur Windows 11 : à partir de NSX 4.1.0, les machines virtuelles exécutant Windows 11 sont prises en charge pour NSX Guest Introspection.

Sécurité de la plate-forme

  • Gestion du cycle de vie des utilisateurs locaux : cette version permet aux clients d'ajouter et de supprimer des utilisateurs locaux du système.

  • Modifications du port sécurisé pour l'installation et la mise à niveau : cette version modifie le port TCP 8080 par défaut pour l'installation et les mises à niveau vers le port TCP 443 afin d'améliorer la sécurité de la plate-forme.

  • Remplacement des certificats internes : cette version permet aux clients de remplacer les certificats internes auto-signés par des certificats signés par une autorité de certification.

Locataires multiples

  • Locataires multiples dans l'interface utilisateur de NSX : NSX 4.1.0 permet la consommation de locataires multiples à partir de l'interface utilisateur pour les administrateurs d'entreprise (fournisseur) et les utilisateurs de projet (locataires). 

    • Vue différente pour différents utilisateurs : les utilisateurs de projet (locataires) et les administrateurs d'entreprise (fournisseurs) peuvent se connecter à NSX et disposer de leur propre vue. Les utilisateurs de projet ne voient pas les autres projets ni les configurations de fournisseur.

    • Sélecteur de projet : cette version introduit une liste déroulante au-dessus de l'interface, qui vous permet de basculer le contexte d'un projet à l'autre en fonction des autorisations RBAC de l'utilisateur. Les configurations effectuées en dehors des projets sont dans le contexte par défaut. Il s'agit de la valeur par défaut pour les rôles configurés en dehors des projets. Les utilisateurs configurés sous Par défaut (/) peuvent afficher et configurer tous les projets mappés avec leurs autorisations RBAC, tandis que les utilisateurs liés à un projet spécifique n'ont accès qu'à leurs propres projets.

  • Écran Tous les projets : outre la possibilité de basculer entre les projets, l'administrateur d'entreprise dispose d'une vue consolidée affichant toutes les configurations sur le système.

  • Gestion du cycle de vie des projets : les projets sont des constructions facultatives destinées à offrir un locataire qui peut être configuré par l'administrateur d'entreprise sur l'instance de NSX.

    • Projet CRUD : capacité de créer les projets à partir de l'interface utilisateur et d'afficher une vue consolidée de tous les projets et de leur état/leurs alarmes.

    • Allocation d'utilisateurs : les utilisateurs et les groupes peuvent être alloués à des projets (par exemple, l'utilisateur « project_admin_1 » est un administrateur de projet pour les projets 1, 2 et 4).

    • Quota : des quotas peuvent être alloués aux différents projets pour limiter par type le nombre de configurations disponibles (par exemple, le projet 1 peut créer 10 segments).

    • Partage d'objets : les objets peuvent être partagés à partir du contexte par défaut (/infra) par l'administrateur d'entreprise vers tous les projets ou des projets spécifiques (par exemple, le groupe « Services partagés » est partagé avec tous les projets).

  • Locataires multiples pour les opérations et la surveillance

    • Journalisation de locataires multiples pour les journaux de sécurité : introduction de l'ID de journal court du projet, qui est une étiquette placée sur les journaux pour les attacher à un projet. Dans cette version, cet ID de journal court s'applique aux journaux du pare-feu de passerelle et aux journaux de pare-feu distribué.

    • Alarmes de locataires multiples : extension de l'infrastructure d'alarme pour prendre en charge les locataires multiples. L'administrateur de projet peut désormais visualiser ses propres alarmes liées à ses propres configurations.

    • Traceflow au niveau du projet : l'administrateur de projet peut utiliser Traceflow afin de tester la connectivité entre ses charges de travail. Les configurations appliquées à son objet en dehors du projet par le fournisseur seront masquées.

  • NSX Manager Platform

    • Mettez à jour le système d'exploitation du dispositif NSX Manager vers Ubuntu 20.04.

      • Le système d'exploitation du dispositif NSX Manager a été mis à niveau vers Ubuntu 20.04.

Obsolescences de fonctionnalité et d'API, et changements de comportement

Annonce d'obsolescence pour l'équilibrage de charge NSX

VMware prévoit de déconseiller l'équilibreur de charge NSX intégré et recommande aux clients de migrer vers NSX Advanced Load Balancer (Avi) dès que possible. VMware NSX Advanced Load Balancer (Avi) fournit un sur-ensemble de la fonctionnalité d'équilibrage de charge NSX et VMware recommande d'acheter VMware NSX Advanced Load Balancer (Avi) Enterprise pour déverrouiller l'équilibrage de charge de niveau entreprise, GSLB, les analyses avancées, l'entrée de conteneur, la sécurité des applications et le WAF.

Nous informons en avance pour permettre aux clients existants qui utilisent l'équilibreur de charge NSX intégré de migrer vers NSX Advanced Load Balancer (Avi). La prise en charge de l'équilibreur de charge NSX intégré pour les clients utilisant NSX-T Data Center 3.x restera pendant la durée de la série NSX-T Data Center 3.x. La prise en charge de l'équilibreur de charge NSX intégré pour les clients utilisant NSX 4.x restera pendant la durée de la série NSX 4.x. Les détails des deux sont décrits dans la matrice de cycle de vie des produits VMware. N'essayez pas de fournir une prise en charge de l'équilibreur de charge NSX intégré au-delà de la dernière version de NSX 4.x.

Plus d'informations :

Avis d'obsolescence pour les API NSX Manager et les interfaces utilisateur avancées NSX

NSX dispose de deux méthodes de configuration de la mise en réseau et de la sécurité logiques : Mode Gestionnaire et mode Stratégie. L'API de gestionnaire contient des URI qui commencent par /api et l'API de stratégie contient des URI qui commencent par /policy/api.

Notez que VMware a l'intention de supprimer la prise en charge des API de NSX Manager et des interfaces utilisateur avancées de NSX dans une prochaine version mineure ou majeure de NSX, qui sera généralement disponible au moins un an après la date de ce message, le 16 décembre 2021. Les API de NSX Manager qui sont prévues pour être supprimées sont marquées comme « obsolètes » dans le Guide des API de NSX Data Center, avec des instructions sur les API de remplacement.

Il est recommandé que les nouveaux déploiements de NSX tirent parti des API de stratégie NSX et des interfaces utilisateur de stratégie NSX. Pour les déploiements qui exploitent actuellement les API de NSX Manager et les interfaces utilisateurs avancées de NSX, veuillez consulter le dispositif NSX Manager pour la page de promotion des objets de Gestionnaire vers Stratégie et le Guide de l'API de NSX-Data Center pour faciliter la transition.

Obsolescences de l'API et changements de comportement

  • De nouvelles pages sur l'obsolescence ou la suppression des API ont été ajoutées au Guide de NSX API pour simplifier la consommation des API. Celles-ci répertorieront les API et les types obsolètes et supprimés.

  • API supprimées : Les API suivantes ont été supprimées. Pour plus d'informations, reportez-vous au Guide de NSX API.

API supprimée

Remplacement

POST /api/v1/intrusion-services/ids-events

 POST /policy/api/v1/infra/settings/firewall/security/intrusion-services/ids-events

POST /api/v1/intrusion-services/ids-summary

POST /policy/api/v1/infra/settings/firewall/security/intrusion-services/ids-summary

POST /api/v1/intrusion-services/affected-vms

POST /policy/api/v1/infra/settings/firewall/security/intrusion-services/affected-vms

POST /api/v1/intrusion-services/affected-users

POST /policy/api/v1/infra/settings/firewall/security/intrusion-services/affected-users

GET /api/v1/intrusion-services/profiles/<profile-id>

GET /policy/api/v1/infra/settings/firewall/security/intrusion-services/profiles/<profile-id>/effective-signatures

  • API déconseillées : les API suivantes sont marquées comme déconseillées. Pour plus d'informations, reportez-vous au Guide de NSX API.

API obsolète

Remplacement

DELETE /api/v1/aaa/registration-token/<token>

POST /api/v1/aaa/registration-token/delete

GET /api/v1/aaa/registration-token/<token>

POST /api/v1/aaa/registration-token/retrieve

GET /api/v1/node/services/dataplane/l3vpn-pmtu

aucune

GET /api/v1/node/services/policy

GET /api/v1/node/services/manager

GET /api/v1/node/services/policy/status

GET /api/v1/node/services/manager/status

GET /api/v1/ns-groups/<ns-group-id>/effective-cloud-native-service-instance-members

GET /policy/api/v1/infra/domains/{domain-id}/groups/{group-id}/members/cloud-native-service-instances

GET /api/v1/ns-groups/<ns-group-id>/effective-directory-group-members

GET /policy/api/v1/infra/domains/{domain-id}/groups/{group-id}/members/identity-groups

GET /api/v1/ns-groups/<ns-group-id>/effective-ipset-members

GET /policy/api/v1/infra/domains/{domain-id}/groups/{group-id}/members/segment-ports

GET /policy/api/v1/infra/domains/{domain-id}/groups/{group-id}/members/logical-ports

GET /api/v1/ns-groups/<ns-group-id>/effective-physical-server-members

GET /policy/api/v1/infra/domains/{domain-id}/groups/{group-id}/members/physical-servers

GET /api/v1/ns-groups/<ns-group-id>/effective-transport-node-members

GET /policy/api/v1/infra/domains/{domain-id}/groups/{group-id}/members/transport-nodes

POST /api/v1/batch

aucune

POST /api/v1/node/services/policy?action=reset-manager-logging-levels

POST /api/v1/node/services/manager?action=reset-manager-logging-levels

POST /api/v1/node/services/policy?action=restart

POST /api/v1/node/services/manager?action=restart

POST /api/v1/node/services/policy?action=start

POST /api/v1/node/services/manager?action=start

POST /api/v1/node/services/policy?action=stop

POST /api/v1/node/services/manager?action=stop

POST /policy/api/v1/infra/realized-state/enforcement-points/<enforcement-point-name>/virtual-machines?action=update_tags

POST /policy/api/v1/infra/realized-state/virtual-machines/{virtual-machine-id}/tags

PUT /api/v1/node/services/dataplane/l3vpn-pmtu

aucune

PUT /api/v1/node/services/policy

PUT /api/v1/node/services/manager

Compatibilité et configuration système requise

Pour obtenir des informations sur la compatibilité et la configuration système requise, reportez-vous aux matrices d'interopérabilité des produits VMware et au Guide d'installation de NSX.

Notes de mise à niveau de cette version

Pour obtenir des instructions sur la mise à niveau des composants NSX, reportez-vous au Guide de mise à niveau de NSX.

  • NSX 4.1.0 est une nouvelle version fournissant un grand nombre de nouvelles fonctionnalités. Les clients qui ont besoin de ces fonctionnalités doivent effectuer une mise à niveau pour pouvoir les adopter. Les clients qui n'ont pas besoin de cette fonctionnalité à ce stade doivent effectuer une mise à niveau vers la dernière version disponible de NSX 3.2 (actuellement, la version 3.2.2), qui continue d'être la version recommandée par VMware.

  • NSX 4.1.0 n'est pas pris en charge pour les clients NSX Cloud déployés avec des charges de travail AWS/Azure. N'utilisez pas NSX 4.1.0 pour mettre à niveau votre environnement dans ce scénario.

Les clients qui effectuent une mise à niveau vers cette version sont encouragés à exécuter l'outil d'évaluation de mise à niveau de NSX avant de démarrer le processus de mise à niveau. L'outil est conçu pour garantir la réussite en vérifiant la santé et la disponibilité de vos instances de NSX Manager avant la mise à niveau. L'outil est intégré au workflow de mise à niveau avant de commencer la mise à niveau des instances de NSX Manager.

Langues disponibles

NSX a été localisé dans plusieurs langues : anglais, allemand, français, japonais, chinois simplifié, coréen, chinois traditionnel, italien et espagnol. Étant donné que la localisation de NSX utilise les paramètres de langue du navigateur, assurez-vous que vos paramètres correspondent à la langue souhaitée.

Historique de révision du document

Date de révision

Édition

Modifications

28 février 2023

1

Édition initiale

29 mars 2023

2

Ajout des problèmes connus 3094405, 3106569, 3113067, 3113073, 3113076, 3113085, 3113093, 3113100, 3118868, 3121377, 3152174 et 3152195.

12 mai 2023

3

Ajout du problème connu 3210316.

19 mai 2023

4

Ajout du problème connu 3116294.

1 juin 2023

5

Ajout des problèmes connus 3186573, 3155845, 3163020.

20 juillet 2023

6

Ajout du problème connu 3108693.

8 septembre 2023

7

Ajout de la mise à niveau de NSX Manager vers Nouveautés.

14 décembre 2023

8

Ajout du problème connu 3296976.

10 janvier 2024

9

Ajout du problème connu 3222376.

7 mars 2024

10

Ajout du problème connu 3308657.

Problèmes résolus

  • Problème résolu 3053647 : échec du basculement Edge, car l'une des passerelles ESG de NSX-v est hors tension lors de la migration de NSX for vSphere vers NSX-T.

    Les opérations effectuées sur la passerelle ESG pendant la migration échouent.

  • Problème résolu 3048603 : le trafic DNS basé sur UDP a créé des informations de session lorsque de nouvelles connexions sont entrées. Cela entraîne l'épuisement de la mémoire après une longue exécution.

    L'utilisation du pool de mémoire du chemin de données atteint 100 %, ce qui dépasse la valeur de seuil de 85 %.

  • Problème résolu 3106018 : le plan de données du service peut se bloquer dans NSX 4.0.0.1 et 4.0.1.1 si le dispositif Edge reçoit un paquet de rapport IGMPv2.

    Le chemin de données redémarrera et provoquera une interruption du trafic.

  • Problème résolu 3073647 : fausse alarme de DNS « Délai d'expiration du serveur en amont du redirecteur » lorsqu'au moins deux serveurs en amont sont configurés.

    La fausse alarme est source de confusion, car les serveurs en amont fonctionnent tous correctement.

  • Problème résolu 3062615 : la suppression du nœud de transport Edge peut laisser des entrées périmées sur les tables internes du dispositif Edge.

    NSX Manager passe à l'état bloqué après la mise à niveau de NSX en raison des entrées périmées.

  • Problème résolu 3059517 : fuite de mémoire dans la programmation des attributs de résumé DNS.

    En fonction de la quantité de trafic, une utilisation continue des cœurs peut survenir.

  • Problème résolu 3055437 : la propriété SPF est activée même lorsque la zone de transport de superposition est supprimée du commutateur d'hôte.

    Les machines virtuelles peuvent perdre la connectivité après une opération vMotion.

  • Problème résolu 3046491 : la relation entre le pool d'adresses IP et les infra-segments n'est pas vérifiée lors de la validation de la suppression, ce qui permet de supprimer des pools d'adresses IP lorsqu'ils sont activement consommés/référencés par des infra-segments, ce qui entraîne la désallocation d'adresses IP en cours d'utilisation.

    Répercussion fonctionnelle en raison de la perte d'adresses IP lors de l'utilisation par des segments d'infrastructure.

  • Problème résolu 3044226 : la révision de l'intention réalisée dans RealizationState de DhcpRelayConfig n'a pas été mise à jour.

    L'interface utilisateur affiche l'état consolidé dhcp-relay « IN_PROGRESS » bien que dhcp-relay fonctionne correctement.

  • Problème résolu 3056265 : échec du déploiement du nœud NSX Manager avec le même nom d'hôte que celui utilisé précédemment par un nœud NSX Manager détaché.

    Le déploiement de nœuds de NSX Manager est bloqué avec les mêmes noms d'hôte qui ont été détachés précédemment.

  • Problème résolu 3024587 : les journaux IDPS reçus sur le serveur Syslog externe sont tronqués, malgré l'augmentation du paramètre remote-host-max-msg-len.

    Les événements IDPS peuvent être divisés en plusieurs lignes sur le serveur Syslog externe.

  • Problème résolu 3008229 : l'interface de ligne de commande définie sur le délai d'expiration TN du CCP n'a pas la possibilité d'utiliser l'unité heure.

    Impossible d'utiliser l'unité heure dans l'interface de ligne de commande du délai d'expiration TN du CCP.

  • Problème résolu 2863105 : un groupe de trafic consommé par HCX ne peut pas être supprimé de NSX tant que vous n'avez pas supprimé les entités associées de HCX.

    La procédure de suppression des groupes de trafic/mappage d'association HCX n'est pas claire.

  • Problème résolu 3091229 : l'instance de REST API d'appartenance effective pour les instances de service natif de cloud ne fonctionne pas pour les groupes qui ont plus de deux membres CNS.

    L'instance de REST API d'appartenance effective pour le membre CNS ne fonctionne pas comme prévu.

  • Problème résolu 3056889 : les routes statiques sur les routeurs distribués et/ou les routeurs de service de niveau 1 ne sont pas propagées aux nœuds de transport.

    Interruption du trafic pour le trafic destiné à ces routes statiques. Les ports de routeur logique doivent être configurés avant que des routes statiques ne soient configurées.

  • Problème résolu 3046448 : la règle n'est pas supprimée des hôtes ESX lorsque la suppression du groupe NG est forcée dans l'interface utilisateur du MP.

    La règle de pare-feu avec un NSGroup supprimé consommé dans la source ou la destination continuera d'appliquer la position de sécurité sur les hôtes ESX pour toutes les sources ou destinations respectivement.

  • Problème résolu 3044281 : la VM Edge présente une erreur de configuration matérielle périmée. Cela entraîne une erreur de validation lors de l'application des modifications de configuration du gestionnaire.

    La configuration Edge ne peut pas être modifiée via l'API PUT du nœud de transport ou l'interface utilisateur, car il existe une erreur périmée.

  • Problème résolu 3043150 : les données de nœud de transport périmées sont laissées par le réplicateur LCP du CCP après la suppression du nœud de transport par MP.

    Un nouveau nœud de transport est ajouté par MP qui réutilise l'ancienne adresse IP VTEP avec une adresse MAC VTEP différente, ce qui entraîne un signalement de données incorrectes par le CCP, car les données périmées du nœud de transport n'ont pas été nettoyées.

  • Problème résolu 3037403 : lors des requêtes via RPC GetLportRealizedState, le CCP remplacera l'ID de VLAN de la liaison par l'ID de VLAN du segment.

    Lorsque l'utilisateur interroge des liaisons d'adresse, il peut constater que l'ID de VLAN est différent de ce qui est défini dans les liaisons manuelles.

  • Problème résolu 3013563 : la modification du nom de groupe dans AD affecte le chemin d'accès aux données - Règle DFW non appliquée à l'utilisateur qui fait partie du groupe dont le nom a été modifié (après la synchronisation complète/delta).

    Le chemin de données est interrompu.

  • Problème résolu 3008229 : l'interface de ligne de commande définie sur le délai d'expiration TN du CCP n'a pas la possibilité d'utiliser l'unité heure.

    Impossible d'utiliser l'unité heure dans l'interface de ligne de commande du délai d'expiration TN du CCP.

  • Problème résolu 2982055 : les membres des groupes imbriqués ne sont pas synchronisés sur Intelligence.

    L'API de topologie de flux de groupe n'affiche pas les membres du groupe imbriqué.

  • Problème résolu 2930122 : la migration des données CCP de GC/HL vers une version ultérieure peut laisser des enregistrements de conflit, ce qui peut générer de fausses alarmes.

    Vous observez de fausses alarmes concernant les nœuds de transport déconnectés, même s'ils sont connectés.

  • Problème résolu 2863105 : un groupe de trafic consommé par HCX ne peut pas être supprimé de NSX tant que vous n'avez pas supprimé les entités associées de HCX.

    La procédure de suppression des groupes de trafic/mappage d'association HCX n'est pas claire.

  • Problème résolu 3062600 : le proxy NSX continue de redémarrer lorsque le fichier controller-info.xml est supprimé/vide.

    Le proxy NSX redémarrerait continuellement et il y aurait une journalisation continue pour celui-ci.

  • Problème résolu 3063646 : erreur de connexion nestdb-ops-agent sur le dispositif unifié.

    Les journaux seront remplis plus rapidement.

  • Problème résolu 3065925 : la RIB VRF définie par l'utilisateur n'est pas renseignée avec des routes ECMP IPv6.

    Des informations sont manquantes pour les routes ICMP IPv6.

  • Problème résolu 3071393 : la règle de passerelle ayant un profil d'accès L7 n'est pas appliquée sur le dispositif Edge après l'activation ou la désactivation de la passerelle.

    la règle de passerelle ayant un profil d'accès L7 n'est pas appliquée sur le dispositif Edge après l'activation ou la désactivation de la passerelle.

  • Problème résolu 3072735 : le calcul effectif du profil de détection d'adresses IP sur CCP n'applique pas la priorité profils LSP -> profils LS -> profils de groupe comme prévu.

    Des adresses IP incorrectes sont disponibles dans les groupes DFW.

  • Problème résolu 3073055 : les règles héritent accidentellement de l'étendue des définitions DHCP et sont envoyées aux dispositifs Edge.

    Les règles sont réalisées sur les dispositifs Edge lorsqu'elles ne doivent pas se trouver sur l'interface utilisateur.

  • Problème résolu 3073457 : l'état du point de terminaison du tunnel distant n'est pas actualisé.

    La connectivité des sessions BGP sur le point de terminaison de tunnel distant est intacte, il n'y a aucune incidence sur le chemin de données, mais l'interface utilisateur n'affiche pas l'état approprié.

  • Problème résolu 3078357 : la compatibilité de la version LM-LM de fédération doit être +/-2, mais CCP ne prend en charge que +/-1.

    Deux sites de fédération sont déconnectés si un site s'exécute sur la version V et l'autre sur la version V+2 ou V-2.

  • Problème résolu 3081190 : le service de recherche utilise une partition racine sur GM pour stocker des données. L'espace disque de la partition racine est rempli et déclenche une alarme.

    GM ne fonctionnera pas correctement après l'utilisation de 100 % du disque de partition racine.

  • Problème résolu 3081664 : la règle DFW est envoyée au nœud Edge par erreur. L'une des règles transférées vers le dispositif Edge a des paramètres incorrects. Cela peut entraîner un blocage perpétuel du plan de données.

    Port de liaison descendante calculé par CCP dans le cadre de l'étendue de la règle de pare-feu lorsque le commutateur logique/LSP est utilisé dans le paramètre appliedTo de la règle. Par conséquent, la règle DFW est envoyée au nœud Edge par erreur. L'une des règles transférées vers le dispositif Edge a des paramètres incorrects. Cela peut entraîner un blocage perpétuel du plan de données.

  • Problème résolu 3057573 : échec de l'application du profil TN au cluster compatible vLCM.

    L'installation de NSX a échoué sur le cluster compatible LCM, car le mot de passe du compte de service a expiré.

  • Problème résolu 3046985 : certains services de pare-feu de passerelle ne sont pas pris en charge (MS_RPC_TCP, MS_RPC_UDP, SUN_RPC_TCP, SUN_RPC_UDP, ORACLE_TNS). L'opération de publication échoue avec une erreur si les services sont sélectionnés.

    Les services peuvent être sélectionnés dans l'interface utilisateur, mais une erreur s'affiche lors de la publication : « Type de passerelle de niveau application (ALG) non pris en charge : ORACLE_TNS. »

  • Problème résolu 3040934 : impossible de publier les modifications sur les paramètres de pare-feu distribué (DFW) ou de pare-feu de passerelle (GWFW). Le bouton Publier est désactivé lorsque le pare-feu distribué (DFW) ou le pare-feu de passerelle (GWFW) est désactivé.

    Impossible de publier les modifications de configuration, car le pare-feu distribué (DFW) ou le pare-feu de passerelle (GWFW) est désactivé.

  • Problème résolu 2888207 : impossible de réinitialiser les informations d'identification de l'utilisateur local lorsque vIDM est activé.

    vous ne pourrez pas modifier les mots de passe des utilisateurs locaux lorsque vIDM est activé.

  • Problème résolu 3068125 : lorsque BGP est configuré sur l'interface VTI dans un déploiement Edge actif-en veille, BGP doit être inactif sur le nœud Edge en veille, mais une alarme « BGP inactif » est toujours générée sur le nœud Edge en veille.

    Aucune répercussion fonctionnelle. Une fausse alarme « BGP inactif » est toutefois observée sur le nœud Edge en veille.

  • Problème résolu 3057573 : échec de l'application du profil TN au cluster compatible vLCM.

    L'installation de NSX a échoué sur le cluster compatible LCM, car le mot de passe du compte de service a expiré.

  • Problème résolu 3047608 : après le déploiement du dispositif CSM, l'interface utilisateur de CSM ne sera pas accessible après la connexion et le service nsx-cloud-service manager est inactif.

    L'interface utilisateur CSM du jour 0 sera inactive après la connexion.

  • Problème résolu 3045514 : impossible d'afficher les flux des machines virtuelles reposant sur NSX dans vRNI.

    L'utilisateur ne parvient pas à afficher les flux provenant de machines virtuelles reposant sur NSX dans vRNI.

  • Problème résolu 3042523 : les liaisons détectées NSX (adresses IP) fournies par vm-tools pour les ports de segment des machines virtuelles deviennent vides lorsqu'une opération Storage vMotion est en cours.

    Les règles DFW basées sur des adresses IP détectées par vm-tools en tant que source ne s'appliquent pas à l'adresse IP lors de l'opération Storage vMotion de la machine virtuelle.

  • Problème résolu 3038658 : lorsqu'une restauration est effectuée dans une configuration à l'échelle de l'hyperviseur 1K, le service NSX (proton) se bloque en raison de problèmes OOM.

    Le processus de restauration peut s'exécuter plus longtemps au redémarrage du service NSX.

  • Problème résolu 3027580 : si des DVPG sont supprimés dans vCenter Server attachés à des hôtes faisant partie d'un cluster préparé pour la sécurité uniquement mappé à des segments détectés faisant partie de groupes d'inventaire, les segments détectés ne seront jamais nettoyés.

    Ce problème n'a aucune répercussion fonctionnelle. L'interface utilisateur de NSX Manager affiche les objets périmés.

  • Problème résolu 3027473 : les commentaires de l'interface utilisateur ne s'affichent pas lors de la migration de plus de 1 000 règles DFW de NSX for vSphere vers NSX-T Data Center, mais les sections sont divisées en sections de 1 000 règles ou moins.

    les commentaires sur l'interface utilisateur ne s'affichent pas.

  • Problème résolu 3025367 : si le profil de liaison montante dispose de quatre liaisons montantes actives et que dans la configuration TN, seules deux liaisons montantes pour le mappage de liaison montante VDS sont fournies, quatre vmk seront créés côté hôte.

    Cela n'affecte pas la fonctionnalité.

  • Problème résolu 3024658 : lors du traitement des paquets avec le trafic SMB, NSX IDS/IPS génère une utilisation et une latence élevées du CPU.

    Dans certains cas, le processus NSX IDS/IPS se bloque en raison d'une erreur de mémoire insuffisante lors du traitement du trafic SMB.

  • Problème résolu 3024136 : Les modifications apportées à la configuration BGP VRF ne sont pas toujours appliquées.

    La modification de la configuration BGP dans un VRF ne prend pas toujours effet.

  • Problème résolu 3024129 : alarmes de gestionnaire global déclenchées fréquemment.

    Alarmes déclenchées dès qu'une alarme est résolue.

  • Problème résolu 3019893 : blocage de NGINX après la désactivation de la persistance d'équilibreur de charge.

    Impossible d'établir une nouvelle connexion en raison d'un blocage.

  • Problème résolu 2963524 : les connexions UDP ne sont pas purgées en fonction de leur délai d'expiration.

    les commentaires sur l'interface utilisateur ne s'affichent pas.

  • Problème résolu 2947840 : la vue Topologie réseau n'affiche pas tous les composants de mise en réseau sur l'interface utilisateur.

    Vous ne pouvez pas voir la topologie réseau complète.

  • Problème résolu 2928725 : les téléchargements de signatures IDPS ne fonctionnent pas avec le proxy à l'aide d'un port spécifique.

    L'appel de téléchargement de signature via le proxy n'est pas autorisé à atteindre le serveur NTICS.

  • Problème résolu 3034373 : le profil DFW IPFIX est bloqué lors de la suppression après la mise à niveau de la version antérieure à la version 3.2.0 vers la version 3.2.x ou 4.0.x.

    Impossible de supprimer les profils DFW IPFIX.

  • Problème résolu 3043151 : la classification L7 des flux de pare-feu peut ne pas être disponible pendant une courte période lorsque le système rencontre un trafic intense qui doit déterminer AppId

    Les règles L7 peuvent ne pas atteindre les hôtes qui subissent un trafic intense.

  • Problème résolu 3039159 : la migration par vMotion de machines virtuelles avec une interface en mode UPT (Uniform Passthrough) et avec un nombre élevé de flux peut entraîner le PSOD de l'hôte.

    PSOD de l'hôte et donc incidence sur le trafic lors de la migration par vMotion des machines virtuelles basées sur UPT avec un nombre élevé de flux.

  • Problème résolu 3047608 : après le déploiement du dispositif CSM, l'interface utilisateur de CSM ne sera pas accessible après la connexion et le service nsx-cloud-service manager est inactif.

    L'interface utilisateur CSM du jour 0 sera inactive après la connexion.

  • Problème résolu 3027580 : si des DVPG sont supprimés dans vCenter Server attachés à des hôtes faisant partie d'un cluster préparé pour la sécurité uniquement mappé à des segments détectés faisant partie de groupes d'inventaire, les segments détectés ne seront jamais nettoyés.

    Ce problème n'a aucune répercussion fonctionnelle. L'interface utilisateur de NSX Manager affiche les objets périmés.

  • Problème résolu 3042382 : la session doit faire l'objet d'une nouvelle recherche lorsque le paquet correspond à la règle No-SNAT.

    Le trafic correspondant à la règle No-SNAT est bloqué.

  • Problème résolu 3044704 : NSX-Manager prend uniquement en charge le proxy HTTP sans BUMP SSL, même si la page de configuration prend en charge le schéma et le certificat HTTPS.

    Lorsque vous avez configuré le proxy dans Système-> Paramètres généraux -> Serveur Internet Proxy, vous deviez fournir des détails pour le schéma (HTTP ou HTTPS), l'hôte, le port, et ainsi de suite.

    Le schéma ici signifie le type de connexion que vous souhaitez établir entre NSX Manager et le serveur proxy. Cela ne signifie pas le type de proxy. En général, le proxy HTTPS utilise le schéma HTTPS. Mais un proxy tel que Socks configuré avec http_port + transfert SSL établit également la connexion HTTPS entre NSX Manager et le serveur proxy. Cependant, les services dans NSX-Manager supposent toujours que le proxy est exposé avec le port http. Par conséquent, le certificat que vous fournissez ne sera jamais utilisé dans NSX-Manager.

    Lorsque vous choisissez le schéma HTTPS et fournissez le certificat, le système affiche l'erreur « Le certificat xx n'est pas un certificat valide pour xx. » pour un proxy HTTPS sur la page de configuration.

    Aucune erreur ne s'affichera si vous tentez d'utiliser un proxy Squid avec http_port + transfert SSL, mais les services de NSX Manager ne parviennent pas à envoyer une demande à des serveurs externes (l'erreur « Impossible de trouver la chaîne de certificats. » est visible dans le journal).

  • Problème résolu 3025104 : l'hôte passe à l'état « En échec » lorsque vous effectuez une restauration à l'aide d'une adresse IP différente mais du même nom de domaine complet.

    Lorsque la restauration est effectuée à l'aide d'une adresse IP différente des nœuds NSX Manager en utilisant le même nom de domaine complet, les hôtes ne peuvent pas se connecter aux nœuds NSX Manager.

  • Problème résolu 2888207 : impossible de réinitialiser les informations d'identification de l'utilisateur local lorsque vIDM est activé.

    Vous ne pouvez pas modifier les mots de passe des utilisateurs locaux lorsque vIDM est activé.

Problèmes connus

  • Problème 3308657 : lors de la création de sections de pare-feu avec un très grand nombre de règles, la réponse de l'API de création/suppression de règle prend plus de 30 minutes.

    Cette lenteur entraîne des erreurs 409/500 ou une lenteur dans les exécutions d'API pour PODS.

    Solution : réduisez le nombre de règles dans une section.

  • Problème 3222376 : la fonctionnalité NSX « Vérifier l'état » dans l'interface utilisateur de configuration LDAP signale un échec lors de la connexion à Windows Server 2012/Active Directory. Cela est dû au fait que Windows 2012 ne prend en charge que les suites de chiffrement TLS les plus faibles qui ne sont plus prises en charge par NSX pour des raisons de sécurité.

    Même si un message d'erreur s'affiche, l'authentification LDAP via SSL fonctionne, car l'ensemble de suites de chiffrement utilisé par le code d'authentification LDAP est différent de l'ensemble utilisé par le lien « Vérifier l'état ».

    Solution : reportez-vous à l'article 92869 de la base de connaissances pour obtenir plus d'informations.

  • Problème 3296976 : le pare-feu de passerelle peut autoriser l'utilisation d'ID d'application de couche 7 non pris en charge dans le cadre des profils de contexte/d'accès de couche 7.

    Reportez-vous à la page de documentation suivante qui répertorie les ID d'application pris en charge par la version de NSX - https://docs.vmware.com/fr/NSX-Application-IDs/index.html.

    Solution : aucune.

  • Problème 3108693 : l'administrateur de projet ne peut pas configurer la fonctionnalité dns-forwarder à partir de l'interface utilisateur.

    Si vous êtes connecté en tant que « project-admin », les T1 sous project-scope ne sont pas répertoriés dans le menu déroulant de la page dns-forwarder. Par conséquent, project-admin ne peut pas configurer la fonctionnalité dns-forwarder à partir de l'interface utilisateur.

    Solution :

    1. L'administrateur de projet peut effectuer la même fonctionnalité à partir de l'API.

    2. L'administrateur d'entreprise peut créer des services DNS dans l'étendue du projet.

  • Problème 3186573 : perte de données CorfuDB.

    Perte soudaine de certaines configurations. Impossible de créer/mettre à jour certaines configurations.

    Solution : pour plus d'informations, reportez-vous à l'article 92039 de la base de connaissances.

  • Problème 3163020 : lorsque le nom de domaine complet dans les paquets DNS diffère en casse de texte avec les noms de domaine configurés dans les profils L7 des règles de nom de domaine complet, les actions de règle de nom de domaine complet de DFW ne sont pas appliquées correctement.

    Les actions de règle de nom de domaine complet DFW ne sont pas appliquées correctement. Le filtrage du nom de domaine complet DFW ne fonctionne pas correctement.

    Solution : configurez le nom de domaine complet dans le profil de contexte L7 pour qu'il corresponde au nom de domaine dans le paquet DNS.

  • Problème 3155845 : PSOD pendant vMotion lorsque le filtrage du nom de domaine complet est configuré.

    L'hôte ESXi redémarrera.

    Solution : supprimez la configuration du FQDN.

  • Problème 3116294 : la règle avec un groupe imbriqué ne fonctionne pas comme prévu sur les hôtes.

    Trafic non autorisé ou ignoré correctement.

    Solution : reportez-vous à l'article 91421 de la base de connaissances.

  • Problème 3210316 : la configuration de vIDM est effacée si (1) Le gestionnaire est IPv4/IPv6 à double pile et (2) aucune adresse VIP n'est configurée et (3) vous entrez une adresse IP au lieu d'un nom de domaine complet pour le champ « dispositif NSX » dans la configuration vIDM.

    Vous ne pouvez pas vous connecter à l'aide de vIDM tant que la configuration vIDM n'est pas reconfigurée.

    Solution : utilisez le nom de domaine complet pour le champ « dispositif NSX ».

  • Problème 3152195 : les règles DFW avec des profils de contexte avec le nom de domaine complet de type .*XYZ.com ne peuvent pas être appliquées.

    L'application de la règle DFW ne fonctionne pas comme prévu dans ce scénario spécifique.

    Solution : aucune.

  • Problème 3152174 : la préparation de l'enregistrement avec VDS échoue avec l'erreur : l'hôte {UUID} n'est pas ajouté à la valeur VDS.

    Sur vCenter, si des réseaux sont imbriqués dans des dossiers, les migrations de NVDS vers CVDS ou de NSX-V vers NSX-T peuvent échouer si la migration s'effectue vers CVDS dans NSX-T.

    Solution : le premier réseau de l'hôte est le premier réseau visible dans le champ Réseau de la page MOB vCenter https://<VC-IP>/mob?moid=host-moref

    • Avant la version 3.2.1 : premier réseau d'hôte tel que susmentionné et le VDS concerné doit se trouver directement sous le même dossier. Le dossier peut être un dossier DataCenter ou de réseau dans DataCenter.

    • À partir de 3.2.1 et 4.0.0, et versions ultérieures : Le premier réseau d'hôte tel que susmentionné doit se trouver directement sous un dossier. Le VDS souhaité peut alors se trouver directement dans le même dossier ou il peut être imbriqué dans le même dossier. Le dossier peut être un dossier DataCenter ou de réseau dans DataCenter.

  • Problème 3118868 : filtres vNIC incorrects ou périmés programmés sur la pNIC lorsque des filtres de superposition sont programmés en même temps qu'une pNIC est activée.

    Les filtres vNIC programmés sur la pNIC peuvent être périmés, incorrects ou manquants lorsque des filtres de superposition sont programmés en même temps qu'une pNIC est activée, ce qui peut conduire à une régression des performances.

    Solution : aucune.

  • Problème 3113100 : l'adresse IP n'est pas réalisée pour certaines machines virtuelles dans les groupes de sécurité dynamiques en raison d'une entrée VIF obsolète.

    Si un cluster a été initialement configuré pour la mise en réseau et la sécurité à l'aide du démarrage rapide, désinstallé, puis réinstallé uniquement à des fins de sécurité, les règles DFW peuvent ne pas fonctionner comme prévu. Cela est dû au fait que la zone de transport automatique générée pour la mise en réseau et la sécurité est toujours présente et doit être supprimée pour que les règles DFW fonctionnent correctement.

    Solution : supprimez la zone de transport (TZ) générée automatiquement du Démarrage rapide de mise en réseau et sécurité qui fait référence au même DVS que celui utilisé par Sécurité uniquement.

  • Problème 3113093 : les hôtes récemment ajoutés ne sont pas configurés pour la sécurité.

    Après l'installation de la sécurité, lorsqu'un nouvel hôte est ajouté à un cluster et connecté au commutateur virtuel distribué, il ne déclenche pas automatiquement l'installation de NSX sur cet hôte.

    Solution : effectuez les mises à jour du VDS (vSphere Distributed Switch) existant dans VC (ou) ajoutez un nouveau VDS dans VC et ajoutez tous les hôtes du cluster au VDS. Cela mettra automatiquement à jour le profil de nœud de transport (TNP, Transport Node Profile) et celui-ci sera réappliqué au TNC. Lorsque le TNC est mis à jour, le nouvel hôte ajouté dispose de la dernière configuration du TNP.

  • Problème 3113085 : les règles DFW ne sont pas appliquées à la machine virtuelle sur vMotion.

    Lorsqu'une machine virtuelle protégée par DFW est migrée par vMotion d'un hôte vers un autre dans un déploiement d'installation de sécurité uniquement, les règles DFW peuvent ne pas être appliquées sur l'hôte ESX, ce qui entraine une classification incorrecte de la règle.

    Solution : Connectez la VM à un autre réseau, puis reconnectez-la au DVPortgroup cible.

  • Problème 3113076 : les vidages de mémoire non générés pour le démon FRR se bloquent.

    En cas de blocage du démon FRR, les vidages de mémoire ne sont pas générés par le système dans le répertoire /var/dump. Cela peut entraîner le bagotement de BGP.

    Solution : activez le vidage de mémoire pour les démons FRR, déclenchez le blocage et obtenez le vidage de mémoire à partir de /var/dump.

    Pour activer le vidage de mémoire, utilisez la commande suivante sur le nœud Edge, qui doit être exécutée en tant qu'utilisateur racine sur le nœud Edge.

    prlimit --pid <pid of the FRR daemon> --core=500000000:500000000

    Pour vérifier si le vidage de mémoire est activé pour le démon FRR, utilisez la commande suivante et vérifiez les limites SOFT et HARD pour la ressource CORE. Ces limites doivent être de 500 000 000 octets ou 500 Mo.

    prlimit --pid <pid of the FRR daemon>

  • Problème 3113073 : les règles DFW ne sont pas appliquées pendant un certain temps après l'activation du mode de verrouillage.

    L'activation du mode de verrouillage sur un nœud de transport peut entraîner un retard dans l'application des règles DFW. Cela est dû au fait que lorsque le mode de verrouillage est activé sur un nœud de transport, la machine virtuelle associée peut être supprimée de l'inventaire NSX, puis recréée. Pendant cet intervalle de temps, les règles DFW peuvent ne pas être appliquées sur les machines virtuelles associées à cet hôte ESXi.

    Solution : Ajoutez manuellement « da-user » dans la liste d'exceptions avant de passer ESX en mode de verrouillage.

  • Problème 3113067 : impossible de se connecter à NSX-T Manager après une opération vMotion.

    Lors de la mise à niveau de NSX à partir d'une version antérieure à NSX 3.2.1, les machines virtuelles NSX Manager ne sont pas automatiquement ajoutées à la liste d'exclusion de pare-feu. Par conséquent, toutes les règles DFW sont appliquées aux machines virtuelles du gestionnaire, ce qui peut entraîner des problèmes de connectivité réseau.

    Ce problème ne se produit pas dans les nouveaux déploiements à partir de NSX 3.2.2 ou versions ultérieures. Cependant, si vous effectuez une mise à niveau de NSX 3.2.1 ou versions antérieures vers n'importe quelle version cible jusqu'à NSX 4.1.0 inclus, ce problème peut se produire.

    Solution : Contactez le support VMware.

  • Problème 3106569 : les performances n'atteignent pas les niveaux attendus avec le mode serveur de route EVPN.

    Les filtres vNIC programmés sur la pNIC peuvent être périmés, incorrects ou manquants lorsque des filtres de superposition sont programmés sur la pNIC dans une situation d'association, ce qui peut conduire à une régression des performances.

    Solution : aucune.

  • Problème 3094405 : filtres vNIC incorrects ou périmés programmés sur pNIC lorsque des réseaux de superposition sont configurés.

    Les filtres de superposition vNIC sont mis à jour dans un ordre spécifique. Lorsque les mises à jour se produisent en succession rapide, seule la première mise à jour est conservée et les mises à jour suivantes sont ignorées, ce qui entraîne une programmation de filtre incorrecte et une éventuelle régression des performances.

    Solution : aucune.

  • Problème 3121377 : PSOD sur ESX.

    Nœud de transport inactif ayant une incidence sur le trafic.

    Solution :

    1. modifiez la configuration de la charge de travail pour éviter d'envoyer du trafic au routeur de premier saut pour l'homologue sur le même segment.

    2. L'option Accepter ICMP6 redirige normalement à partir du routeur de premier saut.

  • Problème 3098639 : la mise à niveau de NSX Manager échoue en raison de l'échec du service de proxy inverse/d'authentification à passer en mode de maintenance pendant la mise à niveau.

    Échec de la mise à niveau de NSX Manager.

    Solution : pour plus d'informations, reportez-vous à l'article 91120 de la base de connaissances.

  • Problème 3114329 : Intel QAT n'est pas disponible après l'installation du dispositif NSX Edge bare metal.

    Intel QuickAssist Technology (QAT) est une technologie d'accélérateur matériel conçue pour décharger des algorithmes cryptographiques gourmands en calcul et de compression/décompression du CPU vers le matériel dédié. En raison de ce problème, vous ne pouvez pas utiliser Intel QAT pour améliorer les performances de débit du service VPN avec le dispositif NSX Edge bare metal.

    Solution : aucune.

  • Problème 3106950 : Lorsque le quota de DFW est atteint, la création d'un VPC sous l'étendue du projet échoue.

    Vous ne pouvez pas créer un VPC sous le projet dans lequel le quota de DFW a été atteint.

    Solution : aucune.

  • Problème 3094463 : une règle de pare-feu sans état avec FTP de service ALG via l'API de MP obsolète peut être créée. Cette opération n'est pas prise en charge via l'API de stratégie.

    Vous ne pourrez pas effectuer la migration de MP vers une stratégie en cas de règles de pare-feu problématiques sur le MP.

    Solution : la règle de pare-feu problématique doit être mise à jour avec état ou ne doit pas disposer du service FTP du service ALG.

  • Problème 3083358 : le contrôleur met beaucoup de temps à rejoindre le cluster lors du redémarrage du contrôleur.

    Après le redémarrage du contrôleur, les nouvelles configurations créées sur NSX Manager peuvent subir un retard de réalisation, car le contrôleur peut mettre du temps à démarrer.

    Solution : supprimez les groupes d'adresses IP malveillantes redondants, puis redémarrez.

  • Problème 3106317 : lorsque l'adresse MAC d'une VNIC est modifiée dans l'invité, les modifications peuvent ne pas être reflétées dans les filtres programmés sur la PNIC.

    Dégradation potentielle des performances.

    Solution : désactivez, puis réactivez l'interface dans l'invité.

  • Problème 3047727 : CCP n'a pas publié la mise à jour de RouteMapMsg.

    Les routes qui ne sont pas destinées à être publiées sont publiées.

    Solution : aucune.

  • Problème 2792485 : l'adresse IP de NSX Manager s'affiche à la place du nom de domaine complet pour le gestionnaire installé dans vCenter.

    l'interface utilisateur de NSX-T intégrée dans vCenter affiche l'adresse IP de NSX Manager au lieu du nom de domaine complet pour le gestionnaire installé.

    Solution : aucune.

  • Problème 3092154 : la carte réseau actuelle ne prend pas en charge l'en-tête d'extension de routage IPv6.

    Tout trafic IPv6 avec des en-têtes d'extension de routage est abandonné par la carte réseau intelligente.

    Solution : aucune.

  • Problème 3079932 : la modification du MTU peut échouer avec des flux TCP déchargés à grande échelle sur des interfaces UPT.

    Avec des flux TCP déchargés à grande échelle sur des interfaces UPT, le changement de MTU peut parfois échouer.

    Solution :

    1. n'effectuez pas de modification de MTU en cas de trafic.

    2. Vous pouvez également désactiver le déchargement matériel, puis effectuer un changement de MTU.

  • Problème 3077422 : les machines virtuelles et les ports/interfaces reposant sur SmartNIC ne sont pas répertoriés dans l'analyse LTA, car celle-ci n'est pas prise en charge sur les machines virtuelles et les ports reposant sur SmartNIC.

    L'analyse LTA ne peut pas être créée sur certaines machines virtuelles.

    Solution : aucune.

  • Problème 3076771 : l'option « get physical-ports <physical-port-name> stats verbose » affiche une valeur de 0 pour les statistiques par file d'attente.

    Des valeurs nulles inattendues s'affichent lorsque les statistiques de port détaillées sont utilisées dans le débogage.

    Solution : lorsqu'elle est disponible, l'option « get physical-ports <physical-port-name> xstats » affiche les statistiques par file d'attente pour les ports physiques.

  • Problème 3069003 : opérations LDAP excessives sur le service d'annuaire LDAP client lors de l'utilisation de groupes LDAP imbriqués.

    Charge élevée sur le service d'annuaire LDAP en cas d'utilisation de groupes LDAP imbriqués.

    Solution : pour les instances de vROps antérieures à la version 8.6, utilisez l'utilisateur local « admin » au lieu d'un utilisateur LDAP.

  • Problème 3068100 : la fuite de route n'est prise en charge qu'un cas de routage symétrique. Une fuite de route asymétrique entre les VRF peut entraîner un trou noir du trafic.

    Si les routes VRF sont asymétriques dans les nœuds Edge du cluster, ces routes asymétriques ne seront pas synchronisées sur le cluster Edge, même si le routage inter-SR est activé. Cette condition peut potentiellement créer un trou noir pour le trafic sud/nord.

    Solution : assurez-vous que les routes sont propagées symétriquement à tous les nœuds Edge du cluster. Dans cet exemple, les préfixes 2.1.4.0/24 et 2.1.5.0/24 doivent être propagés aux dispositifs Edge e1 et e2.

  • Problème 2855860 : le chemin de données Edge cesse de transférer les données indéfiniment lorsque le système de fichiers Edge passe en mode de lecture seule.

    Perte de trafic. L'accès à la console de la machine virtuelle Edge peut indiquer que le système de fichiers est passé en mode de lecture seule.

    Solution : aucune.

  • Problèmes 3046183 et 3047028 : après l'activation ou la désactivation de l'une des fonctionnalités NSX hébergées sur NSX Application Platform, l'état du déploiement des autres fonctionnalités NSX hébergées devient In Progress. Les fonctionnalités NSX affectées sont NSX Network Detection and Response, Protection contre les programmes malveillants NSX et NSX Intelligence.

    Après le déploiement de NSX Application Platform, l'activation ou la désactivation de la fonctionnalité NSX Network Detection and Response entraîne la modification des états de déploiement de la fonctionnalité Protection contre les programmes malveillants NSX et de la fonctionnalité NSX Intelligence en In Progress. De même, l'activation et la désactivation de la fonctionnalité Protection contre les programmes malveillants NSX entraîne l'état de déploiement de la fonctionnalité NSX Network Detection and Response sur In Progress. Si NSX Intelligence est activé et que vous activez la protection contre les programmes malveillants NSX, l'état de la fonctionnalité NSX Intelligence passe à Down et à Partially up.

    Solution : aucune. le système récupère de lui-même.

  • Problème 3041672 : pour les modes de migration de configuration uniquement et DFW, une fois toutes les étapes de migration réussies, vous appelez des API de pré-migration et de post-migration pour déplacer les charges de travail. Si vous modifiez les informations d'identification de NSX for vSphere, vCenter Server ou NSX après la réussite des étapes de migration, l'appel des API pour la pré-migration et la post-migration échouera.

    Vous ne pourrez pas déplacer les charges de travail, car les appels d'API de pré-migration, de post-migration et de finalisation d'infrastructure échoueront.

    Solution : effectuez les procédures suivantes.

    1. Redémarrez le coordinateur de migration.

    2. Sur l'interface utilisateur de migration, en utilisant le même mode de migration qu'avant le redémarrage, fournissez tous les détails d'authentification. Cela devrait synchroniser la progression de la migration.

    3. Exécutez les API d'infrastructure de pré-migration et de post-migration.

  • Problème 3043600 : le déploiement de NSX Application Platform échoue lorsque vous utilisez un référentiel Harbor privé (non défini par défaut) avec un certificat auto-signé d'une autorité de certification (CA) moins connue.

    Si vous tentez de déployer NSX Application Platform à l'aide d'un référentiel Harbor privé (non défini par défaut) avec un certificat auto-signé d'une autorité de certification moins connue, le déploiement échoue, car la tâche de déploiement ne parvient pas à obtenir les graphiques Helm et les images Docker de la plate-forme d'application NSX. Étant donné que la NSX Application Platform n'a pas été déployée correctement, vous ne pouvez activer aucune des fonctionnalités de NSX, telles que NSX Intelligence, que la plate-forme héberge.

    Solution : utilisez une autorité de certification approuvée connue pour signer le certificat que vous utilisez pour votre serveur Harbor privé.

  • Problème 2491800 : l'expiration ou la révocation des attributs de certificat du port de canal du réplicateur asynchrone ne sont pas vérifiées périodiquement.

    Cela peut entraîner l'utilisation d'un certificat expiré/révoqué pour une connexion existante.

    Solution : une nouvelle connexion utiliserait les nouveaux certificats (le cas échéant) ou générerait une erreur, car l'ancien certificat a expiré ou a été révoqué. Pour déclencher la reconnexion, le redémarrage du Hub du proxy du dispositif (APH) sur le nœud de gestionnaire serait suffisant.

  • Problème 2994066 : échec de la création d'une carte vmknic miroir sur ESXi 8.0.0.0 et NSX 4.0.1 ou version ultérieure.

    Impossible d'activer L3SPAN avec la pile de mise en miroir, car la carte vmknic miroir n'a pas pu être créée.

    Solution :

    1. à partir de l'invite de la CLI ESXi, créez une pile miroir sur ESXi.

    2. À partir du vSphere Web Client, créez un vmknic.

    3. Exécutez la commande suivante :

    esxcli network ip netstack add -N mirror

  • Problème 3007396 : Si le nœud distant est défini sur le mode de délai d'expiration LACP lent, il peut y avoir une perte de trafic d'au moins 60 à 90 secondes une fois que nous arrêtons l'une des liaisons LAG via la commande CLI « esxcli network nic down -n vmnicX »

    Le trafic diminue d'au moins 60 à 90 secondes une fois que nous arrêtons l'une des liaisons LAG via la commande CLI « esxcli network nic down -n vmnicX ».

    Ce problème se produit uniquement si le délai d'expiration LACP du nœud distant est défini sur le mode LENT.

    Solution : définissez le délai d'expiration LACP du commutateur externe sur RAPIDE.

  • Problème 3013751 : la progression de l'installation/désinstallation de NSX n'est pas visible automatiquement sur la page Infrastructure.

    La progression est visible après l'actualisation manuelle de la page Infrastructure.

    Solution : actualisez manuellement la page Infrastructure.

  • Problème 3018596 : la fonction virtuelle (VF) est libérée si vous définissez le MTU de la carte réseau virtuelle (vnic) de la machine virtuelle sur la machine virtuelle invitée sur une valeur supérieure à la valeur de MTU de la carte réseau physique.

    Une fois que le MTU de vNIC est modifié pour être supérieur au MTU de pNIC, la machine virtuelle ne pourra pas acquérir de VF. Par conséquent, la machine virtuelle ne sera pas en mode UPT. Elle sera en mode « emu vmnic ».

    Solution :

    1. Modifiez la taille MTU sur DVS de 1 600 à 9 100.

    2. La fonction virtuelle est réattribuée à la vNIC de la machine virtuelle.

  • Problème 3003762 : la désinstallation du service de protection contre les programmes malveillants NSX échoue si vous ne supprimez pas les règles du service de protection contre les programmes malveillants de la stratégie. Aucun message d'erreur indiquant que la désinstallation échoue ne s'affiche, car des règles sont toujours présentes dans la stratégie.

    La désinstallation du service de protection contre les programmes malveillants NSX échouera dans ce scénario.

    Solution : supprimez les règles et réessayez la désinstallation.

  • Problème 3003919 : les règles DFW correspondant à CNAMES ayant des actions différentes de celles de la règle DFW correspondant au nom de domaine d'origine entraîneront une application de règle incohérente.

    Dans le cas peu probable où une application/un utilisateur accède à CNAME au lieu du nom de domaine d'origine, il peut sembler contourné ou être abandonné de manière incorrecte par les règles DFW.

    Solution : effectuez l'une des étapes suivantes.

    • Configurez les règles DFW uniquement pour le nom de domaine d'origine et pas le CNAME.

    • Configurez les règles avec le nom de domaine et CNAMES avec la même action.

  • Problème 3014499 : la mise hors tension du trafic intersite de gestion Edge entraîne une interruption de certains flux.

    Certains trafics intersite cessaient de fonctionner.

    Solution : mettez sous tension le dispositif Edge.

  • Problème 3014978 : Le survol de l'indicateur Mise en réseau et sécurité sur la page Infrastructure affiche des informations incorrectes, quelle que soit la mise en réseau sélectionnée.

    Aucun impact.

    Solution : aucune.

  • Problème 3014979 : la progression de l'installation/désinstallation de NSX n'est pas visible automatiquement sur la page Infrastructure.

    Aucun impact. Actualisez manuellement la page pour voir la progression.

    Solution : actualisez manuellement la page Infrastructure.

  • Problème 3017885 : l'analyse du nom de domaine complet ne peut prendre en charge qu'un seul sous-cluster en mode actif/actif avec état.

    N'activez pas la fonctionnalité si actif/actif avec état dispose de plusieurs sous-clusters.

    Solution : déployez un seul sous-cluster.

  • Problème 3010038 : sur un LAG à deux ports qui sert de relais uniforme Edge (UPT), si la connexion physique à l'un des ports LAG est déconnectée, la liaison montante sera inactive, mais les fonctions virtuelles (VF) utilisées par ces machines virtuelles UPT continueront à être actives et en cours d'exécution lorsqu'elles obtiendront la connectivité via l'autre interface LAG.

    Aucun impact.

    Solution : aucune.

  • Problème 3009907 : les VIB NSX ne sont pas supprimés de l'hôte SmartNIC si l'hôte était dans un état déconnecté lors de l'opération « Supprimer NSX » sur le cluster.

    Aucune répercussion fonctionnelle.

    Solution : dans vCenter Server, accédez à l'interface utilisateur de vLCM et corrigez le cluster.

  • Problème 2490064 : la tentative de désactivation de VMware Identity Manager avec l'option « Équilibreur de charge externe » activée ne fonctionne pas.

    Après l'activation de l'intégration de VMware Identity Manager sur NSX avec « Équilibreur de charge externe », si vous tentez de désactiver l'intégration en désactivant « Équilibreur de charge externe », la configuration initiale réapparaît et remplace les modifications locales après environ une minute.

    Solution : lorsque vous tentez de désactiver vIDM, ne désactivez pas l'indicateur Équilibreur de charge externe. Désactivez uniquement Intégration de vIDM. Cela entraîne l'enregistrement de la configuration dans la base de données et sa synchronisation avec les autres nœuds.

  • Problème 2558576 : les versions de gestionnaire global et de gestionnaire local d'une définition de profil global peuvent différer et avoir un comportement inconnu sur le gestionnaire local.

    Les profils DNS globaux, de session ou de propagation créés sur un gestionnaire global ne peuvent pas être appliqués à un groupe local à partir de l'interface utilisateur, mais peuvent être appliqués à partir de l'API. Par conséquent, un utilisateur d'API peut accidentellement créer des cartes de liaison de profil et modifier l'entité globale sur le gestionnaire local.

    Solution : utilisez l'interface utilisateur pour configurer le système.

  • Problème 2355113 : les machines virtuelles de charge de travail exécutant RedHat et CentOS sur des instances de mise en réseau accélérée Azure ne sont pas prises en charge.

    dans Azure, lorsque l'accélération de mise en réseau est activée sur un système d'exploitation RedHat ou CentOS et si NSX Agent est installé, l'interface Ethernet n'obtient pas d'adresse IP.

    Solution : désactivez la mise en réseau accélérée pour les systèmes d'exploitation basés sur RedHat et CentOS.

  • Problème 2574281 : la stratégie n'autorise qu'un maximum de 500 sessions VPN.

    NSX réclame la prise en charge de 512 sessions VPN par dispositif Edge dans le facteur de forme élevé. Cependant, en raison de la stratégie de l'analyse automatique des stratégies de sécurité, la stratégie n'autorise qu'un maximum de 500 sessions VPN.

    Lors de la configuration de la 501e session VPN sur Niveau0, le message d'erreur suivant s'affiche :

    {'httpStatus': 'BAD_REQUEST', 'error_code': 500230, 'module_name': 'Policy', 'error_message': 'GatewayPolicy path=[/infra/domains/default/gateway-policies/VPN_SYSTEM_GATEWAY_POLICY] has more than 1,000 allowed rules per Gateway path=[/infra/tier-0s/inc_1_tier_0_1].'}

    Solution : utilisez les API du plan de gestion pour créer des sessions VPN supplémentaires.

  • Problème 2684574 : si le dispositif Edge comporte plus de 6 000 routes pour la base de données et les routes, l'API de stratégie expire.

    ces API de stratégie pour la base de données OSPF et les routes OSPF renvoient une erreur si le dispositif Edge comporte plus de 6 000 routes : /tier-0s/<tier-0s-id>/locale-services/<locale-service-id>/ospf/routes /tier-0s/<tier-0s-id>/locale-services/<locale-service-id>/ospf/routes?format=csv /tier-0s/<tier-0s-id>/locale-services/<locale-service-id>/ospf/database /tier-0s/<tier-0s-id>/locale-services/<locale-service-id>/ospf/database?format=csv si le dispositif Edge comporte plus de 6 000 routes pour la base de données et les routes, l'API de stratégie expire. Il s'agit d'une API en lecture seule qui a un impact uniquement si l'API/l'interface utilisateur est utilisée pour télécharger plus de 6 000 routes pour les routes et la base de données OSPF.

    Solution : utilisez les commandes de la CLI pour récupérer les informations du dispositif Edge.

  • Problème 2663483 : l'instance de NSX Manager à nœud unique se déconnecte du reste de l'environnement de Fédération NSX si vous remplacez le certificat APH-AR sur cette instance de NSX Manager.

    ce problème se produit uniquement avec Fédération NSX et avec le cluster NSX Manager à nœud unique. l'instance de NSX Manager à nœud unique se déconnecte du reste de l'environnement de la fédération NSX si vous remplacez le certificat APH-AR sur cette instance de NSX Manager.

    Solution : le déploiement d'un cluster NSX Manager à nœud unique n'est pas une option de déploiement prise en charge. Vous devez donc disposer d'un cluster NSX Manager à trois nœuds.

  • Problème 2690457 : lors de la jonction d'un plan de gestion à un cluster MP dans lequel publish_fqdns est défini sur le cluster MP et où le serveur DNS externe n'est pas configuré correctement, le service de protons peut ne pas redémarrer correctement sur le nœud de jonction.

    Le gestionnaire de jonction ne fonctionnera pas et l'interface utilisateur ne sera pas disponible.

    Solution : configurez le serveur DNS externe avec des entrées DNS directes et inversées pour tous les nœuds de gestionnaire.

  • Problème 2719682 : les champs calculés du contrôleur Avi ne sont pas synchronisés avec l'intention sur la stratégie, ce qui entraîne des différences dans les données affichées sur l'interface utilisateur d'Avi et de NSX-T.

    les champs calculés du contrôleur Avi sont affichés comme vides dans l'interface utilisateur de NSX-T.

    Solution : sélecteur d'applications à utiliser pour vérifier les données à partir de l'interface utilisateur d'Avi.

  • Problème 2792485 : l'adresse IP de NSX Manager s'affiche à la place du nom de domaine complet pour le gestionnaire installé dans vCenter.

    l'interface utilisateur de NSX-T intégrée dans vCenter affiche l'adresse IP de NSX Manager au lieu du nom de domaine complet pour le gestionnaire installé.

    Solution : aucune.

  • Problème 2799371 : les alarmes IPSec pour VPN L2 ne sont pas effacées même si les sessions VPN L2 et IPSec sont actives.

    aucune répercussion fonctionnelle, sauf que des alarmes ouvertes inutiles sont visibles.

    Solution : résoudre les alarmes manuellement.

  • Problème 2838613 : pour la version d'ESX antérieure à la version 7.0.3, la fonctionnalité de sécurité NSX n'est pas activée sur VDS mis à niveau de la version 6.5 vers une version supérieure après l'installation de la sécurité sur le cluster.

    les fonctionnalités de sécurité de NSX ne sont pas activées sur les machines virtuelles connectées à VDS mises à niveau de la version 6.5 vers une version ultérieure (6.6 et versions ultérieures) sur lesquelles la fonctionnalité de sécurité NSX sur vSphere DVPortgroups est prise en charge.

    Solution : une fois VDS mis à niveau, redémarrez l'hôte et mettez sous tension les machines virtuelles pour activer la sécurité sur les machines virtuelles.

  • Problème 2848614 : lors de la jonction d'un plan de gestion à un cluster MP où publish_fqdns est défini sur le cluster MP et où l'entrée de recherche directe ou inversée manquante dans le serveur DNS externe ou l'entrée DNS manquante pour joindre le nœud, les alarmes directes ou inverses ne sont pas générées pour le nœud de jonction.

    les alarmes directes/inversées ne sont pas générées pour le nœud de jonction, même si l'entrée de recherche directe/inverse est manquante dans le serveur DNS ou si l'entrée DNS est manquante pour le nœud de jonction.

    Solution : configurez le serveur DNS externe pour tous les nœuds de gestionnaire avec des entrées DNS directes et inverses.

  • Problème 2853889 : lors de la création de la configuration de locataire EVPN (avec le mappage vlan-vni), des segments enfants sont créés, mais l'état de réalisation du segment enfant passe à l'état d'échec pendant environ 5 minutes et récupère automatiquement.

    la réalisation de la configuration du locataire EVPN prendra 5 minutes.

    Solution : aucune. patientez 5 minutes.

  • Problème 2866682 : dans Microsoft Azure, lorsque la mise en réseau accélérée est activée sur des machines virtuelles de charge de travail SUSE Linux Enterprise Server (SLES) 12 SP4 et si NSX Agent est installé, l'interface Ethernet n'obtient pas d'adresse IP.

    l'agent de machine virtuelle ne démarre pas et la machine virtuelle devient non gérée.

    Solution : désactivez la mise en réseau accélérée.

  • Problème 2868944 : les commentaires de l'interface utilisateur ne s'affichent pas lors de la migration de plus de 1 000 règles DFW de NSX for vSphere vers NSX-T Data Center, mais les sections sont divisées en sections de 1 000 règles ou moins.

    les commentaires sur l'interface utilisateur ne s'affichent pas.

    Solution : vérifiez les journaux.

  • Problème 2870085 : la journalisation au niveau de la stratégie de sécurité pour activer/désactiver la journalisation pour toutes les règles ne fonctionne pas.

    vous ne pourrez pas modifier la journalisation de toutes les règles en modifiant « logging_enabled » de la stratégie de sécurité.

    Solution : modifiez chaque règle pour activer/désactiver la journalisation.

  • Problème 2871440 : les charges de travail sécurisées avec NSX Security sur vSphere dvPortGroups perdent leurs paramètres de sécurité lorsqu'elles sont déplacées via vMotion vers un hôte connecté à une instance de NSX Manager inactive.

    Les clusters installés avec la fonctionnalité NSX Security sur vSphere dvPortGroups, les machines virtuelles qui sont déplacées via vMotion vers des hôtes connectés à une instance de NSX Manager inactive ne disposent pas de DFW et de règles de sécurité appliqués. Ces paramètres de sécurité sont appliqués à nouveau lorsque la connectivité à NSX Manager est rétablie.

    Solution : évitez tout déplacement par vMotion vers les hôtes affectés lorsque NSX Manager est inactif. Si d'autres nœuds NSX Manager fonctionnent, effectuez un déplacement par vMotion de la machine virtuelle vers un autre hôte connecté à une instance de NSX Manager saine.

  • Problème 2871585 : la suppression de l'hôte de DVS et de DVS est autorisée pour les versions de DVS antérieures à la version 7.0.3 après que la fonctionnalité Sécurité de NSX sur vSphere DVPortgroups est activée sur les clusters à l'aide du DVS.

    vous devrez peut-être résoudre les problèmes de configuration de nœud de transport ou de cluster qui proviennent d'un hôte supprimé de DVS ou de la suppression de DVS.

    Solution : aucune.

  • Problème 2877776 : la sortie « get controllers » peut afficher des informations périmées sur les contrôleurs qui ne sont pas les contrôleurs maîtres par rapport au fichier controller-info.xml.

    cette sortie de la CLI est source de confusion.

    Solution : redémarrez nsx-proxy sur ce TN.

  • Problème 2879133 : la fonctionnalité de protection contre les programmes malveillants peut prendre jusqu'à 15 minutes pour commencer à fonctionner.

    lorsque la fonctionnalité de protection contre les programmes malveillants est configurée pour la première fois, son initialisation peut prendre jusqu'à 15 minutes. Pendant cette initialisation, aucune analyse de logiciels malveillants n'est effectuée, mais il n'existe aucune indication que l'initialisation se produit.

    Solution : patientez 15 minutes.

  • Problème 2889482 : la confirmation d'enregistrement incorrecte s'affiche lors de la mise à jour des profils de segment pour les ports détectés.

    L'interface utilisateur de stratégie permet de modifier les ports détectés, mais n'envoie pas le mappage de liaison mis à jour pour les demandes de mise à jour de port lorsque des profils de segments sont mis à jour. Un faux message positif s'affiche après avoir cliqué sur Enregistrer. Les segments semblent être mis à jour pour les ports détectés, mais ils ne le sont pas.

    Solution : utilisez MP API ou l'interface utilisateur pour mettre à jour les profils de segment pour les ports détectés.

  • Problème 2898020 : l'erreur « échec de la configuration de FRR:: ROUTING_CONFIG_ERROR (-1) » s'affiche sur l'état des nœuds de transport.

    Le nœud Edge rejette une séquence de mappage de route configurée avec une action de refus qui a plusieurs listes de communauté attachées à ses critères de correspondance. Tous les nœuds Edge ne disposent pas de la configuration prévue par l'administrateur. Cela entraîne un comportement inattendu.

    Solution : aucune.

  • Problème 2910529 : le dispositif Edge perd l'adresse IPv4 après l'allocation DHCP.

    Une fois que la machine virtuelle Edge est installée et qu'elle a reçu une adresse IP du serveur DHCP, elle perd rapidement l'adresse IP et devient inaccessible. Cela est dû au fait que le serveur DHCP ne fournit pas de passerelle. Par conséquent, le nœud Edge perd l'adresse IP.

    Solution : assurez-vous que le serveur DHCP fournit l'adresse de passerelle appropriée. Si ce n'est pas le cas, procédez comme suit :

    1. Connectez-vous à la console de la machine virtuelle Edge en tant qu'admin.

    2. Arrêtez service dataplane.

    3. Définissez l'interface <mgmt intf> dhcp plane mgmt.

    4. Démarrez service dataplane.

  • Problème 2919218 : les sélections effectuées pour la migration de l'hôte sont réinitialisées aux valeurs par défaut après le redémarrage du service MC.

    Après le redémarrage du service MC, toutes les sélections pertinentes pour la migration de l'hôte, telles que l'activation ou la désactivation des clusters, le mode de migration, l'ordre de migration des clusters, etc., qui ont été effectuées précédemment, sont réinitialisées aux valeurs par défaut.

    Solution : assurez-vous que toutes les sélections pertinentes pour la migration de l'hôte sont effectuées à nouveau après le redémarrage du service MC.

  • Problème 2942900 : le pare-feu d'identité ne fonctionne pas pour l'extraction du journal des événements lorsque les requêtes Active Directory expirent.

    Le pare-feu d'identité émet une requête Active Directory récursive pour obtenir les informations de groupe de l'utilisateur. Les requêtes Active Directory peuvent expirer avec une exception NamingException « LDAP response read timed out, timeout used: 60 000 ms ». Par conséquent, les règles de pare-feu ne sont pas renseignées avec les adresses IP de l'analyseur de journaux des événements.

    Solution : pour améliorer les délais de requête récursive, les administrateurs Active Directory peuvent organiser et indexer les objets AD.

  • Problème 2954520 : lorsque le segment est créé à partir de la stratégie et que le pont est configuré à partir du plan de gestion, l'option Détacher le pontage n'est pas disponible sur ce segment à partir de l'interface utilisateur.

    Vous ne pourrez pas détacher ou mettre à jour le pontage de l'interface utilisateur si le segment est créé à partir de la stratégie et que le pont est configuré à partir de MP.

    Si un segment est créé du côté de la stratégie. Il est conseillé de configurer le pontage uniquement du côté de la stratégie. De même, si un commutateur logique est créé côté MP, vous devez configurer le pontage uniquement du côté MP.

    Solution : utilisez des API pour supprimer le pontage.

    1. Mettez à jour le LogicalPort concerné et supprimez l'attachement.

    PUT :: https://<mgr-ip>/api/v1/logical-ports/<logical-port-id>

    Ajoutez cela aux en-têtes dans le champ d'en-têtes de charge utile PUT -> X-Allow-Overwrite : true

    2 SUPPRIMER BridgeEndpoint

    DELETE :: https://<mgr-ip>/api/v1/bridge-endpoints/<bridge-endpoint-id>

    3. Supprimez LogicalPort

    DELETE :: https://<mgr-ip>/api/v1/logical-ports/<logical-port-id>

  • Problème 3030847 : Les modifications apportées à la configuration BGP VRF ne sont pas toujours appliquées.

    La modification de la configuration BGP dans un VRF ne prend pas toujours effet.

    Solution : vous pouvez créer une route statique factice et la supprimer. Cela entraîne un transfert de configuration qui effectue la configuration VRF BGP sur le dispositif Edge.

  • Problème 3005685 : lors de la configuration d'une connexion Open ID Connect comme fournisseur d'authentification LM NSX, les clients peuvent rencontrer des erreurs.

    La configuration d'OpenID Connect génère des erreurs lors de la configuration.

    Solution : aucune.

  • Problème 2949575 : lorsqu'un nœud worker Kubernetes est supprimé du cluster sans vider d'abord les espaces sur celui-ci, les espaces sont bloqués à l'état Arrêt indéfiniment.

    NSX Application platform et les applications sur celle-ci peuvent fonctionner partiellement ou pas comme prévu.

    Solution : supprimez manuellement chacun des espaces qui affichent l'état Arrêt à l'aide des informations suivantes.

    1. À partir de l'hôte NSX Manager ou de l'adresse IP de l'exécuteur (hôte de saut Linux à partir duquel vous pouvez accéder au cluster Kubernetes), exécutez la commande suivante pour répertorier tous les espaces avec l'état Arrêt.

      kubectl get pod -A | grep Terminating

    2. Supprimez chaque espace répertorié à l'aide de la commande suivante.

      kubectl delete pod <pod-name> -n <pod-namespace> --force --grace-period=0

  • Problème 3017840 : un basculement de dispositif Edge ne se produit pas lorsque l'adresse IP de liaison montante est modifiée.

    Un état HA incorrect peut entraîner un blocage du trafic.

    Solution : basculez l'état BFD. Avant de modifier l'adresse IP de liaison montante d'un dispositif Edge, placez-le en mode de maintenance.

check-circle-line exclamation-circle-line close-line
Scroll to top icon