Notes de mise à jour de NSX for vSphere 6.1.7

Document mis à jour le 8 juin 2016
NSX for vSphere 6.1.7 | Mis à jour le 9 juin 2016 | Build 3949567

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés

Découvrez les nouveautés et les modifications apportées dans les versions 6.1.7, 6.1.6, 6.1.5, 6.1.4, 6.1.3, 6.1.2, 6.1.1, 6.1.0.

Nouveautés de la version 6.1.7

La version 6.1.7 offre un correctif de sécurité pour résoudre une vulnérabilité de validation d'entrée critique sur des sites qui utilisent NSX SSL-VPN. Reportez-vous à la section Corrigé dans la version 6.1.7 de ce document.

Nouveautés de 6.1.6

La version 6.1.6 fournit un correctif de sécurité pour résoudre la vulnérabilité glibc et inclut plusieurs correctifs de bogues documentés dans la section Problèmes résolus. Cette version inclut les mêmes correctifs de bogues critiques que ceux qui ont été fournis dans tous les correctifs basés sur les versions 6.1.4 et 6.1.5. Pour les utilisateurs de NSX 6.2.x, ce même ensemble de correctifs est disponible dans NSX 6.2.2 et versions ultérieures.

Modifications introduites dans NSX for vSphere 6.1.6 :

  • Correctif de sécurité CVE-2015-7547 (glibc) : Ce correctif résout CVE-2015-7547, également connu sous le nom de vulnérabilité glibc.

Nouveautés de 6.1.5

Modifications introduites dans NSX for vSphere 6.1.5 :

  • État de la connectivité du contrôleur : L'interface utilisateur de NSX Manager a été améliorée et affiche désormais l'état de la connectivité entre les contrôleurs NSX dans le cluster de contrôleurs. Cela permet d'afficher les différences de connectivité entre les nœuds. Par exemple, dans un cluster composé des contrôleurs A, B et C, l'état du contrôle permet de détecter une partition partielle du cluster, si A est connecté à B et C, mais que B et C ne peuvent pas communiquer.

Nouveautés de 6.1.4

Modifications introduites dans NSX for vSphere 6.1.4 :

  • Correctifs de sécurité : Cette version vient compléter une série de correctifs visant à éliminer les vulnérabilités Skip-TLS (CVE-2014-6593), FREAK (CVE-2015-0204) et POODLE (CVE-2014-3566), ainsi que des correctifs corrigeant d'autres problèmes. Reportez-vous à la section Problèmes résolus de ce document. Vérifiez que tous les composants tiers (par exemple, les solutions de partenaires tiers) prennent en charge les versions mises à jour de JRE et d'OpenSSL utilisées dans NSX.
    Pour obtenir plus de détails, reportez-vous à :

  • Compatibilité avec vSphere 6.0 : NSX 6.1.x est compatible avec vSphere 6.0. Néanmoins, certaines nouvelles fonctionnalités de vSphere ajoutées à vSphere 6.0 n'ont pas été testées avec NSX 6.1.x. Pour obtenir une liste des limitations spécifiques à NSX 6.1.x concernant vSphere 6.0, consultez l'article 2110197 de la base de connaissances VMware.

  • Capacité à forcer la publication de configuration sur des nouveaux NSX Controllers déployés : NSX for vSphere 6.1.4 introduit la commande Force Sync Controller (Forcer le contrôleur de synchronisation) pour envoyer des informations de commutateur logique à des nouveaux NSX Controllers déployés. L'appel API suivant à NSX Manager renvoie la configuration d'origine à chacun des nouveaux contrôleurs déployés.
    Méthode :

    PUT https://<NSX-Manager-IP>/api/2.0/vdn/controller/synchronize?
  • OSPF sur des sous-interfaces : OSPF est désormais pris en charge sur des sous-interfaces (problème résolu 1436023).

  • Fin de la prise en charge de MSRPC dans les règles ALG : NSX Edge ne prend plus en charge le protocole MSRPC pour les règles ALG (Application Level Gateway) sur Edge Firewall.

Nouveautés de 6.1.3

Modifications introduites dans NSX for vSphere 6.1.3 :

  • Les protocoles de routage dynamique sont pris en charge sur les sous-interfaces.
  • ECMP et Logical Firewall sont pris en charge en même temps avec le routage logique.

Nouveautés de 6.1.2

NSX for vSphere 6.1.2 a mis à jour NSX Edge et les NSX Controllers vers OpenSSL 101j et résout plusieurs autres CVE. Cette version incluait un appel API mis à jour pour résoudre la vulnérabilité POODLE. À l'aide de cet appel API, vous pouvez désactiver SSLv3 sur des dispositifs NSX Edge spécifiques au sein de votre environnement. Pour plus d'informations, reportez-vous à la section Problèmes résolus.

Nouveautés de 6.1.1

NSX for vSphere 6.1.1 fournissait des correctifs pour tous les dispositifs NSX afin de résoudre la vulnérabilité de sécurité BASH Shellshock.

Nouveautés de 6.1.0

NSX for vSphere 6.1 incluait plusieurs nouvelles améliorations de fonctionnalité, d'opérations, de consommation et de renforcement :

  • Clusters NSX Edge hautement disponibles avec des vitesses de liaison montante plus rapides : NSX vous permet de créer des clusters NSX Edge hautement disponibles et distribués, fournit une connexion de liaison montante avec une bande passante élevée vers des réseaux physiques, et assure également une redondance active-active sur NVE (Network Virtualization Edge). ECMP sur NSX Edge permet une bande passante Nord-Sud agrégée haut débit et une montée en puissance parallèle de NSX Edge.
  • Amélioration de la micro-segmentation et des opérations de pare-feu : NSX 6.1 améliore les fonctionnalités de micro-segmentation en fournissant un provisionnement, un dépannage et une surveillance améliorés avec les pare-feu NSX Distributed Firewall et Edge Firewall. Une nouvelle interface unifiée permet de configurer les pare-feu Distributed Firewall et Edge Firewall. L'intégration de NSX avec VMware vRealize Automation 6.1 (vRA 6.1, anciennement VMware vCloud Automation Center) permet aux administrateurs d'intégrer leurs workflows d'automatisation de sécurité à leurs workflows d'automatisation de calcul. NSX 6.1 permet également de rediriger le trafic vers des produits de partenaire, tels que les pare-feu de prochaine génération et les services Intrusion Prevention Service.
  • Connecter plusieurs centres de données ou offrir des services de cloud hybride dans SDDC (Software Defined Data Center) : à l'aide de VPN de couche 2 sur NSX Edge, les équipes informatiques peuvent migrer des charges de travail, consolider des centres de données ou créer des niveaux d'application étendus sur plusieurs centres de données. Les fournisseurs de services peuvent facilement offrir des services d'intégration de locataires et d'exploitation du cloud public au sein desquels les réseaux d'applications de locataires sont préservés sur l'ensemble des centres de données sans nécessiter la mise en œuvre de NSX chez le client.
  • Gestion unifiée des adresses IP dans tout le centre de données : avec le relais DHCP, vous pouvez intégrer des services DHCP existants disponibles dans des centres de données physiques à SDDC. Cela garantit une stratégie d'adressage IP cohérente et une gestion simplifiée des adresses IP dans le centre de données. NSX for vSphere 6.1 prend en charge plusieurs serveurs DHCP sur un routeur logique unique et permet l'intégration de plusieurs serveurs DHCP existants.
  • Amélioration de l'équilibrage de charge NSX : pour permettre l'équilibrage de charge et la haute disponibilité de davantage d'applications hébergées dans NSX, NSX 6.1.0 a introduit l'équilibrage de charge UDP. Cela permet à NSX de fournir l'équilibrage de charge à des applications telles que syslog, NTP, DNS.
  • Utiliser des contrôleurs de livraison d'applications (ADC) dans un contexte SDDC (Software Defined Data Center) : NSX 6.1 permet aux clients utilisant des ADC de partenaires NSX de protéger leurs investissements et d'exploiter des services ADC avancés de fournisseurs compatibles.
  • Services avancés de sécurité de l'hôte et du réseau dans SDDC : l'intégration améliorée des partenaires à NSX Service Composer prend en charge plusieurs services de sécurité, notamment des solutions de suite qui comprennent des services hôte-réseau dans une stratégie unique.
  • Libre-service dynamique et sécurisé dans SDDC : NSX 6.1 associé à vCloud Automation Center® vous aide à optimiser l'utilisation et le dimensionnement des ressources en connectant dynamiquement des applications en libre-service à des réseaux logiques NSX, tout en garantissant l'application automatique des stratégies de sécurité d'infrastructure pour isoler et protéger les applications. Reportez-vous aux notes de mise à jour de VMware vCloud Automation Center pour obtenir la liste des fonctionnalités.

Configuration système et installation

Le tableau ci-dessous répertorie les versions recommandées et requises du logiciel VMware. Ces informations sont à jour à la date de publication de ce document.

Produit ou composant Version recommandée
NSX for vSphere 6.2.3
vSphere 5.5U3 ou 6.0U1
Guest Introspection Les fonctionnalités basées sur Guest Introspection et Network Introspection dans NSX sont compatibles avec des versions spécifiques de VMware Tools (VMTools). Pour activer le composant facultatif NSX Network Introspection Driver fourni avec VMware Tools, vous devez effectuer la mise en réseau vers :
  • VMware Tools 5.1 P07 et versions ultérieures

  • VMware Tools 5.5 P04 et versions ultérieures

  • VMware Tools 6.0 P01 et versions ultérieures

  • VMware Tools 10.0 et versions ultérieures

vRealize Orchestrator Plug-in NSX-vRO 1.0.3

Notes relatives aux mises à niveau

Les versions 6.0.x et 6.1.x peuvent être mises à niveau directement vers la version 6.1.7. Consultez la matrice d'interopérabilité des produits VMware pour voir la liste de chemins d'accès de mise à niveau de NSX pris en charge.

Pour effectuer la mise à niveau, réalisez les étapes suivantes :

  1. Mettez à niveau NSX Manager et tous les composants NSX vers la version 6.1.7. Reportez-vous au Guide d'installation et de mise à niveau de NSX pour plus d'informations. Si vous effectuez la mise à niveau depuis vCNS 5.5.x, reportez-vous au Problème résolu 1429432.

    Remarque : Les étapes ci-dessous indiquent comment mettre à niveau d'autres composants de VMware. Si vous ne voulez pas mettre à niveau vCenter Server vers la version 6.0 et ESXi vers la version 6.0, vous n'avez pas à effectuer les étapes suivantes.

    Vous devez effectuer les étapes restantes de cette procédure si vous voulez mettre à niveau vCenter Server et ESXi.

  2. Mettez vCenter Server à niveau vers la version 6.0. Consultez la documentation VMware vSphere 6.0 pour plus d'informations.

  3. Pour réduire les temps d'arrêt, identifiez des sous-réseau des hôtes dans votre environnement, puis mettez à niveau un sous-réseau à la fois. Répétez les étapes 4 à 7 ci-dessous pour chaque sous-réseau.

  4. Placez les hôtes en mode de maintenance. Remarque : Le plan de données des machines virtuelles ne fonctionnera pas comme prévu si des hôtes sont sortis du mode de maintenance et si des machines virtuelles sont mises sous tension trop tôt.

  5. Mettez ESXi à niveau vers la version 6.0. Consultez la documentation VMware vSphere 6.0 pour plus d'informations. Selon les paramètres des hôtes et la méthode de mise à niveau, les hôtes sont redémarrés automatiquement ou nécessitent un redémarrage manuel. Lorsque les hôtes redémarrent, NSX Manager envoie les VIB ESXi 6.0 vers les hôtes.

  6. Lorsque l'onglet Hôtes et clusters, dans la partie gauche de vSphere Web Client, indique qu'un redémarrage des hôtes est nécessaire avec le message reboot required, redémarrez les hôtes une deuxième fois. Les VIB NSX pour ESXi 6.0 sont maintenant activés.

  7. Mettez fin au mode de maintenance sur les hôtes mis à niveau.

    Important : ne sortez pas les hôtes du mode de maintenance avant cette étape.

  8. Répétez les étapes 4 à 7 pour le sous-ensemble d'hôtes suivant jusqu'à ce que tous les hôtes de votre environnement soient mis à niveau.

