Notas de la versión de VMware NSX for vSphere 6.2.8

|

VMware NSX for vSphere 6.2.8   |   Publicado el 6 de julio de 2017  |   Compilación 5901733

Consulte el Historial de revisión de este documento.

Contenido de las notas de la versión

Las notas de la versión contienen los siguientes temas:

Novedades

Correcciones de errores críticos: Esta versión incluye una serie de correcciones de errores críticos y actualizaciones de seguridad. Además, se mejoró la información de registro relacionada con VTEP. Para obtener más información, consulte la sección Problemas resueltos.

 

Consulte las novedades y los cambios de NSX 6.2.7, 6.2.6, 6.2.5, 6.2.4, 6.2.3, 6.2.2, 6.2.1 y 6.2.0.

Instalación, versiones y requisitos del sistema

Nota:

  • En la siguiente tabla, se muestran las versiones recomendadas del software de VMware.  Estas recomendaciones son generales y no deben sustituir ni anular las recomendaciones específicas del entorno.

  • Esta información está actualizada según la fecha de publicación de este documento.

  • Consulte la matriz de interoperabilidad de productos VMware para conocer las versiones mínimas admitidas de NSX y de otros productos de VMware. VMware determina las versiones mínimas admitidas basándose en pruebas internas.

Producto o componente Versión recomendada
NSX for vSphere

VMware recomienda la versión más reciente de NSX for vSphere para nuevas implementaciones.

Al actualizar las implementaciones existentes, revise las notas de la versión de NSX o póngase en contacto con su representante del soporte técnico de VMware para obtener más información sobre problemas específicos antes de planificar una actualización.

  • NSX for vSphere 6.2.4 soluciona un problema conocido con VPN SSL. Para obtener más información, consulte CVE-2016-2079. Se aconseja que los clientes que ejecuten la versión 6.2.2 o una versión anterior actualicen.
  • vSphere 6.0U3 con NSX for vSphere 6.2.4 resuelve el problema de VTEP duplicados que aparecen en los hosts ESXi después de reiniciar vCenter Server. Consulte el artículo 2144605 de la base de conocimientos de VMware para obtener más información.
vSphere VMware recomienda como mínimo 5.5U3 y 6.0U3 en entornos NSX. Consulte también la matriz de interoperabilidad de productos VMware para obtener información sobre la interoperabilidad.

Notas:

Guest Introspection Las características basadas en Guest Introspection en NSX son compatibles con versiones específicas de VMware Tools (VMTools). Para habilitar el componente de controlador de introspección de red opcional de Thin Agent que se incluye con VMware Tools, debe actualizar a una de las siguientes versiones:
  • VMware Tools 10.0.8 y versiones posteriores para solucionar el problema de lentitud en las máquinas virtuales después de actualizar VMware Tools en NSX / vCloud Networking and Security. Consulte el artículo 2144236 de la base de conocimientos de VMware.

  • VMware Tools 10.0.9 y versiones posteriores para compatibilidad con Windows 10

vRealize Orchestrator Complemento NSX-vRO 1.0.3 o versiones posteriores
VMware Integrated Openstack (VIO) VIO 2.5.1 o una versión posterior
vCloud Director (vCD)
  • vCD 8.0 o una versión posterior si la migración es de vCNS a NSX
  • vCD 8.10.1 o una versión posterior si ya se encuentra en NSX

Requisitos del sistema e instalación

Para ver la lista completa de requisitos previos para la instalación de NSX, consulte la sección sobre requisitos del sistema para NSX en la Guía de instalación de NSX.

Para obtener instrucciones de instalación, acceda a la Guía de instalación de NSX o la Guía de instalación de Cross-vCenter NSX.

Funciones obsoletas y suspendidas

Advertencias sobre la finalización del ciclo de vida y del soporte técnico

Consulte la matriz del ciclo de vida de productos de VMware para obtener información sobre NSX y otros productos de VMware que deben actualizarse próximamente. Las próximas fechas de finalización del soporte técnico son:

 

  • vCloud Networking and Security llegó a las etapas de fin de disponibilidad (End of Availability, EOA) y fin de soporte técnico general (End of General Support, EOGS) el 19 de septiembre de 2016. (Consulte también el artículo de la base de conocimientos 2144733 de VMware). (Consulte también el artículo de la base de conocimientos 2144620 de VMware).
  • NSX for vSphere 6.1.x llegó a las etapas de fin de disponibilidad (End of Availability, EOA) y fin de soporte técnico general (End of General Support, EOGS) el 15 de enero de 2017. (Consulte también el artículo 2144769 de la base de conocimientos de VMware).
  • Desde la versión 6.2.3 de NSX, la función NSX Data Security pasó a estar obsoleta. En la versión 6.2.3 de NSX puede seguir utilizando esta función como desee, pero tenga en cuenta que se eliminará de NSX en versiones futuras.

  • La terminal de acceso web (WAT) está obsoleta y no se incluirá en las próximas versiones de mantenimiento. VMware recomienda utilizar el cliente con acceso completo con implementaciones de VPN SSL para mejorar la seguridad.

Los comandos de la controladora que no son compatibles ya no se muestran

Diríjase a la guía de la CLI para obtener la lista completa de los comandos compatibles. Debe utilizar solo los comandos que aparecen documentados en esta guía. El comando "join control-cluster" no es un comando compatible con NSX for vSphere. Consulte también el artículo 2135280 de la base de conocimientos de VMware.

Se dejó de proporcionar compatibilidad con TLS 1.0 a partir de NSX 6.2.3

A partir de NSX 6.2.3, se dejó de proporcionar la compatibilidad con TLS 1.0 en los conjuntos de cifrado de Ipsec y del equilibrador de carga y en la VPN de NSX. Para obtener más información sobre los cambios respecto a la compatibilidad del cifrado, consulte el artículo 2147293 de la base de conocimientos de VMware.

Notas sobre la actualización

  • Las versiones anteriores no son compatibles:
    • Realice siempre una copia de seguridad de NSX Manager antes de realizar una actualización.

    • Una vez que NSX se actualice correctamente, no podrá volver a utilizar una versión anterior.

  • Para actualizar a la versión NSX 6.2.4 o a una versión posterior, debe realizar una actualización completa de NSX, incluido el clúster del host (que actualiza los VIB del host a la versión 6.2.4). Para obtener instrucciones, acceda a la Guía de actualización de NSX, donde se encuentra la sección sobre cómo actualizar los clústeres del host a NSX 6.2.

     

  • Requisito mínimo de 8 GB de memoria: La actualización a NSX 6.2.3 o a versiones posteriores puede provocar un error en los hosts que tengan menos de 8 GB de memoria.
  • Actualizar la puerta de enlace de servicios Edge (ESG):
    A partir de la versión 6.2.5, la reserva de los recursos se realiza al mismo tiempo que la actualización de NSX Edge. Cuando vSphere HA está habilitado en un clúster con recursos insuficientes, se puede producir un error en la operación de actualización, ya que se infringe la restricción de vSphere HA.

     

    Para evitar estos errores de actualización, realice los siguientes pasos antes de actualizar una ESG:

    1. Asegúrese siempre de que su instalación sigue las prácticas recomendadas para vSphere HA. Consulte el artículo 1002080 de la base de conocimientos.

    2. Use la API de configuración de ajuste de NSX:
      PUT https://<NSXManager>/api/4.0/edgePublish/tuningConfiguration
      para asegurarse de que los valores de edgeVCpuReservationPercentage y edgeMemoryReservationPercentage se encuentran dentro de los recursos disponibles para el factor de forma (consulte la tabla que aparece a continuación para ver los valores predeterminados).

       

    NSX Manager usará las siguientes reservas de recursos si no configuró explícitamente los valores en el momento de instalación o actualización.

    NSX Edge
    Factor de forma
    Reserva de CPU Reserva de memoria
    COMPACTA (COMPACT) 1000 MHz 512 MB
    GRANDE (LARGE) 2000 MHz 1024 MB
    CUÁDRUPLE (QUADLARGE) 4000 MHz 2048 MB
    EXTRA GRANDE (X-LARGE) 6000 MHz 8192 MB

     

  • Deshabilite la opción Iniciar máquina virtual (Virtual Machine Startup) de vSphere cuando vSphere HA está habilitado y los Edges están implementados. Tras actualizar NSX Edge 6.2.4 a la versión 6.2.5 u otras posteriores, debe desactivar la opción para iniciar la máquina virtual de vSphere en cada NSX Edge que se encuentre en un clúster en el que esté habilitado vSphere HA y en el que se hayan implementado Edges. Para hacerlo, abra vSphere Web Client, busque el host ESXi donde se encuentra la máquina virtual de NSX Edge y haga clic en Administrar (Manage): Configuración (Settings), y en Máquinas virtuales (Virtual Machines), seleccione Inicio y apagado de máquina virtual (VM Startup/Shutdown), haga clic en Editar (Edit) y asegúrese de que la máquina virtual esté en modo Manual (es decir, asegúrese de que no se haya añadido a la lista de inicio/apagado automático).
  • Antes de actualizar a NSX 6.2.5 o una versión posterior, asegúrese de que todas las listas de cifrados del equilibrador de carga estén separadas por dos puntos. Si su lista de cifrados utiliza otro separador, como, por ejemplo, comas, realice una llamada PUT a https://nsxmgr_ip/api/4.0/edges/EdgeID/loadbalancer/config/applicationprofiles y sustituya cada lista <ciphers> de <clientSsl> y <serverSsl> por una lista separada por dos puntos. Por ejemplo, el segmento relevante del cuerpo de la solicitud puede tener la siguiente apariencia. Repita este procedimiento para todos los perfiles de la aplicación:
    <applicationProfile>
      <name>https-profile</name>
      <insertXForwardedFor>false</insertXForwardedFor>
      <sslPassthrough>false</sslPassthrough>
      <template>HTTPS</template>
      <serverSslEnabled>true</serverSslEnabled>
      <clientSsl>
        <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
        <clientAuth>ignore</clientAuth>
        <serviceCertificate>certificate-4</serviceCertificate>
      </clientSsl>
      <serverSsl>
        <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
        <serviceCertificate>certificate-4</serviceCertificate>
      </serverSsl>
      ...
    </applicationProfile>
  • Diseño de disco de NSX Controller Las instalaciones nuevas de NSX 6.2.3 o versiones posteriores implementarán los dispositivos de NSX Controller con particiones de disco actualizadas para proporcionar una resistencia de clúster adicional. En versiones anteriores, el desbordamiento del registro en el disco de controlador podía afectar a la estabilidad del controlador. Además de la incorporación de mejoras en la administración de registros para evitar los desbordamientos, el dispositivo de NSX Controller presenta particiones de disco independientes para los datos y los registros para protegerse ante estos eventos. Si actualiza a NSX 6.2.3 o a versiones posteriores, los dispositivos de NSX Controller conservarán el diseño de disco original.
  • Rutas de acceso de la actualización:
    • Ruta de acceso de actualización desde NSX 6.x: La matriz de interoperabilidad de productos VMware proporciona los detalles sobre las rutas de acceso de actualización desde VMware NSX. Encontrará información sobre la actualización de Cross-vCenter NSX en la Guía de actualización de NSX.

    • Ruta de acceso de actualización desde vCNS 5.5.x:

      • Con el paquete de actualizaciones de NSX, puede actualizar VMware vCloud Networking and Security (vCNS) 5.5.x directamente a NSX 6.2.x. Para obtener instrucciones, acceda a la Guía de actualización de NSX en la sección sobre actualización de vCloud Networking and Security a NSX. En esta sección se incluyen también instrucciones para actualizar vCNS 5.5.x a NSX en un entorno de vCloud Director. En una guía independiente, titulada Guía de actualización de NSX para vShield Endpoint, encontrará instrucciones para actualizar vCNS 5.5.x a la versión NSX 6.2.x si usa vShield Endpoint solo para la protección antivirus.

      • Si tiene cables virtuales en su entorno, debe actualizar los clústeres del host. Una vez que lo haga, se cambiará el nombre de los cables virtuales a conmutadores lógicos. Consulte el artículo sobre cómo actualizar los clústeres del host para obtener instrucciones.

  • Para validar que su actualización a NSX 6.2.x se realizó correctamente, consulte el artículo de la base de conocimientos 2134525.
  • Compatibilidad con servicios de partner: Si su sitio web utiliza servicios de partners de VMware para la introspección de red o de invitados, consulte la Guía de compatibilidad de VMware antes de realizar la actualización para comprobar que el servicio del proveedor es compatible con esta versión de NSX.
  • Problemas frecuentes de las actualizaciones: Consulte la sección Problemas conocidos de instalación y actualización más adelante en este documento para ver una lista de los problemas conocidos relacionados con la actualización.
  • Nuevos requisitos del sistema: Si desea obtener información sobre los requisitos de memoria y CPU para la instalación y actualización de NSX Manager, consulte la sección sobre los requisitos del sistema para NSX de la documentación de NSX 6.2.

  • Establezca la versión del cifrado correcta para los clientes del equilibrio de carga que usan TLS 1.0: Esto afecta a los miembros del grupo vROP que usan la versión 1.0 de TLS. Si los servidores, cuyo tráfico es de carga equilibrada, usan esta versión, deberá establecer un valor de extensión de supervisión con la opción "ssl-version=10" en el equilibrador de carga de NSX. Consulte la Guía de administración de NSX.
    {
                    "expected" : null,
                    "extension" : "ssl-version=10",
                    "send" : null,
                    "maxRetries" : 2,
                  "name" : "sm_vrops",
                  "url" : "/suite-api/api/deployment/node/status",
                  "timeout" : 5,
                  "type" : "https",
                  "receive" : null,
                  "interval" : 60,
                  "method" : "GET"
               }
  • Número máximo de reglas NAT: En versiones anteriores a NSX Edge 6.2, el usuario podía configurar 2048 reglas SNAT y 2048 reglas DNAT por separado, con un límite total de 4096. Desde la versión 6.2 de NSX Edge, se ha establecido un límite máximo de reglas NAT permitidas en función del tamaño de la aplicación NSX Edge:

    1024 reglas SNAT y 1024 reglas DNAT para un límite total de 2048 reglas para el borde COMPACT.

    2048 reglas SNAT y 2048 reglas DNAT para un límite total de 4096 reglas para el borde LARGE y el borde QUADLARGE.

    4096 reglas SNAT y 4096 reglas DNAT para un límite total de 8192 reglas para el borde XLARGE.

    Durante una actualización de NSX Edge a la versión 6.2, cualquier borde COMPACT existente cuyo total de reglas NAT (suma de SNAT y DNAT) supere el límite de 2048 no se podrá validar, lo que causará un error de actualización. En este contexto, el usuario deberá cambiar el tamaño de la aplicación a LARGE, QUADLARGE y volver a intentar la actualización.

  • Cambio de comportamiento de los filtros de redistribución en el enrutador lógico distribuido y la puerta de enlace de servicios Edge: A partir de la versión 6.2, las reglas de redistribución del DLR y de la ESG funcionan como ACL solamente. Es decir, si una regla es una coincidencia exacta, se lleva a cabo la acción correspondiente.
  • ID de túnel de VXLAN: Antes de actualizar a NSX 6.2.x, debe asegurarse de que la instalación no utilice un identificador de túnel VXLAN 4094 en ningún túnel. El identificador de túnel VXLAN 4094 ya no se puede utilizar. Para evaluar y abordar este tema, siga estos pasos:
    1. En vCenter, desplácese hasta Inicio (Home) > Redes y seguridad (Networking and Security) > Instalación (Installation) y seleccione la pestaña Preparación del host (Host Preparation).
    2. Haga clic en Configurar (Configure) en la columna VXLAN.

    3. En la ventana Configurar redes VXLAN (Configure VXLAN Networking), establezca el identificador de VLAN (VLAN ID) en un valor entre 1 y 4093.

  • Restablecer vSphere Web Client: Después de actualizar NSX Manager, debe restablecer el servidor vSphere Web Client como se explica en la documentación de actualización de NSX. Hasta entonces, es posible que no aparezca la pestaña Redes y seguridad (Networking and Security) en vSphere Web Client. Es posible que también tenga que limpiar la caché o el historial del navegador.
  • Entornos sin estado: Las actualizaciones de NSX en un entorno de host sin estado utilizan URL de VIB nuevas: En las actualizaciones de NSX en un entorno de host sin estado, los VIB nuevos se agregan previamente al perfil de imagen del host durante el proceso de actualización de NSX. Como resultado, el proceso de actualización de NSX en hosts sin estado sigue esta secuencia:
    1. Se descargan manualmente los VIB de NSX más recientes de NSX Manager desde una URL fija.

    2. Se agregan los VIB al perfil de imagen del host.

    Antes de NSX 6.2.0, había una sola URL en NSX Manager a partir de la cual podían encontrarse los VIB para una versión determinada del host ESX. Esto significa que el administrador solo necesitaba conocer una sola URL, independientemente de la versión de NSX. En NSX 6.2.0 y posteriores, los VIB de NSX nuevos están disponibles en distintas URL. Para encontrar los VIB correctos, debe realizar los pasos siguientes:

    • Busque la URL de VIB nueva en https://<NSX-Manager-IP>/bin/vdn/nwfabric.properties.
    • Obtenga los VIB de la versión de host ESX requerida desde la URL correspondiente.
    • Agréguelos al perfil de imagen del host.
  • Borradores guardados de forma automática y Service Composer En NSX 6.2.3 y versiones posteriores, puede asignar el valor true a la propiedad autoDraftDisabled para deshabilitar la función de borradores automáticos. Las opciones que se configuraron de forma manual se mantienen durante la actualización. Si deshabilita esta función antes de realizar un gran número de cambios en las reglas del firewall, podrá mejorar el rendimiento y evitará que se sobrescriban los borradores guardados previamente. Puede usar la siguiente llamada API para establecer la propiedad autoDraftDisabled como verdadera (true) en la configuración global:

    1. Obtenga la configuración del firewall global existente (GlobalConfiguration):
      GET https://NSX-Manager-IP-Address/api/4.0/firewall/config/globalconfiguration
      Tenga en cuenta que GET no mostrará el campo autoDraftDisabled.
    2. Use una llamada PUT para establecer la propiedad autoDraftDisabled como verdadera (true) en la configuración global:
      PUT https://NSX-Manager-IP-Address/api/4.0/firewall/config/globalconfiguration
      con un cuerpo de solicitud que incluye:
      <globalConfiguration>
          <layer3RuleOptimize>...</layer3RuleOptimize>
          <layer2RuleOptimize>...</layer2RuleOptimize>
          <tcpStrictOption>...</tcpStrictOption>
          <autoDraftDisabled>true</autoDraftDisabled>
      </globalConfiguration>
      
  • Es posible que el host se bloquee en el estado de instalación: Durante actualizaciones grandes de NSX, es posible que un host se bloquee en el estado de instalación durante un periodo de tiempo prolongado. Esto puede ocurrir debido a problemas originados al desinstalar los VIB anteriores de NSX. En este caso, el subproceso EAM asociado a este host aparecerá como bloqueado en la lista de tareas del cliente VI.
    Solución alternativa: Inicie sesión en vCenter mediante el cliente VI. Haga clic con el botón derecho en la tarea EAM bloqueada y cancélela. En vSphere Web Client, emita una acción Resolver (Resolve) en el clúster. Es posible que el host bloqueado aparezca ahora como En curso (InProgress). Inicie sesión en el host y reinicie para forzar la finalización de la actualización en dicho host.

