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

|

Documento actualizado el 20 de mayo de 2016
VMware NSX for vSphere 6.2.1 | Publicado el 17 de diciembre de 2015 | Compilación 3300239 |

Contenido de las notas de la versión

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

Novedades

Vea las novedades y los cambios de NSX 6.2.1 y 6.2.0.

Nuevo en la versión 6.2.1

La versión 6.2.1 corrige una serie de errores que se han documentado en la sección Problemas resueltos.

  • Soluciones de la versión 6.1.5: la versión incluye las mismas soluciones críticas que se incluían en el contenido de NSX for vSphere 6.1.5.

  • Se ha introducido un nuevo comando 'show control-cluster network ipsec status' que permite a los usuarios inspeccionar el estado del protocolo de seguridad de Internet (IPsec).

  • Estado de conectividad: la interfaz de usuario de NSX Manager ahora muestra el estado de conectividad del clúster de NSX Controller.

  • Compatibilidad con el complemento vRealize Orchestrator para NSX 1.0.3: con la versión NSX 6.2.1, se ha introducido la versión 1.0.3 del complemento NSX-vRO para su uso con vRealize Automation 7.0.0. Este complemento incluye soluciones que mejoran el rendimiento cuando vRealize Automation 7.0 utiliza NSX for vSphere 6.2.1 como punto final de seguridad y red.

  • Desde la versión 6.2.1, NSX Manager realiza una consulta de cada nodo del controlador en el clúster para obtener información de conexión entre dicho controlador y los otros controladores del clúster.
    Se proporciona en los resultados de API REST de NSX (comando "GET https://[NSX-MANAGER-IP-ADDRESS]/api/2.0/vdn/controller"), que ahora muestra el estado de conexión entre los nodos del controlador. Si NSX Manager detecta que la conexión entre dos nodos del controlador se ha interrumpido, se genera un evento del sistema para avisar al usuario.

  • Service Composer presenta una API que permite a los usuarios configurar la creación automática de borradores de firewall para los flujos de trabajo de Service Composer.
    Esta opción se puede activar o desactivar utilizando REST API, y los cambios se pueden guardar después de reiniciar el sistema. Cuando la opción está deshabilitada, no se crea ningún borrador en Distributed Firewall para los flujos de trabajo de la directiva. Esto limita el número de borradores que se crean automáticamente en el sistema y ofrece un mejor rendimiento.

Nuevo en la versión 6.2.0

NSX for vSphere 6.2.0 ha incluido las siguientes características nuevas y modificadas:

  • Cross vCenter Networking and Security

    • NSX 6.2 con vSphere 6.0 es compatible con Cross vCenter NSX donde los conmutadores lógicos (logical switches, LS), los enrutadores lógicos distribuidos (distributed logical routers, DLR) y Distributed Firewall (DFW) pueden implementarse en varias instancias de vCenter para habilitar funciones de seguridad y redes lógicas de aplicaciones con cargas de trabajo (máquinas virtuales) que abarcan varias instancias de vCenter o varias ubicaciones físicas.

    • Directiva de firewall coherente entre varias instancias de vCenter: Las secciones de reglas de firewall (Firewall Rule Sections) en NSX ahora se pueden marcar como "Universal", por lo cual las reglas definidas en estas secciones se replican en varias instancias de NSX Manager. Esto simplifica los flujos de trabajo que involucran la definición de una directiva de firewall coherente que abarque varias instalaciones de NSX.

    • Cross vCenter vMotion con DFW: Las máquinas virtuales que tienen directivas definidas en las secciones "Universal" se pueden mover entre hosts que pertenecen a distintas instancias de vCenter que implementan una directiva de seguridad coherente.

    • Grupos de seguridad universales: Los grupos de seguridad en NSX 6.2 basados en dirección IP, conjunto IP, dirección MAC y conjunto MAC se pueden utilizar ahora en las reglas universales, por lo que los grupos y la pertenencia a grupos se sincronizan en varias instancias de NSX Manager. Esto mejora la coherencia entre las definiciones de grupos de objetos en varias instancias de NSX Manager y permite la aplicación de directivas coherentes.

    • Conmutador lógico universal (Universal Logical Switch, ULS): Esta nueva funcionalidad, incorporada en NSX 6.2 como parte de Cross vCenter NSX, permite la creación de conmutadores lógicos que pueden abarcar varias instancias de vCenter, lo que permite al administrador de red crear un dominio L2 contiguo para una aplicación o una empresa.

    • Enrutador lógico distribuido universal (Universal Distributed Logical Router, UDLR): Esta nueva funcionalidad, incorporada en NSX 6.2 como parte de Cross vCenter NSX, permite la creación de enrutadores lógicos distribuidos que pueden abarcar varias instancias de vCenter. Los enrutadores lógicos distribuidos universales permiten el enrutamiento en los conmutadores lógicos universales que se describieron anteriormente. Además, el UDLR de NSX tiene la capacidad de enrutamiento norte-sur localizado según la ubicación física de las cargas de trabajo.

  • Mejoras en la solución de problemas y el funcionamiento

    • Nueva herramienta para la solución de problemas Traceflow: Traceflow es una herramienta para la solución de problemas que ayuda a identificar si el problema está en la red virtual o física. Proporciona la capacidad de rastrear un paquete desde el origen hasta el destino y ayuda a observar cómo ese paquete pasa a través de las diversas funciones de red en la red virtual.

    • Flow Monitoring y separación de IPFIX: En NSX 6.1.x, NSX era compatible con los informes IPFIX, pero los informes IPFIX podían habilitarse solo si el informe de flujo a NSX Manager también estaba habilitado. A partir de NSX 6.2.0, estas características son independientes. En NSX 6.2.0 y posteriores, se puede habilitar IPFIX de manera independiente de la supervisión del flujo en NSX Manager.

    • Nuevos comandos para la solución de problemas y supervisión de CLI en la versión 6.2: Consulte el artículo de la base de conocimientos 2129062 para obtener más información.

    • CLI central: La CLI central reduce el tiempo de solución de problemas de las funciones de red distribuidas. Los comandos se ejecutan en la línea de comandos de NSX Manager y recuperan información de las controladoras, los hosts y NSX Manager. Esto permite acceder y comparar la información rápidamente desde varios orígenes. La CLI central brinda información sobre conmutadores lógicos, enrutadores lógicos, Distributed Firewall y perímetros.

    • El comando ping de la CLI agrega el tamaño configurable del paquete y la marca no fragmentar: A partir de NSX 6.2.0, el comando ping de la CLI de NSX ofrece opciones para especificar el tamaño del paquete de datos (sin incluir el encabezado ICMP) y para establecer la marca no fragmentar. Consulte Referencia de la CLI de NSX para ver más detalles.

    • Mostrar estado de los canales de comunicación: NSX 6.2.0 incluye la capacidad de supervisar el estado del canal de comunicación. El estado de mantenimiento del canal entre NSX Manager y el agente de firewall, entre NSX Manager y el agente de plano de control, y entre el host y NSX Controller se puede ver desde la interfaz de usuario de NSX Manager. Además, el canal de comando del host ofrece una mayor tolerancia a errores.

    • CLI de cliente de VPN L2 Edge independiente: Antes de implementar NSX 6.2, se podía configurar un cliente de VPN L2 para NSX Edge independiente solo a través del ajuste ‘deploy OVF’ proporcionado por el centro virtual. Se agregaron los comandos específicos para una instancia independiente de NSX Edge a fin de permitir la configuración con la interfaz de línea de comandos.

  • Enrutamiento y redes lógicas

    • Interoperabilidad de puente L2 con enrutador lógico distribuido: Con VMware NSX for vSphere 6.2, los puentes L2 ahora pueden participar en el enrutamiento lógico distribuido. La red VXLAN a la que está conectada la instancia de puente se utiliza para conectar la instancia de enrutamiento con la instancia de puente.

    • Compatibilidad con prefijos /31 en las interfaces de ESG y DLR según RFC 3021.

    • Compatibilidad mejorada de solicitud DHCP retransmitida en el servidor DHCP ESG.

    • Capacidad de preservar los encabezados/ID de VLAN dentro de las redes virtuales de NSX.

    • Coincidencia exacta para filtros de redistribución: El filtro de redistribución tiene el mismo algoritmo de coincidencia que la ACL, por lo que la coincidencia del prefijo es exacta de forma predeterminada (excepto si se utilizan las opciones LE o GE).

    • Compatibilidad con distancia administrativa para ruta estática.

    • Capacidad para habilitar, reducir o deshabilitar la comprobación por interfaz en Edge.

    • Mostrar ruta de acceso AS en comando de CLI show ip bgp.

    • Exclusión de interfaz de HA de la redistribución a los protocolos de enrutamiento en la máquina virtual de control de DLR.

    • La sincronización forzada del enrutador lógico distribuido (distributed logical router, DLR) evita la pérdida de datos del tráfico de enrutamiento de Este a Oeste en el DLR. El puente y el enrutamiento de Norte a Sur pueden seguir teniendo interrupciones.

    • Ver perímetro activo en par HA: En el cliente web NSX 6.2, se puede ver si un dispositivo NSX Edge es el dispositivo activo o el de copia de seguridad en un par HA.

    • Compatibilidad de API REST con filtro de ruta de acceso inversa (rp_filter) en Edge: Con la API REST de control del sistema, rp_filter sysctl se puede configurar a través de la interfaz de usuario y también se expone a través de la API REST para interfaces y subinterfaces de vNIC. Consulte la documentación de NSX API para obtener más información.

    • Comportamiento de los filtros de ruta BGP del prefijo IP GE y prefijo IP LE: En NSX 6.2, se hicieron las mejoras siguientes a los filtros de ruta BGP:

      • No se permiten las palabras clave LE/GE: En la dirección de red de ruta nula (definida como CUALQUIERA [ANY] o en formato CIDR 0.0.0.0/0), las palabras clave menor-o-igual-que (LE) y mayor-o-igual-que (GE) ya no se permiten. En versiones anteriores, estas palabras clave estaban permitidas.

      • Los valores LE y GE en el rango de 0 a 7 ahora se toman como válidos. En las versiones anteriores, este rango no era válido.

      • En un prefijo de ruta específico, ya no se puede especificar un valor GE mayor que el valor de LE especificado.

  • Servicios Edge y de redes

    • Se cambió el nombre de la interfaz de administración de DLR a interfaz de HA. Se hizo esto para resaltar el hecho de que los keepalive de HA viajan por esta interfaz y de que las interrupciones en el tráfico de esta interfaz pueden provocar una condición de cerebro dividido.

    • Mejoras en la supervisión del estado del equilibrador de carga: Proporciona una supervisión de estado granular que brinda información sobre errores, realiza un seguimiento de la última comprobación de estado y de cambio de estado, e informa sobre los motivos de los errores.

    • Compatibilidad con rango de puertos de grupo y VIP: Habilita la compatibilidad del equilibrador de carga con las aplicaciones que requieren un rango de puertos.

    • Cantidad máxima aumentada de direcciones IP virtuales (VIP): La compatibilidad con VIP aumenta a 1024.

  • Mejoras en el servicio de seguridad

    • Nuevos mecanismos de detección de dirección IP para máquinas virtuales: La aplicación autoritativa de directivas de seguridad según los nombres de máquinas virtuales u otros atributos basados en vCenter requiere que NSX conozca la dirección IP de la máquina virtual. En NSX 6.1 y anteriores, la detección de dirección IP para cada máquina virtual dependía de la presencia de VMware Tools (vmtools) en esa máquina virtual o de la autorización manual de la dirección IP para esa máquina virtual. NSX 6.2 incorpora una opción para detectar la dirección IP de las máquinas virtuales al realizar la detección desde el hipervisor. Estos mecanismos de detección nuevos permiten a NSX aplicar las reglas de Distributed Firewall basadas en objetos en máquinas virtuales que no tengan VMware Tools instalado.

  • Interoperabilidad de soluciones

    • Compatibilidad con las topologías de vSphere 6.0 Platform Services Controller: NSX ahora es compatible con Platform Services Controller (PSC), además de con las configuraciones de PSC integradas ya compatibles.

    • Compatibilidad con el complemento vRealize Orchestrator para NSX: NSX 6.2 es compatible con el complemento NSX-vRO para integración de NSX con vRealize Orchestrator.

