Notes de mise à jour de VMware NSX for vSphere 6.4.0

VMware NSX for vSphere 6.4.0 | Publié le 16 janvier 2018 | Build 7564187

Consultez l'Historique de révision de ce document.

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés de NSX 6.4.0
Versions, configuration système et installation
Fonctionnalités obsolètes et retirées
Notes relatives aux mises à niveau
Conformité FIPS
Historique de révision
Problèmes résolus
Problèmes connus

Nouveautés de NSX 6.4.0

NSX for vSphere 6.4.0 ajoute des améliorations de facilité de gestion et corrige un certain nombre de bogues spécifiques des clients. Pour plus d’informations, voir Problèmes résolus.

Modifications introduites dans NSX for vSphere 6.4.0 :

Services de sécurité :

Pare-feu d'identité : le pare-feu d'identité (IDFW) prend désormais en charge les sessions utilisateur des serveurs d'applications et de postes de travail distants (RDSH) partageant une adresse IP unique. Une nouvelle architecture « à chemin d'accès rapide » améliore la vitesse de traitement des règles IDFW. L'intégration Active Directory autorise désormais la synchronisation sélective pour des mises à jour AD plus rapides.
Pare-feu distribué : le pare-feu distribué (DFW) ajoute un contexte basé sur des applications de couche 7 pour le contrôle de flux et la planification de microsegmentation. Le gestionnaire de règles d'application (ARM) recommande désormais des groupes de sécurité et des stratégies pour une stratégie de microsegmentation cohérente et facile à gérer.
Des règles de pare-feu distribué peuvent désormais être créées en tant que règles sans état à un niveau par section de DFW.
Le pare-feu distribué prend en charge la réalisation d'adresse IP de VM dans l'hyperviseur. Cela permet aux utilisateurs de vérifier si l'adresse IP d'une VM en particulier fait partie d'un groupe de sécurité/cluster/pool de ressources/hôte qui est utilisé dans les champs source, destination ou appliedTo d'une règle de DFW.
Mécanismes de découverte de l'adresse IP pour les VM : la mise en application officielle de stratégies de sécurité basées sur des noms de VM ou autres attributs vCenter nécessite que NSX connaisse l'adresse IP de la VM. NSX 6.2 a introduit la possibilité de découvrir l'adresse IP de la VM en utilisant l'écoute DHCP ou l'écoute ARP. Dans NSX 6.4.0, le nombre d'adresses IP découvertes par ARP a été amélioré jusqu'à 128 et est configurable de 1 à 128. Ces nouveaux mécanismes de découverte permettent à NSX de mettre en application les règles de sécurité basées sur l'adresse IP pour les VM sur lesquelles VMware Tools n'est pas installé.
Guest Introspection : pour vCenter 6.5 et versions ultérieures, les VM Guest Introspection (GI) sont nommées Guest Introspection (XX.XX.XX.XX), où XX.XX.XX.XX est l'adresse IPv4 de l'hôte sur lequel réside la machine GI. Cela se produit lors du déploiement initial de GI.

Interface utilisateur de NSX :

Prise en charge de vSphere Client (HTML5) : introduit le plug-in d'interface utilisateur de VMware NSX pour vSphere Client (HTML5). Pour voir la liste des fonctionnalités prises en charge, consultez Fonctionnalités du plug-in VMware NSX for vSphere dans vSphere Client.
Compatibilité HTML5 avec vSphere Web Client (Flash) : les fonctionnalités de NSX développées dans HTML5 (par exemple, le tableau de bord) restent compatibles avec vSphere Client et vSphere Web Client, ce qui garantit une expérience transparente pour les utilisateurs qui ne peuvent pas passer immédiatement à vSphere Client.
Menu Navigation amélioré : nombre réduit de clics pour accéder à des fonctionnalités clés, telles que Regroupement des objets, Balises, Liste d'exclusion et Configuration système.

Opérations et dépannage :

Le Coordinateur de mise à niveau fournit un portail unique pour simplifier la planification et l'exécution d'une mise à niveau de NSX. Le coordinateur de mise à niveau fournit une vue système complète de tous les composants NSX avec les versions actuelles et cibles, des mesures de progression de la mise à niveau, des plans de mise à niveau en un clic ou personnalisés et des vérifications antérieure et postérieure.
Un nouveau tableau de bord HTML5 amélioré est disponible, ainsi que de nombreux nouveaux composants. Le tableau de bord est désormais votre page d'accueil par défaut. Vous pouvez également personnaliser des widgets existants définis par le système et vous pouvez créer vos propres widgets personnalisés via API.
Le nouveau tableau de bord À l'échelle du système collecte des informations sur l'échelle actuelle du système et affiche les valeurs maximales de configuration pour les paramètres d'échelle pris en charge. Des avertissements et des alertes peuvent également être configurés lorsque des limites sont proches ou dépassées.
Améliorations de la fiabilité et du dépannage de Guest introspection. Des fonctionnalités, telles que la notification d'état EAM, la progression de la mise à niveau, les noms personnalisés pour les SVM, la mémoire supplémentaire et plus encore, améliorent la fiabilité et le dépannage des déploiements de GI.
Une interface de ligne de commande centrale pour le commutateur logique, le routeur logique et le pare-feu distribué Edge réduit le temps de dépannage avec un accès centralisé aux fonctions de réseau distribué.
Un nouvel onglet Bundle de support est disponible pour vous permettre de collecter le bundle de support via l'interface utilisateur en un seul clic. Vous pouvez désormais collecter les données du bundle de support pour les composants NSX, tels que NSX Manager, les hôtes, les dispositifs Edge et les contrôleurs. Vous pouvez télécharger ce bundle de support agrégé ou vous pouvez importer directement le bundle vers un serveur distant. Vous pouvez afficher l'état global de collecte de données et l'état de chaque composant.
Un nouvel onglet Capture de paquets est disponible pour la capture de paquets via l'interface utilisateur. Si un hôte n'est pas dans un état sain, vous pouvez obtenir le fichier de vidage de paquets pour cet hôte et l'administrateur peut examiner les informations du paquet pour un débogage supplémentaire.
Vous pouvez désormais activer le mode CDO (Controller Disconnected Operation) dans l'onglet Gestion sur le site secondaire pour éviter les problèmes de connectivité temporaires. Le mode CDO assure que la connectivité du plan de données n'est pas affectée dans un environnement multi-site lorsque le site principal perd la connectivité.
Prise en charge de plusieurs Syslog pour un maximum de 5 serveurs Syslog.
Améliorations de l'API, dont la prise en charge JSON. NSX offre désormais le choix entre les formats de données JSON et XML. XML reste la valeur par défaut pour la compatibilité en amont.
Certains messages d'événement système NSX Edge incluent désormais les paramètres ID du dispositif Edge et/ou ID de VM. Par exemple, code d'événement 30100, 30014, 30031.
Ces paramètres de message ne seront pas disponibles pour les événements système plus anciens. Dans ce cas, le message d'événement affiche {0} ou {1} pour les paramètres ID du dispositif Edge et/ou ID de VM.
Vous pouvez désormais utiliser NSX API pour connaître l'état de l'hyperviseur. La surveillance de l'intégrité du tunnel d'hyperviseur est utile pour résoudre les problèmes rapidement. La réponse de l'API inclut l'état de la carte réseau physique, l'état du tunnel, l'état de la connexion entre l'hyperviseur et le plan de contrôle et l'état de la connexion entre l'hyperviseur et le plan de gestion.

Améliorations de NSX Edge :

Amélioration de la vérification de l'intégrité de l'équilibrage de charge Edge. Trois nouveaux moniteurs de vérification de l'intégrité ont été ajoutés : DNS, LDAP et SQL.
Vous pouvez désormais filtrer des itinéraires pour la redistribution basée sur LE/GE selon la longueur du préfixe de l'adresse IP de destination.
Prise en charge de BGP et du routage statique sur des tunnels GRE.
NAT64 fournit la traduction IPv6 vers IPv4.
Basculement plus rapide des services de routage Edge.
Les événements de routage génèrent désormais des événements système dans NSX Manager.
Améliorations des performances et de la résilience du VPN L3.

Versions, configuration système et installation

Remarque :

Le tableau ci-dessous répertorie les versions recommandées du logiciel VMware. Ces recommandations sont générales et ne doivent pas remplacer des recommandations spécifiques de l'environnement.
Ces informations sont à jour à la date de publication de ce document.
Pour voir les versions minimales prises en charge de NSX et d'autres produits VMware, consultez la matrice d'interopérabilité des produits VMware. VMware déclare des versions minimales prises en charge en fonction de tests internes.

