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

|

Documento actualizado el 21 de agosto de 2017
VMware NSX for vSphere 6.2.5   |   Publicado el 5 de enero de 2017  |   Compilación 4818372

Contenido de las notas de la versión

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

Novedades

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

Consulte esta información importante acerca de NSX 6.2.3.

Novedades de la versión 6.2.5

La versión 6.2.5 es una versión de corrección de errores que soluciona un problema que hacía que se perdiese la conexión de red después de determinadas operaciones de vMotion en instalaciones en las que algunos hosts usaban una versión más reciente de NSX y otros hosts usaban una versión más antigua. Consulte la sección Problemas resueltos.

Nuevo en la versión 6.2.4

La versión 6.2.4 incluye las siguientes nuevas funciones: También corrige una serie de errores que se documentan en la sección Problemas resueltos.

  • Cambios en la API del estado de firewall (GET /api/4.0/firewall/globalroot-0/status)

    • Se mejoró la API del estado de firewall para incluir el estado de las actualizaciones de los objetos utilizados en las reglas de firewall: La API del estado de firewall muestra un número de generación (generationNumber) para cada grupo de reglas, que se puede utilizar para comprobar si un cambio en los grupos de reglas se propagó a un host. En la versión 6.2.4, se agregó un número de generación de objetos (generationNumberObjects) a la API de estado. Esto le permite verificar si un cambio en los objetos utilizados en las reglas de firewall se propagó a un host. Tenga en cuenta que es posible que el número de generación de objetos cambie con frecuencia y siempre será igual o mayor que el número de generación del conjunto de reglas.

    • Los hosts y los clústeres que no participan en el firewall se excluyen del resultado: Los clústeres (y los hosts dentro de los clústeres) ya no se incluyen en el resultado del estado si el firewall distribuido se deshabilita en el nivel del clúster o si el clúster no está preparado (los VIB de NSX no están instalados). En versiones anteriores de NSX, estos clústeres y hosts sí se incluyen en el resultado. Sin embargo, como no están configurados para firewall, después de publicar una regla de firewall su estado es En curso (InProgress).

  • Correcciones de errores críticos identificados en NSX 6.2.3: NSX 6.2.4 incluye una aplicación de revisión de seguridad para CVE-2016-2079 que supone una vulnerabilidad de validación de entrada crítica para sitios que utilizan la VPN SSL de NSX. Para los clientes que utilicen la VPN SSL, VMware les recomienda que consulten CVE-2016-2079 y que actualicen a NSX 6.2.4 o versiones posteriores.

Nuevo en la versión 6.2.3

Información importante acerca de NSX for vSphere 6.2.3: Para los clientes que tengan instalados NSX 6.2.3 o 6.2.3a, VMware les recomienda instalar NSX 6.2.4 o versiones posteriores para solucionar errores críticos.

La versión 6.2.3 proporciona una aplicación de revisión de seguridad para solucionar la vulnerabilidad CVE-2016-2079. CVE-2016-2079 supone una vulnerabilidad de validación de entrada crítica para sitios que utilizan la VPN SSL de NSX. La versión también incluye una serie de errores solucionados que aparecen en la sección Problemas resueltos.

Cambios introducidos en NSX for vSphere 6.2.3:

  • Enrutamiento y conmutación lógica

    • Integración de la puerta de enlace de capa 2 con el hardware de NSX: amplía las opciones de conectividad física mediante la integración de conmutadores de puerta de enlace de hardware de terceros en la red lógica de NSX.

    • Nuevo puerto 4789 de VXLAN en NSX 6.2.3 y versiones posteriores: Antes de la versión 6.2.3, el número de puerto UDP de VXLAN predeterminado era el 8472. Para obtener más detalles, acceda a la Guía de actualización de NSX.

  • Servicios Edge y de redes

    • Nuevas opciones de Edge DHCP: La opción 121 de DHCP admite la opción de ruta estática, que se usa para que el servidor DHCP publique rutas estáticas en el cliente DHCP; las opciones 66, 67 y 150 de DHCP son compatibles con opciones de DHCP para arranque PXE; y la opción 26 de DHCP admite la configuración de la MTU de interfaz de red del cliente DHCP mediante el servidor DHCP.

    • Aumento de los límites de enlace estático en el grupo de DHCP: A continuación, se muestran nuevos números de límite para distintos factores de forma: Compacto: 2048; grande: 4096; tamaño cuádruple: 4096; y extra grande: 8192.

    • Edge Firewall aporta protección contra ataques de inundación SYN: evita las interrupciones en el servicio; para ello, habilita la protección contra ataque de inundación SYN para el tráfico en tránsito. Esta función está deshabilitada de forma predeterminada; use la API REST de NSX para habilitarla.

    • NSX Edge: conmutación por error bajo demanda: permite al usuario iniciar la conmutación por error bajo demanda cuando sea necesario.

    • NSX Edge: memoria predeterminada para NSX Edge de tamaño cuádruple: Aumentó de 1 a 2 GB.

    • NSX Edge: reserva de recursos: reserva la CPU o memoria para NSX Edge durante su creación. La memoria o la CPU reservadas se basan en el factor de forma del dispositivo Edge. Puede cambiar los porcentajes de la reserva de recursos de la memoria y la CPU establecidos por defecto utilizando la siguiente API. El porcentaje de la memoria y la CPU debe estar a 0 para deshabilitar la reserva de recursos.

      PUT https://<NSXManager>/api/4.0/edgePublish/tuningConfiguration

                  <tuningConfiguration>
                     <lockUpdatesOnEdge>false</lockUpdatesOnEdge>
                     <aggregatePublishing>true</aggregatePublishing>
                     <edgeVMHealthCheckIntervalInMin>0</edgeVMHealthCheckIntervalInMin>
                     <healthCheckCommandTimeoutInMs>120000</healthCheckCommandTimeoutInMs>
                     <maxParallelVixCallsForHealthCheck>25</maxParallelVixCallsForHealthCheck>
                     <publishingTimeoutInMs>1200000</publishingTimeoutInMs>
                     <edgeVCpuReservationPercentage>0</edgeVCpuReservationPercentage>
                     <edgeMemoryReservationPercentage>0</edgeMemoryReservationPercentage>
                     <megaHertzPerVCpu>1000</megaHertzPerVCpu>
                  </tuningConfiguration>
                

    • Cambio en el comportamiento de la actualización de NSX Edge: Las máquinas virtuales de NSX Edge de reemplazo se implementan antes de la actualización o reimplementación. El host debe tener suficientes recursos para 4 máquinas virtuales de NSX Edge durante la actualización o reimplementación del par HA de Edge. El valor predeterminado del tiempo de espera de la conexión TCP se cambió del anterior valor de 3.600 segundos a 21.600 segundos.

    • Cross VC NSX: actualización del enrutador lógico distribuido (Distributed Logical Router, DLR) universal: Actualización automática del DLR universal en NSX Manager secundario, una vez actualizado en NSX Manager principal.

    • Creación flexible de reglas SNAT/DNAT: vnicId ya no es un parámetro de entrada necesario; se eliminó el requisito de que la dirección DNAT deba ser la dirección de una vNIC de NSX Edge.

    • Las máquinas virtuales de NSX Edge (ESG, DLR) muestran ahora la ubicación real y la deseada: NSX Manager y las API de NSX que incluyen GET api/4.0/edges/ /appliances devuelven ahora configuredResourcePool y configuredDataStore, además de la ubicación actual.

    • Edge Firewall aporta protección contra ataques de inundación SYN: evita las interrupciones en el servicio; para ello, habilita la protección contra ataque de inundación SYN para el tráfico en tránsito. Esta función está deshabilitada de forma predeterminada; use la API REST de NSX para habilitarla.

    • NSX Manager presenta el nombre del host ESXi en el que se ejecuta la SVM de firewall de las series de máquinas virtuales de terceros para mejorar la gestión operativa en entornos a gran escala.

    • Ahora se puede aplicar la regla NAT a una interfaz vNIC y más de una dirección IP.

    • Opción Nueva configuración (New configuration) para establecer el tiempo de vencimiento de la sesión del equilibrador de carga: Esta versión proporciona un nuevo comando de reglas de la aplicación para configurar el valor del tiempo de espera para el vencimiento tanto del servidor como del cliente. Si se comparte el grupo entre varios servidores virtuales, se establecerá el valor máximo para ello.

    • NSX API devuelve ahora resultados XML de forma predeterminada cuando no se proporciona el encabezado "Accept:" Desde NSX 6.2.3, si el encabezado "Accept:" no se proporciona en una llamada API de REST, los valores de retorno del formato predeterminado de NSX API están en XML. Antes, NSX API devolvía resultados con formato JSON de forma predeterminada. Para recibir resultados con formato JSON, el usuario de la API debe establecer explícitamente "application/json" en el encabezado "Accept:" al solicitar la función.

    • Nueva NSX API para cambiar la configuración del borrador automático para el firewall distribuido de NSX: A partir de NSX 6.2.3, la siguiente PUT API se puede utilizar para cambiar la configuración del borrador automático del firewall distribuido de NSX:

      • Obtener la configuración global existente:
        GET https://NSX-Manager-IP-Address/api/4.0/firewall/config/globalconfiguration
      • Nota: GET no mostrará el campo autoDraftDisabled.

      • Agregar la propiedad de configuración autoDraftDisabled a la configuración global y realizar una llamada de API PUT:
        PUT https://NSX-Manager-IP-Address/api/4.0/firewall/config/globalconfiguration
      • Cuerpo de solicitud:
          <globalConfiguration>
            <layer3RuleOptimize>...</layer3RuleOptimize>
            <layer2RuleOptimize>...</layer2RuleOptimize>
            <tcpStrictOption>...</tcpStrictOption>
            <autoDraftDisabled>true</autoDraftDisabled>
        </globalConfiguration>
          

  • Servicios de seguridad

    • Distributed Firewall - TFTP ALG: se habilita su utilización en casos como el arranque de una red en las máquinas virtuales.

    • Firewall - Filtrado granular de reglas: simplifica la solución de problemas mediante filtros granulares de reglas en la interfaz de usuario, basados en Origen (Source), Destino (Destination), Acción (Action), Habilitado/Deshabilitado (Enabled/Disabled), Registro (Logging), Nombre (Name), Comentarios (Comments), Identificador de regla (Rule ID), Etiqueta (Tag), Servicio (Service), Protocolo (Protocol).

    • Guest Introspection: compatibilidad con Windows 10

    • Cliente SSL VPN: compatibilidad con Mac OS El Capitan

    • Service Composer - Mejoras en el rendimiento: permite un inicio/reinicio más rápido de NSX Manager mediante la optimización de la sincronización entre la directiva de seguridad y el servicio de firewall, y la deshabilitación del guardado automático de los borradores de firewall de forma predeterminada.

    • Service Composer - Alarmas de estado: activa la alarma del sistema si la directiva de seguridad pierde la sincronización y, para resolver el problema, adopta medidas específicas según el código de la alarma.

    • Reducción del uso de la memoria en montón de firewall: el uso del firewall de los conjuntos de direcciones IP se optimizaron para reducir el uso de la memoria en montón.

  • Funcionamiento y solución de problemas

    • Panel de control de NSX: simplifica la solución de problemas al proporcionar información sobre el estado general de los componentes de NSX en una vista centralizada.

    • Mejoras de Traceflow: servicios de introspección de red: mejora la capacidad de rastrear un paquete desde el origen hasta el destino al identificar si los paquetes se reenviaron a los servicios de introspección de red de terceros y si los paquetes regresan o no desde la máquina virtual de servicios de terceros.

    • Compatibilidad con SNMP: permite configurar capturas de SNMP para eventos de NSX Manager, NSX Controller y Edge.

    • El registro está ahora habilitado de forma predeterminada para VPN SSL y VPN L2. De forma predeterminada, el registro está en nivel de aviso.

    • El registro de IPsec VPN ahora está habilitado de forma predeterminada. El nivel del registro predeterminado se configura como advertencia. Si desea deshabilitar el registro o cambiar el nivel de este, consulte la sección Habilitar el registro de IPsec VPN de la Guía de administración de NSX.

    • La interfaz de usuario de reglas de firewall muestra ahora los protocolos IP configurados y los números de puerto TCP/UDP asociados a los servicios.

    • Se mejoraron los registros de soporte técnico de NSX Edge para informar sobre el consumo de memoria de cada proceso.

    • Se mejoró la supervisión del estado del canal de comunicación con la aparición de nuevos mensajes de registros de eventos cuando el estado del canal cambia para un servidor o un clúster.
    • Mejoras de la CLI central

      • Estado del host en la CLI central: muestra el estado del host, con más de 30 comprobaciones en un solo comando, incluida la configuración de red, la configuración de VXLAN, el uso de recursos, etc.

      • Captura de paquetes en la CLI central: proporciona la capacidad de capturar paquetes en el host y transferir el archivo de captura al servidor remoto del usuario. De esta forma se elimina la necesidad de proporcionar acceso al hipervisor a los administradores de red para solucionar problemas de redes lógicas.

    • Paquete de soporte técnico por host: recopila registros por host y crea un paquete que se puede guardar y enviar a VMware Technical Support para recibir asistencia.

  • Mejoras de la concesión de licencias

    • Cambio de la distribución de claves de evaluación y licencia predeterminada: la licencia predeterminada en el momento de la instalación es "NSX para vShield Endpoint" (NSX for vShield Endpoint), que habilita el uso de NSX para la implementación y administración de vShield Endpoint solo para la capacidad de descarga antivirus. Las claves de licencia de evaluación se pueden solicitar al equipo de ventas de VMware.

    • Informes sobre el uso de licencias: en la interfaz de usuario Resumen (Summary) de NSX Manager se muestran los recuentos del uso de la licencia de NSX; estos datos también se pueden mediante la API. Ya no se informará sobre los recuentos del uso de la licencia de NSX mediante el servicio de licencias de vCenter.

  • Mejoras en el equilibrador de carga (LB)

    • Establecer el tiempo de espera de la sesión para las VIP configuradas sin aceleración: es posible configurar más de 5 minutos de tiempo de espera de la VIP del motor del equilibrador de carga de Capa 7 (sin aceleración) utilizando la regla de la aplicación "timeout client 3600s".

    • Mejoras en las estadísticas de la CLI: las estadísticas globales ya están disponibles a través de la CLI. La VIP específica y las estadísticas de los grupos también están disponibles.

    • Mejora en el LB con aceleración: el motor del equilibrador de carga de Capa 4 (con la aceleración habilitada) respetará siempre las comprobaciones de los estados de UDP, del hash IP de origen de TCP e invalidará la entrada persistente.

    • Refinamiento de los registros: mejoras en los registros del equilibrador de carga.

    • Configurar la autenticación SSL: es posible configurar la autenticación del servidor SSL si existe alguna VIP con SSL de un extremo a otro.

    • Mejoras en la tabla persistente de IP de origen (Source IP): aunque se produzca un cambio en la configuración, la tabla de persistencia de la IP de origen (Source IP Persistence) sigue disponible.

    • Se agrega el parámetro sysctl.net.ipv4.vs.expire_nodest_conn del control del sistema del equilibrador de carga de NSX Edge a la lista blanca de NSX Manager: sysctl.net.ipv4.vs.expire_nodest_conn para cambiar el estado de la conexión persistente.

  • Interoperabilidad de soluciones

    • Programa de mejora de la experiencia de cliente: NSX admite la realización de informes sobre estadísticas del sistema a través del programa de mejora de la experiencia de cliente (Customer Experience Improvement Program, CEIP) de VMware. La participación es opcional y se configura en vSphere Web Client.

    • VMware vRealize Log Insight 3.3.2 for NSX proporciona análisis de registro inteligente para NSX, con paneles de control que se pueden personalizar y capacidades de supervisión y solución de problemas para la virtualización de la red, el análisis de flujo y las alertas. Esta versión acepta las claves de licencia de las ediciones Standard/Advanced/Enterprise de NSX generadas para NSX 6.2.2 y posteriores.​

    • Soporte de administración de vShield Endpoint: NSX es compatible con la administración de la capacidad de descarga antivirus de vShield Endpoint. Los clientes que adquirieron vSphere con vShield Endpoint (Essentials Plus o superior) pueden descargarse NSX de la página de descargas de vSphere. Para obtener más información, consulte el artículo 2110078 de la base de conocimientos de VMware y el artículo 2105558 de la base de conocimientos de VMware.

