VMware NSX Data Center for vSphere 6.4.6 | Publié le 10 octobre 2019 | Build 14819921

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
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 Data Center for vSphere 6.4.6

Important : NSX for vSphere est à présent appelé NSX Data Center for vSphere.

NSX Data Center for vSphere 6.4.6 apporte des améliorations à l'utilisation et à la gestion, et corrige un certain nombre de bogues spécifiques des clients. Pour plus d'informations, consultez Problèmes résolus.

Modifications introduites dans NSX Data Center for vSphere 6.4.6 :

VMware NSX : mises à jour des fonctionnalités de vSphere Client (HTML) : Les fonctionnalités suivantes de VMware NSX sont désormais disponibles via vSphere Client : Services Edge (pare-feu Edge, VPN L2, VPN IPSec, configurations NSX). Pour voir la liste des fonctionnalités prises en charge, consultez Fonctionnalités du plug-in VMware NSX for vSphere dans vSphere Client.
Le rôle auditeur de NSX Manager dispose désormais des privilèges pour collecter des bundles de journaux de support NSX Edge à l'aide de Skyline Log Assist. Grâce à cette amélioration des autorisations, un utilisateur avec un rôle d'auditeur peut télécharger le bundle de journaux de support à partir de NSX Manager et des nœuds Edge sans restriction. Reportez-vous au Guide d'administration de NSX pour obtenir la liste complète des rôles et des autorisations.

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 Data Center 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 Data Center for vSphere 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 : Recommandé : 6.0 Update 3 vSphere 6.0 Update 3 résout le problème des VTEP en double dans les hôtes ESXi après le redémarrage du serveur vCenter Server. Consultez l'article 2144605 de la base de connaissances de VMware pour plus d'informations. Pour vSphere 6.5 : Recommandé : 6.5 Update 3 Remarque : 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. Important : Si vous utilisez le routage de multidiffusion sur vSphere 6.5, il est recommandé d'utiliser vSphere 6.5 Update 2 ou une version ultérieure. Si vous utilisez NSX Guest Introspection sur vSphere 6.5, il est recommandé d'utiliser vSphere 6.5 P03 ou une version ultérieure. Pour vSphere 6.7 : Recommandé : 6.7 Update 2 Important : Si vous utilisez NSX Guest Introspection sur vSphere 6.7, reportez-vous à l'article 57248 de la base de connaissances avant l'installation de NSX 6.4.6 et, pour plus d'informations, consultez le support client VMware. Remarque : vSphere 5.5 n'est pas pris en charge avec NSX 6.4.
Guest Introspection pour Windows	Il est recommandé de mettre à niveau VMware Tools vers la version 10.3.10 avant de procéder à la mise à niveau de NSX for vSphere.
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.
NSX for vSphere 6.2.x a atteint sa date de fin de support général le 20 août 2018.
Conformément aux recommandations de sécurité, l'algorithme de chiffrement 3DES dans le service VPN IPsec de NSX Edge n'est plus pris en charge.
Il vous est recommandé de 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 l'homologue distant est modifiée pour correspondre à l'algorithme de chiffrement utilisé dans NSX Edge.

Si vous utilisez le chiffrement 3DES, modifiez l'algorithme de chiffrement dans la configuration de site IPsec pour remplacer 3DES 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 3DES, remplacez-le par AES. Mettez à jour en conséquence la configuration IPsec sur le point de terminaison homologue.

Changements généraux du comportement

Si vous disposez de plusieurs commutateurs vSphere Distributed Switch et que VXLAN est configuré sur l'un d'entre eux, vous devez connecter n'importe laquelle des interfaces de routeur logique distribué à des groupes de ports sur ce commutateur vSphere Distributed Switch. À partir de NSX 6.4.1, cette configuration s'applique dans l'interface utilisateur et l'API. Dans les versions antérieures, rien ne vous empêchait de créer une configuration non valide. Si vous procédez à la mise à niveau vers NSX 6.4.1 ou version ultérieure et que vous avez connecté les interfaces DLR de manière incorrecte, vous devez résoudre ce problème. Pour plus de détails, consultez les Notes relatives aux mises à niveau.

Modifications et suppressions dans l'interface utilisateur

Dans NSX 6.4.1, Canevas Service Composer est supprimé.

Modifications du comportement de l'installation

À partir de la version 6.4.2, lorsque vous installez NSX Data Center for vSphere sur des hôtes disposant de cartes réseau physiques avec des pilotes ixgbe, la mise à l'échelle côté réception (RSS, Receive Side Scaling) n'est pas activée par défaut sur les pilotes ixgbe. Vous devez activer manuellement RSS sur les hôtes avant d'installer NSX Data Center. Veillez à activer RSS uniquement sur les hôtes disposant de cartes réseau avec des pilotes ixgbe. Pour accéder aux étapes détaillées sur l'activation de RSS, consultez l'article https://kb.vmware.com/s/article/2034676 de la base de connaissance de VMware. Cet article de la base de connaissances décrit les paramètres recommandés de RSS pour améliorer le débit des paquets VXLAN.

Ce nouveau comportement s'applique uniquement lorsque vous effectuez une nouvelle installation des modules de noyau (fichiers VIB) sur les hôtes ESXi. Aucune modification n'est requise lorsque vous mettez à niveau des hôtes gérés par NSX vers 6.4.2.

