VMware NSX Data Center for vSphere 6.4.4 | Publié le 13 décembre 2018 | Build 11197766 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.4

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

NSX Data Center for vSphere 6.4.4 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, consultez Problèmes résolus.

Modifications introduites dans NSX Data Center for vSphere 6.4.4 :

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 : Commutateurs logiques, Edge Appliance Management, Services Edge (DHCP, NAT), Certificats Edge, Objets de regroupement Edge. Pour voir la liste des fonctionnalités prises en charge, consultez Fonctionnalités du plug-in VMware NSX for vSphere dans vSphere Client.

Mise en réseau et services Edge

• Itinéraires statiques par dispositif Edge Service Gateway : passe de 2 048 à 10 240 itinéraires statiques pour les dispositifs Edge Service Gateway super grands et extra grands.

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 : Prise en charge minimale : 6.0 Update 2 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 : Prise en charge minimale : 6.5a Recommandé : 6.5 Update 2 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. Si vous utilisez le routage de multidiffusion sur vSphere 6.5, il est recommandé d'utiliser vSphere 6.5 Update 2. Si vous utilisez NSX Guest Introspection sur vSphere 6.5, vSphere 6.5 P03 est recommandé. Pour vSphere 6.7 Prise en charge minimale : 6.7 Recommandé : 6.7 Update 1 Important :  Si vous utilisez NSX Guest Introspection sur vSphere 6.7, reportez-vous à l'article 57248 de la base de connaissances avant la mise à niveau vers NSX 6.4.4 et, pour plus d'informations, consultez le support client VMware. Si vous mettez à niveau une installation existante de vSphere vers vSphere 6.7, ne mettez pas à niveau les instances de vSphere Distributed Switch vers la version 6.6. (Pour plus d'informations, consultez le problème connu 2197754.)  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 : Utilisez VMware Tools 10.0.9 et 10.0.12 pour activer le composant Thin Agent Network Introspection facultatif fourni avec VMware Tools. Effectuez la mise à niveau vers VMware Tools 10.0.8 et versions ultérieures pour résoudre la lenteur des VM après la mise à niveau de VMware Tools dans NSX/vCloud Networking and Security (consultez l'article 2144236 de la base de connaissances de VMware). Utilisez VMware Tools 10.1.0 et versions ultérieures pour la prise en charge de Windows 10. Utilisez VMware Tools 10.1.10 et versions ultérieures pour la prise en charge de Windows Server 2016.
Guest Introspection pour Linux	Cette version de NSX prend en charge les versions suivantes de Linux : RHEL 7 GA (64 bits) SLES 12 GA (64 bits) Ubuntu 14.04 LTS (64 bits)

Configuration système et installation

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

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

Fonctionnalités obsolètes et retirées

Avertissements sur la fin de vie et la fin du support

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

• NSX for vSphere 6.1.x est arrivé en fin de disponibilité et a atteint sa date de fin de support général le 15 janvier 2017. (Consultez également l'article 2144769 de la base de connaissances de VMware.)

• Arrêt de la prise en charge des dispositifs vCNS Edge. Vous devez effectuer une mise à niveau vers un dispositif NSX Edge avant de procéder à la mise à niveau vers NSX 6.3 ou version ultérieure.

• 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 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 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.

• 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

  1. Veillez toujours à ce que votre installation suive les meilleures pratiques établies pour vSphere HA. Consultez l'article 1002080 de la base de connaissances.

  2. 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"
             }

 

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

13 décembre 2018 : Première édition.

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 généraux

• Problème résolu 2089858 : Limites de mémoire de SVM GI avec un débit réseau élevé

  Mémoire élevée observée dans SVM GI. Une perte de connectivité vers NSX Manager peut également se produire. Les charges de travail client s'exécutant sur des hôtes affectés peuvent être touchées.

• Problème résolu 2094345 : Écran violet sur l'hôte lorsque la collecte de flux est activée dans NSX.

  L'hôte tombait en panne avec un écran violet, ce qui entraînait une perte de données de machines virtuelles.

• Problème résolu 2177097 : Lorsque vous utilisez l'appel API /api/2.0/vdn/config/segments pour créer un pool avec 1 ID de segment, il échoue avec « L'ID de segment est en dehors de la plage, la plage valide est 5000-16777215 »

  Lorsque vous utilisez l'API /api/2.0/vdn/config/segments, si vous fournissez la même valeur de début et de fin lors de la création d'un segment de valeur unique, il échoue avec une erreur.

• Problème résolu 2178339 : rsyslog 8.15.0-7.ph1 a supprimé la ligne ExecReload dans le fichier de service systemd, ce qui entraîne la mauvaise journalisation de /var/log/syslog et /var/log/messages

  Cela entraîne l'occupation à 100 % de l'espace disque par la partition /var/log donc les nouveaux journaux ne peuvent pas être écrits.

• Problème résolu 2188753 : la synchronisation de l'inventaire entraîne l'exception « duplicate key value violates unique constraint » lorsque plusieurs mappages existent pour la vNIC dans la table domain_object_relationships

  La synchronisation de l'inventaire ne cesse d'échouer, ce qui entraîne la désynchronisation de vCenter et NSX.

• Problème résolu 2194374 : GI USVM SSH ne fonctionne pas

  Certaines clés ssh, telles que RSA, DSA, ECDSA et ED25519 ne sont pas générées automatiquement.

• Problème résolu 2134192 : une erreur se produit lorsque le commutateur ne contient aucun port

  Si un commutateur physique sur une passerelle matérielle ne contient aucun port, NSX génère une erreur lorsqu'il tente de récupérer le port à partir du commutateur. L'erreur, « Impossible d'extraire les informations de l'inventaire » s'affichera en essayant de récupérer le port.

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

   

• Problème résolu 2210313 : dans le workflow « Forcer la synchronisation », l'héritage de stratégie de sécurité n'est pas pris en compte

  Si une stratégie de sécurité est héritée par une autre stratégie enfant, après la synchronisation forcée, les groupes de sécurité appliqués de la stratégie enfant ne sont pas considérés comme des groupes de sécurité de stratégie pour la stratégie parente. Les règles de pare-feu de la stratégie parente ne sont pas correctement appliquées aux PSG de stratégie enfant.

• Problème résolu 2216582 : certaines machines virtuelles perdent leur protection antivirus

  En raison d'une utilisation élevée de la mémoire et de la modification de l'UUID de VM, il n'est pas possible d'appliquer la nouvelle configuration pour la machine virtuelle modifiée. Certaines machines virtuelles perdent leur protection antivirus.

• Problème résolu 2195346 : des instances de VDR sont effacées des hôtes de l'instance secondaire de Manager après une suppression et un ajout d'un cluster de contrôleurs

  Perte de trafic d'environ 40 secondes après la suppression et l'ajout d'un cluster de contrôleurs.

• Problème résolu 2213199 : la page VM sous le commutateur logique ne se charge pas

  L'interface utilisateur semble bloquée. Impossible d'afficher toutes les machines virtuelles d'un commutateur logique.

• Problème résolu 2172254 : lorsque seul le pontage est configuré, Actif-Actif est signalé lors du redéploiement d'un dispositif actif

  La même adresse IP peut être signalée par deux dispositifs (scénario actif-actif). Toutefois, si même une liaison montante unique est configurée, ou si le routage est configuré sur le DLR, ce problème n'apparaît pas. Une perte de trafic et un scénario actif-actif se produiront si aucune liaison montante n'est configurée, si le routage dynamique n'est pas activé sur le DLR et si seul un pont L2 est configuré.

• Problème résolu 2018917 : un nombre élevé de fichiers de sauvegarde NSX entraîne un comportement imprévisible

  Un nombre élevé de fichiers de sauvegarde NSX entraîne un comportement imprévisible, notamment des échecs de déploiement NSX, une interface utilisateur qui ne répond pas.

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

• Problème résolu 2158380 : modifications de suffixe DNS de VPN SSL non restaurées après la déconnexion

  Les modifications de suffixe DNS sur l'adaptateur ne sont pas restaurées après la déconnexion du client sslvpn. La résolution DNS peut ne pas fonctionner comme prévu.

• Problème résolu 2177891 : le tronçon suivant appris d'Edge BGP n'est peut-être pas comme prévu après la récupération de l'échec d'un dispositif Edge

  Le tronçon suivant appris d'Edge BGP n'est peut-être pas comme prévu après la récupération de l'échec d'un dispositif Edge. Une perte de paquets peut se produire en fonction de la topologie du client.

• Problème résolu 2178771 : l'interface na0 SSLVPN perd l'adresse IP de passerelle

  L'interface na0 SSLVPN, qui agit comme passerelle pour les clients connectés, perd son adresse IP, ce qui entraîne une interruption du trafic depuis le client. Le trafic client ne circule pas comme prévu.

• Problème résolu 2192834 : aucune solution fournie lors de la tentative de suppression d'une configuration de dispositif sans utiliser l'indicateur deployAppliance

  Le message d'erreur n'est pas effacé et ne fournit pas de solution.

• Problème résolu 2126743 : l'adresse IP des VM n'est pas publiée dans addrset lorsque des VM sont ajoutées au groupe de sécurité

  Lorsqu'une machine virtuelle est ajoutée au groupe de sécurité, l'adresse IP de la machine virtuelle ne s'affiche pas dans addrset. Le trafic échoue, car la stratégie appropriée n'est pas appliquée à la machine virtuelle, même si elle fait partie d'un groupe de sécurité correctement configuré.

• Problème résolu 2197442 : le mot de passe de voisin BGP du routeur logique distribué universel n'est pas répliqué vers l'instance secondaire de NSX Manager

  Les itinéraires ne sont pas appris à partir du voisin configuré.

• Problème résolu 2209469 : l'opération de création/mise à jour de niveau section n'est pas publiée sur Edge

  La mise à jour de la section réussit pour Edge, mais les règles ne sont pas mises à jour dans le plan de données.

• Problème résolu 2207483 : Latence élevée pour le trafic acheminé horizontal et vertical

  TxWorld de VM générant le trafic acheminé prend 100 % de CPU, ce qui entraîne une latence élevée.

• Problème résolu 2192486 : Le transfert du trafic vertical de multidiffusion s'arrête après la mise à niveau de NSX 6.4.2 vers la version 6.4.3 si le routage de monodiffusion sous-jacent est effectué via des itinéraires statiques et que le mode HA est désactivé

  Si vous exécutez des flux de multidiffusion entre la source et les récepteurs respectivement situés à l'intérieur et à l'extérieur de NSX, que le routage de monodiffusion sous-jacent est effectué via des itinéraires statiques et que vous procédez à la mise à niveau de NSX 6.4.2 vers la version 6.4.3, le transfert du trafic des flux de multidiffusion existants s'arrête. Les flux de multidiffusion créés après la mise à niveau ne sont pas affectés et sont transférés.

• Problème résolu 2185738 : impossible d'utiliser une interface si elle dispose d'une adresse IPv6

  Les interfaces internes qui ont une adresse IPv4 sont répertoriées, mais, si elles disposent également d'une adresse IPv6, une erreur est générée. La configuration du redirecteur DNS ne peut pas être appliquée à une interface contenant une adresse IPv6.

• Problème résolu 2215061 : NSX Edge perd l'état HA après la publication de DCN comme étant le même ApplianceConfig envoyé aux deux machines virtuelles lorsque l'équilibrage de charge est configuré avec des objets de regroupement et que HA est activé

  HA est déconnecté, ce qui entraîne Split Brain.

• Problème résolu 2220327 : impossible de définir la réservation de ressources gérée par le système pour un dispositif Edge

  En choisissant la réservation de ressources personnalisée pour Edge, la réservation de ressources gérée par le système n'est pas affichée sur le menu de l'interface utilisateur.

• Problème résolu 2220549 : la validation de règle de pare-feu consommant des objets de regroupement prend du temps, ce qui entraîne l'expiration de l'interface utilisateur

  Le changement de configuration du pare-feu Edge, où des règles de pare-feu consommant des objets de regroupement ont été configurées, prend 2 minutes de trop, ce qui entraîne l'expiration de l'interface utilisateur.

Problèmes résolus de NSX Manager

• Problème résolu 2220325 : le bundle de support technique contient des fichiers avec des mots de passe en texte brut

  Les mots de passe de postgres et rabbitmq sont disponibles dans les fichiers de configuration en texte brut du bundle de support technique et ils peuvent être récupérés.

• Problème résolu 2208178 : après le redémarrage de NSX Manager, la tâche d'installation des VIB NSX s'affiche comme étant en permanence en cours d'exécution dans l'interface utilisateur dans l'onglet Préparation de l'hôte

  EAM ne démarre pas l'installation des VIB NSX.

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 généraux

• 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.

• 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 2118255 : la VM de contrôle du DLR ne participe au routage de multidiffusion

  La VM de contrôle du DLR ne participe 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 2145540 : pour ESX version 6.7, le nombre total de groupes de multidiffusion de sous-couche joints par un hôte ne peut pas dépasser 128

  Il est recommandé d'utiliser une plage de multidiffusion de réplication de 64 au maximum (CIDR /26 ou supérieur) lors de la configuration du routage de multidiffusion sous un DLR.

• Problème 2189417 : nombre de journaux des é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).

  Solution : réduisez l'échelle de la charge de travail physique.