Requisitos del sistema e instalación

Producto o componente Versión recomendada
NSX for vSphere 6.2.1
vSphere 5.5U3 o 6.0U1
Guest Introspection Las características basadas en Guest Introspection y Network Introspection en NSX son compatibles con versiones específicas de VMware Tools (VMTools). Para activar el componente de controlador opcional Network Introspection de NSX que se incluye con VMware Tools, debe actualizar a una de las versiones siguientes:
  • VMware Tools 5.1 P07 y posteriores

  • VMware Tools 5.5 P04 y posteriores

  • VMware Tools 6.0 P01 y posteriores

  • VMware Tools 10.0 y posteriores

vRealize Orchestrator Complemento NSX-vRO 1.0.3

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

Notas sobre la actualización

  • Rutas de acceso de la actualización:

    • Desde NSX 6.x: Consulte la matriz de interoperabilidad de VMware: Rutas de acceso de la actualización para acceder a estas rutas. Tenga en cuenta que un número de versión superior no es indicador de una ruta de acceso de actualización admitida.

    • Para los sitios web de Cross-vCenter: Si realiza una actualización de Cross-vCenter NSX, consulte la sección Actualizaciones de Cross vCenter más adelante en este documento.

    • Desde vCNS 5.x: No se admiten las actualizaciones directas de vCNS 5.x a NSX 6.2.1. En su lugar, si utiliza el paquete de actualización de NSX 6.2.2 publicado el 31 de marzo de 2016 o en una fecha posterior, es posible que pueda actualizar directamente VMware vCloud Network and Security (vCNS) 5.1.x o 5.5.x a la versión NSX 6.2.2. Para obtener instrucciones, acceda a la Guía de actualización de NSX en la sección sobre actualizar vCloud Networking and Security 5.5.x a la versión NSX 6.2.

    • Desde NSX 6.1.6: No existe compatibilidad para las actualizaciones desde NSX 6.1.6 a NSX 6.2.0, 6.2.1 o 6.2.2.

    • Desde NSX 6.1.5: No se admiten las actualizaciones de NSX 6.1.5 a NSX 6.2.0. No se recomiendan las actualizaciones de NSX 6.1.5 a NSX 6.2.1. En su lugar, VMware recomienda actualizar a la versión 6.2.2 o superior para obtener las últimas actualizaciones de seguridad.

  • Para validar que su actualización a la versión 6.2.x se ha realizado correctamente, consulte este artículo de la base de conocimientos 2134525.

  • Actualización como parte de una actualización de producto de VMware más amplia: cuando actualiza NSX en contexto con otras actualizaciones de productos VMware, como vCenter y ESXi, es importante seguir la secuencia de actualización compatible documentada en este artículo 2109760 de la base de conocimientos.

  • 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: Los requisitos de memoria y CPU para instalar y actualizar NSX Manager han cambiado de NSX 6.1.x a NSX 6.2.x. Consulte Requisitos del sistema para NSX en la documentación de instalación de NSX 6.2 o actualización de NSX 6.2 .

  • 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.0, 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 está disponible. 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.

  • 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.
  • Actualizaciones de Cross vCenter: La Guía de actualización de NSX no ofrece instrucciones de actualización para sitios web que ejecutan Cross vCenter NSX. Siga las instrucciones que aparecen a continuación para actualizar la instalación de Cross vCenter NSX:

    1. Actualice NSX Manager según las instrucciones incluidas en la Guía de actualización de NSX. Actualice primero el NSX Manager principal y, a continuación, actualice todos los NSX Manager secundarios. Debe actualizar todos los NSX Manager a la misma versión. VMware no admite conjuntos de NSX Manager con versiones mezcladas en una única instalación de Cross vCenter NSX.
    2. Actualice las controladoras NSX Controller según las instrucciones incluidas en la Guía de actualización de NSX. Le recomendamos que actualice las controladoras en la misma ventana de mantenimiento que actualizó NSX Manager.
    3. Siga la Guía de actualización de NSX para completar la actualización, en la sección sobre cómo actualizar los clústeres del host a NSX 6.2.

  • Actualizaciones de vCNS: Antes de actualizar VMware vCloud Network and Security 5.x a VMware NSX for vSphere 6.2: Si desea actualizar a VMware NSX for vSphere 6.2 a partir de VMware vCloud Network and Security 5.5.x, compruebe si falta la información del nombre del puerto del vínculo superior en las tablas mediante la ejecución de la llamada API REST siguiente:

    GET https://<nsxmgr-IP>/api/2.0/vdn/switches
    En el resultado, busque el campo uplinkPortName. Por ejemplo:

    <?xml version="1.0" encoding="UTF-8"?>
    <vdsContexts>
       <vdsContext>
          <switch>
             <objectId>dvs-22</objectId>
          <objectTypeName>VmwareDistributedVirtualSwitch</objectTypeName>
             <nsxmgrUuid>4236F6CA-3B1A-56BE-4B55-1EF82B8CA12D</nsxmgrUuid>
             <revision>2</revision>
             <type>
                <typeName>VmwareDistributedVirtualSwitch</typeName>
             </type>
             <name>1-vds-20</name>
             <scope>
                <id>datacenter-3</id>
                <objectTypeName>Datacenter</objectTypeName>
                <name>datacenter-1</name>
             </scope>
             <clientHandle />
             <extendedAttributes />
          </switch>
          <mtu>1600</mtu>
          <teaming>FAILOVER_ORDER</teaming>
          <uplinkPortName>uplink2</uplinkPortName>
          <promiscuousMode>false</promiscuousMode>
       </vdsContext>
    </vdsContexts>
    

    Si el resultado de este comando contiene, al menos, un nombre de puerto de vínculo superior para cada conmutador distribuido de vSphere, puede proceder con la actualización. Si en el resultado falta el nombre del puerto de vínculo superior, consulte el artículo de la base de conocimientos 2129200.

Problemas conocidos

Los problemas conocidos se agrupan de la siguiente manera:

Problemas conocidos generales

Algunos informes de Log Insight no se admiten en NSX 6.2
Debido a la incompatibilidad entre NSX 6.2 y el paquete de contenido de vRealize para NSX, NSX 6.2 no admite los siguientes informes de vRealize Log Insight:

  • En el panel de control: NSX for vSphere-Infraestructura: El host - Controlador: No se admite el widget de errores de comunicación
  • En el panel de control: Conmutador lógico-Descripción general, no se admiten los siguientes widgets:
    • Conmutador lógico (crear eventos de auditoría)
    • Conmutador lógico (actualizar eventos de auditoría)
    • Conmutador lógico (eliminar eventos de auditoría)
  • En el panel de control: Enrutador lógico-Descripción general, no se admiten los siguientes widgets:
    • Enrutador lógico (crear eventos de auditoría)
    • Enrutador lógico (actualizar eventos de auditoría)

Solución alternativa: Ninguna. Consulte el artículo de la base de conocimientos 2143058 de VMware para obtener información actualizada.

Es posible que falten las reglas de la capa 2 (L2) si se ha modificado 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 L2 a todos los vNIC (o filtros), uno de los campos de fuente o destino debe estar establecido en "cualquiera" ("any").

NSX tiene un límite de longitud de URL de 16.000 caracteres si los usuarios quieren asignar una etiqueta de seguridad única a x máquinas virtuales de forma simultánea en una llamada de API
Si la longitud de la URL es superior a 16.000 caracteres, los usuarios no pueden asignar una etiqueta de seguridad única al número de máquinas virtuales x de forma simultánea utilizando una llamada de API. La longitud de la URL debe tener un máximo de 16.000 caracteres.

Solución alternativa:

  1. La longitud de la URL debe ser inferior a 16.000 caracteres.

  2. El rendimiento se optimiza cuando aproximadamente 500 máquinas virtuales se etiquetan en una única llamada. Etiquetar más máquinas virtuales en una única llamada puede ocasionar problemas de rendimiento.

Discrepancia entre estado de servicio notificado en interfaz de usuario y estado de servicio notificado en API
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.

Solución alternativa: Actualizar la página.

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.

El usuario debe descargar los registros de NSX Controller de forma secuencial
Se pueden descargar los registros de NSX Controller para la solución de problemas. Debido a un problema conocido, no se puede descargar más de un registro de la controladora de forma simultánea. Incluso cuando se realiza una descarga desde varias controladoras, se debe esperar a que la descarga de la controladora actual finalice antes de iniciar la descarga de la controladora 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.