Suppressions d'API et modifications de comportement

Abandons dans NSX 6.4.2

L'élément suivant est obsolète et pourra être supprimé dans une version ultérieure :

GET/POST/DELETE /api/2.0/vdn/controller/{controllerId}/syslog. Utilisez GET/PUT /api/2.0/vdn/controller/cluster/syslog à la place.

Modifications de comportement dans NSX 6.4.1

Lorsque vous créez un pool d'adresses IP avec POST /api/2.0/services/ipam/pools/scope/globalroot-0 ou lorsque vous modifiez un pool d'adresses IP existant avec PUT /api/2.0/services/ipam/pools/et que plusieurs plages d'adresses IP sont définies sur le pool, une validation est effectuée pour vérifier que les plages ne se chevauchent pas. Cette validation n'était pas réalisée auparavant.

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 une liste des problèmes connus affectant l’installation et les mises à niveau, consultez la section Problèmes connus d'installation et de mise à niveau.

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 Data Center for vSphere 6.4 : NSX 6.4 n'est pas compatible avec vSphere 5.5.
- Mise à niveau vers NSX Data Center for vSphere 6.4.5 : Si NSX est déployé avec VMware Integrated OpenStack (VIO), mettez à niveau VIO vers la version 4.1.2.2 ou 5.1.0.1, car la version 6.4.5 est incompatible avec les versions précédentes en raison de la mise à jour du module de printemps vers la version 5.0.
- Mise à niveau vers vSphere 6.5 : lors de la mise à niveau vers vSphere 6.5a ou version ultérieure à la version 6.5, 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.
- Mise à niveau vers vSphere 6.7 : lors de la mise à niveau vers vSphere 6.7, vous devez d'abord effectuer la mise à niveau vers NSX 6.4.1 ou version ultérieure. Les versions antérieures de NSX ne sont pas compatibles avec vSphere 6.7. 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

Prise en charge de la version 11 matérielle de la machine virtuelle pour les composants NSX

Pour les nouvelles installations de NSX Data Center for vSphere 6.4.2, les composants de NSX (Manager, Controller, Edge, Guest Introspection) utilisent la version 11 matérielle de la machine virtuelle.
Pour les mises à niveau vers NSX Data Center for vSphere 6.4.2, les composants NSX Edge et Guest Introspection sont automatiquement mis à niveau vers la version 11 matérielle de la machine virtuelle. Les composants NSX Manager et NSX Controller utilisent la version 8 du matériel de la machine virtuelle après une mise à niveau. Les utilisateurs ont la possibilité de mettre à niveau le matériel de la machine virtuelle vers la version 11. Pour plus d'instructions sur la mise à niveau des versions matérielles de la machine virtuelle, consultez l'article (https://kb.vmware.com/s/article/1010675) de la base de connaissances.
Pour les nouvelles installations de NSX 6.3.x, 6.4.0, 6.4.1, les composants de NSX (Manager, Controller, Edge, Guest Introspection) utilisent la version 8 matérielle de la machine virtuelle.

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 mettez NSX 6.3.3 à niveau vers NSX 6.3.4 ou version ultérieure, vous devez d'abord suivre les instructions de solution de l'article 2151719 de la base de connaissances de VMware.
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.
Lorsque vous mettez NSX Manager à niveau vers NSX 6.4.1, une sauvegarde est automatiquement effectuée et enregistrée localement dans le cadre du processus de mise à niveau. Pour plus d'informations, consultez Mettre à niveau NSX Manager.
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. 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.

Mise à niveau du contrôleur

Le cluster NSX Controller doit contenir trois nœuds de contrôleur. 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

Ajout d'une validation dans NSX 6.4.1 permettant d'interdire les configurations de routeur logique distribué non valides : dans les environnements où VXLAN est configuré et qui comportent plusieurs commutateurs vSphere Distributed Switch, les interfaces de routeur logique distribué doivent être connectées au commutateur vSphere Distributed Switch configuré pour VXLAN uniquement. La mise à niveau d'un DLR vers NSX 6.4.1 ou version ultérieure échoue dans les environnements où le DLR possède des interfaces connectées au commutateur vSphere Distributed Switch qui n'est pas configuré pour VXLAN. Utilisez l'API pour connecter les interfaces incorrectement configurées aux groupes de ports sur le commutateur vSphere Distributed Switch configuré pour VXLAN. Une fois la configuration valide, réessayez la mise à niveau. Vous pouvez modifier la configuration de l'interface à l'aide de PUT /api/4.0/edges/{edgeId} ou PUT /api/4.0/edges/{edgeId}/interfaces/{index}. Pour plus d'informations, consultez le Guide de NSX API.

Supprimez la VM de contrôle UDLR de vCenter Server associée à une instance secondaire de NSX Manager avant de mettre à niveau UDLR de la version 6.2.7 vers la version 6.4.5 :
Dans un environnement multivCenter, lorsque vous mettez à niveau des UDLR NSX de la version 6.2.7 vers la version 6.4.5, la mise à niveau du dispositif virtuel UDLR (VM de contrôle UDLR) échoue sur l'instance secondaire de NSX Manager, si HA est activé sur la VM de contrôle UDLR. Pendant la mise à niveau, la VM avec l'index ha n° 0 dans la paire HA est supprimée de la base de données NSX. Toutefois, cette VM continue d'exister sur le serveur vCenter Server. Par conséquent, lorsque la VM de contrôle UDLR est mise à niveau sur l'instance secondaire de NSX Manager, la mise à niveau échoue, car le nom de la VM est en conflit avec une VM existante sur le serveur vCenter Server. Pour résoudre ce problème, supprimez la VM de contrôle du serveur vCenter Server associé à l'UDLR sur l'instance secondaire de NSX Manager, puis mettez à niveau l'UDLR de la version 6.2.7 vers la version 6.4.5.
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"
           }