Problèmes connus

Les problèmes connus sont regroupés de la manière suivante :

Problèmes de mise à niveau et d'installation

Après la mise à niveau de NSX Manager/Controller vers NSX 6.1.6 ou version ultérieure, il n'y a pas de compatibilité descendante pour les versions de NSX Edge antérieures à 6.1.6
Dans la plupart des mises à niveau de NSX, vous pouvez mettre à niveau NSX Manager et NSX Controller et continuer l'installation pendant un moment sans mettre à niveau les NSX Edge. Dans les mises à niveau de NSX 6.1.5 ou version antérieure vers NSX 6.1.6 ou version ultérieure, ce n'est pas le cas. Vous devez mettre à niveau NSX Manager, le cluster de NSX Controller, les clusters d'hôte NSX et NSX Edge vers 6.1.6 ou version ultérieure. Les opérations d'Edge ne reprennent qu'une fois que vous avez mis à niveau NSX Edge vers 6.1.6 ou version ultérieure. Ce problème n'affecte pas les mises à niveau de NSX 6.1.6 vers NSX 6.1.7.

DVPort ne parvient pas à s'activer avec Possibilité de blocage en raison d'un problème de préparation de l'hôte
Sur un hôte ESXi activé par NSX, DVPort ne parvient pas à s'activer avec « Possibilité de blocage » en raison d'un problème de préparation de l'hôte. Lorsque cela se produit, le message d'erreur qui s'affiche en premier varie (par exemple, ce problème peut être considéré comme un échec de création de VTEP dans le fichier VC/hostd.log, un échec de connexion DVPort dans le fichier vmkernel.log ou une erreur SIOCSIFFLAGS dans l'invité). Cela se produit lorsque les VIB sont chargés après que les propriétés DVS sont envoyées par vCenter. Cela peut se produire pendant une mise à niveau.

Solution : dans NSX 6.1.4 et version antérieure, un redémarrage supplémentaire est requis pour résoudre ce type d'échec DVPort sur des sites utilisant un routeur logique NSX. Dans NSX 6.1.5 et versions ultérieures, une correction est fournie dans le logiciel NSX. Cette correction permet d'éviter un second redémarrage dans la plupart des cas. La cause principale est un problème connu dans vSphere. Reportez-vous à l'article 2107951 de la base de connaissances VMware pour obtenir plus de détails.

Impossible d'équilibrer la charge des serveurs virtuels
Lors de la mise à niveau de NSX Edge de la version 6.1.1 vers la version 6.1.3, si vous activez un certificat d'autorité de certification et SSL du côté du pool dans le profil d'application associé à un serveur virtuel, NSX Edge tente automatiquement de vérifier le certificat principal du côté du pool. Le trafic ne peut pas traverser le pool principal si les certificats d'autorité de certification configurés dans NSX Edge ne peuvent pas vérifier le certificat de serveur. À tout moment, le serveur de pool principal doit disposer d'un certificat valide.

Solution : si vous utilisez NSX 6.1.3, désélectionnez l'option « Configurer le certificat de service » pour les certificats de pool et les certificats d'autorité de certification dans la configuration des certificats du côté du pool. Il n'est pas nécessaire d'effectuer cette étape si vous utilisez NSX 6.1.1. Pour 6.1.1, le certificat de serveur transmettra la vérification même si l'autorité de certification configurée ne peut pas vérifier le certificat de serveur envoyé par le serveur principal.

Les mises à niveau depuis vCNS 5.5.x nécessitent une étape supplémentaire
Si vous prévoyez d'effectuer une mise à niveau vers VMware NSX 6.1.x depuis VMware vCloud Networking and Security 5.5.x, vérifiez s'il manque l'information de nom de port de liaison montante dans la base de données NSX.
Solution : Consultez l'article 2132355 de la base de connaissances VMware pour obtenir des instructions.

Le redémarrage de NSX Manager durant une mise à niveau entraîne un problème de synchronisation de l'inventaire
Si NSX Manager est redémarré durant une mise à niveau, l'onglet Préparation de l'hôte NSX contient une option « Installation » au lieu d'une option « Mise à niveau » pour les clusters préparés. NSX Manager ne doit pas être réinitialisé durant une mise à niveau.

Solution : Cliquez sur l'option Installation pour pousser les VIB NSX vers les hôtes ou appeler l'API suivant :
POST https://<vsm-ip>/api/2.0/si/deploy?startTime=<time>&ignoreDependency=<true/false>

Perte momentanée de la protection antivirus tierce lors de la mise à niveau
Lorsque vous mettez à niveau NSX 6.0.x vers NSX 6.1.x ou 6.2.x, une perte momentanée de la protection antivirus tierce peut se produire pour les machines virtuelles. Ce problème n'affecte pas les mises à niveau de NSX 6.1.x vers NSX 6.2.x.

Solution : aucune.

Activation obligatoire du démarrage automatique sur l'hôte de destination lors de la migration de dispositifs NSX
Sur les hôtes où les dispositifs NSX Edge et les instances de NSX Controller sont déployés pour la première fois, NSX permet le démarrage et l'arrêt automatiques de machines virtuelles. Si le dispositif NSX ou les machines virtuelles du contrôleur sont migrées ultérieurement vers d'autres hôtes, il se peut que le démarrage et l'arrêt automatique de machines virtuelles ne soient pas activés sur les nouveaux hôtes.

Solution : Lors de la migration d'un dispositif NSX ou d'un contrôleur vers un nouveau cluster, contrôlez tous les hôtes du cluster pour vérifier que le démarrage et l'arrêt automatique de machines virtuelles sont activés.

