| VMware NSX for vSphere 6.4.1 | Publié le 24 mai 2018 | Build 8599035 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.1
- 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.1
NSX for vSphere 6.4.1 ajoute des améliorations de facilité d'utilisation et 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.1 :
Services de sécurité
- Pare-feu sensible au contexte :
- Prise en charge supplémentaire du contexte d'application de couche 7 : SYMUPD (trafic Symantec LiveUpdate, qui inclut des définitions de logiciels espions, des règles de pare-feu, des fichiers de signature antivirus et des mises à jour logicielles), MAXDB (connexions SQL et requêtes faites à un serveur SQL Server MaxDB) et GITHUB (référentiel Git Web ou de contrôle de version et service d'hébergement Internet).
- Prise en charge de système d'exploitation étendue du pare-feu d'identité : La prise en charge du pare-feu d'identité pour les sessions d'utilisateur sur les serveurs d'application et de poste de travail distant (RDSH) est désormais étendue pour inclure Windows Server 2012 avec VMware Tools 10.2.5 et Windows 2012 R2 avec VMware Tools 10.2.5.
Interface utilisateur de NSX
- 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 : Installation, Groupes et balises, Pare-feu, Service Composer, Gestionnaire de règles d'application, SpoofGuard, IPFIX, Flow Monitoring. Pour voir la liste des fonctionnalités prises en charge, consultez Fonctionnalités du plug-in VMware NSX for vSphere dans vSphere Client.
- Pare-feu : améliorations de l'interface utilisateur :
- Amélioration de la visibilité : récapitulatif de l'état, barre d'outils d'action, affichage des détails de l'appartenance au groupe du tableau de pare-feu
- Création efficace des règles : modification en ligne, règles de clone, sélection multiple et prise en charge des actions en bloc, configuration simplifiée des règles
- Gestion efficace des sections : glisser-déposer, insertion positionnelle des sections et des règles, ancres de section lors du défilement
- Opérations d'annulation : restaurer des modifications de règles non publiées et de sections sur le côté client de l'interface utilisateur
- Paramètres de délai d'expiration du pare-feu : Les valeurs de protocole sont visibles d'un coup d'œil, ce qui évite d'avoir à afficher des boîtes de dialogue contextuelles.
- Gestionnaire de règles d'application : améliorations de l'interface utilisateur :
- Gestion de session : affichez une liste des sessions, leur état correspondant (collecte de données, analyse terminée) et leur durée.
- Planification de règle : affichez un récapitulatif des objets de regroupement et des règles de pare-feu ; affichez des recommandations concernant les règles de pare-feu universelles.
- Améliorations des objets de regroupement :
- Meilleure visibilité de l'emplacement d'utilisation des objets de regroupement
- Affichez la liste des membres de groupe effectifs en termes de machines virtuelles, d'adresse IP, d'adresse MAC et de vNIC
- SpoofGuard : améliorations de l'interface utilisateur :
- Prise en charge des actions en bloc : Approuvez ou effacez plusieurs adresses IP à la fois
Améliorations de NSX Edge
- Mise à l'échelle de l'équilibrage de charge : Amélioration de la prise en charge des membres de pool d'équilibrage de charge qui passe de 32 à 256
Opérations et dépannage
- Installation : améliorations de l'interface utilisateur :
- Filtrer la liste des clusters par état : Tous, Installé : Sain, Installé : Nécessite une attention, Non installé
- Affichage du résumé du cluster : affiche l'état de santé du canal de communication
- Alarmes sur l'expiration du certificat : Des événements système et des alertes SNMP sont générés avant et après l'expiration du certificat. L'intervalle de temps est configurable, avec une valeur par défaut de 7 jours avant l'expiration.
- Sauvegarde automatique avant les mises à niveau : 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 et Gestion des sauvegardes de NSX Manager créées lors de la mise à niveau.
Interopérabilité des solutions
- Prise en charge de vSphere 6.7 : lors de la mise à niveau vers vSphere 6.7, vous devez d'abord installer ou effectuer la mise à niveau vers NSX for vSphere 6.4.1 ou version ultérieure. Consultez Mise à niveau de vSphere dans un environnement NSX dans le Guide de mise à niveau de NSX et l'article 53710 de la base de connaissances (Séquence de mise à jour pour vSphere 6.7 et ses produits VMware compatibles).
Éditions des licences NSX
- Licences VMware NSX Data Center : Ajoute la prise en charge des nouvelles licences VMware NSX Data Center (Standard, Professional, Advanced, Enterprise Plus, Remote Office Branch Office) introduites en juin 2018 et continue la prise en charge des clés de licence précédentes de VMware NSX for vSphere. Pour plus d’informations sur les licences NSX, reportez-vous à l'article 2 145 269 de la base de connaissances de VMware.
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 |
Remarque : vSphere 5.5 n'est pas pris en charge avec NSX 6.4. |
| 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 :
|
| Guest Introspection pour Linux | Cette version de NSX prend en charge les versions suivantes de Linux :
|
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.
-
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.
Modifications et suppressions dans l'interface utilisateur
Dans NSX 6.4.1, Canevas Service Composer est supprimé.
Suppressions d'API et modifications de comportement
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/statusest obsolète. GET /api/2.0/services/policy/serviceprovider/firewall/est obsolète. UtilisezGET /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/controllerré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 est202 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.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 :
- Recherchez la nouvelle URL du VIB sur https://<nsxmanager>/bin/vdn/nwfabric.properties.
- Récupérez les VIB pour la version de l'hôte ESX requise à partir de l'URL correspondante.
- 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 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 routeur logique distribué
- La validation est ajoutée dans NSX 6.4.1 pour garantir que, dans les environnements où VXLAN est configuré et plusieurs commutateurs vSphere Distributed Switch sont présents, 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. L'interface utilisateur n'affiche plus le commutateur vSphere Distributed Switch non pris en charge.
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 formeRé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
24 mai 2018 : Première édition.
29 mai 2018 : Deuxième édition. Ajout du problème connu 2127813.
8 juin 2018 : Troisième édition : Informations sur les licences NSX Data Center ajoutées, problème connu 2 130 563 ajouté.
20 juillet 2018 : Quatrième édition. Ajout du problème connu 2147002.
5 septembre 2018 : Cinquième édition. Ajout des problèmes connus 2186968 et 2183584.
19 septembre 2018 : Sixième édition. Problème connu 2197754 ajouté ainsi que la remarque connexe dans la table de la configuration système requise.
5 octobre 2018 : Septiè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 de mise à niveau et d'installation
- Problème résolu 1993691, 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.
- Problème résolu 1809387 : Suppression de la prise en charge du protocole de transport sécurisé faible TLS v1.0
À partir de NSX 6.4.1, TLS v1.0 n'est plus pris en charge.
- Problème résolu 2002679 : Dans un environnement cross-vCenter NSX avec VTEP HW déployé sur le site principal, le trafic ponté peut subir une panne réseau lorsque l'instance secondaire de NSX Manager redémarre.
Dans un environnement cross-vCenter NSX avec VTEP HW déployé sur le site principal, le trafic ponté peut subir une panne réseau lorsque l'instance secondaire de NSX Manager redémarre.
- Problème résolu 2065225 : L'installation de NSX Guest Introspection échoue dans un environnement NSX 6.4.0 avec l'erreur : « un paramètre spécifié n'est pas correct Property.info.key[9] »
Les déploiements GI indiquent un état d'installation en échec et un état de service inconnu pour plusieurs hôtes.
- Problème résolu 2094364 : Le processus USVM ne pouvait pas redémarrer après une panne de processus, car le processus de surveillance ne pouvait pas redémarrer le processus USVM.
La USVM est placée dans un état d'avertissement lorsque le processus se termine.
- Problème résolu 2105632 : Les USVM tentent de synchroniser l'heure avec des serveurs NTP Google (externes).
Le service de synchronisation de l'heure a été modifié pour éviter ce comportement.
- Problème résolu 2031099 : La préparation de l'hôte NSX échoue avec l'erreur EAM : « L'hôte n'est plus dans l'inventaire vCenter »
Consultez l'article 52550 de la base de connaissances de VMware pour plus d'informations.
- Problème résolu 2064298 : Impossible de télécharger les journaux de support technique si le mois contient une lettre accentuée
Si NSX Manager utilise le français, les journaux de support technique ne peuvent pas être téléchargés au cours d'un mois dont le nom court contient une lettre accentuée.
- Problème résolu 2017141 : Le certificat de portée globale (globalroot-0) n'est pas accessible aux utilisateurs de portée Edge
Le message d'erreur suivant s'affiche lorsqu'un utilisateur de portée Edge tente d'accéder à la fonctionnalité d'équilibrage de charge Edge :
« L'utilisateur n'est pas autorisé à accéder à des objets globaux et à la fonctionnalité truststore.trustentity_management. Vérifiez les autorisations pour la portée de l'accès
aux objets et pour les fonctionnalités pour l'utilisateur. »
- Problème résolu 1907141 : Accepter GARP comme réponse valide lors de l'envoi d'une demande ARP
Certains anciens périphériques envoient GARP comme réponse à une demande ARP. Le correctif résout l'acceptation de GARP comme réponse ARP valide.
- Problème résolu 2039443 : Lorsqu'un DLR est créé sans interface, l'instance de DLR n'est pas créée sur l'hôte, mais la VM de contrôle tente toujours de se connecter avec l'hôte.
Si un DLR est créé sans LIF, l'instance de VDR n'est pas créée sur l'hôte. Dans une telle configuration, la VM de contrôle DLR tente d'établir une connexion VMCI, qui échouera. Ce problème n'a aucun impact sur le chemin de données et il peut être ignoré.
- Problème résolu 2070281 : Fuite de mémoire lente lorsque la fonctionnalité DNS est activée et que la résolution de noms échoue avec des erreurs de réseau inaccessible
Journaux Edge remplis d'erreurs de résolution de noms. Après un certain temps, les événements système indiquent que l'utilisation de la mémoire des VM Edge est élevée (utilisation supérieure à 90 %).
- Problème résolu 2084281 : Un tunnel VPN n'apparaît pas lorsque le trafic est initié derrière la passerelle ESG après l'expiration du délai d'inactivité de VPN
Le tunnel VPN reste inactif en raison d'une logique défectueuse qui supprimait des entrées spd IPSEC.
- Problème résolu 2092730 : NSX Edge cesse de répondre avec la partition /var/log lorsque l'utilisation du disque est de 100 %.
La partition /var/log de la passerelle NSX Edge se remplit sur le dispositif Edge actif.
- Problème résolu 1984392 : Les objets universels (zone de transport, UDLR, ULS et segments) ne parviennent pas à se synchroniser avec l'instance secondaire de NSX Manager.
Les threads de réplicateur qui répliquent les données sur l'instance secondaire de NSX Manager étaient bloqués et ne pouvaient pas traiter les nouvelles demandes.
- Problème résolu 2064258 : Échec de la vérification du nom NetBios
Dans la version 6.4.0, un nouveau paramètre a été introduit dans la fonctionnalité de synchronisation de domaine. Ce paramètre est le nom NetBios, qui est vérifié par le serveur principal NSX. Dans certaines structures AD, telles que la configuration d'approbation spéciale entre domaines non racines qui est connue sous le nom Raccourci d'approbation, et lorsque l'approbation entre le domaine racine et des domaines non racines est Racine d'arborescence, la vérification du nom NetBios échoue.
- Problème résolu 1971683 : NSX Manager journalise un faux message d'adresse IP en double.
Amélioration de la journalisation des faux positifs.
- Problème résolu 2085654 : S'il existe des critères dynamiques en double dans le même ensemble (en particulier avec la valeur = null), la mise à niveau des critères dynamiques échoue.
NSX Manager ne parvient pas à démarrer après la mise à niveau. NSX ne peut pas être géré après la mise à niveau.
- Problème résolu 1991702 : Message d'erreur « Impossible de démarrer la collecte des données sur une passerelle de sécurité sans VM » vu dans certaines conditions
L'erreur suivante s'affiche au démarrage d'une session de surveillance de point de terminaison sur une passerelle de sécurité basée sur l'identité qui mappe à un groupe AD : « Impossible de démarrer la collecte des données sur une passerelle de sécurité sans VM »
- Problème résolu 2052634 : La traduction de groupes de sécurité imbriqués avec des membres exclus renvoie un résultat incorrect.
La règle de pare-feu bloque ou autorise de manière incorrecte le trafic si des groupes de sécurité avec imbrication et des membres exclus sont utilisés.
- Problème résolu 2089957 : La traduction de VM génère une exception de pointeur nulle pour un groupe de sécurité qui fait référence à un groupe AD supprimé.
Si un groupe AD est supprimé et qu'un groupe de sécurité fait référence à un groupe AD supprimé, la traduction Groupe de sécurité -> VM génère une exception de pointeur nulle. La publication de la règle échoue.
- Problème résolu 2035026 : Coupure du réseau d'environ 40 à 50 secondes vue lors de la mise à niveau du dispositif Edge
Lors de la mise à niveau du dispositif Edge, la panne réseau est réduite à 10-20 secondes.
- Problème résolu 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é.
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ème 2197754 : les hôtes affichent un écran de diagnostic violet lorsque vSphere Distributed Switch est mis à niveau vers la version 6.6
Si NSX 6.4 est installé et que vous mettez à niveau des instances de vSphere Distributed Switch vers la version 6.6, ESXi affiche un écran de diagnostic violet. Les nouvelles installations de vSphere 6.7 avec vSphere Distributed Switch 6.6 ne sont pas affectées.
Solution : utilisez vSphere Distributed Switch version 6.5 ou antérieure lorsque vous effectuez la mise à niveau vers vSphere 6.7.
- Problème 2 130 563 : Un message d’avertissement s’affiche lors de l’attribution de la licence NSX Data Center : « La licence sélectionnée ne prend pas en charge certaines fonctionnalités dont disposent actuellement les ressources sous licence »
Si vous avez reçu une licence NSX for vSphere, puis une licence NSX Data Center, le message d'avertissement suivant s'affiche : « La licence sélectionnée ne prend pas en charge certaines fonctionnalités dont disposent actuellement les ressources sous licence ». Ceci s'explique par le fait que les deux licences définissent différemment les fonctionnalités de NSX. Si vous attribuez une édition de licence qui autorise les mêmes fonctionnalités que votre licence actuelle, vous pouvez ignorer sans risque ce message.
Pour plus d’informations sur les licences NSX, reportez-vous à l'article 2 145 269 de la base de connaissances de VMware.
Solution : Vérifiez que la nouvelle licence prend en charge la fonctionnalité requise et ignorez le message d’avertissement.
- Problème 2127813 : Impossible de choisir et d'attribuer clé de licence NSX à NSX Manager lors de l'utilisation de vSphere Client (HTML5)
Si vous ouvrez une session dans vSphere Client (HTML5) et que vous ajoutez une clé de licence NSX, vous ne pouvez pas attribuer la clé à partir de Licences > Actifs > Solutions. La nouvelle clé de licence n'est pas visible.
Solution : utilisez vSphere Web Client pour ajouter et attribuer des licences.
- 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 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 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 2147002 : impact sur les services et performances avec Guest Introspection installé sur NSX for vSphere 6.4.1
Le problème est visible lorsque l'installation est trop longue entre les machines virtuelles vMotion ou Storage vMotion entre les hôtes avec Guest Introspection activé.
Des journaux d'événements « Mux est déconnecté » fréquents sont observés dans le fichier vmware.log de la machine virtuelle avec le message d'erreur « PANIC: NamespaceDb.cpp:AccessNamespaceDb():83 Function call to read_key failed » s'affichant dans le syslog de l'hôte.Solution : consultez l'article 56734 de la base de connaissances de VMware pour plus d'informations.
- 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.
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 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 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 2106417 : SVM GI passe dans l'état d'échec après la mise à niveau de NSX Manager de la version 6.3.0 vers la version 6.4.1.
Si vous utilisez vCenter Server 6.5 U1 et que vous mettez NSX Manager à niveau de la version 6.3.0 vers la version 6.4.1, la mise à niveau de SVM GI peut échouer.
Solution : lorsque ce problème se produit, supprimez et redéployez les SVM GI.
- Problème 2088315 : L'opération de sauvegarde de NSX Manager échoue
Le certificat rabbitmq présent dans le fichier de sauvegarde S01_NSX_00_00_00_Fri23Mar2018 est expiré. Utilisez les étapes suivantes pour vérifier le certificat de sauvegarde.
openssl enc -md sha512 -d -aes-256-cbc -salt -in S01_NSX_00_00_00_Fri23Mar2018 -out backup.tar -pass 'pass:)' tar -xvf backup.tar openssl x509 -enddate -noout -in home/secureall/secureall/.store/.rabbitmq_cert.pemLe résultat est une date expirée :
notAfter=Dec 26 20:20:40 1978 GMTContactez le support. La prise en charge doit créer un nouveau certificat.
- 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 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ème 2186968 : IPset statique non signalé à l'appel d'API containerset
Si vous disposez de dispositifs de service, NSX peut omettre les ensembles d'adresses IP dans les communications avec les gestionnaires de services de partenaires. Cela peut amener les pare-feu de partenaire à autoriser ou à refuser les connexions de manière incorrecte.
Solution : contactez le support client VMware pour obtenir une solution. Pour plus d'informations, consultez l'article 57834 de la base de connaissances VMware.
- Problème 2183584 : les groupes de sécurité créés dans une session du gestionnaire de règles d'application ne figurent pas dans le menu déroulant de la colonne Appliqué à de la règle recommandée
Les groupes de sécurité créés dans une session du gestionnaire de règles d'application ne figurent pas dans le menu déroulant de la colonne Appliqué à de la règle recommandée.
Solution : reportez-vous à l'article 57837 de la base de connaissances de VMware pour obtenir une solution.
- 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 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 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.