```
Après la mise à niveau vers NSX 6.4.6, les ponts et interfaces L2 sur un DLR ne peuvent pas se connecter à des commutateurs logiques appartenant à différentes zones de transport : Dans NSX 6.4.5 ou version antérieure, les instances et les interfaces de pont L2 sur un routeur logique distribué (DLR) utilisaient la prise en charge de commutateurs logiques qui appartenaient à des zones de transport différentes. À partir de NSX 6.4.6, cette configuration n'est pas prise en charge. Les instances et les interfaces de pont L2 sur un DLR doivent se connecter à des commutateurs logiques qui se trouvent dans une zone de transport unique. Si des commutateurs logiques de plusieurs zones de transport sont utilisés, la mise à niveau du dispositif Edge est bloquée lors des vérifications de validation préalables à la mise à niveau lorsque vous mettez à niveau NSX vers 6.4.6. Pour résoudre ce problème de mise à niveau Edge, assurez-vous que les instances et les interfaces de pont sur un DLR sont connectées à des commutateurs logiques dans une zone de transport unique.

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

10 octobre 2019 : Première édition.
6 novembre 2019. Deuxième édition. Ajout du problème connu 2442884 et de la note de mise à niveau associée.
3 décembre 2019. Troisième édition. Ajout d'un lien vers la solution du problème connu 2367906.
9 janvier 2020. Quatrième édition. Ajout du problème connu 2449643.
18 mai 2020. Cinquième édition. Ajout des problèmes connus 2444275, 2445183, 2445396, 2448235, 2448449, 2451586, 2452833, 2458746, 2459936, 2493095, 2498988, 2502739, 2509224, 2513773, 2536058, 2551523.
25 mai 2020. Sixième édition. Ajout d'une note de mise à niveau Edge pour le problème résolu 2379274.

Problèmes résolus

Problème résolu 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.
Problème résolu 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.
Problème résolu 2005973 : le MSR du démon de routage perd toute la configuration de routage après la suppression de plusieurs 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.
Problème résolu 2005900 : le MSR du démon de routage 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.
Problème résolu 2118255 : la VM de contrôle du DLR ne participe pas au routage multidiffusion.
La VM de contrôle du DLR ne participe pas au routage de multidiffusion. Toute la CLI liée à la multidiffusion indiquera un affichage de CLI vide dans la machine virtuelle de contrôle.
Problème résolu 2189417 : nombre de journaux d'événements dépassant la limite prise en charge.
Lorsque des événements sont à grande échelle, certains sont perdus, ce qui entraîne une perte de fonctionnalité IDFW (uniquement pour les charges de travail physiques).
Problème résolu 2312793 : la valeur etag dans l'en-tête HTTP est placée entre guillemets.
REST API échouera si la valeur etag est entrée en réponse.
Problème résolu 2279045 : blocage de la configuration de la latence end2end lors de la connexion de la vNIC à un groupe dvportgroup reposant sur un VLAN.
La latence end2end ne prend pas en charge un dvportgroup reposant sur un VLAN. Lorsque la configuration de la latence sur ce groupe de ports est définie, elle indique une exception. Seul le dvportgroup reposant sur un réseau de superposition peut être utilisé.
Problème résolu 2265909 : fin de la prise en charge des barres obliques doubles dans l'URI de REST API.
Les appels de REST API échouent avec l'erreur 500 : Erreur de serveur interne. Les REST API échouent si l'URI contient des barres obliques doubles.
Problème résolu 2319867 : la latence end2end n'est pas automatiquement configurée sur un nouvel hôte après l'ajout d'un nouvel hôte au VDS avec la latence end2end activée.
Lorsque la latence end2end est déjà configurée sur un VDS et qu'un nouvel hôte est ajouté, la latence end2end n'est pas automatiquement configurée sur le nouvel hôte. La latence sur cet hôte ne peut pas être surveillée.
Problème résolu 2442884 : NSX-v 6.4.6 n'est pas compatible avec VMware Integrated OpenStack.
À partir de NSX 6.4.6, vous ne pouvez pas créer une règle de pare-feu avec une adresse IP de destination de 0.0.0.0/0. Cela entraîne une incompatibilité entre NSX 6.4.6 et toutes les versions de vSphere Integrated OpenStack. Reportez-vous à la Matrice d’interopérabilité des produits VMware pour voir les versions compatibles.
Problème résolu 2331068 : NSX Edge devient ingérable en raison d'un trop grand nombre de messages de mise à jour de l'objet de regroupement de pare-feu.
NSX Edge devient ingérable, mais le plan de données fonctionne correctement. Les administrateurs ne peuvent pas modifier la configuration ou interroger l'état du dispositif Edge.
Problème résolu 2320171 : la réservation de ressources du dispositif Edge est rétablie sur « Pas de réservation » lorsqu'un dispositif Edge est déplacé vers un autre cluster ou pool de ressources.
Après avoir déplacé le dispositif Edge vers un autre cluster ou pool de ressources, les administrateurs doivent réinitialiser manuellement la réservation du dispositif Edge en exécutant une demande d'API.
Problème résolu 2349110 : la fonctionnalité Enregistrer le mot de passe ne fonctionne pas dans le client VPN-Plus SSL sur les ordinateurs Mac.
Les utilisateurs du VPN SSL doivent entrer à nouveau le nom d'utilisateur et le mot de passe pour se connecter au serveur VPN SSL à chaque fois, même lorsque l'option « Enregistrer le mot de passe » est sélectionnée.
Problème résolu 2360114 : dans un environnement Cross-vCenter NSX multisite, la page Redistribution d'itinéraire d'un dispositif Edge géré par une instance de NSX Manager secondaire n'est pas disponible.
Ce problème se pose uniquement dans vSphere Client basé sur HTML5. vSphere Web Client ne rencontre pas ce problème.
Problème résolu 2337437 : verrouillage du noyau de CPU pendant une période prolongée.
Le CPU ne reçoit pas de pulsation pendant N secondes et une dégradation des performances se produit.
Problème résolu 2305079 : le pare-feu d'identité NSX fonctionne de façon intermittente. Le moteur de contexte NSX ne s'exécute pas sur un hôte ESXi.
Lors de l'utilisation de NSX Guest Introspection pour détecter des événements réseau, les fonctions du pare-feu d'identité NSX fonctionnent par intermittence. Lorsque le moteur de contexte NSX est exécuté sur un hôte ESXi, le pare-feu d'identité fonctionne comme prévu. Cependant, lorsque le moteur de contexte n'est pas en cours d'exécution, le pare-feu d'identité ne fonctionne pas.
Problème résolu 2375249 : échec de la publication des règles de pare-feu lorsque des espaces supplémentaires existent dans les champs Adresse IP source et Adresse IP de destination.
Le fichier journal vsfwd affiche une configuration de pare-feu non valide par la fonction « string2ip ».
Problème résolu 2305989 : une fuite de mémoire se produit dans le processus dcsms lorsque les commandes de CLI « show ip bgp » et « show ip bgp neighbors » sont exécutées.
Le processus dcsms (Dynamic Clustering Secure Mobile Multicast) atteint une utilisation de la mémoire très élevée et le traitement normal est affecté. Le dispositif Edge passe en situation de mémoire insuffisante, ce qui entraîne son rechargement.
Problème résolu 2379274 : lorsque des interfaces ou des ponts d'un DLR sont connectés à des commutateurs logiques qui se trouvent dans des zones de transport différentes, des instances de VDR sont manquantes sur certains hôtes.
Les VM ne peuvent pas accéder à leur passerelle par défaut et le trafic du chemin de données est hors service.
Problème résolu 2291285 : lorsqu'un pont est configuré sur l'interface d'un DLR dont la multidiffusion est déjà configurée, cette interface n'est pas supprimée des interfaces de multidiffusion configurées.
Dans l'interface utilisateur de vCenter, l'interface du DLR configurée pour le protocole IGMP multidiffusion et le pontage en tant que source est signalée comme étant déconnectée.
Problème résolu 2377057 : la publication des règles de pare-feu distribué provoque une indisponibilité de NSX Manager en raison d'une utilisation élevée du CPU.
Une utilisation élevée du CPU sur NSX Manager entraîne une dégradation des performances.
Problème résolu 2391802 : les machines virtuelles disparaissent de la liste d'exclusion de NSX lorsque de nouvelles machines virtuelles sont ajoutées à la liste.
Si vous ajoutez une nouvelle machine virtuelle avant que la liste des machines virtuelles existantes dans la liste d'exclusion ne soit chargée dans l'interface utilisateur, les machines virtuelles existantes dans la liste d'exclusion sont supprimées.
Problème résolu 2389897 : conflit de configuration de log4j et log4j2 en raison de l'utilisation de log4j par des bibliothèques tierces.
Les journaux générés par NSX sont manquants dans vsm.log. L'absence de journaux NSX augmente les difficultés à résoudre les problèmes de débogage.
Problème résolu 2273837 : les règles de pare-feu qui utilisent des ensembles d'adresses IP, une application ou des groupes d'applications avec une étendue de centre de données ne sont pas visibles lorsque NSX est mis à niveau vers la version 6.4.0 ou une version ultérieure.
Le message d'erreur suivant s'affiche dans les journaux NSX lorsque des règles de pare-feu utilisent un ensemble d'adresses IP, une application ou des groupes d'applications avec une étendue de centre de données dans NSX 6.4.0 et versions ultérieures :
[Firewall] ObjectId de groupement non valide. Cet objet n'existe pas ou n'est pas disponible.
Problème résolu 2319561 : erreurs de synchronisation sur l'instance principale de NSX Manager.
Le message d'erreur suivant s'affiche dans les journaux de l'interface utilisateur et de NSX :
Échec de REST API : Le format de l'UUID d'instance_uuid n'est pas valide.
Problème résolu 2327330 : TLS 1.1 est activé sur le port RabbitMQ 5671.
La prise en charge de TLS 1.1 existe pour des raisons de compatibilité descendante. Les utilisateurs peuvent supprimer TLS 1.1 explicitement s'ils n'en ont pas besoin.
Pour supprimer TLS 1.1, modifiez le fichier rabbitmq.config sur /etc/rabbitmq/ et redémarrez le Broker sur le gestionnaire.
Problème résolu 2341214 : un dispositif Edge est déployé avec la fonctionnalité HA activée et tous les critères d'activation de cette fonctionnalité sont satisfaits. Cependant, la fonctionnalité HA reste désactivée sur le dispositif Edge jusqu'à ce qu'une deuxième modification de configuration soit publiée sur celui-ci.
Lorsqu'un dispositif Edge (ESG/DLR/UDLR) est créé avec la fonctionnalité HA activée et que des dispositifs sont déployés (configuration en bloc avec d'autres fonctionnalités configurées), la configuration est publiée sur les dispositifs Edge sur lesquels la fonctionnalité HA est désactivée. Le plan de gestion indique que la fonctionnalité HA est activée, mais qu'elle est désactivée sur les dispositifs Edge.
Problème résolu 2392371 : le dispositif virtuel Edge ne parvient pas à redémarrer lorsque VMware Tools n'est pas en cours d'exécution sur le dispositif Edge.
Le redémarrage du dispositif Edge peut échouer dans certains scénarios. Par exemple, lorsque la fonctionnalité FIPS est activée ou désactivée, ou lorsqu'une opération Forcer la synchronisation est tentée sur le dispositif Edge signalant un état système incorrect.
Problème résolu 2273242 : lors de la réception d'un paquet SYN sur une session établie, les filtres NETX n'envoient aucun accusé de réception sur cette connexion.
Lorsque NetX est activé, le paquet SYN est transmis à l'instance de service sur une session établie. Les sessions TCP peuvent se bloquer.
Problème résolu 2285624 : échec de proxy_set lors de son exécution depuis Linux.
La prise en charge de proxy n'était pas présente sur le client sslvpn Linux.
Problème résolu 2287017 : ESX peut afficher un PSOD avec des tempêtes ARP vers des destinations inconnues.
En cas de tempêtes ARP vers des destinations inconnues, ESX affiche un PSOD lors de la réplication des ARP de diffusion vers de nombreuses machines virtuelles du réseau.
Problème résolu 2287578 : la collecte des statistiques de règle entraîne le ralentissement du chemin de pare-feu distribué (DFW).
Lors d'une publication de règle ou d'une collecte de statistiques de règle, une machine virtuelle protégée par DFW peut faire l'objet d'une dégradation des performances réseau.
Problème résolu 2315879 : lorsque plusieurs sites IPSec disposent d'un point de terminaison local, un point de terminaison homologue et un sous-réseau homologue identiques, mais de sous-réseaux locaux différents, le dispositif Edge n'achemine pas le trafic.
Les routes sont manquantes ou non installées. Le dispositif Edge n'achemine pas le trafic.
Problème résolu 2329851 : l'authentification RSA SecureID avec RADIUS pour le client VPN-Plus SSL échoue avec la page Erreur de serveur interne.
Après la connexion au portail sslvpn, l'erreur Page introuvable s'affiche. L'authentification RSA auprès du serveur RADIUS échoue.
Problème résolu 2331796 : la valeur du paramètre « temps mort HA » n'est pas définie dans la configuration HA, même lorsque la valeur est spécifiée pendant le déploiement d'un dispositif Edge autonome.
Une fois le dispositif Edge autonome déployé, la configuration HA affiche de manière incorrecte la valeur du paramètre « temps mort HA » dans le champ d'« intervalle de pulsation HA ». Les utilisateurs ne peuvent pas non plus reconfigurer la valeur du paramètre « temps mort HA » à l'aide de la CLI. Au lieu de cela, l'« intervalle de pulsation HA » est défini.
Problème résolu 2332763 : la mise à niveau du dispositif Edge vers NSX 6.4.2 ou une version ultérieure échoue lorsque la propriété de contrôle du système « sysctl.net.ipv4.tcp_tw_recycle » est configurée.
La publication du dispositif Edge échoue avec le message d'erreur suivant :
ERREUR : VseCommandHandler : Échec de la commande. Erreur : [C_UTILS][73001][65280] sysctl net.ipv4.tcp_tw_recycle="0" failed : sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle: Aucun fichier ou répertoire de ce type.
Problème résolu 2342497 : les VTEP ne peuvent pas fonctionner correctement lorsque la stratégie d'association IP Hash est utilisée.
Les VTEP NSX ne peuvent pas communiquer entre eux.
Problème résolu 2350465 : le dispositif Edge subit une perte de paquets et redémarre en raison d'une mémoire insuffisante.
La mémoire est insuffisante dans les situations de trafic élevé et lorsqu'IPSec est activé.
Problème résolu 2351224 : le client VPN-Plus SSL est installé correctement sur une machine Linux, mais il ne fonctionne pas.
Le module net-tools est manquant sur la machine Linux.
Problème résolu 2367084 : sur un pont, les VM de superposition ne sont pas accessibles depuis les machines virtuelles reposant sur un VLAN.
Lorsque la machine virtuelle de contrôle du DLR et les machines virtuelles de superposition résident sur le même hôte ESXi, les machines virtuelles sur les VLAN ne peuvent pas résoudre les demandes ARP des machines virtuelles sur les réseaux de superposition.
Problème résolu : SynFloodProtection entraîne le contournement des règles de pare-feu.
Lorsque SynFloodProtection est activé sur le dispositif NSX Edge, la vérification des règles de pare-feu est contournée si le trafic est destiné à ce dispositif.
Problème résolu 2381632 : impossible d'ajouter des routes statiques dans un DLR qui n'a pas de machine virtuelle de dispositif Edge déployée.
vSphere Web Client affiche une valeur dans « Distance administrative » pour un DLR qui n'a pas de machine virtuelle de dispositif Edge déployée.
Problème résolu 2385541 : NSX Edge s'exécute en condition Split Brain lorsque l'effacement de l'indicateur de veille forcée est envoyé à la machine virtuelle incorrecte.
Lorsque l'opération Forcer la synchronisation est tentée et que des machines virtuelles sont redémarrées, l'effacement de l'indicateur de veille forcée est envoyé à une machine virtuelle incorrecte. La veille forcée est définie pour son homologue.
L'effacement de l'indicateur de veille forcée échoue, ce qui entraîne l'appel de la tâche Forcer la synchronisation. Les machines virtuelles sont redémarrées dans le cadre de l'opération Forcer la synchronisation, car le dispositif Edge signale un état incorrect du système.
Problème résolu 2385739 : blocage dans NSX Manager.
Zookeeper génère des erreurs et NSX Manager ne répond plus. Le réplicateur supprime et recrée les instances de NSX Controller sur l'instance secondaire de NSX Manager. Le blocage se produit à l'étape finale.
Problème résolu 2387720 : les suites de conformité « Suite-B-GMAC-128 » et « Suite-B-GMAC-256 » dans la configuration du VPN IPSec ne fournissent pas le chiffrement des données.
Ces suites utilisent le chiffrement nul qui est très peu sécurisé. À partir de NSX 6.4.6, ces deux suites de conformité sont déconseillées.
Problème résolu 2390308 : lors du déploiement d'un dispositif Edge compatible FIPS, un redémarrage est requis après le premier démarrage. Cependant, cette opération échoue parfois.
Le message d'erreur suivant est enregistré dans les journaux NSX :
Impossible de terminer l'opération car VMware Tools n'est pas lancé sur cette machine virtuelle.
Problème résolu 2406853 : lors de l'ajout d'une interface de jonction sur un dispositif Edge, la taille de MTU par défaut est définie de manière incorrecte sur 1500 dans l'interface utilisateur.
Le trafic du plan de données traversant l'interface Edge est affecté en raison de la réduction de la taille de MTU par défaut.
Des entrées périmées sont présentes dans les tables de routage du DLR dans les situations suivantes : utilisation de dvportgroup dans les interfaces logiques du DLR, suppression du pont de vCenter ou migration ou suppression d'un commutateur virtuel distribué.
La mise à niveau du DLR échoue. Le redéploiement du dispositif Edge échoue lorsqu'une mise à niveau du dispositif Edge est disponible. Les mises à jour de la configuration du dispositif Edge peuvent échouer.
Problème résolu 2412632 : impossible d'enregistrer un profil d'application d'équilibrage de charge de type « HTTPS de bout en bout » sans sélectionner de certificat de service dans les paramètres SSL du serveur.
Ce problème se produit après la mise à niveau d'un dispositif NSX Edge de la version 6.4.4 vers la version 6.4.5. Dans NSX 6.4.5, la sélection d'un certificat de service est obligatoire lors de la spécification des paramètres SSL du serveur.
Problème résolu 2314438 : les problèmes de synchronisation sur l'instance principale de NSX Manager s'affichent avec l'erreur « Échec de REST API : Le format de l'UUID d'instance_uuid n'est pas valide ».
Certaines machines virtuelles d'un environnement multi-VC, bien que marquées avec des balises universelles sur l'instance principale, ne sont pas répliquées sur l'instance secondaire.
Problème résolu VMSA-2019-0010 : vulnérabilités CVE-2019-11477 et CVE-2019-11478 du noyau Linux dans l'accusé de réception sélectif TCP (SACK)
Tous les composants de NSX-V 6.4.6 contiennent le correctif pour les vulnérabilités du noyau Linux CVE-2019-11477 et CVE-2019-11478 dans l'accusé de réception sélectif TCP (SACK). Les clients peuvent effectuer une mise à niveau vers la version 6.4.6 et les versions ultérieures pour la résolution permanente de ces CVE. L'article 71311 de la base de connaissances comporte des informations supplémentaires sur le problème.
Problème résolu 2324338 : lorsque la règle DFW est configurée avec une vNIC effective avec des adresses IPv4 et IPv6, les mises à jour vers l'un des types d'adresses suppriment également l'autre adresse IP, ce qui entraîne un comportement inattendu pour la règle DFW correspondante.
Toute modification d'un type d'adresse IP remplace les deux types d'adresses IP présents. Si une mise à jour est fournie avec seulement une adresse IPv6, l'enregistrement de la base de données est mis à jour et les adresses IPv4 et IPv6 existantes sont remplacées par la nouvelle adresse IPv6 uniquement.

Problèmes connus

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

Problèmes connus de mise à niveau et d'installation
Problèmes connus de NSX Manager
Problèmes connus généraux
Problèmes connus d'interopérabilité entre les solutions

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 1859572 : lors de la désinstallation des 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 1263858 : le VPN SSL n'envoie aucune 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 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 2429861 : la latence end2end ne s'affichera pas sur l'interface utilisateur vRNI après la mise à niveau vers NSX-v 6.4.6.
La latence end2end est interrompue avec vRNI Interop pour vRNI 4.2 et vRNI 5.0.

Solution : mettez à niveau vRNI vers 5.0.0-P2.
Problème 2449643 : vSphere Web Client affiche l'erreur « Aucune instance de NSX Manager disponible » après la mise à niveau de NSX de 6.4.1 vers 6.4.6.
Dans vSphere Web Client, les pages Pare-feu et Commutateur logique affichent le message d'erreur suivant :
« Aucune instance de NSX Manager disponible. Vérifiez que l'utilisateur actuel a un rôle attribué sur NSX Manager. »

Comme les pages Pare-feu et Commutateur logique ne sont pas disponibles dans l'interface utilisateur, il est possible que les utilisateurs ne puissent pas configurer des règles de pare-feu ou créer des commutateurs logiques. NSX API met également beaucoup de temps à répondre.

Dans le fichier /usr/nsx-webserver/logs/localhost_access_log, des entrées similaires aux suivantes s'affichent :
127.0.0.1 - - [27/Oct/2019:08:38:22 +0100] "GET /api/4.0/firewall/globalroot-0/config HTTP/1.1" 200 1514314 91262
127.0.0.1 - - [27/Oct/2019:08:43:21 +0100] "GET /api/4.0/firewall/globalroot-0/config HTTP/1.1" 200 1514314 90832

127.0.0.1 - - [27/Oct/2019:11:07:39 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 264142
127.0.0.1 - - [27/Oct/2019:11:07:40 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 265023
127.0.0.1 - - [27/Oct/2019:11:07:40 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 265265

Solution :

Renommez les fichiers log4j-1.2.14.jar et log4j-1.2.17.jar manuellement, puis redémarrez le service bluelane-manager.

1. Connectez-vous à la CLI de NSX Manager en tant qu'utilisateur racine.

2. Exécutez ces commandes pour renommer les fichiers .jar :

/home/secureall/secureall/sem/WEB-INF/lib]# mv log4j-1.2.17.jar log4j-1.2.17.jar.old
/home/secureall/secureall/sem/WEB-INF/lib]# mv log4j-1.2.14.jar log4j-1.2.14.jar.old

3. Redémarrez le service bluelane-manager en exécutant cette commande :

/etc/init.d/bluelane-manager restart

Problèmes connus de NSX Manager

Problème 2233029 : ESX ne prend pas en charge les routes 10K.
ESX n'a pas besoin de prendre en charge 10 000 itinéraires. Par conception, la limite maximale sur ESX est de 2 000 itinéraires.

Solution : aucune.
Problème 2391153 : NSX Manager ne met pas à jour le groupe vdn_vmknic_portgroup ni la table vdn_cluster lorsque les opérations vCenter sont effectuées sur le dvportgroup de la vmknic.
Lorsque vous exécutez la requête API PUT https://nsx_manager_ip/api/2.0/nwfabric/configure, NSX Manager ne met pas à jour le groupe vdn_vmknic_portgroup ni la table vdn_cluster lorsque les opérations vCenter sont effectuées sur le groupe de ports virtuels distribués de la vmknic. L'interface utilisateur de vCenter continue d'afficher l'ancien ID de VLAN.

Solution : Aucune
Problème 2445396 : les ports de pool d'équilibreur de charge sont effacés lors de la modification du pool d'équilibreur de charge suivie de « Enregistrer ».
Lors de la modification du pool d'équilibreur de charge et de l'enregistrement de la configuration, les numéros de port sur chaque membre sont effacés.

Problèmes connus généraux

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 2367906 : l'utilisation du CPU sur le dispositif NSX Edge atteint 100 % lorsque le moniteur de service HTTP est configuré sur l'équilibreur de charge avec l'extension « no-body ».
Ce problème se produit lorsque vous configurez le moniteur de service HTTP avec l'extension « no-body » lors de l'utilisation du plug-in « nagios » dans l'équilibrage de charge. L'équilibrage de charge perd la connexion à tous les serveurs principaux, et la demande de l'utilisateur est interrompue.

Solution : pour plus de détails, consultez l'article 71168 de la base de connaissances.
Problème 2551523 : la publication d'une nouvelle règle peut échouer si la règle contient une adresse IP à quatre zéros (0.0.0.0/0) après la mise à niveau de NSX-v 6.3.x vers NSX-v 6.4.6.
La publication d'une nouvelle règle peut échouer si la règle contient une adresse IP à quatre zéros (0.0.0.0/0) après la mise à niveau de NSX-v 6.3.x vers NSX-v 6.4.6.

Solution : remplacez 0.0.0.0/0 par « any » dans la source ou la destination.
Problème 2536058 : temps de réponse élevé de l'API depuis NSX Manager pour obtenir des API flowstats.
Lors de l'interrogation de la configuration du pare-feu et des IPSets, le temps de réponse de ces API est élevé.
Problème 2513773 : les règles IDFW ne sont pas appliquées aux VDI après la suppression en milieu de session de leurs groupes de sécurité respectifs.
Les sessions VDI sont abandonnées de manière aléatoire en raison de la suppression des groupes de sécurité attachés aux règles IDFW.

Solution : déclenchez une autre synchronisation manuelle.
Problème 2509224 : un tableau de flux excessivement volumineux sur NSX Edge en HA entraîne des abandons de connexion.
Une synchronisation excessive du tableau de suivi des connexions du dispositif NSX Edge en veille au dispositif NSX Edge actif entraîne l'abandon de nouvelles connexions.

Solution : aucune.
Problème 2502739 : temps de réponse élevé de l'API de NSX Manager pour les API FW et IPSet.
Lors de l'interrogation de la configuration du pare-feu et des IPSets, le temps de réponse de ces API est élevé.

Solution : aucune.
Problème 2498988 : le temps de réponse est élevé lors de l'interrogation d'objets de regroupement.
Lors de l'interrogation d'objets de regroupement, le temps de réponse de ces API est élevé.
Problème 2458746 : les configurations de LIF non prises en charge ont généré des PSOD sur plusieurs hôtes.
Les validations d'hôte ont été mises en œuvre pour éviter d'ajouter des LIF en double sur différents DLR.

Solution : assurez-vous que le câble virtuel n'est pas présent dans 2 DLR différents en supprimant l'un d'entre eux.
Problème 2452833 : un hôte ESXi effectuant la maintenance d'une VM de contrôle du DLR peut rencontrer un PSOD si le même VXLAN est consommé dans le pontage et dans un LIF dans deux DLR différents.
Un ESXi effectuant la maintenance de la VM de contrôle du DLR peut rencontrer un PSOD si le même câble virtuel est consommé dans le pontage et dans un LIF.

Solution : attendez la fin de la tâche en cours et vérifiez qu'il n'y a pas de travaux en attente avant de passer à la configuration d'un autre dispositif Edge.
Problème 2451586 : les règles d'application LB ne fonctionnent pas après la mise à niveau de NSX vers 6.4.6.
Lorsque des serveurs back-end HTTP(s) se trouvent derrière un équilibreur de charge NSX en tant que partie intégrante du dispositif NSX Edge, les clients communiquent avec les serveurs back-end via l'équilibreur de charge. L'équilibreur de charge envoie des en-têtes en minuscules, alors que les serveurs les ont envoyés en casse mixte.
Problème 2448449 : les règles d'application configurées avec req_ssl_sni peuvent échouer avec une erreur d'analyse lors de la mise à niveau vers NSX for vSphere 6.4.6.
Lors de la mise à niveau vers NSX for vSphere 6.4.6, si un équilibreur de charge est configuré avec une règle liée à une SNI ou lorsque vous créez ou configurez une nouvelle règle associée à une SNI dans cette version, vous pouvez rencontrer un problème au cours duquel la mise à niveau ou la création de la règle associée échoue.

Solution : reportez-vous à l'article 75281 de la base de connaissances VMware.
Problème 2444275 : l'hôte rencontrera un PSOD lorsque la fonctionnalité de latence de l'infrastructure virtuelle est activée.
L'hôte ESXi rencontre un PSOD lorsque la fonctionnalité de latence de l'infrastructure virtuelle est activée sur VRNI dans un environnement composé de plus de 975 tunnels BFD par hôte. Dans un environnement d'échelle, l'hôte ESXi rencontre un PSOD si la latence est activée.

Solution : désactivez la fonctionnalité latence/heatmap dans un environnement d'échelle.
Problème 2493095 : prise en charge des listes d'adresses IP séparées par des virgules dans DFW supprimée de l'interface utilisateur et de la base de données.
Lors de la mise à niveau de versions antérieures de NSX-v vers NSX-v 6.4.6, des adresses IP séparées par des virgules dans DFW ont été supprimées.
Problème 2459936 : impossible de diviser le réseau en deux parties à l'aide de routes statiques avec réseau (0.0.0.0/1 et 128.0.0.0/1).
Seule la route statique avec le réseau 0.0.0.0/0 est autorisée.

Solution : aucune.
Problème 2448235 : après la mise à niveau vers NSX-v 6.4.6, il est possible que vous ne puissiez pas filtrer les règles de pare-feu en utilisant le protocole, le port source et le port de destination.
Vous ne pourrez pas filtrer les règles de pare-feu en utilisant le filtre de protocole, de port source et de port de destination.
Problème 2445183 : NSX Manager n'est pas visible dans vSphere Web Client après le remplacement du certificat SSL de NSX Manager.
Après le remplacement du certificat SSL de NSX Manager, NSX Manager n'est pas visible sur vSphere Web Client.

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

Problèmes connus d'interopérabilité entre les solutions