NSX pour vSphere 6.1.3 | 23 mars 2015 | Build 2591148

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés

NSX vSphere 6.1.3 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.

Si vous effectuez une mise à niveau a partir de NSX 6.1.1, ou que vous n'avez pas Data Security dans votre environnement, reportez-vous au Guide d'installation et de mise à niveau de NSX pour les instructions de mise à niveau de cette version.

Si vous effectuez une mise à niveau à partir d'une version antérieure de NSX 6.1.1 et que vous avez Data Security dans votre environnement, suivez la procédure ci-dessous pour effectuer la mise à niveau dans cette version :

  1. Désinstallez Data Security de tous les clusters sur lesquels le service est installé.
  2. Effectuez une mise à niveau de NSX Manager vers la version 6.1.3. Reportez-vous au Guide d'installation et de mise à niveau de NSX pour plus d'informations.
  3. Installez ou mettez à niveau Guest Introspection et d'autres services sur les clusters appropriés.
  4. Installez Data Security sur les clusters appropriés.
  5. Mettez à niveau des composants restants. Reportez-vous au Guide d'installation et de mise à niveau de NSX pour plus d'informations.

 

Problèmes résolus

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

  • Problème 1407210 : le déploiement simultané d'un grand nombre de machines virtuelles provoque un échec de connexion de l'adaptateur réseau
    HA met fin à plusieurs tentatives de basculement de machines virtuelles suite au déploiement et aucune donnée dvPort n'est chargée. Les machines virtuelles affectées devaient démarrer avec leurs adaptateurs réseau déconnectés. Les machines virtuelles n'étaient pas protégées par HA, car l'indicateur cleanPowerOff n'était pas correctement défini sur la valeur True avant que la configuration de la machine virtuelle ne soit intégralement chargée. Ce problème se produit lorsque le processus hostd subit une charge importante.
  • Problème 1365993 : les machines virtuelles subissent une interruption du réseau pouvant durer 30 secondes après avoir été migrées avec vMotion d'un hôte ESXi à un autre lorsque les règles de Distributed Firewall utilisent des groupes de sécurité des champs Source et/ou Destination
    Lorsqu'une machine virtuelle est migrée avec vMotion sur un autre hôte, les règles et conteneurs du pare-feu sont envoyés vers l'hôte de destination afin que les sessions existantes puissent continuer de fonctionner. Dans le cadre de l'activité vMotion, vCenter envoie une adresse IP de machine virtuelle vide à NSX Manager, qui supprime l'adresse IP de la machine virtuelle des conteneurs du pare-feu. vCenter réapprend ensuite l'adresse IP et envoie une autre notification à NSX Manager, et le conteneur du pare-feu est mis à jour avec l'adresse IP appropriée. Le délai entre la suppression de l'adresse IP et le chargement de la nouvelle adresse entraîne l'application d'une règle non valide sur la machine virtuelle de l'hôte de destination, générant une perte de connexion.
  • Problème 1301660 : erreur affichée lors de la modification des scripts de connexion/déconnexion
    Lorsque vous modifiez un script de connexion ou de déconnexion, l'erreur suivante s'affiche :
    ObjectNotFoundException: core-services:202: L'objet requis : logon1.logoff est introuvable. Les identificateurs d'objets sont sensibles à la casse.
  • Problème 1312379 : des protocoles contigus peuvent apparaître ou non lorsqu'ils sont activés sur les sous-interfaces
    Pour des protocoles OSPF, il arrive souvent que des protocoles OSPF contigus n'apparaissent pas et soient bloqués de deux façons.
    Les protocoles de routage dynamique ne sont pas pris en charge sur les sous-interfaces.
  • L'activation du routage Equal-Cost Multi-Path (ECMP) sur un routeur logique désactive le pare-feu sur la machine virtuelle de contrôle du routeur
    Lorsqu'ECMP est activé dans l'onglet Routage global, le pare-feu est automatiquement désactivé.

Problèmes connus

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

Problèmes de mise à niveau et d'installation

Problème 1375343 : 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.

Problème 1396592 : la spécification de déploiement avec version doit être mise à jour vers la version 6.0.x si vous utilisez vCenter Server 6.0 et ESX 6.0.
Les partenaires disposant de solutions NetX enregistrées avec vCloud networking and Security doivent mettre à jour leur inscription pour inclure VersionedDeploymentSpec for 6.0.x à l'OVF correspondant.
Solution : si la configuration de base est la version 5.5.x avec vSphere 5.5 et si l'infrastructure est mise à niveau vers NSX avant vCloud Networking and Security, procédez comme suit :

  1. Mettez à jour vSphere de la version 5.5 à 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://engweb.eng.vmware.com/~netfvt/ovf/Rhel6-32bit-6.1svm/Rhel6-32bit-6.1svm.ovf</ovfUrl>
    <vmciEnabled>true</vmciEnabled>
    </versionedDeploymentSpec>
  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. Cliquez sur Page d'accueil sur vSphere Web Client.
    2. Cliquez sur Administration.
    3. Dans Solution, sélectionnez vCenter Server Extension.
    4. Cliquez sur vSphere ESX Agent Manager, puis sur l'onglet Gérer.
    5. Sur l'état d'agence en échec, cliquez avec le bouton droit et sélectionnez « Résoudre tous les problèmes ».

 

Problème 1393503 : après la mise à niveau de NSX vSphere de la version 6.0.7 vers la version 6.1.3, vShpere Web client se bloque à l'écran de connexion
Suite à la mise à niveau de VSM 6.0.7 vers la version 6.1.3, l'utilisateur pourra voir des exceptions s'afficher sur l'écran de connexion de l'interface utilisateur vSphere Web Client. L'utilisateur ne pourra plus se 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.