Impossible d'importer des règles de pare-feu depuis une installation de NSX mise à niveau depuis vCNS dans une installation de NSX d'origine
L'ID d'application de chaque protocole ou service connu (comme ICMPv6) est le même sur toutes les versions d'environnements NSX récemment installés. Toutefois, dans une installation qui a été mise à niveau depuis vCNS vers NSX, l'ID d'application d'un service donné peut être différent de l'ID d'application qui est utilisé pour ce service sur une nouvelle installation de NSX (d'origine). Il s'agit d'un comportement connu car de nouveaux ID d'application ont été ajoutés à NSX mais pas à vCNS. Ainsi, il existe une différence entre le nombre d'ID d'application dans vCNS et dans NSX. À cause de cette différence, vous ne pouvez pas exporter des règles de pare-feu (DFW) depuis une installation de NSX mise à niveau et les importer dans une installation de NSX d'origine.

Solution : aucune.

Impossible de reconfigurer le serveur SSO après une mise à niveau
Lorsque le serveur SSO configuré sur NSX Manager est le serveur natif sur vCenter Server, vous ne pouvez pas reconfigurer les paramètres SSO sur NSX Manager après la mise à niveau de vCenter Server vers la version 6.0 et de NSX Manager vers la version 6.1.3.

Solution : aucune.

L'interface utilisateur de déploiement de service affiche l'erreur vAppConfig absente de la VM

Solution : si le message d'erreur ci-dessus s'affiche, vérifiez les points suivants :

  1. Le déploiement de la machine virtuelle de service est terminé.
  2. Aucune tâche telle que le clonage, la reconfiguration, etc. n'est en cours pour cette machine virtuelle dans le volet des tâches de vCenter Server.

Une fois les étapes 1 et 2 achevées, supprimez la machine virtuelle de service. Sur l'interface utilisateur de déploiement de service, le déploiement apparaît avec l'état Échec. En cliquant sur l'icône rouge, une alarme concernant la VM agent comme étant indisponible s'affiche pour l'hôte. Lorsque vous résolvez l'alarme, la machine virtuelle est redéployée et mise sous tension.

vSphere Web Client n'affiche pas l'onglet Networking and Security à la suite de la sauvegarde et de la restauration
Lorsque vous effectuez des opérations de sauvegarde et de restauration à la suite d'une mise à niveau vers NSX for vSphere 6.1.3, vSphere Web Client n'affiche pas l'onglet Networking and Security.

Solution : lorsqu'une sauvegarde NSX Manager est restaurée, vous êtes déconnecté du portail de gestion de dispositif virtuel NSX Manager. Attendez quelques minutes avant de vous connecter à vSphere Web Client.

La spécification de déploiement avec version doit être mise à jour vers la version 6.0.* si vous utilisez vCenter Server 6.0 et ESX 6.0.
Solutions : la solution n'est possible que si le partenaire est à ce moment-là sur vCloud Networking and Security ou NSX for vSphere.

  • Les partenaires possédant des solutions NetX enregistrées avec vCloud Networking and Security doivent mettre leur enregistrement à jour pour inclure une VersionedDeploymentSpec pour 6.0.* dans l'OVF correspondant en utilisant les appels d'API REST.
    1. Mettez à niveau vSphere 5.5 vers 6.0.
    2. Ajoutez la spécification de déploiement avec version 6.0.x à l'aide de l'appel d'API suivant :
      
      POST https://<vCNS-IP>/api/2.0/si/service/<service-id>/service  \
      deploymentspec/versioneddeploymentspec
      <versionedDeploymentSpec> <hostVersion>6.0.x</hostVersion> <ovfUrl>http://sample.com/sample.ovf</ovfUrl> <vmciEnabled>true</vmciEnabled> </versionedDeploymentSpec>

      L'URL du fichier OVF est fournie par le partenaire.
    3. Mettez à jour le service à l'aide de l'appel REST suivant
      POST https://<vsm-ip>/api/2.0/si/service/config?action=update
    4. Résolvez l'alarme EAM en procédant comme suit.
      1. Dans vSphere Web Client, cliquez sur Accueil, puis sur Administration.
      2. Dans Solution, sélectionnez vCenter Server Extension.
      3. Cliquez sur vSphere ESX Agent Manager, puis sur l'onglet Gérer.
      4. En cas d'état échec agence, faites un clic droit et sélectionnez Résoudre tous les problèmes.
  • Si des partenaires ont enregistré des solutions NetX avec une mise à niveau NSX for vSphere vers la version 6.0, ils doivent mettre à jour leur enregistrement pour inclure un VersionedDeploymentSpec pour la version 6.0.* dans l'OVF correspondant. Suivez les étapes ci-dessous :

    1. Ajoutez la spécification de déploiement pour la version 6.0.* en suivant ces étapes.
      1. Dans vSphere Web Client, cliquez sur Accueil puis sur Networking and Security.
      2. Cliquez sur Service Definitions puis sur « Nom de service ».
      3. Cliquez sur Gérer, puis sur Déploiement.
      4. Cliquez sur + et ajoutez des versions ESX en tant que 6.0.* ainsi que l'URL de l'OVF avec l'URL de la machine virtuelle de service correspondante.
      5. Cliquez sur OK.
    2. Résolvez le problème en procédant comme suit.
      1. Cliquez sur Installation.
      2. Cliquez sur Déploiements de services.
      3. Sélectionnez le déploiement et cliquez sur Résoudre.

Une fois la mise à niveau de NSX for vSphere passée de la version 6.0.7 à la version 6.1.3, vSphere Web Client se bloque sur l'écran de connexion
Après la mise à niveau de NSX Manager de la version 6.0.7 vers la version 6.1.3, des exceptions sont affichées sur l'écran de connexion de l'interface utilisateur de vSphere Web Client. Vous ne pourrez plus vous connecter ni réaliser d'opérations sur vCenter ou NSX Manager.

Solution : connectez-vous à VCVA en tant qu'utilisateur racine et redémarrez le service vSphere Web Client.

si vCenter est redémarré lors du processus de mise à niveau de NSX for vSphere, le cluster affiche un statut incorrect
Lors de la préparation de l'hôte dans un environnement avec plusieurs clusters NSX préparés pendant une mise à niveau et si vCenter Server est redémarré suite à la préparation d'au moins un cluster, les autres clusters peuvent afficher le statut Non prêt plutôt que d'afficher un lien de mise à jour. Les hôtes dans vCenter peuvent également afficher Redémarrage requis.

Solution : ne redémarrez pas vCenter lors de la préparation de l'hôte.

Après la mise à niveau de vCloud Networking and Security 5.5.3 vers NSX for vSphere 6.0.5 ou version ultérieure, NSX Manager ne démarre pas si vous utilisez un certificat SSL avec une taille de clé DSA 1 024 bits
Les certificats SSL avec une taille de clé DSA 1 024 bits ne sont pas pris en charge dans NSX for vSphere 6.0.5 ou version ultérieure, ce qui entraîne l'échec de la mise à niveau.

Solution : Avant de commencer la mise à niveau, importez un nouveau certificat SSL dont la taille de clé est de 2 048 bits.

la mise à niveau de NSX Edge échoue si L2 VPN est activé sur le dispositif Edge
La mise à niveau de la configuration VPN L2 de la version 5.x ou 6.0.x vers la version 6.1 n'est pas prise en charge. Par conséquent, la mise à niveau d'Edge échoue si VPN L2 y est configuré.

Solution : supprimez la configuration VPN L2 avant de procéder à la mise à niveau de NSX Edge. Reconfigurez le VPN L2 après la mise à jour.

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 à l'utilisateur. 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.

Après la mise à niveau de NSX de la version 6.0 à la version 6.0.x ou 6.1, les dispositifs NSX Edge ne s'affichent pas sur l'interface utilisateur
Lorsque vous mettez à niveau NSX 6.0 vers NSX 6.0.x ou 6.1, le plug-in de vSphere Web Client peut ne pas se mettre à niveau correctement. Cela peut entraîner des problèmes d'affichage d'interface utilisateur, notamment des instances NSX Edge manquantes.
Ce problème ne se produit pas si vous mettez à niveau NSX 6.0.1 ou une version ultérieure.

Solution : aucune.

Le MTU de vSphere Distributed Switch ne se met pas à jour
Si vous spécifiez une valeur MTU inférieure au MTU de vSphere Distributed Switch lors de la préparation d'un cluster, vSphere Distributed Switch n'est pas mis à jour à cette valeur. Cela a pour but de garantir que le trafic existant présentant une taille de trame supérieure n'est pas abandonné accidentellement.

Solution : vérifiez que le MTU que vous spécifiez lors de la préparation du cluster est supérieur ou égal au MTU actuel de vSphere Distributed Switch. Le MTU minimal requis pour VXLAN est de 1 550.

Si tous les clusters de votre environnement ne sont pas préparés, le message de mise à niveau pour Distributed Firewall ne s'affiche pas sur l'onglet Préparation de l'hôte de la page Installation.
Lorsque vous préparez des clusters pour la virtualisation réseau, Distributed Firewall est activé sur ces clusters. Si tous les clusters de votre environnement ne sont pas préparés, le message de mise à niveau pour Distributed Firewall ne s'affiche pas sur l'onglet Préparation de l'hôte.

Solution : Utilisez l'appel REST suivant pour mettre à niveau Distributed Firewall :

PUT https://vsm-ip/api/4.0/firewall/globalroot-0/state/vsm-ip

si un groupe de services est modifié à la suite de la mise à niveau pour ajouter ou supprimer des services, ces modifications ne sont pas reflétées dans le tableau du pare-feu.
Les groupes de services créés par les utilisateurs sont développés dans le tableau Edge Firewall lors de la mise à niveau, c'est-à-dire que la colonne Service du tableau du pare-feu affiche tous les services au sein du groupe de services. Si le groupe de services est modifié après la mise à niveau pour ajouter ou supprimer des services, ces modifications ne sont pas reflétées dans le tableau du pare-feu.

Solution : créez un nouveau groupe de services avec un nom différent puis utilisez ce groupe de services dans la règle du pare-feu.

l'installation de Guest Introspection échoue sans erreur
Lors de l'installation de Guest Introspection sur un cluster, l'installation échoue avec le message d'erreur suivant :
Format de module VIB non valide

Solution : dans vCenter Web Client, dirigez-vous vers Accueil vCenter > Hôtes et clusters puis redémarrez les hôtes à côté desquels figurent Redémarrage nécessaire, dans l'inventaire situé sur le côté gauche.

La machine virtuelle de service déployée à l'aide de l'onglet Déploiements de services dans la page Installation n'est pas mise sous tension

Solution : Suivez les étapes ci-dessous.

  1. Supprimez manuellement la machine virtuelle de service du pool de ressources Agents ESX dans le cluster.

  2. Cliquez sur Networking and Security, puis cliquez sur Installation.

  3. Cliquez sur l'onglet Déploiements de services.

  4. Sélectionnez le service approprié, puis cliquez sur l'icône Résoudre.
    La machine virtuelle de service est redéployée.

Si un profil de service créé dans la version 6.0.x est lié à la fois au groupe de sécurité et au groupe de ports distribué ou au commutateur logique, les règles du pare-feu de Service Composer ne sont pas synchronisées une fois la mise à niveau vers NSX 6.1.x effectuée
Si une liaison de profil de service était réalisée à la fois avec le groupe de sécurité et le groupe de ports distribué ou le commutateur logique dans la version 6.0.x, les règles de Service Composer ne sont pas synchronisées après la mise à niveau vers la version 6.1 Les règles ne peuvent pas être publiées à partir de l'interface utilisateur de Service Composer.

Solution : Suivez les étapes ci-dessous.

  1. Annulez la liaison entre le profil du service et le groupe de ports distribué ou le commutateur logique via l'interface utilisateur de Service Definition.
  2. Créez un groupe de sécurité en incluant comme membre de ce groupe le groupe de ports distribué ou le commutateur logique requis.
  3. Liez le profil du service au nouveau groupe de sécurité via l'interface utilisateur de Service Definition.
  4. Synchronisez les règles de pare-feu via l'interface utilisateur de Service Composer.

Problèmes généraux

Échec du routeur logique distribué avec l'erreur Possibilité de blocage
Les routeurs logiques distribués NSX peuvent échouer lorsque la configuration de l'hôte change. Cela se produit lorsque vSphere ne parvient pas à créer un port VDR requis sur l'hôte. Cette erreur peut être vue comme un échec de connexion DVPort dans vmkernel.log ou comme une erreur SIOCSIFFLAGS dans l'invité. Cela peut se produire lorsque les VIB sont chargés après que les propriétés de vSphere Distributed Switch (vDS) sont envoyées par vCenter.

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

NSX limite la longueur des URL à 16 000 caractères, si les utilisateurs souhaitent attribuer une balise de sécurité unique à x machines virtuelles à un moment donné dans un appel d'API
Si la longueur de l'adresse est supérieure à 16 000 caractères, les utilisateurs ne peuvent pas attribuer de balise de sécurité unique à un total de x machines virtuelles simultanément en utilisant un seul appel d'API. L'URL doit contenir un maximum de 16 000 caractères.

Solution :

  1. La longueur de l'URL ne doit pas dépasser 16 000 caractères.

  2. Les performances sont optimales lorsque environ 500 machines virtuelles sont balisées lors d'un même appel. Baliser plus de machines virtuelles lors d'un même appel peut dégrader les performances.

Les hôtes ESXi n'apprennent pas la liste des contrôleurs NSX disponibles
Pour voir si ce problème se produit, vérifiez si le fichier config-by-vsm.xml existe sur les hôtes. Un fichier avec les adresses IP de contrôleur existe dans des conditions normales. Ce problème peut être le résultat d'une défaillance temporaire du bus de messages.

Solution : vous devez rechercher des messages d'échec de mot de passe et resynchroniser le bus de messages. Utilisez l'API REST suivante pour resynchroniser le bus de messages :

/api/2.0/nwfabric/configure?action=synchronize
[edit] http method
POST
[edit] Body
<nwFabricFeatureConfig>
  <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
  <resourceConfig>
   <resourceId<{HOST/CLUSTER MOID}</resourceId>
   </resourceConfig>
</nwFabricFeatureConfig>

Prise en charge de vCNS - SSL VPN-Plus dans Windows 10
Le portail VPN SSL ne s'ouvre pas dans les navigateurs Internet Explorer/Edge sous Windows 10, mais cela fonctionne avec les autres navigateurs.

Solution : Les clients SSL VPN PHAT fonctionnent sous Windows 10.

Le nom d'une stratégie de sécurité ne peut pas excéder 229 caractères
Le champ du nom d'une stratégie de sécurité dans l'onglet Stratégie de sécurité de Service Composer peut accepter jusqu'à 229 caractères. Cela est dû au fait que les noms des stratégies sont préparés en interne avec un préfixe.

Solution : aucune.

impossible de mettre sous tension une machine virtuelle invitée
Lorsque vous mettez sous tension une machine virtuelle invitée, l'erreur Toutes les machines virtuelles nécessaires des agents ne sont pas déployées actuellement peut s'afficher.

Solution : Suivez les étapes ci-dessous.

  1. Dans vSphere Web Client, cliquez sur Accueil, puis sur Administration.

  2. Dans Solution, sélectionnez vCenter Server Extension.

  3. Cliquez sur vSphere ESX Agent Manager, puis sur l'onglet Gérer.

  4. Cliquez sur Résoudre.

NSX limite la longueur des URL à 16 000 caractères, si les utilisateurs souhaitent attribuer une balise de sécurité unique à x machines virtuelles à un moment donné dans un appel d'API
Si la longueur de l'URL est supérieure à 16 000 caractères, vous ne pouvez pas attribuer de balise de sécurité unique à un total de x machines virtuelles simultanément en utilisant un seul appel d'API. L'URL peut contenir un maximum de 16 000 caractères.

Solution :

  1. La longueur de l'URL ne doit pas dépasser 16 000 caractères.
  2. Les performances sont optimales lorsque environ 500 machines virtuelles sont balisées lors d'un même appel. Baliser plus de machines virtuelles lors d'un même appel peut dégrader les performances.

Lorsque NSX est installé sur vCSA 6.0, l'utilisateur local de système d'exploitation ne peut pas voir NSX dans vSphere Web Client
Si vous avez installé NSX sur vCSA 6.0, un utilisateur de vSphere authentifié par l'entreprise peut voir l'onglet NSX Networking and Security dans vSphere Web Client, mais pas un utilisateur de vSphere local de système d'exploitation.

Solution : Suivez les étapes décrites ci-dessous :

  1. Connectez-vous à vSphere Web Client en tant qu'utilisateur administrateur@vsphere.local.
  2. Accédez à l'onglet Administration > Utilisateurs et groupes > Groupes et sélectionnez le groupe d'administrateurs sous le domaine vsphere.local.
  3. Cliquez sur le bouton Ajouter un membre sur la grille Membres du groupe et ajoutez un utilisateur racine à ce groupe.
  4. Accédez à NSX Manager et cliquez sur l'onglet Networking and Security > NSX Manager > Gérer > Utilisateurs et cliquez sur le bouton Ajouter un utilisateur (+).
  5. Attribuez un rôle d'utilisateur racine et cliquez sur le bouton Terminer.
  6. Déconnectez-vous et reconnectez-vous en tant qu'utilisateur racine.

Problèmes de NSX Manager

Le contrôle des flux de NSX Manager peut ne pas afficher les flux pour les intervalles suivants : « 15 dernières minutes » ou « dernière heure »

Dans les installations de NSX dont le trafic est volumineux, l'interface utilisateur du contrôle des flux de NSX Manager affiche le message « No Flow Records » (Pas d'enregistrement de flux) lorsque l'intervalle sélectionné correspond à « 15 dernières minutes » ou à « dernière heure ». Cela se produit lorsque les enregistrements de flux ne sont pas actualisés assez souvent pour s'assurer que les derniers enregistrements des flux sont disponibles.