Nuevo en la versión 6.2.2

La versión 6.2.2 proporciona una aplicación de revisión de seguridad que soluciona la vulnerabilidad de glibc y corrige una serie de errores que se han documentado en la sección Problemas resueltos. Esta versión incluye las mismas correcciones de errores críticos que se proporcionaron en todas las aplicaciones de revisión basadas en las versiones 6.1.4 y 6.1.5. Para los usuarios de NSX 6.1.x, esta misma serie de correcciones de aplicación de revisión está disponible en la versión NSX 6.1.6.

Las funciones principales de esta versión son:

  • Aplicación de revisión de seguridad para CVE-2015-7547 (glibc) : Esta aplicación de revisión corrige la vulnerabilidad CVE-2015-7547, también conocida como vulnerabilidad de glibc.

  • Problema 1600484: Eliminación de validaciones restringidas en configuraciones de nombres de dominio de DHCP NSX 6.2.2 ha reactivado la compatibilidad para grupos de DHCP con dominios ".local". Consulte el artículo de la base de conocimientos 2144097 de VMware

  • Problema 1586149: Mejoras en la interfaz de usuario de DFW para mayor comodidad de uso. En la implementación anterior, la tabla solía desplazar la cuadrícula al primer elemento cuando un usuario hacía un cambio. En la implementación corregida, siempre que se añade una regla, la cuadrícula se desplaza a ella. Ahora, al actualizar los datos de la cuadrícula por cualquier motivo (por ejemplo, después de publicar o revertir cambios), se mantiene la posición de desplazamiento vertical de la cuadrícula.

  • Problema 1592562: Cambio de comportamiento cuando se configura un nuevo servicio Edge. En las versiones anteriores a la 6.2.2, cuando se configura un nuevo servicio Edge, este aparece habilitado de forma predeterminada. Este comportamiento cambia en la versión 6.2.2. En este momento, si la licencia actual es compatible con la función, esta aparece habilitada de forma predeterminada. De lo contrario, la función aparece deshabilitada.

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

Instalación, versiones y requisitos del sistema mínimos recomendados

En la tabla siguiente se muestran las versiones mínimas recomendadas y requeridas del software de VMware. Esta información está actualizada según la fecha de publicación de este documento. Si desea conocer las recomendaciones más recientes, consulte el artículo de la base de conocimientos 2144295 de VMware

Producto o componente Versión mínima recomendada
NSX for vSphere 6.2.2

Para los clientes que utilicen la VPN SSL, VMware recomienda que tengan la versión mínima de NSX for vSphere 6.2.4 y consulten CVE-2016-2079.

Para aquellos que quieran usar la conmutación lógica y vSphere 6.0U2, VMware aconseja que utilicen la versión mínima de NSX for vSphere 6.2.4 y consulten el artículo sobre los VTEP duplicados en los hosts ESXi después de reiniciar vCenter Server (KB 2144605).

vSphere 5.5U3 o 6.0U2

Nota: Existe un problema conocido con los objetos NSX y vSphere 6.0. Para obtener más información, consulte el artículo 2144605 de la base de conocimientos de VMware sobre los VTEP duplicados en los hosts ESXi después de reiniciar vCenter Server.

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

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

vRealize Orchestrator Complemento NSX-vRO 1.0.3 o versiones posteriores

Nota: NSX 6.2.x no es compatible con vSphere 6.5. Consulte la matriz de interoperabilidad de productos VMware para obtener más información sobre la interoperabilidad.

Instalación

Para obtener instrucciones de instalación, acceda a la Guía de instalación de NSX o la Guía de instalación de Cross-vCenter NSX. Para ver la lista completa de requisitos previos para la instalación de NSX, consulte la sección sobre requisitos del sistema para NSX en la Guía de instalación de NSX.

Funciones obsoletas y suspendidas

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

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

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

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

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

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

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

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

Notas sobre la actualización

  • Las versiones anteriores no son compatibles:

    • Realice siempre una copia de seguridad de NSX Manager antes de realizar una actualización.

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

  • Nuevo Actualización de la puerta de enlace de los servicios Edge (ESG):
    A partir de la versión 6.2.5, la reserva de los recursos se realiza al mismo tiempo que la actualización de NSX Edge. Cuando vSphere HA está habilitado en un clúster con recursos insuficientes, se puede producir un error en la operación de actualización, ya que se infringe la restricción de vSphere HA.

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

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

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

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

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

  • Nuevo Posibilidad de deshabilitar la opción Iniciar máquina virtual (Virtual Machine Startup) de vSphere cuando vSphere HA está habilitado y los Edges están implementados. Tras actualizar NSX Edge 6.2.4 a la versión 6.2.5 u otras posteriores, debe desactivar la opción para iniciar la máquina virtual de vSphere en cada NSX Edge que se encuentre en un clúster en el que esté habilitado vSphere HA y en el que se hayan implementado Edges. Para hacerlo, abra vSphere Web Client, busque el host ESXi donde se encuentra la máquina virtual de NSX Edge y haga clic en Administrar (Manage): Configuración (Settings), y en Máquinas virtuales (Virtual Machines), seleccione Inicio y apagado de máquina virtual (VM Startup/Shutdown), haga clic en Editar (Edit) y asegúrese de que la máquina virtual esté en modo Manual (es decir, asegúrese de que no se haya añadido a la lista de inicio/apagado automático).

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

  • Diseño de disco de NSX Controller Las instalaciones nuevas de NSX 6.2.3 o versiones posteriores implementarán los dispositivos de NSX Controller con particiones de disco actualizadas para proporcionar una resistencia de clúster adicional. En versiones anteriores, el desbordamiento del registro en el disco de controlador podía afectar a la estabilidad del controlador. Además de la incorporación de mejoras en la administración de registros para evitar los desbordamientos, el dispositivo de NSX Controller presenta particiones de disco independientes para los datos y los registros para protegerse ante estos eventos. Si actualiza a NSX 6.2.3 o a versiones posteriores, los dispositivos de NSX Controller conservarán el diseño de disco original.
  • Rutas de acceso de la actualización:

    • Ruta de acceso de actualización desde NSX 6.x: La matriz de interoperabilidad de productos VMware proporciona los detalles sobre las rutas de acceso de actualización desde VMware NSX. Encontrará información sobre la actualización de Cross-vCenter NSX en la Guía de actualización de NSX.

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

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

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

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

    • No existe compatibilidad para las actualizaciones desde NSX 6.1.5 a NSX 6.2.0. VMware recomienda actualizar desde la versión 6.1.5 a la versión 6.2.4 o posteriores para obtener las actualizaciones de seguridad más recientes.

  • Para validar que su actualización a NSX 6.2.x se realizó correctamente, consulte el 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.

  • Compatibilidad con servicios de partner: Si su sitio web utiliza servicios de partners de VMware para Guest Introspection o para Network Instrospection, consulte la Guía de compatibilidad de VMware antes de actualizar para comprobar que el servicio del proveedor es compatible con esta versión de NSX.
  • Problemas frecuentes de las actualizaciones: Consulte la sección Problemas conocidos de instalación y actualización más adelante en este documento para ver una lista de los problemas conocidos relacionados con la actualización.

  • Nuevos requisitos del sistema: Si desea obtener información sobre los requisitos de memoria y CPU para la instalación y actualización de NSX Manager, consulte la sección sobre los requisitos del sistema para NSX de la documentación de NSX 6.2.

  • Establezca la versión del cifrado correcta para los clientes del equilibrio de carga que usan TLS 1.0: Esto afecta a los miembros del grupo vROP que usan la versión 1.0 de TLS. Si los servidores, cuyo tráfico es de carga equilibrada, usan esta versión, deberá establecer un valor de extensión de supervisión con la opción "ssl-version=10" en el equilibrador de carga de NSX. Consulte la Guía de administración de NSX.

    {
                    "expected" : null,
                    "extension" : "ssl-version=10",
                    "send" : null,
                    "maxRetries" : 2,
                  "name" : "sm_vrops",
                  "url" : "/suite-api/api/deployment/node/status",
                  "timeout" : 5,
                  "type" : "https",
                  "receive" : null,
                  "interval" : 60,
                  "method" : "GET"
               }

  • Número máximo de reglas NAT: En versiones anteriores a NSX Edge 6.2, el usuario podía configurar 2048 reglas SNAT y 2048 reglas DNAT por separado, con un límite total de 4096. Desde la versión 6.2 de NSX Edge, se ha establecido un límite máximo de reglas NAT permitidas en función del tamaño de la aplicación NSX Edge:

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

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

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

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

  • Cambio de comportamiento de los filtros de redistribución en el enrutador lógico distribuido y la puerta de enlace de servicios Edge: A partir de la versión 6.2, las reglas de redistribución del DLR y de la ESG funcionan como ACL solamente. Es decir, si una regla es una coincidencia exacta, se lleva a cabo la acción correspondiente.

  • ID de túnel de VXLAN: Antes de actualizar a NSX 6.2.x, debe asegurarse de que la instalación no utilice un identificador de túnel VXLAN 4094 en ningún túnel. El identificador de túnel VXLAN 4094 ya no 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. Es posible que también tenga que limpiar la caché o el historial del navegador.

  • Entornos sin estado: Las actualizaciones de NSX en un entorno de host sin estado utilizan URL de VIB nuevas: En las actualizaciones de NSX en un entorno de host sin estado, los VIB nuevos se agregan previamente al perfil de imagen del host durante el proceso de actualización de NSX. Como resultado, el proceso de actualización de NSX en hosts sin estado sigue esta secuencia:

    1. Se descargan manualmente los VIB de NSX más recientes de NSX Manager desde una URL fija.

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

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

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

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