Los archivos de registro exportados como CSV desde NSX Manager tienen la marca de tiempo de época en lugar de fecha y hora
Cuando se exportan archivos de registro, como CSV, desde NSX Manager con vSphere Web Client, es posible observar que los archivos de registro tienen la marca de tiempo de época en milisegundos en lugar de la hora adecuada según la zona horaria.

Solución alternativa: Ninguna.

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. Consulte el artículo de la base de conocimientos 2129191 para obtener más información.

Flow Monitoring descarta flujos que exceden el límite de 2 millones de flujos cada 5 minutos
NSX Flow Monitoring retiene registros de hasta 2 millones de flujos. Si los hosts generan más de 2 millones de registros en 5 minutos, los flujos nuevos se descartan.

Tenga en cuenta que NSX Flow Monitoring está preparado para la producción. No obstante, solo es aplicable a contextos con requisitos inferiores de rendimiento/conexión por segundo. También se puede utilizar para la solución de problemas, además de para crear reglas para duraciones limitadas. Los contextos con requisitos de rendimiento superiores pueden experimentar problemas como, por ejemplo, uso de la CPU elevado en NSX Manager, desbordamiento en el bus de mensajes RMQ y error al implementar actualizaciones de directivas. Además, se han detectado problemas con grandes cargas de trabajo UDP. Para la recopilación de información de flujo en curso a nivel de empresa, IPFIX es el enfoque recomendado. Recuerde que una vez que Flow Monitoring esté deshabilitado, es posible que transcurran hasta 15 días antes de que se puedan depurar los datos de flujo en la base de datos.

Solución alternativa: Ninguna.

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.

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.

En las implementaciones de Cross vCenter NSX, se replican varias versiones de las configuraciones 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>

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.

No se puede encender la máquina virtual invitada
Cuando se enciende una máquina virtual invitada, es posible que se muestre el error En este momento, no están implementadas todas las máquinas virtuales de agente necesarias (All required agent virtual machines are not currently deployed).

Solución alternativa: Realice los pasos siguientes:

  1. En vSphere Web Client, haga clic en Inicio (Home) y, a continuación, en Administración (Administration).
  2. En Solución (Solution), seleccione Extensión de vCenter Server (vCenter Server Extension).
  3. Haga clic en vSphere ESX Agent Manager y, a continuación, haga clic en la pestaña Administrar (Manage).
  4. Haga clic en Resolver (Resolve).

Problemas conocidos de instalación y actualización

Antes de la actualización, lea la sección Notas sobre la actualización, más arriba en este documento.

Durante una actualización de Cross-vCenter, NSX se desconecta del VC principal tras la actualización de NSX 6.2 a 6.2.1

Solución alternativa: Elimine los paquetes de NSX y reinicie VC Web Client.

Windows:

  1. Desplácese hasta C:\ProgramData\VMware\vCenterServer\cfg\vsphere-client\vc-packages\vsphere-client-serenity.
  2. Elimine la carpeta com.vmware.vShieldManagerxxxxx (No es necesario borrar la copia de seguridad).
  3. Reinicie VC Web Client.

Unix

  1. Desplácese hasta /etc/vmware/vsphere-client/vc-packages/vsphere-client-serenity.
  2. Elimine la carpeta com.vmware.vShieldManagerxxxxx (No es necesario borrar la copia de seguridad).
  3. Reinicie VC Web Client.

Después de actualizar NSX Edge de la versión 6.1.x a la versión 6.2.x, el archivo vsm.log de NSX Manager muestra el mensaje "Configuración de DHCP no válida" ("INVALID DHCP CONFIG").
Si tiene una interfaz con una subred IPv6, DHCP genera una subred compartida vacía y considera esto como una operación no válida.

Solución alternativa: Deshabilite el servicio DHCP y actualice NSX Edge. Después de la actualización, habilita el servicio DHCP.

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.

La actualización de la puerta de enlace de los servicios Edge no se puede realizar si aparece un mensaje que indica que ha finalizado el tiempo de espera para Edge VM (Timed out waiting for Edge vm)
Al asignar una dirección IPv6 a la interfaz de gestión de NSX, NSX Manager utilizará el nombre de host. El proxy vsfwd que conecta Edge VM a NSX Manager no gestiona correctamente un FQDN, lo que genera un error similar a este: "ERROR TaskFrameworkExecutor-6 AbstractEdgeApplianceManager:185 - Ha finalizado el tiempo de espera para Edge VM {} (Timed out waiting for Edge vm {}). VM ha tardado demasiado en arrancar y responder com.vmware.vshield.edge.exception.VshieldEdgeException".

Solución alternativa: cambie la configuración con un comando similar a "esxcfg-advcfg -q -s "10.20.233.160" /UserVars/RmqIpAddress" o bien elimine el comando "ipv6 address" de la configuración de gestión de la interfaz y utilice IPv4 únicamente.


El reemplazo del certificado de NSX Manager requiere el reinicio de NSX Manager y puede requerir el reinicio de vSphere Web Client.
Después de reemplazar el certificado del dispositivo NSX Manager, siempre se debe reiniciar el dispositivo NSX Manager. En ciertos casos, después del reemplazo del certificado, vSphere Web Client no muestra la pestaña "Redes y seguridad" (Networking and Security). Si sucede esto, siga los pasos en la solución alternativa a continuación.

Solución alternativa: Reinicie el dispositivo NSX Manager y, a continuación, reinicie vSphere Web Client.

Para reiniciar NSX Manager, realice los pasos siguientes:

  1. Inicie sesión en la CLI de NSX Manager.

  2. Cambie al modo habilitado/privilegiado. Para ello, escriba en.

  3. Detenga el servicio web-manager. Para ello, escriba no web-manager. Espere a que aparezca Aceptar (OK) como confirmación de que se detuvo.

  4. Escriba web-manager para iniciar NSX Manager. Espere a que aparezca Aceptar (OK) como confirmación de que se reinició.

  5. Para reiniciar vSphere Web Client, en vCenter 5.5, abra https://{vcenter-ip}:5480 y reinicie el servidor de Web Client.

  6. En el dispositivo vCenter 6.0, inicie sesión en el shell de vCenter Server como usuario raíz y ejecute los comandos siguientes:

    shell.set --enabled True

    shell

    localhost:~ # cd /bin

    localhost:~ # service-control --stop vsphere-client

    localhost:~ # service-control --start vsphere-client

  7. En vCenter Server 6.0, ejecute los comandos siguientes:

    cd C:\Program Files\VMware\vCenter Server\bin

    service-control --stop vsphere-client

    service-control --start vsphere-client

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.

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.

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.

  • Las tareas como clonación, reconfiguración, etc. están en curso en la máquina virtual que se muestra en el panel de tareas 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

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.

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.

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.

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.

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.

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.

Después de actualizar NSX de la versión 6.0 a 6.0.x o 6.1, no aparecen los dispositivos NSX Edge en la interfaz de usuario
Cuando se actualiza de NSX 6.0 a NSX 6.0.x o 6.1, es posible que el complemento de vSphere Web Client no se actualice correctamente. Esto puede provocar problemas en la visualización de la interfaz de usuario, como, por ejemplo, que no se muestren los dispositivos NSX Edge.
Este problema no se presenta si la actualización se realiza desde NSX 6.0.1 o posterior.

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

  1. En vCenter MOB, haga clic en Contenido (Content).

  2. En la columna Valor (Value), haga clic en ExtensionManager.

  3. Busque el valor de propiedad extensionList (por ejemplo, com.vmware.vShieldManager) y copie la cadena.

  4. En el área Métodos (Methods), haga clic en UnregisterExtension.

  5. En el campo Value (Valor), pegue la cadena que copió en el paso 3.

  6. Haga clic en Invocar método (Invoke Method).

Esto asegura la implementación del paquete de complementos más reciente.

No se puede actualizar NSX Edge si la VPN L2 está habilitada en Edge
La actualización de la configuración de la VPN L2 de 5.x o 6.0 a 6.1 no es compatible. Por lo tanto, no se puede actualizar Edge si tiene configurada una VPN L2.

Solución alternativa: Elimine la configuración de la VPN L2 antes de actualizar NSX Edge. Después de la actualización, vuelva a configurar la VPN L2.

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.

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.0, 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.

Aparece un mensaje de error del host mientras se configura Distributed Firewall
Durante la configuración del firewall distribuido, si aparece un mensaje de error sobre el host, se debe comprobar el estado de la característica del tejido com.vmware.vshield.nsxmgr.messagingInfra. Si el estado es rojo, se debe aplicar la solución alternativa siguiente.

Solución alternativa: Utilice la llamada API REST siguiente para restablecer la comunicación entre NSX Manager y un solo host o todos los hosts de un clúster.

POST https://<NSX Manager IP>/api/2.0/nwfabric/configure?action=synchronize

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

El copiado y pegado de una regla de firewall con la opción de origen/destino negativos habilitada enumerará una regla nueva con la opción Negativo (Negate) deshabilitada
Si se copia y pega una regla de firewall con la opción de origen/destino negativos habilitada, después de la operación de pegado habrá una regla de firewall nueva; sin embargo, la opción de "origen/destino negativos" estará deshabilitada.

Solución alternativa: Ninguna.

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.

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

Después de actualizar de vCNS 5.5.4 a NSX 6.2.0, 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.0 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.

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 (in progress) 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 (in progress) y resolver el problema, reinicie el dispositivo virtual NSX Manager.

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.

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.

PSOD durante actualización de ESXi
Cuando se actualiza un host vSphere 5.5U2 compatible con NSX a vSphere 6.0, es posible que algunas actualizaciones del host ESXi se detengan en una pantalla de diagnóstico de color púrpura (también conocida como PSOD).

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

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.

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.

En una implementación de Cross vCenter, es posible que una sección de configuración 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.

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.

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.

Solución alternativa: Ninguna.

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.

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

SSLv2 y SSLv3 obsoletos en NSX 6.2
A partir de NSX 6.2, la puerta de enlace de la VPN SSL solo acepta el protocolo TLS. Después de la actualización de NSX, cualquier cliente de NSX 6.2 nuevo que cree utilizará automáticamente el protocolo TLS durante el establecimiento de la 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 paso del protocolo de enlace de SSL.