Produit ou composant	Version
NSX for vSphere	VMware recommande la dernière version de NSX pour les nouveaux déploiements. Lors de la mise à niveau de déploiements existants, consultez les notes de mise à jour de NSX ou contactez votre représentant du support technique VMware pour plus d’informations sur les problèmes spécifiques avant de planifier une mise à niveau.
vSphere	Pour vSphere 6.0 : Pris en charge : 6.0 Update 2, 6.0 Update 3 Recommandé : 6.0 Update 3. vSphere 6.0 Update 3 résout le problème de VTEP en double dans les hôtes ESXi après le redémarrage de vCenter Server. Consultez l'article 2144605 de la base de connaissances de VMware pour plus d'informations. Pour vSphere 6.5 : Pris en charge : 6.5a, 6.5 Update 1 Recommandé : 6.5 Update 1. vSphere 6.5 Update 1 résout le problème d'EAM qui échoue avec l'erreur OutOfMemory. Consultez l'article 2135378 de la base de connaissances de VMware pour plus d'informations. Remarque : vSphere 5.5 n'est pas pris en charge avec NSX 6.4.0.
Guest Introspection pour Windows	Toutes les versions de VMware Tools sont prises en charge. Certaines fonctionnalités de Guest Introspection requièrent des versions VMware Tools plus récentes : Utilisez VMware Tools 10.0.9 et 10.0.12 pour activer le composant Thin Agent Network Introspection facultatif fourni avec VMware Tools. Effectuez la mise à niveau vers VMware Tools 10.0.8 et versions ultérieures pour résoudre la lenteur des VM après la mise à niveau de VMware Tools dans NSX/vCloud Networking and Security (consultez l'article 2144236 de la base de connaissances de VMware). Utilisez VMware Tools 10.1.0 et versions ultérieures pour la prise en charge de Windows 10. Utilisez VMware Tools 10.1.10 et versions ultérieures pour la prise en charge de Windows Server 2016.
Guest Introspection pour Linux	Cette version de NSX prend en charge les versions suivantes de Linux : RHEL 7 GA (64 bits) SLES 12 GA (64 bits) Ubuntu 14.04 LTS (64 bits)

Configuration système et installation

Pour obtenir la liste complète des prérequis à l'installation de NSX, consultez la section Configuration système pour NSX dans le Guide d'installation de NSX.

Pour obtenir des instructions d'installation, consultez le Guide d'installation de NSX ou le Guide d'installation de Cross-vCenter NSX.

Fonctionnalités obsolètes et retirées

Avertissements sur la fin de vie et la fin du support

Pour plus d'informations sur NSX et d'autres produits VMware devant être mis à niveau rapidement, consultez la Matrice du cycle de vie des produits VMware.

NSX for vSphere 6.1.x est arrivé en fin de disponibilité et a atteint sa date de fin de support général le 15 janvier 2017. (Consultez également l'article 2144769 de la base de connaissances de VMware.)
Arrêt de la prise en charge des dispositifs vCNS Edge. Vous devez effectuer une mise à niveau vers un dispositif NSX Edge avant de procéder à la mise à niveau vers NSX 6.3 ou version ultérieure.
Le support général de NSX for vSphere 6.2.x prendra fin le 20 août 2018.

Suppressions d'API et modifications de comportement

Abandons dans NSX 6.4.0
Les éléments suivants sont obsolètes et pourront être supprimés dans une version ultérieure.

Le paramètre systemStatus dans GET /api/4.0/edges/edgeID/status est obsolète.
GET /api/2.0/services/policy/serviceprovider/firewall/ est obsolète. Utilisez GET /api/2.0/services/policy/serviceprovider/firewall/info à la place.
Le paramètre tcpStrict dans la section de configuration globale du pare-feu distribué est obsolète. À partir de NSX 6.4.0, tcpStrict est défini au niveau de la section. Remarque : si vous effectuez une mise à niveau vers NSX 6.4.0 ou une version ultérieure, le paramètre de configuration globale pour tcpStrict est utilisé pour configurer tcpStrict dans chaque section de couche 3 existante. tcpStrict est défini sur false dans les sections de couche 2 et les sections de redirection de couche 3. Reportez-vous à la section « Utilisation de la configuration du pare-feu distribué » dans le Guide de NSX API pour plus d'informations.

Changements de comportement dans NSX 6.4.0
Dans NSX 6.4.0, le paramètre <name> est requis lorsque vous créez un contrôleur avec POST /api/2.0/vdn/controller.

NSX 6.4.0 présente les modifications suivantes liées à la gestion des erreurs :

Auparavant, POST /api/2.0/vdn/controller répondait avec 201 Créé pour indiquer que le travail de création du contrôleur est créé. Toutefois, la création du contrôleur peut toujours échouer. À partir de NSX 6.4.0, la réponse est 202 Accepté.
Auparavant, si vous envoyiez une demande d'API qui n'était pas autorisée en mode autonome ou de transit, l'état de réponse était 400 Demande incorrecte. À partir de la version 6.4.0, l'état de réponse est 403 Interdit.

Suppressions de CLI et modifications de comportement

N’utilisez pas les commandes non prises en charge sur les nœuds NSX Controller
Il existe des commandes non documentées pour configurer DNS et NTP sur les nœuds NSX Controller. Ces commandes ne sont pas prises en charge et ne doivent pas être utilisées sur les nœuds NSX Controller. Vous ne devez utiliser que les commandes qui sont documentées dans ce Guide de la CLI de NSX.

Notes relatives aux mises à niveau

Remarques générales sur la mise à niveau
Notes de mise à niveau pour les composants NSX
Notes de mise à niveau pour FIPS

Remarque : Pour obtenir la liste des problèmes connus affectant l’installation et les mises à niveau, consultez la section Problèmes connus de mise à niveau et d'installation.

Remarques générales sur la mise à niveau

Pour mettre NSX à niveau, vous devez réaliser une mise à niveau complète de NSX, y compris la mise à niveau du cluster d'hôte (les VIB de l'hôte sont alors mis à niveau). Pour obtenir des instructions, consultez le Guide de mise à niveau de NSX, y compris la section Mettre à niveau des clusters d'hôte.
La mise à niveau des VIB NSX sur des clusters d'hôtes à l'aide de VUM n'est pas prise en charge. Utilisez le Coordinateur de mise à niveau, Préparation de l'hôte ou les REST API associés pour mettre à niveau des VIB NSX sur des clusters d'hôtes.
Configuration système requise : pour plus d'informations sur la configuration système requise lors de l'installation et de la mise à niveau de NSX, consultez la section Configuration système requise pour NSX dans la documentation de NSX.
Chemin de mise à niveau de NSX : La matrice d'interopérabilité des produits VMware fournit des détails sur les chemins de mise à niveau à partir de VMware NSX.
La mise à niveau de cross-vCenter NSX est abordée dans le Guide de mise à niveau de NSX.
Les rétrogradations ne sont pas prises en charge :
- Capturez toujours une sauvegarde de NSX Manager avant de procéder à une mise à niveau.
- Lorsque NSX a été mis à niveau correctement, NSX ne peut pas être rétrogradé.
Pour vérifier que la mise à niveau vers NSX 6.4.x est réussie, consultez l'article 2134525 de la base de connaissances.
Il n'existe pas de support pour les mises à niveau depuis vCloud Networking and Security vers NSX 6.4.x. Vous devez d'abord effectuer une mise à niveau vers une version 6.2.x prise en charge.
Interopérabilité : consultez la Matrice d’interopérabilité des produits VMware pour tous les produits VMware pertinents avant d’effectuer la mise à niveau.
- Mise à niveau vers NSX 6.4 : NSX 6.4 n'est pas compatible avec vSphere 5.5.
- Mise à niveau vers vSphere 6.5a ou version ultérieure : lors de la mise à niveau de vSphere 6.0 vers vSphere 6.5a ou version ultérieure, vous devez d'abord effectuer la mise à niveau vers NSX 6.3.0 ou version ultérieure. NSX 6.2.x n'est pas compatible avec vSphere 6.5. Consultez Mise à niveau de vSphere dans un environnement NSX dans le Guide de mise à niveau de NSX.
Compatibilité des services de partenaires : si votre site utilise des services de partenaires VMware pour Guest Introspection ou Network Introspection, vous devez examiner le Guide de compatibilité VMware avant la mise à niveau, afin de vérifier que le service de votre fournisseur est compatible avec cette version de NSX.
Plug-in Networking and Security : Après la mise à niveau de NSX Manager, vous devez vous déconnecter et vous reconnecter à vSphere Web Client. Si le plug-in NSX ne s'affiche pas correctement, videz le cache du navigateur et effacez l'historique. Si le plug-in Networking and Security ne figure pas dans vSphere Web Client, réinitialisez le serveur vSphere Web Client, comme expliqué dans le Guide de mise à niveau de NSX.
Environnements sans état : pour les mises à niveau de NSX dans un environnement d'hôtes sans état, les nouveaux VIB sont pré-ajoutés au profil d'image d'hôte lors du processus de mise à niveau de NSX. Par conséquent, le processus de mise à niveau de NSX sur des hôtes sans état s'effectue selon les étapes suivantes :
Dans les versions antérieures à NSX 6.2.0, une seule URL de NSX Manager permettait de trouver les VIB pour une version spécifique de l’hôte ESX. (L'administrateur n'avait alors qu'à connaître une seule URL, quelle que soit la version de NSX.) Dans NSX 6.2.0 et versions ultérieures, les nouveaux VIB NSX sont disponibles sur plusieurs URL. Pour trouver les VIB adéquats, vous devez procéder comme suit :
1. Recherchez la nouvelle URL du VIB sur https://<nsxmanager>/bin/vdn/nwfabric.properties.
2. Récupérez les VIB pour la version de l'hôte ESX requise à partir de l'URL correspondante.
3. Ajoutez-les au profil d'image d'hôte.

Notes de mise à niveau pour les composants NSX

Mise à niveau de NSX Manager

Important : Si vous mettez à niveau NSX 6.2.0, 6.2.1 ou 6.2.2 vers NSX 6.3.5 ou version ultérieure, vous devez appliquer une solution avant de démarrer la mise à niveau. Consultez l'article 000051624 de la base de connaissances de VMware pour obtenir plus de détails.
Si vous utilisez SFTP lors des sauvegardes NSX, choisissez sha2-hmac-256 après la mise à niveau vers la version 6.3.0 ou version ultérieure, car il n'y a aucune prise en charge pour hmac-sha1. Consultez l’article 2149282 de la base de connaissances de VMware pour obtenir la liste des algorithmes de sécurité pris en charge.

Mise à niveau du contrôleur

Le cluster NSX Controller doit contenir trois nœuds de contrôleur pour effectuer la mise à niveau vers NSX 6.3.3. S’il dispose de moins de trois contrôleurs, vous devez ajouter des contrôleurs avant de commencer la mise à niveau. Pour obtenir des instructions, reportez-vous à Déployer le cluster NSX Controller.
Dans NSX 6.3.3, le système d’exploitation sous-jacent de NSX Controller change. Cela signifie que lorsque vous effectuez une mise à niveau de NSX 6.3.2 ou version antérieure vers NSX 6.3.3 ou version ultérieure, au lieu d'une mise à niveau logicielle sur place, les contrôleurs existants sont supprimés un à un et les nouveaux contrôleurs basés sur Photon OS sont déployés en utilisant les mêmes adresses IP.

Lorsque les contrôleurs sont supprimés, cela supprime également les règles d'anti-affinité de DRS associées. Vous devez créer des règles d'anti-affinité dans vCenter pour empêcher les nouvelles VM de contrôleur de résider sur le même hôte.

Pour plus d'informations sur les mises à niveau du contrôleur, consultez Mettre à niveau le cluster NSX Controller.

Mise à niveau du cluster d’hôte

Si vous mettez à niveau NSX 6.3.2 ou version antérieure vers NSX 6.3.3 ou version ultérieure, les noms des VIB NSX changent.
Les VIB esx-vxlan et esx-vsip sont remplacés par esx-nsxv si vous avez installé NSX 6.3.3 ou version ultérieure sur ESXi 6.0 ou version ultérieure.
Mise à niveau et désinstallation sans redémarrage sur les hôtes : dans vSphere 6.0 et versions ultérieures, une fois que vous avez mis à niveau NSX 6.2.x vers NSX 6.3.x ou version ultérieure, toutes les modifications suivantes apportées à des VIB NSX ne requièrent pas de redémarrage. Au lieu de cela, les hôtes doivent entrer en mode de maintenance pour terminer la modification de VIB. Cela affecte la mise à niveau du cluster d'hôtes NSX et la mise à niveau d'ESXi. Consultez le Guide de mise à niveau de NSX pour plus d'informations.

Mise à niveau de NSX Edge

Les clusters d'hôtes doivent être préparés pour NSX avant la mise à niveau des dispositifs NSX Edge : La communication au niveau du plan de gestion entre les dispositifs NSX Manager et Edge via le canal VIX n'est plus prise en charge à partir de la version 6.3.0. Seul le canal de bus de messages est pris en charge. Lorsque vous effectuez une mise à niveau à partir de NSX 6.2.x ou version antérieure vers NSX 6.3.0 ou version ultérieure, vous devez vérifier que les clusters d'hôtes où sont déployés les dispositifs NSX Edge sont préparés pour NSX, et que l'état de l'infrastructure de messagerie s'affiche en VERT. Si les clusters d'hôtes ne sont pas préparés pour NSX, la mise à niveau du dispositif NSX Edge échouera. Reportez-vous à Mise à niveau de NSX Edge dans le Guide de mise à niveau de NSX pour plus de détails.

Mise à niveau d'Edge Services Gateway (ESG) :
À partir de NSX 6.2.5, la réservation de ressources est réalisée au moment de la mise à niveau de NSX Edge. Lorsque vSphere HA est activé sur un cluster disposant de ressources insuffisantes, l'opération de mise à niveau peut échouer en raison de contraintes vSphere HA non respectées.

Pour éviter de tels échecs de mise à niveau, procédez comme suit avant de mettre une passerelle ESG à niveau :

Les réservations de ressources suivantes sont utilisées par NSX Manager si vous n’avez pas explicitement défini des valeurs lors de l’installation ou de la mise à niveau.

NSX Edge Facteur de forme	Réservation de CPU	Réservation de mémoire
COMPACTE	1 000 MHz	512 Mo
GRANDE	2 000 MHz	1 024 Mo
SUPER GRANDE	4 000 MHz	2 048 Mo
EXTRA GRANDE	6 000 MHz	8 192 Mo

Veillez toujours à ce que votre installation suive les meilleures pratiques établies pour vSphere HA. Consultez l'article 1002080 de la base de connaissances.
Utilisez l'API de configuration de réglage NSX :
PUT https://<nsxmanager>/api/4.0/edgePublish/tuningConfiguration
en veillant à ce que les valeurs de edgeVCpuReservationPercentage et edgeMemoryReservationPercentage respectent les ressources disponibles pour le facteur de forme (voir les valeurs par défaut dans le tableau ci-dessus).

Désactiver l'option de démarrage de machine virtuelle de vSphere lorsque vSphere HA est activé et que des dispositifs Edge sont déployés. Après avoir mis à niveau vos dispositifs NSX Edge de la version 6.2.4 ou antérieure vers la version 6.2.5 ou ultérieure, vous devez désactiver l'option de démarrage de machine virtuelle de vSphere pour chaque dispositif NSX Edge dans un cluster dans lequel vSphere HA est activé et des dispositifs Edge sont déployés. Pour cela, ouvrez vSphere Web Client, recherchez l'hôte ESXi sur lequel réside la machine virtuelle NSX Edge, cliquez sur Gérer > Paramètres et, sous Machines virtuelles, sélectionnez Démarrage/Arrêt de la VM, cliquez sur Modifier et vérifiez que la machine virtuelle est en mode Manuel (c'est-à-dire qu'elle n'est pas ajoutée à la liste Démarrage/Arrêt automatique).
Avant de procéder à la mise à niveau vers NSX 6.2.5 ou version ultérieure, vérifiez que toutes les listes de chiffrement d'équilibrage de charge sont séparées par un signe deux-points. Si votre liste de chiffrement utilise un autre séparateur (par exemple, des virgules), effectuez un appel PUT à https://nsxmgr_ip/api/4.0/edges/EdgeID/loadbalancer/config/applicationprofiles et remplacez chaque liste <ciphers> </ciphers> dans <clientssl> </clientssl> et <serverssl> </serverssl> par une liste séparée par des deux-points. Par exemple, le segment pertinent du corps de demande peut ressembler à ce qui suit. Répétez cette procédure pour tous les profils d'application :
```
<applicationProfile>
  <name>https-profile</name>
  <insertXForwardedFor>false</insertXForwardedFor>
  <sslPassthrough>false</sslPassthrough>
  <template>HTTPS</template>
  <serverSslEnabled>true</serverSslEnabled>
  <clientSsl>
    <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
    <clientAuth>ignore</clientAuth>
    <serviceCertificate>certificate-4</serviceCertificate>
  </clientSsl>
  <serverSsl>
    <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
    <serviceCertificate>certificate-4</serviceCertificate>
  </serverSsl>
  ...
</applicationProfile>
```
Définir la version de chiffrement correcte pour les clients d'équilibrage de charge sur des versions de vROPs antérieures à la version 6.2.0 : les membres de pool vROPs sur des versions de vROPs antérieures à la version 6.2.0 utilisent TLS version 1.0 et, par conséquent, vous devez définir explicitement une valeur d'extension de moniteur en définissant "ssl-version=10" dans la configuration de l'équilibrage de charge NSX. Consultez Créer un contrôle de service dans le Guide d'administration de NSX pour plus d'informations.
```
{
                "expected" : null,
                "extension" : "ssl-version=10",
                "send" : null,
                "maxRetries" : 2,
              "name" : "sm_vrops",
              "url" : "/suite-api/api/deployment/node/status",
              "timeout" : 5,
              "type" : "https",
              "receive" : null,
              "interval" : 60,
              "method" : "GET"
           }
```

Mise à niveau de Guest Introspection

Les VM Guest Introspection contiennent désormais des informations supplémentaires pour identifier l'hôte dans un fichier XML sur la machine. Lors de la connexion à la VM Guest Introspection, le fichier « /opt/vmware/etc/vami/ovfEnv.xml » doit inclure des informations sur l'identité de l'hôte.

Notes de mise à niveau pour FIPS

Lorsque vous effectuez la mise à niveau depuis une version de NSX antérieure à NSX 6.3.0 vers NSX 6.3.0 ou version ultérieure, vous ne devez pas activer le mode FIPS avant la fin de la mise à niveau. L'activation du mode FIPS avant la fin de la mise à niveau interrompra la communication entre les composants mis à niveau et les composants non mis à niveau. Consultez Comprendre le mode FIPS et la mise à niveau de NSX dans le Guide de mise à niveau de NSX pour plus d'informations.

Chiffrements pris en charge sous OS X Yosemite et OS X El Capitan : Si vous utilisez le client VPN SSL sous OS X 10.11 (El Capitan), vous pourrez vous connecter à l'aide des chiffrements AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA38, AES256-SHA et AES128-SHA et, si vous utilisez OS X 10.10 (Yosemite), vous pourrez vous connecter à l'aide des chiffrements AES256-SHA et AES128-SHA uniquement.
N'activez pas FIPS avant la fin de la mise à niveau vers NSX 6.3.x. Consultez Comprendre le mode FIPS et la mise à niveau de NSX dans le Guide de mise à niveau de NSX pour plus d'informations.
Avant d'activer FIPS, vérifiez que les solutions de partenaire sont certifiées pour le mode FIPS. Consultez le Guide de compatibilité VMware et la documentation de partenaire correspondante.

Conformité FIPS

NSX 6.4 utilise des modules de chiffrement validés pour FIPS 140-2 pour la cryptographie liée à la sécurité lorsqu'ils sont correctement configurés.

Remarque :

Contrôleur et VPN de mise en cluster : NSX Controller utilise le VPN IPsec pour connecter des clusters de contrôleur. Le VPN IPsec utilise le module de chiffrement du noyau VMware Linux (environnement VMware Photon OS 1.0), qui est en cours de validation CMVP.
VPN IPsec Edge : Le VPN IPsec NSX Edge utilise le module de chiffrement du noyau VMware Linux (environnement VMware NSX OS 4.4), qui est en cours de validation CMVP.

Historique de révision du document

16 janvier 2018 : Première édition.
17 janvier 2018 : Deuxième édition. Ajout des problèmes résolus 1461421, 1499978, 1628679, 1634215, 1716464, 1753621, 1777792, 1787680, 1792548, 1801685, 1849043.
22 janvier 2018 : Troisième édition. Ajout du problème connu 2036024.
24 janvier 2018 : Quatrième édition. Mise à jour des notes de mise à niveau.
1er février 2018 : Cinquième édition. Mise à jour des informations de conformité FIPS.
22 février 2018 : Sixième édition. Ajout des problèmes résolus 1773240, 1839953, 1920574, 1954964, 1965589. Ajout des problèmes connus 2013820, 2016689, 2017806, 2026069.
2 mars 2018 : Septième édition. Mise à jour de la section Nouveautés.
6 avril 2018 : Huitième édition. Ajout du problème connu 2014400. Ajout des problèmes résolus 2029693 et 2003453. Mise à jour des changements de comportement et des abandons.
27 avril 2018 : Neuvième édition. Mise à jour des changements de comportement et des abandons.
7 mai 2018 : Dixième édition. Ajout des problèmes résolus 1772473 et 1954628. Ajout des problèmes connus 1993691, 2005900 et 2007991.
14 septembre 2018 : onzième édition. Ajout du problème connu 2006576.
5 octobre 2018 : Douzième édition. Ajout du problème connu 2164138.

Problèmes résolus

Les problèmes résolus sont regroupés comme suit :

Problèmes résolus généraux
Problèmes résolus liés à la mise en réseau logique et NSX Edge
Problèmes résolus de NSX Manager
Problèmes résolus des services de sécurité

Problèmes résolus généraux

Problème résolu 1783528 : L'utilisation du CPU de NSX Manager connaît des pics tous les vendredis soir/samedis matin
NSX interroge LDAP pour une synchronisation complète tous les vendredis soir. Il n'existe aucune option pour configurer une unité d'organisation ou un conteneur Active Directory spécifique, par conséquent, NSX interroge tous les objets qui sont liés au domaine fourni.
Problème résolu 1801685 : Impossible d’afficher les filtres sur ESXi après une mise à niveau de la version 6.2.x vers la version 6.3.0 en raison d’un échec de connexion à l’hôte
Après une mise à niveau de NSX 6.2.x vers la version 6.3.0 et des modules VIB de cluster vers la version 6.3.0 bits, même si l'état de l'installation indique que cette dernière est terminée et que le pare-feu est activé, l'indicateur de « l'intégrité du canal de communication » signale une défaillance au niveau de la connectivité entre NSX Manager et l'agent de pare-feu et au niveau de la connectivité entre NSX Manager et l'agent ControlPlane. Cela entraîne des problèmes au niveau de la publication des règles de pare-feu et des stratégies de sécurité. En outre, la configuration du VXLan risque ne pas être envoyée vers les hôtes.
Problème résolu 1780998 : NSX Manager conserve uniquement 100 000 entrées de journal d'audit au lieu du million d'entrées documentées
Seules 100 000 entrées de journal sont disponibles dans les journaux d'audit.
Problème résolu 1874735 : Le lien « Mise à niveau disponible » n'est pas affiché si le cluster a une alarme
Les utilisateurs ne peuvent pas distribuer la nouvelle spécification de service à EAM, car le lien est manquant et le service ne sera pas mis à niveau.
Problème résolu 1893299 : Une analyse ODS des fichiers non normaux comme un périphérique de traitement par bloc ou un périphérique de caractère peut déclencher la panne ou le blocage du système
ODS analyse uniquement des fichiers normaux et des liens symboliques. Il n'accède pas aux fichiers non normaux comme un périphérique de traitement par bloc ou un fichier de caractère directement, mais il peut y accéder si ces fichiers sont la cible de liens symboliques. L'accès à ces fichiers risque d'entraîner une action accidentelle telle qu'une panne du système, un blocage du système, etc.
Problème résolu 1897878 : Utilisation élevée de la mémoire (et parfois du CPU) sur l'USVM, ce qui entraîne des problèmes de fonctionnement des VM sur le même hôte
Une utilisation élevée de la mémoire entraîne l'échec de la connexion des VM ne répondant pas.
Problème résolu 1882345 : Le CPU ne cesse d'augmenter dans le temps jusqu'à atteindre 100 % et y rester
Lorsque l'écoute ARP est activée comme mécanisme de détection d'adresse IP et que l'environnement dispose de VM avec plusieurs adresses IP par vNIC, l'utilisation du CPU ne cesse d'augmenter, jusqu'à atteindre 100 %, et les performances sont fortement dégradées.
Problème résolu 1920343 : Le certificat de serveur peut être créé sans clé privée
Si les données de clé privée sont fournies dans le contenu de certificat, la clé privée est ignorée.
Problème résolu 1926060 : La case Inverser la source sur la page Pare-feu > Spécifier source ou Spécifier destination est cochée, même lorsque vous cliquez en dehors
La case Inverser la source est cochée lorsque vous déplacez des objets de la liste Objets disponibles vers la liste Objets sélectionnés.
Problème résolu 1965589 : La publication des brouillons DFW générés à partir de versions antérieures à la version 6.4.0 échoue sur 6.4.0
Les brouillons créés avant la version 6.4 ne disposent pas de sections de couche 2 avec un attribut d'indicateur sans état. Lorsque ce type de brouillon est chargé/publié dans une configuration 6.4, il échoue, car l'indicateur sans état des sections de couche 2 est censé être défini sur true dans NSX 6.4 et version ultérieure. Comme l'absence d'attribut entraîne une valeur par défaut (c'est-à-dire, false), la validation de la configuration échoue, ce qui entraîne l'échec de la publication.

Problèmes résolus liés à la mise en réseau logique et NSX Edge

Problème résolu : Journaux de Controller saturés avec le pont « Échec de l'ajout/la suppression d'un enregistrement de Mac MacRecord pour l'instance de pont non existante ».
Lorsque le partitionnement change, le pont ne parvient pas à envoyer la jonction au contrôleur. Problème résolu dans la version 6.4.0
Problème résolu 2014400 : Un dispositif NSX Edge en veille commence à répondre au trafic IPv6 lorsque la fonctionnalité de pare-feu sur le dispositif Edge est désactivée.
Avec IPv6 activé sur NSX Edge, si un basculement est déclenché, les périphériques en amont seront mis à jour avec l'adresse MAC des dispositifs Edge en veille, en conséquence de quoi le trafic N-S peut être transmis à un dispositif Edge incorrect. Problème résolu dans la version 6.4.0
Problème résolu 1783065 : Impossible de configurer l'équilibrage de charge pour le port UDP avec TCP par adresse IPv4 et IPv6 en même temps
UDP ne prend en charge que ipv4-ipv4, ipv6-ipv6 (frontal-principal). Il existe un bogue dans NSX Manager qui provoque la lecture d'une adresse locale de lien IPv6 et son transfert en tant qu'adresse IP de l'objet de regroupement et qui vous empêche de sélectionner le protocole IP à utiliser dans la configuration d'équilibrage de charge.
Voici un exemple de configuration d'équilibrage de charge faisant apparaître le problème :
Dans la configuration d'équilibrage de charge, le pool « vCloud_Connector » est configuré avec un objet de regroupement (vm-2681) comme membre de pool et cet objet contient des adresses IPv4 et IPv6, qui ne peuvent pas être prises en charge par le moteur LB L4.
```
{
              "algorithm" : {
        ...
    },
              "members" : [
        {
            ...  ,
            ...
        }
              ],
              "applicationRules" : [],
              "name" : "vCloud_Connector",
              "transparent" : {
                 "enable" : false
              }
        }

  {
              "value" : [
                 "fe80::250:56ff:feb0:d6c9",
                 "10.204.252.220"
              ],
              "id" : "vm-2681"
            }
```
Problème résolu 1764258 : Perte de trafic pendant une durée pouvant atteindre huit minutes après un basculement HA ou une synchronisation forcée configurée à l'aide d'une sous-interface sur un dispositif NSX Edge
Si un basculement HA se déclenche ou que vous démarrez une synchronisation forcée sur une sous-interface, le trafic n'aboutit pas pendant une durée pouvant atteindre huit minutes.
Problème résolu 1850773 : Le NAT NSX Edge signale une configuration non valide lorsque plusieurs ports sont utilisés pour la configuration de l’équilibrage de charge
Ce problème se produit chaque fois que vous configurez un serveur virtuel d’équilibrage de charge avec plusieurs ports. Pour cette raison, le NAT devient ingérable pendant que cet état de configuration existe pour le dispositif NSX Edge affecté.
Problème résolu 1733282 : NSX Edge ne prend plus en charge les itinéraires de périphérique statiques
NSX Edge ne prend pas en charge la configuration d'itinéraires statiques avec l'adresse de tronçon suivant NULL.
Problème résolu 1711013 : Environ 15 minutes sont nécessaires pour synchroniser FIB avec un dispositif NSX Edge actif/en veille après le redémarrage d'une VM en veille.
Lorsqu'un dispositif NSX Edge en veille est mis hors tension, la session TCP n'est pas fermée entre le mode actif et le mode de veille. Le dispositif Edge actif détectera que la veille est inactive après l'échec KA (keepalive) (15 minutes). Au bout de 15 minutes, une nouvelle connexion de socket est établie avec le dispositif Edge en veille et FIB est synchronisé entre le dispositif Edge actif/en veille.
Problème résolu 1781438 : Sur les dispositifs ESG ou DLR NSX Edge, le service de routage n'envoie pas de message d'erreur s'il reçoit l'attribut de chemin d'accès BGP MULTI_EXIT_DISC plusieurs fois.
Le routeur Edge ou un routeur logique distribué n'envoie pas de message d'erreur s'il reçoit l'attribut de chemin d'accès BGP MULTI_EXIT_DISC plusieurs fois. Conformément à RFC 4271 [Sec 5], le même attribut (attribut du même type) ne peut pas apparaître plusieurs fois dans le champ Attributs de chemin d'accès d'un message de mise à jour particulier.
Problème résolu 1860583 : Évitez d’utiliser des sysloggers distants comme nom de domaine complet si DNS n’est pas accessible.
Sur un dispositif NSX Edge, si les sysloggers distants sont configurés à l’aide du nom de domaine complet et que DNS n’est pas accessible, la fonctionnalité de routage peut être affectée. Le problème ne se produit pas systématiquement.
Problème résolu 1242207 : La modification des ID de routeur pendant l'exécution n'est pas reflétée dans la topologie OSPF
Si vous essayez de modifier l'ID de routeur sans désactiver OSPF, de nouvelles annonces d'état des liens (LSA) externes ne sont pas générées de nouveau avec cet ID de routeur, ce qui entraîne la perte des itinéraires externes OSPF.
Problème résolu 1767135 : Erreurs lors de la tentative d'accès à des certificats et à des profils d'application sous l'équilibrage de charge
Les utilisateurs avec des privilèges d'administrateur de sécurité et de portée Edge ne peuvent pas accéder aux certificats et aux profils d'application sous l'équilibrage de charge. vSphere Web Client affiche des messages d'erreur.
Problème résolu 1844546 : L'adresse IP attribuée par l'utilisateur configuré sur l'interface HA du DLR ne fonctionne pas
La saisie d'une adresse IP attribuée par un utilisateur spécifique pour l'interface HA du DLR ne fonctionne pas. La saisie de plusieurs adresses IP entraîne une « Erreur de serveur interne ».
Problème résolu 1874782 : NSX Edge devient ingérable en raison d’un problème de connexion au bus de message
Si NSX Edge rencontre des problèmes de connexion au bus de message, NSX Manager ne peut pas modifier la configuration ou récupérer des informations à partir de NSX Edge.
Problème résolu 1461421 : la sortie de la commande « show ip bgp neighbor » pour NSX Edge conserve le nombre historique de connexions précédemment établies
La commande « show ip bgp neighbor » affiche le nombre de fois que la machine d'état BGP est passée à l'état Établi pour un homologue donné. La modification du mot de passe utilisé avec l'authentification MD5 entraîne la destruction et la recréation de la connexion homologue, ce qui en retour effacera les compteurs. Ce problème ne se produit pas avec un DLR Edge.
Problème résolu 1499978 : Les messages de Syslog Edge n'atteignent pas le serveur Syslog distant
Tout de suite après le déploiement, le serveur Syslog Edge ne peut pas résoudre les noms d'hôte pour des serveurs Syslog distants configurés.
Problème résolu 1916360 : Le basculement HA peut échouer en raison d'un disque complet lorsque plus de 100 itinéraires sont installés.
Lorsque plus de 100 itinéraires sont installés, le démon vmtools sur le dispositif Edge en veille envoie 2 messages de journal d'avertissement toutes les 30 secondes. Les journaux sont enregistrés dans un fichier appelé /var/log/vmware-vmsvc.log, qui peut croître jusqu'à remplir complètement la partition de journal. La rotation des journaux n'est pas configurée pour ce fichier journal. Lorsque cela se produit, le basculement HA peut échouer.
Problème résolu 1634215 : La sortie des commandes CLI OSPF n'indique pas si le routage est désactivé
Lorsqu'OSPF est désactivé, la sortie des commandes CLI de routage n'affiche aucun message indiquant « OSPF est désactivé ». La sortie est vide.
Problème résolu 1716464 : l'équilibrage de charge NSX ne sera pas acheminé vers des VM récemment balisées avec une balise de sécurité.
Si on déploie deux VM avec une balise donnée, puis que l'on configure un équilibrage de charge pour l'acheminement vers cette balise, l'équilibrage de charge procédera à l'acheminement vers ces deux VM sans problème. En revanche, si on déploie ensuite une troisième VM avec cette balise, l'équilibrage de charge ne procède à l'acheminement que vers les deux premières VM.
Problème résolu 1935204 : Le DLR prend entre 1 et 1,5 seconde pour la résolution ARP
Lorsque la suppression ARP échoue, la résolution ARP du DLR local pour une machine virtuelle en cours d'exécution dans un hôte distant prend entre 1 et 1,5 seconde.
Problème résolu 1777792 : Le point de terminaison homologue défini sur ANY entraîne l'échec de la connexion IPSec
Lorsque la configuration IPSec de NSX Edge définit le point de terminaison homologue distant sur « ANY », le dispositif Edge fonctionne comme un « serveur » IPSec et attend que les homologues distants lancent les connexions. Toutefois, lorsque l'initiateur envoie une demande d'authentification à l'aide de PSK+XAUTH, le dispositif Edge affiche ce message d'erreur : « Message de mode principal initial reçu sur XXX.XXX.XX.XX:500, mais aucune connexion n'a été autorisée avec policy=PSK+XAUTH » et IPsec ne peut pas être établi.
Problème résolu 1881348 : Problème avec la configuration d'AS_TRANS (ASN 23456) pour le numéro de système autonome (ASN) local de BGP.
La configuration d'AS_TRANS (ASN 23456) pour le numéro de système autonome (ASN) local de BGP présente des problèmes sur ESG/DLR, et
les voisins BGP ne s'activent pas, même après la restauration du numéro de système autonome (ASN) sur un numéro valide.
Problème résolu 1792548 : NSX Controller peut être bloqué au message : « En attente de jonction du cluster »
NSX Controller peut être bloqué au message : « En attente de jonction du cluster » (commande d'interface de ligne de commande :show control-cluster status). Cela se produit, car la même adresse IP a été configurée pour les interfaces eth0 et breth0 du contrôleur alors que ce dernier s'active. Vous pouvez vérifier cela en utilisant la commande d'interface de ligne de commande suivante sur le contrôleur : show network interface
Problème résolu 1983497 : Un écran violet s'affiche lorsqu'une modification du basculement de pont et une modification de la configuration de pont se produisent en même temps
Lorsqu'une modification du basculement de pont et une modification de la configuration de pont se produisent en même temps, cela peut entraîner un blocage et un écran violet. Le risque de blocage est faible.
Problème résolu 1849042/1849043 : Verrouillage du compte d'administrateur lorsqu'une période de validité du mot de passe est configurée sur le dispositif NSX Edge
Si une période de validité du mot de passe est configurée pour l'utilisateur administrateur sur le dispositif NSX Edge, lorsque le mot de passe expire, il sera demandé à l'utilisateur de modifier le mot de passe à chaque connexion au dispositif pendant 7 jours. La non-modification du mot de passe entraînera le verrouillage du compte. En outre, si le mot de passe est modifié au moment de la connexion à l'invite de l'interface de ligne de commande, le nouveau mot de passe peut ne pas être conforme à la stratégie de mot de passe fort appliquée par l'interface utilisateur et REST.
Problème résolu 1982690 : NSX Controller ne stocke pas l'entrée MAC de la VM de charge de travail sur l'hôte ESXi sur lequel la VM de contrôle de pont L2 active est en cours d'exécution.
Vous pouvez rencontrer une perte de trafic pour toutes les VM de charge de travail qui sont installées sur l'hyperviseur sur lequel la VM de contrôle de pontage actif est exécutée.
Problème résolu 1753621 : lorsqu'un dispositif Edge avec un AS local privé envoie des itinéraires à des homologues EBGP, tous les chemins d'AS privés sont extraits des mises à jour de routage BGP envoyées.
Actuellement, NSX for vSphere présente une limite qui l'empêche de partager le chemin d'AS complet avec des voisins eBGP lorsque le chemin d'AS contient uniquement des chemins d'AS privés. Bien que ce comportement soit voulu dans la plupart des cas, il peut arriver que l'administrateur souhaite partager des chemins d'AS privés avec un voisin BGP. Ce correctif permet de modifier le comportement « chemin d'AS privé » des homologues BGP externes. Le comportement par défaut de cette fonctionnalité consiste à « supprimer l'ASN privé », qui s'aligne sur les versions antérieures de NSX for vSphere.
Problème résolu 1954964 : État du moteur HA non mis à jour correctement sur une passerelle ESG en veille après Split Brain
Dans certains cas, après une récupération Split Brain, l'état du moteur de configuration ESG en veille peut ne pas être mis à jour correctement. Il s'agit d'un état incohérent et les clients peuvent voir des pertes de trafic intermittentes dans cet état.
Problème résolu 1920574 : Impossible de configurer des sous-interfaces pour un dispositif Edge
La création de sous-interfaces sur un dispositif Edge échoue avec NSX for vSphere 6.3.2/6.3.3 (impossible de publier la sous-interface avec une adresse IP).
Problème résolu 1772473 : Les clients SSLVPN ne peuvent pas obtenir l'adresse IP de la part d'ippool
Les clients ne peuvent pas se connecter au réseau privé, car aucune adresse IP n'est attribuée depuis ippool. L'adresse IP d'ippool est consommée dans la reconnexion automatique.

Les clients ne peuvent pas se connecter au réseau privé, car aucune adresse IP n'est attribuée à partir d’ippool lorsque le client se reconnecte automatiquement au serveur. En outre, l'ancienne adresse IP attribuée au client à partir du pool d'adresses IP n'est pas nettoyée.

Problèmes résolus de NSX Manager

Problème résolu 1804116 : Le routeur logique passe à un état incorrect sur un hôte qui a perdu la communication avec l'instance de NSX Manager
Si un routeur logique est mis sous tension ou redéployé sur un hôte qui a perdu la communication avec l'instance de NSX Manager (à cause d'un échec de mise à niveau/installation de NSX VIB ou d'un problème de communication de l'hôte), le routeur logique passe sur un état incorrect et l'opération continue de récupération automatique via la synchronisation forcée échoue.
Problème résolu 1786515 : Un utilisateur disposant de privilèges « Administrateur de sécurité » ne peut pas modifier la configuration d'équilibrage de charge via l'interface utilisateur de vSphere Web Client.
Un utilisateur disposant de privilèges « Administrateur de sécurité » pour un dispositif NSX Edge spécifique n'est pas en mesure de modifier la configuration globale d'équilibrage de charge pour ce dispositif Edge, à l'aide de l'interface utilisateur de vSphere Web Client. Le message d'erreur suivant s'affiche : « L'utilisateur n'est pas autorisé à accéder à l'objet Global et à la fonctionnalité si.service. Vérifiez l'étendue d'accès aux objets et les fonctionnalités autorisées pour l'utilisateur. »
Problème résolu 1801325 : Événements système « Critique » et journalisation générés dans NSX Manager avec une utilisation élevée du CPU et/ou du disque
En cas d'une utilisation élevée de l'espace disque, d'une forte évolution des données de travail ou d'une taille élevée de la file d'attente des travaux sur NSX Manager, vous pouvez rencontrer un ou plusieurs des problèmes suivants :
- Événements système « Critique » dans vSphere Web Client
- Utilisation élevée du disque sur NSX Manager pour la partition /common
- Utilisation élevée du CPU sur des périodes prolongées ou à des intervalles réguliers
- Impact négatif sur les performances de NSX Manager
Solution : contactez le support client VMware. Consultez l'article 2147907 de la base de connaissances de VMware pour plus d'informations.
Problème résolu 1902723 : Le bundle de fichiers NSX Edge n'est pas supprimé du répertoire /common/tmp après chaque publication et remplit le répertoire /common
Le répertoire /common est plein et NSX Manager manque d'espace, car un bundle de fichiers NSX Edge (sslvpn-plus config) n'est pas supprimé de /common/tmp.
Problème résolu 1954628 : Échec de l’opération de restauration lorsque le disque /common est plein
Si une sauvegarde est restaurée sur une instance de NSX Manager dont la taille de disque a/common est pleine, la restauration peut échouer. L’échec est signalé sur la page de résumé du dispositif. NSX Manager atteint un état incohérent qui ne peut pas être récupéré.

Problèmes résolus des services de sécurité

Problème résolu 2029693 : Dans un environnement d'échelle DFW (avec plus de 65 000 règles), la durée de publication des règles DFW peut être plus longue.
Les règles de pare-feu prennent effet 10 à 15 minutes après la publication. Problème résolu dans la version 6.4.0
Problème résolu 1662020 : L'opération de publication peut échouer avec le message d'erreur « La dernière publication a échoué sur l'hôte numéro de l'hôte » sur l'interface utilisateur de DFW dans les sections Général et Services de sécurité partenaires
Après la modification d'une règle, l'interface utilisateur affiche « La dernière publication a échoué sur l'hôte numéro de l'hôte ». Les hôtes répertoriés sur l'interface utilisateur ne disposent peut-être pas de la version correcte des règles de pare-feu, ce qui entraîne un manque de sécurité et/ou une interruption du réseau.

En général, le problème a lieu dans les scénarios suivants :
- Après la mise à niveau d'une version antérieure de NSXv vers la dernière version.
- Sortie d'un hôte du cluster et retour dedans.
- Déplacement d'un hôte d'un cluster à un autre.
Problème résolu 1496273 : L'interface utilisateur permet de créer des règles entrantes/sortantes de pare-feu NSX qui ne peuvent pas s'appliquer aux dispositifs Edge
Le client Web autorise de manière incorrecte la création d'une règle de pare-feu NSX appliquée à un ou plusieurs dispositifs NSX Edge lorsque la règle permet d'acheminer le trafic dans le sens entrant ou sortant et lorsque PacketType est IPV4 ou IPV6. L'interface utilisateur ne devrait pas autoriser la création de ce type de règles, du fait que NSX ne peut pas les appliquer aux dispositifs NSX Edge.
Problème résolu 1854661 : Dans une installation cross-vCenter, les règles de pare-feu filtrées n'affichent pas la valeur d'index lorsque vous basculez entre des instances de NSX Manager
Lorsque vous appliquez un critère de filtre de règle à une instance de NSX Manager, puis que vous passez à une autre instance de NSX Manager, l'index de règle indique « 0 » pour toutes les règles filtrées au lieu d'afficher la position réelle de la règle.
Problème résolu 2000749 : Le pare-feu distribué reste dans l'état Publication avec certaines configurations de pare-feu
Le pare-feu distribué reste dans l'état « Publication » si vous disposez d'un groupe de sécurité contenant un IPSet avec 0.0.0.0/0 comme membre EXCLUSION, comme membre INCLUSION ou comme partie d'une « appartenance dynamique contenant une intersection (ET) ».
Problème résolu 1628679 : Avec le pare-feu basé sur l'identité, la VM d'utilisateurs supprimés fait toujours partie du groupe de sécurité
Lorsqu'un utilisateur est supprimé d'un groupe sur le serveur AD, la VM sur laquelle l'utilisateur est connecté fait toujours partie du groupe de sécurité. Cela conserve les stratégies de pare-feu de la vNIC de VM sur l'hyperviseur, ce qui octroie à l'utilisateur un accès complet aux services.
Problème résolu 1787680 : La suppression de la section de pare-feu universel échoue lorsque NSX Manager est en mode Transit
Lorsque vous essayez de supprimer une section de pare-feu universel de l'interface utilisateur de NSX Manager en mode Transit et de publier, la publication échoue et, par conséquent, vous ne pouvez pas définir NSX Manager en mode Autonome.
Problème résolu 1773240 : Rôle d'administrateur de sécurité non autorisé à modifier et publier des règles d'insertion de services/redirection
Si un utilisateur avec un rôle ou des privilèges d'administrateur de sécurité tente de créer/modifier/publier des règles d'insertion de services, l'opération échoue.
Problème résolu 1845174 : Tous les groupes de sécurité disparaissent de l'interface utilisateur une fois qu'une stratégie de sécurité est attribuée
Tous les groupes de sécurité disparaissent de l'interface utilisateur une fois qu'une stratégie de sécurité est attribuée.
Problème résolu 1839953 : La suppression ARP d'adresses IP de sous-interface de VM invitées échoue
La résolution ARP de ces interfaces est un peu plus longue que la normale (1 seconde) pour la première fois.

Problèmes connus

Les problèmes connus sont classés comme suit.

Problèmes connus généraux
Problèmes connus de mise à niveau et d'installation
Problèmes connus de NSX Manager
Problèmes connus liés à la mise en réseau logique et à NSX Edge
Problèmes connus des services de sécurité
Problèmes connus des services de surveillance

Problèmes connus généraux

Problème 1931236 : Du texte du système s'affiche dans les onglets de l'interface utilisateur
Du texte du système s'affiche dans les onglets de l'interface utilisateur « Tableau de bord.Système.Échelle.Titre » au lieu de « À l'échelle du système ».

Solution : supprimez les cookies du navigateur et actualisez le navigateur, ou déconnectez-vous et reconnectez-vous à vSphere Client.
Dans vSphere Web Client, lorsque vous ouvrez un composant Flex qui chevauche une vue HTML, la vue devient invisible.
Lorsque vous ouvrez un composant Flex, par exemple un menu ou une boîte de dialogue, qui chevauche une vue HTML, la vue est temporairement masquée.
(Référence : http://pubs.vmware.com/Release_Notes/en/developer/webclient/60/vwcsdk_600_releasenotes.html#issues)

Solution : aucune.
Problème 1944031 : Le moniteur DNS utilise le port 53 par défaut pour la vérification de l'intégrité plutôt que d'autres ports
Le port du moniteur dans le membre du pool est utilisé par le moniteur de service pour effectuer des vérifications de l'intégrité auprès du serveur principal. Le moniteur DNS utilise le port 53 par défaut quel que soit le port du moniteur défini. Ne définissez pas le port d'écoute du serveur DNS principal sur une valeur autre que 53, ou le moniteur DNS échouera.
Problème 1874863 : Authentification impossible avec le mot de passe modifié après la désactivation/activation du service sslvpn avec le serveur d’authentification local
Lorsque le service VPN SSL est désactivé et réactivé, et lors de l’utilisation de l’authentification locale, les utilisateurs ne peuvent pas se connecter avec des mots de passe modifiés.

Consultez l’article 2151236 de la base de connaissances de VMware pour plus d’informations.
Problème 1702339 : Les analyseurs de vulnérabilité peuvent signaler la vulnérabilité Quagga bgp_dump_routes CVE-2016-4049
Les analyseurs de vulnérabilité peuvent signaler la vulnérabilité Quagga bgp_dump_routes CVE-2016-4049 dans NSX for vSphere. NSX for vSphere utilise Quagga, mais la fonctionnalité BGP (y compris la vulnérabilité) n'est pas activée. Cette alerte de vulnérabilité peut être ignorée en toute sécurité.

Solution : Comme le produit n'est pas vulnérable, aucune solution n'est nécessaire.
Problème 1926467 : Curseur invisible avec Chrome version 59.0.3071.115 dans le gestionnaire de dispositif NSX Manager
Vous ne pouvez pas voir le curseur pour saisir le nom d'utilisateur/mot de passe lors de l'ouverture du dispositif NSX Manager à l'aide de Chrome version 59.0.3071.115. Vous pouvez toujours saisir vos informations d'identification, même si le curseur n'est pas visible.

Solution : mettez à niveau le navigateur Chrome vers la version 61.0.3163.100, 64.0.3253.0 ou version supérieure.
Problème 2015520 : La configuration de pontage échoue lorsque le nom de pont contient plus de 40 caractères
La configuration de pontage échoue lorsque le nom de pont contient plus de 40 caractères.

Solution : Lorsque vous configurez le pont, son nom ne doit pas dépasser 40 caractères.
Problème 1934704 : Le nom non-ASCII n'est pas pris en charge sur le nom de pont
Si vous configurez des caractères non-ASCII sur le nom de pont dans VDR, la configuration du pont n'est pas visible sur l'hôte et le chemin de données du pont ne fonctionne pas.

Solution : utilisez des caractères ASCII pour le nom de pont.
Problème 1529178 : Le téléchargement d'un certificat de serveur qui n'inclut pas un nom commun renvoie le message « Erreur de serveur interne »
Si vous téléchargez un certificat de serveur sans nom commun, le message « Erreur de serveur interne » s'affiche.
Problème 2013820 : Un membre du pool d'objet de regroupement ne peut pas être partagé entre différents pools qui utilisent différentes stratégies de filtre IP
Un membre du pool d'objet de regroupement ne peut pas être partagé entre différents pools qui utilisent différentes stratégies de filtre IP.

Solution :
1. si le membre du pool d'objet de regroupement doit être partagé entre des pools, assurez-vous que tous les pools utilisent la même stratégie de filtre IP.
2. Utilisez l'adresse IP de l'objet de regroupement directement comme membre du pool s'il doit être partagé entre différents pools avec différentes stratégies de filtre IP.
Problème 2016689 : L'application SMB n'est pas prise en charge pour les utilisateurs RDSH
Si vous créez une règle de pare-feu RDSH qui bloque/autorise l'application SMB, la règle ne se déclenche pas.

Solution : aucune.
Problème 2007991 : Les versions 4.0, 5.0, 5.1, 5.2 et 6.0 serveur ou client des services Bureau à distance (RDP) ne sont pas classées par DFW comme protocole de couche 7
Si l’environnement du client utilise les versions 4.0, 5.0, 5.1, 5.2 ou 6.0 du serveur ou du client RDP, le trafic RDP n’est pas classé ou identifié comme trafic RDP par la règle DFW de couche 7 lorsque vous utilisez le service APP_RDP. Si le trafic RDP est censé être bloqué par la règle DFW, il risque de ne pas l’être.

Solution : Créez la règle de couche 4 en utilisant le service RDP de couche 4 pour que le trafic RDP corresponde.
Problème 1993691 : La suppression d’un hôte sans le supprimer au préalable comme un nœud de réplication peut conduire à des entrées périmées dans NSX Manager
Si vous utilisez un hôte comme nœud de réplication pour un VTEP HW et qu’il doit être supprimé de son cluster parent, assurez-vous tout d’abord qu’il n’est plus un nœud de réplication avant de le supprimer du cluster. Sinon, dans certains cas, son statut de nœud de réplication est conservé dans la base de données NSX Manager, ce qui peut provoquer des erreurs lors de la manipulation ultérieure des nœuds de réplication.

Solution : pour plus d'informations, consultez l’article 52418 de la base de connaissances.
Problème 2164138 : Lors de la préparation d'un cluster pour NSX, le pilote ixgbe est rechargé sur des hôtes avec des cartes réseau physiques exécutant le pilote ixgbe
Le pilote ixgbe est rechargé afin d'activer l'option RSS (mise à l'échelle côté de réception) afin d'améliorer le débit vxlan. La recharge du pilote ixgbe entraîne une panne de quelques secondes des vmnic utilisant le pilote ixgbe et leur sauvegarde. Dans de rares circonstances, la recharge du pilote ixgbe peut échouer et les vmnic utilisant le pilote ixgbe restent en panne jusqu'au redémarrage de l'hôte ESXi.

Solution : Pour plus d'informations, consultez l'article 52980 de la base de connaissances VMware.

Problèmes connus de mise à niveau et d'installation

Avant d'effectuer la mise à niveau, lisez la section antérieure Notes relatives aux mises à niveau.

Problème 2036024 : Mise à niveau de NSX Manager bloquée sur « Vérification du fichier téléchargé » en raison de l'utilisation du disque de base de données
Le fichier journal de mise à niveau vsm-upgrade.log contient également ce message : « L'utilisation du disque de base de données est de 75 %, mais elle devrait être inférieure à 70 %. » Vous pouvez afficher le fichier vsm-upgrade.log dans le bundle de support de NSX Manager. Accédez à Mise en réseau et sécurité > Bundle de support, et choisissez d'inclure les journaux NSX Manager.

Solution : contactez le support client VMware.
Problème 2033438 : vSphere Web Client affiche « Aucun NSX Manager disponible » si la mise à niveau vers NSX 6.4.0 et TLS 1.0 uniquement est activée
Lorsque vous effectuez la mise à niveau vers NSX 6.4.0, les paramètres TLS sont conservés. Si seul TLS 1.0 est activé, vous pourrez afficher le plug-in dans vSphere Web Client NSX, mais les instances de NSX Manager ne sont pas visibles. Cela n'a aucune incidence sur le chemin de données, mais vous ne pouvez modifier la configuration d'aucune instance de NSX Manager.

Solution : connectez-vous à l'interface utilisateur Web de gestion du dispositif NSX à l'adresse https://nsx-mgr-ip/ et activez TLS 1.1 et TLS 1.2. Cela redémarre le dispositif NSX Manager.
Problème 2006028 : La mise à niveau de l'hôte peut échouer si le système vCenter Server redémarre au cours de la mise à niveau
Si le système vCenter Server associé est redémarré au cours de la mise à niveau d'un hôte, cette dernière peut échouer et laisser l'hôte en mode de maintenance. Le fait de cliquer sur Résoudre ne sort pas l'hôte du mode de maintenance. L'état du cluster est « Non prêt ».

Solution : sortez l'hôte du mode de maintenance manuellement. Cliquez sur « Non prêt », puis sur « Tout résoudre » dans le cluster.
Problème 1959940 : Erreur lors du déploiement d'OVF de NSX Manager à l'aide d'ovftool : « Nom OVF non valide (VSMgmt) spécifié dans le mappage net »
À partir de NSX 6.4.0, VSMgmt n'est plus un nom valide pour le mappage net dans le fichier OVF du dispositif et il est remplacé par « Réseau de gestion ».

Solution : utilisez plutôt « Réseau de gestion ». Par exemple, au lieu de --net:VSMgmt='VM Network', utilisez --net:'Management Network=VM Network'.
Problème 2001988 : Lors de la mise à niveau du cluster d'hôtes NSX, le statut de l'installation dans l'onglet Préparation de l'hôte alterne entre « Non prêt » et « Installation en cours » pour l'intégralité du cluster lorsque chaque hôte du cluster est mis à niveau
Lors de la mise à niveau de NSX, le fait de cliquer sur « Mise à niveau disponible » pour le cluster préparé pour NSX déclenche la mise à niveau de l'hôte. Pour les clusters configurés avec DRS FULL AUTOMATIC, le statut de l'installation alterne entre « Installation en cours » et « Non prêt », même si les hôtes sont mis à niveau en arrière-plan sans problème.

Solution : il s'agit d'un problème d'interface utilisateur et peut être ignoré. Attendez la mise à niveau du cluster d'hôtes pour continuer.
Problème 1859572 : Lors de la désinstallation de VIB NSX version 6.3.x sur des hôtes ESXi gérés par vCenter 6.0.0, l’hôte reste en mode de maintenance
Si vous désinstallez des VIB NSX version 6.3.x sur un cluster, le workflow implique de mettre les hôtes en mode de maintenance, de désinstaller les VIB et de retirer les hôtes du mode de maintenance par le service EAM. Toutefois, si ces hôtes sont gérés par vCenter Server 6.0.0, cela bloque l’hôte en mode de maintenance après la désinstallation des VIB. Le service EAM responsable de la désinstallation des VIB met l’hôte en mode de maintenance, mais ne parvient pas à l'en sortir.

Solution : sortez manuellement l’hôte du mode de maintenance. Ce problème ne se produit pas si l’hôte est géré par vCenter Server 6.5a et versions supérieures.
Problème 1797929 : Canal de bus de messages inactif après la mise à niveau du cluster d'hôte
Après la mise à niveau d'un cluster d'hôte, vCenter 6.0 (et versions antérieures) ne génère pas l'événement « reconnect » et, par conséquent, NSX Manager ne configure pas l'infrastructure de messagerie sur l'hôte. Ce problème a été résolu dans vCenter 6.5.

Solution : resynchronisez l'infrastructure de messagerie comme suit :
POST https://<ip>:/api/2.0/nwfabric/configure?action=synchronize
```
<nwFabricFeatureConfig>
        <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
        <resourceConfig>
            <resourceId>host-15</resourceId>
        </resourceConfig>
    </nwFabricFeatureConfig>
```
Problème 1263858 : VPN SSL n'envoie pas de notification de mise à niveau au client distant
La passerelle VPN SSL n'envoie pas de notification de mise à niveau aux utilisateurs. L'administrateur doit informer manuellement les utilisateurs distants que la passerelle VPN SSL (serveur) est mise à jour et qu'ils doivent mettre à jour leurs clients.

Solution : les utilisateurs doivent désinstaller l'ancienne version du client et installer la dernière version manuellement.
Problème 1979457 : Si GI-SVM est supprimé ou retiré lors du processus de mise à niveau en mode de compatibilité descendante, le pare-feu d'identité via Guest Introspection (GI) ne fonctionnera pas, sauf si le cluster de GI est mis à niveau.
Le pare-feu d'identité ne fonctionnera pas et aucun journal lié au pare-feu d'identité ne sera visible. La protection par pare-feu d'identité sera suspendue, sauf si le cluster est mis à niveau.

Solution : mettez le cluster à niveau afin que tous les hôtes exécutent la dernière version de GI-SVM.

- Ou -

Activez l'analyseur de journaux pour que le pare-feu d'identité fonctionne.
Problème 2016824 : Le moteur de contexte NSX ne parvient pas à démarrer après l'installation et/ou la mise à niveau de Guest Introspection
Ce problème se produit lorsque Guest Introspection (GI) est installé ou mis à niveau avant la fin de la préparation de l'hôte. Le pare-feu d'identité pour les VM RDSH ne fonctionne pas si le moteur de contexte n'est pas démarré.

Solution : consultez l'article 51973 de la base de connaissances de VMware pour obtenir plus de détails.
Problème 2027916 : Le Coordinateur de mise à niveau peut indiquer que les contrôleurs qui n'ont pas pu être mis à niveau ont été correctement mis à niveau
Pour un cluster de contrôleurs à trois nœuds, si le troisième contrôleur a échoué au cours de la mise à niveau et est supprimé, la mise à niveau du cluster de contrôleurs dans son intégralité peut être marquée comme ayant réussi même si la mise à niveau a échoué.

Solution : consultez l'onglet Installer et mettre à niveau > Gestion et vérifiez que tous les contrôleurs sont affichés comme « Mis à niveau » avant la mise à niveau des autres composants (hôtes, dispositifs Edge, etc.).

Problèmes connus de NSX Manager

Problème 1991125 : Le regroupement des objets créés lors de la session du gestionnaire de règles d'application sur 6.3.x n'est pas répercuté sur le tableau de bord après la mise à niveau de NSX Manager vers la version 6.4.0
Le regroupement des objets créés lors de la session du gestionnaire de règles d'application sur 6.3.x n'est pas répercuté sur le tableau de bord après la mise à niveau de NSX Manager vers la version 6.4.0.

Solution : le regroupement des objets créés lors de la session du gestionnaire de règles d'application sur 6.3.x est disponible après la mise à niveau de NSX Manager vers la version 6.4.0. Le regroupement des objets est disponible dans la page respective de la section Regroupement des objets.
Problème 1892999 : Impossible de modifier les critères de sélection uniques, même lorsqu’aucune VM n’est attachée à la balise de sécurité universelle
Si une machine virtuelle attachée à une balise de sécurité universelle est supprimée, un objet interne représentant la VM reste encore attaché à la balise de sécurité universelle. Cela entraîne l’échec de la modification des critères de sélection universels avec une erreur indiquant que des balises de sécurité universelle sont encore attachées aux machines virtuelles.

Solution : Supprimez toutes les balises de sécurité universelle, puis modifiez les critères de sélection universels.

Problèmes connus liés à la mise en réseau logique et NSX Edge

Problème 1983902 : Dans un environnement d'installation d'échelle, après le redémarrage de NSX Manager, netcpad ne se connecte pas immédiatement à vsfwd
Ce problème n'a aucune répercussion sur le chemin d'accès des données. Le système récupère sans intervention après 13 minutes.

Solution : Aucune
Problème 1747978 : Les contiguïtés OSPF sont supprimées avec l'authentification MD5 après le basculement HA de NSX Edge
Dans un environnement NSX for vSphere 6.2.4 où NSX Edge est configuré pour HA avec le redémarrage normal OSPF configuré et où MD5 est utilisé pour l'authentification, OSPF ne parvient pas à démarrer normalement. Les formulaires de contiguïté uniquement après le temporisateur mort expirent sur les nœuds voisins OSPF.

Solution : Aucune
Problème 1525003 : La restauration d'une sauvegarde NSX Manager avec une phrase secrète incorrecte échouera en mode silencieux, car des dossiers racine critiques ne sont pas accessibles

Solution : aucune.
Problème 1995142 : L'hôte n'est pas supprimé du cluster de réplication après sa suppression de l'inventaire VC
Si un utilisateur ajoute un hôte à un cluster de réplication, puis qu'il supprime l'hôte de l'inventaire VC avant de le supprimer du cluster, l'hôte hérité restera dans le cluster.

Solution : chaque fois que vous supprimez un hôte, assurez-vous qu'il a déjà été supprimé du cluster de réplication, le cas échéant.
Problème 2005973 : Le MSR démon de routage perd toute la configuration de routage après la suppression de quelques tunnels GRE et l'exécution d'une synchronisation forcée du nœud Edge à partir du plan de gestion
Ce problème peut se produire sur un dispositif Edge avec des sessions BGP sur des tunnels GRE. Lorsque certains des tunnels GRE sont supprimés et qu'une synchronisation forcée du dispositif Edge est effectuée à partir du plan de gestion, le dispositif Edge perd toute la configuration de routage.

Solution : redémarrez le nœud Edge.
Problème 2015368 : La journalisation de pare-feu peut provoquer des problèmes de mémoire insuffisante dans certaines circonstances
Lorsque le pare-feu Edge est activé dans des configurations d'échelle élevée, et que la journalisation de pare-feu est activée sur certaines ou sur toutes les règles, il est possible, mais rare, que le dispositif Edge rencontre une condition de mémoire insuffisante (OOM). Cela est particulièrement vrai lorsqu'une grande quantité de trafic répond aux règles de journalisation. Lorsqu'une condition OOM se produit, la VM Edge redémarre automatiquement.

Solution : la journalisation de pare-feu est utilisée pour le débogage, puis est désactivée de nouveau pour une utilisation normale. Pour éviter ce problème de condition OOM, désactivez la journalisation de tous les pare-feu.
Problème 2005900 : Le démon de routage MSR du dispositif Edge se bloque à 100 % du CPU lorsque tous les tunnels GRE sont instables dans une topologie en échelle ECMP iBGP à 8 voies/BGP à plusieurs tronçons
Ce problème peut se produire dans une topologie en échelle dans laquelle iBGP ou BGP à plusieurs tronçons est configuré sur une passerelle ESG avec plusieurs voisins en cours d’exécution sur un grand nombre de tunnels GRE. Lorsque plusieurs tunnels GRE sont instables, MSR peut être bloqué indéfiniment sur 100 % du CPU.

Solution : redémarrez le nœud Edge.

Problèmes connus des services de sécurité

Problème 1948648 : Pour les utilisateurs connectés à l'aide de règles de pare-feu d'identité RDSH, les modifications de l'appartenance au groupe AD ne prennent pas effet immédiatement.
Des règles de pare-feu d'identité RDSH sont créées. Un utilisateur Active Directory se connecte à son poste de travail RDS et des règles de pare-feu prennent effet. L'administrateur AD apporte ensuite des modifications à l'appartenance au groupe de l'utilisateur AD et une synchronisation delta est effectuée sur NSX Manager. Toutefois, la modification de l'appartenance au groupe AD n'est pas immédiatement visible par l'utilisateur connecté et n'entraîne pas une modification des règles de pare-feu effectives de l'utilisateur. Ce comportement est une limite d'Active Directory.

Solution : les utilisateurs doivent fermer leur session puis se reconnecter pour que les modifications de l'appartenance au groupe AD prennent effet.
Problème 2017806 : Le message d'erreur n'est pas clair lors de l'ajout de membres à des groupes de sécurité utilisés dans des sections de pare-feu RDSH sur des stratégies de sécurité
Si un groupe de sécurité est utilisé dans des sections de pare-feu RDSH sur des stratégies de sécurité, vous ne pouvez lui ajouter que des membres du groupe de répertoires. Si vous tentez d'ajouter un membre ne provenant pas d'un groupe de répertoires, le message d'erreur suivant s'affiche :
« Le groupe de sécurité est utilisé par Service Composer et le pare-feu et ne peut pas être modifié. »

Le message d'erreur n'indique pas que le groupe de sécurité ne peut pas être modifié, car le groupe de sécurité est utilisé dans des sections de pare-feu RDSH sur des stratégies de sécurité.

Solution : aucune.
Problème 2026069 : L'utilisation du chiffrement Triple DES comme algorithme de chiffrement dans le service VPN IPsec NSX Edge peut entraîner une perte de tunnels IPsec sur des sites IPsec lors de la mise à niveau
VMware ne recommande pas l'utilisation de 3DES comme algorithme de chiffrement dans le service VPN IPsec NSX Edge pour des raisons de sécurité. Toutefois, il est disponible dans les versions NSX jusqu'à la version 6.4 pour des raisons d'interopérabilité. Selon les recommandations de sécurité, la prise en charge de ce chiffrement sera supprimée dans la prochaine version de NSX for vSphere. Par conséquent, vous devez cesser d'utiliser Triple DES comme algorithme de chiffrement et passer à l'un des chiffrements sécurisés disponibles dans le service IPsec. Cette modification concernant l'algorithme de chiffrement est applicable à IKE SA (phase1), ainsi qu'à la négociation IPsec SA (phase2) pour un site IPsec.

Si l'algorithme de chiffrement 3DES est utilisé par le service IPsec NSX Edge lors de la mise à niveau vers la version dans laquelle sa prise en charge est supprimée, il sera remplacé par un autre chiffrement recommandé et, par conséquent, les sites IPsec qui utilisaient 3DES ne démarrent pas, sauf si la configuration sur un homologue distant est modifiée pour correspondre à l'algorithme de chiffrement utilisé dans NSX Edge.

Solution : modifiez l'algorithme de chiffrement dans la configuration de site IPsec pour remplacer Triple DES par l'une des variantes AES prises en charge (AES/AES256/AES-GCM). Par exemple, pour chaque configuration de site IPsec dont l'algorithme de chiffrement est Triple DES, remplacez-le par AES. Mettez à jour en conséquence la configuration IPsec sur le point de terminaison homologue.
Problème 1648578 : NSX force l'ajout de cluster/réseau/stockage lors de la création d'une instance de service basé sur l'hôte NetX
Lorsque vous créez une instance de service à partir de vSphere Web Client pour des services basés sur l'hôte NetX tels que Pare-feu, ID et Adresses IP, vous êtes obligé d'ajouter cluster/réseau/stockage même si ces éléments ne sont pas obligatoires.

Solution : lors de la création d'une instance de service, vous pouvez ajouter des informations pour cluster/réseau/stockage afin de remplir les champs. Cela permet de créer l'instance de service et vous pourrez continuer comme prévu.
Problème 2018077 : Échec de la publication du pare-feu lorsque la règle dispose du service ALG L7 personnalisé sans protocole ni port de destination
Lorsque vous créez un service L7 en sélectionnant l'une des applications ALG L7 suivantes (APP_FTP, APP_TFTP, APP_DCERPC, APP_ORACLE) sans fournir de port de destination ni de protocole, puis que vous l'utilisez dans des règles de pare-feu, la publication de la règle de pare-feu échoue.

Solution : fournissez les valeurs du port de destination et du protocole (TCP/UDP) appropriées lors de la création du service L7 personnalisé pour les services ALG suivants :
- APP_FTP : port 21 protocole : TCP
- APP_TFTP : port 69 protocole : UDP
- APP_DCERPC : port 135 protocole : TCP
- APP_ORACLE : port 1521 protocole : TCP
Problème 1980551 : NSX Manager ne prend pas en charge TLSv1 par défaut
Si vous essayez de vous connecter à NSX Manager à l'aide de TLSv1, cela échoue.

Solution : utilisez des versions supérieures de TLS : TLSv1.1 ou TLSv1.2.

Il n'est pas recommandé d'utiliser TLSv1.0. Il va être supprimé à partir d'une future version, mais il est possible de l'activer pour NSX Manager. Consultez la section « Utilisation des paramètres de sécurité » dans le Guide de NSX for vSphere API pour obtenir des instructions. Notez que la modification des paramètres de sécurité entraîne le redémarrage de NSX Manager.
Problème 2006576 : l'état enregistré (informations de connexion stockées pour le trafic acheminé vers des filtres d'insertion de services) est perdu lorsqu'une machine virtuelle invitée sur laquelle est installé un filtre d'insertion de services est déplacée d'un cluster vers un autre (en supposant que les deux clusters ont le même service déployé)
Les machines virtuelles clientes avec des règles NetX (insertion de services) configurées perdront temporairement ces règles NetX si le cluster de destination d’une migration vmotion n'est pas le même que le cluster d'origine.

Solution : limitez la migration vmotion d’une machine virtuelle invitée avec un filtre d'insertion de services au sein du cluster.

Problèmes connus des services de surveillance

Problème 1466790 : Impossible de choisir les VM sur le réseau ponté à l'aide de l'outil NSX Traceflow
Vous ne pouvez pas sélectionner de VM qui ne sont pas associées à un commutateur logique à l'aide de l'outil NSX Traceflow. Autrement dit, les VM d'un réseau ponté L2 ne peuvent pas être choisies par nom de VM comme adresse source ou adresse de destination pour l'inspection Traceflow.

Solution : pour les VM associées à des réseaux pontés L2, utilisez l'adresse IP ou l'adresse MAC de l'interface que vous souhaitez spécifier comme destination d'inspection Traceflow. Vous ne pouvez pas choisir des VM associées à des réseaux pontés L2 comme source. Pour plus d'informations, consultez l'article 2129191 de la base de connaissances.