Problème 1402307 : 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.

Problème 1288506 : 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 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.

Problème 1278690 : 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.

Problème 1266433 : 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.

Problème 1169078 : 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. Sur vSphere Server, accédez à l'emplacement suivant :
    /var/lib/vmware/vsphere-client/vc-packages/vsphere-client-serenity
  2. Supprimez les dossiers suivants :
    com.vmware.vShieldManager-6.0.x.1546773
    com.vmware.vShieldManager-6.0.1378053
  3. Redémarrez le service vSphere Web Client.
Cela garantit le déploiement du dernier module du plug-in.

 

Problème 1088913 : 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.

Problème 1088913 : 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

Problème 1215460 : les groupes de services sont développés dans le tableau Edge Firewall lors de la mise à niveau de vCloud Networking and Security 5.5 vers NSX
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 : Suivez les étapes ci-dessous :

  1. Recréez les groupes de services dans l'onglet Groupement d'objets après la mise à niveau.
  2. Modifiez la colonne Service pour les règles de pare-feu concernées et pointez sur les groupes de services appropriés.

 

Problème 1088497 : 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, accédez à Accueil vCenter > Hôtes et clusters et redémarrez les hôtes qui affichent Redémarrage requis.

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.

 

Problème 1312562 : 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 de pare-feu Service Composer ne sont pas synchronisées après la mise à niveau vers NSX 6.1
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

Problème 1411125 : impossible d'activer une machine virtuelle invitée
Lorsque vous activez une machine virtuelle invitée, l'erreur « Toutes les machines virtuelles agent requises ne sont pas actuellement déployées » peut s'afficher.
Solution : suivez les étapes ci-dessous.

  1. Cliquez sur Page d'accueil sur vSphere Web Client.
  2. Cliquez sur Administration.
  3. Dans Solution, sélectionnez vCenter Server Extension.
  4. Cliquez sur vSphere ESX Agent Manager, puis sur l'onglet Gérer.
  5. Cliquez sur Résoudre.

 

Problème 1301627 : 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 acceptera 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

Problème 1386874 : NSX Manager n'apparaît pas après la mise à niveau de vSphere vers la version 6.0.
Du fait que vSphere 6.0 n'accepte pas le nom d'utilisateur racine, NSX Manager ne démarre pas si vous pouvez vous connecter en tant qu'utilisateur racine.
Solution : connectez-vous avec le nom d'utilisateur administrator@vsphere.local.

Problème 1317814 : ServiceComposer n'est pas synchronisé lorsque des modifications de la stratégie sont effectuées alors qu'une instance de ServiceManagers est en panne.
Ceci est dû au fait que des instances enregistrées de plusieurs services/ServiceManagers et des stratégies créées font référence à ces différents services. Lorsque des modifications sont effectuées dans ServiceComposer sur une telle stratégie lorsque que l'une des instances de ServiceManagers est en panne, les modifications échouent en raison de l'échec du rappel de l'instance de ServiceManager qui est en panne. Par conséquent, l'instance de ServiceComposer n'est pas synchronisée.
Solution : assurez-vous que l'instance de ServiceManger en question réponde, puis exécutez une synchronisation forcée à partir de ServiceComposer.

Problème 1070905 : 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.

Problème 1027066 : 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ème 1091117 : impossible de supprimer des services tiers après la restauration d'une sauvegarde de NSX Manager
Les déploiements de services tiers ne peuvent être supprimés de vSphere Web Client que si l'état restauré de NSX Manager contient l'enregistrement du service tiers
Solution : Effectuez une sauvegarde de la base de données de NSX Manager après que tous les services tiers ont été enregistrés.

Problèmes de NSX Edge

Problème 1399955 : la mise à niveau de NSX Edge autonome n'est pas prise en charge
Solution : l'utilisateur devra déployer un nouvel OVF Edge et reconfigurer les paramètres du dispositif.

Problème 1399863 : 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.

Problème 1395183 : la modification du script de connexion/déconnexion VPN Plus SSL ne fonctionne pas
Le script modifié est correctement appliqué sur l'interface utilisateur NGC mais pas sur la passerelle.
Solution : supprimez le script d'origine, puis ajoutez-le de nouveau.

Problème 1364996 : le client VPN SSL sur un ordinateur SSL pour le système d'exploitation X Yosemite affiche une erreur d'authentification du certificat
Du fait que Yosemite n'utilise pas /Library/StartupItems/ comme élément de démarrage, le script de démarrage de VMware ne s'exécute pas lorsque la machine démarre.
Solution : Suivez les étapes ci-dessous :

  1. Exécutez la commande suivante pour configurer kext-dev-mode
    sudo nvram boot-args="kext-dev-mode=1"
  2. Redémarrez la machine.
  3. Installez le client.

 

Problème 1278437 : 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 apprises dynamiquement
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.

Problème 1288487 : 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.

Problèmes 1265605 et 1265548 : 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.

Problème 1278728 : 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.

Problème 1275788 : lorsque l'optimisation de sortie est activée pour VPN L2, l'équilibrage 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.

Problème 1113491 : 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 dispositif 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.

Problème 1113755 : 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.

Problème 1089745 : 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.

Problème 1082549 : 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.

Problème 1088400 : 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.

Problème 1078618 : VPN SSL ne prend pas en charge les CRL (listes de révocation des certificats)
Vous pouvez ajouter une CRL à une instance de NSX Edge, mais cette CRL ne sera pas utilisée par VPN SSL.
Solution : Les CRL ne sont pas prises en charge, mais vous pouvez activer l'authentification utilisateur avec l'authentification du certificat client.

Problème 859909 : 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

Problème 1109671 : 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

Problème 1110295 : 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.