Solución alternativa: Después de la actualización a NSX 6.2, desinstale los clientes de la VPN SSL antiguos e instale la versión NSX 6.2 de los clientes de la VPN SSL.

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.

Después de la actualización a NSX 6.2, NSX Manager tiene un porcentaje superior a 100 de memoria física asignada
A partir de NSX 6.2, NSX Manager requiere 16 GB de memoria reservada. El requisito anterior era de 12 GB.

Solución alternativa: Aumente la memoria reservada del dispositivo virtual NSX Manager a 16 GB.

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.

Problemas conocidos de NSX Manager

No se puede añadir un NSX Manager secundario si la interfaz gráfica de usuario está en japonés en Firefox
Si se añade un NSX Manager secundario en Firefox con la interfaz gráfica en alemán, japonés, coreano o francés, el cuadro de diálogo de huella digital no aparecerá. Por este motivo, el usuario no puede configurar un NSX Manager secundario mientras esté utilizando estos idiomas.

Solución alternativa: Utilice Internet Explorer o el inglés.

El servicio de gestión de NSX no está disponible si el nombre de host tiene más de 64 caracteres.
Para crear certificados a través de la biblioteca OpenSSL, el nombre de host debe tener 64 caracteres o menos.

La lista de NSX Manager aparecerá lentamente en Web Client
En los entornos vSphere 6.0 con varios NSX Manager, vSphere Web Client puede tardar hasta dos minutos en mostrar la lista de los NSX Manager cuando el usuario conectado se está validando con una configuración de grupo de AD grande. Es posible que aparezca un error de tiempo de espera del servicio de datos al intentar mostrar la lista de NSX Manager. No hay solución. Debe esperar a que la lista se cargue o volver a iniciar la sesión para ver la lista de NSX Manager.

El controlador de NSX aparece como desconectado
Los registros de NSX Manager indican que los controladores están desconectados a través de un mensaje similar a este: "ERROR http-nio-127.0.0.1-7441-exec-16908 BaseRestController:339 - Exception : 'Error de E/S: Ha finalizado el tiempo de espera de lectura; la excepción anidada es java.net.SocketTimeoutException: Ha finalizado el tiempo de espera de lectura'". Esto ocurre cuando un firewall intermedio de la red bloquea el mensaje TCP/IP FIN una vez que se alcanza el valor de tiempo de espera inactivo. Cuando esto ocurre, aumenta el número de conexiones a NSX Manager.

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.

Las copias de seguridad anteriores no aparecen en la interfaz de usuario de NSX Manager
Las copias de seguridad nunca se realizan correctamente en la interfaz de usuario de NSX Manager. Este problema puede ocurrir si se almacenan muchos archivos de copia de seguridad en la carpeta de destino. Es necesario comprobar la compatibilidad de todos los archivos de copia de seguridad antes de mostrar la lista en la misma página. El proceso de la lista de archivos actual puede hacer que el tiempo de espera de la página finalice.

Solución alternativa: Disminuya el número de archivos almacenados en la carpeta de copia de seguridad con limpiezas periódicas de su servidor de almacenamiento o bien mueva las copias de seguridad anteriores a otra carpeta. Para comprobar que la copia de seguridad ha finalizado, busque un mensaje similar al siguiente en el archivo de registro de NSX Manager: 2015-07-01 22:10:55.869 GMT INFO http-nio-443-exec-250 VsmServiceBackupRestoreExecutor:236 - Run backup script - Start 2015-07-01 22:14:35.992 GMT INFO http-nio-443-exec-250 VsmServiceBackupRestoreExecutor:278 - Run backup script - Completed

Service Composer pierde la sincronización cuando se realizan cambios en la directiva mientras una de las instancias de Service Manager está inactiva.
Esto se relaciona con las instancias de varios servicios/Service Manager registrados y con las directivas creadas que hacen referencia a esos servicios. Si se hacen cambios en Service Composer a dicha directiva cuando una de las instancias de Service Manager está inactiva, se produce un error en los cambios debido al error de devolución de llamada a la instancia de Service Manager inactiva. Como resultado, Service Composer pierde la sincronización.

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

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.

Una vez restaurada la copia de seguridad de NSX Manager, la llamada REST muestra el estado de la característica del tejido com.vmware.vshield.nsxmgr.messagingInfra en rojo
Cuando se restaura la copia de seguridad de una instancia de NSX Manager y se comprueba el estado de la característica del tejido com.vmware.vshield.nsxmgr.messagingInfra con una llamada API REST, se muestra en rojo en lugar de verde.

Solución alternativa: Utilice la llamada API REST siguiente para restablecer la comunicación entre NSX Manager y un solo host o todos los hosts de un clúster.

POST https://<NSX Manager IP>/api/2.0/nwfabric/configure?action=synchronize

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

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.

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.

Syslog muestra el nombre del host de la instancia de NSX Manager de la que se realizó una copia de seguridad en la instancia de NSX Manager restaurada
Supongamos que el nombre de host de la primera instancia de NSX Manager es A y que se crea una copia de seguridad de esa instancia de NSX Manager. Ahora se instala y configura una segunda instancia de NSX Manager en la misma dirección IP que la instancia de Manager antigua según los documentos de restauración de copia de seguridad, pero el nombre de host es B. Se ejecuta una restauración en esta instancia de NSX Manager. La instancia de NSX Manager restaurada muestra el nombre de host A justo después de la restauración y el nombre de host B nuevamente después del reinicio.

Solución alternativa: El nombre de host de la segunda instancia de NSX Manager debe configurarse para que sea igual a la instancia de NSX Manager de la que se realizó una copia de seguridad.

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

La interfaz de usuario de NSX Manager no cierra automáticamente la sesión de los usuarios después de cambiar la contraseña con NSX Command Line Interface
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.

NSX Manager independiente permite incorrectamente la importación de la configuración de firewall universal
Por lo general, NSX Manager con el rol independiente debería permitir solo la importación de reglas de firewall locales. A partir de NSX 6.2, NSX Manager puede ejecutarse con el rol independiente (para la administración de redes de una instancia de vCenter) o en el modo Cross vCenter en el que permite, incorrectamente, importar una regla de firewall universal en un entorno NSX Manager que se ejecuta con el rol independiente. Una vez importadas, no se pueden eliminar las reglas de firewall universales a través de la API REST o de vSphere Web Client. Esto se debe a que el administrador se ejecuta actualmente con el rol independiente en el que la sección universal se trata como una local.

Solución alternativa: Si ejecuta NSX Manager con el rol independiente, no importe una configuración de firewall que contenga reglas universales. Si ya importó una regla de firewall universal en una instancia de NSX Manager independiente, solucione el problema importando un archivo de configuración de firewall guardado que no contenga reglas universales, y publique ese archivo de configuración cargándolo en la tabla Firewall.
Realice los pasos siguientes:

  1. Inicie sesión en vSphere Web Client.

  2. Haga clic en Redes y seguridad (Networking & Security) y, a continuación, en Firewall.

  3. Haga clic en la pestaña Firewall.

  4. Haga clic en la pestaña Configuraciones guardadas (Saved Configurations).

  5. Haga clic en el icono Importar configuración (importar) (Import configuration [import]).

  6. Haga clic en Examinar (Browse) y seleccione el archivo que contiene la configuración que desea importar.

    Las reglas se importan según los nombres de las reglas. Durante la importación, el firewall se asegura de que cada objeto al que se hace referencia en la regla exista en el entorno. Si no se encuentra un objeto, la regla se marca como no válida. Si una regla hacía referencia a un grupo de seguridad dinámico, el grupo de seguridad dinámico se crea en NSX Manager durante la importación.

  7. Vuelva a agregar el nodo como un nodo secundario. La sincronización entre las instancias de NSX Manager sincroniza automáticamente la sección universal de forma correcta mediante cualquier limpieza necesaria.

    Una vez que se haya publicado correctamente el archivo de configuración, las reglas se transmiten al host e impactan en la ruta de datos. El sistema funciona del modo esperado.

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.

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.

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

El tráfico multidifusión disminuye en algunos conmutadores lógicos respaldados por la ejecución de conmutadores de Arista EOS-4.12.7.1
En instalaciones de NSX en las que la red física incluye conmutadores de Arista en ejecución, versión EOS-4.12, es posible que el tráfico multidifusión lógico disminuya. Esto podría tener repercusión en caso de que dos VTEPS de ESX se comuniquen a través del puerto 8472 de VxLAN por medio de un conmutador de Arista afectado como refuerzo físico. Todos los productos 7150 de Arista se ven afectados cuando ejecutan alguna versión actual superior o de mantenimiento de EOS 4.12.

Solución alternativa: Los clientes que utilicen conmutadores de Arista tienen dos formas de solucionar el problema:

  1. Actualizar los conmutadores de Arista a EOS 4.13.0 o posteriores.
  2. Configurar NSX para utilizar otro puerto UDP a través de API REST de NSX. VMware recomienda utilizar el puerto 4789 según las especificaciones de VXLAN.

La demora al conectar con el equilibrador de carga de NSX no proporciona conexiones consistentes en diferentes direcciones IP virtuales (VIP)
Cuando el equilibrador de carga está configurado para utilizar el equilibrio de carga del Hash IP de origen, una sesión de cliente conectada recibe una conexión consistente en un servidor Back-end. El equilibrador de carga también debe ofrecer, para un cliente conectado específico, conexiones consistentes en diferentes direcciones IP virtuales (VIP) si estas se encuentran respaldadas por el mismo grupo de servidores. Es decir, cuando un servidor Back-end proporciona diferentes direcciones IP virtuales (VIP), la conexión de un cliente determinado a una de las VIP del servidor Back-end debería garantizar que el cliente utilice el mismo servidor Back-End al conectarse a otras VIP a través de dicho servidor. Un problema conocido evita que el equilibrador de carga de NSX pueda ofrecer conexiones consistentes en diferentes direcciones IP virtuales.

Demora al conectar con RIB y FIB tras asignar una dirección IP a la interfaz
Cuando intente asignar una dirección IP a la interfaz, por lo general la información de la interfaz se actualizará inmediatamente. Sin embargo, cuando el intervalo de sondeo aumenta, es posible que experimente una demora en la asignación de la dirección IP.