Problemas conocidos

Los problemas conocidos se agrupan de la siguiente manera:

Problemas conocidos generales

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

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

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

Problema 1700980: En la aplicación de revisión de seguridad CVE-2016-2775, un nombre de consulta demasiado largo puede causar un error de segmentación en lwresd

NSX 6.2.4 cuenta con BIND 9.10.4 instalado en el producto, pero no usa la opción lwres en named.conf y, por lo tanto, el producto no es vulnerable.

Solución alternativa: No es necesaria ninguna, ya que el producto no es vulnerable.

Problema 1710624: El servidor de registro de eventos Windows 2008 se agregó como "TIPO" ("TYPE") de "WIN2K3", si serverType no está especificado en el cuerpo de solicitud de la API REST

Si crea la solicitud de la API del servidor EventLog, el servidor se agregará como "TIPO" ("TYPE") de "WIN2K3". Si usa el servidor EventLog solo para IDFW, es posible que este firewall no funcione correctamente.

Solución alternativa: Agregue serverType al cuerpo de solicitud de la API REST. Por ejemplo:

<EventlogServer>
  <domainId>1</domainId>
  <hostName>AD_server_IP</hostName>
  <enabled>true</enabled>
  <serverType>WIN2k8</serverType>
</EventlogServer>

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

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

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

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

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

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

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

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

Pasos para ignorar las búsquedas de SID para las SID sin solución:
  1. Inicie sesión en la máquina virtual de Guest Introspection.
  2. Edite el archivo en /usr/local/usvmmgmt/config/ignore-sids.lst.
  3. Anexe las siguientes líneas:
    S-1-18-1
    S-1-18-2
  4. Guarde y cierre el archivo.
  5. Reinicie el servicio de Guest Introspection con el siguiente comando:
    rcusvm restart.

Problema 1558285: Al eliminar un clúster con Guest Introspection desde Virtual Center, la acción acaba en una excepción de puntero nulo
Se deben eliminar servicios como Guest Introspection antes de eliminar un clúster de VC.

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

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

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

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

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

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

Solución alternativa: Ninguna.

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

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

Problemas conocidos de instalación y actualización

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

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

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

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

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

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

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

Solución alternativa: Ninguna.

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

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

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

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

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

Solución alternativa: Reiniciar NSX Manager.

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

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

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

Problema 1660373: vCenter aplica la licencia de NSX caducada

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

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

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

Solución alternativa: Ninguna.

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

Solución alternativa: Ninguna.

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

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

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

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

Problema 1394287: La dirección IP definida en las reglas de vShieldApp (vShieldApp Rules) no se actualiza al agregar o eliminar máquinas virtuales de un cable virtual (VirtualWire)
Si la instalación de un firewall de vShield App de vCNS ya existente no se actualiza al firewall distribuido de NSX en modo mejorado, las nuevas máquinas virtuales con reglas de firewall basadas en cables virtuales (VirtualWire) no tendrán una dirección IP actualizada. Como resultado, estas máquinas virtuales no contarán con la protección del firewall de NSX. Este problema solo aparece en las siguientes situaciones:

  • Después de actualizar Manager de vCNS a NSX sin cambiar al modo DFW mejorado.
  • Si agrega nuevas máquinas virtuales a un cable virtual (VirtualWire) mediante reglas de vShield App que consumen dichos cables virtuales, estas reglas no tendrán definida la nueva dirección IP correspondiente a las nuevas máquinas virtuales.
  • Esto hará que vShield App no proteja las nuevas máquinas virtuales.

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

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

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

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

Solución alternativa: Ninguna.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Solución alternativa: Ninguna.

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

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

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

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

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

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

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

Solución alternativa: Ninguna.

Problema 1498376: 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 siguiente solución alternativa.

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>

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

Solución alternativa: Ninguna.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Opción 2: Realice los pasos siguientes.

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

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

    3. Elimine los VTEP de la VXLAN del host.

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

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

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

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

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

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

Solución alternativa: Ninguna.

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

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

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

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

Problema 1479314: 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.

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

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

Problema 1493777: 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.

Problema 1716619: La modificación de vNIC de NSX Edge 5.x.x Edges produce un error en NSX Manager 6.x.x porque falta la función "systemControl"
La configuración de los vNIC de NSX 5.x.x en NSX 6.x.x provoca un error porque no hay entrada de "systemControl" si Edge se creó en vCNS (vCloud Networking and Security) Manager. La función systemControl se introdujo en la versión 6.1.5 y no está disponible en vCNS ni vShield Manager 5.5.x. Este problema se produce al editar la configuración de interfaz de dispositivos Edge anteriores (vCNS o vShield 5.5.x) con NSX Manager 6.1.5, versiones posteriores o 6.2.x.

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

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

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

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

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

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

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

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

Problemas conocidos de NSX Manager

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

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

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

Solución alternativa: Ninguna.

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

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

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

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

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

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

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

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

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

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

Solución alternativa:

Realice los pasos siguientes:

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

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

Solución alternativa: Ninguna.

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

Solución alternativa: Ninguna.

Problema 1534877: 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.

Problema 1537258: 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.

Problema 1534622: 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.

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

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

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

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

Problema 1415480: 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://<nsxmgr-ip>/api/2.0/nwfabric/configure? action=synchronize

<nwFabricFeatureConfig>
<featureId>com.vmware.vshield.nsxmgr.messagingInfra</featureId>
  <resourceConfig>
    <resourceId>HOST/CLUSTER MOID</resourceId>
</resourceConfig>
</nwFabricFeatureConfig>

Problema 1027066: Es posible que vMotion de NSX Manager muestre el mensaje de error "El adaptador de red 1 de la tarjeta Ethernet virtual no es compatible" (Virtual ethernet card Network adapter 1 is not supported)
Se puede ignorar este error. Las redes funcionan correctamente después de vMotion.

Problema 1406471: 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
Si se instala una segunda instancia de NSX Manager con la misma dirección IP y un nombre de host único como primera instancia de NSX Manager, al restaurar la configuración se mostrará el nombre de host de la primera instancia de NSX Manager tras una restauración y, si reinicia el equipo, se mostrará el nombre de host de la segunda instancia de NSX Manager.

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.

Problema 1477041: La página de resumen del dispositivo virtual NSX Manager no muestra ningún nombre DNS
Cuando se inicia sesión en el dispositivo virtual NSX Manager, la página Resumen (Summary) tiene un campo para el nombre DNS. Este campo permanece en blanco a pesar de que se definió un nombre DNS para el dispositivo NSX Manager.

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

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

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

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

  1. Inicie sesión en el dispositivo virtual NSX Manager.

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

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

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

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

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

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

  • Restore of NSX Manager from backup failed (with Severity=Critical).

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

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

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

Solución alternativa: Ninguna.

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

Problema 1833934:
Todas las instancias de vCNS Edge (versión 5.5.4) y de NSX Edge (versiones 6.1.x y 6.2.x) que se ejecuten en el modo de comunicación VIX no podrán seguir administrándose después de Storage vMotion.
Las instancias de NSX Edge que se ejecutan con el modo de comunicación MessageBus no se verán afectadas.

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

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

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

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

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

Problema 1772004: La conmutación por error de alta disponibilidad (HA) de Edge del nodo 0 al 1 tarda más de lo esperado
La conmutación por error del nodo 0 al 1 tarda más de lo esperado en un entorno configurado en modo de alta disponibilidad de Edge. Sin embargo, la conmutación por error del tráfico del nodo 1 al 0 es normal.

Solución alternativa: Ninguna.

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

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

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

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

Nuevo problema 1726379: Si un rango de multidifusión IP tiene un valor de enlace superior mayor a 99 en los últimos tres octetos, se produce un error en la configuración del grupo de puertos troncal de VXLAN.
Al configurar un ID de segmento, si crea un valor de IP de multidifusión con un valor de enlace superior mayor a 99 en los últimos tres octetos, por ejemplo, 1.100.100.100, y un conmutador lógico híbrido o de multidifusión con el mismo rango, se producirá un error en la configuración del grupo de puertos troncal de VXLAN.

Solución alternativa: Mientras configura el ID de segmento, use el rango de la IP de multidifusión menor a 100 en cada uno de los tres últimos octetos, por ejemplo 100.1.1.1.

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

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

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

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

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

Problema 1733146: En determinadas condiciones, no se pueden crear ni modificar interfaces lógicas (LIF) de un DLR universal cuando no existe ninguna máquina virtual de control

Este problema se manifiesta bajo las siguientes circunstancias:

  • ECMP con dos rutas estáticas predeterminadas
  • Rutas estáticas con marca de salida local
Este problema se produce porque se solicitó una sincronización completa en vez de una actualización delta, lo que crea el rechazo de las entidades duplicadas y un funcionamiento erróneo. Se mostrará un mensaje similar al siguiente:
22-09-2016 20:18:58.080 ERROR DE GMT TaskFrameworkExecutor-24 NvpRestClientManagerImpl:774 - La API de NVP devuelve el error: [409] Ya existe en el enrutador una ruta con el mismo prefijo y la misma prioridad (Route with the same prefix and priority already exist on router) dc5e541a-d7a6-4cb9-8d8a-9334a9c51127

Solución alternativa:

  1. Eliminar el enrutador lógico universal.
  2. Implemente un nuevo enrutador lógico universal. Habilitar la salida local y desactivar “Implementar dispositivo Edge”. Configurar dos interfaces de vínculo superior y una dirección IP de puerta de enlace predeterminada a través del primer vínculo superior mediante id de idioma en el DLR principal (por ejemplo, 1111xxxx).
  3. No agregue una ruta estática de 0.0.0.0/0 con el id de idioma que se utilizó en el sitio secundario (por ejemplo, 2222xxxx).
  4. Agregue las dos rutas estáticas siguientes con el id de idioma y la dicción IP de salto siguiente correctos del sitio secundario (por ejemplo, 222xxxx).
  5. Ruta nº 1: 0.0.0.0/1
    Ruta nº 2: 128.0.0.0/1

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

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

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