• Problème 2236618 : l'opération de configuration de carte réseau virtuelle/dispositif sur ESG avec 10 000 itinéraires statiques s'affiche pendant environ 2 minutes dans le temps de réponse

  Avec un nombre croissant d'itinéraires statiques, l'exécution de l'opération de configuration de carte réseau virtuelle/dispositif prend plus de temps. Les opérations de l'interface utilisateur pour la configuration de cartes réseau virtuelles/sous-interfaces/dispositifs peuvent expirer lors du dépassement de la limite de 2 minutes, mais la configuration réussit.

  Solution : actualisez l'interface utilisateur pour refléter l'état de la modification de configuration.

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 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 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 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 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èmes connus de NSX Manager

• Problème 2171182 : impossible de créer ou de gérer plusieurs clusters de réplication dans l'onglet Périphériques matériels de l'interface utilisateur de NSX

  Via l'interface utilisateur de NSX, vous pouvez afficher et gérer un cluster de réplication par défaut unique, mais pas plusieurs clusters de réplication.

  Solution : la prise en charge de plusieurs clusters de réplication n'est actuellement disponible que via l'API. Utilisez NSX API pour gérer plusieurs clusters de réplication.

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

• 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 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 2239686 : la configuration de la multidiffusion sur la passerelle ESG (extra grande ou super grande) avec 10 000 itinéraires statiques prend environ deux minutes

  Avec un nombre croissant d'itinéraires statiques configurés, la configuration de BGP/OSPF/Global dans l'opération de configuration du routage démarrera en prenant plus de temps. Une fois la multidiffusion configurée, la configuration de BGP/OSPF/Global suivante dans la configuration du routage réussit, mais prend plus de temps. Des opérations de l'interface utilisateur pour la configuration de BGP/OSPF/Global dans la configuration du routage peuvent dépasser la limite de 2 minutes, mais la configuration aboutit. Dans ce cas, l'interface utilisateur doit être actualisée pour refléter l'état de la modification de configuration.

  Solution :

  • si la multidiffusion n'est pas configurée, la configuration de BGP, OSPF, des itinéraires statiques et de la configuration globale se termine en 10 à 20 secondes.
  • Si la multidiffusion n'est pas requise, ne configurez pas la multidiffusion.
  • Si la multidiffusion est configurée et non requise, supprimez la configuration de la multidiffusion pour améliorer le temps de réponse.

Problèmes connus des services de sécurité

• 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