La convergencia es lenta si el enrutador de borde de área OSPF que tiene la dirección IP superior está apagado
La convergencia es lenta si el enrutador de borde de área (ABR) OSPF basado en NSX que tiene la dirección IP superior está apagado o reiniciado. Si un ABR que no tiene una dirección IP numéricamente superior está apagado o reiniciado, el tráfico se dirige rápidamente a otra ruta de acceso. Sin embargo, si el enrutador de borde de área (ABR) que tiene la dirección IP superior está apagado o 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.

El número total de enlaces de estadísticas en un servidor dhcp edge no puede ser superior a 2048
Si se supera la cifra de 2.048, aparecerá el siguiente mensaje de error: «El número total de enlaces y grupos no debe superar a 2.048 (Total number of bindings and pools should not exceed 2,048)».

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>

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.

El enrutador lógico distribuido anuncia un salto siguiente incorrecto de la ruta predeterminada cuando el filtro vecino BGP está establecido en "CUALQUIERA , FUERA , DENEGAR" (ANY , OUT , DENY)
Con la opción Origen predeterminado (Default Originate) habilitada en un enrutador lógico distribuido (DLR) de NSX, establecer un filtro vecino BGP "CUALQUIERA , FUERA , DENEGAR" (ANY , OUT , DENY) 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:

  • Dirección: FUERA (OUT)
  • Acción: Denegar (Deny)
  • Red: Cualquiera (Any)

Solución alternativa: Ninguna.

Deshabilitar un protocolo de enrutamiento en NSX Edge puede provocar una pérdida temporal del tráfico de datos
Al deshabilitar un protocolo de enrutamiento en NSX Edge no se envía una solicitud route-withdraw a un elemento del mismo nivel, por lo que el tráfico permanece en un agujero negro hasta que se agota el temporizador de inactividad/retención.

Solución alternativa: Ninguna.

Las rutas LIF del enrutador lógico se anuncian mediante la puerta de enlace de servicios Edge ascendente incluso si 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 aun cuando 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.

Syslog de ESG no puede hacer envíos al servidor remoto, muestra que no puede resolver el nombre de host; sin embargo, la resolución DNS funciona
Inmediatamente después de la implementación de Edge, Syslog 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. Este problema se observó por primera vez en la versión 6.2.

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.

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.

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.

Problemas conocidos de los servicios de seguridad

Sin conectividad en ID 0 de VLAN en VPN L2
La configuración de VPN L2 de NSX no permite al usuario configurar correctamente una VPN L2 con ID 0 de VLAN. Una vez configurada, no hay tráfico en esta VPN.

Solución alternativa: Solución alternativa: Utilice una ID de VLAN válida dentro del rango de 1 a 4094.

No hay soporte para algoritmos de cifrado de Cipher 3C (SHA-256) para SSLVPN-Plus

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.

Al utilizar IPset como fuente/destino en la regla de NetX, se muestra el error Tipo de contenedor no válido: IPSet (Invalid container type: IPSet)
Solución alternativa: en lugar de utilizar IPSet como fuente/destino para las reglas de NetX, cree un grupo de seguridad y configure IPSet como miembro del mismo.

Este problema es habitual en la versión 6.2.1

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.

Este problema es habitual en la versión 6.2.1

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

Este problema es habitual en las versiones 6.1.5 y 6.2.1

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.

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.

La interfaz de usuario de NSX necesita 3 minutos como mínimo para cargar los usuarios/grupos de Active Directory al crear un grupo de seguridad

Al configurar grupos de seguridad y seleccionar "Grupo de directorio (Directory Group)", la interfaz de usuario de NSX tardará 3 minutos o más en rellenar la lista de usuarios y grupos de Active Directory. No hay solución.

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.

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.

Algunas versiones de VM-Series de Palo Alto Networks no funcionan con la configuración predeterminada de NSX Manager
Algunos componentes de NSX 6.1.4 deshabilitan SSLv3 de forma predeterminada. Antes de realizar la actualización, es necesario comprobar 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.

En las instalaciones de NSX actualizadas, es posible que la publicación de una regla de firewall de como resultado la excepción de puntero nulo (Null Pointer exception) en Web Client
En las instalaciones de NSX actualizadas, es posible que la publicación de una regla de firewall de como resultado la excepción de puntero nulo (Null Pointer exception) en la interfaz de usuario. Se guardan los cambios realizados en la regla. Este es solo un problema de visualización.

Si se elimina la configuración de firewall con una llamada API REST, no se puede cargar y publicar la configuración guardada
Cuando se elimina la configuración de firewall, se crea una sección predeterminada nueva con un identificador de sección nuevo. Cuando se carga un borrador guardado (con el mismo nombre de sección, pero un identificador de sección anterior), los nombres de sección entran en conflicto y muestran el error siguiente:
Los valores clave duplicados infringen la restricción exclusiva firewall_section_name_key (Duplicate key value violates unique constraint firewall_section_name_key)

Solución alternativa: Realice una de las tareas siguientes:

  • Cambie el nombre de la sección de firewall predeterminada actual después de cargar una configuración guardada.
  • Cambie el nombre de la sección predeterminada en una configuración guardada cargada antes de publicarla.

Problemas conocidos de servicios de supervisión

No se pueden agregar más de ocho interfaces de vínculo superior durante la implementación del enrutador lógico distribuido (DLR) con vSphere Web Client

Solución alternativa: Espere a que finalice la implementación de DLR y, a continuación, agregue interfaces adicionales al enrutador lógico distribuido.

Problemas resueltos

Los problemas siguientes se resolvieron en las versiones 6.2.0 y 6.2.1:

Los problemas resueltos se agrupan de la siguiente manera:

Problemas conocidos resueltos

  • En VMware ESXi 5.x y 6.x sale una pantalla de diagnóstico morada al utilizar detección de direcciones IP en VMware NSX for vSphere 6.2.0 (2134329)
    Al utilizar detección de direcciones IP en conmutadores lógicos en VMware NSX for vSphere 6.2.0, en el host ESXi 5.x y 6.x aparece una pantalla de diagnóstico morada que muestra un error tal y como se explica en el artículo 2134329 de la base de conocimientos

    Este problema se solucionó en NSX 6.2.1.

  • La opción Administrar (Manage) del portlet de la etiqueta de seguridad aparece atenuada de forma predeterminada
    En la página Resumen (Summary) de una máquina virtual, el hipervínculo "Administrar" (Manage)del portlet de la etiqueta de seguridad aparecerá atenuado hasta que el usuario cree una nueva etiqueta de seguridad.

    Este problema se solucionó en NSX 6.2.1.

  • Algunos registros de controladores no están disponibles para syslog export.
    Los registros de controladores, incluidos los registros de clúster de Zookeeper, no forman parte de syslog export.

    Este problema se solucionó en NSX 6.2.1.

  • Pantalla de diagnóstico de color púrpura (PSOD) de ESXi 6.0 en vdl2 al hacer ping si el tamaño de los datos es superior al tamaño de los datos disponibles en la MTU
    El ping de inicio de vmknic del conmutador del host NSX llevará a una pantalla de diagnóstico de color púrpura (PSOD) en el host si el tamaño de los datos es superior a la MTU.

    Este problema se solucionó en NSX 6.2.1.

  • Los usuarios tenían que configurar la misma dirección IP y el mismo número de puerto para el protocolo UDP y para el TCP.
    Esta versión resuelve también los siguientes problemas:

    • El servidor virtual UDP sin la configuración de grupo puede producir un error de configuración.
    • Las estadísticas muestran datos incorrectos cuando el servidor virtual UDP no está asociado a ningún grupo.

    Este problema se solucionó en NSX 6.2.1. Con la versión 6.2.1, los usuarios pueden utilizar la misma dirección IP y el mismo número de puerto para ambos protocolos TCP y UDP con o sin grupo asociado.

Problemas de instalación y actualización resueltos

  • El cliente SSL VPN-Plus no se puede instalar en Mac OS X Yosemite ni en versiones posteriores
    Se admiten versiones anteriores de Mac OS X.

    Este problema se solucionó en NSX 6.2.1.

  • Después de actualizar NSX for vSphere de la versión 6.0.7 a la 6.1.3, ocurre un error en la pantalla de inicio de sesión de vSphere Web Client
    Después de actualizar NSX Manager de la versión 6.0.7 a la 6.1.3, se muestran excepciones en la pantalla de inicio de sesión de la interfaz de usuario de vSphere Web Client. No es posible iniciar sesión ni realizar operaciones en vCenter o NSX Manager.

    Este problema se solucionó en NSX 6.2.0.

  • Error en la instalación de Guest Introspection
    Cuando se instala Guest Introspection en un clúster, se produce el error siguiente en la instalación:
    Formato de módulo VIB no válido (Invalid format for VIB Module)

    Este problema se solucionó en NSX 6.2.0.

  • DVPort no puede habilitarse con la opción "Bloquearía" (Would block) debido a un problema de preparación del host
    En un host ESXi compatible con NSX, DVPort no puede habilitarse con la opción "Bloquearía" (Would block) debido a un problema de preparación del host. Cuando sucede esto, el mensaje de error que se observa primero varía (por ejemplo, es posible que se vea como un error de creación de VTEP en VC/hostd.log, un error de conexión de DVPort en vmkernel.log o un error 'SIOCSIFFLAGS' en el invitado). Esto sucede cuando los VIB se cargan después de que vCenter transmite las propiedades de vSphere Distributed Switch (vDS). Esto puede suceder durante la actualización. Consulte el artículo 2107951 de la base de conocimientos.

    Este problema se solucionó en NSX 6.2.0.

  • Error en los intentos de eliminar la puerta de enlace de NSX Edge existente en un entorno actualizado a NSX 6.1.4
    En las instalaciones de NSX que se actualizaron de la versión 6.1.3 a la 6.1.4, no se pueden eliminar las puertas de enlace de NSX Edge existentes después de la actualización a la versión 6.1.4. Este problema no afecta a las puertas de enlace Edge nuevas creadas después de la actualización. Las instalaciones que se actualizaron directamente desde la versión 6.1.2 o anterior no se ven afectadas por este problema.

    Este problema se solucionó en NSX 6.2.0.

  • El cifrado AES no está disponible cuando se realiza una copia de seguridad de NSX con una copia de seguridad de FTP protegida por terceros

    Este problema se solucionó en NSX 6.2.0.

  • La interfaz de usuario de NSX Manager no muestra mensajes de error fáciles de comprender para el usuario durante el reinicio del host
    En esta versión 6.2, la interfaz de usuario de NSX Manager se actualizó para mostrar mensajes de error detallados que describen los problemas que se pueden presentar durante el reinicio del host y proporcionan soluciones posibles.

    Este problema se solucionó en NSX 6.2.0.

  • No se puede instalar la instalación de VIB de NSX
    Es posible que la instalación de VIB de NSX no se complete como se esperaba si el controlador ixgbe no se carga correctamente desde el módulo de terceros porque se bloqueó, y esto evita que se utilice para la instalación.

    Este problema se solucionó en NSX 6.2.0.

  • No se puede iniciar el servicio NSX Manager después de actualizar de vCloud Networking and Security (vCNS) 5.5.3
    Después de actualizar vCloud Networking and Security (vCNS) 5.5.3 a NSX 6.1.3, el servicio NSX Manager no responde y no se puede iniciar correctamente.

    Este problema se solucionó en NSX 6.2.0.

  • Aleatoriamente, el bus de mensajes no se inicia después del reinicio de NSX Edge
    Después de reiniciar una máquina virtual Edge, con frecuencia, el bus de mensajes no se inicia correctamente después del encendido y es necesario reiniciar nuevamente.

    Este problema se solucionó en NSX 6.2.0.