Solución alternativa: Ninguna.

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

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

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

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

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

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

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

Solución alternativa: No hay solución.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Problema 1556924: Error Bloquearía (Would Block) por la pérdida de conectividad de L3 con VXLAN

Si las LIF de DLR están configuradas en el host, pero la capa de VXLAN subyacente no está completamente preparada, puede verse afectada la conectividad de algunas LIF de DLR. No se puede establecer la comunicación con algunas de las máquinas virtuales que pertenecen al DLR. Es posible que haya registros de tipo "Error al crear estado troncal de VXLAN: Bloquearía" (Failed to Create VXLAN trunk status: Would Block) en el archivo /var/log/vmkernel.log.

Solución alternativa: Puede eliminar las LIF y volver a crearlas. Otra posibilidad es reiniciar los hosts ESX afectados por el problema.

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

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

Solución alternativa: No hay solución.

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

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

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

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

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

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

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

PUT /api/4.0/edges/{edgeId}/firewall/config/global

<globalConfig>
<tcpPickOngoingConnections>true</tcpPickOngoingConnections>
</globalConfig>

Problema 1374523: Es necesario reiniciar ESXi o ejecutar [services.sh restart] tras la instalación del VIB de VXLAN para que los comandos de VXLAN estén disponibles al utilizar esxcli

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

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

Problema 1604514: Falla la edición o configuración de la puerta de enlace predeterminada de un DLR no administrado después de hacer clic en Publicar (Publish)

Cuando se agrega una puerta de enlace predeterminada a un DLR no administrado, falla la publicación con el error "La distancia de enrutamiento solo se admite en NSX Edge versión 6.2.0 y posteriores con máquinas virtuales de NSX Edge implementadas" (Routing Distance is support only on NSX Edge version 6.2.0 and later with NSX Edge VMs deployed). Esto se produce a causa de la distancia administrativa predeterminada "1" rellenada en la interfaz de usuario.

Solución alternativa: Elimine la distancia administrativa "1", que se proporciona de forma predeterminada.

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

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

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

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

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

Solución alternativa: Ninguna.

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

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

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

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

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

Solución alternativa: Actualizar la página.

Problema 1562767: 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.

Problema 1553600: 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, al esperar un evento de sondeo, puede que aprecie una demora para que se muestre la dirección IP asignada. (El enrutador lógico de NSX realiza un sondeo periódico para obtener los cambios producidos en las interfaces).

Problema 1534799: 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.

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

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

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

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

  • Acción: DENEGAR (DENY)
  • Red: CUALQUIERA (ANY)
  • Dirección: FUERA (OUT)

Solución alternativa: Ninguna.

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

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

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

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

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

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

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

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

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

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

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

Solución alternativa: Ninguna.

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

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

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

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

Solución alternativa: Ninguna.

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

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

Problema 1493611: 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.

Problemas conocidos de los servicios de seguridad

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

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

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

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

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

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

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

Solución alternativa:

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

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

Problema 1707931: El orden de las reglas de firewall distribuido cambia cuando existen directivas de servicio definidas en Service Composer y se modifica o publica una regla de firewall con un filtro aplicado en la interfaz de usuario del firewall
Cambiar el orden, agregar o eliminar directivas de servicio creadas en Service Composer tras realizar una o varias operaciones desde Redes y seguridad > Interfaz de usuario de firewall (Networking & Security > Firewall UI) harán que el orden de las reglas de firewall cambie y podría causar consecuencias involuntarias.

Solución alternativa: Las siguientes soluciones alternativas están disponibles:

  • Sincronice las reglas de Service Composer con las reglas de firewall; para ello, seleccione Sincronizar reglas de firewall en el menú Acciones en la pestaña Directivas de seguridad.
  • Utilice los filtros únicamente para ver los grupos de reglas, no para actualizarlos.
  • Realice una publicación completa antes de utilizar un filtro a través de la API de REST /api/4.0/firewall/globalroot-0/config PUT o a través de la interfaz de usuario mediante la actualización de varias secciones (no solo una de ellas) para garantizar que la configuración global del firewall se ha cambiado.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Este problema se produce normalmente en las situaciones siguientes:

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

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

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

Solución alternativa: Ninguna.

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

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

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

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

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

Problema 1662020: En la configuración de Cross vCenter aparece el mensaje siguiente: "Error en la última publicación en el host 10.156.221.88" (Last publish failed on host 10.156.221.88) en la interfaz de usuario de DFW en las pestañas General y Servicios de seguridad de partners (Partner Security Services)

El mensaje de error aparece cuando la NIC asociada a las reglas no está presente.

Solución alternativa: Ninguna.

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

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

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

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

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

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

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

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

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

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

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

Problema 1505316: La regla NetX de NSX no se publica en el host si el servicio seleccionado es un grupo de servicios
Cuando se crea una regla de redireccionamiento de Capa 3 en la pestaña Servicios de partner (Partner Services)en DFW, al seleccionar un grupo de servicios no se crea la regla correctamente.

Solución alternativa: Utilice servicios individuales en vez de utilizar un grupo de servicios al crear la regla.

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

Solución alternativa: Ninguna.

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

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

Solución alternativa: Ninguna.

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

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

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

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

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

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

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

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

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

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

Solución alternativa: Ninguna.

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

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

Solución alternativa: Ninguna.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Problemas conocidos de servicios de supervisión

Problema 1655593: Falta el estado en el panel de control de NSX al conectarse con los roles de auditor o administrador de seguridad

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

Solución alternativa: Ninguna.

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

Solución alternativa: En el caso de las máquinas virtuales asociadas a redes con puente L2, utilice la dirección IP o la dirección MAC de la interfaz que desea especificar como destino en una inspección de Traceflow. No puede elegir máquinas virtuales asociadas a redes con puente L2 como origen. Consulte el artículo de la base de conocimientos 2129191 para obtener más información.

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

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

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

Problemas de interoperabilidad de soluciones

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

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

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

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

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

Solución alternativa: Ninguna.

Problemas conocidos de NSX Controller

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

Nuevo problema 1760102: Es posible que las máquinas virtuales no puedan comunicarse después de eliminar NSX Controller y volver a implementarlo para recuperarse de un estado de falta de almacenamiento
Es posible que un entorno de NSX Controller for vSphere 6.2.4/6.2.5 esté en modo de solo lectura si se queda sin almacenamiento. Si elimina y vuelve a implementar el controlador para que se recupere de ese estado, es posible que algunas máquinas virtuales presenten errores de comunicación. Si se produce una interrupción en el almacenamiento de un controlador, se espera que se recupere del modo de solo lectura al reiniciarlo, pero esto no sucede actualmente en NSX.

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

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

Solución alternativa:

Siga estos pasos para solucionar este problema:

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

    PUT /2.0/vdn/controller/node

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

  2. Vuelva a habilitar IPsec mediante NSX API.

    PUT /2.0/vdn/controller/node

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

Aplique estas prácticas recomendadas para evitar este problema:

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

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

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

Problemas resueltos

Consulte los problemas resueltos en la versión 6.2.5 o en la versión 6.2.4 y anteriores.

Nuevos problemas resueltos en NSX 6.2.5

Los problemas resueltos en la versión 6.2.5 se agrupan de la siguiente manera:

Problemas conocidos resueltos en la versión 6.2.5

  • Problema solucionado 1685375: Falta la dirección MAC remota en la puerta de enlace de VXLAN
    Las direcciones MAC remotas no se envían tras volver a cargar el conmutador. En circunstancias excepcionales, es posible que la controladora de NSX no vuelva a rellenar las tablas de direcciones MAC de OVSDB cuando se reinicie una puerta de enlace de HW VTEP. Solucionado en NSX 6.2.5.

