NSX pour vSphere 6.0.6 | 11 septembre 2014 | Build 2103699

Mis à jour le 11 septembre 2014

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés

NSX vSphere 6.0.6 contient un correctif NSX Edge qui corrige une vulnérabilité susceptible d'entraîner la divulgation d'informations critiques. VMware vous recommande d'effectuer une mise à niveau vers cette version.

Spécifications du système et installation

Pour obtenir des informations sur les spécifications système et l'installation, reportez-vous au Guide d'installation et de mise à niveau de NSX .

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.

 

Problèmes connus

Les problèmes connus sont classés comme suit :

Problèmes d'installation et de mise à niveau

La mise à niveau de NSX Edge échoue, mais NSX Manager ne restaure pas les dispositifs Edge à l'ancienne version
Si la mise à niveau de NSX Edge échoue et si le système n'est pas restauré, vous pouvez rencontrer des perturbations réseau et ne pas être en mesure de gérer le dispositif Edge. Solution : Redéployez NSX Edge, puis procédez à nouveau à la mise à niveau du dispositif Edge.

Le client VPN SSL doit être désinstallé et réinstallé après la mise à niveau
Après la mise à niveau vers vShield 6.0.5, vous devez désinstaller le client VPN SSL, puis le réinstaller. Pour installer le client le plus récent, accédez à https:// ssl-vpn-ip-address, où ssl-vpn-ip-address est l'adresse IP de la liaison montante attribuée à l'interface Edge sur laquelle le service VPN SSL est configuré pour écouter.

Le MTU de vSphere Distributed Switch n'est pas mis à 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 une 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

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 : Procédez comme suit.

  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.

 

Après la mise à niveau de NSX 6.0 vers la version 6.0.x, les instances de NSX Edge ne sont pas répertoriées sur l'interface utilisateur
Lorsque vous procédez à la mise à niveau de NSX 6.0 vers NSX 6.0.x, le plug-in vSphere Web Client n'est pas correctement mis à niveau. 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 : Procédez comme suit.

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

Les licences NSX vSphere CPU s'affichent comme des licences de VM
Les droits d'accès NSX vSphere CPU s'affichent comme des droits d'accès VM dans l'onglet Licences vSphere. Par exemple, si un client dispose de licences pour 100 CPU, l'interface utilisateur affiche 100 VM.
Solution : Aucune.

Une demande REST échoue avec l'erreur HTTP/1.1 500 Internal Server Error
Lorsque Single Sign-On (SSO) n'est pas correctement configuré, tous les appels à l'API REST échouent avec ce message, car NSX ne peut pas valider les informations d'identification.
Solution : Configurez SSO comme indiqué dans le Guide d'administration de NSX.

 

Lors de la navigation entre des périphériques NSX Edge, vSphere Web Client se bloque ou affiche une page vide
Solution : Redémarrez le navigateur.

vSphere Web Client affiche l'erreur : Impossible d'effectuer cette opération. Pour plus d'informations, consultez le journal des événements
Lorsque vous installez des services tels que vShield Endpoint sur un dispositif de partenaire via l'onglet Déploiements de services, vSphere Web Client peut afficher l'erreur ci-dessus. Vous pouvez ignorer cette erreur.

Impossible de supprimer et de rajouter un hôte à un cluster protégé par vShield Endpoint et des solutions de sécurité tierces
Si vous supprimez un hôte d'un cluster protégé par vShield Endpoint et 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èmes du gestionnaire NSX

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.
Solution : Après la restauration de la sauvegarde du dispositif NSX Manager, redémarrez toutes les machines virtuelles de contrôle du routeur logique.

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.

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

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 récréé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.
Solution : Redémarrez la machine virtuelle de contrôle du routeur logique après avoir activé HA pour restaurer les routes.

Un routeur logique NSX 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 NSX sur lequel High Availability est activé, le routeur ne redistribue pas les routes.
Solution : Après avoir mis à niveau le routeur logique NSX, resynchronisez-le avec NSX Manager en sélectionnant Plus d'actions > Forcer la synchronisation.

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.

Impossible de configurer des interfaces non balisées pour un routeur logique
L'ID VLAN du vSphere Distributed Switch auquel se connecte un routeur logique (distribué) doit être différent de 0.
Solution : Créez uniquement des interfaces balisées.

Des routes VDR LIF sont annoncées par ESG en amont même lorsqu'OSPF VDR est désactivé
ESG (Edge Services Gateway) en amont continue à annoncer des LSA externes OSPF extraites des interfaces VDR connectées, même lorsqu'OSPF VDR 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 une passerelle, 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 requis pour déclencher la veille dépasse le délai d'attente normal de redémarrage et entraîne la suppression des routes extraites des OSPF voisins de leur tableau 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.

La configuration HA échoue si vous choisissez la même interface pour la gestion de HA et la configuration de VPN L2
Si la couche VPN L2 est activée sur une instance de NSX Edge et que vous tentez d'activer HA sur la même instance de NSX Edge, la configuration peut échouer. Il existe deux cas dans lesquels cette situation peut se produire :

  1. Si vous sélectionnez manuellement la même interface pour la gestion de HA et la configuration de VPN L2.
  2. Si vous sélectionnez la configuration automatique de HA, auquel cas HA peut finir par utiliser la même interface que VPN L2.
Solution : Sélectionnez une interface dédiée à la gestion de HA différente de l'interface de VPN L2 VPN.

 