Solution : Pour les installations dont le trafic est élevé, VMware conseille à ses clients d'utiliser IPFix ou de se connecter à un serveur syslog distant (en utilisant par exemple VMware LogInsight) pour recueillir les flux.

NSX manager redémarre automatiquement si plusieurs projets de workflow Service Composer s'accumulent
S'il existe un grand nombre d'objets dans le champ source/destination/appliqué à dans les règles de pare-feu et si NSX a enregistré automatiquement plusieurs workflows de Service Composer, NSX Manager peut redémarrer de façon inattendue. Cela peut également se produire si vous utilisez Service Composer pour appliquer des stratégies à un grand nombre de groupes de service et si NSX a enregistré automatiquement plusieurs Workflows de Service Composer.

Solution : Si votre installation correspond à la description ci-dessus, et que NSX Manager redémarre de façon inattendue, contactez le support VMware pour obtenir de l'aide pour supprimer les projets de workflows de Service Composer enregistrés.

Après restauration de la sauvegarde de NSX Manager, l'appel REST affiche l'état de la fonctionnalité fabric « com.vmware.vshield.vsm.messagingInfra » comme étant « Rouge »
Lorsque vous restaurez la sauvegarde d'une instance de NSX Manager et vérifiez l'état de la fonctionnalité fabric « com.vmware.vshield.vsm.messagingInfra » à l'aide d'un appel d'API REST, il s'affiche comme étant « Rouge » au lieu de « Vert ».

Solution : Utilisez l'appel API REST suivant pour réinitialiser la communication entre NSX Manager et un hôte unique ou tous les hôtes d'un cluster.
POST https://<nsxmgr-ip>/api/2.0/nwfabric/configure?action=synchronize
<nwFabricFeatureConfig>
<featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
<resourceConfig>
    <resourceId>HOST/CLUSTER MOID</resourceId>
</resourceConfig>
</nwFabricFeatureConfig>

l'onglet Networking and Security non affiché dans vSphere Web Client
À la suite de la mise à niveau de vSphere vers la version 6.0, il vous est impossible de voir l'onglet Networking and Security lors de votre connexion à vSphere Web Client en utilisant le nom d'utilisateur racine.

Solution : connectez-vous en tant qu'administrateur@vsphere.local ou tout autre utilisateur vCenter existant sur vCenter Server avant la mise à niveau et dont le rôle était défini dans NSX Manager.

impossible de supprimer et de rajouter un hôte à un cluster protégé par Guest Introspection et par des solutions de sécurité tierces
Si vous supprimez un hôte d'un cluster protégé par Guest Introspection et par des solutions de sécurité tierces en le déconnectant, puis en le supprimant de vCenter Server, vous pouvez rencontrer des problèmes si vous essayez de rajouter le même hôte au même cluster.

Solution : Pour supprimer un hôte d'un cluster protégé, placez tout d'abord l'hôte en mode de maintenance. Placez ensuite l'hôte dans un cluster non protégé ou en dehors de l'ensemble des clusters, puis déconnectez-le et supprimez-le.

vMotion de NSX Manager peut afficher l'erreur La carte Ethernet virtuelle Adaptateur réseau 1 n'est pas prise en charge
Vous pouvez ignorer cette erreur. La mise en réseau fonctionnera correctement après vMotion.

Problèmes relatifs à NSX Edge et au routage logique

lors de la modification d'une règle de filtre voisin BGP, les filtres existants peuvent ne pas s'appliquer pendant une durée pouvant atteindre 40 secondes.
Lorsque les filtres BGP sont appliqués à un NSX Edge exécutant IBGP, ils peuvent nécessiter jusqu'à 40 secondes pour s'appliquer à la session IBGP. Pendant ce temps, NSX Edge peut annoncer des routes qui sont refusées par le filtre BGP pour la session IBGP homologue.

Solution : aucune.

Une fois ECMP autorisé sur un routeur logique, le dispositif Edge orienté vers le nord ne reçoit aucun préfixe de la part de ce routeur logique.

Solution : Suivez les étapes ci-dessous :

  1. Désactivez ECMP sur le routeur logique.
  2. Désactivez OSPF.
  3. Activez ECMP.
  4. Activez OSPF.

Si le certificat d'authentification est activé sous configuration d'authentification de service VPN-Plus SSL, une connexion au serveur VPN SSL à partir d'une version plus ancienne de client Windows échoue
Si le certificat d'authentification est activé, l'établissement d'une liaison TLS entre une version plus ancienne du client Windows et la dernière version de VPN SSL échoue. Cela empêche le client Windows de se connecter à VPN SSL. Ce problème ne se produit pas sur les clients Linux et Mac ou avec une connexion à l'aide d'un navigateur vers VPN SSL.

Solution : mettez le client Windows à niveau vers la version la plus récente, comme la version 6.1.4.

La mise à niveau du programme autonome NSX Edge en tant que client VPN L2 n'est pas prise en charge

Solution : vous devez déployer un nouvel OVF Edge et reconfigurer les paramètres du dispositif.

lorsque le réseau agrégé direct d'un sous-réseau local et distant d'un canal VPN IPsec est supprimé, la route agrégée vers les sous-réseaux indirects du dispositif Edge homologue disparaît également
Lorsqu'il n'y a aucune passerelle par défaut sur le dispositif Edge et que vous supprimez tous les sous-réseaux de connexion directe dans les sous-réseaux locaux et une partie des sous-réseaux distants en même temps que vous configurez IPsec, les sous-réseaux homologues restants deviennent inaccessibles par VPN IPsec.

Solution : désactivez, puis réactivez VPN IPsec sur NSX Edge.

La modification du script de connexion/déconnexion VPN Plus SSL ne fonctionne pas
Le script modifié est correctement appliqué sur vSphere Web Client mais pas sur la passerelle.

Solution : supprimez le script d'origine, puis ajoutez-le de nouveau.

L'ajout d'une route apprise via un protocole comme connectée entraîne l'affichage dans le tableau FIB (Forwarding Information Base) de routes connectées et de routes dynamiquement apprises
Si vous ajoutez une route déjà apprise via un protocole comme connectée, le tableau FIB local affiche des routes connectées et apprises dynamiquement. La route apprise dynamiquement apparaît comme prioritaire (préférée), devant la route directement connectée.

Solution : Retirez la route apprise de l'annonce de route afin qu'elle soit supprimée du tableau FIB et configurez uniquement la route connectée.

si une machine virtuelle NSX Edge avec une sous-interface soutenue par un commutateur logique est supprimé via l'interface utilisateur vCenter Web Client, le chemin de données peut ne pas fonctionner pour une nouvelle machine virtuelle qui se connecte au même port
Lorsque la machine virtuelle Edge est supprimée via l'interface utilisateur vCenter Web Client (plutôt qu'à partir de NSX Manager), la jonction vxlan configurée sur dvPort sur le canal opaque n'est pas réinitialisée. Cela est dû au fait que la configuration de la jonction est gérée par NSX Manager.
 
Solution : pour supprimer manuellement la configuration de la jonction vxlan, procédez comme suit :

  1. Accédez à vCenter Managed Object Browser en tapant la commande suivante dans une fenêtre de navigateur :
    https://vc-ip/mob?vmodl=1
  2. Cliquez sur Contenu.
  3. Pour récupérer la valeur dvsUuid, procédez comme suit.
    1. Cliquez sur le lien rootFolder (par exemple, group-d1(Datacenters)).
    2. Cliquez sur le lien du nom du centre de données (par exemple, datacenter-1).
    3. Cliquez sur le lien networkFolder (par exemple, group-n6).
    4. Cliquez sur le lien du nom DVS (par exemple, dvs-1)
    5. Copiez la valeur d'uuid.
  4. Cliquez sur DVSManager, puis sur updateOpaqueDataEx.
  5. Dans selectionSet, ajoutez le code XML suivant
    <selectionSet xsi:type="DVPortSelection">
        <dvsUuid>value</dvsUuid>
        <portKey>value</portKey> <!--numéro de port du DVPG où la jonction vnic est connectée-->
    </selectionSet>
  6. Dans opaqueDataSpec, ajoutez le code XML suivant
    <opaqueDataSpec>
        <operation>remove</operation>
        <opaqueData>
          <key>com.vmware.net.vxlan.trunkcfg</key>
          <opaqueData></opaqueData>
        </opaqueData>
    </opaqueDataSpec>
  7. Définissez isRuntime sur false.
  8. Cliquez sur Appeler la méthode.
  9. Répétez les étapes 5 à 8 pour chaque port de jonction configuré sur la machine virtuelle Edge supprimée.

Lorsque l'option Provenance par défaut est activée, le filtre BGP permettant de refuser la route par défaut n'est pas appliqué
Lorsque l'option Provenance par défaut est activée sur un dispositif NSX Edge, une route par défaut est annoncée inconditionnellement à tous les voisins BGP. Si vous ne souhaitez pas qu'un voisin BGP installe la route par défaut annoncée par ce locuteur BGP, vous devez configurer une stratégie entrante sur ce voisin BGP pour rejeter la route par défaut.
 
Solution : Configurez une stratégie entrante sur le voisin BGP pour refuser la route par défaut.

impossible d'ajouter des caractères non-ASCII dans un nom de pont ou de locataire pour un routeur logique
Les API de contrôleur NSX ne prennent pas en charge les caractères non-ASCII.
 
Solution : Utilisez des caractères ASCII dans les noms de pont et de locataire. Vous pouvez ensuite modifier les noms pour inclure des caractères non-ASCII.

SNAT et l'équilibrage de charge (avec L4 SNAT) configurés sur une sous-interface ne fonctionnent pas
La configuration de la règle SNAT passe sur NSX Edge mais le chemin de données de la règle ne fonctionne pas en raison des contrôles de filtre RP.
 
Solution : Contactez le support VMware pour obtenir de l'aide sur l'assouplissement du contrôle de filtre RP sur un dispositif NSX Edge.

Lorsque l'optimisation de sortie est activée pour VPN L2, les équilibrages de charge avec les membres du pool étendus à l'échelle du site sont présentés comme étant hors service
Avec l'optimisation de sortie, le client et le serveur VPN L2 ont la même adresse IP interne. De ce fait, tout paquet provenant d'un membre du pool et soumis à l'équilibrage de charge n'atteint pas le dispositif NSX Edge.
 
Solution : Effectuez l'une des opérations suivantes.

  • Désactivez l'optimisation de sortie.
  • Attribuez une adresse IP pour l'équilibrage de charge qui est différente de l'adresse IP optimisée de sortie.

Les routes statiques ne sont pas envoyées vers les hôtes lorsque aucune adresse Next Hop n'est spécifiée
L'interface utilisateur vous permet de créer une route statique sur un périphérique NSX Edge sans avoir besoin de spécifier une adresse Next Hop. Si vous ne spécifiez pas de valeur Next Hop, la route statique n'est pas envoyée vers les hôtes.
 
Solution : Spécifiez toujours une adresse Next Hop pour les itinéraires statiques.