Historial de revisión del documento

6 de julio de 2017: Primera edición. 
21 de agosto de 2017: Segunda edición. Se agregaron los problemas 1904842, 1878081 y 1910593.
2 de octubre de 2017: Tercera edición. Se actualizó la versión mínima recomendada para NSX.

Problemas resueltos

Los problemas resueltos se agrupan del siguiente modo:

Problemas de instalación y actualización resueltos en NSX 6.2.8
  • Problema solucionado 1854519: Las máquinas virtuales pierden la conectividad de norte a sur tras la migración de una VLAN a una VXLAN con puente

    En cuanto la red de máquina virtual cambie de una VLAN a una VXLAN con puente en DLR, se perderá el tráfico de entrada a la máquina virtual. Solucionado en NSX 6.2.8.

Problemas de servicios Edge y de redes resueltos en NSX 6.2.8
  • Problema solucionado 1849037: Los subprocesos de la API de NSX Manager se agotan si se rompe el vínculo de comunicación con NSX Edge
    Si se rompe el canal de comunicación entre NSX Manager y la máquina virtual de NSX Edge, las solicitudes de estado o de estadísticas a la máquina virtual de Edge no responderán y bloquearán los subprocesos de la API. Varias solicitudes de este tipo pueden provocar que todos los subprocesos de la API se bloqueen. Solucionado en NSX 6.2.8.

  • Problema solucionado 1865394: La directiva de catalogación de tráfico no se elimina nunca del puerto dvPortGroup
    La directiva de catalogación de tráfico (TSP) se establece en el puerto dvPortGroup que está conectado a la vNIC de NSX Edge al configurar el puerto. El comportamiento esperado consiste en que cuando una vNIC se desconecte de este puerto, la TSP se elimine. Los siguientes casos que activan NSX Manager provocan que se cambie o se desconecte un puerto dvPortGroup conectado a la vNIC de NSX Edge:
    • Se vuelve a implementar NSX Edge
    • Se actualiza NSX Edge
    • Se desconecta y se vuelve a conectar NSX Edge
    • Se cambia el tamaño del dispositivo NSX Edge
    • Se elimina la interfaz de NSX Edge
    • Se elimina NSX Edge
    Solucionado en NSX 6.2.8.

  • Problema solucionado 1704940: Si el recuento de pCPU es superior a 256, puede aparecer una pantalla de diagnóstico de color púrpura en el host ESXi
    El DLR de NSX tiene una tabla de flujos por pCPU y el número de pCPU está restringido a 256, por lo que aparece un error si el recuento de pCPU supera este número. Solucionado en NSX 6.2.8.

  • Problema solucionado 1892265: El paquete de archivos de NSX Edge no se elimina del directorio /common/tmp después de cada publicación y llena el directorio /common
    El directorio /common se llena y NSX Manager se queda sin espacio porque el paquete de archivos de NSX Edge (sslvpn-plus config) no se elimina de /common/tmp. Solucionado en NSX 6.2.8.

  • Problema solucionado 1681063: El estado de túnel VPN para algunas puertas de enlace de Edge no se refleja de forma precisa en vCloud Director

    vCloud Director (vCD) y NSX muestran otro estado del túnel VPN IPsec. vCD muestra el túnel de IPSec como inactivo, aunque esté activado y enviando tráfico. Solucionado en NSX 6.2.8.

  • Problema solucionado 1849760: El proceso de enrutamiento puede consumir CPU si algunos prefijos se conocen a través de la red IBGP, por lo que el salto siguiente pertenece a la subred de prefijo

    El problema se observa en las configuraciones en las que la máquina virtual de control DLR se empareja con las ESG en IBGP y las ESG se emparejan con enrutadores físicos a través de EBGP. Además, la máquina virtual de control de DLR está ejecutando HA. Los temporizadores intensos están en uso para la sesión BGP. Cuando la red subyacente comienza a oscilar y, de este modo, induce a la oscilación de los vecinos BGP, la máquina virtual de control de DLR también vuelve a aprender los prefijos del vecino de oscilación y debe resolverlos. Cuando la subred de prefijo aprendida abarca la dirección IP de salto siguiente(ejemplo 10.0.0.0/8 a través de 10.1.1.2), el proceso de enrutamiento puede entrar en un bucle recursivo. Solucionado en NSX 6.2.8.

Problemas de NSX Manager resueltos en NSX 6.2.8
  • Problema solucionado 1892208: La base de datos de NSX Manager solo muestra un almacén de datos (ubicación del archivo vmx) pero la IU muestra dos: Actual y Configurado (Current and Configured).
    Solucionado en NSX 6.2.8.

  • Problema solucionado 1861785: Se observa un uso total de CPU en NSX Manager con vCloud Director (vCD) y vRealize Operations (vROps)
    Si la base de datos tiene un número considerable de registros huérfanos en las tablas system_event_message_params y system_event_event_metadata, las API necesitarán más tiempo para responder a las solicitudes desde vCD y, mientras tanto, los clientes vCD se desconectarán, lo que provoca una nueva llamada a las mismas API. Esto da lugar a un uso elevado de CPU. Este problema se soluciona eliminando los registros huérfanos. Solucionado en NSX 6.2.8.

  • Problema solucionado 1760940: Varias tareas simultáneas de vMotion desencadenan un uso elevado de CPU en NSX Manager
    DFW se configura con grupos de seguridad dinámicos cuyos criterios están basados en el nombre o el SO invitado de la máquina virtual. Consulte el artículo 2150668 de la base de conocimientos de VMware para obtener más información. Solucionado en NSX 6.2.8.
Problemas de servicios de seguridad resueltos en NSX 6.2.8
  • Problema solucionado 1836322: "Error de Flash" ("Flash error") al editar las reglas de firewall de NSX
    A veces, al editar los grupos de seguridad, la interfaz de usuario de vSphere Web Client muestra un error relacionado con el complemento Flash. Solucionado en NSX 6.2.8.

  • Problema solucionado 1832912: Cuando se activa el modo de mantenimiento en un host, algunas máquinas virtuales de ese host pierden las reglas del firewall que se aplicaron previamente
    Cuando se activa el modo de mantenimiento en un host y DRS mueve todas las máquinas virtuales a otro host, algunas máquinas virtuales de ese host pierden las reglas del firewall que se aplicaron previamente. La solución alternativa es evitar la creación de grupos de seguridad con criterios dinámicos basados en el nombre del equipo o de su sistema operativo. Solucionado en NSX 6.2.8.

  • Problema solucionado 1818550: La agrupación de las actualizaciones de objetos se retrasa en los hosts que cuentan con una gran cantidad de máquinas virtuales y de grupos de seguridad anidados

    En los hosts que tengan una gran cantidad de máquinas virtuales y de grupos de seguridad anidados, un solo cambio en el inventario hará que una actualización de contenedor se vacíe, lo que causará un gran retraso cuando se agrupen las actualizaciones de objetos en los hosts. Solucionado en NSX 6.2.8.

  • Problema solucionado 1800196: El registro VMkernel se detiene si un número elevado de paquetes de IP con direcciones MAC de difusión coincide con una regla para rechazar Distributed Firewall

    Distributed Firewall envía paquetes rechazados únicamente a direcciones MAC de unidifusión. Cuando los paquetes de IP con una dirección MAC de difusión coinciden con una regla de rechazo, no se envía ningún paquete rechazado. Sin embargo, este evento se registra en vmkernel.log. Si la red se desborda con este tráfico, vmkernel.log desecha mensajes debido al estrés del registro y se detiene el registro. Ahora, el rechazo de paquetes con direcciones MAC de difusión se registra únicamente si la depuración está habilitada. Solucionado en NSX 6.2.8. Ahora, el rechazo de paquetes con direcciones MAC de difusión se registra únicamente si la depuración está habilitada.

  • Problema solucionado 1798537: El proceso del controlador de DFW en ESXi (vsfwd) se puede quedar sin memoria

    En un entorno con un elevado número de reglas o grupos de seguridad de gran tamaño en la configuración DFW, el proceso del controlador de DFW en ESXi (vsfwd) puede quedarse sin memoria y podría no publicar reglas en la ruta de acceso a los datos. Solucionado en NSX 6.2.8.

  • Problema solucionado 1853106: Se produce un error en la IU cuando la certificación está desactivada o se realizan algunos cambios en la configuración IPsec para la VPN de IPsec en el modo PSK

    Aparece el error "Error al leer certificados y secretos. : 002 olvidando secretos" (Failed to read certs & secrets. 002 forgetting secrets) en la pestaña Configuración global (Global Configuration) cuando la certificación del modo PSK está desactivada o modificada para la VPN IPsec con la autenticación basada en certificados. Solucionado en NSX 6.2.8.

Problemas de interoperabilidad de soluciones resueltos en NSX 6.2.8
  • Problema solucionado 1838742: La versión de NSX Edge puede ser diferente de la versión de API o de IU que se muestra y de la versión implementada del entorno de VCD
    Durante una actualización de vCNS a NSX, cuando NSX Manager se actualiza, todos los vCNS Edge se deben actualizar o volver a implementar de forma explícita antes de realizar cualquier otra operación de edición en vCloud Director. Si la actualización no se inicia, la versión de NSX Edge que aparece en la interfaz de usuario y en la API puede ser diferente de la versión implementada. Solucionado en NSX 6.2.8.

Problemas conocidos

Los problemas conocidos se dividen del siguiente modo.

Problemas conocidos generales
  • Problema 1708769: Aumentó la latencia en la máquina virtual segura (máquina virtual de servicios) tras ejecutar una instantánea en NSX

    Este problema se produce porque al ejecutar una instantánea en una máquina virtual de servicios (máquina virtual segura) se puede producir una latencia adicional en la red. En algunas ocasiones, las aplicaciones de copia de seguridad que se ejecutan en el entorno invocan la instantánea.

    Solución alternativa: Consulte el artículo 2146769 de la base de conocimientos de VMware.

  • Problema 1716328: Si se elimina un host que está en modo de mantenimiento, puede aparecer un error en la preparación del clúster

    Si un administrador establece un host ESXi compatible con NSX en modo de mantenimiento y lo elimina de un clúster preparado con NSX, NSX no puede eliminar los registros del número ID del host eliminado. Después de que se realice la instalación en este estado, si existe otro host con el mismo ID en otro clúster o si este host se agrega a otro clúster, se producirá un error en el proceso de preparación de dicho clúster.

    Solución alternativa: Reinicie NSX Manager o ejecute la siguiente API para bloquear la entrada adicional. Ejecute un PUT del método API,
    https://nsx-manager-address/api/internal/firewall/updatestatus

  • Problema 1659043: El estado del servicio de Guest Introspection aparece como "No listo" (Not Ready) cuando se alcanza el tiempo de espera de la comunicación de NSX Manager con USVM.

    Puede aparecer un mensaje de error similar a "Inicio de sesión PLAIN rechazada: usuario 'usvm-admin-host-14' - credenciales no válidas" para las Universal SVM de Guest Introspection cuando no se realice con éxito el proceso de cambio de contraseña con NSX Manager en el bus de mensajería interna (rabbit MQ).

    Solución alternativa: Para volver a establecer la conexión entre la USVM y NSX Manager, reinicie la USVM o elimínela de forma manual y seleccione a continuación el botón Resolver (Resolve) en la UI de Service Composer para solicitar una reimplementación de la USVM solo en el host afectado.

  • Problema 1662842: Guest Introspection: Se pierde la conexión entre MUX y USVM cuando se intenta resolver las SID de Windows sin solución
    El servicio de Guest Introspection entra en estado de advertencia y cada instancia de Guest Introspection entra y sale de dicho estado. Hasta que la máquina virtual de Guest Introspection se vuelva a conectar, los eventos de la red no se enviarán a NSX Manager. Esto afectará tanto a la supervisión de la actividad como al firewall de ID si se detectan eventos de inicio de sesión a través de la ruta de Guest Introspection.

    Solución alternativa: Las máquinas virtuales de Guest Introspection deben configurarse para ignorar las búsquedas de las SID ya conocidas, para que así Guest Introspection vuelva a un estado estable. Para conseguir esto, es necesario actualizar un archivo de configuración en cada máquina virtual de Guest Introspection y reiniciar luego el servicio. Además, se pueden extraer los registros de Active Directory como solución alternativa para detectar eventos de inicio de sesión del firewall de ID.

    Pasos para ignorar las búsquedas de SID para las SID sin solución:
    1. Inicie sesión en la máquina virtual de Guest Introspection.
    2. Edite el archivo en /usr/local/usvmmgmt/config/ignore-sids.lst.
    3. Anexe las siguientes líneas:
      S-1-18-1
      S-1-18-2
    4. Guarde y cierre el archivo.
    5. Reinicie el servicio de Guest Introspection con el siguiente comando:
      rcusvm restart.
  • Problema 1558285: Al eliminar un clúster con Guest Introspection desde Virtual Center, la acción acaba en una excepción de puntero nulo
    Se deben eliminar servicios como Guest Introspection antes de eliminar un clúster de VC.

    Solución alternativa: Elimine la agencia EAM para la implementación del servicio sin clúster asociado.

  • Problema 1629030: La captura de paquetes de la CLI central (depurar la captura de paquetes y mostrar captura de paquetes) necesita vSphere 5.5U3 o versiones posteriores
    Estos comandos no son compatibles con versiones anteriores a vSphere 5.5.

    Solución alternativa: VMware aconseja a todos los clientes de NSX que ejecuten vSphere 5.5U3 o una versión posterior.

  • Problema 1568180: Lista de funciones incorrecta para NSX cuando se usa vCenter Server Appliance (vCSA) 5.5.
    Para ver las funciones de una licencia en vSphere Web Client, seleccione la licencia y haga clic en Acciones (Actions) > Ver funciones (View Features). Si actualiza a NSX 6.2.3, su licencia se actualizará a una licencia empresarial, que habilita todas las funciones. Sin embargo, si NSX Manager se registró con vCenter Server Appliance (vCSA) 5.5, al seleccionar Ver funciones (View Features) se mostrará la lista de funciones de la licencia utilizada antes de la actualización, no la nueva licencia empresarial.

    Solución alternativa: Todas las licencias empresariales tienen las mismas funciones, aunque no se muestren correctamente en vSphere Web Client. Consulte la página de concesión de licencia de NSX para obtener más información.

  • Problema 1477280: No se pueden crear instancias de puerta de enlace de hardware si no hay ningún controlador implementado
    Antes de configurar ninguna instancia de puerta de enlace de hardware se deben implementar los controladores. Si no se implementan los controladores en primer lugar, se mostrará el mensaje de "error al realizar la operación en el controlador".

    Solución alternativa: Ninguna.

  • Problema 1491275: NSX API devuelve el formato JSON en vez de XML en determinadas circunstancias
    En algunas ocasiones, una solicitud API devuelve al usuario el formato JSON, no XML.

    Solución alternativa: Agregue Accept: application/xml al encabezado de la solicitud.