Problemas de instalación y actualización resueltos en NSX 6.2.5

  • Problema solucionado 1685894: Las máquinas virtuales migradas (con DRS) desde hosts con los VIB de la nueva versión a hosts con VIB de una versión anterior pierden conectividad a la red
    Esta situación no es compatible, ya que NSX no es compatible con versiones anteriores.

    • Con un clúster con DRS habilitado, cambie el modo de DRS a Manual durante la actualización hasta que todos los hosts del clúster estén actualizados a la nueva versión de NSX.

    • En un clúster que no tenga DRS habilitado, no migre las máquinas virtuales creadas o conectadas/desconectadas de un host con VIB de la nueva versión a un host con VIB de versiones anteriores.

      Solucionado en NSX 6.2.5.

    Problemas de redes lógicas resueltos en NSX 6.2.5

    • Problemas solucionados 1663902, 1717370: Realizar operaciones UPDATE/PUT en ESG/DLR durante la producción puede afectar al tráfico durante un breve período de tiempo
      Detectará interrupciones del tráfico durante un breve período de tiempo si realiza operaciones UPDATE/PUT en ESG/DLR durante la producción. Solucionado en NSX 6.2.5.

    • Problema solucionado 1737807 y 1703913: Las máquinas virtuales pierden conectividad a la red en NSX con HA de DLR
      En un entorno de NSX que utilice enrutamiento dinámico con alta disponibilidad (HA) configurado en una máquina virtual de control DLR, las máquinas virtuales pierden conectividad a la red cuando las máquinas virtuales de control DLR se recuperan de una condición de cerebro dividido. Los nodos de alta disponibilidad DLR, tanto principales como secundarios, mantienen el estado Activo (Active) simultáneamente. Solucionado en NSX 6.2.5.

    • Problema solucionado 1717369: Cuando se configuran en modo de alta disponibilidad, las máquinas virtuales de Edge tanto activa como en espera se pueden implementar en el mismo host
      Este problema se debe a que no se crearon ni aplicaron automáticamente reglas de antiafinidad en los hosts de vSphere durante las operaciones de actualización y reimplementación. Este problema no se producirá cuando se habilite alta disponibilidad en una instancia de Edge existente. Solucionado en NSX 6.2.5.

    • Problema solucionado 1717371: Las máquinas virtuales de NSX Edge no realizan una conmutación por error durante un evento de vSphere HA
      Cuando se ha instalado o se ha vuelto a implementar NSX Edge en un clúster de vSphere que tiene habilitado vSphere HA, durante la implementación de NSX Edge, NSX Manager habilita el administrador de inicio automático para el host de ESX en el que Edge se está implementando. Esto no es compatible con vSphere HA y, por lo tanto, vSphere no proporciona alta disponibilidad para la máquina virtual de Edge. Solucionado en NSX 6.2.5. Consulte el artículo Nota de actualización sobre el administrador de inicio automático.

    • Problema solucionado 1606785 y 1736095: El equilibrador de carga de NSX Edge puede completar la partición /var/log/ con los mensajes del archivo nagios.log
      La partición /var/log se completa en el equilibrador de carga de NSX Edge. Solucionado en NSX 6.2.5.

    Problemas de servicios Edge y de redes resueltos en NSX 6.2.5

    • Problema solucionado 1770797: Puerta de enlace predeterminada ignorada por los clientes si se configuran rutas estáticas sin clase en el grupo de DHCP de la puerta de enlace de servicios Edge
      RFC 3442 indica que si un servidor DHCP proporciona tanto una ruta predeterminada como rutas estáticas sin clase (opción 121), los clientes DHCP deberían ignorar la ruta predeterminada.
      A partir de la versión NSX 6.2.5, si configura un grupo de DHCP en una puerta de enlace de servicios Edge con rutas estáticas sin clase y una puerta de enlace predeterminada, la puerta de enlace predeterminada se agregará como ruta estática sin clase.

    • Problema solucionado 1777121: El gran volumen de la tabla de detección de MAC se actualiza con el puente de Capa 2 de NSX y el LACP podría ocasionar una situación de agotamiento de memoria
      Si un puente de Capa 2 de NSX ve una dirección MAC en otro vínculo superior, notifica un cambio de tabla de detección de MAC a los controladores a través del proceso netcpa. Los entornos de red que utilizan el LACP conocerán la misma dirección MAC en varias interfaces, lo que dará lugar a un gran volumen de actualizaciones de tablas y potencialmente agotará la memoria que el proceso netcpa necesita para realizar la notificación. Consulte el artículo 2147181 de la base de conocimientos de VMware. Solucionado en NSX 6.2.5.

    • Problema solucionado 1771285: La IP de multidifusión no se establece en el host para la red VXLAN con puente durante la operación de sincronización de controlador, lo que provoca que falle la conexión de plano de control.
      El plano de control se marca como "inactivo", lo cual da lugar a la interrupción del tráfico cada vez que la sincronización del controlador se activa en cualquiera de las siguientes formas:

      • DLR se vuelve a implementar, actualizar o fuerza la sincronización

      • Se sincroniza el estado del controlador de nivel VSM

      • El controlador se reinicia o se desconecta y vuelve a conectar

      Solucionado en NSX 6.2.5.

    • Problema solucionado 1766624: Se coloca un paquete aleatorio cuando el tráfico atraviesa un DLR puente en NSX
      Se coloca un paquete aleatorio cuando el tráfico atraviesa un DLR puente en NSX y el comando ping muestra varios mensajes como el siguiente: Finalizó el tiempo de espera de la solicitud (Timed Out Request). Solucionado en NSX 6.2.5.
      Para obtener más información, consulte el artículo 2148175 de la base de conocimientos de VMware.

    • Problema solucionado 1779313: Interrupción de conectividad después de reiniciar NSX Manager
      Se produce una interrupción de conectividad después de reiniciar NSX Manager. Esto sucede porque se eliminaron instancias del enrutador lógico distribuido (DLR) del host ESX debido a una sincronización parcial incorrecta de VDR. Cuando se produjo este error, el entorno de NSX se pudo recuperar al forzar la sincronización del servicio de VXLAN/enrutamiento. Solucionado en NSX 6.2.5.

    • Problema solucionado 1730633: Estado de supervisión incorrecto al usar objetos de agrupamiento
      La CLI no muestra el estado de supervisión correcto cuando se usan objetos de agrupamiento. Solucionado en NSX 6.2.5.

    • Problema solucionado 1745928: Se produce un error en la autenticación NTLM con la regla de aplicación no option http-server-close configurada
      Si configura la regla de aplicación no option http-server-close, se produce un error en la autenticación NTLM. Solucionado en NSX 6.2.5.

    • Problema solucionado 1736941: El cliente web del firewall de NSX Edge es muy lento
      El cliente web del firewall de NSX Edge es muy lento al desplazarse por la cuadrícula de las reglas del firewall de Edge. Solucionado en NSX 6.2.5.

    • Problema solucionado 1729066: El tiempo de espera del disco SCSI de Edge no se aplicó.
      El tiempo de espera del disco SCSI de Edge no se aplicó debido a que los permisos del archivo de secuencia de comandos de arranque no eran correctos. Solucionado en NSX 6.2.5.

    • Problema solucionado 1649098: Los agentes de retransmisión DHCP no funcionan en NSX
      Si el servidor DHCP está a más de 10 saltos de distancia, el TTL caduca mientras está en tránsito y los paquetes de DHCP no llegan al servidor de retransmisión configurado. Solucionado en NSX 6.2.5.

    Problemas de servicios de seguridad resueltos en NSX 6.2.5

    • Problema solucionado 1765744: Las reglas DFW con "Se aplica a" (Applied To) establecido en un "grupo de seguridad" no se publican en los hosts.
      Las reglas DFW con el campo "Se aplica a" (Applied To) establecido en un grupo de seguridad no se envían a los hosts ESXi en un clúster nuevo. Solucionado en NSX 6.2.5.

    • Problema solucionado 1760081: Las reglas de perfil de servicio o Netx no se muestran en los hosts después de publicarlas
      En entornos reducidos, el procesamiento de este conjunto de reglas tarda horas en implementarse en los hosts después de publicar reglas nuevas o modificadas. Solucionado en NSX 6.2.5.

    • Problema solucionado 1738421: El controlador DFW se cierra de forma inesperada en respuesta a una dirección no válida de una NIC de una máquina virtual
      En raras condiciones, un administrador de vCenter puede establecer una dirección no válida para la NIC de una máquina virtual, lo que provoca que se cierre el proceso del controlador de DFW de forma inesperada. Solucionado en NSX 6.2.5.

    • Problema solucionado 1723946: Las reglas eliminadas se convierten en reglas ANY ANY de forma momentánea.
      En un sistema de aprovisionamiento de reglas simultáneas donde las reglas se modifican o se eliminan, una regla que se agrega y se elimina en la siguiente llamada se puede publicar de forma momentánea como una regla ANY ANY hasta que se realice la operación de eliminación. Solucionado en NSX 6.2.5.

    • Problema resuelto: 1738588: Algunas máquinas virtuales no se agregan a un grupo de seguridad
      En algunas ocasiones, las máquinas virtuales no se agregan a un grupo de seguridad con criterios dinámicos hasta que alguna actividad actualiza la pertenencia al grupo. Solucionado en NSX 6.2.5.

    • Problema solucionado 1733763: NSX Distributed Firewall aplica el ALG de TFTP incorrecto
      NSX Distributed Firewall aplica el ALG de TFTP incorrecto mientras procesa una sesión TCP en el puerto 69. Solucionado en NSX 6.2.5.

    • Problema solucionado 1738419: Una dirección no válida para la NIC de una máquina virtual provoca que se cierre el proceso del controlador de DFW
      En raras condiciones, un administrador de vCenter puede establecer una dirección no válida para la NIC de una máquina virtual, lo que provoca que se cierre el proceso del controlador de DFW de forma inesperada. Solucionado en NSX 6.2.5.

    • Problema solucionado 1704661 y 1739613: Las máquinas virtuales pierden conectividad de red con el error: "No se pudo restaurar el estado de PF: Se superó el límite"
      Las máquinas virtuales pierden conectividad de red con el error: "No se pudo restaurar el estado de PF: Se superó el límite." Solucionado en NSX 6.2.5.

    • Problema solucionado 1732337 y 1724222: NSX Manager no puede enviar reglas de firewall al host ESXi 6.0 P03
      NSX Manager no puede enviar reglas de firewall al host ESXi 6.0 P03 y se produce un error en la comprobación de estado de NSX Edge. Solucionado en NSX 6.2.5.

    • Problema solucionado 1460363: NSX Manager independiente permite incorrectamente la importación de la configuración de firewall universal
      En una instancia de NSX Manager que se ejecute en modo independiente, las reglas de firewall universales se pueden importar aunque no se apliquen. Una vez importadas, estas reglas no se pueden eliminar a través de la API ni de Web Client. En su lugar, se conservan y se toman como una sección local. Solucionado en NSX 6.2.5.

    Los siguientes problemas se resolvieron en versiones 6.2.x anteriores:

    Problemas conocidos resueltos en la versión 6.2.4 y anteriores

    • Problema solucionado 1696192: Problemas de sincronización de NTP en NSX Manager
      Se introdujo una nueva versión de fcron en NSX 6.2.3. No hay variables de entorno definidas en fcrontab, lo cual significa que el entorno no se inició para las tareas de ejecución de fcron. El script no puede ubicar el comando ntpdate porque $PATH está vacío. Solucionado en NSX 6.2.4.

    • Problema solucionado 1644529: Aplicación de revisión de seguridad para solucionar la vulnerabilidad, CVE-2016-2079
      La versión 6.2.3 proporciona una aplicación de revisión de seguridad para solucionar la vulnerabilidad CVE-2016-2079.

    • Problema solucionado 1571156: El reinicio de vCenter 6.0 puede hacer que haya VTEP duplicados en los hosts ESX preparados mediante VXLAN
      Consulte el artículo de la base de conocimientos 2144605 de VMware. Solucionado en NSX 6.2.3.

    • Problema solucionado 1529665: El servicio DaaS no funciona como un servicio que usa 2 VIP diferentes (una VIP para HTTP y otra para PCoIP) y que deben tener exactamente la misma persistencia
      Este problema se solucionó en la versión 6.2.1.
    • Problema solucionado 1631261: Identity Firewall (IDFW) está configurado para funcionar con Log Scraper y GI está también instalado; después de desinstalar GI, IDFW deja de funcionar
      Solucionado en NSX 6.2.2.

    • Problema solucionado 1551773: La selección del menú desplegable vNIC HA de la puerta de enlace de servicios Edge (ESG) (Edge Security Gateway (ESG) HA vNIC) está siempre vacía en VMware NSX for vSphere 6.2.0
      Solucionado en NSX 6.2.2. Consulte el artículo de la base de conocimientos 2138158 de VMware.

    • Problema solucionado 1608608: Aplicación de revisión de seguridad para solucionar la vulnerabilidad de glibc, CVE-2015-7547
      La versión 6.2.2 proporciona una aplicación de revisión de seguridad para solucionar la vulnerabilidad CVE-2015-7547.

    • Problema solucionado 1480581: Las ranuras netcpa están CERRADAS y VM no se puede comunicar a través de VNI ni subredes
      Este problema se ha corregido al resolver el uso inseguro de subprocesos de boost::asio en vmacore. Solucionado en NSX 6.2.2. Consulte el artículo de la base de conocimientos 2137011 de VMware

    • Problema solucionado 1583566: Reglas no enviadas al host
      No se han podido programar las actualizaciones de la lista de reglas/ip de DFW debido a limitaciones de recursos en el marco de tareas en NSX Manager. El mensaje de error indicaba un problema para poner en la cola tareas para subprocesos de cambio de notificaciones. Este problema se solucionó en NSX 6.2.2.

    • Problema solucionado 1573818: El tráfico se ha interrumpido durante 50 segundos tras un error de HA en ESG
      Este problema se producía cuando NSX no podía sincronizar las rutas estáticas entre los nodos de NSX Edge de HA. Solucionado en NSX 6.2.2.

    • Problema solucionado 1570808: Problema de comprobación de estado de equilibrio de carga IP_HASH de NSX
      En IPVS, al utilizar el algoritmo source-ip hash, si el peso del servidor backend es 0, se envía una respuesta de "servicio no disponible" aunque haya disponibles servidores backend en buen estado. Este problema se solucionó en NSX 6.2.2.

    • Problema solucionado 1564005: En NetX de NSX no se pueden añadir reglas para redirigir el tráfico a los dispositivos asociados
      Los clientes no podían añadir reglas de redireccionamiento de tráfico a los conjuntos de reglas de NetX. Como consecuencia, los clientes no podían redirigir el tráfico a los dispositivos asociados. Esto afectaba a las reglas que utilizaban conjuntos de direcciones IP. Este problema se debía a un uso incorrecto de rangos de IP en las reglas de NetX. Solucionado en NSX 6.2.2.

    • Problema solucionado 1587660: Error de NetX de NSX en DVFilterProcessSlowPathPackets
      Si se utiliza NetX de NSX sin DFW, se produce un error en DVFilter. El mensaje de error completo indicaba error de NetX PF (err=11,cr2=0x10) en DVFilterProcessSlowPathPackets: VSIPDVFProcessSlowPathPackets: PFFilterPacket. Solucionado en NSX 6.2.2. Consulte el artículo de la base de conocimientos 2144018 de VMware

    • Problema solucionado 1591673: Al añadir un host ESXi a vSphere Distributed Switch se produce un error de licencia
      Únicamente en NSX 6.2.1, al añadir un host ESXi a vSphere Distributed Switch se produce un error de licencia: "La Dirección IP del host no tiene licencia para la función de VDS. No se puede añadir este host a dvSwitch". Si desea obtener más detalles, consulte el artículo de la base de conocimientos 2143397 de VMware. Solucionado en NSX 6.2.2.

    • Problema solucionado 1590563: Error de licencia empresarial tras actualización
      La rutina de actualización de NSX 6.2.1 le permitía actualizar a la versión 6.2.1 sin licencia empresarial de VMware, pero, tras la actualización, era necesario tener la licencia empresarial para utilizar NSX. Solucionado en NSX 6.2.2. Consulte el artículo de la base de conocimientos 2135310 de VMware

    • Problema solucionado 1589046: Paquete enviado a LIF sin resultados de DHCP relay en PSOD
      En el host ESXi sale una pantalla de diagnóstico morada (PSOD) si se envía un paquete de unidifusión de DHCP a la IP de una LIF que supuestamente tiene activado el protocolo DHCP relay, pero la LIF que recibe el paquete no tiene activado el protocolo DHCP relay. Este problema se solucionó en NSX 6.2.2. Consulte el artículo de la base de conocimientos 2144314 de VMware

    • Problema solucionado 1593436: En el modo híbrido de VXLAN, si la controladora se desconecta de forma incorrecta, el modo pasa a ser de multidifusión
      Solucionado en NSX 6.2.2. Consulte el artículo de la base de conocimientos 2144457 de VMware

    • Problema solucionado 1574995: Error de publicación de DFW
      Si las reglas de DFW se modifican y se guardan en el modo de filtrado, es posible que éstas no se guarden ni se publiquen. Solucionado en NSX 6.2.2. Consulte el artículo de la base de conocimientos 2141155 de VMware

    • Problema solucionado 1422110: Una de las controladoras NSX Controller no entrega el rol maestro a otras controladoras cuando se apaga
      Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1483728: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1487910: 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 - Finalizó 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". Este problema se solucionó en NSX 6.2.0.

    • Problema solucionado 1571548: En la versión NSX for vSphere 6.2.0 y posteriores, si se cambia directamente una dirección IP de VTEP en un host o VC, la anterior dirección IP del VTEP se libera automáticamente.
      Solucionado en NSX 6.2.0.

    • Problema solucionado 1551164: La interfaz de usuario de NSX aparece sombreada durante algunos segundos y presenta un bajo rendimiento en NSX for vSphere 6.2.0
      Consulte el artículo de la base de conocimientos 2141919 de VMware. Solucionado en NSX 6.2.1.

    • Problema solucionado 1545840: No se puede deshabilitar NSX Distributed Firewall (DFW) en un host de VMware NSX for vSphere 6.x
      Consulte también el artículo de la base de conocimientos 2141915 de VMware. Solucionado en NSX 6.2.1.

    • Problema solucionado 1528680: 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 (KB 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. Solucionado en NSX 6.2.1.

    • Problema solucionado 1545885: 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. Solucionado en NSX 6.2.1.

    • Problema solucionado 1476087: 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. Solucionado en NSX 6.2.1.

    • Problema solucionado 1545830: 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. Solucionado en NSX 6.2.1.

    • Problema solucionado 1545873: 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.

      Solucionado 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 en la versión 6.2.4 y anteriores

    • Problema solucionado 1710454: Inconsistencia del tiempo de inactividad de HA entre los DLR actualizados y los implementados recientemente
      Este problema se produce porque el tiempo de inactividad de HA de los DLR actualizados recientemente se cambió explícitamente de 15 a 6 segundos durante la actualización. Consulte el artículo 2146714 de la base de conocimientos de VMware. Solucionado en NSX 6.2.4.

    • Problema solucionado 1578509: Tras reiniciar EAM, el servicio Guest Introspection (GI) mostrará el estado advertencia
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1539203: Después de la actualización de NSX, el complemento de NSX se desconecta del VC principal durante una actualización de Cross-vCenter
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1558017: 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.

    • Problema solucionado 1490496: Tras la actualización de NSX, Guest Introspection no se puede comunicar con NSX Manager
      Tras actualizar de NSX 6.0.x a NSX 6.1.x o de NSX 6.0.x a NSX 6.2 y antes de actualizar el servicio Guest Introspection, NSX Manager no se puede comunicar con Guest Introspection Universal Service Virtual Machine (USVM). Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1536179: 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. Solucionado en NSX 6.2.1.

    • Problema solucionado 1393503: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1088497: 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) Solucionado en NSX 6.2.0.

    • Problema solucionado 1328589: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1446544: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1418836: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1410153: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1412133: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1467438: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1440867: 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. Solucionado en NSX 6.2.0.

    Problemas de NSX Manager resueltos en la versión 6.2.4 y anteriores

    • Problema solucionado 1668519: Uso elevado de la CPU en NSX Manager
      Es posible que NSX Manager experimente un uso elevado constante de la CPU, sobre todo después de un reinicio, cuando la tarea purgetask tiene que procesar o limpiar un volumen elevado de entradas del trabajo en la base de datos de NSX Manager.
      Solución alternativa: Póngase en contacto con el soporte técnico de VMware. Consulte el artículo 2145934 de la base de conocimientos de VMware.Solucionado en NSX 6.2.4.

    • Problema solucionado 1603954: NSX Manager muestra constantemente el uso de memoria casi al 100%
      Al reiniciar NSX Manager, el uso de memoria baja del 100% de forma significativa. Sin embargo, el valor del uso vuelve a subir al 100% a lo largo del tiempo y se muestra a ese nivel. Solucionado en NSX 6.2.4.

    • Problema solucionado 1540187: Los usuarios no pueden iniciar sesión en vSphere Web Client ni usar el complemento NSX, ya que aparece un error que afirma que los usuarios o el grupo no tienen permisos
      Este problema está relacionado con el tiempo de espera necesario para la generación del token SAML. En ocasiones, cuando la operación de solicitud no se completa al comunicarse con el servicio SSO, NSX no puede actualizar el proveedor de registro de solución de forma interna. Una vez que esto sucede, causa una excepción de puntero nulo en todas las solicitudes.
      Solucionado en NSX 6.2.3 al evitar las excepciones de puntero nulo y al volver a conectar al servicio SSO si es necesario.

    • Problema solucionado 1640388: Al desinstalar Guest Introspection en un clúster que no incluye ninguna máquina virtual, aparece el mensaje "Error de limpieza previo a la desinstalación" (Pre-Uninstall cleanup failed) y se muestra el estado sin resolver
      Se produjo un problema conocido en la lógica de desinstalación de Guest Introspection.
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1534588: 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.
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1593910: No se detecta ni evita la existencia de una dirección IP de NSX Manager duplicada
      Si la dirección IP de NSX Manager está asignada a otro dispositivo de la red, no se genera un registro de eventos o errores explícitos. Como resultado, los hosts y controladores NSX Controller pueden usar una dirección MAC incorrecta para responder a NSX Manager, lo que provoca la interrupción de la ruta de datos. Solución alternativa: Intente determinar cuál es el otro dispositivo de la red y elimínelo o asígnele una dirección IP diferente. Debido a la presencia de una IP de NSX Manager duplicada en la red, los hosts y los controladores están respondiendo a NSX Manager o a la máquina virtual con una dirección MAC errónea. Esto afecta a las comunicaciones entre NSX Manager y ESX y entre NSX Manager y los controladores NSX Controller. Esto puede producir una interrupción en la ruta de datos. En este caso, las aplicaciones se ven afectadas hasta que la IP duplicada se elimina de la red y los canales de comunicaciones se restauran.
      Solucionado en NSX 6.2.3 al añadir un evento del sistema cuando se detecta una dirección IP duplicada.

    • Problema solucionado 1489648: NSX no se encuentra disponible en el complemento de vSphere Web Client después de realizar una copia de seguridad de NSX Manager con una instantánea en modo inactivo
      Consulte el artículo de la base de conocimientos 2142263 de VMware. Solucionado en NSX 6.2.3.

    • Problema solucionado 1440451: 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).

    • Problema solucionado 1568861: No se puede añadir un NSX Manager secundario si la interfaz gráfica de usuario está en japonés en Firefox
      Cuando 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á, lo cual bloquea la configuración.

    • Problema solucionado 1482989 / 1522092: NSX Networking and Security muestra todos los hosts en VERDE, pero el estado del clúster aparece en ROJO de forma incorrecta
      En la versión 6.1.4 de NSX y versiones anteriores, no era habitual que la pestaña de Seguridad y redes NSX (NSX Networking and Security) mostrara todos los hosts en VERDE pero apareciera el estado del clúster en ROJO de forma incorrecta, e indicase una situación de error cuando no se producía. Solucionado en NSX 6.1.5.

    • Problema solucionado 1515656: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1484939: 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)
      Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1521710: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1479665: Desde la versión 6.2.1, NSX Manager realiza una consulta de cada nodo de la controladora en el clúster para obtener información de conexión entre dicha controladora y las demás controladoras 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. Solucionado en NSX 6.2.1.

    • Problema solucionado 1525516: 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. Solucionado en NSX 6.2.1.

    • Problema solucionado 1509454: 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. Solucionado en NSX 6.2.1. Solucionado en NSX 6.2.1.

    • Problema solucionado 1418655: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1366669: 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. Solucionado en NSX 6.2.0. Solucionado en NSX 6.2.0.

    • Problema solucionado 1352169: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1497113: 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>). Solucionado en NSX 6.2.0.

    Problemas de redes lógicas y de enrutamiento de NSX Edge resueltos en la versión 6.2.4 y anteriores

    • Problema solucionado 1696887: Las máquinas virtuales pierden la conectividad norte a la red de los enrutadores lógicos distribuidos
      Si la máquina virtual obtiene el pMac del enrutador lógico como una dirección MAC para la puerta de enlace predeterminada en lugar de la dirección MAC del enrutador lógico genérico, se pierde la conectividad norte del enrutador lógico.
      Solución alternativa: Consulte el artículo 2146293 de la base de conocimientos de VMware. Solucionado en NSX 6.2.4.

    • Problema resuelto: Problemas de rutas de datos para VNI con NSX Controller desconectado
      Este problema se produce porque la regeneración de claves de IPSec se deshabilita en las versiones NSX-V 6.1.5, 6.1.6, 6.2, 6,2,1 y 6.2.2 para evitar encontrar otro problema conocido de IPSec.

      Consulte el artículo 2146973 de la base de conocimientos de VMware. Solucionado en NSX 6.2.3.
    • Problema solucionado 1591582: En algunas situaciones muy concretas, es posible que las solicitudes de ARP enviadas mediante una instancia VDR se caigan
      Puede que se caigan las solicitudes de ARP mediante VDR de máquinas virtuales ubicadas en otros hosts al procesar los resultados del vínculo superior de VDR, lo que hace que se establezca una conexión lenta.

    • Problema solucionado 1501900: El enrutador OSPF de Edge permanece en estado ExchangeStart después de cambiar la dirección IP de la interfaz de OSPF
      Debido a una condición de carrera, cambiar la dirección IP en una interfaz de OSPF provocaba que los vecinos OSPF permanecieran en estado ExchangeStart en ambos lados.​ En condiciones normales, se admite la operación de cambiar la dirección IP de la interfaz de OSPF.
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1498251: El protocolo de enrutamiento IS-IS no es compatible con el enrutador de puerta de enlace de servicios Edge
    • Se eliminan las referencias a IS-IS de la interfaz de usuario y de la API en NSX 6.2.3.

    • Problema solucionado 1492738: 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
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1552038: Pérdida intermitente de conexión de NSX Edge a la interfaz del vínculo superior de DLR
      La causa de este problema es el NSX Edge que tiene la dirección MAC de las máquinas virtuales del control DLR en su tabla ARP en lugar de tenerla en la dirección MAC de la instancia local del DLR. Esta versión agrega un filtro ARP de salida para prevenir que las máquinas virtuales de control DLR generen ARP relacionados con la dirección IP de DLR.

    • Problema solucionado 1454161: Los enrutadores estáticos no se pueden configurar con un salto siguiente igual a una dirección IP de 31 bits
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1528443: La caché de ARP de VXLAN del host no se actualiza cuando una máquina virtual de Edge envía un GARP durante la conmutación por error
      En ciertas implementaciones en las que las máquinas virtuales y Edge se encuentran en el mismo segmento de VXLAN, la caché de ARP de VXLA del host no se actualizará tras la conmutación por error de Edge. Solucionado en NSX 6.2.3.

    • Problema solucionado 1600874: Las máquinas virtuales en mal estado no se eliminan durante la implementación de la nueva máquina virtual de Edge
      Al actualizar un dispositivo de Edge, si fallan tanto la operación de publicación como las operaciones de restauración, la máquina virtual de Edge original permanece en la base de datos de NSX Manager, mientras que el VC conserva el nuevo ID de la máquina virtual de Edge. Debido a esta falta de correspondencia, se producirá un error si se intenta implementar de nuevo una máquina virtual de Edge. También se producirá un fallo si se fuerza la sincronización y se mostrará el error "Máquina virtual no encontrada" (VM not found).

    • Problema solucionado 1467774: Se muestra un valor incorrecto en el comando "show ip bgp neighbor" del campo de distancia administrativa
      Una ruta conocida por un par EBGP y anunciada a un par IBGP en el mismo AS mantiene incorrectamente la distancia de administración anterior. Este problema se solucionó en la versión 6.2.3.

    • Problema solucionado 1613383: Para un equilibrador de carga de NSX Edge que se ejecute en el modo L4, el valor de las conexiones actuales usaron incorrectamente el número de conexiones totales
      En esta versión se soluciona este problema; para ello se calculan las conexiones actuales a partir de la suma de las conexiones activas. Este problema se solucionó en la versión 6.2.3.

    • Problema solucionado 1584664: Si las máquinas virtuales que forman parte del grupo del equilibrador de carga se eliminan manualmente del inventario de vCenter sin haber eliminado primero su configuración en NSX, las entradas de base de datos huérfanas se quedan en la base de datos de NSX Manager. Se incluirá una excepción ObjectNotFoundException en los registros de NSX Manager.
      Este problema se solucionó en la versión 6.2.3.

    • Problema solucionado 1446809: vCloud Director ya no puede administrar NSX Edge si no se envía ningún evento de recuperación de comprobación de estado después de reiniciar Edge
      NSX Manager guarda el estado de la conectividad de Edge en memoria. Cuando una máquina virtual de Edge no responde a una comprobación de estado, se genera un evento de omisión y, durante la recuperación, se genera un evento de recuperación. Si se reinicia NSX Manager, es posible que no se envíe el evento de recuperación si no se omitió ninguna comprobación de estado después del reinicio. Dado que vCloud Director depende de estos eventos, un evento de recuperación omitido puede hacer que una máquina virtual de Edge no se pueda administrar desde VCD.

    • Problema solucionado 1462506: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1441319: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1399863: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1445291: 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.

    • Problema solucionado 1534811: 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. Solucionado en NSX 6.2.1.

    • Problema solucionado 1500624: Los filtros BGP tardan aproximadamente 40 segundos en 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). Solucionado en NSX 6.2.0.

    • Problema solucionado 1484758: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1265605: No se pueden agregar caracteres que no sean ASCII al nombre de arrendatario o puente en el enrutador lógico
      Las API de NSX Controller no son compatibles con caracteres no ASCII. Solucionado en NSX 6.2.0.

    • Problema solucionado 1341784: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1422110: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1440790: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1432420: La eliminación de varias reglas BGP en NSX Edge/DLR al mismo tiempo provoca errores en el cliente web. Solucionado en NSX 6.2.0. Ahora puede eliminar varias reglas BGP al mismo tiempo.

    • Problema solucionado 1431716: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1441773: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1463579: 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. Solucionado en NSX 6.2.0.

    Problemas de servicios de Edge resueltos en la versión 6.2.4 y anteriores

    • Problema solucionado 1674721: No se puede administrar NSX Edge después de actualizar a NSX 6.2.3
      Este problema se presenta cuando serverSsl o clientSsl está configurado en el equilibrador de carga pero el valor del cifrado está configurado como NULO (NULL) en la versión anterior.
      Solución alternativa: Consulte el artículo 2145887 de la base de conocimientos de VMware. Solucionado en NSX 6.2.4.

    • Problema solucionado 1698389: Después de cambiar algunas configuraciones de enrutamiento a través de vSphere Web Client, la configuración del enrutamiento es incorrecta
      Algunas modificaciones provocan una configuración incorrecta cuando se editan los vecinos BGP, la asignación del área OSPF en la interfaz y la redistribución del enrutamiento (prefijos IP o filtros BGP). Cuando se configura un gran número de vecinos BGP, es posible que se produzca una configuración incorrecta al desplazarse por la lista y, a continuación, realizar algún cambio.
      Solución alternativa: Consulte el artículo 2146363 de la base de conocimientos de VMware. Solucionado en NSX 6.2.4.

    • Problema solucionado 1633694: Un error en el almacenamiento puede provocar una pérdida de configuración de VXLAN en la base de datos de NSX Manager
      Después de que se produzca un error en el almacenamiento, Virtual Center informa de que se eliminó el DVS y NSX Manager responde eliminando la configuración VXLAN asociada a dicho DVS. Cuando esto ocurre, se imprimirá un mensaje de error en los registros de NSX Manager similar a: "INFO DCNPool-9 VcDriver:1077 - Deleting vmknic info from host tables [host-21843 : 319]" .
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1456172: La NAT no traduce las direcciones IP cuando NSX Edge Firewall está deshabilitado
      Cuando el firewall de la puerta de enlace de Edge está deshabilitado, se deshabilitan también todos los servicios con estado si el dispositivo Edge es un dispositivo 6.0 Extra Large o un dispositivo Edge 6.1 y 6.2 Edge. La versión 6.2.3 de NSX incluye en la interfaz de usuario una advertencia de que otros servicios con estado están también deshabilitados.

    • Problema solucionado 1499601: Tiempos de conmutación por error de HA ampliados para la puerta de enlace de servicios Edge (ESG) o DLR con máquinas virtuales de Edge cuando se utilizan solo rutas estáticas
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1618289: Interrupción de TCP inesperada en sesiones TCP durante la conmutación por error de alta disponibilidad (HA) de Edge VMware NSX for vSphere 6.2.x
      Este problema se producía debido al uso de bibliotecas internas obsoletas en VMware NSX for vSphere 6.2.x. Solucionado en NSX 6.2.3.

    • Problema solucionado 1653484: Los volcados de memoria de NSX Edge no mostraban los nombres de las funciones
      NSX 6.2.3 mejora la capacidad de depuración al mostrar en el archivo principal información sobre la dirección de la memoria. Sin embargo, debe habilitar los volcados de memoria solo cuando lo solicite el equipo de soporte técnico de VMware.
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1604506: No se puede implementar DLR sin la máquina virtual de NSX Edge si se utiliza la puerta de enlace predeterminada en caso de que se utilice enrutamiento estático

      Al implementar un nuevo enrutador lógico distribuido (DLR) a través de Web Client, si selecciona la opción para "configurar puerta de enlace predeterminada" durante la configuración, el DLR no se podrá crear y se abrirá una ventana emergente con el error siguiente: "[Enrutamiento] La distancia administrativa es compatible únicamente en NSX Edge versión 6.2.0 y posteriores con máquinas virtuales de NSX Edge implementadas".

      Consulte el artículo 2144551 de la base de conocimientos de VMware para obtener más información. Solucionado en NSX 6.2.3.

    • Problema solucionado 1445057: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1406471: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1444581: 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). Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1444784: 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). Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1440867: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1548939: 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. Solucionado en NSX 6.2.1.

    • Problema solucionado 1599706: Paquete SYN o ACK perdido en la comunicación a través de LDR entre 2 VNI
      Solucionado en NSX 6.2.2.

    • Problema solucionado 1082549: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1403594: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1477176: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1484743: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1449461: La ejecución del comando clear ip ospf neighbor devuelve un error de segmentación
      Solucionado en NSX 6.2.0.

    • Problema solucionado 1418264: 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. Solucionado en NSX 6.2.0.

    Problemas de servicios de seguridad resueltos en la versión 6.2.4 y anteriores

    • Problemas solucionados 1558051, 1769174: Para los clústeres con un DFW en estado deshabilitado, las actualizaciones de la lista de exclusión no se aplican y los filtros se crean en la listas de exclusiones
      Las actualizaciones de la lista de exclusión no se aplican si uno de los clústeres tiene un DFW en estado deshabilitado. Esto ocurría porque la API isFirewallEnabled realizaba una comprobación estricta y devolvía el valor "true" únicamente si todos los hosts tenían DFW habilitado. Si cualquier clúster del entorno tenía el firewall deshabilitado, se devolvía el valor "false".
      Después de la corrección, la API ahora comprueba si el firewall está habilitado para los clústeres y devuelve "true" si cualquiera de ellos incluido en el entorno tiene el firewall habilitado.
      Además, los filtros que se crearon en la lista de exclusión se actualizan en los hosts que tienen el DFW deshabilitado. Tras la corrección, en cada una de las máquinas virtuales excluidas, la API accede al clúster y, si este tiene el firewall habilitado, agregará los ID de vNIC de sistema de dicho clúster y los ID de vNIC, y publicará la lista de exclusión de cada clúster. La migración de la máquina virtual de un clúster a otro se lleva a cabo mediante la publicación de la lista de exclusión del clúster de la máquina virtual. Solucionado en NSX 6.2.4.

    • Problema solucionado 1694483: Después de instalar NSX for vSphere 6.2.3 o actualizar a dicha versión con Distributed Firewall (DFW) y los grupos de seguridad (SG) configurados, puede interrumpirse el tráfico en una operación de vMotion en el cálculo de las máquinas virtuales
      Consulte el artículo 2146227 de la base de conocimientos de VMware. Solucionado en NSX 6.2.4.

    • Problema solucionado 1689356: Al editar un grupo de seguridad a través de una búsqueda, se eliminarán todos sus objetos
      Al editar un grupo de seguridad buscando un miembro incluido estáticamente (por ejemplo, una máquina virtual) y eliminándolo después, todos los miembros incluidos de forma estática se eliminan del grupo de seguridad. Solucionado en NSX 6.2.4.

    • Problema solucionado 1675694: El firewall distribuido coloca paquetes cuando vuelve a utilizar la misma IP y el mismo puerto después de la interrupción de la conexión
      Las conexiones medio cerradas no se desconectan, lo que desencadena un error en las nuevas conexiones a dicho puerto e IP. Solucionado en NSX 6.2.4.

    • Problema solucionado 1698863: La retransmisión del paquete TFTP inicial en una sesión TFTP establecida mientras el firewall distribuido está habilitado puede ocasionar que aparezca una pantalla de diagnóstico de color púrpura
      Solucionado en NSX 6.2.4.

    • Problema solucionado 1701195: El montón del firewall distribuido está agotado
      En grandes implementaciones con ratios de consolidación elevada (número de máquinas virtuales aprovisionadas por host), la memoria en motón del firewall distribuido puede agotarse, ya que DFW en VMkernel tiene una cantidad disponible limitada (hasta 1,5 GB en hosts con una memoria de gran capacidad). Solucionado en NSX 6.2.4. El tamaño máximo del montón se aumentó a 3 GB para los hosts ESXi 6.0 que cuentan con una memoria de 96 GB o superior a esta capacidad, lo que permite un ratio de consolidación más elevado.

    • Problema solucionado 1712698: Se eliminan las reglas de las directivas de seguridad de Service Composer después de intentar modificar las reglas del firewall de la directiva de seguridad
      Solucionado en NSX 6.2.4.

    • Problema solucionado 1620109: Es posible que la implementación de máquinas virtuales de servicios de terceros no se realice según lo esperado, por lo que el estado de la instalación aparecerá como "Fallido" (Failed)
      Por ejemplo, es posible que la máquina virtual segura no reciba la dirección IP esperada. Se incluirá el mensaje de error "El valor proporcionado para el parámetro property.info.key no es correcto" (Value provided for parameter property.info.key was not correct) de los registros de NSX Manager.

      Consulte el artículo de la base de conocimientos 2145376 de VMware. Solucionado en NSX 6.2.3.
    • Problema solucionado 1619570: En una configuración de DFW a gran escala con millones de reglas y Service Composer, es posible que se necesiten algunos segundos después de reiniciar para que se publiquen las reglas. Durante este periodo, no se pueden publicar nuevas reglas
      NSX 6.2.3 reduce el tiempo de sincronización de las reglas de firewall al reiniciar; para ello, solo se vuelven a sincronizar aquellas directivas de firewall cuya última revisión no se pudo procesar debido a una operación de reinicio.

    • Problema solucionado 1526781: La consulta a la API getFirewallConfigLayer3SectionByName no devuelve el campo responseHeaders en NSX 6.2.x
      Este problema se solucionó en la versión 6.2.3 y la información del encabezado de etiquetas de entidad (ETag) se restauró en los resultados de la API.

    • Problema solucionado 1599576: No se puede publicar una regla editada en una sección de firewall universal porque se estableció un valor nulo en el campo ID de la sección global (Global Section ID).
      No aparece ningún mensaje de error. Solucionado en NSX 6.2.3.

    • Problema solucionado 1558501: Es posible que se produzca un error en la instalación de Guest Introspection si no se puede conectar Universal Service Virtual Machine (USVM) a NSX Manager
      Si se configura NSX Manager solo con un FQDN, es posible que se produzca un error en el canal de comunicación entre NSX Manager y la máquina virtual del servicio Guest Introspection. Cuando ocurre este problema, el servicio Guest Introspection permanece en estado "Advertencia" (Warning). Aparece el mensaje "UnknownHostException" en el archivo eventmanager.log de USVM. Solucionado en NSX 6.2.3 al añadir compatibilidad con DNS.

    • Problema solucionado 1673068: La edición de las reglas de firewall en la sección Directiva de Service Composer (Service Composer Policy) provoca una configuración no sincronizada
      La sincronización de Service Composer se detiene cuando se agregan o se editan las reglas de firewall desde la sección Directiva de Service Composer (Service Composer Policy) en la pantalla de configuración del firewall. Solucionado al cambiar la sección de Service Composer de la configuración del firewall a solo lectura. Las reglas creadas con Service Composer deben administrarse mediante Service Composer. Solucionado en NSX 6.2.3.

    • Problema solucionado 1639612: Problemas de conectividad MSRPC con Windows 2008 y posteriores en NSX for vSphere 6.2.x
      En versiones posteriores de Windows que admiten direccionamiento de 64 bits, el protocolo DCE/EPM negocia NDR64 como formato de codificación de la transferencia, lo que hace que el firewall no analice el paquete de respuesta de EPM y, por tanto, no pueda detectar el puerto dinámico que se debe abrir. Consulte el artículo de la base de conocimientos 2145135 de VMware. Solucionado en NSX 6.2.3.

    • Problema solucionado 1567693: 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)
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1407920: 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).
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1498504: La máquina virtual pierde la protección del firewall cuando se elimina de uno de dos grupos de servicio superpuestos
      Los filtros NetX (creados mediante el flujo de trabajo de firewall) del host se eliminan cuando otro servicio que Service Composer creó se aplica a la misma máquina virtual. Esto podría ocurrir, por ejemplo, cuando se aplica un perfil de servicio a dos grupos de servicio superpuestos. En este caso. una máquina virtual pierde la protección si se encuentra en ambos grupos de servicio y, a continuación, se elimina de uno de ellos. Solucionado en NSX 6.2.3 mediante la introducción del campo de prioridad (priority) en el perfil de servicio. Si hay grupos de servicio superpuestos para una vNIC en un host, se aplica el perfil de servicio con la prioridad más alta.

    • Problema solucionado 1550370: El sistema operativo de las máquinas virtuales Linux con montajes NFSv3 deja de responder después de 15 minutos de interrupción en la ruta de datos ascendente
      Consulte el artículo de la base de conocimientos 2133815 de VMware. Solucionado en NSX 6.2.3.

    • Problema solucionado 1494366: 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
      Al copiar una regla de firewall con la opción de origen/destino negativos habilitada, se creará un nuevo firewall con esta opción deshabilitada. Solucionado en NSX 6.2.3.

    • Problema solucionado 1473767: 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. Solucionado en NSX 6.2.3.
      Consulte el artículo de la base de conocimientos 2091376 de VMware.

    • Problema solucionado 1611238: En Edge Firewall 6.2.x, solo se mostraban los grupos de seguridad creados en el alcance de Edge (los grupos de seguridad del alcance de Edge solo se podían crear mediante REST)
      En la versión 6.2.3, los grupos de seguridad creados en el alcance global (estos se pueden crear en la interfaz de usuario) y los creados en el alcance de Edge para el correspondiente dispositivo Edge (estos se pueden crear solo mediante REST) se muestran en la lista Grupo de seguridad (Security Group) de Edge Firewall bajo las columnas Origen/Destino (Source/Destination).
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1516460: Las reglas de firewall siguen marcándose como válidas, incluso después de haber eliminado de la regla el conmutador lógico al que se aplicó
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1542157: Pérdida de la función Distributed Firewall tras una operación de vMotion de máquinas virtuales protegidas en el host de destino
      La eliminación de un host preparado con NSX desde el inventario de VC elimina la entrada del host de las tablas del firewall interno. La posterior incorporación de dicho host al inventario de VC no implicaba que se volvieran a crear las entradas de la tabla del firewall. Solucionado en NSX 6.2.3.

    • Problema solucionado 1592439: Service Composer no puede convertir las máquinas virtuales en grupos de seguridad
      Este problema se producía por un interbloqueo de EpSecLib en Universal Service Virtual Machine (USVM). Solucionado en NSX 6.2.3.

    • Problema solucionado 1534597: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1491042: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1468169: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1476642: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1510350: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1515656: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1515630: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1545879: Si cambia el nombre de un borrador de firewall existente, se producirá un error de funcionamiento y la interfaz de usuario mostrará el mensaje siguiente: "Error interno del servidor" (Internal Server Error)
      Solucionado en NSX 6.2.1.

    • Problema solucionado 1545893: 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. Solucionado en NSX 6.2.1.

    • Problema solucionado 1545853: 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. Solucionado en NSX 6.2.1.

    • Problema solucionado 1545895: El tiempo de espera de los comandos de CLI centrales que se ejecutan para un host ESXi específico finaliza en algunas configuraciones
      Solucionado en NSX 6.2.1.

    • Problema solucionado 1491365: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1113755: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1425691: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1352926: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1295384: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1412713: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1448022: 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). Solucionado en NSX 6.2.0.

    • Problema solucionado 1473585: No se puede agregar la regla de firewall con origen/destino como varias direcciones IP separadas por coma. Solucionado en NSX 6.2.0.

    • Problema solucionado 1460351: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1501451: 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. Solucionado en NSX 6.2.0.

    Problemas de servicios de supervisión resueltos en la versión 6.2.4 y anteriores

    • Problema solucionado 1697118: Todos los flujos IPFIX se etiquetan como nuevos flujos en lugar de flujos actualizados, dando lugar a procesos de actualización frecuentes en el recopilador IPFIX
      Además, la frecuencia para enviar flujos activos no respeta el valor configurado del tiempo de espera del flujo activo. Solucionado en NSX 6.2.4.

    • Problema solucionado 1617561: Inundaciones de archivos de registro vmkernel log files con el mensaje "ALERT: vdrb: VdrArpInput:1015: CP:Malformed pkt"
      Esto ocurre cuando el dispositivo de conexión de red, como un servidor, envía una solicitud de ARP en formato ARP de redes IEEE 802. Solucionado en NSX 6.2.3.

    • Problema solucionado 1525620: El valor de icmpCode en una regla de Distributed Firewall no se enviaba al host. Los valores de protocolName y subProtocolName funcionan según lo esperado
      Solucionado en NSX 6.2.3.

    • Problema solucionado 1563830: Falla la aplicación de la regla de firewall en un dispositivo DLR con 'mgmtInterface' como origen o destino
      Se incluye un mensaje similar a "vShield Edge:10014:Error de configuración en máquina virtual de NSX Edge" (vShield Edge:10014:Configuration failed on NSX Edge vm) en los registros de NSX Manager. Solucionado en NSX 6.2.3.

    • Problema solucionado 1474498: Falla la importación del borrador de las reglas de firewall después de eliminar la configuración de firewall existente mediante una solicitud de la API REST
      Este problema se produce cuando se crean borradores en VMware NSX for vSphere 6.1.x y 6.2.x que incluyen la sección id = null. Solucionado en NSX 6.2.3.

    • Problema solucionado 1545888: 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. Solucionado en NSX 6.2.1.

    • Problema solucionado 1460085: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1288395: 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

      Solucionado en NSX 6.2.0.
    • Problema solucionado 1354728: 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. Solucionado en NSX 6.2.0.

    Problemas de interoperabilidad de soluciones resueltos en la versión 6.2.4 y anteriores

    • Problema solucionado 1571170: Algunos informes de Log Insight no se admiten en NSX 6.2 con algunas versiones del paquete de contenido de vRealize
      Solucionado en la última versión del paquete de contenido de Log Insight. Puede descargar e instalar el contenido del paquete en Intercambio de soluciones de VMware. Solucionado en NSX 6.2.3.

    • Problema solucionado 1484506: Pantalla de diagnóstico de color púrpura durante la 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. Consulte el artículo 2137826 de la base de conocimientos de VMware. Solucionado en NSX 6.2.3.

    • Problema solucionado 1453802: Error al copiar la máquina virtual a través de vCloud Connector cuando la ruta pasa al equilibrador de carga de NSX. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1462006: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1482665: 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. Solucionado en NSX 6.1.5 y NSX 6.2.1.

    • Problema solucionado 1326669: 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. Solucionado en NSX 6.2.0.

    • Problema solucionado 1497044: 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. Solucionado en NSX 6.2.0.

    Historial de revisión del documento

    20 de agosto de 2015: Primera edición de NSX 6.2.0.
    17 de diciembre de 2015: Primera edición de NSX 6.2.1.
    4 de marzo de 2016: Primera edición de NSX 6.2.2. Aplicación de revisión de seguridad para solucionar la vulnerabilidad de glibc.
    9 de junio de 2016: Primera edición de NSX 6.2.3.
    25 de agosto de 2016: Primera edición de NSX 6.2.4.
    2 de septiembre de 2016: Segunda edición de NSX 6.2.4. Se agregaron problemas conocidos.
    9 de septiembre de 2016: Tercera edición de NSX 6.2.4. Se agregaron problemas conocidos.
    23 de septiembre de 2016: Cuarta edición para NSX 6.2.4. Se resolvieron 2 problemas conocidos.
    6 de octubre de 2016: Quinta edición de NSX 6.2.4. Se agregaron problemas conocidos.
    16 de noviembre de 2016: Sexta edición de NSX 6.2.4. KB añadidos.
    28 de noviembre de 2016: Sexta edición de NSX 6.2.4. Cambios correspondientes al error 1685894.
    5 de enero de 2017: Primera edición de NSX 6.2.5.
    10 de enero de 2017: Segunda edición de NSX 6.2.5. Se agregaron problemas resueltos.
    21 de febrero de 2017: Tercera edición de NSX 6.2.5. Se agregó el problema conocido 1777792.
    14 de abril de 2017: Cuarta edición para NSX 6.2.5. Se agregó el problema conocido 1833934.
    20 de abril de 2017: Quinta edición de NSX 6.2.5. Se agregaron los problemas resueltos 1663902 y 1717370.
    14 de junio de 2017: Sexta edición de NSX 6.2.5. Se agregó el problema resuelto 1770797.
    21 de agosto de 2017: Séptima edición de NSX 6.2.5. Se agregó el problema resuelto 1685894.