impossible de configurer le pare-feu NSX en utilisant des groupes de sécurité ou d'autres objets de regroupement définis à un niveau global
Les administrateurs définis au niveau de NSX Edge ne peuvent pas accéder aux objets définis au niveau global. Par exemple, si l'utilisateur abc est défini au niveau Edge et si le groupe de sécurité sg-1 est défini au niveau global, abc ne pourra pas utiliser sg-1 dans la configuration du pare-feu sur NSX Edge.

Solution : L'administrateur doit utiliser les objets de regroupement définis au niveau NSX Edge uniquement, ou créer une copie des objets définis à un niveau global au niveau de NSX Edge.

Des routes LIF de routeur logique sont annoncées par ESG (Edge Services Gateway) en amont même lorsque le protocole OSPF du routeur logique est désactivé
ESG (Edge Services Gateway) en amont continue à annoncer des LSA externes OSPF extraites des interfaces connectées du routeur logique, même lorsque le protocole OSPF du routeur logique est désactivé.

Solution : Désactivez manuellement la redistribution des itinéraires connectés manuellement dans OSPF et publiez-la avant de désactiver le protocole OSPF. Cela garantit que les itinéraires sont retirés correctement.

lorsque HA est activé sur Edge Services Gateway, les intervalles OSPF hello et dead respectivement configurés à des valeurs différentes de 30 secondes et de 120 secondes peuvent entraîner une perte de trafic lors d'un basculement
Lorsque l'instance principale de NSX Edge échoue alors que le protocole OSPF est en cours d'exécution et que HA est activé, le temps nécessaire pour déclencher la veille dépasse le délai d'attente normal de redémarrage et entraîne la suppression des routes apprises des protocoles OSPF voisins de leur table FIB (Forwarding Information Base). Cela entraîne une indisponibilité du plan de données jusqu'à ce que le protocole OSPF converge de nouveau.

Solution : Définissez les délais d'attente de l'intervalle « hello/dead » de tous les routeurs voisins sur 30 secondes pour l'intervalle hello et à 120 secondes pour l'intervalle dead. Cela active le basculement normal sans perte de trafic.

L'interface utilisateur vous permet d'ajouter plusieurs adresses IP à une interface de routeur logique, même si elle n'est pas prise en charge
Cette version ne prend pas en charge plusieurs adresses IP pour une interface de routeur logique.

Solution : aucune.

VPN SSL ne prend pas en charge les CRL (listes de révocation des certificats)
Un CRL peut être ajouté à NSX Edge, mais ce CRL n'est pas utilisé par VPN VPN.

Solution : Les CRL ne sont pas prises en charge, mais vous pouvez activer l'authentification utilisateur avec l'authentification du certificat client.

Vous devez utiliser une adresse IP, mais pas un nom d'hôte, pour ajouter un serveur d'authentification externe à VPN-Plus SSL
Vous ne pouvez utiliser ni le nom de domaine complet ni le nom d'hôte du serveur d'authentification externe.

Solution : Vous devez utiliser l'adresse IP du serveur d'authentification externe.

Problèmes de pare-feu

Les règles de pare-feu créées par Service Composer sont automatiquement désactivées lorsque les services référencés sont forcés à être supprimés
Lorsque vous forcez la suppression de services référencés dans les règles de Service Composer, vous remarquerez que les règles de référencement des services supprimés sont automatiquement désactivées sans avertissement ou alerte pour l'utilisateur. Cela permet d'éviter que Service Composer ne perde sa synchronisation.

Solution : Vous devez corriger la règle de pare-feu de la règle de sécurité dont le service n'est pas valide. Assurez-vous de ne pas forcer la suppression de groupes de service et de sécurité utilisés dans les règles de pare-feu de Service Composer.

L'ajout d'une nouvelle machine virtuelle à un commutateur logique ne publie pas automatiquement les règles de pare-feu de NSX Edge
Lorsque vous ajouterez de nouvelles machines virtuelles à un commutateur logique, vous remarquerez peut-être que les règles de pare-feu NSX Edge ne sont pas publiées automatiquement. Il pourra s'avérer nécessaire de republier manuellement les règles de pare-feu pour que les nouvelles machines virtuelles soient appliquées avec une règle correcte.

Solution : Placez chaque commutateur logique dans un groupe de sécurité. Si les règles de pare-feu sont définies à l'aide du groupe de sécurité auquel appartient un commutateur logique, et que la nouvelle machine virtuelle est ajoutée à ce commutateur logique, les règles de pare-feu associées sont automatiquement mises à jour pour inclure l'adresse IP de la nouvelle machine virtuelle. Il n'est pas nécessaire de redéployer les règles de pare-feu.

La republication de la règle de pare-feu échoue après l'utilisation de l'API DELETE
Si vous supprimez la totalité de la configuration du pare-feu par la méthode de l'API DELETE, et que vous essayez ensuite de republier toutes les règles d'un projet de règles de pare-feu enregistré, la publication des règles échouera.

Solution : aucune.

Certaines versions de la série VM de Palo Alto Networks ne fonctionnent pas avec les paramètres par défaut de NSX Manager
Certains composants de NSX 6.1.4 désactivent par défaut le protocole SSLv3. Avant de procéder à la mise à niveau, vérifiez que toutes les solutions tierces intégrées à votre déploiement de NSX ne reposent pas sur la transmission SSLv3. Ainsi, certaines versions de la solution de la série VM de Palo Alto Networks requièrent la prise en charge de SSLv3. Vérifiez auprès de vos fournisseurs leurs exigences en matière de version.

L'interface utilisateur affiche l'erreur Échec de la publication du pare-feu malgré la réussite de la publication
Si Distributed Firewall est activé sur un sous-ensemble de clusters dans votre environnement et que vous mettez à jour un groupe de dispositifs utilisé dans une ou plusieurs règles actives de pare-feu, toute action de publication sur l'interface utilisateur affichera un message d'erreur contenant les identifiants des hôtes appartenant aux clusters là où le pare-feu NSX n'est pas activé.
Malgré les messages d'erreur, les règles seront publiées et appliquées avec succès sur les hôtes où Distributed Firewall est autorisé.
 
Solution : Contactez le support VMware pour supprimer les messages de l'interface utilisateur.

si vous supprimez la configuration du pare-feu en utilisant un appel d'API REST, vous ne pouvez pas charger et publier des configurations enregistrées.
Lorsque vous supprimez la configuration du pare-feu, une nouvelle section par défaut est créée avec un nouvel ID de section. Lorsque vous chargez un brouillon enregistré (portant le même nom de section mais un ID de section plus ancien), les noms de section entrent en conflit et provoquent l'affichage de l'erreur suivante :
Une valeur de clé en double viole une contrainte unique firewall_section_name_key
 
Solution : utilisez l'une des méthodes suivantes :

  • Renommez la section de pare-feu par défaut actuelle après le chargement d'une configuration enregistrée.
  • Renommez la section par défaut sur une configuration enregistrée chargée avant de la publier.

Lorsqu'une configuration IPFIX est activée pour Distributed Firewall, les ports de pare-feu dans l'interface de gestion ESXi pour NetFlow pour vDS ou SNMP peuvent être supprimés
Lorsqu'une adresse IP et un port de collecteur sont définis pour IPFIX, le pare-feu pour l'interface de gestion ESXi est ouvert dans la direction sortante pour les ports de collecteur UDP spécifiés. Cette opération peut supprimer la configuration de l'ensemble de règles dynamique sur le pare-feu de l'interface de gestion ESXi pour les services suivants s'ils avaient été précédemment configurés sur l'hôte ESXi :

  • Configuration du port du collecteur Netflow sur vDS
  • Configuration du port cible SNMP

Solution : pour rajouter les règles de l'ensemble de règles dynamique, vous devez actualiser les paramètres netFlow pour vDS dans vCenter Web Client. Vous devez également rajouter la cible snmp à l'aide de commandes snmp système esxcli. Cette intervention devra être répétée si l'hôte ESXi est redémarré après l'activation de la configuration IPFIX ou si le VIB esx-vsip est désinstallé de l'hôte.

Problèmes des commutateurs logiques

La création d'un nombre important de commutateurs logiques avec une simultanéité élevée en utilisant l'appel d'une API peut entraîner des échecs
Ce problème peut se produire si vous créez un nombre important de commutateurs logiques en utilisant l'appel d'API suivant :

POST https://<nsxmgr-ip>/api/2.0/vdn/scopes/scopeID/virtualwires

Il est possible que certains commutateurs logiques ne soient pas créés.
 
Solution : réexécutez l'appel d'API.

Problèmes de déploiement de services

Règle NSX NetX non publiée sur l'hôte lorsque le service sélectionné est un groupe de services
Lors de la création d'une règle de redirection L3 dans l'onglet des services de partenaire dans DFW, la sélection d'un groupe de services ne crée pas la règle correctement.

Solution : utilisez des services individuels lors de la création de la règle au lieu d'utiliser un groupe de services.

le statut de service de Data Security s'affiche comme étant actif, même lorsque la connectivité IP n'est pas établie.
Le dispositif de Data Security peut ne pas avoir reçu l'adresse IP de la part de DHCP ou être connecté à un groupe de ports incorrect.
 
Solution : vérifiez que le dispositif de Data Security reçoive l'IP de la part du pool DHCP/IP et qu'elle soit accessible au réseau de gestion. Vérifiez que le ping adressé au dispositif de Data Security a réussi à partir de NSX/ESX.

Les anciennes machines virtuelles de service ne fonctionnent pas
Les anciennes machines virtuelles de service qui avait été conservées sur des hôtes lors de la suppression d'hôtes de vCenter Server restent déconnectées et ne peuvent pas fonctionner lorsque l'hôte est rajouté au même système vCenter Server.
 
Solution : suivez les étapes ci-dessous :

  1. Déplacez l'hôte du cluster protégé à un cluster non protégé ou à l'extérieur de tous les clusters. Cela désinstallera les machines virtuelles de service de l'hôte.
  2. Supprimez l'hôte de vCenter Server.

Problèmes avec Service Insertion

la suppression des règles de sécurité via REST affiche une erreur
Si un appel d'API REST est utilisé pour supprimer les règles de sécurité créées par Service Composer, l'ensemble de règles correspondant n'est pas réellement supprimé dans le cache du profil du service, ce qui entraîne une erreur ObjectNotFoundException.
 
Solution : aucune.

la stratégie de sécurité configurée comme une plage de ports entraîne la non synchronisation du pare-feu.
La configuration des stratégies de sécurité comme plage de ports (par exemple, « 5900-5964 ») entraînera la non synchronisation du pare-feu avec une erreur NumberFormatException
 
Solution : Vous devez configurer les règle de sécurité de pare-feu sous la forme d'une liste de ports de protocole séparés par des virgules.

Problèmes résolus

Découvrez les problèmes résolus dans les versions 6.1.7, 6.1.6, 6.1.5, 6.1.4, 6.1.3, 6.1.2, 6.1.1, 6.1.0.

Les problèmes suivants ont été résolus dans la version 6.1.7 :

  • Ce correctif résout une vulnérabilité de validation d'entrée critique qui existe lorsque SSL-VPN est activé.
    Cette vulnérabilité peut permettre à un personne malveillante distante d'accéder à des informations sensibles. La version 6.1.7 fournit ce correctif de sécurité.

  • Problème résolu 1660928 : Erreur d'utilisation PANIC dans dlmalloc
    Message d'erreur « PANIC Usage error in dlmalloc » (Erreur d'utilisation PANIC dans dlmalloc) lors de l'appel de Netx_GetConnInfoBrief dans le rappel d'état de restauration. Ce problème a été corrigé dans NSX 6.1.7.