Problemas de NSX Manager resueltos

  • Desde la versión 6.2.1, NSX Manager realiza una consulta de cada nodo del controlador en el clúster para obtener información de conexión entre dicho controlador y los otros controladores del clúster.
    Se proporciona en los resultados de API REST de NSX (comando "GET https://[NSX-MANAGER-IP-ADDRESS]/api/2.0/vdn/controller"), que ahora muestra el estado de conexión entre los nodos del controlador. Si NSX Manager detecta que la conexión entre dos nodos del controlador se ha interrumpido, se genera un evento del sistema para avisar al usuario.

    Este problema se solucionó en NSX 6.2.1.

  • Si la copia de seguridad de Manager se restaura en otra aplicación, no se puede forzar la sincronización del controlador
    Si una aplicación de NSX Manager se clona y/o restaura a partir de una copia de seguridad, no se podrá forzar la sincronización del clúster del controlador en NSX. Este problema no ocurre si NSX Manager se ha implementado desde cero.

    Este problema se solucionó en NSX 6.2.1.

  • Error de latido de inicio de sesión en NSX para hosts que no forman parte de la instalación de NSX
    Cuando un host preparado en NSX se ha eliminado directamente del inventario de vCenter (sin anular primero su preparación en NSX), NSX recibe un DCN inesperado de 'Host conectado', lo que causa la eliminación parcial de los componentes de la infraestructura de mensajes del host. Como resultado, es posible que el enlace de mensajes entre NSX y el host permanezca activo cuando debería haberse eliminado, y NSX puede mostrar una 'alerta' falsa SystemEvents para el host. Este problema se solucionó en NSX 6.2.1.

    Este problema se solucionó en NSX 6.2.1.

  • NSX Manager no funciona después de ejecutar el comando write erase
    Cuando se reinicia NSX Manager después de ejecutar el comando write erase, es posible que NSX Manager no funcione como se espera; por ejemplo, se restableció la contraseña para acceder al shell de Linux, falta el comando de configuración, etc.

    Este problema se solucionó en NSX 6.2.0.

  • Agregar dominio (Add Domain) muestra un error en la opción LDAP con Utilizar credenciales de dominio (Use Domain Credentials)
    En NSX 6.1.x, cuando el usuario intenta agregar un dominio LDAP, el cliente web muestra el error No se especificó el nombre de usuario (User Name was not specified), incluso cuando se proporcionó un nombre de usuario en la interfaz de usuario. Este problema se solucionó en NSX 6.2.0.

    Este problema se solucionó en NSX 6.2.0.

  • La importación del certificado firmado por una entidad de certificación requiere el reinicio de NSX Manager para poder aplicarse
    Cuando se importa un certificado firmado por una entidad de certificación de NSX Manager, el certificado recién importado no se aplica hasta que se reinicia NSX Manager.

    Este problema se solucionó en NSX 6.2.0.

  • No se puede importar NSX Manager en el dominio LDAPS
    Cuando se intenta agregar NSX Manager al dominio LDAPS, aparece el mensaje de error siguiente.
    No es posible conectarse al host <FQDN del servidor>
    mensaje de error: error de enlace simple: <FQDN del servidor:Número> (Cannot connect to host <Server FQDN> error message: simple bind failed: <Server FQDN:Number>)

    Este problema se solucionó en NSX 6.2.0.

Problemas resueltos de redes lógicas y problemas resueltos de NSX Edge

  • Error de configuración del servidor de autenticación RADIUS en NSX Edge
    En NSX 6.1.5 y versiones anteriores, la cadena de clave secreta del servidor RADIUS tenía un límite de 32 caracteres; si la cadena superaba este límite, el servidor RADIUS no se conectaba a NSX Edge. Ahora el límite es de 64 caracteres.

    Este problema se solucionó en NSX 6.2.0.

  • La implementación en la pila de VIO Heat falla de forma intermitente en VMware NSX for vSphere 6.x Edge con el siguiente error: No se puede asignar memoria (Cannot allocate memory)
    El uso de la memoria de supervisión de estado aumenta con el tiempo, lo que causará problemas en Edge.

    Este problema se solucionó en NSX 6.2.1.

  • Los filtros BGP demoran aproximadamente 40 segundos para aplicarse de forma efectiva
    Durante este período, todas las directivas de redistribución se aplican sin filtros. Esta demora corresponde solo al enrutador lógico distribuido (DLR) NSX para las direcciones FUERA (OUT).

    Este problema se solucionó en NSX 6.2.0.

  • En las subinterfaces NSX Edge, los redireccionamientos de ICMP se envían, incluso cuando la opción Enviar redireccionamiento de ICMP (Send ICMP redirect) está deshabilitada
    De forma predeterminada, las subinterfaces NSX Edge tienen la opción Enviar redireccionamiento de ICMP (Send ICMP redirect) deshabilitada. A pesar de que está opción está deshabilitada, los redireccionamientos de ICMP se envían en las subinterfaces de Edge.

    Este problema se solucionó en NSX 6.2.0.

  • No se pueden agregar caracteres no ASCII en el nombre de puente o empresa en el enrutador lógico
    Las API de NSX Controller no son compatibles con caracteres no ASCII.

    Este problema se solucionó en NSX 6.2.0.

  • Cuando se modifica una regla de filtro de vecino BGP, es posible que los filtros existentes no se apliquen por hasta 40 segundos
    Cuando se aplican filtros BGP a una instancia de NSX Edge que ejecuta IBGP, es posible que los filtros demoren hasta 40 segundos en aplicarse en la sesión IBGP. Durante este período, es posible que NSX Edge anuncie rutas que se deniegan en el filtro BGP para el IBGP del mismo nivel.

    Este problema se solucionó en NSX 6.2.0.

  • Una de las controladoras NSX Controller no entrega el rol maestro a otras controladoras cuando se apaga
    Por lo general, cuando una controladora asume el rol maestro de operaciones y se prepara para apagarse, entrega automáticamente el rol maestro a otras controladoras. En este caso, la controladora no entrega el rol a otras controladoras y el estado se interrumpe y, a continuación, pasa a modo desconectado.

    Este problema se solucionó en NSX 6.2.0.

  • No se puede pasar tráfico de VXLAN entre hosts con unidifusión o multidifusión
    Cuando las máquinas virtuales se encuentran en el mismo host, pueden comunicarse en toda la VXLAN con unidifusión o multidifusión, pero no pueden comunicarse cuando las máquinas virtuales se encuentran en hosts diferentes.

    Este problema se solucionó en NSX 6.2.0.

  • La eliminación de varias reglas BGP en NSX Edge/DLR al mismo tiempo provoca errores en el cliente web

    Este problema se solucionó en NSX 6.2.0. Ahora puede eliminar varias reglas BGP al mismo tiempo.

  • La dirección del protocolo se muestra brevemente después de agregar la regla de denegación de Border Gateway Protocol (BGP)
    Es posible que se observe que la dirección del protocolo se muestra brevemente después de agregar la regla de denegación de Border Gateway Protocol (BGP) en la puerta de enlace de servicios NSX Edge.

    Este problema se solucionó en NSX 6.2.0.

  • Las máquinas virtuales se desconectan durante la ejecución de vMotion
    Es posible que se observe que las máquinas virtuales se desconectan durante la ejecución de vMotion o que se reciban alertas por máquinas virtuales con NIC desconectadas.

    Este problema se solucionó en NSX 6.2.0.

  • No se puede descargar instantánea de controladora
    Cuando se descargan instantáneas de la controladora, es posible que no se pueda descargar la instantánea de la última controladora. Por ejemplo, si hay tres controladoras, una puede descargar correctamente las instantáneas de las primeras dos, pero es posible que ocurra un error al descargar la instantánea de la tercera controladora.

    Este problema se solucionó en NSX 6.2.0.

  • Al configurar un servidor virtual, se aplica la dirección IP previamente seleccionada
    Al crear un nuevo servidor virtual, es posible que detecte que la dirección IP se aplica automáticamente desde la lista del grupo de direcciones IP seleccionado previamente. Esto sucede cuando ha seleccionado previamente un grupo de direcciones IP para obtener la dirección IP del servidor virtual. Al intentar editar la información del grupo de direcciones IP del servidor virtual, la información no se envía automáticamente al Back-end desde la interfaz de usuario y se aplica automáticamente la dirección IP obtenida a partir del grupo de direcciones IP.

    Este problema se solucionó en NSX 6.2.1.

  • Cuando HA está habilitado en la puerta de enlace de servicios Edge, los intervalos de saludo y de inactividad de OSPF configurados con valores distintos a 30 segundos y 120 segundos respectivamente pueden provocar cierta pérdida de tráfico durante la conmutación por error
    Cuando se produce un error en el NSX Edge principal con OSPF en ejecución y HA habilitado, el tiempo requerido para que el modo inactivo asuma el control excede el tiempo de espera de reinicio estable y hace que los vecinos OSPF quiten las rutas conocidas de su tabla de base de información de reenvío (Forwarding Information Base, FIB). Esto genera una interrupción en el plano de datos hasta que converjan los reinicios de OSPF.

    Este problema se solucionó en NSX 6.2.0.

  • Las máquinas virtuales no pueden recibir el ping del servidor DHCP Edge
    Las máquinas virtuales pueden hacer ping en la puerta de enlace de Edge pero no pueden recibir un ping DHCP de un tronco de puerta de enlace de Edge a través de una red superpuesta. El servidor DHCP Edge está configurado como un puerto troncal y no puede pasar ni recibir nada de tráfico. Sin embargo, cuando la puerta de enlace de Edge y Edge DHCP se encuentran en el mismo host, pueden hacerse ping mutuamente. Cuando Edge DHCP se mueve a otro host, Edge DHCP no puede recibir un ping de la puerta de enlace de Edge.

    Este problema se solucionó en NSX 6.2.0.

  • Las estadísticas del equilibrador de carga Edge no se muestran correctamente en vSphere Web Client
    El equilibrador de carga no muestra la cantidad de estadísticas de conexión simultáneas en el gráfico de la interfaz de usuario de vSphere Web Client.

    Este problema se solucionó en NSX 6.2.0.

  • Cuando se quita la red agregada directa en una subred local y remota de un canal VPN IPsec, la ruta agregada a las subredes indirectas de la instancia de Edge del mismo nivel también desaparece
    Cuando no hay una puerta de enlace predeterminada en Edge y se quitan todas las subredes de conexión directa en subredes locales y parte de las subredes remotas al mismo tiempo cuando se configura IPsec, las subredes del mismo nivel restantes quedan fuera del alcance de la VPN IPsec.

    Este problema se solucionó en NSX 6.2.0.

  • No se puede pasar tráfico a través del equilibrador de carga después de actualizar a NSX 6.1.2 o posterior
    Cuando se utiliza la opción Insertar X-Forwarded-For (Insert X-Forwarded-For) en el equilibrador de carga de NSX Edge, es posible que el tráfico no pase por el equilibrador de carga.

    Este problema se solucionó en NSX 6.2.0.

  • La ejecución del comando clear ip ospf neighbor devuelve un error de segmentación

    Este problema se solucionó en NSX 6.2.0.

  • No se pueden procesar las solicitudes de Kerberos
    Se produce un error en ciertas solicitudes de Kerberos cuando se equilibran con una instancia de NSX Edge.

    Este problema se solucionó en NSX 6.2.0.