Des dispositifs sur lesquels VPN L2 est activé peuvent donner des résultats incohérents si la fonctionnalité High Availability est activée.
Solution : N'utilisez pas VPN L2 VPN avec la fonctionnalité High Availability.


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 des dispositifs Edge internes.
Solution : Ajoutez manuellement le routage statique pour le sous-réseau local.

 

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.

Impossible d'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.

Un client VPN SSL dont le proxy est activé dans Utiliser les paramètres Safari ne fonctionne pas sur des ordinateurs Mac
Si vous sélectionnez un proxy dans les paramètres Safari du client VPN SSL sur un ordinateur Mac, il est automatiquement désélectionné. Par conséquent, vous ne pourrez pas vous connecter à cet ordinateur Mac via le client VPN SSL.
Solution : Sur un ordinateur Mac, utilisez le protocole SOCKS version 4/5 ou HTTP plutôt que le paramètre Safari.

Impossible de télécharger les journaux de support technique de NSX Edge avec Google Chrome 29
Solution : Utilisez Google Chrome version 30 ou ultérieure.

Impossible de modifier un module d'installation VPN-Plus SSL
Lorsque vous modifiez un module d'installation VPN-Plus SSL, les modifications ne sont pas appliquées au module.
Solution : Suivez les étapes ci-dessous :

  1. Supprimez le module d'installation au lieu de l'éditer et créez un nouveau module d'installation avec d'autres paramètres.
  2. Si un client VPN SSL est installé sur l'ordinateur, supprimez-le.
  3. Redémarrez l'ordinateur.
  4. Installez le nouveau module d'installation.

 

Problèmes des commutateurs logiques

Problèmes lors de la suppression des agences EAM
Pour supprimer correctement des agences EAM du gestionnaire d'agent ESX (EAM), il est nécessaire que le gestionnaire NSX ayant déployé les services correspondants aux agences EAM soit disponible.
Solution : Assurez-vous que le gestionnaire NSX est disponible.

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.

Problèmes avec vShield Endpoint

Après un déploiement, la machine virtuelle du service vShield Endpoint ne parvient pas à communiquer avec NSX Manager
Solution : Procédez comme suit.

  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èmes résolus

Les problèmes suivants ont été résolus dans la version 6.0.6.

  • Le basculement du service de cluster Microsoft ne fonctionne pas correctement avec des commutateurs logiques
    Lorsque les 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.

Les problèmes suivants ont été résolus dans la version 6.0.5.

  • Là où cela est nécessaire, OpenSSL 1.0.1 est mis à jour vers la version 1.0.1h afin de résoudre les problèmes CVE-2014-0224, CVE-2014-0198, CVE-2010-5298 et CVE-2014-3470.
  • Là où cela est nécessaire, OpenSSL 0.9.8 est mis à jour vers la version openssl-0.9.8za afin de résoudre les problèmes CVE-2014-0224, CVE-2014-0198, CVE-2010-5298 et CVE-2014-3470.
  • Une machine virtuelle perd la connectivité réseau au cours de la migration entre des pools de ressources, des clusters ou des vApp.
    Pour plus d'informations, voir Une machine virtuelle perd la connectivité pendant la migration entre les pools de ressources, les clusters ou les vApps dans vCloud Networking and Security 5.1.4, 5.5.2 et NSX pour vSphere 6.0.4.
  • La mise à niveau de NSX Edge échoue avec un message d'erreur indiquant que le port 22 est en cours d'utilisation
    Si vous mettez à niveau un dispositif NSX Edge avec un équilibrage de charge, si SSH est activé et si le serveur virtuel de l'équilibrage de charge est configuré pour écouter sur un port dont le numéro contient le chiffre « 22 » (par exemple, le port 22 ou 8228), la mise à niveau échoue.
  • Le profil du service NSX/PAN n'est pas appliqué aux commutateurs logiques
    Lorsque vous sélectionnez un commutateur logique en tant qu'objet appliqué du service Palo Alto NGFW (PAN), le profil du service n'est pas appliqué.
  • Un débordement de la pile sur NSX Manager peut entraîner le redémarrage de NSX Manager
    La génération des journaux de support technique de vShield Edge peut entraîner un débordement de la pile et le redémarrage de NSX Manager.
  • Lorsqu'une machine virtuelle ou un hôte est déplacé d'un pool de ressources à un autre ou d'un cluster à un autre, la machine virtuelle peut perdre la connectivité
    Lorsqu'une machine virtuelle est déplacée entre des pools de ressources ou des clusters, sa variable PATH peut ne pas être correctement définie. Cela peut entraîner la perte de connectivité de la machine virtuelle.
  • Si la connexion à la carte réseau virtuelle d'une machine virtuelle est fréquemment activée et désactivée, l'hôte peut se bloquer
  • Si vous configurez VSphere Web Client sur le port 443, vous ne pouvez pas accéder à l'onglet Networking and Security de vSphere Web Client
    Si vSphere Web Client est configuré sur le port 443, les appels proxy de vSphere Web Client à NSX Manager ne passent pas, car le canal AMF n'est pas configuré.
  • vMotion échoue pour une machine virtuelle invitée lorsque des services de partenaires sont déployés
  • La suppression de VXLAN ARP peut échouer pour certains modèles de trafic
    Lors de l'apprentissage du plan de données des entrées ARP, VXLAN met à jour toutes les entrées existantes du cache ARP. Ainsi, une entrée ARP qui attend la réponse du contrôleur peut être alimentée plutôt par le trafic du plan de données, même si cette entrée n'aboutit pas dans le contrôleur.