Les problèmes suivants ont été résolus dans la version 6.1.6 :

  • Correctif de sécurité visant à éliminer la vulnérabilité glibc CVE-2015-7547
    La version 6.1.6 fournit un correctif de sécurité pour résoudre CVE-2015-7547.

  • Les sockets netcpa sont fermés et la machine virtuelle ne parvient pas à communiquer sur des VNI, des sous-réseaux
    Ce problème a été résolu en corrigeant l'utilisation dangereuse du thread boost::asio dans vmacore. Ce problème a été corrigé dans NSX 6.1.6. Consultez l'article 2137011 de la base de connaissances VMware.

  • Règles non transmises à l'hôte
    La planification des mises à jour de la liste de règles/IP DFW échouait à cause des limites de ressources de l'infrastructure des tâches dans NSX Manager. Un message d'erreur indiquait un échec de la mise en file d'attente des tâches pour les threads Notification de modification. Ce problème a été corrigé dans NSX 6.1.6.

  • Trafic interrompu pendant 50 secondes après le basculement HA sur ESG
    Ce problème était causé lorsque NSX ne parvenait pas à synchroniser les routes statiques parmi les nœuds NSX Edge HA. Ce problème a été corrigé dans NSX 6.1.6.

  • Problème de vérification de la santé IP_HASH de l'équilibrage de charge NSX
    Dans IPV6, lors de l'utilisation de l'algorithme de hachage source-ip, si le poids du serveur principal sélectionné est égal à 0, une réponse « service indisponible » est envoyée même s'il existe des serveurs principaux sains. Ce problème a été corrigé dans NSX 6.1.6.

  • Dans NSX NetX, impossible d'ajouter des règles pour rediriger le trafic vers des périphériques de partenaires
    Les clients ne pouvaient pas ajouter des règles de redirection de trafic à leurs ensembles de règles NetX. Par conséquent, les clients ne pouvaient pas rediriger le trafic vers des périphériques de partenaires. Cela affectait les règles qui utilisaient des ensembles d'adresses IP. Ce problème était causé par le traitement incorrect des plages d'adresses IP dans les règles NetX. Ce problème a été corrigé dans NSX 6.1.6.

  • Erreur NSX NetX dans DVFilterProcessSlowPathPackets
    L'utilisation de NSX NetX sans DFW se traduisait par une erreur dans DVFilter. Le message d'erreur complet indiquait l'erreur NetX PF (err=11,cr2=0x10) dans DVFilterProcessSlowPathPackets : VSIPDVFProcessSlowPathPackets : PFFilterPacket. Ce problème a été corrigé dans NSX 6.1.6. Consultez l'article 2144018 de la base de connaissances VMware.

  • Un paquet envoyé à LIF sans relais DHCP entraîne un PSOD
    L'hôte ESXi rencontre un PSOD si un paquet de monodiffusion DHCP est dirigé vers l'adresse IP d'un LIF sur lequel le relais DHCP est censé être activé, mais le relais DHCP n'est pas activé sur le LIF récepteur réel. Ce problème a été corrigé dans NSX 6.1.6. Consultez l'article 2144314 de la base de connaissances VMware.

  • Dans VXLAN en mode hybride, la déconnexion de contrôleur déclenche de façon incorrecte le passage au mode multidiffusion
    Ce problème a été corrigé dans NSX 6.1.6. Consultez l'article 2144457 de la base de connaissances VMware.

  • Erreur de publication DFW
    La modification et l'enregistrement de règles DFW en mode filtré peuvent se traduire par des règles non enregistrées et non publiées. Ce problème a été corrigé dans NSX 6.1.6. Consultez l'article 2141155 de la base de connaissances VMware.

Les problèmes suivants ont été résolus dans la version 6.1.5 :

  • La copie d'une machine virtuelle via vCloud Connector échoue lorsque l'acheminement passe par un équilibreur de charge NSX

    Ce problème a été corrigé dans NSX 6.1.5.

  • L'hôte ESXi peut perdre la connectivité réseau
    Un hôte ESXi peut perdre la connectivité réseau et rencontrer des problèmes de stabilité lorsque plusieurs messages d'erreur similaires au suivant sont journalisés :
    WARNING: Heartbeat: 785: PCPU 63 didn't have a heartbeat for 7 seconds; *may* be locked up.

    Ce problème a été corrigé dans NSX 6.1.5.

  • La connectivité du plan de contrôle ne fonctionne pas pour NSX Controller
    La connectivité du plan de contrôle peut ne pas fonctionner pour un contrôleur, cela entraîne l'affichage d'une erreur dans netcpa associée à txInProgress.

    Ce problème a été corrigé dans NSX 6.1.5.

  • Le client Web de NSX manager affiche l'erreur : Code 301002
    Description : lorsque vous accédez à NSX Manager > Surveiller > Événements système, Web Client affiche le message suivant : La configuration de filtre n'est pas appliquée à la vNIC. Code 301002.

    Ce problème a été corrigé dans NSX 6.1.5.

  • Après avoir mis à niveau NSX, Guest Introspection échoue à communiquer avec NSX Manager
    Après la mise à niveau de NSX 6.0.x vers NSX 6.1.x ou de NSX 6.0.x vers NSX 6.2 et avant que le service Guest Introspection soit mis à niveau, NSX Manager ne peut pas communiquer avec l'USVM de Guest Introspection.

    Ce problème a été corrigé dans NSX 6.1.5.

  • Des machines virtuelles se déconnectent pendant l'exécution de vMotion
    Des machines virtuelles se déconnectent pendant l'exécution de vMotion sous la version 6.0.8 avec le message : VISP heap depleted.

    Ce problème a été corrigé dans NSX 6.1.5.

  • Le retour des objets de domaine LDAP prend trop de temps ou ne se produit pas sur l'écran de sélection des objets de groupes de sécurité

    Ce problème a été corrigé dans NSX 6.1.5.

  • Mouvement de la souris retardé lors de l'affichage des règles FW
    Dans la section NSX Networking and Security de vSphere Web Client, le déplacement de la souris sur les lignes du tableau des règles du pare-feu peut afficher les résultats avec un retard de 3 secondes à chaque déplacement de la souris.

    Ce problème a été corrigé dans NSX 6.1.5.

  • Certaines règles de Spoofguard d'IP de NSX-v ne s'appliquent pas correctement.
    Certaines règles de Spoofguard d'IP de NSX-v ne s'appliquent pas correctement. L'instance est absente du groupe de sécurité de NSX-v et doit être ajoutée manuellement au groupe de sécurité.

    Ce problème a été corrigé dans NSX 6.1.5.

  • Dans le déploiement de VIO, certaines machines virtuelles nouvellement déployées semblent avoir reçu un port et une adresse IP valides, mais ne peuvent pas accéder au réseau

    Ce problème a été corrigé dans NSX 6.1.5.

  • L'une des instances de NSX Controller ne passe pas le rôle principal à d'autres contrôleurs lors de sa mise hors tension
    Normalement, lorsque NSX Controller assume le rôle principal des opérations et se prépare à la mise hors tension, il passe automatiquement ce rôle à d'autres contrôleurs. Si cette erreur se produit, le contrôleur ne peut pas passer le rôle à d'autres contrôleurs, son statut devient Interrompu, puis passe en mode déconnecté.

    Ce problème a été corrigé dans NSX 6.1.5.

  • L'impossibilité d'enregistrer NSX Manager 6.1.4 avec vCenter donne l'erreur suivante : NSX Management Service ne fonctionne pas

    Ce problème a été corrigé dans NSX 6.1.5.

  • Impossible de redéployer NSX Edge avec le service L2VPN configuré avec un certificat signé par une autorité de certification
    Impossible de redéployer ou de modifier la taille de NSX Edge avec le service L2VPN configuré avec un certificat signé par une autorité de certification, ou un certificat autosigné.

    Ce problème a été corrigé dans NSX 6.1.5.

  • La détection en masse de l'interface utilisateur de Service Composer génère le message « between 0 to 0 » (Entre 0 et 0)
    La suppression en masse de stratégies (environ 100) de l'interface utilisateur de NSX Service Composer génère le message « Il doit être compris entre 0 et 0 ». Vous pouvez ignorer ce message sans risque.

    Ce problème a été corrigé dans NSX 6.1.5.

  • La connexion à l'onglet NSX de vSphere Web Client est lente lors d'une authentification SSO soutenue par AD
    Pour les installations de NSX for vSphere qui utilisent l'authentification SSO pour AD, la connexion initiale de l'utilisateur à la section Networking and Security de NSX de vSphere Web Client peut prendre un certain temps.

    Ce problème a été corrigé dans NSX 6.1.5.

  • Les opérations en arrière-plan de la suppression de stratégies peuvent prendre un certain temps et utiliser beaucoup de ressources du processeur
    La suppression d'une stratégie réévalue toutes les stratégies restantes en arrière-plan. Cela peut prendre plus d'une heure pour les configurations qui disposent d'un grand nombre de stratégies, de groupes de sécurité et/ou de règles par stratégie.

    Ce problème a été corrigé dans NSX 6.1.5 et 6.2.

  • L'utilisation de CPU de NSX Manager est élevée après son ajout au domaine Active Directory
    L'utilisation de CPU de NSX Manager est élevée après son ajout au domaine Active Directory. Dans les journaux système de NSX Manager, plusieurs threads Postgres sont vus comme étant en cours d'exécution.

    Ce problème a été corrigé dans NSX 6.1.5.

  • Perte de connectivité après la suppression d'une interface logique (LIF) dans des installations avec un routage dynamique
    Un problème identifié dans le routeur logique NSX (Edge/DLR) lors de l'utilisation du routage dynamique (OSPF et BGP) provoque une perte de connectivité réseau après la suppression d'une LIF. Ce problème concerne les versions NSX 6.0.x jusqu'aux versions NSX 6.1.4.

    Dans les installations de NSX qui utilisent le routage dynamique, chaque LIF est associée à un ID d'index de règle de redistribution. Lorsqu'un utilisateur supprime une LIF dans une de ces installations, les ID d'index attribués à des LIF actives peuvent être modifiés. Cette modification d'index peut provoquer une perte temporaire de connectivité réseau pour les LIF dont les ID d'index sont modifiés. Si la suppression des LIF est réalisée en série, les LIF concernées subiront une interruption de fonctionnement de 5 à 30 secondes. Si la suppression des LIF est réalisée en masse, les LIF concernées subiront une interruption de fonctionnement totale de 5 à 30 secondes.

    Ce problème a été corrigé dans NSX 6.1.5.

  • Toutes les tâches publiables en attente sont indiquées comme des échecs après le délai par défaut de 20 minutes.
    Les files d'attentes sont triées par dispositif NSX Edge et peuvent publier en parallèle pour différents dispositifs Edge. Les tâches publiables en attente sont exécutées dans l'ordre. Chaque tâche dure environ 3 à 4 secondes et 300 à 400 tâches sont réalisées en 20 minutes. Dans les cas où plus de 400 tâches à publier sont placées dans la file d'attente d'un dispositif Edge en peu de temps, et que le délai de publication de 20 minutes s'est écoulé en attendant l'exécution, les tâches sont considérées comme des échecs. NSX Manager répond à cet échec en restaurant la dernière configuration fonctionnelle connue, dans laquelle la publication vers Edge a réussi. Les applications ou les plug-ins qui envoient des mises à jour de configuration pour un dispositif Edge vers NSX Manager en mode rafale doivent vérifier l'état d'échec ou de réussite de la tâche à l'aide de l'identifiant associé à la tâche.

    Ce problème a été corrigé dans NSX 6.1.5.

  • Le bus de messages ne démarre pas après le redémarrage de NSX Edge
    Après le redémarrage d'une machine virtuelle Edge, le bus de messages ne démarre pas après avoir été mis sous tension et requiert un redémarrage supplémentaire.

    Ce problème a été corrigé dans NSX 6.1.5 et NSX 6.2.0.

  • NSX Manager ne fonctionne plus après l'exécution de la commande « write erase »
    Lorsque vous redémarrez NSX Manager après l'exécution de la commande « write erase », vous pouvez remarquer que NSX Manager ne fonctionne pas comme prévu. Par exemple, la commande setup peut être manquante dans l'interface de ligne de commande de NSX.

    Ce problème a été corrigé dans NSX 6.1.5 et NSX 6.2.0.

  • Syslog affiche le nom de l'hôte de NSX Manager sauvegardé sur NSX Manager restauré
    Supposons que le nom d'hôte d'un premier NSX Manager soit A et qu'une sauvegarde soit créée pour ce NSX Manager. Désormais un second NSX Manager est installé et configuré à la même adresse IP en tant qu'ancien gestionnaire à partir des documents de restauration-sauvegarde, mais le nom de l'hôte est B. La restauration s'exécute sur ce NSX Manager. Le NSX Manager restauré affiche le nom de l'hôte A à la suite de la restauration puis une nouvelle fois le nom de l'hôte B après le redémarrage.

    Ce problème a été corrigé dans NSX 6.1.5 et NSX 6.2.0.