Problemas de servicios de seguridad resueltos

  • Si cambia el nombre de un borrador de firewall existente, se producirá un error de funcionamiento y la interfaz de usuario mostrará el mensaje "Error interno del servidor" (Internal Server Error).

    Este problema se solucionó en NSX 6.2.1.

  • Algunos CLI centralizados de DFW muestran el mensaje "Salida de error 100" ("ERROR output 100")
    En determinadas situaciones, cuando un adaptador de red virtual (vNIC) está desconectado, puede surgir una discrepancia entre la información de estado de vNIC en NSX Manager y el host, desencadenando un mensaje "Salida de error 100" (ERROR output 100) en los CLI centralizados.

    Este problema se solucionó en NSX 6.2.1.

  • La lista de perfiles de aplicación no está ordenada.
    La lista de los nombres de perfiles de aplicación en NSX Edge cuando la inserción de servicios está habilitada, aparece de forma desordenada. Esta versión incorpora la solución para presentar la lista de perfiles de aplicación de forma ordenada.

    Este problema se solucionó en NSX 6.2.1.

  • El tiempo de espera de los comandos CLI centrales que se ejecutan para un host ESXi específico finaliza en algunas configuraciones.

    Este problema se solucionó en NSX 6.2.1.

  • El vsfwd.log se sobrescribe rápidamente con una gran cantidad de actualizaciones del contenedor
    Una vez que se modifica la directiva SpoofGuard, NSX Manager envía sin demora el cambio al host, pero el host demora más en procesar el cambio y actualizar el estado de SpoofGuard de la máquina virtual.

    Este problema se solucionó en NSX 6.2.0.

  • No se puede configurar el firewall de NSX con grupos de seguridad u otros objetos de agrupación definidos en el alcance global
    Los usuarios administradores definidos en el alcance de NSX Edge no pueden acceder a los objetos definidos en el alcance global. Por ejemplo, si el usuario abc se define en el alcance de Edge y el grupo de seguridad sg-1 se define en el alcance global, abc no puede utilizar sg-1 en la configuración de firewall en NSX Edge.

    Este problema se solucionó en NSX 6.2.0.

  • Movimiento demorado del mouse cuando se visualizan reglas de firewall
    En la sección Redes y seguridad de NSX (NSX Networking and Security) de vSphere Web Client, cuando se pasa el mouse sobre las filas en la pantalla Reglas de firewall (Firewall Rules) ocurre una demora de 3 segundos.

    Este problema se solucionó en NSX 6.2.0.

  • La interfaz de usuario muestra el mensaje Error de publicación de firewall (Firewall Publish Failed) a pesar de la correcta publicación
    Si se habilita Distributed Firewall en una subred de clústeres en el entorno y se actualiza un grupo de aplicaciones que se utiliza en una o más reglas de firewall activas, todas las acciones de publicación en la interfaz de usuario muestran un mensaje de error con los identificadores de los hosts que pertenecen a los clústeres que no tienen el firewall de NSX habilitado.
    A pesar de los mensajes de error, las reglas se publican y aplican correctamente en los hosts que tienen Distributed Firewall habilitado.

    Este problema se solucionó en NSX 6.2.0.

  • La eliminación de reglas de seguridad por medio de REST muestra un error
    Si se utiliza una llamada API REST para eliminar las reglas de seguridad creadas por Service Composer, el conjunto de reglas correspondientes no se elimina en realidad de la memoria caché del perfil del servicio, lo que provoca el error ObjectNotFoundException.

    Este problema se solucionó en NSX 6.2.0.

  • Las reglas de firewall no reflejan la máquina virtual agregada recientemente
    Cuando se agregaron máquinas virtuales nuevas al conmutador lógico, las reglas de firewall no se actualizaron correctamente para incluir las máquinas virtuales agregadas recientemente. Si se realiza un cambio en el firewall y se publican los cambios, los objetos nuevos se agregan a la directiva.

    Este problema se solucionó en NSX 6.2.0.

  • No se pueden seleccionar objetos de Active Directory cuando se configuran grupos de seguridad
    En NSX 6.1.x, los objetos de dominio de AD/LDAP demoraron mucho en regresar a la pantalla de selección Objeto de grupo de seguridad (Security Group Object).

    Este problema se solucionó en NSX 6.2.0.

  • No se puede agregar la regla de firewall con origen/destino como varias direcciones IP separadas por coma

    Este problema se solucionó en NSX 6.2.0.

  • No se puede mover la sección de Distributed Firewall (DFW) de NSX a la parte superior de la lista
    Cuando se utiliza Service Composer para crear una directiva de grupo de seguridad, la sección creada en la tabla de DFW no se puede agregar a la parte superior de la lista. No hay manera de mover la sección DFW hacia arriba o abajo.

    Este problema se solucionó en NSX 6.2.0.

  • La directiva de seguridad configurada como un rango de puertos hace que el firewall pierda sincronización
    La configuración de directivas de seguridad como un rango de puertos (por ejemplo, "5900-5964") hace que el firewall pierda la sincronización y muestre el error NumberFormatException.

    Este problema se solucionó en NSX 6.2.0.

Problemas de servicios de supervisión resueltos

  • Al realizar informes sobre las estadísticas de flujo, los recuentos del índice 0 (bytes de entrada) y del índice 1 (bytes de salida) en ocasiones aparecen invertidos.
    El índice 0 mantiene el recuento del tráfico en la dirección del estado del registro del flujo, mientras que el índice 1 mantiene el recuento del tráfico en la dirección inversa.

    Este problema se solucionó en NSX 6.2.1.

  • El comando #show interface no muestra la velocidad o el ancho de banda de la interfaz de vNic_0
    Después de ejecutar el comando "#show interface", se muestra una velocidad de dúplex completo de 0 M/s, pero no se muestran la velocidad o el ancho de banda de la interfaz de NSX Edge vNic_0.

    Este problema se solucionó en NSX 6.2.0.

  • Cuando está habilitada la configuración IPFIX para Distributed Firewall, es posible que se quiten los puertos de firewall en la interfaz de administración de ESXi de NetFlow para vDS o SNMP
    Cuando un puerto y una IP del recopilador se definen para IPFIX, el firewall de la interfaz de administración de ESXi se abre en dirección de salida para los puertos recopiladores UDP especificados. Es posible que esta operación quite la configuración del conjunto de reglas dinámico del firewall de interfaz de administración de ESXi para los servicios siguientes si anteriormente estaban configurados en el host ESXi:
    • Configuración del puerto recopilador NetFlow en vDS
    • Configuración del puerto de destino SNMP

    Este problema se solucionó en NSX 6.2.0.
  • No se pueden procesar los eventos Denied/Block mediante el protocolo IPFIX
    Por lo general, el proceso de usuario vsfwd se ocupa de la recopilación de flujos, incluidos los desechados/denegados, y los procesa para IPFIX. Esto sucede cuando el recopilador IPFIX no puede ver los eventos Denied/Block porque la cola de descarte de paquetes de vSIP es demasiado limitada o está rodeada de eventos de flujo inactivos. En esta versión, se implementa la capacidad para enviar eventos Denied/Block con el protocolo IPFIX.

    Este problema se solucionó en NSX 6.2.0.

Problemas de interoperabilidad de soluciones resueltos

  • No se puede configurar la red organizativa
    Cuando se intenta configurar una red para toda la organización, vCloud Director muestra un mensaje de error.

    Este problema se solucionó en NSX 6.2.0.

  • No se pueden iniciar varias máquinas virtuales con la configuración de VIO
    Los usuarios que utilizaban VMware Integrated OpenStack no podían iniciar una gran cantidad de máquinas virtuales o publicar grandes cantidades de reglas de firewall en un período breve. Esto generaba el mensaje Error publishing ip for vnic en el registro.

    Este problema se solucionó en NSX 6.2.0.

Los problemas siguientes se resolvieron en las versiones 6.1.5 y 6.2.1:

Los problemas resueltos se agrupan de la siguiente manera:

