NSX for vSphere 6.1.4 | 7 mai 2015 | Build 2691049

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés

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 à :

 

NSX vSphere 6.1.4 est compatible avec vSphere 6.0. Néanmoins, les nouvelles fonctions de vSphere ajoutées à vSphere 6.0 n'ont pas été testées avec NSX vSphere. Ces nouvelles fonctions de vSphere ne doivent pas être utilisées dans un environnement où NSX vSphere est installé, car elles ne sont pas prises en charge. Pour obtenir une liste des limitations spécifiques à NSX vSphere concernant vSphere 6.0, reportez-vous à l' article 2110197 de la base de connaissances VMware.

Spécifications du système et installation

La Matrice d'interopérabilité des produits VMware fournit des détails sur la compatibilité des versions en cours et précédentes des composants et produits VMware, tels que VMware vCenter Server.

Les versions 5.5.x, 6.0.x et 6.1.x peuvent être mises à niveau directement vers 6.1.4.

Pour mettre à niveau NSX vSphere vers la version 6.1.4, suivez les étapes ci-dessous :

  1. Mettez à niveau NSX Manager et tous les composants NSX vers la version 6.1.4. Reportez-vous au Guide d'installation et de mise à niveau de NSX pour plus d'informations.
    Si vous ne souhaitez pas mettre à niveau vCenter Server et ESXi vers la version 6.0, vous en avez terminé avec la procédure de mise à niveau.
    Si vous souhaitez mettre à niveau vCenter Server et ESXi, effectuez les étapes restantes de cette procédure.
  2. Mettez vCenter Server à niveau vers la version 6.0. Reportez-vous à la documentation VMware vSphere 6.0 pour plus d'informations.
  3. Pour effectuer la mise à niveau sans interruption de service, repérez dans votre environnement un sous-ensemble d'hôtes pour lesquels vous pouvez commencer la mise à niveau. Placez ces hôtes en mode de maintenance.
  4. Mettez ESXi à niveau vers la version 6.0. Reportez-vous à 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 démarrent, NSX Manager envoie les VIB ESXi 6.0 vers les hôtes.
  5. 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, redémarrez les hôtes une deuxième fois.
    Les VIB NSX pour ESXi 6.0 sont maintenant activés.
  6. Mettez fin au mode de maintenance sur les hôtes mis à niveau.
  7. Répétez les étapes 3 à 6 pour le sous-ensemble d'hôtes suivant jusqu'à ce que tous les hôtes de votre environnement soient mis à jour.

Problèmes résolus

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

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

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.

Problème résolu 1406377 : 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 de CPU peut maintenir une charge élevée du CPU sur le serveur NSX Manager.

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

Problème résolu 1409714/1405945 : 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.

Problème résolu 1361424 : 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 VPN SSL NSX Edge (depuis la version 6.1.4). Pour réactiver la prise en charge de SSLv3 sur ce composant, reportez-vous à l' article 2115871 de la base de connaissances 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, reportez-vous à l' article 2116104 de la base de connaissances VMware.
  • Désactivation de SSLv3 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.
  • Mise à jour de la bibliothèque SSL du système vShield Edge vers OpenSSL 0.9.8zc.

 

Problème résolu 1363274 : 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 vShield Manager. Cela a été corrigé dans NSX 6.1.3.

Problèmes connus

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

Problèmes de mise à niveau et d'installation

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 vSphere 6.1.3, vSphere Web Client n'affiche pas l'onglet Networking and Security.
Solution : Lorsqu'une sauvegarde de NSX Manager est restaurée, vous êtes déconnecté du gestionnaire de dispositif. 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.
La solution de contournement n'est possible que si les partenaires sont à 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>/servicedeploymentspec/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 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 vSphere passée de la version 6.0.7 à la version 6.1.3, vSphere Web Client se bloque sur l'écran de connexion
Une fois la mise à niveau de NSX Manager passée de la version 6.0.7 à la version 6.1.3, des exceptions sont affichées sur l'écran de connexion 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 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 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 vSphere 6.0.5 ou version ultérieure, ce qui entraîne l'échec de la mise à niveau.
Solution : Importez un nouveau certificat SSL avec une taille de clé prise en charge avant de procéder à la mise à niveau.

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 : Suivez les étapes ci-dessous.

  1. Dans vCenter, cliquez sur Contenu.
  2. Dans la colonne valeur, cliquez sur ExtensionManager.
  3. Recherchez [extensionList["com.vmware.vShieldManager"] et copiez la chaîne.
  4. Dans la section Méthodes, cliquez sur UnregisterExtension.
  5. Dans le champ Valeur, collez la chaîne que vous avez copiée à l'étape 3.
  6. Cliquez sur Appeler la méthode.

Cela garantit le déploiement du dernier module du plug-in.

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 accidentellement abandonné.
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

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 ; p.ex. 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. Lier 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

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.

 

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.

Problèmes du gestionnaire NSX

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>

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.
Solution : Le nom de l'hôte de deuxième NSX Manager doit être configuré pour être le même que celui de NSX Manager sauvegardé.

L'import d'un certificat signé par CA nécessite un redémarrage de NSX Manager avant de devenir efficace
Lorsque vous importez un certificat NSX Manager signé par une autorité de certification, le nouveau certificat importé n'est pas actif tant que NSX Manager n'est pas redémarré.
Solution : Redémarrez NSX Manager en vous connectant au dispositif virtuel NSX Manager ou en utilisant la commande CLI reboot.

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.

Service Composer n'est pas synchronisé lorsque des modifications de la stratégie sont effectuées alors qu'une instance de Service Managers est en panne.
Ceci est dû au fait que des instances enregistrées de plusieurs services/gestionnaires de service et des stratégies créées font référence à ces différents services. Si des modifications sont effectuées dans Service Composer sur une telle stratégie lorsque que l'une des instances de Service Managers est en panne, les modifications échouent en raison de l'échec du rappel de l'instance de Service Manager qui est en panne. Cela empêche la synchronisation de Service Composer.
Solution : Vérifiez que le gestionnaire de service réponde puis publiez une synchronisation forcée à partir de Service Composer.

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 de NSX Edge

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 dynamiquement apprises. La route dynamiquement apprise 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 Content.
  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</portKeyv <!--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 lorsqu'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 lorsqu'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 qu'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 qu'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

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 un groupe de dispositifs à jour, 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 dans 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

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.