Les problèmes suivants ont été résolus dans la version 6.1.4 :

  • Dans des configurations VXLAN avec l'association de cartes réseau sur des hôtes où le commutateur DVS contient 4 liaisons montantes de carte réseau physique (PNIC), une seule VMKNIC sur les 4 obtient l'adresse IP
    Dans NSX 6.1.3, lorsque vous configurez VXLAN avec un IP de port source d'association où le DVS contient 4 liaisons montantes de carte réseau physique (PNIC), NSX crée 4 VMKNIC sur l'hôte. En mode d'association, les quatre VMKNIC doivent recevoir l'adresse IP, mais à cause d'un problème dans NSX 6.1.3, une seule VMKNIC sur chaque hôte reçoit l'adresse IP.

    Ce problème a été corrigé dans NSX 6.1.4.

  • NSX Manager ne répond plus
    NSX Manager ne répond plus lorsqu'il ne parvient pas à reconnaître l'adaptateur réseau. Ce correctif remplace l'adaptateur réseau e1000 de vCNS Manager Appliance par un adaptateur vmxnet3. Dans les nouvelles installations de vCNS 5.5.4.1 et versions ultérieures, ce correctif est automatiquement appliqué. Si vous effectuez la mise à niveau de vCNS 5.5.x vers NSX 6.1.4 ou version ultérieure, vous devez appliquer le correctif manuellement comme expliqué dans l'article 2115459 de la base de connaissances VMware.

    Ce problème a été corrigé dans NSX 6.1.4.

  • Problème résolu 1443458 : Dans les installations avec plusieurs clusters vSphere, les hôtes peuvent disparaître de l'onglet d'installation
    Dans les installations avec plusieurs clusters vSphere, l'écran de préparation de l'hôte dans NSX Manager peut prendre environ 3 minutes pour charger tous les clusters. Les hôtes peuvent disparaître de la fenêtre temporairement.

    Ce problème a été corrigé dans NSX 6.1.4.

  • Problème résolu 1424992 : L'onglet NSX Networking and Security de vSphere Web Client peut afficher une erreur de délai d'attente du service de données lorsqu'un magasin Active Directory volumineux est utilisé
    Dans les installations de NSX avec vSphere 6.0, l'onglet NSX Networking and Security de vSphere Web Client peut afficher une erreur de délai d'attente du service de données lorsqu'un magasin Active Directory volumineux est utilisé. Il n'existe pas de solution. Rechargez Web Client dans votre navigateur.

    Ce problème a été corrigé dans NSX 6.1.4.

  • Les machines virtuelles connectées à un commutateur logique et un routeur distribué VMware NSX for vSphere obtiennent une bande passante et un débit très faibles
    Ce correctif résout le problème couvert par l'article 2110598 de la base de connaissances VMware.

    Ce problème a été corrigé dans NSX 6.1.5.

  • Problème résolu 1421287 : L2VPN tombe en panne lors de l'envoi d'une requête Ping à l’adresse IP de diffusion. L'interface tap0 tombe en panne sur une instance Edge autonome.
    Lors de l'envoi d'une requête Ping à l’adresse de diffusion, les adresses MAC sont apprises, mais le tunnel L2VPN tombe en panne. L'interface tap0 tombe en panne lorsque l'instance d'Edge apprend un grand nombre d'adresses MAC.

    Ce problème a été corrigé dans NSX 6.1.4.

  • Utilisation intensive du CPU par NSX Manager pendant les mises à jour de l'inventaire vCenter
    Le provisionnement de règles de pare-feu impliquant un grand nombre de groupes de sécurité nécessite de nombreuses connexions à la base de données Postgres interne. L'exécution simultanée de plusieurs threads du processeur peut entraîner une utilisation élevée du processeur pendant une longue durée sur le serveur NSX Manager.

    Ce problème a été corrigé dans NSX 6.1.4.

  • Temps de chargement de NSX Manager longs sur les grands comptes de domaine
    Lorsque des utilisateurs du domaine disposant d'un grand nombre de groupes se connectent à vSphere Web Client, l'accès à l'interface de NSX Manager est extrêmement long.

    Ce problème a été corrigé dans NSX 6.1.4.

  • Correctifs de résolution des vulnérabilités CVE-2014-6593 « Skip-TLS » et CVE-2015-0204 « FREAK » (dénommées collectivement vulnérabilités « SMACK »)
    Ces correctifs résolvent des problèmes aussi appelés généralement vulnérabilités « SMACK ». Cela inclut la vulnérabilité « FREAK », qui affecte les clients utilisant OpenSSL en permettant de les tromper à l'aide de suites de chiffrement semblables à celles utilisées pour l'exportation. Les clients VPN SSL ont été mis à jour avec OpenSSL version 1.0.1L pour résoudre cela. OpenSSL sur NSX Edge a également été mis à jour vers la version 1.0.1L.
     
    Ce correctif résout également la vulnérabilité « Skip-TLS ». Le module JRE Oracle (Sun) est mis à jour vers la version 1.7.0_75 (version 1.7.0 Update 75), car Skip-TLS affectait les versions de Java antérieures à Update 75. Oracle a répertorié les identifiants CVE résolus dans JRE 1.7.0_75 sur la page Oracle Java SE Critical Patch Update Advisory de janvier 2015.

  • Correctifs de résolution de la vulnérabilité CVE-2014-3566 « POODLE »
    La version 6.1.4 inclut des modifications permettant de résoudre la vulnérabilité CVE-2014-3566 (vulnérabilité SSLv3, aussi appelée « POODLE »). Les modifications incluent les éléments suivants :
    • Désactivation de SSLv3 par défaut sur NSX Manager (depuis la version 6.1.2). Pour réactiver la prise en charge de SSLv3 sur ce composant, contactez le support VMware.
    • Désactivation de SSLv3 par défaut sur l'équilibrage de charge NSX Edge (depuis la version 6.1.4). Pour réactiver la prise en charge de SSLv3 sur ce composant, consultez l'article 2116104 de la base de connaissances VMware.
    • Une nouvelle méthode API qui vous permet de désactiver et de réactiver SSLv3 sur VPN SSL NSX Edge (depuis la version 6.1.4). Pour désactiver et réactiver la prise en charge de SSLv3 sur ce composant, consultez l'article 2115871 de la base de connaissances VMware.
    • Mise à jour de la bibliothèque SSL du système NSX Edge vers OpenSSL 0.9.8zc.

Les problèmes suivants ont été résolus dans la version 6.1.3 :

  • Les machines virtuelles perdent la connectivité aux réseaux qui sont connectés via des configurations de routeurs logiques distribués valides
    Cela se produisait en raison d'une erreur qui empêchait NSX Manager d'être mis à jour avec le dernier état de NSX Controller. Pendant cette condition d'erreur, NSX ne pouvait pas synchroniser l'état SSL (<controllerConfig><sslEnabled>true/false</sslEnabled></controllerConfig>) vers l'hôte ESX après un redémarrage de NSX Manager.

    Ce problème a été résolu dans NSX 6.1.3.

  • impossible de mettre les contrôleurs NSX for vSphere à niveau à partir de vCNS 5.0.x ou 5.1.x
    Si le chemin de migration vCNS vers NSX for vSphere démarrait à partir de la version 5.0.x ou 5.1.x de vCNS, le déploiement du NSX for vSphere Controller échouait en raison des modifications des schémas de base de données effectuées au rythme des mises à jour.

    Ce problème a été résolu dans NSX 6.1.3.

  • l'installation du VIB / la préparation de l'hôte échouait lorsque l'hôte ESXi était configuré pour le mode de verrouillage
    La préparation de l'hôte et l'installation des VIB VXLAN échouaient lorsque l'hôte ESXi était configuré pour le mode de verrouillage.

    Ce problème a été résolu dans NSX 6.1.3.

  • Validation de certificat de serveur pour les clients Linux et OS X VPN SSL
    Nous avons pris en compte les commentaires de nos clients et amélioré notre gestion de la relation d’approbation pour nos clients SSLVPN Mac et Linux. Désormais, nous utilisons des outils standard disponibles sur ces plateformes afin d'établir de meilleures relations d’approbation avec notre serveur SSLVPN. Le client VPN Windows profite déjà du magasin d'approbations de la plateforme s'il est installé alors que « Vérifier les certificats » est activé. Pour plus d'informations, consultez le Guide d'administration de NSX.

    Ce problème a été résolu dans NSX 6.1.3.

  • sur toutes les passerelles de services NSX Edge où OSPF était activé, la contiguïté OSPF n'était pas établie et sa négociation était bloquée à l'état bilatéral
    La contiguïté OSPF échouait et restait bloquée à l'état bilatéral.
    Les protocoles de routage dynamique n'étaient pas pris en charge pour une exécution sur les sous-interfaces.

    Ce problème a été résolu dans NSX 6.1.3.

  • l'activation d'ECMP sur un routeur logique désactivait le pare-feu
    Lorsqu'ECMP était activé sur l'onglet Global Routing, le pare-feu était automatiquement désactivé.

    Ce problème a été résolu dans NSX 6.1.3.

  • la configuration du pontage de la couche 2 sur un routeur logique distribué échouait
    La configuration du pontage de la couche 2 sur un routeur logique distribué dans NSX for vSphere 6.1.2 échouait avec l'erreur Accès non autorisé de l'utilisateur vers l'objet edge-XX et la fonctionnalité edge.bridging. Consultez l'article 2099414 de la base de connaissances VMware pour obtenir plus de détails.

    Ce problème a été résolu dans NSX 6.1.3.

  • deux chemins à coûts différents installés dans la FIB
    Lorsque NSX Edge présente pour un réseau une route statique et découvre également une route dynamique pour la même route, la route statique est choisie plutôt que la route dynamique, car elle lui est préférable. Néanmoins, lorsque l'interface correspondant à la route statique était basculée, la FIB commettait une erreur et installait deux chemins vers ce réseau.

    Ce problème a été résolu dans NSX 6.1.3.

  • le VPN SSL Mac client pour OS X Yosemite affichait erreur d'authentification certificat
    Puisque Yosemite n'utilisait pas /Library/StartupItems/ pour démarrer, le script de démarrage VMware ne s'exécutait pas lors du démarrage de la machine.

    Ce problème a été résolu dans NSX 6.1.3.

  • échec de la publication de la règle du pare-feu dû à l'insertion de blancs.
    La publication de la règle du pare-feu échouait car le transfert des données IP insérait des blancs dans les plages IP générées lors de l'exclusion dans ces dernières de membres par les groupes de sécurité imbriqués.

    Ce problème a été résolu dans NSX 6.1.3.

  • les machines virtuelles rencontraient une interruption de réseau pouvant atteindre 30 secondes après leur migration d'un hôte ESXi à un autre par vMotion lorsque les règles du Distributed Firewall présentaient des groupes de sécurité dans les champs source et/ou destination
    Pour plus d'informations, consultez l'article 2096529 de la base de connaissances VMware.

    Ce problème a été résolu dans NSX 6.1.3.

  • L'interface utilisateur du pare-feu acceptait l'ensemble de règles IP du pare-feu avec espaces mais ne la publiait pas sur les hôtes
    Un ensemble de règles IP avec espaces intermédiaires tels que '10.10.10.2 ,10.10.10.3' était accepté dans l'interface utilisateur du pare-feu, sans être publié sur les hôtes.

    Ce problème a été résolu dans NSX 6.1.3.

  • le déploiement simultané d'un grand nombre de machines virtuelles entraînait un échec de connexion de l'adaptateur réseau
    HA abandonnait plusieurs tentatives de basculement pour les machines virtuelles après le déploiement et aucune donnée dvPort n'était chargée. Les machines virtuelles affectées devaient démarrer avec leurs adaptateurs réseau déconnectés.

    Ce problème a été résolu dans NSX 6.1.3.

  • l'ajout d'un commutateur logique à un groupe de sécurité échouait
    L'ajout d'un nouveau commutateur logique ou la modification d'un commutateur logique existant comme la valeur incluse ou exclue dans un groupe de sécurité Service Composer ne pouvait s'achever, et l'interface utilisateur semblait se bloquer.

    Ce problème a été résolu dans NSX 6.1.3.

  • impossible d'afficher les paramètres de la machine virtuelle à partir de Web Client si la machine virtuelle comportait des balises de sécurité.
    L'affichage des paramètres d'une machine virtuelle à partir de vSphere Web Client échouait pour les utilisateurs sans fonction NSX et affichait l'erreur code statut = 403, message statut = [Interdit] si la machine virtuelle comportait des informations de balises de sécurité.

    Ce problème a été résolu dans NSX 6.1.3.

