VMware NSX 3.2 | 16 décembre 2021 | Build 19067070

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

Informations importantes sur NSX-T Data Center 3.2.0.

Notez que l'équipe VMware NSX a identifié un problème lié à la mise à niveau de versions antérieures vers NSX-T Data Center 3.2.0 et a décidé de retirer la version des pages de téléchargement au profit de NSX-T Data Center 3.2.0.1.

Les clients qui ont téléchargé et déployé NSX-T Data Center 3.2.0 restent pris en charge, mais sont invités à effectuer la mise à niveau vers NSX-T Data Center 3.2.0.1.

Nouveautés

NSX-T Data Center 3.2.0 est une version majeure offrant de nombreuses nouvelles fonctionnalités dans tous les secteurs verticaux de NSX-T : mise en réseau, sécurité, services et intégration. Voici quelques-unes des améliorations majeures.

  • Sécurité distribuée indépendante du commutateur : Possibilité d'étendre la microsegmentation aux charges de travail déployées sur des réseaux vSphere.

  • Sécurité de passerelle : Amélioration des ID d'application L7, de la détection et du sandboxing des programmes malveillants, du filtrage d'URL, du pare-feu ID de l'utilisateur, de l'inspection TLS (version d'évaluation technique) et du service de détection et de prévention des intrusions (IDS/IPS).

  • Sécurité distribuée améliorée : Détection et protection contre les programmes malveillants, IDS/IPS comportemental, identités d'application améliorées pour le pare-feu L7.

  • Amélioration de l'intégration à NSX Advanced Load Balancer (anciennement Avi) : Installez et configurez NSX ALB (Avi) à partir de l'interface utilisateur de NSX-T ; migrez NSX for vSphere LB vers NSX ALB (Avi).

  • Migration de NSX for vSphere vers NSX-T : Améliorations majeures apportées au coordinateur de migration pour étendre la couverture des topologies NSX for vSphere prises en charge et fournir de la flexibilité sur les topologies NSX-T cibles.

  • Amélioration de la protection contre la vulnérabilité Log4j : Apache Log4j mis à jour vers la version 2.16 afin de résoudre les problèmes CVE-2021-44228 et CVE-2021-45046. Pour plus d'informations sur ces vulnérabilités et leur impact sur les produits VMware, reportez-vous à la section VMSA-2021-0028.

Outre ces fonctionnalités, de nombreuses autres sont ajoutées à chaque zone du produit.

Mise en réseau de couche 2

  • Prise en charge des liaisons à deux cartes réseau sur des serveurs physiques Windows : les connexions utilisant des liaisons à double carte réseau physique (pNIC) sont désormais prises en charge sur les serveurs physiques. Cela permet la configuration d'une liaison active/active ou active/en veille. Cette fonctionnalité est prise en charge sur les réseaux VLAN et de superposition.

  • Stratégie d'association compatible NUMA : NSX prend désormais en charge le traitement du trafic sur le même nœud NUMA que les pNIC utilisées pour quitter ESXi. Cette fonctionnalité améliore les performances du déploiement en tirant parti des stratégies d'association sur plusieurs NUMA.

  • Nouvelles capacités du chemin de données optimisé : le commutateur de chemin de données optimisé prend désormais en charge le pare-feu distribué (DFW), l'équilibreur de charge distribué (DLB) et les capacités de mise en miroir de ports.

Mise en réseau de couche 3

  • Prise en charge du mode serveur de route EVPN L3 : ESXi est désormais en mesure d'envoyer directement le trafic VXLAN aux routeurs d'infrastructure du centre de données en contournant le nœud Edge dans le chemin de données. Dans ce modèle de déploiement, le SR de niveau 0 (routeur de service) hébergé sur le nœud Edge est nécessaire uniquement pour gérer le plan de contrôle, c'est-à-dire annoncer les préfixes connectés via la famille d'adresses l2vpn EVPN à l'infrastructure. ESXi prend désormais en charge ECMP vers plusieurs routeurs physiques dans l'infrastructure et teste la disponibilité des routeurs avec BFD.

  • 5 tuples ECMP sur ESXi et KVM : le routeur distribué (DR) hébergé sur ESXi prend désormais en charge l'algorithme de hachage à 5 tuples lorsqu'ECMP est activé. Avec cette fonctionnalité, le hachage est basé sur la source d'adresse IP, la destination de l'adresse IP, le protocole IP, la source de port de couche 4 et la destination de port de couche 4. Cela permet une meilleure distribution du trafic sur tous les routeurs de service (SR) disponibles.

  • Prise en charge du proxy ARP sur la passerelle de niveau 0 active/active : dans les topologies simples sans routage dynamique, une passerelle de niveau 0 en mode HA actif/actif peut désormais être utilisée, ce qui fournit un débit plus élevé.

Multidiffusion

  • Prise en charge d'Actif/Actif sur SR de niveau 0 pour le trafic multidiffusion : NSX prend désormais en charge ECMP du trafic multidiffusion sur plusieurs SR de niveau 0 (routeurs de service), ce qui offre un meilleur débit pour le trafic multidiffusion.

Plate-forme Edge

  • Prise en charge de l'UEFI sur un dispositif Edge bare metal : NSX prend désormais en charge le déploiement d'un nœud Edge bare metal sur des serveurs s'exécutant en mode UEFI. Cela permet de déployer des nœuds Edge sur un ensemble plus large de serveurs.

Pare-feu distribué

  • Le pare-feu distribué prend en charge les machines virtuelles déployées sur des groupes de ports distribués sur des commutateurs VDS : dans les versions précédentes, NSX ne pouvait appliquer que les fonctionnalités de sécurité distribuée pour les ports de commutateur N-VDS. Vous pouvez désormais exploiter les capacités du pare-feu distribué pour les réseaux VLAN basés sur VDS sans avoir à convertir le port de commutateur en N-VDS.

  • Prise en charge des critères de balise dynamique sur les groupes d'adresses IP.

  • Prise en charge du pare-feu distribué pour les serveurs physiques : système d'exploitation Redhat Enterprise Linux 8.0.

  • Ajout d'autres ID d'application pour l'utilisation du pare-feu L7.

  • Protection contre les programmes malveillants pour le pare-feu distribué (cas d'utilisation E-O) : le pare-feu distribué NSX dispose désormais de capacités de détection et de protection contre les programmes malveillants zero-day à l'aide de techniques avancées d'apprentissage automatique et de capacités de sandboxing.

  • Configuration de la synchronisation sélective AD pour IDFW : la configuration AD du pare-feu d'identité prend désormais en charge l'ajout sélectif d'unités d'organisation et d'utilisateurs.

  • Statistiques du pare-feu d'identité : amélioration du tableau de bord Présentation de la sécurité pour inclure les statistiques du pare-feu d'identité pour les utilisateurs actifs et les sessions utilisateur actives.

  • Prise en charge du pare-feu d'identité pour le protocole SMB.

Système de détection/prévention distribué des intrusions (D-IDPS)

  • IDS/IPS distribué est pris en charge pour les machines virtuelles déployées sur des groupes de ports distribués sur VDS.

  • IDS/IPS distribué prend désormais en charge la détection et la prévention basées sur le comportement : une nouvelle classe de signatures IDS est désormais disponible sur le fournisseur d'identité distribué et sur le dispositif Edge. Plutôt que d'identifier un comportement spécifique aux programmes malveillants, ces signatures tentent d'identifier les comportements réseau qui pourraient être associés au signe d'une infection réussie. Cela inclut, par exemple, l'identification de la communication Tor dans le réseau, la présence de certificats TLS auto-signés sur des ports élevés ou des détections avec état plus sophistiquées, telles que la détection d'un comportement de balisage. Cette classe de signatures est modifiée par le niveau de gravité « informatif ». Si NSX NDR est activé, un traitement basé sur ML supplémentaire est appliqué aux alertes produites par ces signatures pour hiérarchiser les cas qui sont très susceptibles d'être anormaux dans l'environnement surveillé spécifique.

  • Conservation et combinaison de signatures Trustwave et VMware : l'ensemble de signatures IDS/IPS de NSX permet désormais d'accéder à un nouvel ensemble de règles IDS développé et organisé par VMware pour garantir une efficacité de sécurité élevée et réduire la probabilité de faux positifs. L'ensemble de règles combine des détections développées par des fournisseurs tiers tels que Trustwave et les menaces émergentes avec un grand nombre de signatures développées par VMware et optimisées pour les moteurs IDS NSX.

Pare-feu de passerelle

  • Contrôle d'accès basé sur l'identité d'utilisateur : le pare-feu de passerelle introduit les capacités supplémentaires de pare-feu d'identité d'utilisateur suivantes :

    1. Pour les déploiements dans lesquels Active Directory est utilisé comme système d'authentification utilisateur, NSX exploite des journaux Active Directory.

    2. Pour tous les autres systèmes d'authentification, NSX peut désormais exploiter les journaux basés sur vRealize Log Insight pour identifier le mappage Identité d'utilisateur à adresse IP.

  • Ensemble amélioré d'ID d'application L7 : les capacités de pare-feu de passerelle sont améliorées pour identifier un nombre plus complet d'applications de couche 7.

  • Inspection TLS pour le trafic entrant et sortant (🔎Tech Preview ; pas pour les déploiements de production) : de plus en plus de trafic est chiffré sur le réseau. Avec la fonctionnalité d'inspection TLS, vous pouvez désormais exploiter le pare-feu de passerelle NSX pour effectuer une inspection approfondie des paquets, ainsi que des services de détection et de prévention des menaces pour le trafic chiffré.

  • Filtrage URL (inclut la catégorisation et la réputation des URL) : vous pouvez désormais contrôler le trafic internet en fonction de la nouvelle fonctionnalité de filtrage URL. Cette fonctionnalité vous permet de contrôler l'accès à Internet en fonction des catégories d'URL et de la réputation des URL. Le référentiel d'URL, y compris les données de catégorisation et de réputation, est régulièrement mis à jour pour une protection mise à jour.

  • Prise en charge de l'analyse et du sandboxing des programmes malveillants : le pare-feu de passerelle NSX assure désormais la détection des programmes malveillants à partir des programmes malveillants connus et des programmes malveillants zero-day à l'aide de techniques avancées d'apprentissage automatique et de capacités de sandboxing. Les données des programmes malveillants connus sont mises à jour de façon continue. (Consultez le problème connu 2888658 avant de déployer dans des déploiements de production en direct.)

  • Détection et prévention des intrusions (🔎Tech Preview, pas pour les déploiements de production) : pour le pare-feu de passerelle NSX, les fonctionnalités de détection et de prévention des intrusions (IPS) sont introduites en mode « Tech Preview ». Vous pouvez essayer l'ensemble de fonctionnalités dans des déploiements hors production.

Nouveau NSX Application Platform

NSX Application Platform : VMware NSX Application Platform est une nouvelle solution basée sur un conteneur introduite dans NSX-T 3.2.0. Elle fournit une architecture de montée en charge résiliente et hautement disponible pour fournir un ensemble de services de plate-forme de base qui permettent plusieurs nouvelles fonctionnalités NSX telles que :

NSX Intelligence

Mesures NSX

NSX Network Detection and Response

Protection contre les programmes malveillants NSX

Le processus de déploiement de NSX Application Platform est entièrement orchestré via l'interface utilisateur de NSX Manager et nécessite un environnement Kubernetes pris en charge. Reportez-vous au guide Déploiement et gestion de VMware NSX Application Platform pour plus d'informations sur les conditions préalables et requises de l'infrastructure pour l'installation.

Détection et réponse du réseau

  • VMware NSX Network Detection and Response met en corrélation les événements IDPS, de programmes malveillants et d'anomalies dans des campagne d'intrusion qui aident à identifier les menaces et les activités malveillantes sur le réseau.

  • Corrélation avec les menaces plutôt qu'avec les événements, ce qui permet aux opérateurs SOC de se concentrer sur le tri uniquement d'un petit ensemble de menaces exploitables.

  • NSX Network Detection and Response collecte les événements IDPS d'IDPS distribué, les événements de programmes malveillants (fichiers malveillants uniquement) de la passerelle et les événements d'anomalie réseau de NSX Intelligence.

    • Les événements IDPS de passerelle (Tech Preview) ne sont pas collectés par NSX Network Detection and Response dans NSX-T 3.2.

  • La fonctionnalité NSX Network Detection and Response s'exécute dans le cloud et est disponible dans deux régions de cloud : États-Unis et UE.

Pour plus d'informations sur l'activation, l'utilisation, l'administration et le dépannage de la fonctionnalité NSX Network Detection and Response, reportez-vous à la section NSX Network Detection and Response du Guide d'administration de NSX-T Data Center.

VPN

  • Alarmes de niveau de service améliorées pour VPN : détails de l'état du service IPSec.

  • Détails de journalisation supplémentaires pour le suivi de paquets : afficher les informations SPI et Exchange pour IPSec.

Guest Introspection

  • Améliorations de Guest Introspection : Guest Introspection fournit un ensemble d'API dans le plan de données pour une consommation dans le contexte d'invité. Cette amélioration garantit que seuls les utilisateurs disposant de droits appropriés disposent de cet accès.

  • Prise en charge supplémentaire du système d'exploitation pour GI : Guest Introspection prend désormais en charge CentOS 8.2, RHEL 8.2, SLES15 SP1, Ubuntu 20.04.

Fédération

Note:

si les versions NSX antérieures à la version 3.2.0 prennent en charge l'intégration des sites de gestionnaires locaux existants, cette prise en charge de l'intégration est retardée de la version 3.2.0 et sera réintroduite dans une version ultérieure de 3.2.

  • Prise en charge de la réplication de balises de machines virtuelles entre les gestionnaires locaux : pendant la récupération d'urgence (DR), les machines virtuelles répliquées sont redémarrées dans l'emplacement de récupération d'urgence. Si la stratégie de sécurité est basée sur les balises de machine virtuelle NSX, les machines virtuelles répliquées dans l'emplacement DR doivent avoir ces balises NSX sur le gestionnaire local distant au moment de la récupération. NSX fédération 3.2 prend désormais en charge la réplication de balises de machine virtuelle entre les gestionnaires locaux. La stratégie de réplication des balises est configurable uniquement via l'API.

  • Surveillance des communications de fédération : la page du gestionnaire d'emplacements offre désormais une vue de la latence et de l'utilisation des canaux entre les gestionnaires globaux et les gestionnaires locaux. Cela fournit une meilleure visibilité de la santé entre les différents composants de la fédération.

  • Brouillons de pare-feu : le brouillon des stratégies de sécurité est désormais disponible sur le gestionnaire global. Cela inclut la prise en charge des brouillons automatiques et des brouillons manuels.

  • Prise en charge du gestionnaire global LDAP : le gestionnaire global prend désormais en charge la configuration des sources LDAP pour le contrôle d'accès basé sur les rôles (RBAC) de la même manière que pour les gestionnaires locaux.

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

  • Intégration d'Antrea à NSX-T : ajout de la possibilité de définir des stratégies réseau Antrea à partir de l'interface utilisateur du pare-feu distribué NSX-T. Les stratégies sont appliquées aux clusters K8s exécutant Antrea 1.3.1-1.2.2 à l'aide du contrôleur d'interfonctionnement. Ajoute également la collecte d'inventaire : Les objets K8s tels que les espaces, les espaces de noms et les services sont collectés dans l'inventaire NSX-T et balisés pour pouvoir être sélectionnés dans les stratégies DFW. Antrea Traceflow peut désormais être contrôlé à partir de la page de l'interface utilisateur de NSX-T Traceflow et les bundles de journaux peuvent être collectés à partir de clusters K8s à l'aide d'Antrea. Il n'est pas obligatoire d'activer le plan de données NSX-T sur vos nœuds de cluster K8s Antrea.

  • Améliorations du regroupement : ajout de la prise en charge des objets de conteneur Antrea. Ajout de la prise en charge de l'opérateur En dehors de sur les critères de balise de port de segment. Ajoute la prise en charge de l'opérateur AND entre les critères d'appartenance au groupe impliquant des segments et des ports de segment.

Équilibrage de charge

  • L'installation de VMware NSX Advanced Load Balancer (Avi) via les contrôleurs NSX : VMware NSX Advanced Load Balancer (Avi) peut désormais être installé via l'interface utilisateur de NSX-T Manager, qui fournit un volet unique pour l'installation de tous les composants NSX.

  • Interface utilisateur cross-launch de VMware NSX Advanced Load Balancer (Avi) à partir de l'interface utilisateur de NSX-T Manager : lancez l'interface utilisateur de VMware NSX ALB (Avi) à partir de NSX-T Manager pour des fonctionnalités avancées.

  • Interfaces utilisateur d'Advanced Load Balancer (Avi) affichées dans NSX : configurez VMware NSX Advanced Load Balancer (Avi) dans NSX Manager.

  • Migrez l'équilibrage de charge de NSX for vSphere vers VMware NSX Advanced Load Balancer (Avi) : migrez les équilibreurs de charge vers VMware NSX ALB (Avi) lors de l'utilisation du modèle Utiliser votre propre topologie avec le coordinateur de migration.

  • Cas d'équilibreur de charge distribué (DLB) pour vSphere with Kubernetes (K8s)

    • Prise en charge du système de détection des intrusions distribué (DIDS) et de DLB pour fonctionner ensemble.

    • Prise en charge vMotion.

    • Algorithme de sélection de membre de pool DLB supplémentaire : Hachage à connexion minimale et IP source.

    • Commandes de dépannage supplémentaires.

  • Équilibreur de charge natif NSX-T : les fonctionnalités d'équilibrage de charge ne seront pas ajoutées ou améliorées ultérieurement. Les améliorations apportées à la plate-forme NSX-T ne sont pas étendues à l'équilibreur de charge natif NSX-T.

  • Recommandation d'équilibrage de charge

    • Si vous utilisez l'équilibrage de charge dans NSX-T, il est recommandé de migrer vers VMware NSX Advanced Load Balancer (Avi), qui fournit un sur-ensemble de la fonctionnalité d'équilibrage de charge NSX-T.

    • Si vous avez acheté NSX Data Center Advanced, NSX Data Center Enterprise Plus, NSX Advanced ou NSX Enterprise, vous êtes autorisé à utiliser l'édition Basic de VMware NSX Advanced Load Balancer (Avi), qui dispose de la parité des fonctionnalités avec NSX-T LB.

    • Il est recommandé 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 WAF.

Note:

il est recommandé que les nouveaux déploiements avec NSX-T Data Center tirent parti de VMware NSX Advanced Load Balancer (Avi) à l'aide de la version v20.1.6 ou ultérieure et n'utilisent pas l'équilibreur de charge NSX-T natif.

Pour plus d'informations :

NSX Cloud

  • Prise en charge étendue du système d'exploitation sur NSX Cloud : NSX Cloud prend désormais en charge le système d'exploitation suivant, en plus de celui déjà pris en charge :

    • Ubuntu 20.04

    • RHEL 8.next

  • Prise en charge NSX Cloud des fonctionnalités de sécurité avancée (couche 7) sur PCG (🔎Tech Preview , pas pour les déploiements de production) : NSX Cloud offre certaines fonctionnalités de sécurité avancée (couche 7) sur la PCG sur Azure et AWS, ce qui vous permet de tirer parti de la sécurité de la couche d'application pour vos charges de travail dans le cloud public. Vous pouvez essayer l'ensemble de fonctionnalités dans des déploiements hors production.

  • Prise en charge NSX Cloud d'IDFW pour VDI mono-utilisateur (🔎Tech Preview , pas pour les déploiements de production) : NSX Cloud offre un pare-feu d'identité pour offrir une sécurité basée sur l'utilisateur pour le déploiement VDI. Il pourra associer à une machine virtuelle un profil de sécurité mappé à l'utilisateur connecté, ce qui simplifie la gestion de la sécurité et renforce la sécurité. Vous pouvez essayer l'ensemble de fonctionnalités dans des déploiements hors production.

Opérations et surveillance

  • Commande del nsx pour nettoyer NSX sur un serveur physique/bare metal : en continuité avec la prise en charge de la fonctionnalité del nsx sur les serveurs ESX, une commande CLI del nsx est disponible pour supprimer NSX d'un serveur physique/bare metal exécutant un système d'exploitation Linux. Si vous disposez d'un serveur physique/bare metal avec des VIB NSX dans un état périmé et que vous ne parvenez pas à désinstaller NSX de cet hôte, vous pouvez vous connecter à l'hôte et utiliser la commande CLI del nsx pour effectuer un processus pas à pas guidé afin de supprimer NSX de cet hôte et le ramener à un état propre pour pouvoir le réinstaller complètement.

  • Analyse du trafic en direct via l'interface utilisateur de NSX Manager : la fonctionnalité Analyse du trafic en direct est désormais disponible dans l'interface utilisateur de NSX Manager, ce qui vous permet d'analyser facilement les flux de trafic en direct entre les centres de données. Cette fonctionnalité offre une approche unifiée du diagnostic en combinant Traceflow et la capture de paquets. Vous pouvez effectuer les deux actions en une seule capture : suivre les paquets en direct et effectuer la capture de paquets à la source. L'analyse du trafic en direct permet de déterminer avec précision les problèmes de trafic réseau et offre la possibilité d'effectuer l'analyse sur des flux spécifiques afin d'éviter le bruit.

  • Mise en miroir sélective de ports : mise en miroir améliorée avec une capacité de filtrage basé sur le flux et des exigences de ressources réduites. Vous pouvez désormais vous concentrer sur les flux pertinents pour un dépannage efficace.

  • Vérification de la configuration de la MTU d'infrastructure : une vérification de MTU à la demande et périodique sera disponible sur l'interface utilisateur de NSX Manager pour vérifier la configuration MTU pour le réseau de superposition ; des alertes sont déclenchées en cas d'incompatibilité de MTU.

  • Prise en charge de Traceflow sur un réseau logique reposant sur VLAN : vous pouvez exécuter Traceflow sur un réseau logique reposant sur un VLAN. Cette fonctionnalité est disponible via l'API.

  • Amélioration de la journalisation : journalisation améliorée en détectant et en supprimant les messages de journaux répétitifs émis trop fréquemment pour éviter que des messages de journaux importants ne soient perdus ou dégradés.

  • Guide de la CLI amélioré et commandes supplémentaires : introduit un ensemble de nouvelles commandes CLI mappées avec les constructions d'interface utilisateur (stratégie) comme pour le segment d'instance. Cela permet une consommation plus simple de l'interface de CLI pour les utilisateurs. Un guide d'interface de CLI entièrement refactorisé a également été introduit pour simplifier la consommation.

  • Limites de capacité : le tableau de bord Capacité reconnaît désormais la taille de déploiement de NSX Manager pour certaines limites de capacité et peut générer des alarmes lorsque la capacité recommandée après la mise à niveau vers NSX-T 3.2 est dépassée. Les clients qui ont besoin de capacité supplémentaire sont invités à effectuer une mise à niveau d'une instance de NSX Manager de taille moyenne vers une instance de NSX Manager de grande taille ou à réduire l'utilisation pour rester pris en charge.

Surveillance

  • Surveillance de séries chronologiques : permet de collecter et de stocker des mesures pour une durée plus longue, jusqu'à un an, avec NSX Application Platform. Les mesures chronologiques aident à surveiller la tendance des indicateurs de performance clés, à effectuer des analyses avant et après, et fournissent le contexte historique utile pour le dépannage. Des mesures de séries chronologiques sont disponibles pour le nœud Edge, les passerelles de niveau 0 et de niveau 1, NSX Manager, NSX Application Platform et les fonctionnalités de sécurité, qui incluent l'inspection TLS, IDPS, le pare-feu de passerelle. Ces mesures de séries chronologiques sont disponibles via les API NSX-T et un sous-ensemble de ces mesures est également disponible dans l'interface utilisateur de NSX Manager.

  • Événements et alarmes

    • Certificats : mise à jour du bundle d'autorité de certification recommandée

    • Opération : cluster hors service, cluster non disponible, canal de gestion vers le nœud de gestionnaire inactif, canal de gestion vers le nœud de gestionnaire inactif pendant longtemps

    • Fédération : avertissement de latence de GM à GM, avertissement de synchronisation de GM à GM, erreur de synchronisation de GM à GM, avertissement de latence de GM à LM, avertissement de synchronisation de GM à LM, erreur de synchronisation de GM à LM, restauration de LM pendant l'importation de la configuration, seuil d'occupation de la file d'attente dépassé

    • Santé du nœud de transport : liaison montante du nœud de transport inactive

    • Pare-feu distribué : nombre élevé de sessions DFW, échec de DFW VMotion

    • Edge : les paramètres du nœud Edge et les paramètres de vSphere sont modifiés, les paramètres de nœud Edge ne correspondent pas, les paramètres de la VM Edge vSphere ne correspondent pas, l'emplacement du dispositif Edge vSphere ne correspond pas

    • Santé du dispositif Edge : débit élevé de la carte réseau du chemin de données Edge, débit très élevé de la carte réseau du chemin de données Edge, domaine de pannes inactif

    • VPN : service IPSec inactif

    • NAT : l'utilisation du port SNAT sur la passerelle est élevée

    • Équilibrage de charge : configuration de l'équilibrage de charge non réalisée en raison d'un manque de mémoire

    • Vérification de la MTU : incompatibilité de MTU dans la zone de transport, MTU du routeur global trop volumineuse

    • Communication de NSX Application Platform : retard détecté lors du dépassement de capacité de messagerie, retard détecté dans le flux brut de messagerie, exportateur de flux TN déconnecté

    • Santé de NSX Application Platform : environ 55 alarmes pour surveiller la santé de la plate-forme

Convivialité et interface utilisateur

  • Personnaliser les messages et les bannières de connexion :vous pouvez configurer et personnaliser le message de connexion à partir de NSX Manager et spécifier les champs obligatoires que l'utilisateur doit accepter avant de se connecter.

  • Améliorations de la recherche et des filtres : amélioration de la capacité de recherche et de filtrage existante dans l'interface utilisateur de NSX. Un écran initial affiche les expressions de recherche possibles et les éléments recherchés les plus récemment. Un panneau distinct est disponible pour « Recherche avancée » qui permet aux utilisateurs de personnaliser et de configurer les « Recherches ». Les requêtes de recherche renvoient désormais des informations à partir de balises et d'alarmes.

  • VPAT : correctifs pour réduire l'écart d'accessibilité dans le produit.

  • Topologie NSX : visualiser l'infrastructure sous-jacente associée aux passerelles. Cette fonctionnalité vous permet de visualiser les clusters Edge, la configuration du commutateur d'hôte et d'obtenir des détails sur les configurations de l'hôte et du dispositif Edge.

  • Amélioration de la convivialité du sélecteur d'objets dans l'interface utilisateur : cette fonctionnalité permet de sélectionner plusieurs objets de la même catégorie. En outre, vous pouvez sélectionner tous les objets.

  • Nouvelle présentation de la sécurité : page Nouvelle présentation de la sécurité pour fournir une vue holistique des configurations de sécurité. Vous pouvez afficher « Menaces et réponses » dans différentes fonctionnalités, ainsi que la configuration et la capacité existantes du système.

  • L'interface utilisateur de NSX-T intégrée dans vCenter  NSX-T peut désormais être installé et configuré via l'interface utilisateur de vCenter avec le plug-in vCenter pour NSX-T. Cette fonctionnalité est prise en charge UNIQUEMENT à partir de vCenter 7.0U3 et versions ultérieures.

  • Assistant de déploiement de NSX-T pour les cas d'utilisation courants : lorsqu'il est installé via le plug-in vCenter, NSX-T peut désormais activer les fonctionnalités NSX-T basées sur des cas d'utilisation courants, ce qui permet aux utilisateurs d'activer rapidement des fonctionnalités NSX-T exploitant les assistants de déploiement. Cette version prend en charge deux assistants, l'un pour activer les fonctionnalités de sécurité de NSX et l'autre pour activer les fonctionnalités de mise en réseau virtuelle de NSX.

Stratégie

  • Outil de promotion de NSX Manager vers la stratégie NSX : permet de promouvoir la configuration existante de NSX Manager à la stratégie NSX sans interruption du chemin de données ni suppression/recréation d'objets existants. Une fois que les objets NSX Manager sont promus vers la stratégie NSX, les objets de NSX Manager sont définis en lecture seule via l'interface utilisateur/l'API du gestionnaire, et vous pouvez interagir avec les mêmes objets via l'interface utilisateur/l'API de stratégie de NSX.

AAA et sécurité de la plateforme

  • Améliorations de la gestion des certificats pour l'inspection TLS (🔎Tech Preview, pas pour les déploiements de production) : avec l'introduction de la fonctionnalité d'inspection TLS, la gestion des certificats prend désormais en charge l'ajout et la modification des bundles de certification et la possibilité de générer des certificats d'autorité de certification à utiliser avec la fonctionnalité d'inspection TLS. En outre, l'interface utilisateur générale de gestion des certificats peut apporter des modifications qui simplifient l'importation/exportation des certificats.

  • Améliorations de la haute disponibilité et de l'échelle pour l'intégration LDAP : la configuration LDAP prend désormais en charge la configuration de plusieurs serveurs LDAP par domaine et la prise en charge de la « confiance » de plusieurs certificats associés à différents serveurs LDAP par domaine.

Échelle

  • Augmentation de l'échelle : il existe plusieurs augmentations de l'échelle prise en charge pour les déploiements les plus importants. Pour plus d'informations sur les changements d'échelle consultez l'outil VMware Configuration Maximums.

Attribution de licences

  • Application de la licence : NSX-T s'assure désormais que les utilisateurs sont conformes à la licence en restreignant l'accès aux fonctionnalités en fonction de l'édition de la licence. Les nouveaux utilisateurs peuvent accéder uniquement aux fonctionnalités disponibles dans l'édition qu'ils ont achetée. Les utilisateurs existants qui ont utilisé des fonctionnalités ne figurant pas dans leur édition de licence sont limités à l'affichage des objets uniquement ; la création et la modification ne seront pas autorisées.

  • Nouvelles licences : ajout de la prise en charge du nouveau pare-feu de passerelle VMware NSX et du module complémentaire de fédération NSX et continue de prendre en charge les licences NSX Data Center (Standard, Professional, Advanced, Enterprise Plus, Remote Office Branch Office) introduites en juin 2018 et les clés de licence VMware NSX for vSphere précédentes. Pour plus d'informations sur les licences NSX, reportez-vous à l'article 52462 de la base de connaissances de VMware.

Migration de NSX Data Center for vSphere vers NSX-T Data Center

  • Migration pour VMware Integrated OpenStack : ajout de la possibilité d'effectuer une migration NSX for vSphere vers NSX-T dans des environnements VIO sans interrompre la représentation OpenStack des objets. Cette fonctionnalité nécessite la prise en charge des capacités de migration par la version VMware Integrated OpenStack utilisée.

  • Utiliser votre propre topologie : le coordinateur de migration étend son modèle pour proposer la migration entre NSX for vSphere et une topologie définie par l'utilisateur dans NSX-T. Cela permet aux utilisateurs de définir leur topologie NSX-T et d'étendre le nombre de topologies pouvant être migrées de NSX for vSphere vers NSX-T.

    Cette fonctionnalité ne peut être utilisée que pour la migration de configuration afin d'activer lift-and-shift ou dans le cadre de l'exécution complète du workflow de migration en place.

  • Prise en charge de la migration OSPF pour les topologies fixes : le coordinateur de migration prend en charge les topologies fixes avec OSPF (au lieu de BGP et statiques). Cela permet aux utilisateurs souhaitant utiliser des topologies fixes (et non BYOT) de le faire même lorsqu'OSP est configuré pour la connectivité N/S entre esg et le haut du rack (OSPF entre ESG et DLR était déjà pris en charge et remplacé par le routage interne NSX-T).

  • Augmentation de l'échelle du coordinateur de migration : l'échelle du coordinateur de migration augmente afin de couvrir des environnements plus importants et de se rapprocher de l'échelle maximale de NSX for vSphere.

  • Migration de Guest Introspection : la migration de NSX for vSphere vers NSX-T pour GI est désormais ajoutée au coordinateur de migration. Vous pouvez utiliser cette fonctionnalité à condition que le fournisseur partenaire prenne également en charge le coordinateur de migration.

  • Migration IDFW/RDSH : le coordinateur de migration prend désormais en charge les configurations de pare-feu basées sur l'identité.

Fonctionnalités de Tech Preview

NSX-T Data Center 3.2 offre plusieurs fonctionnalités pour votre version d'évaluation technique. Les fonctionnalités de la version d'évaluation technique ne sont pas prises en charge par VMware pour une utilisation en production. Elles ne sont pas entièrement testées et certaines fonctionnalités peuvent ne pas fonctionner comme prévu. Cependant, ces aperçus aident VMware à améliorer la fonctionnalité NSX-T actuelle et à développer de futures améliorations.

Pour plus d'informations sur ces fonctionnalités de la version d'évaluation technique, reportez-vous à la documentation disponible fournie dans le Guide d'administration de NSX-T Data Center 3.2. Des liens sont fournis dans la liste suivante qui décrit brièvement ces fonctionnalités de la version d'évaluation technique. Le titre des rubriques s'affichera avec Version d'évaluation technique.

Terminologie inclusive

Chez VMware, nous privilégions l'inclusion et la diversité. Pour promouvoir ces principes au sein de nos communautés de clients, de partenaires et internes, des efforts sont déployés à l'échelle de l'entreprise pour remplacer le langage non inclusif dans nos produits. La terminologie problématique dans l'interface utilisateur de NSX-T Data Center, la documentation, les API, les interfaces de ligne de commande et les journaux sont en cours de remplacement par des alternatives plus inclusives. Par exemple, le terme non inclusif disabled a été remplacé par le terme deactivate.

Compatibilité et configuration système requise

Pour plus d'informations sur la compatibilité et la configuration système requise, consultez les Matrices d'interopérabilité des produits VMware et le Guide d'installation de NSX-T Data Center.

Obsolescences de fonctionnalité/API et changements de comportement

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

NSX-T 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 stratégie 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 gestionnaire et des interfaces utilisateurs avancées de NSX dans une prochaine version mineure ou majeure de NSX-T, 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 gestionnaire de NSX-T 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-T 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.

Avis d'obsolescence du commutateur d'hôte N-VDS NSX-T

NSX-T 3.0.0 et versions ultérieures peuvent s'exécuter sur le commutateur vSphere VDS version 7.0 et ultérieures. Cela permet une intégration plus étroite à vSphere et une adoption de NSX-T plus facile pour les clients qui ajoutent NSX-T à leur environnement vSphere.

Notez que VMware a l'intention de supprimer la prise en charge du commutateur virtuel N-VDS NSX-T sur les hôtes ESXi dans une prochaine version de NSX-T, qui sera généralement disponible au moins un an après la date de ce message, (le 17 avril 2021). N-VDS restera le commutateur virtuel pris en charge sur KVM, les nœuds NSX-T Edge, les agents de gestion de cloud public NSX natifs et les charges de travail bare metal.

Il est recommandé que les nouveaux déploiements de NSX-T et de vSphere profitent de cette intégration étroite et qu'ils se déploient à l'aide du commutateur VDS version 7.0 et ultérieures. En outre, pour les déploiements existants de NSX-T qui utilisent le N-VDS sur des hôtes ESXi, VMware recommande de passer à l'utilisation de NSX-T sur VDS. Pour faciliter ce processus, VMware a fourni un outil de migration de commutateur basé sur la CLI, qui a été mis à disposition pour la première fois dans NSX-T 3.0.2, et un outil de disponibilité de mise à niveau basé sur l'interface graphique, qui a été mis à disposition pour la première fois dans NSX-T 3.1.1 (voir la documentation de NSX pour plus de détails sur ces outils).

Note:

dans NSX-T 3.2.0, l'outil de migration N-VDS vers VDS n'est pas disponible. Les clients qui souhaitent migrer leurs charges de travail de N-VDS vers VDS dans cette version peuvent le faire en migrant manuellement les charges de travail.

Les considérations de déploiement suivantes sont recommandées lors du passage de N-VDS à VDS :

  • Les API N-VDS et VDS sont différentes, et le type de sauvegarde pour les API de machine virtuelle et d'interface vmKernel pour les commutateurs N-VDS et VDS est également différent. Tandis que vous utilisez VDS dans votre environnement, vous devrez commencer par appeler les API VDS au lieu des API N-VDS. Cette modification de l'écosystème devra être effectuée avant de convertir le N-VDS en VDS. Pour obtenir plus d'informations, reportez-vous à l'article 79872 de la base de connaissances. Remarque : Aucune modification n'est apportée aux API N-VDS ou VDS.

  • VDS est configuré via vCenter. Le N-VDS est indépendant de vCenter. Grâce à la prise en charge de NSX-T sur VDS et à l'obsolescence finale de N-VDS, NSX-T sera étroitement lié à vCenter et vCenter sera nécessaire pour activer NSX dans des environnements vSphere.

OpenStack et KVM

La série de versions 3.x est la dernière série permettant de prendre en charge les distributions KVM et non-VIO OpenStack, notamment RedHat OpenStack Platform, Canonical/Ubuntu OpenStack, SUSE OpenStack Cloud, OpenStack et les OpenStack basés sur la communauté, qui n'ont pas de fournisseur spécifique. Les clients qui utilisent des OpenStack non-VIO avec NSX sont encouragés à envisager vRealize Automation ou VMware Cloud Director comme remplacement de leurs déploiements.

Avis d'obsolescence pour les API d'équilibrage de charge NSX-T

Les API NSX-T API d'équilibreur de charge sont marquées comme obsolètes. Cela s'appliquerait à toutes les API contenant des URI qui commencent par /policy/api/v1/infra/lb-

Notez que VMware a l'intention de supprimer la prise en charge de l'équilibreur de charge NSX-T dans une prochaine version de NSX-T, qui sera généralement disponible au moins un an après la date de ce message (16 décembre 2021). Les API de gestionnaire de NSX-T qui sont prévues pour être supprimées sont marquées comme « obsolètes » dans le Guide des API de NSX Data Center.

Il est recommandé que les nouveaux déploiements avec NSX-T Data Center tirent parti de VMware NSX Advanced Load Balancer (Avi) à l'aide de la version v20.1.6 ou version ultérieure.

Note:

l'obsolescence de l'API ne s'applique pas à l'équilibreur de charge distribué.

Alarmes

  • Alarmes de communication de NSX Intelligence remplacées par les alarmes de communication de NSX Application Platform.

  • Alarmes de santé de NSX Intelligence remplacées par les alarmes de santé de NSX Application Platform.

  • DNS : alarme Redirecteur désactivé.

  • Service d'infrastructure : l'alarme État inactif du service Edge sera couverte dans le cadre de l'alarme Modification de l'état du service Edge.

  • Santé du nœud de transport : l'alarme Liaison montante inactive NVDS a été remplacée par l'alarme Liaison montante inactive du nœud de transport.

Désapprobation et modifications de l'API d'analyse du trafic en direct

  • Les API MP d'analyse du trafic en direct sont marquées comme obsolètes dans NSX-T 3.2.0.

  • L'option Nombre de paquets est supprimée de l'analyse du trafic en direct dans NSX-T 3.2.0. L'analyse du trafic en direct continuera à prendre en charge le suivi et la capture de paquets.

  • Les champs et les types suivants sont supprimés :

    • API de stratégie : Champs - count_config, Types - PolicyCountObservation

    • API MP : Champs : count_config, count_results, Types - CountActionConfig, LiveTraceActionType (NOMBRE : action non prise en charge), CountActionArgument, CountResult, CountObservation, BaseCountObservation

Obsolescences de l'API et changements de comportement

  • Suppression d'API NSX obsolètes : les API suivantes ont été supprimées il y a plus d'un an et sont supprimées dans NSX-T 3.2.0.

    API supprimée

    Remplacement

    GET api/v1/hpm/alarms

    Remplacé par /api/v1/alarms

    POST /fabric/nodes

    POST /api/v1/transport-nodes

    POST /fabric/nodes/<node-id>?action=restart_inventory_sync

    POST /api/v1/transport-nodes/<node-id>?action=restart_inventory_sync

    POST /api/v1/fabric/discovered-nodes/<node-ext-id>?action=hostprep

    POST /api/v1/fabric/discovered-nodes/<node-ext-id>?action=create_transport_node

    GET /fabric/nodes

    GET /api/v1/transport-nodes

    GET /fabric/nodes/<node-id>

    GET /api/v1/transport-nodes/<node-id>

    POST /fabric/nodes/<node-id>

    POST /api/v1/transport-nodes/<node-id>

    PUT /fabric/nodes/<node-id>

    PUT /api/v1/transport-nodes/<node-id>

    DELETE /fabric/nodes/<node-id>

    DELETE /api/v1/transport-nodes/<node-id>

    GET /fabric/nodes/<node-id>/status

    GET /api/v1/transport-nodes/<node-id>/status

    GET /fabric/nodes/status

    GET /api/v1/transport-nodes/<node-id>/status

    GET /fabric/nodes/<node-id>/capabilities

    GET /api/v1/transport-nodes/<node-id>/capabilities

    POST /fabric/nodes/<node-id>?action=<enter/exit>_maintenance_mode

    Aucun remplacement dans NSX-T API.

    GET /fabric/nodes/<node-id>/state

    GET /api/v1/transport-nodes/<node-id>/state

    GET /fabric/nodes/<node-id>/modules

    GET /api/v1/transport-nodes/<node-id>/modules

    POST /fabric/nodes/<node-id>?action=upgrade_infra

    Aucun remplacement dans NSX-T API.

    GET /fabric/nodes/<node-id>/network/interfaces

    GET /api/v1/transport-nodes/<node-id>/interfaces

    GET /fabric/nodes/<node-id>/network/interfaces/<interface-id>

    GET /api/v1/transport-nodes/<node-id>/interfaces/<interface-id>

    GET /fabric/compute-collection-fabric-templates

    Workflows gérés différemment à l'aide des API de profil de nœud de transport (TNP) et de collecte de nœuds de transport (TNC)

    POST /fabric/compute-collection-fabric-templates

    Workflows gérés différemment à l'aide des API de profil de nœud de transport (TNP) et de collecte de nœuds de transport (TNC)

    DELETE /fabric/compute-collection-fabric-templates/<fabric-template-id>

    Workflows gérés différemment à l'aide des API de profil de nœud de transport (TNP) et de collecte de nœuds de transport (TNC)

    PUT /fabric/compute-collection-fabric-templates/<fabric-template-id>

    Workflows gérés différemment à l'aide des API de profil de nœud de transport (TNP) et de collecte de nœuds de transport (TNC)

    GET /fabric/compute-collection-fabric-templates/<fabric-template-id>

    Workflows gérés différemment à l'aide des API de profil de nœud de transport (TNP) et de collecte de nœuds de transport (TNC)

    GET /fabric/compute-collection-transport-node-templates

    Workflows gérés différemment à l'aide des API de profil de nœud de transport (TNP) et de collecte de nœuds de transport (TNC)

    POST /fabric/compute-collection-transport-node-templates

    Workflows gérés différemment à l'aide des API de profil de nœud de transport (TNP) et de collecte de nœuds de transport (TNC)

    DELETE /fabric/compute-collection-transport-node-templates/<transport-node-template-id>

    Workflows gérés différemment à l'aide des API de profil de nœud de transport (TNP) et de collecte de nœuds de transport (TNC)

    PUT /fabric/compute-collection-transport-node-templates/<transport-node-template-id>

    Workflows gérés différemment à l'aide des API de profil de nœud de transport (TNP) et de collecte de nœuds de transport (TNC)

    GET /fabric/compute-collection-transport-node-templates/<transport-node-template-id>

    Workflows gérés différemment à l'aide des API de profil de nœud de transport (TNP) et de collecte de nœuds de transport (TNC)

    GET /api/v1/ipfix-obs-points/switch-global

    Utilisez /api/v1/ipfix-profiles/<ipfix-profile-id> pour le profil IPFIX de commutateur et /api/v1/ipfix-collector-profiles/<ipfix-collector-profile-id> pour le profil de collecteur IPFIX.

    PUT /api/v1/ipfix-obs-points/switch-global

    Utilisez /api/v1/ipfix-profiles/<ipfix-profile-id> pour le profil IPFIX du commutateur et /api/v1/ipfix-collector-profiles/<ipfix-collector-profile-id> pour le profil de collecteur IPFIX.

    GET /api/v1/ipfix-obs-points

    Utilisez /api/v1/ipfix-profiles pour le profil IPFIX de commutateur et /api/v1/ipfix-collector-profiles pour le profil de collecteur IPFIX

    GET /infra/ipfix-collector-profiles

    GET /policy/api/v1/infra/ipfix-l2-collector-profiles

    GET /infra/ipfix-collector-profiles/<ipfix-collector-profile-id>

    GET /policy/api/v1/infra/ipfix-l2-collector-profiles/<ipfix-collector-profile-id>

    PUT /infra/ipfix-collector-profiles/<ipfix-collector-profile-id>

    PUT /policy/api/v1/infra/ipfix-l2-collector-profiles/<ipfix-collector-profile-id>

    PATCH /infra/ipfix-collector-profiles/<ipfix-collector-profile-id>

    PATCH /policy/api/v1/infra/ipfix-l2-collector-profiles/<ipfix-collector-profile-id>

    DELETE /infra/ipfix-collector-profiles/<ipfix-collector-profile-id>

    DELETE /policy/api/v1/infra/ipfix-l2-collector-profiles/<ipfix-collector-profile-id>

    GET /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances

    GET /policy/api/v1/infra/ipfix-l2-profiles

    GET /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances/<ipfix-switch-collection-instance-id>

    GET /policy/api/v1/infra/ipfix-l2-profiles/<ipfix-switch-collection-instance-id>

    PUT /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances/<ipfix-switch-collection-instance-id>

    PUT /policy/api/v1/infra/ipfix-l2-profiles/<ipfix-switch-collection-instance-id>

    PATCH /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances/<ipfix-switch-collection-instance-id>

    PATCH /policy/api/v1/infra/ipfix-l2-profiles/<ipfix-switch-collection-instance-id>

    DELETE /infra/tier-1s/<tier-1-id>/ipfix-switch-collection-instances/<ipfix-switch-collection-instance-id>

    DELETE /policy/api/v1/infra/ipfix-l2-profiles/<ipfix-switch-collection-instance-id>

    GET /api/v1/node/services/mgmt-plane-bus

    L'API a été supprimée suite aux modifications apportées à l'architecture interne dans NSX-T

    POST /api/v1/node/services/mgmt-plane-bus?action=restart|start|stop

    L'API a été supprimée suite aux modifications apportées à l'architecture interne dans NSX-T

    GET /api/v1/node/services/mgmt-plane-bus/status

    L'API a été supprimée suite aux modifications apportées à l'architecture interne dans NSX-T

    DELETE /api/v1/node/rabbitmq-management-port

    L'API a été supprimée suite aux modifications apportées à l'architecture interne dans NSX-T

    GET /api/v1/node/rabbitmq-management-port

    L'API a été supprimée suite aux modifications apportées à l'architecture interne dans NSX-T

    POST /api/v1/node/rabbitmq-management-port

    L'API a été supprimée suite aux modifications apportées à l'architecture interne dans NSX-T

    GET /api/v1/node/services/intelligence-upgrade-coordinator

    L'API a été supprimée de NSX-T Manager, car NSX Intelligence est désormais hébergé sur NSX Application Platform

    POST /api/v1/node/services/intelligence-upgrade-coordinator?action=start|stop|restart

    L'API a été supprimée de NSX-T Manager, car NSX Intelligence est désormais hébergé sur NSX Application Platform

    GET /api/v1/node/services/intelligence-upgrade-coordinator/status

    L'API a été supprimée de NSX-T Manager, car NSX Intelligence est désormais hébergé sur NSX Application Platform

    GET /api/v1/bridge-clusters

    Ces API ont été utilisées pour configurer le pont sur ESXi, qui est une fonctionnalité obsolète et supprimée. Le pontage est pris en charge et le cluster Edge peut être configuré sur le segment avec des profils de pont Edge. (Reportez-vous à la documentation du pont Edge)

    POST /api/v1/bridge-clusters

    Ces API ont été utilisées pour configurer le pont sur ESXi, qui est une fonctionnalité obsolète et supprimée. Le pontage est pris en charge et le cluster Edge peut être configuré sur le segment avec des profils de pont Edge. (Reportez-vous à la documentation du pont Edge)

  • Suppression de champs d'API NSX obsolètes : les champs d'API suivants ont été supprimés il y a plus d'un an et sont supprimés dans NSX-T 3.2.0. (L'API elle-même n'est pas supprimée, seul le champ mentionné.)

    • Suppression du champ API de la zone de transport :

      POST /api/v1/transport-zones
{
     "display_name":"tz1",
     "host_switch_name":"test-host-switch-1", <<==== WILL BE REMOVED
     "host_switch_mode":  "STANDARD", <<==== WILL BE REMOVED
     "description":"Transport Zone 1",
     "transport_type":"OVERLAY"
}

    • Suppression du champ API du nœud de transport pour la VM du nœud Edge :

      POST /api/v1/transport-nodes
POST /api/v1/transport-node-profiles
{
"node_id": "92f893b0-1157-4926-9ce3-a1787100426c",
"host_switch_spec": {
"host_switches": [
{
...
...
"transport_zone_endpoints": [ <<<==== SHOULD BE USED INSTEAD
{
"transport_zone_id": "1b3a2f36-bfd1-443e-a0f6-4de01abc963e"
}
],
}
],
"resource_type": "StandardHostSwitchSpec"
},
"transport_zone_endpoints": [], <<<<=== WILL BE REMOVED
"node_deployment_info": {
"deployment_type": "VIRTUAL_MACHINE",
"deployment_config": {
"vm_deployment_config": {
"vc_id": "23eaf46e-d826-4ead-9aad-ed067574efb7",
"compute_id": "domain-c7",
"storage_id": "datastore-22",
"management_network_id": "network-24",
"hostname": "edge", <-- will be removed
"data_network_ids": [
"network-24"
],
"search_domains": [ "vmware.com" ] <<<<=== WILL BE REMOVED (replacement in out block)
"dns_servers": [ "10.172.40.1" ], <<<<=== WILL BE REMOVED
"enable_ssh": true, <<<<=== WILL BE REMOVED
"allow_ssh_root_login": true, <<<<=== WILL BE REMOVED
"placement_type": "VsphereDeploymentConfig"
},
...
"node_settings": {
"hostname": "edge", <<<<=== This should be used - REPLACEMENT
"search_domains": ["eng.vmware.com" ], <<<<=== This should be used - REPLACEMENT
"dns_servers": [ "10.195.12.31"], <<<<=== This should be used - REPLACEMENT
"enable_ssh": true, <<<<=== This should be used - REPLACEMENT
"allow_ssh_root_login": true <<<<=== This should be used - REPLACEMENT
},
"resource_type": "EdgeNode",
"id": "90ec1776-f3e2-4bd0-ba1f-a1292cc58707",
...
"display_name": "edge", <<<<=== WILL BE REMOVED (replacement in out block)
"_create_user": "admin", <<<<=== WILL BE REMOVED
"_create_time": 1594956232211, <<<<=== WILL BE REMOVED
"_last_modified_user": "admin", <<<<=== WILL BE REMOVED
"_last_modified_time": 1594956531314, <<<<=== WILL BE REMOVED
"_system_owned": false, <<<<=== WILL BE REMOVED
"_protection": "NOT_PROTECTED", <<<<=== WILL BE REMOVED
"_revision": 2 <<<<=== WILL BE REMOVED
},
"failure_domain_id": "4fc1e3b0-1cd4-4339-86c8-f76baddbaafb",
"resource_type": "TransportNode",
"id": "90ec1776-f3e2-4bd0-ba1f-a1292cc58707",
"display_name": "edge", <<<<=== This should be used - REPLACEMENT
"_create_user": "admin", <<<<=== This should be used - REPLACEMENT
"_create_time": 1594956232373, <<<<=== This should be used - REPLACEMENT
"_last_modified_user": "admin", <<<<=== This should be used - REPLACEMENT
"_last_modified_time": 1594956531551, <<<<=== This should be used - REPLACEMENT
"_system_owned": false, <<<<=== This should be used - REPLACEMENT
"_protection": "NOT_PROTECTED", <<<<=== This should be used - REPLACEMENT
"_revision": 1 <<<<=== This should be used - REPLACEMENT
}

Notes de mise à niveau de cette version

Pour obtenir des instructions sur la mise à niveau des composants de NSX-T Data Center, consultez le Guide de mise à niveau de NSX-T Data Center.

Les clients qui effectuent une mise à niveau vers NSX-T 3.2.0.1 sont fortement 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.

Ressources relatives aux interfaces de ligne de commande et aux API

Pour utiliser les API ou les interfaces de ligne de commande de NSX-T Data Center pour l'automatisation, consultez developer.vmware.com.

La documentation de l'API est disponible dans l'ongletRéférence de l'API. La documentation de l'interface de ligne de commande est disponible dans l'onglet Documentation.

Langues disponibles

NSX-T Data Center a été localisé dans plusieurs langues : anglais, allemand, français, italien, japonais, chinois simplifié, coréen, chinois traditionnel et espagnol. Étant donné que la localisation de NSX-T Data Center 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

16 décembre 2021

1

Édition initiale.

3 janvier 2022

2

Ajout d'une note à la section Fédération dans Nouveautés.

Ajout du problème connu 2882574.

5 janvier 2022

3

Ajout du problème connu aux Notes de mise à niveau de cette version et aux sections Problèmes connus.

21 janvier 2022

4

Ajout de la section Informations importantes sur NSX-T Data Center 3.2.0.

Ajout d'informations sur l'outil d'évaluation de la mise à niveau NSX dans la section Notes de mise à niveau de cette version.

Ajout du problème connu 2890348.

4 février 2022

5

Prise en charge du pare-feu d'identité pour le protocole SMB.

15 février 2022

6

Ajout d'une puce sur les limites de capacité dans Nouveautés.

22 février 2022

7

Ajout de conditions requises pour le déploiement de NSX Application Platform.

29 avril 2022

8

Ajout des problèmes connus 2885820, 2871440 et 2945515.

Suppression des entrées en double pour les problèmes connus 2685550, 2566121 et 2848614.

5 mai 2022

9

Ajout des problèmes connus 2875563, 2875667, 2883505, 2914934, 2921704 et 2933905.

16 mai 2022

10

Ajout du problème connu 2927442.

6 juin 2022

11

Ajout du problème connu 2937810.

2 août 2022

12

Ajout du problème connu 2989696.

24 août 2022

13

Ajout du problème connu 3015843.

1 septembre 2022

14

Mise à jour des informations sur l'emplacement de la documentation de VMware NSX Network Detection and Response.

7 septembre 2022

15

Ajout du problème connu 3012313.

14 septembre 2022

16

Ajout du problème connu 3025104.

6 février 2023

17

Ajout d'une puce sur les fonctionnalités supplémentaires de l'équilibreur de charge distribué pour vSphere dans Nouveautés.

23 février 2023

18

Mise à jour éditoriale.

Problèmes résolus

  • Problème résolu 2692344 : si vous supprimez le point d'application Avi, il supprime tous les objets réalisés de la stratégie, ce qui supprime toutes les entités réalisées de l'objet par défaut de la stratégie. L'ajout d'un nouveau point d'application ne parvient pas à resynchroniser l'objet par défaut à partir du contrôleur Avi.

    Vous ne pourrez pas utiliser les objets par défaut du système après la suppression et la recréation du point d'application d'AVIConnectionInfo.

  • Problème résolu 2858893 : le nettoyage du déploiement de service échoue pour le déploiement basé sur un cluster.

    Aucune répercussion fonctionnelle. Échec du nettoyage du service si vous tentez d'annuler l'enregistrement de ServiceDefinion avec ServiceDeployment ou des instances non résolus. Vous devez effectuer un nettoyage manuel/forcé à partir de la base de données.

  • Problème résolu 2557287 : les mises à jour de TNP effectuées après la sauvegarde ne sont pas restaurées.

    vous ne verrez aucune mise à jour de TNP effectuée après la sauvegarde sur un dispositif restauré.

  • Problème résolu 2679614 : lorsque le certificat API est remplacé sur le gestionnaire local, l'interface utilisateur du gestionnaire global affiche le message « Une erreur générale s'est produite. »

    Lorsque le certificat API est remplacé sur le gestionnaire local, l'interface utilisateur du gestionnaire global affiche le message « Une erreur générale s'est produite. »

  • Problème résolu 2658687 : l'API de basculement du gestionnaire global signale un échec lorsque la transaction échoue, mais le basculement se produit.

    L'API échoue, mais le basculement du gestionnaire global est effectué.

  • Problème résolu 2652418 : suppression lente lorsqu'un grand nombre d'entités sont supprimées.

    La suppression sera plus lente.

  • Problème résolu 2649499 : la création de règles de pare-feu prend beaucoup de temps lorsque des règles individuelles sont créées l'une après l'autre.

    API lente ; la création de règles prend plus de temps.

  • Problème résolu 2649240 : la suppression est lente lorsqu'un grand nombre d'entités sont supprimées à l'aide d'API de suppression individuelles.

    Il faut beaucoup de temps pour terminer le processus de suppression.

  • Problème résolu 2606452 : l'intégration est bloquée lors d'une tentative d'intégration via l'API.

    l'intégration de l'API échoue avec le message d'erreur « La zone de transport par défaut est introuvable sur le site ».

  • Problème résolu 2587513 : la stratégie affiche une erreur lorsque plusieurs plages VLAN sont configurées dans la liaison de profil de pont.

    Un message d'erreur « ID VLAN NON VALIDES » s'affiche.

  • Problème résolu 2662225 : lorsque le nœud Edge actif devient un nœud Edge non actif pendant le flux de trafic S-N, une perte de trafic se produit.

    Le flux S->N actuel est en cours d'exécution sur le nœud actif de multidiffusion. La route préférée sur les TOR à la source doit se faire via le nœud Edge actif de multidiffusion uniquement. La mise en place d'un autre dispositif Edge peut se faire sur le nœud actif de multidiffusion (le nœud Edge de rang inférieur est un nœud de multidiffusion actif). Le trafic S->N actuel subit une perte de quatre minutes maximum. Cela n'aura pas d'incidence sur le nouveau flux ou si le flux actuel est arrêté et redémarré.

  • Problème résolu 2625009 : Les sessions iBGP inter-SR présentent un bagottement continu, lorsque les routeurs intermédiaires ou les cartes réseau physiques ont une valeur MTU inférieure ou égale à celle du port inter-SR.

    Cela peut avoir un impact sur la connectivité inter-site dans les topologies de fédération.

  • Problème résolu 2521230 : l'état de BFD affiché sous « get bgp neighbor summary » peut ne pas refléter correctement l'état de la dernière session BFD.

    BGP et BFD peuvent configurer leurs sessions indépendamment. Dans le cadre de « get bgp neighbor summary », BGP affiche également l'état de BFD. Si BGP est inactif, il ne traitera aucune notification de BFD et continuera à afficher le dernier état connu. Cela peut entraîner l'affichage d'un état périmé de BFD.

  • Problème résolu 2550492 : pendant une mise à niveau, le message « Les informations d'identification étaient incorrectes ou le compte spécifié a été verrouillé » s'affiche temporairement et le système récupère automatiquement.

    Message d'erreur transitoire lors de la mise à niveau.

  • Problème résolu 2682480 : fausse alarme possible pour l'état de santé de NCP.

    L'alarme d'état de santé de NCP peut ne pas être fiable dans le sens où elle est déclenchée lorsque le système NCP est sain.

  • Problème résolu 2655539 : les noms d'hôtes ne sont pas mis à jour sur la page Gestionnaire d'emplacements de l'interface utilisateur du gestionnaire global lors de la mise à jour des noms d'hôte à l'aide de l'interface de ligne.

    L'ancien nom d'hôte s'affiche.

  • Problème résolu 2631703 : lorsque vous effectuez une sauvegarde/restauration d'un dispositif avec l'intégration vIDM, la configuration de vIDM est interrompue.

    En général, lorsqu'un environnement a été mis à niveau et/ou restauré, toute tentative de restauration d'un dispositif sur lequel l'intégration de vIDM est en cours d'exécution entraîne une interruption de l'intégration et vous devrez reconfigurer.

  • Problème résolu 2730109 : lorsque le dispositif Edge est mis sous tension, il tente d'établir un voisinage OSPF avec l'homologue à l'aide de son adresse IP de liaison de routeur en tant que RouterID OSPF, même si une boucle est présente.

    Après le rechargement du dispositif Edge, OSPF sélectionne l'adresse IP de liaison descendante (adresse IP la plus élevée) comme ID de routeur jusqu'à ce qu'il reçoive la configuration de l'ID de routeur OSPF en raison de l'ordre de séquencement de la configuration. L'entrée du voisin avec l'ancien ID de routeur finit par devenir obsolète lors de la réception de la salutation OSPF avec le nouvel ID de routeur et expire après l'expiration du temporisateur inactif sur l'homologue.

  • Problème résolu 2610851 : les espaces de noms, la collection de calcul, le filtrage de la grille des services L2VPN peuvent ne renvoyer aucune donnée pour quelques combinaisons de filtres de types de ressources.

    L'application de plusieurs filtres pour quelques types en même temps n'a renvoyé aucun résultat, même si les données sont disponibles avec des critères de correspondance. Il ne s'agit pas d'un scénario courant et le filtre n'échouera que pour les combinaisons suivantes d'attributs de filtre : Pour la grille Espaces de noms ==> Sur le filtre Nom du cluster et Nom d'espaces pour la page Topologie réseau ==> Sur le service L2VPN appliquant un filtre IP distant Pour la collecte de calcul ==> Sur le filtre ComputeManager

  • Problème résolu 2482580 : la configuration IDFW/IDS n'est pas mise à jour lorsqu'un cluster IDFW/IDS est supprimé de vCenter.

    Lorsqu'un cluster sur lequel IDFW/IDS est activé est supprimé de vCenter, le plan de gestion NSX n'est pas informé des mises à jour nécessaires. Cela entraîne un nombre exact de clusters IDFW/IDS activés. Ce problème n'a aucune répercussion fonctionnelle. Seul le nombre de clusters activés est incorrect.

  • Problème résolu 2587257 : dans certains cas, le paquet PMTU envoyé par le dispositif NSX-T est ignoré lors de la réception à la destination.

    la détection PMTU échoue, ce qui entraîne la fragmentation et le réassemblage, puis l'abandon de paquets. Cela entraîne une perte de performances ou une interruption du trafic.

  • Problème résolu 2622576 : les pannes dues à la duplication de la configuration ne sont pas propagées correctement à l'utilisateur.

    Lorsque l'intégration est en cours, le message « Échec de l'intégration » s'affiche.

  • Problème résolu 2638673 : les vNIC SRIOV pour les machines virtuelles ne sont pas détectées par l'inventaire.

    Les vNIC SRIOV ne sont pas répertoriées dans la boîte de dialogue Ajouter une nouvelle session SPAN. Les vNIC SRIOV ne seront pas visibles lors de l'ajout d'une nouvelle session SPAN.

  • Problème résolu 2643749 : impossible d'imbriquer le groupe à partir de la région personnalisée créée sur un site spécifique dans un groupe appartenant à la région spécifique au site créé par le système.

    Le groupe créé dans la région personnalisée spécifique au site ne sera pas visible lors de la sélection du groupe enfant en tant que membre du groupe dans la région créée par le système avec le même emplacement.

  • Problème résolu 2805986 : impossible de déployer la machine virtuelle Edge gérée par NSX-T.

    Le déploiement du dispositif Edge NSX-T échoue lorsqu'il est effectué à l'aide de l'interface utilisateur d'ESX.

  • Problème résolu 2685550 : l'état de réalisation de la règle de pare-feu est toujours affiché comme « En cours d'exécution » lorsqu'il est appliqué aux segments de pont.

    Lors de l'application de règles de pare-feu à un NSGroup qui contient des segments de pont en tant que membres, l'état de réalisation s'affiche toujours comme étant en cours d'exécution. Vous ne pourrez pas vérifier l'état de réalisation des règles de pare-feu appliquées aux segments de pont.

Problèmes connus

  • Problème 3025104 : hôte indiquant l'état « En échec » lors d'une restauration effectuée sur une adresse IP différente et le même nom de domaine complet.

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

    Solution : Actualisez le cache DNS de l'hôte. Utilisez la commande /etc/init.d/nscd restart.

  • Problème 3012313 : La mise à niveau de la protection contre les programmes malveillants NSX ou de NSX Network Detection and Response de la version 3.2.0 vers NSX ATP 3.2.1 ou 3.2.1.1 échoue.

    Après la mise à niveau de NSX Application Platform de NSX 3.2.0 vers NSX ATP 3.2.1 ou 3.2.1.1, la mise à niveau de la fonctionnalité de protection contre les programmes malveillants NSX (MP) ou NSX Network Detection and Response (NDR) échoue avec un ou plusieurs des symptômes suivants.

    1. La fenêtre Interface utilisateur de ka mise à niveau affiche un état FAILED pour NSX NDR et les espaces cloud-connector.

    2. Pour une mise à niveau de NSX NDR, quelques espaces avec le préfixe de nsx-ndr sont à l'état ImagePullBackOff.

    3. Pour une mise à niveau de NSX MP, quelques espaces avec le préfixe de cloud-connector sont à l'état ImagePullBackOff.

    4. La mise à niveau échoue lorsque vous cliquez sur METTRE À NIVEAU, mais les fonctionnalités précédentes NSX MP et NSX NDR fonctionnent toujours de la même manière qu'avant le démarrage de la mise à niveau. Toutefois, NSX Application Platform risque de devenir instable.

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

  • Problème 2989696 : Les sauvegardes planifiées ne parviennent pas à démarrer après l'opération de restauration de NSX Manager.

    La sauvegarde planifiée ne génère pas de sauvegardes. Les sauvegardes manuelles continuent de fonctionner.

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

  • Problème 3015843 : l'identifiant du journal de paquets DFW a été modifié dans NSX-T 3.2.0 et n'a pas été mentionné dans les notes de mise à jour.

    Impossible d'afficher les journaux de paquets DFW portant l'identifiant de journal utilisé dans les versions antérieures.

    Les champs Syslog NSX-T suivants ont été modifiés pour s'aligner sur la conformité RFC :

    • FIREWALL_PKTLOG modifié en FIREWALL-PKTLOG

    • DLB_PKTLOG modifié en DLB-PKTLOG

    • IDPS_EVT modifié en IDPS-EVT

    • nsx_logger modifié en nsx-logger

    Étant donné que ces modifications ont été apportées pour s'aligner sur la conformité RFC, il n'existe aucun scénario hypothétique de futures versions NSX qui reviennent à la structure des journaux à partir de versions antérieures.

  • 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 2283559 : les API MP /routing-table et /forwarding-table renvoient une erreur si le dispositif Edge comporte plus de 65 000 routes pour RIB et plus de 100 000 pour FIB.

    Si le dispositif Edge comporte plus de 65 000 routes pour RIB et plus de 100 000 pour FIB, la demande de l'interface multiprotocole au dispositif Edge prend plus de 10 secondes et expire. Il s'agit d'une API en lecture seule qui a un impact uniquement s'il est nécessaire de télécharger les 65 000 routes minimum pour RIB et les 100 000 routes minimum pour FIB à l'aide de l'API/interface utilisateur.

    Solution : il existe deux options pour extraire les tables RIB/FIB. Ces API prennent en charge les options de filtrage basées sur les préfixes de réseau ou le type de route. Utilisez ces options pour télécharger les routes qui vous intéressent. Prise en charge d'une interface de ligne de commande au cas où l'intégralité des tables RIB/FIB soit nécessaire et en l'absence de délai d'expiration.

  • Problème 2693576 : le nœud de transport affiche « Échec de l'installation de NSX » après la mise à niveau de KVM RHEL 7.9 vers RHEL 8.2.

    après la mise à niveau de RHEL 7.9 vers la version 8.2, les dépendances nsx-opsagent et nsx-cli sont manquantes, l'hôte est marqué comme ayant échoué à l'installation. La résolution de l'échec à partir de l'interface utilisateur ne fonctionne pas : échec de l'installation du logiciel sur l'hôte. Dépendances non résolues : [PyYAML, python-mako, python-netaddr, python3]

    Solution : installez manuellement les vibs NSX RHEL 8.2 après la mise à niveau du système d'exploitation hôte puis résolvez-le à partir de l'interface utilisateur.

  • Problème 2628503 : la règle DFW reste appliquée même après la suppression forcée du NSGroup du gestionnaire.

    Solution : ne forcez pas la suppression d'un NSGroup qui est toujours utilisé par une règle DFW. À la place, videz le NSGroup ou supprimez la règle DFW.

  • 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 NSX fédération si vous remplacez le certificat APH-AR sur cette instance de NSX Manager.

    ce problème se produit uniquement avec NSX Fédération 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 NSX fédération 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 2636771 : la recherche peut renvoyer une ressource lorsqu'une ressource est balisée avec plusieurs paires de balises et que la balise et l'étendue correspondent à toute valeur de balise et de portée.

    Cela affecte la requête de recherche avec une condition sur la balise et l'étendue. Le filtre peut renvoyer des données supplémentaires si la balise et l'étendue correspondent à une paire.

    Solution : aucune.

  • Problème 2668717 : une perte intermittente du trafic peut être observée pour le routage E-O entre les réseaux créés par vRA connectés à des segments partageant le niveau 1.

    Dans les cas où vRA crée plusieurs segments et se connecte à une passerelle ESG partagée, V2T convertit une telle topologie en un niveau 1 partagé connecté à tous les segments du côté NSX-T. Pendant la fenêtre de migration de l'hôte, une perte intermittente du trafic peut être observée pour le trafic E-O entre les charges de travail connectées aux segments partageant le niveau 1.

    Solution : aucune.

  • 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 2526769 : la restauration échoue sur un cluster à nœuds multiples.

    Lors du démarrage d'une restauration sur un cluster à nœuds multiples, la restauration échoue et vous devez redéployer le dispositif.

    Solution : déployez une nouvelle configuration (cluster à un nœud) et démarrez la restauration.

  • Problème 2534933 : les certificats disposant de CDP (CRL Distribution Point) basés sur LDAP ne s'appliquent pas en tant que certificats tomcat/cluster.

    Vous ne pouvez pas utiliser des certificats signés par une autorité de certification qui ont des CDP LDAP en tant que certificat cluster/tomcat.

    Solution : Il existe deux options.

    1. Utiliser un certificat avec CDP basé sur HTTP.

    2. Désactivez la vérification de la CRL à l'aide de l'API PUT https://<manager>/api/v1/global-configs/SecurityGlobalConfig (dans la charge utile pour PUT, assurez-vous que « crl_checking_enabled » est false.)

  • Problème 2566121 : le message d'erreur incorrect « Certains composants du dispositif ne fonctionnent pas correctement » s'affiche lorsque le serveur est surchargé.

    lorsqu'il y a trop d'appels d'API effectués vers NSX, l'interface utilisateur/API affiche l'erreur « Certains composants du dispositif ne fonctionnent pas correctement » au lieu de « Le serveur est surchargé ».

    Solution : aucune.

  • Problème 2613113 : si l'intégration est en cours et que la restauration du gestionnaire local est terminée, l'état du gestionnaire global reste sur IN_PROGRESS.

    L'interface utilisateur affiche IN_PROGRESS dans le gestionnaire global pour l'intégration du gestionnaire local. La configuration du site restauré ne peut pas être importée.

    Solution : redémarrez le cluster de gestionnaire global, un nœud à la fois.

  • 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 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 2658092 : l'intégration échoue lorsque NSX Intelligence est configuré sur le gestionnaire local.

    L'intégration échoue avec une erreur d'identité de principal et vous ne pouvez pas intégrer un système avec l'utilisateur d'identité de principal.

    Solution : créez un utilisateur d'identité de principal temporaire avec le même nom d'identité de principal que celui utilisé par NSX Intelligence.

  • Problème 2639424 : la correction d'un hôte dans un cluster vLCM avec un déploiement basé sur l'hôte échouera une fois 95 % de la correction effectués.

    La progression de la correction d'un hôte sera bloquée à 95 %, puis échouera après la fin du délai d'expiration de 70 minutes.

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

  • Problème 2636420 : l'hôte passera à l'état « Installation de NSX ignorée » et le cluster dans l'état « Échec » après la restauration si « Supprimer NSX » s'exécute sur le cluster après la sauvegarde.

    « Installation de NSX ignorée » s'affiche pour l'hôte.

    Solution : après la restauration, vous devez exécuter de nouveau « Supprimer NSX » sur le cluster pour atteindre l'état qui était présent après la sauvegarde (état non configuré).

  • 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 2491800 : la validité des certificats SSL de canal AR n'est pas vérifiée périodiquement. Ceci peut entraîner l'utilisation d'un certificat expiré/révoqué pour une connexion existante.

    La connexion utiliserait un SSL expiré/révoqué.

    Solution : redémarrez l'APH sur le nœud de gestionnaire pour déclencher une reconnexion.

  • Problème 2561988 : toutes les sessions IKE/IPSEC sont temporairement interrompues.

    L'interruption du trafic durera un certain temps.

    Solution : modifiez les points de terminaison locaux par phases plutôt que tous en même temps.

  • Problème 2584648 : le basculement principal pour la passerelle T0/T1 affecte la connectivité ascendante.

    la durée de basculement de l'emplacement entraîne une interruption de quelques secondes et peut affecter le basculement d'emplacement ou le test de retour arrière.

    Solution : aucune.

  • Problème 2636420 : le profil de nœud de transport est appliqué à un cluster sur lequel « Supprimer NSX » est appelé après la sauvegarde.

    les hôtes ne sont pas à l'état préparé, mais le profil de nœud de transport est toujours appliqué au cluster.

    Solution : après une restauration, vous devez exécuter de nouveau « Supprimer NSX » sur le cluster pour atteindre l'état qui était présent après la sauvegarde (état non configuré).

  • Problème 2687084 : après la mise à niveau ou le redémarrage, l'API de recherche peut renvoyer l'erreur 400 avec le code d'erreur 60508 « La recréation des index peut prendre un certain temps ».

    en fonction de l'échelle du système, l'API de recherche et l'interface utilisateur sont inutilisables jusqu'à la fin de la réindexation.

    Solution : aucune.

  • Problème 2782010 : l'API de stratégie permet de modifier vdr_mac/vdr_mac_nested même lorsque « allow_changing_vdr_mac_in_use » est false

    l'adresse MAC VDR sera mise à jour sur TN même si allow_changing est défini sur false. L'erreur n'est pas signalée.

    Solution : remplacez l'adresse MAC VDR par l'ancienne valeur si vous n'aviez pas prévu que le champ change.

  • Problème 2791490 : Fédération : impossible de synchroniser les objets avec le gestionnaire global (GM) en veille après la modification du mot de passe de GM en veille.

    impossible d'observer le GM actif sur le gestionnaire d'emplacements du GM en veille, aucune mise à jour du GM actif.

    Solution : demandez une synchronisation forcée sur l'interface utilisateur du GM en veille.

  • 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 2839782 : impossible de mettre à niveau NSX-T 2.4.1 vers la version 2.5.1, car l'entité CRL est volumineuse et Corfu impose une limite de taille dans 2.4.1, empêchant ainsi l'entité de CRL d'être créée dans Corfu pendant la mise à niveau.

    impossible d'effectuer la mise à niveau.

    Solution : remplacez le certificat par un certificat signé par une autorité de certification différente.

  • Problème 2851991 : IDFW échoue si le groupe de stratégies avec le groupe AD comporte également un groupe source vide imbriqué.

    IDFW échoue si le groupe de stratégies avec le groupe AD a un groupe source vide imbriqué.

    Solution : supprimez le groupe enfant vide.

  • Problème 2852419 : message d'erreur affiché lorsque la route statique est configurée avec un tronçon suivant IPv4/v6 non local de liaison ayant plusieurs valeurs d'étendue.

    l'API de route statique avec une adresse IP de tronçon suivant non locale de liaison ayant plusieurs configurations de valeurs d'étendue sera rejetée.

    Solution : créez plusieurs tronçons suivants au lieu de plusieurs valeurs d'étendue et assurez-vous que chaque tronçon suivant a une adresse IP différente.

  • 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 2854139 : ajout/suppression continus des routes BGP dans RIB pour une topologie dans laquelle le SR de niveau 0 sur le dispositif Edge comporte plusieurs voisins BGP et ces voisins BGP envoient des préfixes ECMP au SR de niveau 0.

    abandon de trafic pour les préfixes qui sont continuellement ajoutés/supprimés.

    Solution : ajoutez une carte de route entrante qui filtre le préfixe BGP qui se trouve dans le même sous-réseau que la route statique nexthop.

  • Problème 2864250 : un échec se produit lors de la réalisation du nœud de transport si le profil NIOC personnalisé est utilisé lors de la création d'un nœud de transport.

    le nœud de transport n'est pas prêt à être utilisé.

    Solution : créez le nœud de transport avec le profil NIOC par défaut, puis mettez-le à jour en appliquant le profil NIOC personnalisé.

  • 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 2867243 : les API d'appartenance effective d'un groupe de stratégies ou d'un NSGroup sans membres effectifs ne renvoient pas les champs « résultats » et « result_count » dans la réponse de l'API.

    Ce problème n'a aucune répercussion fonctionnelle.

    Solution : aucune.

  • Problème 2868235 : dans la boîte de dialogue Démarrage rapide - Mise en réseau et sécurité, la visualisation affiche un VDS en double lorsque plusieurs PNIC sont attachées au même VDS.

    la visualisation affiche un VDS en double. Il peut être difficile de trouver ou de faire défiler jusqu'à la section Personnaliser le commutateur d'hôte si l'accent est mis sur le graphique de visualisation.

    Solution : pour le problème de défilement, appuyez sur la touche Tabulation ou déplacez le pointeur de la souris en dehors de la zone de visualisation et faites défiler jusqu'à la section Personnaliser la configuration du commutateur.

  • 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 2870529 : les informations d'exécution pour l'identification du pare-feu (IDFW) ne sont pas disponibles si la casse exacte du nom NetBIOS n'est pas utilisée lors de l'ajout d'un domaine AD.

    vous ne pouvez pas obtenir facilement et rapidement les informations/l'état d'exécution actuels d'IDFW. Les connexions actives actuelles ne peuvent pas être déterminées.

    Solution : modifiez le domaine en question et corrigez le nom netbios. Une fois les modifications appliquées, tous les événements IDFW futurs seront signalés correctement.

  • Problème 2870645 : en réponse à l'API /policy/api/v1/infra/realized-state/realized-entities, « publish_status_error_details » affiche les détails de l'erreur même si « publish_status » est « SUCCESS », ce qui signifie que la réalisation a réussi.

    Ce problème n'a aucune répercussion fonctionnelle.

    Solution : aucune.

  • 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 2874236 : après la mise à niveau, si vous redéployez une seule passerelle de cloud public (PCG) dans une paire HA, l'ancien build HA AMI/VHD est réutilisé.

    cela se produit uniquement après la mise à niveau lors du premier redéploiement des PCG.

    Solution : fournissez l'AMI ou le VHD approprié après la mise à niveau via l'API.

  • Problème 2875385 : lorsqu'un nouveau nœud rejoint le cluster, si les utilisateurs locaux (admin, audit, guestuser1, guestuser2) ont été renommés sous un autre nom, il se peut que ces utilisateurs locaux ne puissent pas se connecter.

    l'utilisateur local ne peut pas se connecter.

    Solution : il existe deux solutions.

    • Solution 1 : Renommez l'utilisateur puis revenez au nom souhaité.

    • Solution 2 : si vous ne parvenez pas à renommer les utilisateurs, redémarrez NSX Manager.

  • 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 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 2747735 : après la restauration, la connectivité VIP est interrompue en raison de problèmes de compatibilité réseau.

    Lors de la restauration de la sauvegarde, les clients peuvent mettre à jour l'adresse IP virtuelle avant l'étape « AddNodeToCluster ».

    [Entrez la solution, le cas échéant, sinon indiquez « Aucune »] La restauration s'interrompt généralement à l'étape « AddNodeToCluster » où l'utilisateur est invité à ajouter des nœuds de gestionnaire supplémentaires. À cette étape, a. Supprimez/mettez d'abord à jour l'adresse IP virtuelle pour utiliser une nouvelle adresse IP de la page « Interface utilisateur des systèmes/dispositifs ». Et b. Ajoutez des nœuds supplémentaires à un cluster à 1 nœud restauré une fois que l'adresse IP virtuelle est corrigée.

  • Problème 2816781 : les serveurs physiques ne peuvent pas être configurés avec une stratégie d'association basée sur l'équilibrage de charge, car ils prennent en charge un seul VTEP.

    vous ne pourrez pas configurer des serveurs physiques avec une stratégie d'association basée sur l'équilibrage de charge.

    Solution : remplacez la stratégie d'association par une stratégie d'association basée sur le basculement ou par une stratégie ayant un seul VTEP.

  • Problème 2856109 : l'ajout du 2 000e membre du pool entraîne une erreur de limite si la version du contrôleur Avi est 21.1.2.

    le contrôleur Avi 21.1.2 autorise 1 999 membres du pool au lieu de 2 000.

    Solution : utilisez la version du contrôleur Avi 20.1.7 ou 21.1.3.

  • Problème 2862418 : le premier paquet peut être perdu dans l'analyse du trafic en direct (LTA) lors de la configuration de LTA pour suivre le nombre exact de paquets.

    vous ne pouvez pas voir le premier suivi de paquet.

    Solution : aucune.

  • Problème 2864929 : le nombre de membres du pool est plus élevé lors de la migration de NSX for vSphere vers Avi Load Balancer sur NSX-T Data Center.

    vous verrez un nombre de membres du pool plus élevé. Le moniteur de santé marquera ces membres du pool comme étant inactifs, mais le trafic ne sera pas envoyé aux membres du pool inaccessibles.

    Solution : aucune.

  • Problème 2865273 : le moteur de recherche Advanced Load Balancer (Avi) ne se connecte pas au contrôleur Avi s'il existe une règle DFW pour bloquer les ports 22, 443, 8443 et 123 avant la migration de NSX for vSphere vers NSX-T Data Center.

    le moteur de recherche Avi ne parvient pas à se connecter au contrôleur Avi.

    Solution : ajoutez des règles DFW explicites pour autoriser les ports 22, 443, 8443 et 123 pour les machines virtuelles SE ou exclure les machines virtuelles SE des règles DFW.

  • Problème 2866885 : l'analyseur de journaux d'événements (ELS) requiert que le nom NetBIOS configuré dans le domaine AD corresponde à celui du serveur AD.

    la connexion de l'utilisateur ne sera pas détectée par ELS.

    Solution : modifiez le nom NetBIOS pour qu'il corresponde à celui du serveur AD.

  • 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 2878030 : la mise à niveau du nœud d'orchestrateur pour la modification du site du gestionnaire local n'affiche pas de notification.

    si le nœud d'orchestrateur est modifié après la mise à niveau de l'UC et que vous continuez avec le workflow de l'interface utilisateur en cliquant sur un bouton d'action (prévérification, démarrage, etc.), vous ne verrez aucune progression sur l'interface utilisateur de mise à niveau. Cela s'applique uniquement si l'interface utilisateur de mise à niveau du gestionnaire local est accessible dans l'interface utilisateur du gestionnaire global à l'aide du sélecteur de site.

    Solution : accédez au gestionnaire local de ce site et poursuivez la mise à niveau pour voir la notification attendue.

  • Problème 2878325 : dans la vue Inventaire du tableau de bord de capacité pour Manager, le nombre d'attributs « Groupes basés sur des ensembles d'adresses IP » n'inclut pas les groupes contenant des adresses IP créées à partir de l'interface utilisateur de stratégie.

    dans la vue Inventaire du tableau de bord de capacité pour Manager, le nombre de « Groupes basés sur des ensembles d'adresses IP » n'est pas correctement représenté si des groupes de stratégies contiennent des adresses IP.

    Solution : aucune.

  • 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 2879734 : la configuration échoue lorsque le même certificat auto-signé est utilisé dans deux points de terminaison locaux IPsec différents.

    la session IPsec ayant échoué ne sera pas établie tant que l'erreur n'aura pas été résolue.

    Solution : utilisez un certificat auto-signé unique pour chaque point de terminaison local.

  • Problème 2879979 : le service IKE peut ne pas initier une nouvelle session basée sur la route IPsec après une « Dead Peer Detection » en raison de l'inaccessibilité de l'homologue IPsec.

    il peut y avoir une panne pour une session basée sur une route IPsec spécifique.

    Solution : activer/désactiver sur la session IPsec peut résoudre le problème.

  • Problème 2881281 : la configuration simultanée de plusieurs serveurs virtuels peut échouer pour certains.

    les connexions client aux serveurs virtuels peuvent expirer.

    Solution : exécutez l'API suivante pour redéclencher le workflow de routeur logique.

    https://{ip}/api/v1/logical-routers/<id>? action=retraitement

  • Problème 2881471 : l'état du déploiement des services n'est pas mis à jour lorsque l'état du déploiement passe d'échec à réussite.

    vous pouvez voir que l'état du déploiement des services reste dans l'état Inactif indéfiniment avec l'alarme qui a été déclenchée.

    Solution : utilisez l'API d'état du déploiement des services pour vérifier l'état.

    API : https://{{nsx-mgr-ip}}/api/v1/serviceinsertion/services/{{service-id}}/service-deployments/{{service-deployment-id}}/status

  • Problème 2882070 : les membres et les critères NSGroup ne s'affichent pas pour les groupes globaux dans la liste d'API Manager.

    Aucune répercussion fonctionnelle.

    Solution : affichez les définitions de groupe global via l'API de stratégie sur le gestionnaire local.

  • Problème 2882769 : les balises sur les objets NSService et NSServiceGroup ne sont pas reportées après la mise à niveau vers NSX-T 3.2.

    il n'y a aucun impact fonctionnel sur NSX, car les balises sur NSService et NSServiceGroup ne sont consommées par aucun workflow. Il peut y avoir un impact sur les scripts externes dont les workflows reposent sur des balises sur ces objets.

    Solution : après la mise à niveau vers NSX-T 3.2, les balises manquantes peuvent être ajoutées à NSService et NSServiceGroup en mettant à jour les entités.

  • Problème 2884939 : la limite de débit de 100 demandes par seconde de NSX est atteinte lors de la migration d'un grand nombre de services virtuels de NSX for vSphere vers NSX-T ALB et toutes les API sont bloquées pendant un certain temps.

    l'API de stratégie NSX-T génère une erreur : Le client « admin » a dépassé le taux de demandes de 100 par seconde (code d'erreur : 102) pendant un certain temps après la migration, la configuration est atteinte lors de la migration.

    Solution : mettez à jour la limite de débit de l'API du client à 200 demandes par seconde.

  • 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 2884518 : nombre incorrect de machines virtuelles connectées au segment sur l'interface utilisateur de topologie réseau après la mise à niveau d'un dispositif NSX vers NSX-T 3.2.

    vous verrez un nombre incorrect de machines virtuelles connectées au segment sur la topologie réseau. Toutefois, le nombre réel de machines virtuelles associées au segment s'affiche lorsque vous développez le nœud de la machine virtuelle.

    Solution :

    1. connectez-vous au dispositif NSX en mode ingénierie.

    2. Exécutez la commande suivante : curl -XDELETE http://localhost:9200/topology_manager

  • Problème 2874995 : la priorité des fichiers LCore peut rester élevée même lorsqu'elle n'est pas utilisée, ce qui les rend inutilisables pour certaines machines virtuelles.

    dégradation des performances des machines virtuelles à « Latence normale ».

    Solution : Il existe deux options.

    • Redémarrez le système.

    • Supprimez les fichiers LCore haute priorité, puis recréez-les. Ils reviendront ensuite par défaut aux LCore de priorité normale.

  • Problème 2772500 : l'activation de la superposition imbriquée sur ENS peut entraîner un PSOD.

    peut entraîner un PSOD.

    Solution : désactivez ENS.

  • Problème 2832622 : le profil IPv6 ND ne prend pas effet après avoir été modifié ou changé.

    le réseau fera toujours référence à l'ancien profil NDRA.

    Solution : redémarrez ccp pour mettre à jour le profil IPv6 ND.

  • Problème 2840599 : l'API de normalisation MP génère une erreur INVALID_ARGUMENT.

    expérience d'interface utilisateur médiocre.

    Solution : aucune.

  • Problème 2844756 : la suppression du segment échoue avec une erreur.

    vous ne pourrez pas supprimer le segment.

    Solution : forcez la suppression des ports attachés au segment.

    1. Extrayez tous les ports logiques connectés à ce segment à l'aide de l'API suivante. Par exemple, pour PolicySegment01.

      GET : https://<NSX MANAGER IP>/policy/api/v1/infra/segments/PolicySegment01/ports

    2. Pour chaque port logique répertorié dans l'appel ci-dessus, effectuez l'appel suivant.

      DELETE : https://<NSX MANAGER IP>/api/v1/logical-ports/<LOGICAL PORT UUID>?detach=true

    Une fois tous les ports attachés supprimés, le segment peut être supprimé.

  • Problème 2866751 : l'API d'appartenance effective consolidée ne répertorie pas les adresses IP statiques dans la réponse d'un groupe fantôme.

    aucun impact fonctionnel ou de chemin de données. Vous ne verrez pas les adresses IP statiques dans l'API d'appartenance effective consolidée GET pour un groupe fantôme. Cela s'applique uniquement à un groupe fantôme (également appelé groupes de référence).

    Solution : vérifiez l'appartenance effective consolidée d'un groupe fantôme sur son site d'origine.

  • Problème 2869356 : une erreur s'affiche sur le plan de gestion lorsque vous cliquez sur l'onglet « Présentation » d'un NSGroup avec des membres IPSet.

    mauvaise expérience utilisateur.

    Solution : aucune.

  • Problème 2872658 : après l'enregistrement du site, l'interface utilisateur affiche une erreur « Impossible d'importer en raison de ces fonctionnalités non prises en charge : IDS ».

    Ce problème n'a aucune répercussion fonctionnelle. l'importation de la configuration n'est pas prise en charge dans NSX-T 3.2.

    Solution : supprimez la configuration IDS du gestionnaire local et réessayez l'enregistrement.

  • Problème 2877628 : lorsque vous tentez d'installer la fonctionnalité de sécurité sur un VDS de commutateur d'hôte ESX d'une version antérieure à la version 6.6, un message d'erreur confus s'affiche.

    le message d'erreur s'affiche via l'interface utilisateur et l'API.

    Solution : utilisez une version de VDS supérieure ou égale à 6.6 sur ESX pour installer NSX Security.

  • 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 2879119 : lorsqu'un routeur virtuel est ajouté, l'interface réseau du noyau correspondant ne s'affiche pas.

    le routage sur le VRF échoue. Aucune connectivité n'est établie pour les machines virtuelles connectées via le vrf.

    Solution : redémarrez le service de plan de données.

  • Problème 2881168 : la sortie de l'API LogicalPort GET est au format étendu « fc00:0:0:0:0:0:0:1 » par rapport au format précédent « fc00::1 ».

    la sortie de l'API LogicalPort GET dans NSX-T 3.2 est au format étendu « fc00:0:0:0:0:0:0:1 » par rapport au format NSX-T 3.0 « fc00::1 ».

    Solution : aucune.

  • Problème 2882822 : les IPSets temporaires ne sont pas ajoutés aux SecurityGroups utilisés dans les règles de pare-feu EDGE/les membres du pool d'équilibrage de charge lors de la configuration de la migration de NSX for vSphere vers NSX-T.

    pendant la migration, il peut y avoir un écart jusqu'à ce que les machines virtuelles/VIF soient découvertes sur NSX-T et qu'elles fassent partie des groupes de sécurité auxquels elles s'appliquent via des appartenances statiques/dynamiques. Cela peut entraîner l'abandon ou l'autorisation du trafic, contrairement aux règles de pare-feu Edge, pendant la période entre le basculement nord/sud (trafic N/S passant par la passerelle NSX-T) jusqu'à la fin de la migration.

    Solution : ajoutez une fausse règle DFW dans laquelle la source/destination contient tous les groupes de sécurité consommés dans le pare-feu Edge. Une autre option consiste à déplacer la source et la destination des règles de pare-feu Edge vers des IPSet avant la migration.

  • Problème 2884070 : en cas d'incompatibilité du paramètre MTU entre la liaison montante NSX-T Edge et le routeur d'appairage, le voisinage OSPF est bloqué dans l'état Exstart. Lors de la migration de NSX for vSphere vers NSX-T, le MTU n'est pas automatiquement migré de sorte qu'une incompatibilité peut avoir un impact sur le plan de données lors du basculement nord/sud Edge.

    la contiguïté OSPF est bloquée dans l'état Exstart.

    Solution : configurez manuellement la MTU correspondante sur les interfaces de voisin OSPF avant d'effectuer le basculement Edge.

  • Problème 2884416 : l'état de l'équilibreur de charge ne peut pas être actualisé en temps opportun.

    état de l'équilibreur de charge incorrect.

    Solution : arrêtez la collecte des statistiques de l'équilibreur de charge.

  • Problème 2885009 : le gestionnaire global dispose de profils de commutation par défaut supplémentaires après la mise à niveau.

    Aucune répercussion fonctionnelle.

    Solution : vous n'êtes pas censé utiliser les profils de commutation par défaut commençant par le préfixe « nsx-default ».

  • Problème 2885248 : pour le scénario InterVtep, si des VNIC Edge sont connectées à des groupes de ports NSX (quel que soit le VLAN sur la machine virtuelle Edge et l'hôte ESX), le trafic nord-sud entre les machines virtuelles de charge de travail sur les dispositifs ESX et Edge cesse de fonctionner, car ESX abandonne les paquets destinés au VTEP Edge.

    Solution : mettez à jour EdgeTN en déconnectant les segments de ses interfaces et en les reconnectant.

  • Problème 2885330 : membre effectif non affiché pour le groupe AD.

    les membres effectifs du groupe AD ne s'affichent pas. Aucune répercussion sur le chemin d'accès des données.

    Solution : aucune.

  • Problème 2885552 : si vous avez créé une source d'identité LDAP qui utilise OpenLDAP et que plusieurs serveurs LDAP sont définis, seul le premier serveur est utilisé.

    si le premier serveur LDAP devient indisponible, l'authentification échoue au lieu d'essayer le reste du ou des serveurs OpenLDAP configurés.

    Solution : s'il est possible de placer un équilibreur de charge devant les serveurs OpenLDAP et de configurer NSX avec l'adresse IP virtuelle de l'équilibreur de charge, vous pouvez disposer d'une haute disponibilité.

  • Problème 2886210 : pendant la restauration, si le VC est en panne, une boîte de dialogue Sauvegarde/Restauration s'affiche et indique à l'utilisateur de s'assurer que VC est actif et en cours d'exécution, mais l'adresse IP du VC n'est pas affichée.

    l'adresse IP du VC n'est pas affichée lors de la restauration de la connectivité VC.

    Solution : vérifiez que tous les VC enregistrés sont en cours d'exécution avant de passer à l'étape de restauration suivante.

  • Problème 2886971 : les groupes créés sur le gestionnaire global ne sont pas nettoyés après la suppression. Cela se produit uniquement si ce groupe est un groupe de référence sur un site de gestionnaire local.

    aucun impact fonctionnel ; cependant, vous ne pouvez pas créer un autre groupe avec le même chemin d'accès de stratégie que le groupe supprimé.

    Solution : aucune.

  • Problème 2887037 : après la promotion de l'objet Gestionnaire vers Stratégie, les règles NAT ne peuvent pas être mises à jour ou supprimées.

    cela se produit lorsque des règles NAT sont créées par un utilisateur PI (identité de principal) sur Manager avant le déclenchement de la promotion. Les règles NAT créées par l'utilisateur PI ne peuvent pas être mises à jour ou supprimées après la promotion de l'objet Gestionnaire vers Stratégie.

    Solution : des règles NAT avec la même configuration peuvent être créées avec un utilisateur non protégé tel que « admin » avant la promotion de l'objet Gestionnaire vers Stratégie.

  • Problème 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é.

    Solution : la configuration de vIDM doit être (temporairement) désactivée, les informations d'identification locales sont réinitialisées pendant ce temps, puis l'intégration doit être réactivée.

  • Problème 2889748 : échec de la suppression du nœud Edge si le redéploiement a échoué. La suppression laisse une intention périmée dans le système qui s'affiche dans l'interface utilisateur.

    bien que la VM Edge soit supprimée, l'intention Edge périmée et les objets internes seront conservés dans le système, puis l'opération de suppression sera réessayée en interne. Aucune incidence sur la fonctionnalité, car les machines virtuelles Edge sont supprimées et seule l'intention comporte des entrées périmées.

    Solution : aucune.

  • Problème 2875962 : le workflow de mise à niveau pour les configurations cloud natives est différent de NSX-T 3.1 à NSX-T 3.2.

    suivre le workflow habituel effacera toutes les données CSM.

    Solution : la mise à niveau nécessite l'assistance de VMware. Contactez le support VMware.

  • Problème 2888658 : impact significatif sur les performances en termes de connexions par seconde et de débit observé sur le pare-feu de passerelle NSX-T lorsque la fonctionnalité de détection et de sandboxing des programmes malveillants est activée.

    tout trafic soumis à la détection de programmes malveillants rencontre des latences importantes et peut-être des échecs de connexion. Lorsque la détection des programmes malveillants est activée sur la passerelle, elle affecte également le trafic L7FW, ce qui entraîne des latences et des échecs de connexion.

    Solution : limitez la quantité de trafic soumise à la détection de programmes malveillants en écrivant des règles IDS qui correspondent uniquement à une petite sous-section du trafic.

  • Problème 2882574 : API « Intégration de la configuration existante » bloquées dans NSX-T version 3.2.0, car la fonctionnalité n'est pas entièrement prise en charge.

    vous ne pourrez pas utiliser la fonctionnalité « Intégration de la configuration existante ».

    Solution : aucune.

  • Problème 2890348 : le changement de nom du pool VNI par défaut entraîne un pool VNI incohérent lors de la mise à niveau vers NSX-T 3.2.

    L'allocation de VNI et les opérations associées peuvent échouer.

    Solution : pour la mise à niveau vers NSX-T 3.2, renommez le pool VNI par défaut en DefaultVniPool à l'aide de l'API PUT https://{{url}}/api/v1/pools/vni-pools/<vni-pool-id>.

  • Problème 2885820 : traductions manquantes pour certaines adresses IP pour la plage d'adresses IP commençant par 0.0.0.0.

    Un NSGroup dont la plage d'adresses IP commence par 0.0.0.0 (par exemple, « 0.0.0.0-255.255.255.0 ») présente des problèmes de traduction (sous-réseau 0.0.0.0/1 manquant).

    Le NSGroup avec la plage d'adresses IP « 1.0.0.0-255.255.255.0 » n'est pas affecté.

    Solution : pour configurer des groupes avec une plage d'adresses IP commençant par 0.0.0.0, ajoutez manuellement 0.0.0.0/1 dans la configuration du groupe.

  • 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 2945515 : la mise à niveau de NSX Tools dans Azure peut échouer sur les machines virtuelles Redhat Linux.

    Par défaut, NSX Tools est installé sur le /répertoire opt. Cependant, lors de l'installation de NSX Tools, le chemin d'accès par défaut peut être remplacé par l'option « --chroot-path » transmise au script d'installation.

    Un espace disque insuffisant sur la partition où NSX Tools est installé peut entraîner l'échec de la mise à niveau de NSX Tools.

    Solution : aucune.

  • Problème 2875563 : la suppression de la session LTA IN_PROGRESS peut entraîner une fuite de fichiers PCAP.

    Le fichier PCAP fuite si une LTA est supprimée avec une action PCAP lorsque l'état de la session LTA est « IN_PROGRESS ». Cela peut entraîner la saturation de la partition /tmp d'ESXi.

    Solution : effacer la partition /tmp peut aider.

  • Problème 2875667 : le téléchargement du fichier LTA PCAP génère une erreur lorsque la partition NSX /tmp est saturée.

    Le fichier LTA PCAP ne peut pas être téléchargé, car la partition /tmp est saturée.

    Solution : effacer la partition /tmp peut aider.

  • Problème 2883505 : PSOD sur les hôtes ESXi pendant la migration NSX V2T.

    PSOD (Purple Screen of Death) sur plusieurs hôtes ESXi lors de la migration V2T. Cela entraîne une indisponibilité du chemin de données.

    Solution : aucune.

  • Problème 2914934 : les règles DFW sur les dvPortGroups sont perdues après la migration de NSX-V vers NSX-T.

    Après une migration NSX-V vers NSX-T, les charges de travail qui sont toujours connectées à vSphere dvPortGroup ne disposeront pas de la configuration DFW.

    Solution : après une migration NSX-V vers NSX-T, les segments VLAN sont configurés avec une configuration DFW identique. Utilisez les segments VLAN au lieu des dvPortGroups.

    Une autre solution consiste à désinstaller NSX-V, puis à installer NSX-T en mode de sécurité uniquement. Vous pouvez ensuite utiliser des charges de travail sur des dvPortGroups existants.

  • Problème 2921704 : le CPU du service Edge peut atteindre un pic en raison d'un blocage du processus nginx lors de l'utilisation de l'équilibreur de charge L7 avec l'algorithme d'équilibrage de charge ip-hash.

    Il n'est pas possible de se connecter aux serveurs principaux derrière l'équilibreur de charge.

    Solution : basculez vers le moteur L4 pour corriger le problème. Si vous souhaitez continuer à utiliser l'équilibreur de charge L7, remplacez l'algorithme d'équilibrage de charge par round-robin au lieu d'ip-hash.

  • Problème 2933905 : le remplacement d'une instance de NSX-T Manager entraîne la perte de connexion des nœuds de transport au contrôleur.

    L'ajout ou la suppression d'un nœud dans le cluster de gestionnaire peut entraîner la perte de connectivité du contrôleur par certains nœuds de transport.

    Solution : redémarrez le service de proxy NSX sur les nœuds de transport affectés chaque fois qu'un gestionnaire est ajouté ou supprimé du cluster de gestion. Cela permettra de renseigner à nouveau controller-info.xml et d'autoriser la connexion au contrôleur.

  • Problème 2927442 : le trafic atteint parfois la règle de refus DFW par défaut sur les machines virtuelles sur différents hôtes et clusters depuis la mise à niveau de NSX-T 3.2.0.1.

    Certains problèmes de PSOD se sont produits après la migration de NSX for vSphere vers NSX-T 3.1.3. Par conséquent, il a été recommandé de mettre à niveau vers la version 3.2.0.1. Cependant, depuis lors, les hôtes n'appliquent pas les règles de pare-feu distribué de manière cohérente. Différents hôtes correspondent à différentes règles qui sont incohérentes et non attendues.

    Solution :

    - Si l'exception ci-dessus s'observe sur un contrôleur spécifique, il peut être redémarré pour résoudre temporairement le problème.

    - En outre, si le problème a une incidence sur DFW, des règles d'autorisation any/any peuvent être créées en haut de la liste des règles pour contourner les règles de blocage indésirables qui sont affectées.

  • Problème 2937810 : Le service de chemin de données ne parvient pas à démarrer et certaines fonctions de pont Edge (par exemple, port de pont Edge) ne fonctionnent pas.

    Si le pontage Edge est activé sur les nœuds Edge, le plan de contrôle central (CCP, Central Control Plane) envoie les règles DFW aux nœuds Edge, qui ne doivent être envoyées qu'aux nœuds hôtes. Si les règles DFW contiennent une fonction qui n'est pas prise en charge par le pare-feu Edge, les nœuds Edge ne peuvent pas gérer la configuration DFW non prise en charge, ce qui entraîne l'échec du démarrage du chemin de données.

    Solution : Supprimez ou désactivez les règles DFW qui ne sont pas prises en charge par le pare-feu Edge.

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