NSX pour vSphere 6.1 | 11 septembre 2014 | Build 2107742

Contenu des notes de mise à jour

Les notes de mise à jour couvrent les sujets suivants :

Nouveautés

NSX vSphere 6.1 inclut plusieurs nouvelles améliorations de fonctionnalité, d'opérations, de consommation et de renforcement.

  • Clusters NSX Edge hautement disponibles offrant des vitesses de liaison montante plus rapides
    Equal Cost Multi-Path (ECMP)
    sur NSX permet de créer des clusters NSX Edge hautement disponibles et distribués, fournit une connexion de liaison montante à bande passante élevée et garantit également une redondance active-active au niveau du périmètre de virtualisation réseau, le tout dans une solution entièrement logicielle. ECMP sur NSX Edge permet une bande passante agrégée verticale maximale de 80 GBits/s ainsi qu'un périmètre avec montée en puissance.
  • 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 NSX Distributed et les pare-feu Edge Firewall. Une nouvelle interface unifiée permet de configurer les pare-feu Distributed Firewall et Edge Firewall. L'intégration de NSX dans vCAC 6.1 permet des workflows d'automatisation de sécurité à intégrer dans l'automatisation du calcul. NSX 6.1 permet également de rediriger le trafic vers le réseau et d'utiliser les produits des partenaires de sécurité, tels que les pare-feu Next Generation Firewall et les services Intrusion Prevention Service.
  • Connectez plusieurs centres de données ou offrez des services Cloud hybrides dans Software Defined Datacenter (SDDC)
    VPN couche 2 sur NSX Edge
    VPN couche 2 sur NSX Edge permet aux entreprises de migrer des charges de travail, de consolider des centres de données ou de créer des niveaux d'application s'étendant 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 l'intégralité du centre de données
    Relais DHCP
    Le relais DHCP vous permet d'intégrer les services DHCP existants disponibles dans les centres de données physiques au sein de SDDC. Cela garantit une stratégie d'adressage IP cohérente et une gestion simplifiée des adresses IP dans l'intégralité du centre de données. NSX 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 dans NSX
    Pour permettre l'équilibrage de charge et une haute disponibilité pour les autres applications hébergées dans NSX, UDP et FTP, l'équilibrage de charge est désormais disponible dans NSX. Cela permet l'équilibrage de charge d'applications telles que syslog, NTP et DNS.
  • Protégez les investissements ADC (Application Delivery Controller) et tirez-en parti de manière transparente dans SDDC
    Intégration étroite avec les partenaires afin d'activer ADCaaS
    NSX 6.1 permet aux clients utilisant des ADC de partenaires NSX de protéger leurs investissements et de tirer parti de services ADC avancés de leurs meilleurs fournisseurs. Cette solution prête à l'emploi apporte une simplicité opérationnelle, des workflows intégrés, le déploiement automatique de ressources et un volet central de dépannage et de surveillance des ADC virtuels et physiques.
  • Services avancés de sécurité de l'hôte ou du réseau dans SDDC
    L'intégration avancée de partenaires à Service Composer prend en charge plusieurs services de sécurité, notamment des solutions qui comprennent plusieurs services réseau-hôte dans une stratégie unifiée.
  • 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.
    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.
    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.
    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.
    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.
    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.
    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.
    • 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.

       

    • 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.
    • La configuration du routage logique ne fonctionne pas dans un environnement sans état
      Lorsque vous utilisez des hôtes ESXi sans état avec NSX, le contrôleur NSX 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.
    • 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.
    • La demande REST échoue avec l'erreur Erreur de serveur interne HTTP/1.1 500
      Lorsque Single Sign-On (SSO) n'est pas correctement configuré, tous les appels d'API REST échouent avec ce message, car NSX ne peut pas valider les informations d'identification.
    • Lors d'une navigation entre des périphériques NSX Edge, vSphere Web Client se bloque ou affiche une page vierge
    • 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 High Availability est activé, le routeur ne redistribue pas les routes.
    • Impossible de configurer OSPF sur plusieurs liaisons montantes NSX Edge
      Il n'est pas possible de configurer OSPF sur plusieurs liaisons montantes NSX Edge.
    • 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.
    • 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.
    • 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.
    • 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 de vSphere Distributed Switch auquel se connecte un routeur logique doit être différent de 0.
    • Le service VPN L2 avec IPV6 n'est pas pris en charge dans cette version.
    • 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 utilisée. É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.
    • 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.
    • La configuration de la stratégie n'est pas mise à jour tant qu'aucune modification n'y est apportée.
    • 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.
    • 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.
    • Configuration du port du collecteur Netflow sur vDS
    • Configuration du port cible SNMP
  •  

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

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

    Problèmes connus

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

    Problèmes d'installation et de mise à niveau

    La mise à niveau du dispositif ne met pas à niveau la version ou la configuration de NSX Edge
    Les opérations autres que le redéploiement ou la mise à niveau qui nécessitent le déploiement d'une nouvelle machine virtuelle ou le remplacement d'une machine virtuelle existante (par exemple configuration de dimensionnement, de pool de ressources ou de banque de données) remplacent le dispositif par la dernière version disponible mais n'effectuent pas une mise à niveau complète.
    Solution : À la suite de la mise à niveau de NSX Manager, vous devez mettre à niveau NSX Edge avant de tenter l'une des opérations décrites ci-dessus.

    La mise à niveau de NSX Edge échoue si VPN L2 est activé sur Edge
    La mise à jour de la configuration VPN L2 5.x ou 6.x vers 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.

    La passerelle 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 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 ou 6.1, 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.

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

     

    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

    Les groupes de services sont développés dans le tableau Edge Firewall pendant la mise à niveau de vCloud Networking and Security 5.5 vers NSX
    Les groupes de services créés par l'utilisateur sont développés dans le tableau Edge Firewall pendant la mise à niveau ; c'est-à-dire que la colonne Service dans le tableau du pare-feu affiche tous les services 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 : Procédez comme suit :

     

    L'installation de Guest Introspection échoue avec une erreur
    Lors de l'installation de Guest Introspection sur un cluster, l'installation échoue avec l'erreur suivante :
    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 : Procédez comme suit.

     

    Si un profil de service créé dans la version 6.0.x est lié à la fois à un groupe de sécurité et à un groupe de port sécurisé ou un 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 a été réalisée à la fois sur un groupe de sécurité et un groupe de ports distribué ou un commutateur logique dans 6.0.x, les règles 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 : Procédez comme suit.

     

    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.

    Le serveur vSphere Web Client 5.5 redémarre et l'interface utilisateur devient inaccessible
    Si vous utilisez le dispositif vCenter Server ou exécutez vCenter Server sur une machine virtuelle, vous pouvez rencontrer des problèmes si le dispositif ou la machine virtuelle ne répond pas à certaines exigences.
    Solution : Vérifiez que le dispositif ou la machine virtuelle dispose d'une mémoire minimale de 12 Go et d'un processeur Intel ou AMD x64 comportant au moins deux cœurs logiques, chacun ayant une vitesse d'au moins 2 GHz.

    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 Guest Introspection sur un dispositif de partenaire via l'onglet Déploiements de services, vSphere Web Client peut afficher l'erreur ci-dessus. Cette erreur n'affecte pas l'installation. Elle peut donc être ignorée.

    Impossible de supprimer et de rajouter un hôte à un cluster protégé par Guest Introspection et des solutions de sécurité tierces
    Si vous supprimez un hôte d'un cluster protégé par Guest Introspection 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

    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 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
    Solution : Aucune.

    Protocoles de routage dynamique non pris en charge sur les sous-interfaces
    Solution : Aucune.

    L'ajout d'une route apprise par protocole comme route connectée produit un tableau FIB (Forwarding Information Base) local montrant à la fois des routes connectées et les routes dynamiquement apprises
    Si vous ajoutez une route déjà apprise via un protocole en tant que route connectée, le FIB local montre les routes connectées et les routes 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 disposant d'une sous-interface sauvegardée par un commutateur logique est supprimée via l'interface utilisateur de vCenter Web Client, le chemin de données risque de 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 de 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 :

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

    Règle de refus implicite pour les filtres BGP créés sur Edge Services Gateway mais pas sur un routeur logique
    Lorsqu'un filtre de voisin sortant BGP est configuré sur Edge Services Gateway, seuls les préfixes disposant d'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.
    Solution : Lors de la configuration du protocole BGP, spécifiez les préfixes qui doivent être abandonnés, même si un filtre sortant est créé.

    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 SNAT L4) 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, 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 actions suivantes.

    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, l'itinéraire statique n'est pas envoyé vers les hôtes.
    Solution : Spécifiez toujours une adresse Next Hop pour les itinéraires statiques.

    Impossible de traiter 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 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.

    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.

    Affichage d'une erreur lors de la modification des scripts d'ouverture ou de fermeture de session
    Lorsque vous modifiez un script d'ouverture ou de fermeture de session, l'erreur suivante s'affiche :
    ObjectNotFoundException: core-services:202: L'objet demandé : logon1.logoff est introuvable. Les identificateurs d'objets sont sensibles à la casse..
    Solution : Supprimez le script existant et un nouveau dont les paramètres sont modifiés.

    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.

    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

    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 : Effectuez l'une des actions suivantes :

     

    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 :

    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 de Guest Introspection

    D'anciennes machines virtuelles de service ne fonctionnent pas
    D'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 : Procédez comme suit