Les problèmes suivants ont été résolus dans la version 6.1.2 :

  • Le filtre ARP de l'adresse IP de l'interface de transfert/liaison montante est absent de VDR
    Le filtre ARP de l'adresse IP de l'interface de transfert/liaison montante était absent de la machine virtuelle de contrôle de NSX Edge, ce qui a entraîné la réponse du routeur logique distribué de (DLR) NSX à des demandes que la machine virtuelle de contrôle aurait dû gérer.

    Activez OSPF. Ce problème a été corrigé dans NSX 6.1.2.

  • Des vNIC se font éjecter car la mémoire de segment ESXi est insuffisante
    Selon le nombre de filtres, de règles de pare-feu et de constructions de regroupement sur un hôte ESXi, la mémoire de segment allouée sur l'hôte peut être dépassée. Cela entraîne la déconnexion des vNIC.
    La mémoire de segment ESXi est passée à 1,5 Go dans cette version.

    Ce problème a été résolu dans NSX 6.1.2.

  • Lorsque des objets utilisés dans des règles de pare-feu sont renommés, le nouveau nom n'est pas reflété dans le tableau du pare-feu

    Ce problème a été résolu dans NSX 6.1.2.

  • Demande d'ajout d'un support pour l'authentification NTLM dans l'équilibrage de charge NSX Edge

    Ce problème a été résolu dans NSX 6.1.2.

  • Des licences de CPU NSX for vSphere sont affichées en tant que licences de machine virtuelle
    Les droits de CPU NSX for vSphere sont affichés en tant que droits de machine virtuelle dans l'onglet Licences vSphere. Par exemple, si un client dispose de licences pour 100 CPU, l'interface utilisateur affiche 100 VM.

    Ce problème a été résolu dans NSX 6.1.2.

  • Règle de refus implicite pour les filtres BGP créés sur Edge Services Gateway mais pas sur le routeur logique
    Lorsqu'un filtre voisin sortant BGP est configuré sur Edge Services Gateway, seuls les préfixes avec une stratégie d'acceptation explicite sont annoncés. Par conséquent, une règle de refus implicite est créée automatiquement. Sur un routeur logique, tous les préfixes sont annoncés sauf s'ils sont explicitement bloqués.

    Ce problème a été résolu dans NSX 6.1.2.

Le problème suivant a été résolu dans la version 6.1.1 :

  • Dispositifs NSX sensibles à la vulnérabilité de sécurité BASH Shellshock
    Ce correctif met à jour les bibliothèques Bash dans les dispositifs NSX pour résoudre plusieurs problèmes de sécurité critiques, couramment appelés Shellshock. Le projet Common Vulnerabilities and Exposures (cve.mitre.org) a attribué les noms CVE-2014-6271, CVE-2014-7169, CVE-2014-7186 et CVE-2014-7187 à ces problèmes.
    Pour corriger cette vulnérabilité, vous devez mettre à niveau tous les dispositifs NSX. Pour effectuer la mise à niveau, suivez les instructions du Guide d'installation et de mise à niveau de NSX.

    Ce problème a été résolu dans NSX 6.1.1.

Les problèmes suivants ont été résolus dans la version 6.1.0 :

  • Le basculement des services de cluster Microsoft ne fonctionne pas correctement avec des commutateurs logiques
    Lorsque des machines virtuelles envoient des sondes ARP dans le cadre du processus de détection des adresses en double (DAD), la couche de suppression de VXLAN ARP répond à la demande ARP. Cela provoque l'échec de l'acquisition d'adresse IP, ce qui conduit à l'échec du processus DAD.

    Ce problème a été résolu dans NSX 6.1.0.

  • La restauration de NSX Manager à partir de la sauvegarde ne s'effectue pas correctement
    Après la restauration de NSX Manager à partir de la sauvegarde, la récupération des canaux de communication avec la machine virtuelle de contrôle du routeur logique ne s'effectue pas correctement. De ce fait, les commutateurs logiques et les groupes de ports ne peuvent pas être connectés au routeur logique ou déconnectés de celui-ci.

    Ce problème a été résolu dans NSX 6.1.0.

  • La configuration de routage logique ne fonctionne pas dans un environnement sans état
    Lorsque vous utilisez des hôtes ESXi sans état avec NSX, le NSX Controller peut envoyer des informations sur la configuration du routage distribué aux hôtes avant la création du commutateur virtuel distribué. Cela crée un manque de synchronisation et provoque l'échec de la connectivité entre deux hôtes hébergés sur différents commutateurs.

    Ce problème a été résolu dans NSX 6.1.0.

  • L'activation de HA sur un routeur logique déployé fait perdre au routeur ses routes distribuées sur les hôtes ESXi
    L'instance du routeur logique est supprimée et recréée sur les hôtes ESXi dans le cadre du processus d'activation de HA. Une fois l'instance recréée, les informations de routage de la machine virtuelle de contrôle du routeur ne sont pas correctement resynchronisées. Cela fait perdre au routeur ses routes distribuées sur les hôtes ESXi.

    Ce problème a été résolu dans NSX 6.1.0.

  • La demande REST échoue avec l'erreur Erreur de serveur interne HTTP/1.1 500
    Lorsque l'authentification unique (SSO) n'est pas correctement configurée, tous les appels API REST échouent avec ce message, car NSX ne peut pas valider les informations d'identification.

    Ce problème a été résolu dans NSX 6.1.0.

  • Lors d'une navigation entre des périphériques NSX Edge, vSphere Web Client se bloque ou affiche une page vierge

    Ce problème a été résolu dans NSX 6.1.0.

  • Un routeur logique sur lequel HA est activé ne redistribue pas les routes après une mise à niveau ou un redéploiement
    Lorsque vous mettez à niveau ou redéployez un routeur logique sur lequel la haute disponibilité est activée, le routeur ne redistribue pas les routes.

    Ce problème a été résolu dans NSX 6.1.0.

  • Impossible de configurer OSPF sur plusieurs liaisons montantes NSX Edge
    Il n'est pas possible de configurer OSPF sur plusieurs liaisons montantes NSX Edge.

    Ce problème a été résolu dans NSX 6.1.0.

  • Erreur lors de la configuration de VPN IPSec
    Lorsque vous configurez le service VPN IPSec, le message d'erreur suivant peut s'afficher :
    [Ipsec] LocalSubnet : xxx.xxx.xx.x/xx est inaccessible. Il devrait être accessible via le routage statique ou un sous-réseau d'interfaces Edge interne.

    Ce problème a été résolu dans NSX 6.1.0.

  • Problèmes lors de la suppression d'agences EAM
    Pour supprimer correctement des agences EAM d'ESX Agent Manager (EAM), le dispositif NSX Manager qui a déployé les services correspondant aux agences EAM doit être disponible.

    Ce problème a été résolu dans NSX 6.1.0.

  • Aucun avertissement affiché lors de la suppression d'un commutateur logique utilisé par une règle de pare-feu
    Vous pouvez supprimer un commutateur logique même s'il est utilisé par une règle de pare-feu. La règle de pare-feu est marquée comme non valide, mais le commutateur logique est supprimé sans aucun avertissement indiquant que le commutateur est utilisé par la règle de pare-feu.

    Ce problème a été résolu dans NSX 6.1.0.

  • Un membre du pool d'équilibrage de charge affiche un message d'AVERTISSEMENT
    Même lorsqu'un membre du pool d'équilibrage de charge affiche un message d'AVERTISSEMENT, il peut toujours traiter le trafic. Vous pouvez ignorer ce message.

    Ce problème a été résolu dans NSX 6.1.0.

  • Impossible de configurer des interfaces non balisées pour un routeur logique
    L'ID VLAN de vSphere Distributed Switch auquel se connecte un routeur logique doit être différent de 0.

    Ce problème a été résolu dans NSX 6.1.0.

  • Le service VPN L2 avec IPV6 n'est pas pris en charge dans les versions NSX 6.1.x

    Ce problème a été résolu dans NSX 6.1.0.

  • Des règles de pare-feu utilisant des commutateurs logiques non valides en tant que source ou destination s'affichent
    Un commutateur logique peut être supprimé indépendamment de la règle de pare-feu. Étant donné qu'aucun message de confirmation ne s'affiche avant la suppression d'un commutateur logique, vous pouvez le supprimer sans réaliser qu'il est utilisé par une règle de pare-feu.

    Ce problème a été résolu dans NSX 6.1.0.

  • Après la mise à niveau de la version 5.5 vers la version 6.0.x, la connectivité VXLAN échoue si l'association LACP étendue est activée
    Lorsqu'un centre de données dispose d'au moins un cluster et que l'association LACP étendue est activée, cela peut affecter la communication entre deux hôtes dans l'un des clusters. Ce problème ne se produit pas lors de la mise à niveau de NSX 6.0.x vers NSX 6.1.

    Ce problème a été résolu dans NSX 6.1.0.

  • La configuration de la stratégie n'est pas mise à jour tant qu'aucune modification n'y est apportée

    Ce problème a été résolu dans NSX 6.1.0.

Historique de révision du document

  • 1 octobre 2015 : Première édition de NSX 6.1.5.
  • 22 novembre 2015 : Deuxième édition de NSX 6.1.5. Explication du problème de possibilité de blocage (1328589). Ce problème reste un problème connu tant qu'aucun correctif n'est fourni dans vSphere. Dans NSX 6.1.5 et 6.2.0, NSX ajoute des corrections pour le problème.
  • 4 mars 2016 : Première édition de NSX 6.1.6. Correctif de sécurité pour résoudre la vulnérabilité glibc.
  • 20 mai 2016 : Deuxième édition de NSX 6.1.6. Limites de niveau à niveau de 6.1.x notées.
  • 8 juin 2016 : Première édition de NSX 6.1.7.