Problemas conocidos resueltos

  • Una de las controladoras NSX Controller no entrega el rol maestro a otras controladoras cuando se apaga
    Por lo general, cuando una controladora NSX Controller asume el rol maestro de operaciones y se prepara para apagarse, entrega automáticamente el rol maestro a otras controladoras. En este caso, la controladora no entrega el rol a otras controladoras y el estado se interrumpe y, a continuación, pasa a modo desconectado.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • Se ha producido un error en la conexión de plano de control en la controladora NSX Controller
    Se ha producido un error en la conexión de plano de control de una controladora y se ha mostrado un error en netcpa relacionado con txInProgress.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

Problemas de instalación y actualización resueltos

  • Después de la actualización de NSX, Guest Introspection no se puede comunicar con NSX Manager
    Después de actualizar de NSX 6.0.x a NSX 6.1.x o de NSX 6.0.x a NSX 6.2 y antes de que se actualice el servicio Guest Introspection, NSX Manager no se puede comunicar con Universal Service Virtual Machine (USVM) de Guest Introspection. La pérdida de comunicación entre NSX Manager y Guest Introspection lleva a una pérdida de protección de las máquinas virtuales en el clúster de NSX cuando hay un cambio en las máquinas virtuales, como adiciones de máquinas virtuales, migraciones de vMotion o eliminaciones. La pestaña Instalación de NSX (NSX Installation) > Implementaciones de servicios (Service Deployments) muestra la versión actual de Guest Introspection. Cuando se presenta este problema, aparece una advertencia en la columna Estado de servicio (Service Status). El mensaje de advertencia incluye la lista de hosts afectados y el mensaje de error Guest Introspection no está listo.

    Solución alternativa: Para resolver el problema, siga el procedimiento para actualizar Guest Introspection en la documentación de actualización de NSX.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

Problemas de NSX Manager resueltos

  • El uso de la CPU en NSX Manager es elevado después de agregarlo al dominio de Active Directory
    El uso de la CPU en NSX Manager es elevado después de agregarlo al dominio de Active Directory. En los registros del sistema de NSX Manager aparecen varios subprocesos de Postgres en ejecución.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • No ha sido posible registrar NSX Manager 6.1.4 con vCenter, al aparecer el error: Error en la operación del servicio de gestión de NSX (NSX Management Service operation failed)

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • El cliente web de NSX Manager muestra el error: Código 301002
    Descripción: Al navegar hasta NSX manager > Monitor (Supervisar) > Eventos del sistema (System Events), el cliente web muestra el siguiente mensaje: La configuración de filtro no se ha aplicado a vnic (Filter config not applied to vnic). Código 301002.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

Problemas de redes lógicas resueltos

  • Pérdida de conectividad después de quitar una interfaz lógica (logical interface, LIF) en instalaciones con enrutamiento dinámico
    Se identificó un problema en el enrutador lógico de NSX (Edge/DLR) cuando se utiliza el enrutamiento dinámico (OSPF y BGP) que provocará la pérdida de conectividad de red después de quitar una LIF. Esto afecta a las versiones 6.0.x a 6.1.4 de NSX.

    En las instalaciones de NSX que utilizan el enrutamiento dinámico, cada LIF tiene un identificador de índice de reglas de redistribución asociado a ella. Cuando un usuario elimina una LIF en tales instalaciones, es posible que cambien los identificadores de índice asignados a algunas LIF activas. Esta modificación de los índices puede provocar una pérdida temporal de la conectividad de red en las LIF cuyos identificadores de índice se cambien. Si la eliminación de LIF se realiza en serie, se podrá observar una interrupción de entre 5 y 30 segundos en las LIF afectadas después de cada eliminación. Si la eliminación de LIF se hace de forma masiva, se podrá observar una interrupción de entre 5 y 30 segundos en las LIF afectadas.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

Problemas de servicios Edge y de redes resueltos

  • Las rutas de OSPF configuradas en la puerta de enlace de los servicios NSX Edge (ESG) no aparecen en el enrutador lógico y los paquetes afectados se han caído
    Este problema sucede en los casos en los que OSPF utiliza la opción IP_HDRINCL. En determinados kernels de Linux, cuando esta opción está presente, evita que la pila de IP fragmente los paquetes. Por lo tanto, todos los paquetes que sean mayores que la MTU de la interfaz se caerán.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • Syslog muestra el nombre del host de la instancia de NSX Manager de la que se realizó una copia de seguridad en la instancia de NSX Manager restaurada
    Supongamos que el nombre de host de la primera instancia de NSX Manager es A y que se crea una copia de seguridad de esa instancia de NSX Manager. Ahora se instala y configura una segunda instancia de NSX Manager en la misma dirección IP que la instancia de Manager antigua según los documentos de restauración de copia de seguridad, pero el nombre de host es B. Se ejecuta una restauración en esta instancia de NSX Manager. La instancia de NSX Manager restaurada muestra el nombre de host A justo después de la restauración y el nombre de host B nuevamente después del reinicio.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • Parece que el host ESXi pierde la conectividad de red
    Es posible que un host ESXi haya perdido la conectividad de red y experimente problemas de estabilidad cuando se registran varios mensajes de error como los que se indican a continuación:
    ADVERTENCIA: Latido: 785: PCPU 63 no ha tenido ningún latido durante 7 segundos; es posible que esté bloqueado (WARNING: Heartbeat:785: PCPU 63 didn’t have a heartbeat for 7 seconds; *may* be locked up).

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • Las máquinas virtuales se desconectan durante la ejecución de vMotion
    Se han desconectado las máquinas virtuales durante la ejecución de vMotion en la versión 6.0.8 con el mensaje Montón VISP agotado (VISP heap depleted).

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • No es posible volver a implementar NSX Edge con el servicio L2VPN configurado con el certificado firmado por una entidad de certificación
    No es posible volver a implementar ni cambiar el tamaño de NSX Edge con el servicio L2VPN configurado con el certificado autofirmado o firmado por una entidad de certificación.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • Aleatoriamente, el bus de mensajes no se inicia después del reinicio de NSX Edge
    Después de reiniciar una máquina virtual Edge, con frecuencia, el bus de mensajes no se inicia correctamente después del encendido y es necesario reiniciar nuevamente.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

Problemas de servicios de seguridad resueltos

  • Las controladoras de NSX for vSphere 6.x se desconectan intermitentemente
    Debido a un error de IPSEC en el paquete StrongSWAN que fue enviado en la versión 6.1.4 y versiones anteriores, no estaban establecidos los túneles entre controladoras después de la regeneración de claves de IPSEC. Esto ha provocado errores de conectividad parciales entre las controladoras, lo que ha derivado a su vez en diferentes problemas. Para obtener más información, consulte el artículo 2127655 de la base de conocimientos.

    Este problema se solucionó en NSX 6.1.5 y 6.2.1

  • Los objetos de dominio de LDAP tardan mucho tiempo en regresar a la pantalla de selección Objeto de grupo de seguridad (Security Group Object) o no pueden regresar.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • Movimiento demorado del mouse cuando se visualizan reglas de firewall
    En la sección Redes y seguridad de NSX (NSX Networking and Security) de vSphere Web Client, cuando se pasa el mouse sobre las filas en la pantalla Reglas de firewall (Firewall Rules) ocurre una demora de 3 segundos con cada movimiento del mouse.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • Algunas reglas SpoofGuard de IP en NSX-v no se aplican correctamente
    Algunas reglas SpoofGuard de IP en NSX-v no se aplican correctamente. La instancia no está presente en el grupo de seguridad en NSX-v y se necesita agregar manualmente al grupo de seguridad

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • La eliminación masiva en la interfaz de usuario de Service Composer genera el mensaje "entre 0 y 0" ("between 0 to 0")
    La eliminación masiva de directivas (~100) de la interfaz de usuario NSX Service Composer genera el siguiente mensaje "Debería estar entre 0 y 0" ("It should be between 0 to 0"). Puede ignorar este mensaje de forma segura.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • La operación en segundo plano para la eliminación de directivas puede tardar demasiado tiempo con un uso elevado de la CPU
    La eliminación de una directiva vuelve a evaluar todas las directivas restantes en segundo plano. Esto puede tarde más de una hora en configuraciones con un gran número de directivas, de grupos de seguridad o de de reglas por directiva.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • Todas las tareas publicables en cola están marcadas como erróneas después de un tiempo de espera de 20 minutos
    NSX Edge se encarga del mantenimiento de las colas y pueden publicarse en paralelo para diferentes Edges. Las tareas publicables en cola se ejecutan de forma secuencial: cada tarea tarda aproximadamente 3-4 segundos, por lo que 300-400 tareas se completan en 20 minutos. En los casos en los que haya más de 400 tareas de publicación para un Edge en cola durante un corto período de tiempo y se haya superado el límite de tiempo de espera de publicación de 20 minutos mientras se espera para la ejecución, las tareas se marcarán automáticamente como erróneas. NSX Manager responde a este error revirtiendo la última configuración correcta conocida, en la que la publicación se realizó correctamente en el Edge. Las aplicaciones o los complementos que están enviando actualizaciones de configuración de un Edge en NSX Manager en modo de ráfaga necesitan supervisar el estado de error y de éxito de la tarea utilizando el ID de trabajo asociado.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

Problemas de interoperabilidad de soluciones resueltos

  • Error al copiar la máquina virtual a través de vCloud Connector cuando la ruta pasa al equilibrador de carga de NSX

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • En la implementación de VIO, parece que algunas máquinas virtuales recientemente implementadas tienen un puerto válido y direcciones IP asignadas, pero no tienen acceso a la red

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

  • Inicio sesión lento en la pestaña NSX de vSphere Web Client con un SSO con respaldo de AD
    En las instalaciones de NSX for vSphere que utilizan SSO para autenticación AD, el inicio de sesión inicial del usuario en la sección Redes y seguridad de NSX (NSX Networking and Security) de vSphere Web Client tarda mucho tiempo.

    Este problema se solucionó en NSX 6.1.5 y en NSX 6.2.1.

Historial de revisión del documento

20 de agosto de 2015: Primera edición de NSX 6.2.0.
04 de septiembre de 2015: Segunda edición de NSX 6.2.0. Se quitó la advertencia de actualización innecesaria.
17 de diciembre de 2015: Primera edición de NSX 6.2.1.
27 de febrero de 2016 Segunda edición de NSX 6.2.1. Compatibilidad de NSX-Log Insight aclarada.
20 de mayo de 2016: Tercera edición de NSX 6.2.2. Se han añadido los límites de la actualización 6.1.x.