Problemas conocidos de instalación y actualización
  • Nuevo Problema 1905064: Algunos hosts del clúster pierden las conexiones TCP a NSX Manager y a los controladores durante una actualización del host
    Si un host ESXi pierde la conexión TCP a NSX Manager durante una actualización, este no podrá obtener la información del controlador. Esto evita que el controlador envíe configuraciones de NSX a este host, lo que causa que todas las máquinas virtuales del mismo pierdan conectividad.

    Solución alternativa: Reinicie el host afectado.

  • Nuevo Problema 1910593: Los parámetros de respuesta distinguen entre mayúsculas y minúsculas en la API de actualización de NSX Manager
    Si utiliza NSX API para actualizar NSX Manager y desea habilitar SSH o participar en el programa CEIP de VMware, debe asignar el valor "Sí" (Yes), no "SÍ"(YES), al parámetro de respuesta.

    Solución alternativa: Consulte la Guía de NSX API para obtener más información sobre cómo actualizar a través de la API.

  • Problema 1838229: Las transacciones de HTTP/HTTPS fallan en el equilibrador de carga de NSX después de actualizar a NSX 6.1.5 o a una versión posterior.
    A partir de NSX 6.1.5, al habilitar x-forwarded-for, se cambió el modo de conexión HTTP de cierre pasivo (opción httpclose) al modo predeterminado cerrado del servidor (opción http-server-close) de HTTP. D esta forma, se puede mantener abierta la conexión orientada al cliente, mientras que la conexión orientada al servidor permanece cerrada después de recibir una respuesta del servidor. Esto ocasiona problemas en algunas aplicaciones debido a que, en versiones NSX anteriores a la versión 6.1.5, el equilibrador de carga no cerró la conexión de forma proactiva, pero insertó el encabezado "Connection:close" en ambas direcciones para indicar al cliente o al servidor que deben cerrar la conexión.

    Solución alternativa: Agregue una regla de aplicación con la opción httpclose de script y asóciela al servidor virtual.

  • Problema 1820723: No se pueden ver los filtros en ESXi después de actualizar de la versión 6.2.x a la 6.2.7 debido a un error al conectarse al host
    Tras actualizar NSX de la versión 6.2.x a la 6.2.7 y los VIB de clúster a 6.2.7 bits, aunque el estado de la instalación se muestre como correcto y esté habilitado el firewall, el estado del canal de comunicación mostrará la conectividad de NSX Manager con el agente firewall y con el agente de plano de control como inactivas. Esto generará errores en la publicación de la directiva de seguridad y de las reglas del firewall, y provocará que la configuración de VXLAN no se envíe a los hosts.

    Solución alternativa: Ejecute la llamada API de sincronización del bus de mensajes para el clúster que utilice la API POST:https://<NSX-IP>/api/2.0/nwfabric/configure?action=synchronize.
    Cuerpo de la API:

    <nwFabricFeatureConfig>
     <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
     <resourceConfig>
       <resourceId>{Cluster-MOID}</resourceId>
     </resourceConfig>
    </nwFabricFeatureConfig>
    

  • Problema 1435504: Comprobación de estado HTTP/HTTPS aparece en estado INACTIVO tras actualizar de 6.0.x o 6.1.x a 6.2.x con la razón de error "El código de retorno de 127 está fuera de los límites: es posible que el complemento falte"
    En las versiones 6.0.x y 6.1.x de NSX, las direcciones URL configuradas sin comillas dobles ("") generaron un fallo de comprobación de estado con el siguiente error: "El código de retorno de 127 está fuera de los límites: es posible que el complemento falte". La solución a este problema fue agregar las comillas dobles ("") a la URL de entrada (esto no era necesario para enviar, recibir o esperar campos). Sin embargo, este problema se solucionó en la versión 6.2.0 y, como resultado, si va a actualizar de 6.0.x o 6.1.x a 6.2.x, las comillas dobles adicionales hacen que los miembros del grupo se muestren como INACTIVOS en la comprobación de estado.

    Solución alternativa: Elimine las comillas dobles ("") en el campo de URL de todas las configuraciones relevantes de comprobación de estado después de actualizar.

  • Problema 1768144: Las reservas de recursos de dispositivos NSX Edge anteriores que superen los nuevos límites pueden provocar errores durante la actualización o la nueva implementación
    En NSX 6.2.4 y versiones anteriores, podía especificar una gran reserva de recursos para un dispositivo NSX Edge. NSX no aplicaba un valor máximo. Después de actualizar NSX Manager a la versión 6.2.5 o posterior, si Edge tiene recursos reservados (sobre todo memoria) que superan el nuevo valor máximo impuesto para el factor de forma seleccionado, se producen errores durante la actualización o nueva implementación (que activa una actualización) de Edge. Por ejemplo, supongamos que el usuario especificó una reserva de memoria de 1.000 MB en un dispositivo Edge GRANDE con una versión anterior a la 6.2.5 y, después de actualizarlo a la versión 6.2.5 o una versión posterior, cambia el tamaño a COMPACTO. La reserva de memoria especificada por el usuario superará el nuevo valor máximo establecido (en este caso, 512 para un Edge COMPACTO) y se producirá un error en la operación.
    Consulte cómo actualizar la puerta de enlace del servicio Edge (ESG) para obtener más información sobre la asignación de recursos a partir de NSX 6.2.5.

    Solución alternativa: Use la REST API del dispositivo PUT https://<NSXManager>/api/4.0/edges/<edge-Id>/appliances/ para volver a configurar la reserva de memoria y que se encuentre dentro de los valores especificados para el factor de forma sin más cambios en el dispositivo. Podrá modificar el tamaño del dispositivo una vez que se complete esta operación.

  • Problema 1730017: Las actualizaciones de 6.2.3 a 6.2.7 no muestran un cambio de versión para Guest Introspection
    Dado que el módulo 6.2.3 de Guest Introspection es la última versión disponible, la versión posterior a la actualización 6.2.7 permanece sin cambios. Tenga en cuenta que las actualizaciones de versiones anteriores de NSX pueden mostrar un cambio de versión a 6.2.7

    Solución alternativa: Esto no afecta a ninguna función.

  • Problema 1683879: La actualización a NSX 6.2.3 o versiones posteriores puede provocar un error en los hosts que tengan menos de 8 GB de memoria

    NSX 6.2.3 y las versiones posteriores necesitan un mínimo de 8 GB de memoria en los hosts preparados con servicios de seguridad y redes en ejecución. El requisito mínimo de memoria de 4 GB de ESXi 6.0 no es suficiente para ejecutar NSX.

    Solución alternativa: Ninguna.

  • Problema 1673626: No se permite modificar tcpLoose a través de /api/3.0/edges después de actualizar de vCloud Networking and Security a NSX

    Después de actualizar de vCloud Networking and Security a NSX, aparecerá un error si intenta modificar la configuración tcpLoose en esta solicitud de API: /api/3.0/edges

    Solución alternativa: En su lugar, utilice la configuración tcpPickOngoingConnections en la sección globalConfig en la solicitud de API /api/4.0/firewall/.

  • Problema 1658720: Si se habilita DFW en un clúster concreto, se genera un error en la actualización de vCNS a NSX si el clúster tiene instalado VXLAN pero no tiene instalado vShield App (o se eliminó antes de la actualización) en una implementación de vCNS

    Este problema se produce porque no se invoca el estado de sincronización del clúster cuando se actualizan los hosts.

    Solución alternativa: Reiniciar NSX Manager.

  • Problema 1600281: En el estado de instalación de USVM para Guest Introspection aparece Error (Failed) en la pestaña Implementaciones de servicio (Service Deployments)

    Si el almacén de datos de copias de seguridad para la Universal SVM de Guest Introspection se desconecta o aparece inaccesible, es necesario reiniciar la USVM o volverla a implementar para su recuperación.

    Solución alternativa: reiniciar o volver a implementar la USVM para su recuperación.

  • Problema 1660373: vCenter aplica la licencia de NSX caducada

    En la versión vSphere 5.5 actualización 3 o vSphere 6.0.x, se incluye vSphere Distributed Switch en la licencia de NSX. Sin embargo, vCenter no permite que se agreguen hosts ESX a vSphere Distributed Switch si caducó la licencia de NSX.

    Solución alternativa: La licencia de NSX debe estar activa para agregar un host a vSphere Distributed Switch.​

  • Problema 1569010/1645525: Al actualizar de la versión 6.1.x a NSX for vSphere 6.2.3 en un sistema conectado a Virtual Center 5.5, el campo Producto (Product) de la ventana "Asignar clave de licencia" (Assign License Key) muestra la licencia de NSX con el valor genérico de "NSX para vSphere" (NSX for vSphere) y no con uno más específico como "NSX para vSphere - Enterprise" (NSX for vSphere - Enterprise).

    Solución alternativa: Ninguna.

  • Problema 1465249: El estado de la instalación para Guest Introspection es correcto aunque el host no tenga conexión
    Una vez instalado Guest Introspection en el clúster que tiene un host sin conexión, dicho host mostrará el estado de la instalación como correcto y desconocido.

    Solución alternativa: Ninguna.

  • Problema 1636916: En un entorno de vCloud Air, al actualizar la versión de NSX Edge de vCNS 5.5.x a NSX 6.x, las reglas de Edge Firewall con un valor de protocolo de origen de "cualquiera" (any) se cambian a "tcp:cualquiera, udp:cualquiera" (tcp:any, udp:any)
    Como resultado, se bloquea el tráfico ICMP y se puede apreciar la colocación de paquetes.

    Solución alternativa: Antes de actualizar su versión de NSX Edge, cree reglas de Edge Firewall y sustituya el valor "cualquiera" (any) con valores específicos del puerto de origen.

  • Problema 1660355: Las máquinas virtuales que se migran de la versión 6.1.5 a la versión 6.2.3 no ofrecerán compatibilidad con ALG de TFTP
    Aunque el host esté habilitado, las máquinas virtuales que se migran de la versión 6.1.5 a la versión 6.2.3 no ofrecerán compatibilidad con ALG de TFTP.

    Solución alternativa: Agregue y elimine la máquina virtual de la lista de exclusión o reiníciela, de modo que el nuevo filtro de la versión 6.2.3 se cree para ofrecer compatibilidad con ALG de TFTP.

  • Problema 1394287: La dirección IP definida en las reglas de vShieldApp (vShieldApp Rules) no se actualiza al agregar o eliminar máquinas virtuales de un cable virtual (VirtualWire)
    Si la instalación de un firewall de vShield App de vCNS ya existente no se actualiza al firewall distribuido de NSX en modo mejorado, las nuevas máquinas virtuales con reglas de firewall basadas en cables virtuales (VirtualWire) no tendrán una dirección IP actualizada. Como resultado, estas máquinas virtuales no contarán con la protección del firewall de NSX. Este problema solo aparece en las siguientes situaciones:
    • Después de actualizar Manager de vCNS a NSX sin cambiar al modo DFW mejorado.
    • Si agrega nuevas máquinas virtuales a un cable virtual (VirtualWire) mediante reglas de vShield App que consumen dichos cables virtuales, estas reglas no tendrán definida la nueva dirección IP correspondiente a las nuevas máquinas virtuales.
    • Esto hará que vShield App no proteja las nuevas máquinas virtuales.

    Solución alternativa: Publique la regla de nuevo de modo que establezca la nueva dirección.

  • Problema 1386874: Después de la actualización de vCenter, es posible que vCenter pierda conectividad con NSX
    Si se utiliza SSO integrado de vCenter y se actualiza vCenter 5.5 a vCenter 6.0, es posible que vCenter pierda conectividad con NSX. Esto sucede si vCenter 5.5 se registró con NSX con el nombre de usuario raíz. En NSX 6.2, el registro de vCenter con raíz es obsoleto.
    Nota: Si se utiliza un SSO externo, no es necesario hacer cambios. Puede mantener el mismo nombre de usuario, por ejemplo, admin@miempresa.midominio, y la conectividad de vCenter no se perderá.

    Solución alternativa: Registre vCenter con NSX con el nombre de usuario administrator@vsphere.local en lugar del de raíz.

  • Problema 1375794: Cerrar sistema operativo invitado para máquinas virtuales de agente (SVA) antes de apagar
    Cuando se coloca un host en modo de mantenimiento, todos los dispositivos de servicio se apagan, en lugar de cerrarse de manera estable. Esto puede provocar errores en aplicaciones de terceros.

    Solución alternativa: Ninguna.

  • Problema 1112628: No se puede encender el dispositivo de servicio que se implementó con la vista Implementaciones de servicios (Service Deployments)

    Solución alternativa: Antes de continuar, compruebe lo siguiente:

    • Se completó la implementación de la máquina virtual.

    • Ninguna tarea, como clonación, reconfiguración, etc., está en curso en la máquina virtual que se muestra en el panel de tareas de VC.

    • En el panel de eventos VC de la máquina virtual, se muestran los eventos siguientes una vez iniciada la implementación:
       
      Se aprovisionó la máquina virtual de agente <nombre de máquina virtual>(Agent VM <vm name> has been provisioned).
      Marque el agente como disponible para continuar con el flujo de trabajo del agente (Mark agent as available to proceed agent workflow).
       

      En tal caso, elimine la máquina virtual de servicio. En la interfaz de usuario de implementación de servicios, el estado de la implementación es Con errores (Failed). Cuando hace clic en el icono rojo, se muestra una alarma de una máquina virtual de agente no disponible para el host. Cuando resuelve la alarma, se vuelve a implementar la máquina virtual y se enciende.

  • Si no están preparados todos los clústeres del entorno, el mensaje de actualización de Distributed Firewall no aparece en la pestaña Preparación del host (Host Preparation) de la página Instalación (Installation)
    Cuando se preparan los clústeres para la virtualización de red, se habilita Distributed Firewall en esos clústeres. Si no están preparados todos los clústeres del entorno, el mensaje de actualización de Distributed Firewall no aparece en la pestaña Preparación del host (Host Preparation).

    Solución alternativa: Utilice la llamada REST siguiente para actualizar Distributed Firewall:

    PUT https://<nsxmgr-ip>/api/4.0/firewall/globalroot-0/state

  • Problema 1215460: Si se modifica un grupo de servicios después de una actualización para agregar o quitar servicios, estos cambios no se ven reflejados en la tabla del firewall
    Los grupos de servicios creados por el usuario se expanden en la tabla Firewall de Edge (Edge Firewall) durante la actualización, es decir, la columna Servicio (Service) de la tabla del firewall muestra todos los servicios incluidos en el grupo de servicios. Si se modifica el grupo de servicios después de una actualización para agregar o quitar servicios, estos cambios no se ven reflejados en la tabla del firewall.

    Solución alternativa: Cree un grupo de servicios nuevo con un nombre distinto y, a continuación, utilice este grupo de servicios en la regla del firewall.

  • Problema 1088913: La MTU de vSphere Distributed Switch no se actualiza
    Si se especifica un valor de MTU inferior al de la MTU del conmutador distribuido de vSphere cuando se prepara un clúster, vSphere Distributed Switch no se actualiza con este valor. Esto se hace para garantizar que el tráfico existente con el tamaño mayor de trama no se descarte de manera accidental.

    Solución alternativa: Asegúrese de que la MTU que especifica cuando prepara el clúster sea mayor o igual que la MTU actual del conmutador distribuido de vSphere. La MTU mínima requerida para VXLAN es 1550.

  • Problema 1413125: No se puede volver a configurar SSO después de la actualización
    Cuando el servidor de SSO configurado en NSX Manager es el nativo en vCenter Server, no se pueden volver a configurar las opciones de SSO en NSX Manager una vez que vCenter Server se actualizó a la versión 6.0 y NSX Manager a la versión 6.x.

    Solución alternativa: Ninguna.

  • Problema 1288506: Después de la actualización de vCloud Networking and Security 5.5.3 a NSX for vSphere 6.0.5 o posterior, NSX Manager no arranca si se utiliza un certificado SSL con tamaño de clave DSA-1024
    Los certificados SSL con tamaño de clave DSA-1024 no son compatibles con NSX for vSphere 6.0.5 y posteriores, por lo que la actualización no se completa correctamente.

    Solución alternativa: Importe un certificado SSL nuevo con un tamaño de clave compatible antes de iniciar la actualización.

  • Problema 1263858: La VPN SSL no envía una notificación de actualización al cliente remoto
    La puerta de enlace de la VPN SSL no envía una notificación de actualización a los usuarios. El administrador debe comunicar manualmente a los usuarios remotos que la puerta de enlace de la VPN SSL (servidor) está actualizada y que deben actualizar los clientes.

    Solución alternativa: Los usuarios deben desinstalar la versión anterior del cliente e instalar la última versión manualmente.

  • Problema 1402307: Si se reinicia vCenter durante el proceso de actualización de NSX for vSphere, se muestra un estado del clúster incorrecto
    Cuando se realiza la preparación del host en un entorno con varios clústeres preparados con NSX durante una actualización y vCenter Server se reinicia después de que se preparó al menos un clúster, los demás clústeres pueden mostrar el estado de clúster como No listo (Not Ready) en lugar de mostrar un vínculo de actualización. Los hosts en vCenter también pueden mostrar el estado Reinicio necesario (Reboot Required).

    Solución alternativa: No reinicie vCenter durante la preparación del host.

  • Problema 1487752: Pérdida momentánea de la protección antivirus de terceros durante la actualización
    Cuando se actualiza de NSX 6.0.x a NSX 6.1.x o 6.2.x, es posible que se produzca una pérdida momentánea de la protección antivirus de terceros en las máquinas virtuales. Este problema no afecta las actualizaciones de NSX 6.1.x a NSX 6.2.

    Solución alternativa: Ninguna.

  • Problema 1491820: El registro de NSX Manager recopila mensajes WARN messagingTaskExecutor-7 después de la actualización a NSX 6.2
    Después de actualizar de NSX 6.1.x a NSX 6.2, el registro de NSX Manager se llena de mensajes similares al siguiente: WARN messagingTaskExecutor-7 ControllerInfoHandler:48 - host is unknown: host-15 return empty list. No afectan el funcionamiento.

    Solución alternativa: Ninguna.

  • Problema 1284735: Después de actualizar desde vCNS, no es posible colocar nuevos objetos de agrupación en algunos objetos de agrupación actualizados
    vCNS 5.x admite la creación de objetos de agrupación en alcances por debajo de GlobalRoot (inferiores al alcance amplio de NSX). Por ejemplo, en vCNS 5.x es posible crear un objeto de agrupación como nivel DC o PG. En cambio, la interfaz de usuario de NSX 6.x crea esos objetos bajo GlobalRoot. Además, estos objetos de agrupación creados recientemente no se pueden agregar a los ya existentes que fueron creados con un alcance inferior (DC o PG) en la instalación de vCNS actualizada previamente.

    Solución alternativa: Consulte el artículo 2117821 de la base de conocimientos de VMware.

  • Problema 1495969: Después de actualizar de vCNS 5.5.4 a NSX 6.2.x, el firewall en la pestaña Preparación del host (Host Preparation) permanece deshabilitado
    Después de actualizar de vCNS 5.5.x a NSX 6.2.x y de actualizar todos los clústeres, el firewall en la pestaña Preparación del host (Host Preparation) permanece deshabilitado. Además, la opción para actualizar el firewall no aparece en la interfaz de usuario. Esto sucede solo cuando hay hosts que no son parte de ningún clúster preparado en el centro de datos, porque los VIB no se instalan en esos hosts.

    Solución alternativa: Para resolver el problema, mueva los hosts a un clúster preparado de NSX 6.2.

  • Problema 1495307: Durante una actualización, las reglas de firewall L2 y L3 no se publican en los hosts
    Después de publicar un cambio en la configuración de Distributed Firewall, el estado permanece En curso (InProgress) tanto en la interfaz de usuario como en la API de manera indefinida, y no se escribe ningún registro para las reglas L2 o L3 en el archivo vsfwd.log.

    Solución alternativa: Durante una actualización de NSX, no publique los cambios en la configuración de Distributed Firewall. Para salir del estado En curso (InProgress) y resolver el problema, reinicie el dispositivo virtual NSX Manager.

  • Problema 1474066: Parece que la llamada API REST de NSX para habilitar o deshabilitar la detección de IP no surte efecto
    Si no se completó la preparación del clúster del host, la llamada API REST de NSX para habilitar o deshabilitar la detección de IP (https://<nsxmgr-ip>/api/2.0/xvs/networks/universalwire-5/features) no surte efecto.

    Solución alternativa: Antes de emitir esta llamada API, asegúrese de que se haya completado la preparación del clúster del host.

  • Problema 1479314: Los clientes de la VPN SSL de NSX 6.0.7 no se pueden conectar a las puertas de enlace de la VPN SSL de NSX 6.2
    En las puertas de enlace de la VPN SSL de NSX 6.2, los protocolos SSLv2 y SSLv3 están deshabilitados. Esto significa que la puerta de enlace de la VPN SSL solo acepta el protocolo TLS. Los clientes de la VPN SSL versión 6.2 se actualizaron para utilizar el protocolo TLS de forma predeterminada durante el establecimiento de la conexión. En NSX 6.0.7, el cliente de VPN SSL utiliza una versión anterior de la biblioteca OpenSSL y el protocolo SSLv3 para establecer una conexión. Cuando un cliente NSX 6.0.x intenta conectarse a una puerta de enlace de NSX 6.2, se produce un error en el establecimiento de la conexión en el nivel del protocolo de enlace de SSL.

    Solución alternativa: Actualice el cliente de VPN SSL a NSX 6.2 después de haber actualizado a NSX 6.2. Para ver las instrucciones de actualización, consulte la documentación de actualización de NSX.

  • Problema 1434909: Se debe crear un grupo de identificadores de segmentos para los enrutadores lógicos nuevos o actualizados
    En NSX 6.2, debe haber un grupo de identificadores de segmentos con identificadores de segmentos disponibles para poder actualizar un enrutador lógico a 6.2 o crear un enrutador lógico 6.2 nuevo. Esto aplica incluso si no se planean utilizar conmutadores lógicos NSX en la implementación.

    Solución alternativa: Si la implementación de NSX no tiene un grupo de identificadores de segmentos local, cree uno como requisito previo para la instalación o actualización del enrutador lógico NSX.

  • Problema 1459032: Error en la configuración de la puerta de enlace de VXLAN
    Cuando se configura una VXLAN con un grupo de direcciones IP estáticas (en Redes y seguridad [Networking & Security] >Instalación [Installation] > Preparación del host [Host Preparation] >Configurar VXLAN [Configure VXLAN]) y la configuración no puede establecer una IP de puerta de enlace de grupo de direcciones IP en VTEP (debido a que la puerta de enlace no está correctamente configurada o no es posible comunicarse con ella), el estado de configuración de la VXLAN entra en estado de error (ROJO) en el clúster del host.

    El mensaje de error es La puerta de enlace de la VXLAN no puede establecerse en el host y el estado de error es VXLAN_GATEWAY_SETUP_FAILURE. En la llamada API REST, GET https://<nsxmgr-ip>/api/2.0/nwfabric/status?resource=<cluster-moid>, el estado de la VXLAN es el siguiente:

    <nwFabricFeatureStatus>
      <featureId>com.vmware.vshield.nsxmgr.vxlan</featureId>
      <featureVersion>5.5</featureVersion>
      <updateAvailable>false</updateAvailable>
      <status>RED</status>
      <message>VXLAN Gateway cannot be set on host</message>
      <installed>true</installed>
      <enabled>true</enabled>
      <errorStatus>VXLAN_GATEWAY_SETUP_FAILURE</errorStatus>
    </nwFabricFeatureStatus>
    

    Solución alternativa: Existen dos opciones para solucionar el error.

    • Opción 1: Quite la configuración de la VXLAN del clúster del host, solucione la configuración de la puerta de enlace subyacente en el grupo de direcciones IP (asegúrese de que la puerta de enlace esté configurada correctamente y de que se pueda establecer una comunicación con ella) y, a continuación, vuelva a configurar la VXLAN del clúster del host.

    • Opción 2: Realice los pasos siguientes.

      1. Solucione la configuración de la puerta de enlace subyacente en el grupo de direcciones IP; para ello, asegúrese de que la puerta de enlace esté configurada correctamente y de que se pueda establecer una comunicación con ella.

      2. Coloque el host (o los hosts) en modo de mantenimiento para asegurar que no haya tráfico de máquina virtual activo en el host.

      3. Elimine los VTEP de la VXLAN del host.

      4. Finalice el modo de mantenimiento del host. Al finalizar el modo de mantenimiento del host, se activa el proceso de creación de VTEP de la VXLAN en NSX Manager. NSX Manager intenta recrear los VTEP necesarios en el host.

  • Problema 1463767: En una implementación de Cross vCenter, es posible que una sección de configuración de firewall universal esté bajo (subordinada a) una sección de configuración local
    Si se traslada una instancia de NSX Manager secundaria al estado independiente (tránsito) y, a continuación, se la regresa al estado secundario, cualquier cambio en la configuración local que se haya hecho mientras se encontraba de forma temporal en modo independiente puede aparecer sobre las secciones de configuración universal replicadas heredadas de la instancia de NSX Manager principal. Esto genera la condición de error la sección universal debe estar sobre todas las demás secciones en las instancias de NSX Manager secundarias (universal section has to be on top of all other sections on secondary NSX Managers).

    Solución alternativa: Utilice la opción de la interfaz de usuario para mover las secciones hacia arriba o abajo de modo que la sección local se encuentre debajo de la universal.

  • Problema 1289348: Después de una actualización, es posible que las reglas de firewall y los servicios de introspección de red no estén sincronizados con NSX Manager
    Después de actualizar de NSX 6.0 a NSX 6.1 o 6.2, la configuración del firewall de NSX muestra el mensaje de error: error de sincronización/no sincronizado (synchronization failed / out of sync). La acción Forzar servicios de sincronización: Firewall (Force Sync Services: Firewall) no resuelve el problema.

    Solución alternativa: En NSX 6.1 y NSX 6.2, tanto los grupos de seguridad como los dvPortgroups pueden estar enlazados a un perfil de servicio, pero no los dos al mismo tiempo. Para resolver este problema, modifique los perfiles de servicio.

  • Problema 1462319: El VIB esx-dvfilter-switch-security ya no está presente en el resultado del comando "esxcli software vib list | grep esx"
    A partir de NSX 6.2, los módulos esx-dvfilter-switch-security se incluyen en el VIB esx-vxlan. Los únicos VIB de NSX instalados para la versión 6.2 son esx-vsip y esx-vxlan. Durante una actualización de NSX a 6.2, el VIB antiguo esx-dvfilter-switch-security se quita de los hosts ESXi.
    Desde NSX 6.2.3, se proporciona un tercer VIB, el esx-vdpi, junto con los VIB de NSX esx-vsip y esx-vxlan. Si la instalación se realiza correctamente, se mostrarán los 3 VIB.

    Solución alternativa: Ninguna.

  • Problema 1481083: Después de la actualización, es posible que los enrutadores lógicos con formación de equipos por conmutación por error explícita configurada no puedan reenviar correctamente los paquetes
    Cuando los hosts ejecutan ESXi 5.5, la directiva de formación de equipos de NSX 6.2 por conmutación por error explícita no es compatible con varios vínculos superiores activos en los enrutadores lógicos distribuidos.

    Solución alternativa: Altere la directiva de formación de equipos por conmutación por error explícita de modo que haya solo un vínculo superior activo y que los demás vínculos superiores se encuentren en modo en espera.

  • Problema 1485862: La desinstalación de NSX de un clúster de hosts a veces genera una condición de error
    Cuando se utiliza la acción Desinstalar (Uninstall) en la pestaña Instalación (Installation): Preparación del host (Host Preparation) es posible que ocurra un error y aparezca el mensaje eam.issue.OrphanedAgency en los registros de EAM de los hosts. Después de utilizar la acción Resolver (Resolve) y de reiniciar los hosts, el estado de error continúa a pesar de que se desinstalaron correctamente los VIB de NSX.

    Solución alternativa: Elimine la agencia huérfana de vSphere ESX Agent Manager (Administración [Administration]: Extensiones de vCenter Server [vCenter Server Extensions]: vSphere ESX Agent Manager).

  • Problema 1411275: vSphere Web Client no muestra la pestaña Redes y seguridad (Networking and Security) después de la copia de seguridad y restauración en NSX for vSphere 6.2
    Cuando realiza una operación de copia de seguridad y restauración después de la actualización a NSX for vSphere 6.2, vSphere Web Client no muestra la pestaña Redes y seguridad (Networking and Security).

    Solución alternativa: Cuando se restaura una copia de seguridad de NSX Manager, se cierra la sesión del Administrador de dispositivos (Appliance Manager). Espere unos minutos antes de iniciar sesión en vSphere Web Client.

  • Problema 1393889: El estado del servicio Data Security se muestra como Activo (UP) incluso si no hay conectividad IP
    Es posible que el dispositivo Data Security no haya recibido la dirección IP del DHCP o que esté conectado a un grupo de puertos incorrecto.

    Solución alternativa: Asegúrese de que el dispositivo Data Security obtenga la dirección IP del grupo de direcciones IP/DHCP y de que se pueda establecer una comunicación con él desde la red de administración. Compruebe que se haga ping hacia el dispositivo Data Security desde NSX/ESX correctamente.

  • No se enciende la máquina virtual de servicios implementada desde la pestaña Implementaciones de servicios (Service Deployments) en la página Instalación (Installation)

    Solución alternativa: Siga los pasos a continuación.

    1. Quite manualmente la máquina virtual de servicio del grupo de recursos Agentes de ESX (ESX Agents) en el clúster.
    2. Haga clic en Redes y seguridad (Networking and Security) y, a continuación, en Instalación (Installation).
    3. Haga clic en la pestaña Implementaciones de servicios (Service Deployments).
    4. Seleccione el servicio adecuado y haga clic en el icono Resolver (Resolve).
      Se vuelve a implementar la máquina virtual de servicio.

  • Problema 1764460: Después de completar la preparación del host, todos los miembros del clúster están listos, pero aparece de forma errónea que el estado del clúster es "No válido" (Invalid)
    Una vez que complete la preparación del host, todos los miembros de clúster muestran el estado correcto "Listo" (Ready), pero el estado del clúster aparece como "No válido" (Invalid). Se indica que debe reiniciar el host aunque ya lo hizo.

    Solución alternativa: Haga clic en el icono de advertencia rojo y seleccione Resolver (Resolve).

Problemas conocidos de NSX Manager
  • Nuevo Problema 1904842: NSX Manager no se está registrando con vCenter ni con Platform Service Controller
    NSX Manager no aparece en la interfaz de usuario y se produce un error en todas las llamadas de REST a NSX Manager.

    Solución alternativa: Reinicie el servicio de gestión de NSX o reinicie el dispositivo NSX Manager.

  • Nuevo Problema 1826225: El estado de servicio de las máquinas virtuales del servicio de partners aparece como "Desconocido" ("Unknown") en NSX Manager
    El estado de servicio de las máquinas virtuales del servicio de partners aparece como "Desconocido" ("Unknown") en NSX Manager. Este problema se produce cuando existen entradas obsoletas en la base de datos de las máquinas virtuales de partner.

    Solución alternativa: Póngase en contacto con el servicio de atención al cliente de VMware.

  • Nuevo Problema 1713669: El disco de NSX Manager se llena con los datos del IDFW

    Independientemente de si las reglas del IDFW se usan o no, los eventos de registro detectados por los servidores de registro de eventos (Event Log Servers) y por Guest Introspection se almacenan en la base de datos de NSX Manager y se conservan en dicha ubicación durante 30 días antes de que caduquen. En entornos con un gran volumen de actividad de inicio de sesión, la base de datos puede crecer y afectar al espacio del disco de NSX Manager.

    Solución alternativa: No hay solución. Si se detecta este problema, póngase en contacto con el soporte técnico de VMware.

  • Problema 1806368: En el caso de una conmutación por error de Cross-vCenter, la configuración DLR no se inserta en todos los hosts si se reutilizan controladores anteriores para un NSX Manager principal que presentara errores anteriormente y que vuelve a ser principal después de una conmutación por error.
    En una instalación de Cross-vCenter, cuando se produce un error en el NSX Manager principal, uno secundario pasa a ser principal y se implementa un nuevo clúster del controlador para su uso con el NSX Manager secundario que ahora es el principal. Cuando el NSX Manager principal vuelve a estar activo, se degrada el NSX Manager secundario y el primario se restaura. En este caso, si vuelve a utilizar los controladores existentes que se implementaron en este NSX Manager principal antes de la conmutación por error, la configuración DLR no se transmite a todos los hosts. Este problema no ocurre si, en su lugar, crea un nuevo clúster del controlador.

    Solución alternativa: Implemente un nuevo clúster del controlador para el NSX Manager principal restaurado.

  • Problema 1831131: Se produce un error en la conexión de NSX Manager con SSO al realizar la autenticación con el usuario LocalOS
    Se produce un error en la conexión de NSX Manager con SSO al realizar la autenticación con el usuario LocalOS y aparece el mensaje: "No se pudo establecer comunicación con NSX Manager. Póngase en contacto con el administrador" (Could not establish communication with NSX Manager. Please contact administrator).

    Solución alternativa: Agregue la función de administrador de organización para nsxmanager@localos, además de nsxmanager@domain.

  • Problema 1772911: El consumo de espacio de disco de NSX Manager aumenta rápidamente y el tamaño de las tablas de trabajos y tareas aumenta con el uso elevado de CPU
    La CPU en NSX Manager se encuentra constantemente al 100% o rozando esta cifra. Al ejecutar el comando show process monitor en la interfaz de línea de comandos de NSX Manager (CLI), se muestra el proceso Java que está consumiendo los mayores ciclos de CPU. El consumo de espacio de disco aumenta rápidamente con el aumento del tamaño de la base de datos, lo que provoca un rendimiento lento de NSX Manager.

    Solución alternativa: Póngase en contacto con el soporte técnico de VMware.

  • Problema 1441874: Se produce un error al actualizar un único NSX Manager en un entorno de vCenter Linked Mode
    En un entorno con varios VMware vCenter Server con múltiples NSX Managers, al seleccionar uno o varios NSX Managers desde vSphere Web Client > Redes y seguridad > Instalación > Preparación del host (vSphere Web Client > Networking and Security > Installation > Host Preparation), verá este error:
    "No se pudo establecer comunicación con NSX Manager. Póngase en contacto con el administrador" (Could not establish communication with NSX Manager. Please contact administrator).

    Solución alternativa: Consulte el artículo 2127061 de la base de conocimientos de VMware para obtener más información.

  • Problema 1696750: Para asignar una dirección IPv6 a NSX Manager a través de una API de PUT se deberá reiniciar el sistema
    Para cambiar la configuración de red en NSX Manager a través de https://{NSX Manager IP address}/api/1.0/appliance-management/system/network , se deberá reiniciar el sistema. Hasta que el sistema se reinicie, se mostrará la configuración existente.

    Solución alternativa: Ninguna.

  • Problema 1671067: El complemento de NSX no aparece en vCenter Web Client, mientras que el complemento ESXTOP está también instalado
    Tras implementar NSX y registrarlo correctamente en vCenter, el complemento de NSX no aparece en vCenter Web Client. Este problema está originado por un conflicto entre el complemento de NSX y el complemento ESXTOP.

    Solución alternativa: Elimine el complemento ESXTOP mediante este procedimiento:

    1. Compruebe que existe una copia de seguridad reciente de la máquina virtual de vCenter (sin modo inactivo)
    2. Elimine /usr/lib/vmware-vsphere-client/plugin-packages/esxtop-plugin
      rm -R /usr/lib/vmware-vsphere-client/plugin-packages/esxtop-plugin
    3. Elimine /usr/lib/vmware-vsphere-client/server/work
      rm -R /usr/lib/vmware-vsphere-client/server/work
    4. Reinicie el cliente web
      service vsphere-client restart
    5. (Opcional) Compruebe que no haya resultados al ejecutar el siguiente comando: "tail -f /var/log/vmware/vsphere-client/logs/eventlog.log | grep esx"
    6. Asegúrese de consolidar la instantánea de vCenter si es el método preferido de opción de restauración.

  • Problema 1486403: NSX Manager no acepta cadenas de búsqueda de DNS con delimitador de espacio
    NSX Manager no acepta cadenas de búsqueda de DNS con delimitador de espacio. Solo se puede utilizar la coma como delimitador. Por ejemplo, si el servidor DHCP anuncia eng.sample.com y sample.com para la lista de búsqueda de DNS, NSX Manager se configura con eng.sample.com sample.com.

    Solución alternativa: Utilice comas como separadores. NSX Manager solo acepta el separador coma como cadenas de búsqueda de DNS.

  • Problema 1529178: Si se carga un certificado de servidor que no incluye un nombre común, se mostrará un mensaje de "error interno del servidor"

    Si carga un certificado de servidor que no tenga un nombre común, aparecerá un mensaje de "error interno del servidor".

    Solución alternativa: Utilice un certificado de servidor que tenga tanto un SubAltName como un nombre común o, al menos, un nombre común.

  • Problema 1655388: La interfaz de usuario de la versión NSX Manager 6.2.3 se muestra en inglés en lugar de hacerlo en el idioma local cuando se usa el explorador IE11/Edge en sistemas operativos Windows 10 para los idiomas JA, CN y DE

    Al iniciar NSX Manager 6.2.3 con el explorador IE11/Edge en sistemas operativos Windows 10 para los idiomas JA, CN y DE, la interfaz se muestra en inglés.

    Solución alternativa:

    Realice los pasos siguientes:

    1. Inicie el Editor del Registro de Microsoft (regedit.exe) y diríjase a Equipo > HKEY_CURRENT_USER > SOFTWARE > Microsoft > Internet Explorer > International.
    2. Modifique el valor del archivo AcceptLanguage para aceptar el idioma local. Por ejemplo, si desea cambiar el idioma a DE, cambie el valor y asegúrese de que DE aparezca en el primer lugar.
    3. Reinicie el explorador e inicie sesión de nuevo en NSX Manager. De esta forma se muestra el idioma correcto.

  • Problema 1435996: Los archivos de registro exportados como CSV desde NSX Manager tienen la marca de tiempo de época en lugar de fecha y hora
    Los archivos exportados en formato .csv desde NSX Manager mediante vSphere Web Client incluyen una marca de tiempo de época en milisegundos, en lugar de mostrar la hora que correspondería a la zona horaria.

    Solución alternativa: Ninguna.

  • Problema 1644297: La operación de agregar o eliminar cualquier sección DFW de NSX principal crea dos configuraciones de DFW guardadas en NSX secundario
    En la configuración de Cross-vCenter, cuando se agrega una sección de DFW adicional local o universal al NSX Manager principal, se guardan dos configuraciones de DFW en el NSX Manager secundario. Aunque no afecta a ninguna función, este problema hará que se alcance más rápidamente el límite de configuraciones guardadas y que, posiblemente, se sobrescriban las configuraciones críticas.

    Solución alternativa: Ninguna.

  • Problema 1534606: No se puede cargar la página de preparación del host
    Al ejecutar Virtual Center en modo de conexión, cada VC debe estar conectado a un NSX Manager de la misma versión de NSX. Si las versiones de NSX son distintas, vSphere Web Client solo podrá comunicarse con el NSX Manager que esté ejecutando la versión posterior de NSX. Aparecerá un error similar al siguiente: "No se ha podido establecer la comunicación con NSX Manager. Póngase en contacto con el administrador (Could not establish communication with NSX Manager. Please contact administrator)" en la pestaña Preparación del host (Host Preparation).

    Solución alternativa: Deberá actualizar todos los NSX Managers a la misma versión del software de NSX.

  • Problema 1386874: No se muestra la pestaña Redes y seguridad (Networking and security) en vSphere Web Client
    Una vez que vSphere se actualizó a la versión 6.0, no se puede ver la pestaña Redes y seguridad (Networking and Security) cuando se inicia sesión en vSphere Web Client con el nombre de usuario raíz.

    Solución alternativa: Inicie sesión como administrator@vsphere.local o como cualquier otro usuario de vCenter que existía en vCenter Server antes de la actualización y cuyo rol se definió en NSX Manager.

  • Problema 1027066: Es posible que vMotion de NSX Manager muestre el mensaje de error "El adaptador de red 1 de la tarjeta Ethernet virtual no es compatible" (Virtual ethernet card Network adapter 1 is not supported)
    Se puede ignorar este error. Las redes funcionan correctamente después de vMotion.
  • Problema 1477041: La página de resumen del dispositivo virtual NSX Manager no muestra ningún nombre DNS
    Cuando se inicia sesión en el dispositivo virtual NSX Manager, la página Resumen (Summary) tiene un campo para el nombre DNS. Este campo permanece en blanco a pesar de que se definió un nombre DNS para el dispositivo NSX Manager.

    Solución alternativa: Puede ver el nombre de host y los dominios de búsqueda de NSX Manager en la página Administrar (Manage): Red (Network).

  • Problema 1460766: La interfaz de usuario de NSX Manager no cierra automáticamente la sesión después de cambiar la contraseña con la interfaz de línea de comandos de NSX
    Si se está conectado a NSX Manager y se acaba de cambiar la contraseña con la CLI, es posible continuar conectado a la interfaz de usuario de NSX Manager con la contraseña antigua. Por lo general, el cliente NSX Manager debería cerrar la sesión automáticamente si se agota el tiempo de espera de la sesión por inactividad.

    Solución alternativa: Cierre la sesión de la interfaz de usuario de NSX Manager y vuelva a iniciar sesión con la contraseña nueva.

  • Problema 1467382: No se puede editar un nombre de host de red
    Una vez que inicia sesión en el dispositivo virtual NSX Manager y se desplaza hasta Administración de dispositivos (Appliance Management), hace clic en Administrar configuración de dispositivos (Manage Appliance Settings) y en Red (Network) en la sección Configuración (Settings) para editar el nombre de host de red, es posible que aparezca un error de lista de nombres de dominio no válida. Esto sucede cuando los nombres de dominio especificados en el campo Buscar dominios (Search Domains) se separan con caracteres de espacios en blanco en lugar de comas. NSX Manager solo acepta nombres de dominio separados por coma.
    Solución alternativa: Realice los pasos siguientes:
    1. Inicie sesión en el dispositivo virtual NSX Manager.

    2. En Administración de dispositivos (Appliance Management), haga clic en Administrar configuración de dispositivos (Manage Appliance Settings).

    3. En el panel Configuración (Settings), haga clic en Red (Network).

    4. Haga clic en Editar (Edit) junto a Servidores DNS (DNS Servers).

    5. En el campo Buscar dominios (Search Domains), reemplace todos los caracteres de espacios en blanco por comas.

    6. Haga clic en Aceptar (OK) para guardar los cambios.

  • Problema 1436953: Se genera un evento falso del sistema incluso después de restaurar correctamente NSX Manager desde una copia de seguridad
    Después de restaurar correctamente NSX Manager desde una copia de seguridad, aparecen los eventos del sistema siguientes en vSphere Web Client cuando se desplaza hasta Redes y seguridad (Networking & Security): NSX Manager: Monitor (Supervisar): Eventos del sistema (System Events).
    • Restore of NSX Manager from backup failed (with Severity=Critical).

    • Restore of NSX Manager successfully completed (with Severity=Informational).

    Solución alternativa: Si el mensaje del evento del sistema final muestra que se completó correctamente, puede omitir los mensajes de eventos generados por el sistema.

  • Problema 1489768: Cambio en el comportamiento de la llamada API REST de NSX para agregar un espacio de nombre en un centro de datos
    En NSX 6.2, la llamada API REST POST https://<nsxmgr-ip>/api/2.0/namespace/datacenter/ devuelve una URL con una ruta de acceso absoluta, por ejemplo, http://198.51.100.3/api/2.0/namespace/api/2.0/namespace/datacenter/datacenter-1628/2. En las versiones anteriores de NSX, esta llamada API devolvía una URL con una ruta de acceso relativa, por ejemplo: /api/2.0/namespace/datacenter/datacenter-1628/2.

    Solución alternativa: Ninguna.

Problemas conocidos de redes lógicas y problemas conocidos de NSX Edge
  • Nuevo Problema 1878081: Algunas de las rutas se purgan de la tabla de reenvío en la puerta de enlace de servicios Edge
    En ciertos casos, algunas de las rutas se purgan de la tabla de reenvío. Esto provoca una interrupción del tráfico.

    Solución alternativa: Reinicie el nodo de Edge.

  • Problema 1798847: En una configuración Cross VC NSX, la actualización de puerto UDP de VXLAN puede quedar atascada para siempre.
    Si una instancia de NSX Manager principal no tiene configurada ninguna instancia de NSX Manager secundario, la actualización del puerto UDP de VXLAN se bloquea para siempre.

    Solución alternativa: La API de NSX Manager le permitirá reanudar el flujo de trabajo de actualización del puerto en la instancia de NSX Manager principal.

  • Problema 1698286: El VTEP de hardware de un entorno Cross-vCenter NSX solo es compatible con el NSX Manager principal
    En un entorno cross-vCenter NSX, las operaciones y las configuraciones de un conmutador de puerta de enlace de hardware solo son compatibles con la instancia principal de NSX Manager. Los conmutadores de puerta de enlace de hardware deben estar vinculados a conmutadores lógicos que no sean universales. Las configuraciones de puerta de enlace de hardware no son compatibles con instancias secundarias de NSX Manager.

    Solución alternativa: En un entorno Cross-vCenter NSX, se recomienda utilizar un puente L2 para conectar conmutadores lógicos a redes físicas.

  • Problema 1844966: El sistema de archivos de NSX Edge pasa a ser de solo lectura
    Si hay problemas en la conectividad del almacenamiento en el que se encuentra una instancia de Edge, el sistema de archivos de Edge puede pasar a ser de solo lectura para proteger el sistema de archivos del sistema operativo. Este es el comportamiento esperado en un servidor Linux. Consulte el artículo 2146870 de la base de conocimientos de VMware para obtener más información.

    Solución alternativa: Haga lo siguiente:

    1. Vuelva a implementar el Edge.
    2. Reinicie el Edge (ambos Edges en par HA).
    3. Fuerce la sincronización del Edge.

  • Problema 1799261: NSX Edge puede ejecutar una condición de cerebro dividido después de una actualización o reimplementación
    En el NSX Edge en espera, el comando de CLI show service highavailability muestra el estado de alta disponibilidad en "En espera" ("Standby"), pero el estado del motor de configuración aparece como "Activo" ("Active").

    Solución alternativa: Reinicie la instancia de NSX Edge en espera.

  • Problema 1777792: La conexión de IPSec falla si se establece un endpoint par como "CUALQUIERA" (ANY).
    Cuando la configuración de IPSec de NSX Edge establece un endpoint par remoto como CUALQUIERA (ANY), Edge actúa como un "servidor" IPSec y espera que los pares remotos inicien las conexiones. Sin embargo, si el iniciador envía una solicitud de autenticación mediante PSK y XAUTH, Edge muestra este mensaje de error: "Se recibió un mensaje del modo principal inicial en XXX.XXX.XX.XX:500, pero no se autorizó ninguna conexión conpolicy=PSK+XAUTH" ("initial Main Mode message received on XXX.XXX.XX.XX:500 but no connection has been authorized with policy=PSK+XAUTH") y no se puede establecer IPsec.

    Solución alternativa: Use la dirección IP o el FQDN del endpoint par específico en la configuración de la VPN IPsec en lugar de ANY.

  • Problema 1741158: Si crea un nuevo NSX Edge sin configurar y le aplica configuración, puede producirse una activación prematura del servicio de Edge.
    Si usa NSX API para crear un nuevo NSX Edge sin configurar, después realiza una llamada API para deshabilitar uno de los servicios de Edge (por ejemplo, asigna el valor false a dhcp-enabled) y, finalmente, aplica cambios de configuración al servicio de Edge deshabilitado, este se activará inmediatamente.

    Solución alternativa: Después de hacer cambios en la configuración de un servicio de Edge que quiere mantener en estado deshabilitado, realice de forma inmediata una llamada PUT para asignarle el valor "false" a la marca habilitada de ese servicio.

  • Problema 1758500: La ruta estática con varios saltos siguientes no se instala en las tablas de enrutamiento y reenvío de NSX Edge si al menos uno de los saltos siguientes configurados es la dirección IP de la vNIC de Edge
    Con ECMP y varias direcciones de salto siguiente, NSX permite que la dirección IP de la vNIC de Edge se configure como salto siguiente si al menos una de las direcciones IP de salto siguiente es válida. Esto se acepta sin errores ni advertencias, pero la ruta de la red se elimina de la tabla de reenvío/enrutamiento de Edge.

    Solución alternativa: No configure la dirección IP de la vNIC de Edge como salto siguiente en rutas estáticas si utiliza ECMP.

  • Problema 1733165: IPsec puede hacer que se eliminen rutas estáticas de la tabla de reenvío de NSX Edge
    Si se usa una subred a la que se puede acceder a través de una ruta dinámica como una subred remota para la configuración de IPsec, NSX Edge la elimina de la tabla de reenvío y no vuelve a instalarla aunque esta subred se elimine de la configuración de IPsec.

    Solución alternativa: Habilite/deshabilite el protocolo de enrutamiento o borre las relaciones de vecindad del enrutamiento.

  • Problema 1675659: Se prefieren enrutamientos estáticos flotantes a los dinámicos OSPF
    Se introduce un enrutamiento estático flotante de forma incorrecta en una tabla de enrutamiento de Edge cuando la Redistribución del enrutamiento (Route Redistribution) aparece habilitada aunque esté disponible un enrutamiento OSPF.

    Solución alternativa: Para solucionar este problema, deshabilite la redistribución del enrutamiento de estático a OSPF.
    Nota: Este problema no afecta a la ruta de datos. Consulte el artículo de la base de conocimientos 2147998 de VMware.

  • Problema 1716464: El equilibrador de carga NSX no enrutará las máquinas virtuales etiquetadas recientemente con una etiqueta de seguridad (Security).
    Si se implementan dos máquinas virtuales con una etiqueta dada y, a continuación, se configura un LB para enrutar a esa etiqueta, el LB se enrutará correctamente a esas dos máquinas virtuales. Sin embargo, si se implementa una tercera máquina virtual con esa etiqueta, el LB solo enrutará las dos primeras. Solución alternativa: Haga clic en Guardar (Save) en el Grupo LB (LB Pool). Esto hará que se vuelvan a examinar las máquinas virtuales y se empiece a enrutar a las nuevas máquinas virtuales etiquetadas.

  • Problema 1776073: Cuando Edge con AS local y privada envía enrutamientos a pares EBGP, todas las rutas privadas AS se eliminan de las actualizaciones de enrutamiento BGP enviadas.
    NSX tiene actualmente una limitación que evita que comparta la ruta AS completa con vecinos eBGP cuando la ruta AS solo contiene rutas AS privadas. Mientras que este es el comportamiento esperado en la mayoría de los casos, existen casos en los que el administrador pueda querer compartir rutas AS privadas con un vecino eBGP.

    Solución alternativa: No existe ninguna solución disponible para que Edge anuncie todas las rutas AS en la actualización de BGP.

  • Problema 1716545: Cambiar el tamaño del dispositivo de Edge no afecta a la reserva de memoria y CPU de Edge en espera

    Solo se asigna a la configuración de reserva la primera máquina virtual de Edge creada como parte de un par HA.
    Para configurar la misma reserva de memoria o CPU en ambas máquinas virtuales de Edge:

    • Use la API PUT https:// <NSXManager>/api/4.0/edgePublish/tuningConfiguration para enviar valores explícitos a ambas máquinas virtuales de Edge.
    • o bien
    • Deshabilite y vuelva a habilitar la alta disponibilidad de Edge, con lo que eliminará la segunda máquina virtual de Edge y volverá a implementar una nueva con las reservas predeterminadas.

    Solución alternativa: Ninguna.

  • Problema 1510724: Las rutas predeterminadas no se rellenan en los hosts tras la creación de un enrutador lógico distribuido universal (Universal Distributed Logical Router, UDLR)

    Tras cambiar NSX Manager del modo independiente al principal con el propósito de configurar Cross-vCenter en NSX for vSphere 6.2.x, es posible que observe estos síntomas:

    • Al crear un UDLR nuevo, las rutas predeterminadas no se rellenan en la instancia del host.
    • Las rutas se rellenan en la máquina virtual de control del UDLR, pero no en la instancia del host.
    • El comando show logical-router host host-ID dlr Edge-ID route no muestra las rutas predeterminadas debido a un error.

    Solución alternativa: Para solucionar este problema, consulte el artículo 2145959 de la base de conocimientos de VMware.

  • Problema 1492547: Aumenta el tiempo de convergencia cuando el enrutador de borde de área OSPF basado en NSX que tiene la dirección IP superior está apagado o se ha reiniciado
    Si un enrutador de borde de área NSSA que no tiene la dirección IP superior está apagado o se ha reiniciado, el tráfico se dirige rápidamente a otra ruta de acceso. Si un enrutador de borde de área NSSA que tiene la dirección IP superior está apagado o se ha reiniciado, el proceso para volver a dirigir el tráfico tardará varios minutos. El proceso OSPF se puede eliminar manualmente para reducir el tiempo de convergencia.

    Solución alternativa: Consulte el artículo 2127369 de la base de conocimientos de VMware.

  • Problema 1542416: La ruta de datos no funciona durante 5 minutos después de volver a implementar el borde y se produce una conmutación por error de HA con las subinterfaces
    Las operaciones de conmutación por error de HA o de reimplementación sufrirán cinco minutos de interrupción si se utilizan subinterfaces. No se aprecian problemas en las interfaces.

    Solución alternativa: No hay solución.

  • Problema 1706429: Los problemas de comunicación al habilitar la alta disponibilidad (HA) después de la implementación inicial del enrutador lógico (distribuido) pueden causar que ambos dispositivos enrutadores estén activos.
    Si implementa un enrutador lógico sin HA y la habilita posteriormente (al implementar un nuevo enrutador lógico) o si la deshabilita y luego la vuelve a habilitar, en algunas ocasiones, uno de los enrutadores lógicos no tiene una ruta conectada a la interfaz de HA. Esto provoca que ambos dispositivos estén en estado activo.

    Solución alternativa: En el enrutador lógico al que le falta la ruta conectada a la interfaz de HA, desconecte y vuelva a conectar el vNIC del dicho enrutador o reinícielo.

  • Problema 1461421: El resultado del comando "show ip bgp neighbor" para NSX Edge retiene el recuento del historial de las conexiones establecidas previamente

    El comando "show ip bgp neighbor" muestra el número de veces que la máquina de estado BGP cambió al estado establecido para un par ya existente. Cambiar la contraseña utilizada con la autenticación MD5 hace que la conexión de dicho par se elimine y se vuelva a crear, acción que a su vez limpiará los contadores. Este problema no sucede con Edge DLR.

    Solución alternativa: Para limpiar los contadores, ejecute el comando "clear ip bgp neighbor".

  • Problema 1676085: No se puede habilitar HA de Edge si se produce un error en la reserva de recursos

    A partir de NSX for vSphere 6.2.3, se producirá un error al habilitar la alta disponibilidad en una instancia de Edge existente cuando no se puedan reservar recursos suficientes para el dispositivo de la máquina virtual de Edge secundario. La configuración se restaurará a la última configuración conocida y efectiva. En las versiones anteriores, si se habilita HA antes de la implementación de Edge y se produce un error en la reserva de recursos, se crea la máquina virtual de Edge igualmente.

    Solución alternativa: Este cambio de comportamiento es correcto.

  • Problema 1656713: Faltan directivas de seguridad (SP) IPsec en NSX Edge tras conmutación por error de HA y el tráfico no fluye a través del túnel

    La conmutación En espera (Standby)>Activa (Active) no hará posible que el tráfico fluya en los túneles de IPsec.

    Solución alternativa: Deshabilite o habilite IPsec tras la conmutación de NSX Edge.

  • Problema 1624663: Después de hacer clic en "Configurar depuración avanzada" (Configure Advanced Debugging), la interfaz de usuario de VC se actualiza, pero el cambio no se mantiene

    Después de hacer clic en el ID de una instancia concreta de Edge > Configuración > Acción > Configurar depuración avanzada (Configuration > Action > Configure Advanced Debugging) la interfaz de usuario de VC se actualiza, pero el cambio no se mantiene.

    Solución alternativa: Diríjase directamente al menú de la lista de instancias de Edge, seleccione la instancia y haga clic en Acción > Configurar depuración avanzada (Action > Configure Advanced Debugging) para continuar con los cambios.

  • Problema 1354824: Cuando una máquina virtual de Edge está dañada o no se puede establecer la comunicación con ella por causas tales como un fallo en la alimentación, se activan los eventos del sistema al fallar la comprobación del estado de NSX Manager

    En la pestaña Eventos del sistema (System Events) se muestran los eventos con el estado "Error de comunicación con Edge" (Edge Unreachability). Puede que la lista de dispositivos NSX Edge siga mostrando Implementado (Deployed) en el Estado (Status).

    Solución alternativa: Utilice la APIhttps://NSX-Manager-IP-Address/api/4.0/edges/edgeId/status con detailedStatus=true.

  • Problema 1647657: Visualización de un máximo de 2.000 rutas por instancia VDR con los comandos para Mostrar (Show) en un host ESXi con visualización VDR

    Los comandos para Mostrar (Show) en un host ESXi con visualización VDR no muestran más de 2.000 rutas por instancia VDR, aunque haya en ejecución un número superior a este. Se trata solo de un problema de visualización, por lo que las rutas de datos funcionarán según lo esperado en todas las rutas.

    Solución alternativa: No hay solución.

  • Problema 1634215: El resultado de los comandos CLI de OSPF no indica si el enrutamiento está deshabilitado

    Cuando el protocolo OSPF está deshabilitado, el resultado de los comandos CLI de enrutamiento no muestra ningún mensaje que indique que "El protocolo OSPF está deshabilitado" (OSPF is disabled). El resultado está vacío:

    Solución alternativa: El comando show ip ospf muestra el estado correcto.

  • Problema 1663902: El cambio de nombre de una máquina virtual de NSX Edge interrumpe el flujo de tráfico a través de Edge

  • Problema 1647739: Implementar de nuevo una máquina virtual de Edge después de una operación de vMotion hace que la máquina virtual de DLR o Edge se vuelva a colocar en el clúster original.  

    Solución alternativa: Para ubicar la máquina virtual de Edge en un clúster o grupo de recursos diferente, use la interfaz de usuario de NSX Manager para configurar la ubicación que desee.

  • Problema 1463856: Cuando NSX Edge Firewall esté habilitado, se bloquearán las conexiones TCP existentes
    Las conexiones TCP están bloqueadas por el firewall de Edge con estado, ya que no se puede ver el protocolo inicial de enlace de tres vías.

    Solución alternativa: Para controlar los flujos existentes, siga estas instrucciones. Use la API REST de NSX para habilitar la marca "tcpPickOngoingConnections" en la configuración global del firewall. Esto cambia el firewall de un modo estricto a un modo más permisivo. El siguiente paso es habilitar el firewall. Una vez seleccionadas las conexiones existentes (esto puede producirse unos minutos después de habilitar el firewall), vuelva a establecer la marca "tcpPickOngoingConnections" en falso (false) para que el firewall funcione en modo estricto. (Esta configuración es persistente.)

    PUT /api/4.0/edges/{edgeId}/firewall/config/global
    <globalConfig>
    <tcpPickOngoingConnections>true</tcpPickOngoingConnections>
    </globalConfig>
  • Problema 1374523: Es necesario reiniciar ESXi o ejecutar [services.sh restart] tras la instalación del VIB de VXLAN para que los comandos de VXLAN estén disponibles al utilizar esxcli

    Tras la instalación de VXLAN VIB, debe reiniciar ESXi o bien ejecutar el comando [services.sh restart] para que los comandos de VXLAN estén disponibles al utilizar esxcli.

    Solución alternativa: En vez de utilizar esxcli, utilice localcli.

  • Problema 1642087: Después de modificar el valor del parámetro securelocaltrafficbyip en la extensión VPN IPsec, falla el reenvío a las redes de destino

    Al utilizar una puerta de enlace de servicios NSX Edge, se produce lo siguiente:

    • Después de cambiar el valor securelocaltrafficbyip a 0 en la pantalla Editar VPN IPsec (Edit IPsec VPN) de la interfaz de usuario de NSX, no funciona el reenvío a una subred remota del túnel VPN IPsec
    • Después de cambiar este parámetro, ya no se muestra la información correcta de una subred remota en la tabla de enrutamiento IP

    Solución alternativa: Deshabilite y vuelva a habilitar el servicio VPN IPSec. A continuación, compruebe que se muestre la información de enrutamiento prevista en la CLI y la interfaz de usuario.

  • Problema 1525003: La restauración de una copia de seguridad de NSX Manager con una contraseña incorrecta falla silenciosamente, ya que no se puede acceder a carpetas raíz esenciales

    Solución alternativa: Ninguna.

  • Problema 1637639: Al utilizar el cliente PHAT de la VPN SSL de Windows 8, la IP virtual no se asigna desde el grupo de IP
    En Windows 8, la dirección IP virtual no se asigna, como cabría esperar, desde el grupo de IP cuando se asigna una nueva dirección IP mediante la puerta de enlace de servicios Edge o cuando el grupo de IP cambia para usar un intervalo de IP diferente.

    Solución alternativa: Este problema solo ocurre en Windows 8. Use un sistema operativo Windows diferente para no experimentar este problema.

  • Problema 1483426: El estado del servicio de VPN L2 e IPsec se muestra como inactivo aunque el servicio no esté habilitado
    En la ficha Configuración (Settings) de la interfaz de usuario, el estado del servicio L2 aparecerá inactivo mientras que en API, el estado de servicio aparecerá activo. El servicio IPsec y VPN L2 se muestran siempre inactivos en la ficha Configuración (Settings) si no se actualiza la página de la interfaz de usuario.

    Solución alternativa: Actualizar la página.

  • Problema 1446327: Es posible que el tiempo de espera finalice en algunas aplicaciones basadas en TCP si se conectan a través de NSX Edge
    El tiempo de espera de inactividad predeterminado de la conexión TCP es 3600 segundos. NSX Edge elimina la inactividad de las conexiones que supere al tiempo de espera de inactividad y desecha dichas conexiones.

    Solución alternativa:
    1. Si la aplicación tiene un tiempo de inactividad relativamente largo, active los keepalive de TCP en los hosts configurando keep_alive_interval en menos de 3600 segundos.
    2. Aumente el tiempo de espera de inactividad de Edge TCP a más de 2 horas a través de la siguiente API REST de NSX. Puede aumentarlo a 9000 segundos: URL de la API de NSX:
      /api/4.0/edges/{edgeId}/systemcontrol/config PUT Method <systemControl> <property>sysctl.net.netfilter.nf_conntrack_tcp_timeout_established=9000</property> </systemControl>

  • Problema 1534602: La interfaz de usuario no muestra el modo plano de gestión de Edge (VIX/MSGBUS) y no ofrece la posibilidad de cambiar de VIX a MSGBUS
    Cuando una aplicación de Edge está en el modo VIX, no se puede seleccionar para incluir en DFW, y los comandos CLI centralizados tardan mucho más en ejecutarse en comparación con el modo MSGBUS
    Solución alternativa: Compruebe que el clúster en el que Edge está implementado está listo para NSX y su "NSX Manager para el agente firewall" está en estado "Activo", y vuelva a implementar Edge.

  • Problema 1498243: El enrutador lógico distribuido anuncia un salto siguiente incorrecto de la ruta predeterminada cuando el filtro vecino BGP está establecido en "DENEGAR, CUALQUIERA, FUERA" (DENY, ANY, OUT)
    Con la opción Origen predeterminado (Default Originate) habilitada en un enrutador lógico distribuido (DLR) de NSX, establecer un filtro vecino BGP "DENEGAR, CUALQUIERA, FUERA" (DENY, ANY, OUT) en el DLR hace que el DLR anuncie una dirección de salto siguiente incorrecta para la ruta predeterminada. Este error se produce solo cuando se agrega un filtro vecino BGP con los atributos siguientes:
    • Acción: DENEGAR (DENY)
    • Red: CUALQUIERA (ANY)
    • Dirección: FUERA (OUT)

    Solución alternativa: Ninguna.

  • Problema 1471561: No se establecen relaciones de vecinos entre BGP y OSPF con enrutadores conectados directamente. 
    El enrutamiento dinámico no funciona según se esperaba con los enrutadores conectados directamente cuando existan rutas ECMP para dicha red.

    Solución alternativa: Reinicie Edge O BIEN elimine y vuelva a crear la interfaz de vNIC asociada.

  • Problema 1089238: Las rutas LIF del enrutador lógico se anuncian mediante la puerta de enlace de servicios Edge ascendente aunque el protocolo OSPF del enrutador lógico esté deshabilitado
    La puerta de enlace de servicios Edge ascendente sigue anunciando los LSA externos de OSPF que se conocieron por las interfaces conectadas del enrutador lógico aunque el protocolo OSPF del enrutador lógico esté deshabilitado.

    Solución alternativa: Deshabilite la redistribución de rutas conectadas a OSPF manualmente y publique antes de deshabilitar el protocolo OSPF. Esto garantiza que las rutas se retiren correctamente.

  • Problema 1499978: Los mensajes de syslog de Edge no llegan al servidor syslog remoto
    Inmediatamente después de la implementación, el servidor syslog de Edge no puede resolver los nombres de host de ningún servidor syslog remoto configurado.

    Solución alternativa: Configure los servidores de Syslog remotos con sus direcciones IP o utilice la interfaz de usuario para forzar la sincronización de Edge.

  • Problema 1489829: Los ajustes de configuración del cliente DNS del enrutador lógico no se aplicaron por completo luego de la actualización de la API Edge REST

    Solución alternativa: Cuando utilice una API REST para configurar el reenviador de DNS (resolución), realice los pasos siguientes:

    1. Especifique la configuración de los servidores XML del cliente DNS de tal forma que coincida con la configuración del reenviador de DNS.

    2. Habilite el reenviador de DNS y asegúrese de que la configuración del reenviador sea la misma que la configuración de los servidores del cliente DNS especificada en la configuración de XML.

  • Problema 1243112: Mensaje de error y validación ausentes en salto siguiente no válido en la ruta estática, con ECMP habilitado
    Cuando se intenta agregar una ruta estática, con ECMP habilitado, si la tabla de enrutamiento no contiene una ruta predeterminada y hay un salto siguiente al que no se puede acceder en la configuración de la ruta estática, no se muestra ningún mensaje de error y la ruta estática no se instala.

    Solución alternativa: Ninguna.

  • Problema 1281425: Si una máquina virtual NSX Edge con una subinterfaz respaldada por un conmutador lógico se elimina a través de la interfaz de usuario de vCenter Web Client, es posible que la ruta de datos no funcione para una máquina virtual nueva que se conecta al mismo puerto
    Cuando se elimina la máquina virtual Edge a través de la interfaz de usuario de vCenter Web Client (y no desde NSX Manager), el tronco de VXLAN configurado en dvPort por canal opaco no se restablece. Esto se debe a que NSX Manager administra la configuración del tronco.

    Solución alternativa: Elimine manualmente la configuración del tronco de VXLAN con los pasos siguientes:

    1. Desplácese hasta el Explorador de objetos administrados de vCenter (vCenter Managed Object Browser); para ello, escriba lo siguiente en la ventana del explorador:
      https://<vc-ip>/mob?vmodl=1
    2. Haga clic en Contenido (Content).
    3. Recupere el valor dvsUuid con los pasos siguientes.
      1. Haga clic en el vínculo rootFolder (por ejemplo, group-d1(Datacenters)).
      2. Haga clic en el vínculo del nombre del centro de datos (por ejemplo, datacenter-1).
      3. Haga clic en el vínculo networkFolder (por ejemplo, group-n6).
      4. Haga clic en el vínculo del nombre de DVS (por ejemplo, dvs-1)
      5. Copie el valor de uuid.
    4. Haga clic en DVSManager y, a continuación, en updateOpaqueDataEx.
    5. En selectionSet, agregue el XML siguiente.
      <selectionSet xsi:type="DVPortSelection">
        <dvsUuid>value</dvsUuid>
        <portKey>value</portKey> <!--port number of the DVPG where trunk vnic got connected-->
      </selectionSet>
    6. En opaqueDataSpec, agregue el XML siguiente.
      <opaqueDataSpec>
        <operation>remove</operation>
        <opaqueData>
          <key>com.vmware.net.vxlan.trunkcfg</key>
          <opaqueData></opaqueData>
        </opaqueData>
      </opaqueDataSpec>
    7. Establezca isRuntime en falso.
    8. Haga clic en Invocar método (Invoke Method).
    9. Repita los pasos 5 a 8 para cada puerto troncal configurado en la máquina virtual Edge eliminada.

  • Problema 1637939: No se admiten certificados MD5 al implementar puertas de enlace de hardware
    Al implementar conmutadores de puerta de enlace de hardware como VTEP para realizar un puente de VLAN L2 a VXLAN lógico, los conmutadores físicos admiten al menos certificados SHA1 SSL para la conexión OVSDB entre el controlador NSX y el conmutador OVSDB.

    Solución alternativa: Ninguna.

  • Problema 1637943: No se admiten los modos de replicación Híbrido (Hybrid) o Multidifusión (Multicast) para los VNI que tienen enlaces de puerta de enlace de hardware
    Los conmutadores de puerta de enlace de hardware, cuando se usan como VTEP para realizar un puente de VXLAN a VLAN L2, admiten solo el modo de replicación Unidifusión (Unicast).

    Solución alternativa: Utilice solo el modo de replicación Unidifusión (Unicast).

Problemas conocidos de los servicios de seguridad
  • Problema 1474650: Para los usuarios de NetX, los hosts ESXi 5.5.x y 6.x reciben una pantalla de diagnóstico de color púrpura con el mensaje ALERT: NMI: 709: NMI IPI received
    Cuando se transmite o se recibe un gran número de paquetes a través de una máquina virtual de servicio, DVFilter sigue dominando la CPU, lo que provoca una pérdida de latidos y aparece una pantalla de diagnóstico de color púrpura. Consulte el artículo 2149704 de la base de conocimientos de VMware para obtener más información.

  • Problema 1741844: Detectar direcciones de vNIC con varias direcciones IP mediante la intromisión ARP provoca el consumo total de la CPU.
    Este problema aparece cuando el vNIC de una máquina virtual se configura con varias direcciones IP y la intromisión ARP se habilita para la detección de IP. El módulo de detección de IP envía actualizaciones de vNIC-IP a NSX Manager continuamente para cambiar la asignación de vNIC-IP en todas las máquinas virtuales configuradas con varias direcciones IP.

    Solución alternativa: No hay solución. La función de intromisión de ARP admite actualmente solo una dirección IP por vNIC. Para obtener más información, consulte la sección Detección de IP para máquinas virtuales en la Guía de administración de NSX.

  • Problema 1689159: La función Agregar regla (Add Rule) de Flow Monitoring no funciona correctamente en los flujos de ICMP.
    Al agregar una regla de Flow Monitoring, el campo Servicios (Services) se quedará vacío si no le asigna ICMP explícitamente. Como resultado, es posible que tenga que agregar una regla con el tipo de servicio "CUALQUIERA" (ANY).

    Solución alternativa: Actualice este campo para que refleje el tráfico de ICMP.

  • Problema 1620460: NSX no puede evitar que los usuarios creen reglas en la sección de reglas de Service Composer
    En vSphere Web Client, la interfaz Redes y seguridad: La interfaz de Firewall no puede evitar que los usuarios agreguen reglas a la sección de reglas de Service Composer. Los usuarios deben poder agregar reglas antes o después de la sección Service Composer, pero no dentro de ella.

    Solución alternativa: No use el botón "+" a nivel de regla global para agregar reglas a la sección correspondiente de Service Composer.

  • Problema 1682552: No se informa sobre los eventos del umbral de la CPU, memoria o CPS de Distributed Firewall (DFW)
    Aunque el umbral de DFW para la CPU, memoria y CPS esté configurado para enviar informes, no se envían los correspondientes a los eventos del umbral cuando dichos umbrales están cruzados.

    Solución alternativa:

    • Inicie sesión en cada host ESXi y reinicie el proceso del plano de control de DFW con el siguiente comando:
    • /etc/init.d/vShield_Stateful_Firewall restart
    • Verifique el estado ejecutando el siguiente comando:
    • /etc/init.d/vShield_Stateful_Firewall status
    • Aparecerá un resultado similar al siguiente:
    • "vShield-Stateful-Firewall is running"

    Nota: Debe tener cuidado al realizar esta operación ya que volverá a enviar todas las reglas DFW a todos los filtros. Si existe un número elevado de reglas, es posible que tarde en aplicarlas en todos los filtros.

  • Problema 1717635: Se produce un error en la operación de la configuración del firewall si más de un clúster están presentes en el entorno y los cambios se realizan en paralelo
    En un entorno con varios clústeres, si dos o más usuarios modifican la configuración del firewall continuamente en bucle (por ejemplo, reglas o secciones Agregar o Eliminar), se puede producir un error en algunas operaciones y el usuario verá una respuesta de API similar a:
    <?xml version="1.0" encoding="UTF-8"? >
    neutron-server.log.1:70282:2016-08-23 17:58:23.429 30787 ERROR vmware_nsx.plugins.nsx_v.plugin
    <error>
    <details> org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update; nested exception is javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update </details>
    <errorCode>258
    </errorCode>
    </error>

    Solución alternativa: Evite la modificación simultánea de la configuración del firewall.

  • Problema 1717994: Al consultar la API del estado del firewall distribuido (DFW) aparece un mensaje 500 error interno del servidor de forma intermitente
    Si se realiza una consulta de API del estado del DFW mientras se agrega un nuevo host en un clúster preparado para dicho host, se produce un error de tipo "500 error interno del servidor" al intentar consultar la API varias veces y, a continuación, devuelve la respuesta correcta una vez que el host comienza a obtener los VIB instalados.

    Solución alternativa: No use la API del estado del DFW hasta que el nuevo host esté correctamente preparado.

  • Problema 1686036: No se pueden agregar, editar o eliminar las reglas de firewall si se elimina la sección predeterminada
    Si la sección Layer2 o Layer3 predeterminadas están eliminadas, se produce un error al publicar una regla de firewall.

    Solución alternativa: No elimine la regla predeterminada. Si la configuración con la regla predeterminada se guardó como borrador, realice los siguientes pasos:

    1. Elimine la configuración completa del firewall con la siguiente llamada de DELETE API.
    2. https://<NSX Manager IP>/api/4.0/firewall/globalroot-0/config
      Esto restaurará la sección predeterminada del firewall.
    3. Cargue en el firewall el borrador guardado de las reglas de firewall con la sección predeterminada.

  • Problema 1628220: Las observaciones de NetX o DFW no se muestran en el receptor
    Es posible que Traceflow no muestre las observaciones de NetX y DFW en el lado del receptor si se cambió el puerto del conmutador asociado con la vNIC de destino. Este no será fijo para las versiones de vSphere 5.5. En las versiones vSphere 6.0 y posteriores no se produce este problema.

    Solución alternativa: No deshabilite la vNIC. Reinicie la máquina virtual.

  • Problema 1626233: Cuando la máquina virtual de servicio (SVM) de NetX coloca paquetes, Traceflow no genera observaciones de colocación

    La sesión de Traceflow se inicia después de enviar el paquete a la máquina virtual de servicio (SVM) de NetX. Cuando la SVM coloca paquetes, Traceflow no genera observaciones de colocación.

    Solución alternativa: No hay solución. Si el paquete de Traceflow no se vuelve a insertar, se puede asumir que la SVM colocó el paquete.

  • Problema 1632235: Durante la instalación de Guest Introspection, la lista desplegable de redes solo muestra "Especificadas en host" (Specified on Host)
    Cuando se instala Guest Introspection con la licencia de solo antivirus de NSX y la licencia de vSphere Essential o estándar, la lista desplegable de redes mostrará solo la lista de los grupos de puertos DV existentes. Esta licencia no es compatible con la creación de DVS.

    Solución alternativa: Antes de instalar Guest Introspection en un host de vSphere con una de estas licencias, especifique primero la red en la ventana "Configuración de máquina virtual agente" (Agent VM Settings).

  • Problema 1652155: No se pueden crear ni migrar reglas de firewall mediante las API de REST bajo ciertas condiciones y aparece un error HTTP 404

    No es compatible agregar ni migrar reglas de firewall mediante las API de REST en las siguientes condiciones:

    • Creando reglas de firewall como una operación masiva cuando se configure el valor autosavedraft=true.
    • Agregando reglas de firewall en diferentes secciones simultáneamente.

    Solución alternativa: Configure como "falso" (false) el parámetro autoSaveDraft en la llamada de API cuando se creen o se migren reglas de firewall de forma masiva.

  • Problema 1509687: La longitud de la URL admite hasta 16.000 caracteres cuando se asigna una etiqueta de seguridad única a muchas máquinas virtuales de forma simultánea en una llamada de API
    Una etiqueta de seguridad única no se puede asignar a un gran número de máquinas virtuales de forma simultánea con una única API si la longitud de la URL supera los 16.000 caracteres.

    Solución alternativa: Para optimizar el rendimiento, etiquete hasta un máximo de 500 máquinas virtuales en una única llamada.

  • Problema 1662020: La operación de publicación puede fallar, lo que resulta en un mensaje "Error en la última publicación en el host número de host" (Last publish failed on host host number) en las secciones General y Servicios de seguridad de partners (Partner Security Services) de la interfaz de usuario de DFW

    Después de cambiar cualquier regla, la interfaz de usuario muestra el mensaje "Error en la última publicación en el host número de host" (Last publish failed on host host number). Es posible que los hosts enumerados en la interfaz de usuario no dispongan de la versión correcta de las reglas de firewall, lo que resulta en una falta de seguridad o interrupciones en el funcionamiento de la red.

    Este problema se produce normalmente en las situaciones siguientes:

    • Después de actualizar de una versión anterior a la versión más reciente de NSX-v.
    • Al sacar un host de un clúster y volver a introducirlo en él.
    • Al mover un host de un clúster a otro.

    Solución alternativa: Para realizar la recuperación, debe forzar la sincronización de los clústeres afectados (solo firewall).

  • Problema 1481522: No se admite la migración de los borradores de reglas de firewall de la versión 6.1.x a la versión 6.2.3, ya que no son compatibles entre estas versiones

    Solución alternativa: Ninguna.

  • Problema 1491046: La dirección IP IPv4 no se aprueba automáticamente cuando la directiva SpoofGuard está establecida en Confiar en el primer uso [Trust On First Use (TOFU)] en VMware NSX for vSphere 6.2.x

    Solución alternativa: Consulte el artículo de la base de conocimientos 2144649 de VMware.

  • Problema 1628679: Con el firewall basado en la identidad, la máquina virtual de los usuarios eliminados continúa formando parte del grupo de seguridad

    Cuando se elimina un usuario de un grupo del servidor de AD, la máquina virtual a la que el usuario está conectado continúa formando parte del grupo de seguridad (SG). De esta forma se conservan las directivas de firewall en la vNIC de la máquina virtual en el hipervisor, con lo que se otorga al usuario acceso completo a los servicios.

    Solución alternativa: Ninguna. Por diseño, este es el comportamiento previsto.

  • Problema 1462027: En las implementaciones de Cross vCenter NSX, se replican varias versiones de las configuraciones de firewall guardadas en las instancias de NSX Manager secundarias
    La sincronización universal guarda varias copias de la configuración universal en las instancias de NSX Manager secundarias. La lista de configuraciones guardadas contiene varios borradores creados por la sincronización a través de los NSX Manager con el mismo nombre y en el mismo momento o con una diferencia de 1 segundo.

    Solución alternativa: Ejecute la llamada API para eliminar los borradores duplicados.

    DELETE : https://<nsxmgr-ip>/api/4.0/firewall/config/drafts/

    Busque los borradores que se deben eliminar; para ello vea todos los borradores:

    GET: https://<nsxmgr-ip>/api/4.0/firewall/config/drafts

    En los resultados de muestra siguientes, los borradores 143 y 144 tienen el mismo nombre y se crearon a la misma hora, por lo tanto, son duplicados. Lo mismo sucede con los borradores 127 y 128: tienen el mismo nombre y una diferencia de 1 segundo; también son duplicados.

    <firewallDrafts>
        <firewallDraft id="144" name="AutoSaved_Wednesday, August 5, 2015 11:08:40 PM GMT" timestamp="1438816120917"> 
            <description>Auto saved configuration</description>
            <preserve>false</preserve>
            <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
            <mode>autosaved</mode>
        </firewallDraft>
        <firewallDraft id="143" name="AutoSaved_Wednesday, August 5, 2015 11:08:40 PM GMT" timestamp="1438816120713">
            <description>Auto saved configuration</description>
            <preserve>false</preserve>
            <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
            <mode>autosaved</mode>
        </firewallDraft>
       <firewallDraft id="128" name="AutoSaved_Wednesday, August 5, 2015 9:08:02 PM GMT" timestamp="1438808882608">
            <description>Auto saved configuration</description>
            <preserve>false</preserve>
            <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
            <mode>autosaved</mode>
        </firewallDraft>
        <firewallDraft id="127" name="AutoSaved_Wednesday, August 5, 2015 9:08:01 PM GMT" timestamp="1438808881750">
            <description>Auto saved configuration</description>
            <preserve>false</preserve>
            <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
            <mode>autosaved</mode>
        </firewallDraft>
    </firewallDrafts>
    

  • Problema 1449611: Cuando una directiva de firewall en Service Composer no está sincronizada debido a un grupo de seguridad eliminado, no se puede solucionar la regla de firewall en la interfaz de usuario

    Solución alternativa: En la interfaz de usuario, puede eliminar la regla de firewall no válida y, a continuación, volver a agregarla. O, en la API, puede solucionar la regla de firewall eliminando el grupo de seguridad no válido. Después, sincronice la configuración del firewall: Seleccione Service Composer: Directivas de seguridad (Security Policies) y en cada directiva de seguridad que tenga reglas de firewall asociadas, haga clic en Acciones (Actions) y seleccione Sincronizar config. de firewall (Synchronize Firewall Config). Para evitar este problema, modifique las reglas de firewall para que no refieran a los grupos de seguridad antes de eliminar los grupos de seguridad.

  • Problema 1557880: Es posible que falten las reglas de la Capa 2 (L2) si se modificó la dirección MAC de una máquina virtual utilizada en las reglas
    Dado que la optimización de reglas de L2 está activada de forma predeterminada, las reglas de L2 con los campos de origen y de destino especificados (otra opción distinta a "cualquiera" ["any"]) se aplicarán a los vNIC (o filtros) solo si la dirección MAC del vNIC coincide con la lista de direcciones MAC de origen o destino. No se aplicarán estas reglas de L2 en los hosts con máquinas virtuales que no coincidan con las direcciones MAC de origen o destino.

    Solución alternativa: Para que se apliquen las reglas de Capa 2 a todos los vNIC (o filtros), establezca uno de los campos de fuente o destino en "cualquiera" (any).

  • Problema 1496273: La interfaz de usuario permite la creación de reglas de firewall de NSX de entrada/salida que no se pueden aplicar a las instancias de Edge
    El cliente web, incorrectamente, permite la creación de una regla de firewall de NSX aplicada a una o más instancias de NSX Edge cuando la regla tiene tráfico que se traslada en dirección "de entrada" o "de salida", y cuando PacketType es IPV4 o IPV6. La interfaz de usuario no debería permitir la creación de tales reglas, dado que NSX no puede aplicarlas a las instancias de NSX Edge.

    Solución alternativa: Ninguna.

  • Problema 1557924: Se permite consumir el conmutador lógico universal en el campo AppliedTo de una regla de DFW local
    Cuando un conmutador lógico universal se utiliza como miembro de un grupo de seguridad, la regla de DFW puede utilizar este grupo en el campo AppliedTo. Esto aplica indirectamente la regla en el conmutador lógico universal, lo que no se debería permitir porque puede provocar un comportamiento desconocido de estas reglas.

    Solución alternativa: Ninguna.

  • Problema 1559971: La lista de exclusión del firewall de Cross-vCenter NSX no se publica si el firewall está deshabilitado en un clúster
    En Cross-vCenter NSX, la lista de exclusión del firewall no se publica en ningún clúster si el firewall está deshabilitado en uno de los clústeres.

    Solución alternativa: fuerce la sincronización que afectó a los dispositivos NSX Edge.

  • Problema 1407920: Error al volver a publicar la regla de firewall tras utilizar ELIMINAR API (DELETE API)
    Si elimina la configuración entera del firewall a través del método DELETE API y a continuación intenta volver a publicar todas las reglas de un borrador de reglas de firewall previamente guardado, la regla publicada no funcionará.

  • Problema 1534585: Error al publicar reglas de Distributed Firewall (DFW) tras eliminar un objeto de referencia en VMware NSX for vSphere 6.1.x y 6.2.x

    Solución alternativa: Si esto sucede, consulte el artículo 2126275 de la base de conocimientos.

  • Problema 1494718: No se pueden crear reglas universales nuevas y las reglas universales existentes no se pueden editar desde la interfaz de usuario de Flow Monitoring

    Solución alternativa: No se pueden agregar ni editar reglas universales desde la interfaz de usuario de Flow Monitoring. Se deshabilitará automáticamente EditRule.

  • Problema 1442379: Configuración del firewall de Service Composer no sincronizada
    En NSX Service Composer, si cualquier directiva de firewall no es válida (por ejemplo, si se eliminó un grupo de seguridad que se utilizaba en una regla de firewall en ese momento), eliminar o modificar otra directiva de firewall hace que Service Composer pierda la sincronización y se muestra el mensaje de error Configuración de firewall no sincronizada.

    Solución alternativa: Elimine cualquier regla de firewall no válida y, a continuación, sincronice la configuración del firewall. Seleccione Service Composer: Directivas de seguridad (Security Policies) y en cada directiva de seguridad que tenga reglas de firewall asociadas, haga clic en Acciones (Actions) y seleccione Sincronizar config. de firewall (Synchronize Firewall Config). Para evitar este problema, solucione o elimine siempre las configuraciones de firewall no válidas antes de realizar más cambios de configuración en el firewall.

  • Problema 1066277: El nombre de la directiva de seguridad no permite más de 229 caracteres
    El campo Nombre de directiva de seguridad (Security Policy Name) en la pestaña Directiva de seguridad (Security Policy) de Service Composer puede aceptar hasta 229 caracteres. Esto se debe a que los nombres de las directivas están antecedidos por un prefijo.

    Solución alternativa: Ninguna.

  • Problema 1443344: Algunas versiones de VM-Series de Networks de terceros no funcionan con la configuración predeterminada de NSX Manager
    Algunos componentes de NSX 6.1.4 o versiones posteriores deshabilitan SSLv3 de forma predeterminada. Antes de realizar la actualización, compruebe por favor que todas las soluciones de terceros integradas en la implementación de NSX no dependan de la comunicación de SSLv3. Por ejemplo, algunas versiones de la solución VM-Series de Palo Alto Networks requieren compatibilidad con SSLv3, por lo que es necesario comprobar los requisitos de la versión con los proveedores.

  • Problema 1660718: El estado de las directivas de Service Composer aparece "En curso" (In Progress) en la interfaz de usuario y "Pendiente" (Pending) en el resultado de la API

    Solución alternativa: Ninguna.

  • Problema 1620491: El estado de sincronización a nivel de directivas en Service Composer no muestra el estado de publicación de las reglas de una directiva

    Cuando se crea o se modifica una directiva, Service Composer muestra un estado correcto que solo indica el estado de persistencia. No refleja si las reglas se publicaron correctamente en el host.

    Solución alternativa: Utilice la interfaz de usuario del firewall para ver el estado de la publicación.

  • Problema 1317814: Service Composer pierde la sincronización cuando se realizan cambios en la directiva mientras una de las instancias de Service Manager está inactiva
    Si se realizan cambios de directivas mientras una o varias instancias de Service Manager estén inactivas, dichos cambios no se realizarán y la sincronización de Service Composer se detendrá.

    Solución alternativa: Asegúrese de que Service Manager responda y, a continuación, emita una sincronización forzada desde Service Composer.

  • Problema 1070905: No se puede quitar y volver a agregar un host a un clúster protegido por Guest Introspection y soluciones de seguridad de terceros
    Si se desconecta y quita un host de vCenter Server con el fin de quitarlo de un clúster protegido por Guest Introspection y soluciones de seguridad de terceros, es posible que surjan problemas si se intenta volver a agregar el mismo host al clúster.

    Solución alternativa: Para quitar un host de un clúster protegido, primero coloque el host en modo de mantenimiento. Después, mueva el host a un clúster sin protección o fuera de todos los clústeres y, a continuación, desconecte y quite el host.

  • Problema 1648578: NSX obliga agregar un clúster, una red o un almacenamiento cuando se crea una nueva instancia del servicio basada en un host NetX
    Cuando cree una nueva instancia del servicio desde vSphere Web Client para los servicios basados en el host NetX como el firewall, IDS e IPS, se le obliga a agregar un clúster, una red o un almacenamiento aunque no sean necesarios.

    Solución alternativa: Al crear una nueva instancia del servicio, puede agregar cualquier información del clúster, de la red o del almacenamiento para rellenar los campos. Esto le permitirá crear la instancia del servicio y podrá continuar con el procedimiento.

  • Problema 1772504: Service Composer no admite los grupos de seguridad con el conjunto MAC
    Service Composer admite el uso de los grupos de seguridad en las Configuraciones de directivas (Policy configurations). Si un grupo de seguridad contiene un conjunto MAC, Service Composer lo aceptará sin problemas, pero se producirá un error al aplicar reglas a ese conjunto MAC específico. Esto es porque Service Composer funciona en Layer3 y no admite construcciones de Layer2. Tenga en cuenta que, si un grupo de seguridad tiene un conjunto IP y un conjunto MAC, el valor de la IP seguirá siendo efectivo pero el conjunto MAC se ignorará. No existe ningún problema al hacer referencia a un grupo de seguridad que contenga un conjunto MAC. El usuario debe saber que el conjunto MAC se ignorará.

    Solución alternativa: Si la intención del usuario es crear reglas del firewall con un conjunto MAC, debe usar una configuración DFW Layer2/Ethernet en lugar de Service Composer.

  • Problema 1718726: No se puede forzar la sincronización de Service Composer después de que un usuario haya eliminado manualmente la sección Directiva de Service Composer con una DFW REST API

    En un entorno de Cross-vCenter NSX, se producirá un error cuando un usuario intenta forzar la sincronización de la configuración de NSX Service Composer si solo había una sección Directiva y dicha sección (la sección de directiva administrada por Service Composer) se eliminó previamente a través de una llamada REST API.

    Solución alternativa: No elimine la sección de directiva administrada por Service Composer a través de una llamada REST API (tenga en cuenta que la interfaz de usuario ya evita la eliminación de esta sección).

Problemas conocidos de servicios de supervisión
  • Problema 1655593: Falta el estado en el panel de control de NSX al conectarse con los roles de auditor o administrador de seguridad

    Al consultar el panel de control de NSX como auditor o administrador de seguridad, se muestra el mensaje de error "El usuario no está autorizado para ver el objeto ... y la función ... Compruebe el alcance del acceso a objetos y los permisos sobre funciones del usuario" (User is not authorized to access object ... and feature ... Please check object access scope and feature permissions for the user). Por ejemplo, es posible que el auditor no pueda ver el "Estado de conmutador lógico (Logical Switch Status) en el panel de control.

    Solución alternativa: Ninguna.

  • Problema 1466790: No se pueden elegir las máquinas virtuales en la red con puente mediante la herramienta NSX Traceflow
    Con la herramienta NSX Traceflow, no se pueden seleccionar las máquinas virtuales que no están asociadas a un conmutador lógico. Esto significa que las máquinas virtuales en una red con puente L2 no se pueden elegir por nombre de máquina virtual como dirección de origen o destino para una inspección de Traceflow.

    Solución alternativa: En el caso de las máquinas virtuales asociadas a redes con puente L2, utilice la dirección IP o la dirección MAC de la interfaz que desea especificar como destino en una inspección de Traceflow. No puede elegir máquinas virtuales asociadas a redes con puente L2 como origen.

Problemas conocidos de interoperabilidad de soluciones
  • Problema 1840744: En el host de VMware ESXi 6.0.0, se muestra una pantalla de diagnóstico de color púrpura después de que una máquina virtual se bloquee en un bucle de reinicio
    Este problema se produce a causa de la condición de carrera en los eventos crear/destruir de dvfilter que se crea por el bloqueo de la máquina virtual en un bucle de reinicio. - Para obtener más información, consulte el artículo 2149782 de la base de conocimientos de VMware.

    Solución alternativa: Este problema se resuelve en la revisión 03 de VMware ESXi 6.0 y versiones posteriores, disponible en la página de descargas de VMware.
    Para solucionar este problema, si no desea realizar esta actualización, apague la máquina virtual afectada.

  • Problema 1568861: La implementación de NSX Edge falla durante cualquier implementación de Edge que se realice desde una celda vCD que no controle el agente de escucha de VC

    La implementación de NSX Edge falla durante cualquier implementación de Edge que se realice desde una celda vCD que no controle el agente de escucha de VC. Además, se produce un error desde vCD en las acciones de NSX Edge, entre las que se incluye una nueva implementación.

    Solución alternativa: Implemente un NSX Edge desde la celda vCD, que controla el agente de escucha de VC.

  • Problema 1530360: Tras la conmutación por error de una máquina virtual de NSX Manager, Site Recovery Manager (SRM) notifica de forma incorrecta un error de tiempo de espera.

    Tras la conmutación por error de una máquina virtual de NSX Manager, SRM notifica de forma incorrecta un error de tiempo de espera a la espera de VMware Tools. En este caso, VMware Tools está en realidad funcionando durante los 300 segundos de tiempo de espera.

    Solución alternativa: Ninguna.

Problemas conocidos de NSX Controller
  • Problema 1845087: La API de NSX Controller se verá afectada de forma negativa si la latencia de disco es muy alta
    Es posible que la API de NSX Controller no responda dentro del límite de tiempo de NSX Manager si la latencia de E/S es demasiado alta para el almacenamiento utilizado por NSX Controller. A su vez, esto puede afectar a la actualización y a otras funciones de NSX Controller. El complemento de red y seguridad de vSphere Web Client mostrará el mensaje de error "Latencia de disco de controlador alta" (High controller disk latency) si la gravedad supera un determinado límite.

    Solución alternativa: Para solucionar este problema, VMware recomienda utilizar un disco SSD y un disco duro local dedicados.

  • Problema 1765354: <deployType> es una propiedad obligatoria, pero no se usa
    <deployType> es una propiedad obligatoria, pero no se usa y no tiene ningún significado.

  • Problema 1760102: Es posible que las máquinas virtuales no puedan comunicarse después de eliminar NSX Controller y volver a implementarlo para recuperarse de un estado de falta de almacenamiento
    Un NSX Controller para el entorno de vSphere 6.2.x puede entrar en el modo de solo lectura en caso de que se interrumpa el almacenamiento. Si elimina y vuelve a implementar el controlador para recuperarse de este estado, es posible que se produzca un error en las máquinas virtuales al comunicarse. Si se produce una interrupción en el almacenamiento de un controlador, se espera que se recupere del modo de solo lectura al reiniciarlo, pero esto no sucede actualmente en NSX.

    Solución alternativa: Reinicie el servicio de gestión de NSX.

  • Problema 1516207: Es posible que los controladores se aíslen cuando se vuelva a habilitar la comunicación IPsec en un clúster de NSX Controller
    Si el clúster de un controlador de NSX está configurado para permitir comunicaciones entre controladores de forma clara (IPsec está deshabilitado) y posteriormente se vuelve a habilitar la comunicación IPsec, es posible que una o varios controladores se aíslen del clúster debido principalmente a que no coincide la clave previamente compartida ("PSK"). Cuando esto ocurre, es posible que la API de NSX no pueda cambiar la configuración de IPsec de los controladores.

    Solución alternativa:

    Siga estos pasos para solucionar este problema:

    1. Deshabilite IPSec a través de NSX API.

      PUT /2.0/vdn/controller/node

      <controllerNodeConfig>
        <ipSecEnabled>false</ipSecEnabled>
      </controllerNodeConfig>

    2. Vuelva a habilitar IPsec mediante NSX API.

      PUT /2.0/vdn/controller/node

      <controllerNodeConfig>
        <ipSecEnabled>true</ipSecEnabled>
      </controllerNodeConfig>

    Aplique estas prácticas recomendadas para evitar este problema:

    • Use siempre NSX API para deshabilitar IPsec. No se admite el uso de la CLI de NSX Controller para deshabilitar IPsec.
    • Verifique siempre que todos los controladores estén activos antes de usar la API para cambiar la configuración de IPsec.

  • Problema 1306408: Los registros de NSX Controller se deben descargar secuencialmente
    Los registros de NSX Controller no se pueden descargar simultáneamente. Incluso cuando se realiza una descarga desde varios controladores, se debe esperar a que la descarga del controlador actual finalice antes de iniciar la descarga del controlador siguiente. Además, se debe tener en cuenta que no se puede cancelar una descarga de registro una vez que se inició.

    Solución alternativa: Espere a que finalice la descarga del registro del controlador actual antes de iniciar otra descarga de registro.