VMware NSX Data Center for vSphere 6.4.6 | Publicado el 10 de octubre de 2019 | Compilación 14819921

Consulte el Historial de revisión de este documento.

Contenido de las notas de la versión

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

Novedades
Instalación, versiones y requisitos del sistema
Funciones obsoletas y suspendidas
Notas sobre la actualización
Cumplimiento de FIPS
Historial de revisión
Problemas resueltos
Problemas conocidos

Novedades de NSX Data Center for vSphere 6.4.6

Importante: NSX for vSphere ahora se denomina NSX Data Center for vSphere.

NSX Data Center for vSphere 6.4.6 agrega mejoras de mantenimiento y de uso, y soluciona una serie de errores específicos de los clientes. Consulte la sección Problemas resueltos para obtener más información.

Cambios introducidos con NSX Data Center for vSphere 6.4.6:

VMware NSX: actualizaciones de funciones para vSphere Client (HTML): Las siguientes funciones de VMware NSX ya están disponibles a través de vSphere Client: Servicios Edge (Firewall de Edge, VPN de Capa 2, VPN de IPSEC y Configuraciones de NSX). Para ver la lista de funciones compatibles, consulte Funciones del complemento de IU VMware NSX for vSphere en vSphere Client.
El rol de auditor de NSX Manager ahora tiene privilegios para recopilar paquetes de registro de soporte de NSX Edge mediante Skyline Log Assist. Con esta mejora de permisos, un usuario con una función de auditor puede descargar el paquete de registro de soporte de los nodos de Edge y NSX Manager sin restricciones. Puede consultar una lista completa de funciones y permisos en la Guía de administración de NSX.

Versiones, requisitos del sistema e instalación

Nota:

En la siguiente tabla, se muestran las versiones recomendadas del software de VMware. Estas recomendaciones son generales y no deben sustituir ni anular las recomendaciones específicas del entorno. Esta información está actualizada según la fecha de publicación de este documento.
Consulte la matriz de interoperabilidad de productos VMware para conocer las versiones mínimas admitidas de NSX y de otros productos de VMware. VMware determina las versiones mínimas admitidas basándose en pruebas internas.

Producto o componente	Versión
NSX Data Center for vSphere	VMware recomienda la versión más reciente de NSX para nuevas implementaciones. Al actualizar las implementaciones existentes, revise las notas de la versión de NSX Data Center for vSphere o póngase en contacto con su representante del soporte técnico de VMware para obtener más información sobre problemas específicos antes de planificar una actualización.
vSphere	Para vSphere 6.0: Versión recomendada: 6.0 Update 3 vSphere 6.0 Update 3 resuelve el problema de VTEP duplicados en los hosts ESXi después de reiniciar vCenter Server. Consulte el artículo 2144605 de la base de conocimientos de VMware para obtener más información. Para vSphere 6.5: Versión recomendada: 6.5 Update 3 Nota: vSphere 6.5 Update 1 soluciona el error OutOfMemory de EAM. Consulte el artículo 2135378 de la base de conocimientos de VMware para obtener más información. Importante: Si utiliza el enrutamiento multidifusión en vSphere 6.5, se recomienda vSphere 6.5 Update 2 o una versión posterior. Si utiliza NSX Guest Introspection en vSphere 6.5, se recomienda vSphere 6.5 P03 o una versión posterior. Para vSphere 6.7: Versión recomendada: 6.7 Update 2 Importante: Si utiliza NSX Guest Introspection en vSphere 6.7, consulte el artículo 57248 de la base de conocimientos antes de instalar NSX 6.4.6 y contacte con el servicio de soporte técnico de VMware para obtener más información. Nota: vSphere 5.5 no se admite en NSX 6.4.
Guest Introspection para Windows	Se recomienda actualizar VMware Tools a la versión 10.3.10 antes de actualizar NSX for vSphere.
Guest Introspection para Linux	Esta versión de NSX admite las siguientes versiones de Linux: RHEL 7 GA (64 bits) SLES 12 GA (64 bits) Ubuntu 14.04 LTS (64 bits)

Requisitos del sistema e instalación

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

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

Funciones obsoletas y suspendidas

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

Consulte la matriz del ciclo de vida de productos de VMware para obtener información sobre NSX y otros productos de VMware que deben actualizarse próximamente.

NSX for vSphere 6.1.x llegó a las etapas de fin de disponibilidad (End of Availability, EOA) y de fin de soporte técnico general (End of General Support, EOGS) el 15 de enero de 2017. (Consulte también el artículo 2144769 de la base de conocimientos de VMware).
vCNS Edge ya no es compatible. Debe actualizar a una instancia de NSX Edge antes de actualizar a NSX 6.3 o versiones posteriores.
NSX for vSphere 6.2.x llegó al fin de soporte técnico general (End of General Support, EOGS) el 20 de agosto de 2018.
De acuerdo a las recomendaciones de seguridad, ya no se admite 3DES como algoritmo de cifrado en el servicio VPN IPsec de NSX Edge.
Se recomienda que cambie a uno de los cifrados seguros disponibles en el servicio IPsec. Este cambio en el algoritmo de cifrado es aplicable a la asociación de seguridad de IKE (fase 1), así como a la negociación de la asociación de seguridad de IKE (fase 2) para un sitio de IPsec.

Si el servicio IPsec de NSX Edge utiliza el algoritmo de cifrado 3DES en el momento de la actualización a una versión que no admita este tipo de cifrado, se reemplazará por otro recomendado, por lo que los sitios de IPsec que utilizaban 3DES no aparecerán, a menos que la configuración en el par remoto se modifique para que coincida con el algoritmo de cifrado utilizado en NSX Edge.

Si utiliza un cifrado 3DES, modifique el algoritmo de cifrado en la configuración del sitio de IPsec para reemplazar 3DES por una de las variantes AES admitidas (AES, AES256 y AES-GCM). Por ejemplo, para cada configuración de sitios de IPsec con el algoritmo de cifrado 3DES, reemplácelo por AES. Actualice también la configuración de IPsec en el endpoint par.

Cambios en el comportamiento general

Si cuenta con más de un vSphere Distributed Switch y si VXLAN está configurado en uno de ellos, debe conectar las interfaces del enrutador lógico distribuido a los grupos de puerto de ese vSphere Distributed Switch. A partir de NSX 6.4.1, esta configuración se aplica en la interfaz de usuario y la API. En versiones anteriores, no se evitaba la creación de una configuración no válida. Si actualiza a NSX 6.4.1 o una versión posterior y tiene interfaces DLR conectadas de forma incorrecta, tendrá que solucionar esta situación. Consulte las Notas sobre la actualización para obtener más información.

Cambios y eliminaciones en la interfaz de usuario

En NSX 6.4.1, se elimina Service Composer Canvas.

Cambios en el comportamiento de la instalación

A partir de la versión 6.4.2, cuando instala NSX Data Center for vSphere en hosts que cuentan con NIC físicas con controladores ixgbe, el Ajuste de escala en lado de recepción (RSS) está deshabilitado en los controladores ixgbe de forma predeterminada. Debe habilitar RSS de forma manual en los hosts antes de instalar NSX Data Center. Asegúrese de habilitar RSS solo en los hosts que tengan NIC con controladores ixgbe. Para obtener instrucciones detalladas sobre cómo habilitar RSS, consulte el artículo de la base de conocimientos de VMware https://kb.vmware.com/s/article/2034676. Este artículo de la base de conocimientos describe la configuración recomendada de RSS para mejorar el rendimiento del paquete de VXLAN.

Este nuevo comportamiento solo se aplica cuando realiza una instalación nueva de los módulos kernel (archivos VIB) en los hosts ESXi. No se requiere ningún cambio cuando actualiza a 6.4.2 los hosts administrados por NSX.

Eliminaciones de la API y cambios del comportamiento

Desusos en NSX 6.4.2

Ya no se utiliza el siguiente elemento y es posible que se elimine en una versión futura:

GET/POST/DELETE /api/2.0/vdn/controller/{controllerId}/syslog. En su lugar, utilice GET/PUT /api/2.0/vdn/controller/cluster/syslog.

Cambios de comportamiento de NSX 6.4.1

Cuando crea un nuevo grupo de IP con POST /api/2.0/services/ipam/pools/scope/globalroot-0 o modifica un grupo existente de IP con PUT /api/2.0/services/ipam/pools/, y el grupo tiene varios rangos de IP definidos, se realiza la validación para garantizar que los rangos no se superponen. Esta validación no se realizaba previamente.

Desusos en NSX 6.4.0
Ya no se utilizan los siguientes elementos y es posible que se eliminen en una versión futura.

El parámetro systemStatus de GET /api/4.0/edges/edgeID/status está obsoleto.
GET /api/2.0/services/policy/serviceprovider/firewall/ está obsoleta. En su lugar, utilice GET /api/2.0/services/policy/serviceprovider/firewall/info.
La opción tcpStrict de la sección de configuración global del firewall distribuido está obsoleta. A partir de NSX 6.4.0, tcpStrict se define en el nivel de la sección. Nota: Si actualiza a NSX 6.4.0 o una versión posterior, la opción de la configuración global para tcpStrict se usa para configurar tcpStrict en cada sección de Capa 3. tcpStrict se establece como falso (false) en las secciones de la Capa 2 y las secciones redireccionadas de la Capa 3. Consulte cómo trabajar con la configuración del firewall distribuido en la Guía de NSX API Guide para obtener más información.

Cambios de comportamiento de NSX 6.4.0
En NSX 6.4.0, el parámetro <name> es necesario cuando crea un controlador con POST /api/2.0/vdn/controller.

NSX 6.4.0 introduce estos cambios en el control de errores:

Antes, POST /api/2.0/vdn/controller respondía con 201 creado (201 Created) para indicar que se creó el trabajo de creación del controlador. Sin embargo, la creación del controlador puede fallar. A partir de NSX 6.4.0, la respuesta es 202 aceptado (202 Accepted).
Antes, si enviaba una solicitud de API que no se permitía en modo de tránsito o independiente, el estado de la respuesta era 400 solicitud incorrecta (400 Bad Request). A partir de NSX 6.4.0 la respuesta es 403 prohibido (403 Forbidden).

Cambios de comportamiento y eliminaciones de la CLI

No utilice comandos no admitidos en nodos de NSX Controller
Existen comandos sin documentar para configurar NTP y DNS en los nodos de NSX Controller. Estos comandos no son compatibles y no deben utilizarse en nodos de NSX Controller. Debe utilizar solo los comandos que aparecen documentados en la guía de la CLI de NSX.

Notas sobre la actualización

Notas generales sobre la actualización
Notas sobre la actualización de los componentes de NSX
Notas sobre la actualización de FIPS

Nota: Para obtener una lista de problemas conocidos que afectan a la instalación y las actualizaciones, consulte Problemas conocidos de instalación y actualización.

Notas generales sobre la actualización

Para actualizar NSX, debe realizar una actualización completa de NSX, incluido el clúster del host (que actualiza los VIB del host). 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.
No se admite actualizar los VIB de NSX en los clústeres de hosts con VUM. Puede usar el coordinador de la actualización, la preparación del host o las REST API asociadas para actualizar los VIB de NSX en los clústeres de hosts.
Requisitos del sistema: Si desea obtener información sobre los requisitos del sistema para la instalación y actualización de NSX, consulte la sección Requisitos del sistema para NSX de la documentación de NSX.
Ruta de actualización de NSX: 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.
Las versiones anteriores no son compatibles:
- Realice siempre una copia de seguridad de NSX Manager antes de realizar una actualización.
- Una vez que NSX se actualice correctamente, no podrá volver a utilizar una versión anterior.
Para validar que su actualización a NSX 6.4.x se realizó correctamente, consulte el artículo de la base de conocimientos 2134525.
No existe compatibilidad para las actualizaciones de vCloud Networking and Security con NSX 6.4.x. En primer lugar, debe actualizar a una versión compatible con la versión 6.2.x.
Interoperabilidad: Consulte la sección Matriz de interoperabilidad de productos de VMware para obtener información sobre todos los productos de VMware relevantes antes de actualizar.
- Actualización a NSX Data Center for vSphere 6.4: NSX 6.4 no es compatible con vSphere 5.5.
- Actualización a NSX Data Center for vSphere 6.4.5: Si NSX se implementa con VMware Integrated OpenStack (VIO), actualice VIO a la versión 4.1.2.2 o 5.1.0.1, ya que la 6.4.5 no es compatible con las versiones anteriores debido a la actualización del paquete de Spring a la versión 5.0.
- Actualizar a vSphere 6.5: Al actualizar a vSphere 6.5a o a una versión posterior, debe actualizar primero a NSX 6.3.0 o una versión posterior. NSX 6.2.x no es compatible con vSphere 6.5. Consulte cómo actualizar vSphere en un entorno de NSX en la Guía de actualización de NSX.
- Actualizar a vSphere 6.7: Al actualizar a vSphere 6.7, debe actualizar primero a NSX 6.4.1 o una versión posterior. Las versiones anteriores de NSX no son compatibles con vSphere 6.7. Consulte cómo actualizar vSphere en un entorno de NSX en la Guía de actualización de NSX.
Compatibilidad con servicios de partner: Si su sitio web utiliza servicios de partners de VMware para Guest Introspection o para Network Introspection, consulte la Guía de compatibilidad de VMware antes de realizar la actualización para comprobar que el servicio del proveedor sea compatible con esta versión de NSX.
Complemento de Redes y seguridad: Después de actualizar NSX Manager, debe cerrar sesión y volver a iniciarla en vSphere Web Client. Si el complemento de NSX no se muestra correctamente, borre el historial y la memoria caché del explorador. Si el complemento de Redes y seguridad no aparece en vSphere Web Client, restablezca el servidor de vSphere Web Client como se explica en la Guía de actualización de NSX.
Entornos sin estado: 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:
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:
1. Busque la URL nueva de VIB en https://<nsxmanager>/bin/vdn/nwfabric.properties.
2. Obtenga los VIB de la versión de host ESX requerida desde la URL correspondiente.
3. Agréguelos al perfil de imagen del host.

Notas sobre la actualización de los componentes de NSX

Soporte para la versión 11 del hardware de máquina virtual para los componentes de NSX

En las nuevas instalaciones de NSX Data Center for vSphere 6.4.2, los componentes de NSX (Manager, Controller, Edge y Guest Introspection) tienen la versión 11 del hardware de máquina virtual.
En las actualizaciones a NSX Data Center for vSphere 6.4.2, los componentes NSX Edge y Guest Introspection se actualizan automáticamente a la versión 11 del hardware de máquina virtual. Los componentes NSX Manager y NSX Controller siguen con la versión 8 del hardware de la máquina virtual tras actualizar. Los usuarios tienen la opción de actualizar el hardware de máquina virtual a la versión 11. Consulte la base de conocimientos (https://kb.vmware.com/s/article/1010675) para obtener instrucciones sobre cómo actualizar las versiones del hardware de máquina virtual.
En las nuevas instalaciones de NSX 6.3.x, 6.4.0, 6.4.1, los componentes de NSX (Manager, Controller, Edge y Guest Introspection) tienen la versión 8 del hardware de máquina virtual.

Actualización de NSX Manager

Importante: Si actualiza NSX 6.2.0, 6.2.1 o 6.2.2 a NSX 6.3.5 o una versión posterior, deberá completar una solución alternativa antes de iniciar la actualización. Consulte el artículo 000051624 de la base de conocimientos de VMware para obtener más detalles.
Si actualiza de NSX 6.3.3 a NSX 6.3.4 o a una versión posterior, primero debe seguir las instrucciones de solución alternativa del artículo 2151719 de la base de conocimientos de VMware.
Si utiliza SFTP para realizar copias de seguridad de NSX, cambie a hmac-sha2-256 después de actualizar a 6.3.0 o una versión posterior, porque no se admite hmac-sha1. Consulte el artículo 2149282 de la base de conocimientos de VMware para obtener una lista de los algoritmos de seguridad compatibles.
cuando actualiza NSX Manager a NSX 6.4.1, se realiza una copia de seguridad automáticamente y se guarda de forma local como parte del proceso de actualización. Para obtener más información, consulte Actualizar NSX Manager.
Al actualizar a NSX 6.4.0, se mantiene la configuración de TLS. Si solo está habilitado TLS 1.0, podrá ver el complemento de NSX en vSphere Web Client, pero no se verán las instancias de NSX Manager. La ruta de datos no se ve afectada, pero no puede cambiar ninguna configuración de NSX Manager. Inicie sesión en la IU de la web de administración del dispositivo de NSX en https://nsx-mgr-ip/ y habilite TLS 1.1 y TLS 1.2. De esta forma se reinicia el dispositivo de NSX Manager.

Actualización de Controller

El clúster de NSX Controller debe contener tres nodos de controlador. Si tiene menos de tres controladores, debe agregarlos antes de iniciar la actualización. Para obtener instrucciones, consulte la sección Implementar clúster de NSX Controller.
En la versión 6.3.3 de NSX, el sistema operativo subyacente de NSX Controller cambia. Esto significa que, cuando se actualiza de NSX 6.3.2 o de una versión anterior a NSX 6.3.3 o una versión posterior, en vez de una actualización local de software, los controladores existentes se eliminan uno a uno y se implementan nuevos controladores basados en Photon OS mediante las mismas direcciones IP.

Cuando se eliminan los controladores, también se eliminan las reglas de antiafinidad de DRS asociadas. Debe crear nuevas reglas antiafinidad en vCenter para evitar que las nuevas máquinas virtuales de controlador residan en el mismo host.

Para obtener más información sobre actualizaciones de los controladores, consulte Actualizar el clúster de NSX Controller.

Actualización del clúster del host

Si actualiza de NSX 6.3.2 o una versión anterior a NSX 6.3.3 o versiones posteriores, los nombres de los VIB de NSX cambian.
Los VIB esx-vsip y esx-vxlan se sustituyen por esx-nsxv si tiene instalado NSX 6.3.3 o una versión posterior en ESXi 6.0 o una versión posterior.
Desinstalación y actualización sin reinicio en los hosts: A partir de vSphere 6.0 y versiones posteriores, una vez que actualizó de NSX 6.2.x a NSX 6.3.x o versiones posteriores, no será necesario reiniciar después de realizar cambios en el VIB de NSX. En su lugar, los hosts deben entrar en modo de mantenimiento para completar el cambio de VIB. Esto afecta tanto a la actualización del clúster del host de NSX como a la actualización de ESXi. Consulte la Guía de actualización de NSX para obtener más información.

Actualización de NSX Edge

Se agregó la validación a NSX 6.4.1 para no permitir configuraciones no válidas del enrutador lógico distribuido: En entornos en los que VXLAN esté configurado y aparezcan más de un vSphere Distributed Switch, las interfaces de los enrutadores lógicos distribuidos deben estar conectadas únicamente al vSphere Distributed Switch configurado para VXLAN. Se producirá un error al actualizar el DLR a NSX 6.4.1 o una versión posterior en entornos donde el DLR tenga interfaces conectadas al vSphere Distributed Switch que no esté configurado para VXLAN. Use la API para conectarse a las interfaces configuradas de forma incorrecta en el vSphere Distributed Switch configurado para VXLAN. Una vez que la configuración sea válida, vuelva a intentar actualizar. Puede cambiar la configuración de la interfaz con PUT /api/4.0/edges/{edgeId} o PUT /api/4.0/edges/{edgeId}/interfaces/{index}. Consulte la Guía de NSX API para obtener más información.

Elimine de vCenter Server la máquina virtual de control de UDLR asociada al NSX Manager secundario antes de actualizar UDLR de la versión 6.2.7 a la 6.4.5:
En un entorno de varios vCenter, al actualizar los UDLR de NSX de la versión 6.2.7 a la 6.4.5, se produce un error de actualización del dispositivo virtual de UDLR (máquina virtual de control de UDLR) en el NSX Manager secundario si HA está habilitado en la máquina virtual de control de UDLR. Durante la actualización, la máquina virtual con el índice #0 en el par HA se elimina de la base de datos de NSX; sin embargo, esta máquina virtual sigue existiendo en vCenter Server. Por lo tanto, cuando la máquina virtual de control de UDLR se actualiza en el NSX Manager secundario, se produce un error debido a que el nombre de la máquina virtual entra en conflicto con una máquina virtual existente en vCenter Server. Para solucionar este problema, elimine de vCenter Server la máquina virtual de control asociada con el UDLR en el NSX Manager secundario y, a continuación, actualice el UDLR de la versión 6.2.7 a la 6.4.5.
Los clústeres del host deben estar preparados para NSX antes de actualizar los dispositivos de NSX Edge: A partir de la versión 6.3.0, no se admite la comunicación en el plano de administración entre NSX Manager y Edge a través del canal VIX. Solo se admite el canal del bus de mensajería. Cuando actualiza de NSX 6.2.x o una versión anterior a NSX 6.3.0 o una versión posterior, debe verificar que los clústeres del host donde se implementan los dispositivos NSX Edge estén preparados para NSX y que el estado de la infraestructura de mensajería sea de color VERDE. Si los clústeres del host no están preparados para NSX, se producirá un error en la actualización del dispositivo de NSX Edge. Consulte Actualizar NSX Edge en la Guía de actualización de NSX para obtener más información.

Actualizar la puerta de enlace de servicios Edge (ESG):
A partir de la versión 6.2.5 de NSX, 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:

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

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.
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 anterior para ver los valores predeterminados).

Deshabilite la opción Iniciar máquina virtual (Virtual Machine Startup) de vSphere cuando vSphere HA está habilitado y los Edges están implementados. Tras actualizar NSX Edge 6.2.4 a la versión 6.2.5 u otras posteriores, debe desactivar la opción para iniciar la máquina virtual de vSphere en cada NSX Edge que se encuentre en un clúster en el que esté habilitado vSphere HA y en el que se hayan implementado Edges. Para ello, abra vSphere Web Client, busque el host ESXi donde se encuentra la máquina virtual de NSX Edge, haga clic en Administrar (Manage) > Configuración (Settings) y, en Máquinas virtuales (Virtual Machines), seleccione Inicio y apagado automático de la máquina virtual (VM Startup/Shutdown), haga clic en Editar (Edit) y asegúrese de que las máquinas virtuales estén en modo Manual (es decir, asegúrese de que no se añadiera a la lista de inicio/apagado automático).
Antes de actualizar a NSX 6.2.5 o una versión posterior, asegúrese de que todas las listas de cifrados del equilibrador de carga estén separadas por dos puntos. Si su lista de cifrados utiliza otro separador, como, por ejemplo, comas, realice una llamada PUT a https://nsxmgr_ip/api/4.0/edges/EdgeID/loadbalancer/config/applicationprofiles y sustituya cada lista <ciphers> </ciphers> de <clientssl> </clientssl> y <serverssl> </serverssl> por una lista separada por dos puntos. Por ejemplo, el segmento relevante del cuerpo de la solicitud puede tener la siguiente apariencia. Repita este procedimiento para todos los perfiles de la aplicación:
```
<applicationProfile>
  <name>https-profile</name>
  <insertXForwardedFor>false</insertXForwardedFor>
  <sslPassthrough>false</sslPassthrough>
  <template>HTTPS</template>
  <serverSslEnabled>true</serverSslEnabled>
  <clientSsl>
    <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
    <clientAuth>ignore</clientAuth>
    <serviceCertificate>certificate-4</serviceCertificate>
  </clientSsl>
  <serverSsl>
    <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
    <serviceCertificate>certificate-4</serviceCertificate>
  </serverSsl>
  ...
</applicationProfile>
```
Establezca la versión correcta del cifrado para los clientes del equilibrador de carga en versiones de vROPs anteriores a 6.2.0: los miembros del grupo vROPs de versiones anteriores a la 6.2.0 usan la versión 1.0 de TLS y, por lo tanto, debe establecer un valor de extensión de supervisión configurando explícitamente "ssl-version=10" en la configuración del equilibrador de carga de NSX. Consulte Crear un monitor de servicio en la Guía de administración de NSX para obtener instrucciones.
```
{
    "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"
}
```
Después de actualizar a NSX 6.4.6, las interfaces y los puentes de capa 2 de un DLR no se pueden conectar a conmutadores lógicos que pertenezcan a diferentes zonas de transporte: En NSX 6.4.5 o versiones anteriores, las interfaces y las instancias de puente de capa 2 de un enrutador lógico distribuido (DLR) admiten el uso de conmutadores lógicos que pertenecían a diferentes zonas de transporte. A partir de NSX 6.4.6, esta configuración no está admitida. Las interfaces y las instancias de puente de capa 2 en un DLR deben conectarse a conmutadores lógicos que se encuentren en una sola zona de transporte. Si se utilizan conmutadores lógicos de varias zonas de transporte, la actualización de Edge se bloqueará durante las comprobaciones de validación previas a la actualización cuando se actualice a NSX 6.4.6. Para resolver este problema de actualización de Edge, asegúrese de que las instancias de puente y las interfaces de un DLR estén conectadas a conmutadores lógicos en una misma zona de transporte.

Notas sobre la actualización de FIPS

Cuando actualice de una versión de NSX anterior a NSX 6.3.0 a esta versión o una versión posterior, no debe habilitar el modo FIPS antes de que se complete la actualización. Si habilita el modo FIPS antes de que se haya completado la actualización, la comunicación entre los componentes actualizados y no actualizados se interrumpirá. Consulte la descripción del modo FIPS y la actualización de NSX en la Guía de actualización de NSX para obtener más información.

Cifrados admitidos en OS X Yosemite y OS X El Capitan: Si usa el cliente de VPN de SSL en OS X 10.11 (El Capitan), podrá conectarse usando los cifrados AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA38, AES256-SHA y AES128-SHA. Por su parte, aquellos que usen OS X 10.10 (Yosemite) podrán conectarse usando únicamente los cifrados AES256-SHA y AES128-SHA.
No habilite FIPS antes de que se complete la actualización a NSX 6.3.x. Consulte la descripción del modo FIPS y la actualización de NSX en la Guía de actualización de NSX para obtener más información.
Antes de habilitar FIPS, compruebe que todas las soluciones para partners tengan el certificado del modo FIPS. Consulte la Guía de compatibilidad de VMware y la documentación relevante del partner.

Cumplimiento de FIPS

Si se ha configurado correctamente, NSX 6.4 utilizará módulos criptográficos validados mediante FIPS 140-2 para toda la criptografía relacionada con la seguridad.

Nota:

Controller y VPN de agrupación en clústeres: NSX Controller utiliza IPsec VPN para conectarse a los clústeres de Controller. La VPN IPsec utiliza el módulo criptográfico del kernel de Linux para VMware (entorno VMware Photon OS 1.0), que está en proceso de validación mediante CMVP.
VPN IPsec de Edge: La VPN IPsec de NSX Edge utiliza el módulo criptográfico del kernel de Linux para VMware (entorno VMware NSX OS 4.4), que está en proceso de validación mediante CMVP.

Historial de revisión del documento

10 de octubre de 2019: Primera edición.
6 de noviembre de 2019. Segunda edición. Se agregó el problema conocido 2442884 y la nota de actualización relacionada.
3 de diciembre de 2019. Tercera edición. Se agregó un vínculo a una solución alternativa al problema conocido 2367906.
9 de enero de 2020. Cuarta edición. Se agregó el problema conocido 2449643.
18 de mayo de 2020. Quinta edición. Se agregaron los problemas conocidos 2444275, 2445183, 2445396, 2448235, 2448449, 2451586, 2452833, 2458746, 2459936, 2493095, 2498988, 2502739, 2509224, 2513773, 2536058 y 2551523.
25 mayo 2020. Sexta edición. Se agregó una nota de actualización de Edge para el problema solucionado 2379274.

Problemas resueltos

Problema solucionado 1648578: NSX obliga a 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.
Problema solucionado 2001988: Durante la actualización del clúster de hosts de NSX, el estado de Instalación (Installation) en la pestaña Preparación del host (Host Preparation) alterna entre "no está listo" ("not ready") e "instalando" ("installing") para todo el clúster cuando se está actualizando cada uno de los hosts del clúster.
Durante la actualización de NSX, al hacer clic en "actualización disponible" ("upgrade available") para el clúster preparado de NSX, se activa la actualización del host. Para los clústeres configurados con la opción DRS AUTOMÁTICO COMPLETO (DRS FULL AUTOMATIC), el estado de instalación alterna entre "instalando" ("instaling") y "no está listo" ("not ready"), aunque los hosts se actualicen en segundo plano sin problemas.
Problema solucionado 2005973: El MSR de daemon de enrutamiento pierde la configuración de enrutamiento completa tras eliminar algunos túneles GRE y posteriormente mediante una sincronización forzada del nodo de Edge desde el plano de administración.
Este problema puede producirse en una instancia de Edge con sesiones BGP mediante túneles GRE. Cuando se eliminan algunos de los túneles GRE y, a continuación, se realiza una sincronización forzada de la instancia de Edge desde el plano de administración, Edge pierde la configuración de enrutamiento completa.
Problema solucionado 2005900: El MSR de daemon de enrutamiento en Edge se bloquea al 100 % de CPU cuando todos los túneles GRE oscilan en una topología de escala ECMP de BGP con iBGP/multisalto de ocho vías.
Este problema puede suceder en una topología de escala en la que iBGP o BGP con multisalto se configura en ESG con varios vecinos que se ejecutan en varios túneles GRE. Cuando varios túneles GRE oscilan, MSR puede bloquearse de forma indefinida al 100 % de CPU.
Problema solucionado 2118255: La máquina virtual de control de DLR no participa en el enrutamiento de multidifusión.
La máquina virtual de control de DLR no participa en el enrutamiento multidifusión; la CLI relacionada con la multidifusión mostrará una pantalla vacía en la máquina virtual de control.
Problema solucionado 2189417: El número de registros de eventos excede el límite permitido.
Si los eventos están a escala, se pierden algunos registros, lo que provoca la pérdida de la funcionalidad de IDFW (solo para cargas de trabajo físicas).
Problema solucionado 2312793: El valor de etag en el encabezado HTTP está rodeado por comillas dobles.
Se producirá un error en la REST API si se usa el valor de etag en la respuesta.
Problema solucionado 2279045: Bloqueo al configurar la latencia de extremo a extremo cuando vNIC se conecta al dvPortgroup respaldado por VLAN.
La latencia de extremo a extremo no admite el dvPortgroup respaldado por VLAN. Cuando se establece la configuración de latencia en este grupo de puertos, se mostrará una excepción. Solo se puede utilizar el dvPortgroup respaldado por superposición.
Problema solucionado 2265909: Ya no se admite el uso de la barra diagonal doble en el URI de la REST API.
Las llamadas de la REST API generan el ERROR 500: Error interno del servidor (Internal Server Error). Se producirá un error en las REST API si el URI contiene una barra diagonal doble.
Problema solucionado 2319867: La latencia de extremo a extremo no se configura automáticamente en el nuevo host después de agregar un nuevo host al VDS con la latencia de extremo a extremo habilitada.
Cuando la latencia de extremo a extremo ya está configurada en un VDS y se agrega un nuevo host, la latencia de extremo a extremo no se configura automáticamente en el nuevo host. No se puede supervisar la latencia en este host.
Problema solucionado 2442884: NSX-v 6.4.6 no es compatible con VMware Integrated OpenStack.
A partir de NSX 6.4.6 no se pueden crear reglas de firewall con una IP de destino del tipo 0.0.0.0/0. Esto provoca una incompatibilidad entre NSX 6.4.6 y todas las versiones de vSphere Integrated OpenStack. Consulte más información en la sección Matriz de interoperabilidad de productos de VMware.
Problema solucionado 2331068: NSX Edge no se puede administrar porque hay demasiados mensajes de actualización de objetos de agrupamiento del firewall.
NSX Edge no se puede administrar; sin embargo, el plano de datos funciona correctamente. Los administradores no pueden realizar cambios de configuración ni consultar el estado de Edge.
Problema solucionado 2320171: La reserva de recursos del dispositivo de Edge se restablece al valor "Sin reserva" cuando el dispositivo de Edge se mueve a otro clúster o grupo de recursos.
Después de mover el dispositivo de Edge a otro clúster o grupo de recursos, los administradores deben restablecer manualmente la reserva del dispositivo de Edge mediante la ejecución de una solicitud de API.
Problema solucionado 2349110: La función Guardar contraseña no funciona en el cliente SSL VPN-Plus en equipos Mac.
Los usuarios de SSL VPN deben volver a introducir el nombre de usuario y la contraseña para iniciar sesión en el servidor SSL VPN cada vez, incluso cuando se selecciona la opción "Guardar contraseña".
Problema solucionado 2360114: En un entorno Cross-vCenter NSX de varios sitios, no está disponible la página de redistribución de rutas de una instancia de Edge administrada por una instancia secundaria de NSX Manager.
Este problema solo existía en vSphere Client basado en HTML5. vSphere Web Client no tenía este problema.
Problema solucionado 2337437: Bloqueo del kernel de la CPU durante un tiempo prolongado.
La CPU no recibe latido durante N segundos y se produce una reducción del rendimiento.
Problema solucionado 2305079: El firewall de identidad de NSX funciona de forma intermitente. El motor de contexto de NSX no se ejecuta en un host ESXi.
Al usar NSX Guest Introspection para detectar eventos de red, el firewall de identidad de NSX funciona de forma intermitente. Cuando el motor de contexto de NSX se ejecuta en un host ESXi, el firewall de identidad funciona según lo previsto. Sin embargo, cuando el motor de contexto no se está ejecutando, el firewall de identidad no funciona.
Problema solucionado 2375249: Las reglas de firewall no pueden publicarse cuando existen espacios adicionales en los campos Dirección IP de origen y Dirección IP de destino.
El archivo de registro vsfwd muestra una configuración de firewall no válida mediante la función "string2ip".
Problema solucionado 2305989: Se produce una pérdida de memoria en el proceso dcsms cuando se ejecutan los comandos de la CLI "show ip bgp" y "show ip bgp neighbors".
El proceso dcsms (multidifusión móvil segura de clústeres dinámicos) alcanza un uso de memoria muy alto, lo que afecta al procesamiento normal. Edge se queda con memoria insuficiente y hace que la instancia de Edge se vuelva a cargar.
Problema solucionado 2379274: Cuando las interfaces o los puentes de un DLR están conectados a conmutadores lógicos que se encuentran en diferentes zonas de transporte, faltan instancias de VDR en algunos hosts.
Las máquinas virtuales no pueden acceder a su puerta de enlace predeterminada y el tráfico de la ruta de datos no está activo.
Problema solucionado 2291285: Cuando se configura un puente en una interfaz de un DLR que ya tiene configurada la multidifusión, esa interfaz no se elimina de las interfaces de multidifusión configuradas.
En la interfaz de usuario de vCenter, la interfaz del DLR configurado para IGMP de multidifusión y de puente como origen aparece como desconectada.
Problema solucionado 2377057: La publicación de reglas de firewall distribuido provoca interrupciones de NSX Manager debido al uso intensivo de la CPU.
El uso elevado de la CPU en NSX Manager afecta el rendimiento.
Problema solucionado 2391802: Las máquinas virtuales desaparecen de la lista de exclusión de NSX cuando se agregan nuevas máquinas virtuales.
Si agrega una nueva máquina virtual antes de que las máquinas virtuales de la lista de exclusión se carguen en la interfaz de usuario, dichas máquinas virtuales se eliminarán.
Problema solucionado 2389897: Conflicto de configuración entre log4j y log4j2 debido al uso de log4j por parte de bibliotecas de terceros.
Faltan los registros generados por NSX en vsm.log. La ausencia de registros de NSX aumenta la dificultad de los problemas de depuración.
Problema solucionado 2273837: Las reglas de firewall que utilizan conjuntos de direcciones IP, aplicaciones o grupos de aplicaciones con un ámbito de centro de datos no están visibles cuando se actualiza a NSX 6.4.0 o versiones posteriores.
Se muestra el siguiente mensaje de error en los registros de NSX cuando las reglas de firewall utilizan un conjunto de direcciones IP, una aplicación o un grupo de aplicaciones con el ámbito "centro de datos" en NSX 6.4.0 y versiones posteriores:
[Firewall] ObjectId de agrupación no válido. Este objeto no existe o no está disponible.
Problema solucionado 2319561: Errores de sincronización en la instancia principal de NSX Manager.
Se muestra el siguiente mensaje de error en la interfaz de usuario y en los registros de NSX:
Error en REST API: El formato de uuid de instance_uuid no es válido.
Problema solucionado 2327330: TLS 1.1 está habilitado en el puerto 5671 de RabbitMQ.
Se admiten las versiones anteriores de TLS 1.1. Los usuarios pueden quitar TLS 1.1 de forma explícita si no lo necesitan.
Para quitar TLS 1.1, edite el archivo rabbitmq.config en /etc/rabbitmq/ y reinicie el agente en el administrador.
Problema solucionado 2341214: Se implementa un dispositivo de Edge con HA habilitado y que cumple todos los criterios para la habilitación de la HA. Sin embargo, HA permanece deshabilitado en la instancia de Edge hasta que se publica un segundo cambio de configuración en el dispositivo de Edge.
Cuando se crea una instancia de Edge (ESG/DLR/UDLR) con HA habilitado y se implementan dispositivos (configuración masiva con otras funciones configuradas), la configuración se publica en los dispositivos de Edge con HA deshabilitado. El plano de administración muestra HA como habilitado, pero en realidad HA está deshabilitado en los dispositivos de Edge.
Problema solucionado 2392371: El dispositivo virtual de Edge no se reinicia cuando no se está ejecutando VMware Tools en el dispositivo de Edge.
Es posible que se produzca un error al reiniciar el dispositivo de Edge en algunos escenarios. Por ejemplo, cuando se está habilitando o deshabilitando FIPS o cuando se intenta ejecutar ForceSync en la instancia de Edge que informa de un estado incorrecto del sistema.
Problema solucionado 2273242: Al recibir un paquete SYN en una sesión establecida, los filtros con NetX no envían ACK en esa conexión.
Con NetX habilitado, el paquete SYN se reenvía a la instancia de servicio en una sesión establecida. Es posible que las sesiones de TCP se bloqueen.
Problema solucionado 2285624: proxy_set no puede ejecutarse desde Linux.
El cliente sslvpn de Linux no admitía el proxy.
Problema solucionado 2287017: ESX puede mostrar PSOD con tormentas de ARP a destinos desconocidos.
Con tormentas de ARP a destinos desconocidos, ESX muestra PSOD mientras se replican los ARP de difusión en varias máquinas virtuales de la red.
Problema solucionado 2287578: La recopilación de estadísticas de reglas provoca que se ralentice la ruta de datos del firewall distribuido (DFW).
Cuando se produce una recopilación de estadísticas de reglas o publicación de reglas, una máquina virtual protegida por DFW puede experimentar una reducción de su rendimiento de la red de máquinas virtuales.
Problema solucionado 2315879: Varios sitios de IPSec con el mismo endpoint local, un endpoint del mismo nivel o una subred del mismo nivel, pero con diferentes subredes locales, hacen que Edge no enrute el tráfico.
Hay rutas que faltan o no están instaladas. Edge no enruta el tráfico.
Problema solucionado 2329851: Se produce un error de servidor interno de la página en la autenticación del SecurID de RSA con RADIUS para SSLVPN Plus Client.
Después de iniciar sesión en el portal de sslvpn, aparece un error indicando que no se encontró la página. Error de RSA con el servidor RADIUS.
Problema solucionado 2331796: El valor de "Tiempo de inactividad de HA" no está establecido en la configuración de HA aunque se haya especificado el valor durante la implementación de una instancia de Edge independiente.
Después de implementar la instancia de Edge independiente, la configuración de HA muestra de forma incorrecta el valor de "Tiempo de inactividad de HA" en el campo "Intervalo de latidos de HA". Los usuarios tampoco pueden reconfigurar el valor de "Tiempo de inactividad de HA" mediante la CLI. En su lugar, se establece el valor de "Intervalo de latidos de HA".
Problema solucionado 2332763: Se produce un error al actualizar la instancia de Edge a NSX 6.4.2 o una versión posterior cuando se configura la propiedad de control del sistema "sysctl.net.ipv4.tcp_tw_recycle".
Se produce un error al publicar el dispositivo de Edge con el siguiente mensaje de error:
ERROR :: VseCommandHandler :: El comando falló en ese momento. Error: [C_UTILS][73001][65280] sysctl net.ipv4.tcp_tw_recycle="0" failed : sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle: No existe dicho archivo o directorio.
Problema solucionado 2342497: Los VTEP no pueden funcionar correctamente cuando se utiliza la directiva de formación de equipos de hash de IP.
Los VTEP de NSX no se pueden comunicar entre sí.
Problema solucionado 2350465: La instancia de Edge experimenta una pérdida de paquetes y se reinicia debido a la falta de memoria.
No hay memoria suficiente en situaciones de tráfico alto y cuando IPSec está habilitado.
Problema solucionado 2351224: El cliente SSL VPN-Plus se instaló correctamente en una máquina Linux, pero el cliente no funciona.
Falta el paquete de net-tools en la máquina Linux.
Problema solucionado 2367084: En un puente, no se puede acceder a las máquinas virtuales superpuestas desde máquinas virtuales respaldadas por VLAN.
Cuando las máquinas virtuales de control de DLR y las máquinas virtuales superpuestas residen en el mismo host ESXi, las máquinas virtuales en las redes VLAN no pueden resolver las solicitudes de ARP de las máquinas virtuales en las redes superpuestas.
Problema solucionado: SynFloodProtection hace que se ignoren las reglas de firewall.
Cuando SynFloodProtection está habilitado en NSX Edge, se omite la comprobación de reglas de firewall si el tráfico tiene como destino la instancia de Edge.
Problema solucionado 2381632: No se pueden agregar rutas estáticas en un DLR que no tenga implementada ninguna máquina virtual de dispositivo de Edge.
vSphere Web Client muestra un valor en "Distancia administrativa" para un DLR que no tiene implementada ninguna máquina virtual de dispositivo de Edge.
Problema solucionado 2385541: NSX Edge se ejecuta en un estado de cerebro dividido cuando se envía una marca ForceStandby vacía a la máquina virtual incorrecta.
Cuando se intenta ForceSync y se reinician las máquinas virtuales, se envía una marca ForceStandby vacía a la máquina virtual incorrecta. Su par tiene ForceStandby establecido.
Se produce un error al borrar la marca ForceStandby, lo que provoca que se invoque la tarea ForceSync. Las máquinas virtuales se reinician como parte de la operación de ForceSync, ya que la instancia de Edge informa de un estado incorrecto del sistema.
Problema solucionado 2385739: Interbloqueo en NSX Manager.
Zookeeper emite errores y eso hace que NSX Manager no responda. El replicador elimina y vuelve a crear los controladores de NSX en la instancia secundaria de NSX Manager. El interbloqueo se produce en el paso final.
Problema solucionado 2387720: Los paquetes de conformidad "Suite-B-GMAC-128" y "Suite-B-GMAC-256" de la configuración de VPN de IPSec no proporcionan cifrado de datos.
Estos conjuntos usan cifrado nulo, que no es seguro. A partir de NSX 6.4.6, estos dos conjuntos de cumplimiento quedan obsoletos.
Problema solucionado 2390308: En la implementación de una instancia de Edge con FIPS habilitado, se requiere reiniciar después del primer arranque. Sin embargo, a veces se produce un error en la operación de reinicio.
Se muestra el siguiente mensaje de error en los registros de NSX:
No se puede completar la operación porque VMware Tools no se está ejecutando en esta máquina virtual.
Problema solucionado 2406853: Al agregar una interfaz troncal en una instancia de Edge, el tamaño de MTU predeterminado se configura incorrectamente con el valor 1500 en la interfaz de usuario.
El tráfico del plano de datos que pasa por la interfaz de Edge se ve afectado debido al reducido tamaño predeterminado de la MTU.
Hay entradas obsoletas en las tablas de enrutamiento de DLR en las siguientes situaciones: dvportgroup se utiliza en las interfaces lógicas de DLR, el puente se elimina de vCenter, el conmutador distribuido virtual se migra o se elimina.
Se produce un error al actualizar DLR. Se produce un error en la reimplementación de Edge cuando hay una actualización de Edge disponible. Las actualizaciones de la configuración de Edge podrían fallar.
Problema solucionado 2412632: No se puede guardar un perfil de aplicación del equilibrador de carga de tipo "HTTPS de extremo a extremo" sin seleccionar un certificado de servicio en la configuración de SSL del servidor.
Este problema se produce después de actualizar NSX Edge de la versión 6.4.4 a la 6.4.5. En NSX 6.4.5, se hizo obligatorio seleccionar un certificado de servicio al especificar la configuración de SSL del servidor.
Problema solucionado 2314438: Los problemas de sincronización en la instancia principal de NSX Manager aparecen con el error "Error de REST API: 'El formato de uuid de instance_uuid no es válido".
Algunas máquinas virtuales de un entorno de varios VC, aunque se etiqueten con etiquetas universales en el principal, no se replican en el secundario.
Problema solucionado VMSA-2019-0010: Vulnerabilidades de kernel Linux en la confirmación selectiva de TCP (SACK) CVE-2019-11477, CVE-2019-11478
Todos los componentes de NSX-V 6.4.6 contienen la solución para las vulnerabilidades de kernel de Linux en la confirmación selectiva de TCP (SACK) CVE-2019-11477, CVE-2019-11478. Los clientes pueden actualizar a la versión 6.4.6 y versiones posteriores para obtener una resolución permanente de los CVE mencionados anteriormente. El artículo de la base de conocimientos 71311 incluye información adicional sobre el problema.
Problema solucionado 2324338: Si la regla DFW está configurada y tiene vNIC efectivas con direcciones IPv4 e IPv6, la actualización de uno de los tipos de direcciones también eliminará la otra dirección IP, lo que provocará un comportamiento inesperado en la regla de DFW correspondiente.
Cualquier cambio en un tipo de dirección IP sobrescribirá los dos tipos de direcciones IP presentes. Si se incluye una actualización que solo tenga una dirección IPv6, se actualizará el registro de la base de datos, y tanto la dirección IPv4 como la IPv6 se reemplazarán solo con la nueva dirección IPv6.

Problemas conocidos

Los problemas conocidos se dividen del siguiente modo.

Problemas conocidos de instalación y actualización
Problemas conocidos de NSX Manager
Problemas conocidos generales
Problemas conocidos de interoperabilidad de soluciones

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 1859572: Durante la desinstalación de la versión 6.3.x de VIB de NSX en hosts ESXi administrados por la versión 6.0.0 de vCenter, el host continúa en modo de mantenimiento.
Si va a desinstalar la versión 6.3.x de VIB de NSX en un clúster, el flujo de trabajo implica colocar los hosts en modo de mantenimiento, desinstalar los VIB y, a continuación, quitar los hosts del modo de mantenimiento por el servicio EAM. Sin embargo, si dichos hosts están administrados por la versión 6.0.0 de vCenter Server, esto dará lugar a que el host se bloquee en el modo de mantenimiento después de desinstalar los VIB. El servicio EAM responsable de desinstalar los VIB pone al host en modo de mantenimiento, pero se produce un error al sacar los hosts de dicho modo.

Solución alternativa: Sacar manualmente el host del modo de mantenimiento. Este problema no se producirá si el host está administrado por la versión 6.5a y posteriores de vCenter Server.
Problema 1263858: La VPN SSL no envía una notificación de actualización al cliente remoto.
La puerta de enlace de la VPN SSL no envía una notificación de actualización a los usuarios. El administrador debe comunicar manualmente a los usuarios remotos que la puerta de enlace de la VPN SSL (servidor) está actualizada y que deben actualizar los clientes.

Solución alternativa: Los usuarios deben desinstalar la versión anterior del cliente e instalar la última versión manualmente.
Problema 2006028: Es posible que se produzca un problema en la actualización del host si el sistema vCenter Server se reinicia durante la actualización.
Si el sistema vCenter Server asociado se reinicia durante una actualización del host, es posible que se produzca un error en dicha actualización y deje al host en modo de mantenimiento. Aunque haga clic en Resolver (Resolve), el host no saldrá del modo de mantenimiento. El estado del clúster es "No está listo" ("Not Ready").

Solución alternativa: Sacar manualmente al host del modo de mantenimiento. Haga clic en "No está listo" ("Not Ready") y "Resolver todo" ("Resolve All") en el clúster.
Problema 2429861: La latencia de extremo a extremo no se mostrará en la interfaz de usuario de vRNI después de actualizar a NSX-v 6.4.6.
La latencia de extremo a extremo se interrumpió con la interoperabilidad de vRNI para vRNI 4.2 y vRNI 5.0.

Solución alternativa: Actualice vRNI a la versión 5.0.0-P2.
Problema 2449643: vSphere Web Client muestra el error "No hay disponible ninguna instancia de NSX Manager" (No NSX Manager available) tras actualizar NSX de la versión 6.4.1 a la 6.4.6.
En vSphere Web Client, las páginas Firewall y Conmutador lógico muestran el siguiente mensaje de error:
"No hay disponible ninguna instancia de NSX Manager. Compruebe que el usuario actual tiene la función asignada en NSX Manager " (No NSX Manager available. Verify current user has role assigned on NSX Manager).

Dado que las páginas Firewall y Conmutador lógico no están disponibles en la interfaz de usuario, es posible que los usuarios no puedan configurar reglas de firewall ni crear conmutadores lógicos. Las API de NSX también tardan mucho tiempo en responder.

En el archivo /usr/nsx-webserver/logs/localhost_access_log se muestran entradas similares a las siguientes:
127.0.0.1 - - [27/Oct/2019:08:38:22 +0100] "GET /api/4.0/firewall/globalroot-0/config HTTP/1.1" 200 1514314 91262
127.0.0.1 - - [27/Oct/2019:08:43:21 +0100] "GET /api/4.0/firewall/globalroot-0/config HTTP/1.1" 200 1514314 90832

127.0.0.1 - - [27/Oct/2019:11:07:39 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 264142
127.0.0.1 - - [27/Oct/2019:11:07:40 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 265023
127.0.0.1 - - [27/Oct/2019:11:07:40 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 265265

Solución alternativa:

Cambie el nombre de los archivos log4j-1.2.14.jar y log4j-1.2.17.jar manualmente y reinicie el servicio bluelane-manager.

1. Inicie sesión en la CLI de NSX Manager como usuario raíz.

2. Ejecute estos comandos para cambiar el nombre de los archivos. jar:

/home/secureall/secureall/sem/WEB-INF/lib]# mv log4j-1.2.17.jar log4j-1.2.17.jar.old
/home/secureall/secureall/sem/WEB-INF/lib]# mv log4j-1.2.14.jar log4j-1.2.14.jar.old

3. Reinicie el servicio bluelane-manager ejecutando este comando:

/etc/init.d/bluelane-manager restart

Problemas conocidos de NSX Manager

Problema 2233029: ESX no admite rutas de 10K.
ESX no admite 10.000 rutas. Por diseño, el límite máximo en ESX es de 2.000 rutas.

Solución alternativa: Ninguna.
Problema 2391153: NSX Manager no actualiza la tabla vdn_vmknic_portgroup y vdn_cluster después de que las operaciones de vCenter se realicen en vmknic dvportgroup.
Al ejecutar la solicitud de API PUT https://nsx_manager_ip/api/2.0/nwfabric/configure, NSX Manager no actualiza la tabla vdn_vmknic_portgroup y vdn_cluster después de que las operaciones de vCenter se realicen en el portgroup virtual distribuido vmknic. La interfaz de usuario de vCenter sigue mostrando el identificador de VLAN anterior.

Solución alternativa: Ninguna
Problema 2445396: los puertos del grupo de equilibradores de carga se eliminan si se edita el grupo de equilibradores de carga y a continuación, se selecciona "Guardar" (Save).
Al editar el grupo de equilibradores de carga y guardar la configuración, se borran los números de puerto de todos los miembros.

Problemas conocidos generales

En vSphere Web Client, al abrir un componente de Flex que se superpone a la vista HTML, dicha vista se hace invisible.
Al abrir un componente de Flex (un menú o un cuadro de diálogo) que se superpone a una vista HTML, dicha vista se oculta temporalmente.
(Referencia: http://pubs.vmware.com/Release_Notes/en/developer/webclient/60/vwcsdk_600_releasenotes.html#issues)

Solución alternativa: Ninguna.
Problema 2367906: El uso de la CPU en NSX Edge alcanza el 100 % cuando se configura el monitor de servicio HTTP en el equilibrador de carga con la extensión "no-body".
Este problema se produce cuando se configura el monitor de servicio HTTP con la extensión "no-body" mientras se utiliza el complemento "nagios" en el equilibrador de carga. El equilibrador de carga pierde la conexión con todos los servidores back-end y se rompe la solicitud del usuario.

Solución alternativa: Consulte el artículo 71168 de la base de conocimientos para obtener más información.
Problema 2551523: es posible que se produzca un error al publicar una nueva regla si la regla contiene una dirección IP de cuatro ceros (0.0.0.0/0) después de actualizar de NSX-v 6.3.x a NSX-v 6.4.6.
Es posible que se produzca un error al publicar una nueva regla si la regla contiene una dirección IP de cuatro ceros (0.0.0.0/0) después de actualizar de NSX-v 6.3.x a NSX-v 6.4.6.

Solución alternativa: Cambie 0.0.0.0/0 por 'any' en el origen o el destino.
Problema 2536058: tiempo de respuesta elevado desde la API de NSX Manager para las API de get flowstats.
Al consultar la configuración del firewall y conjuntos de direcciones IP, el tiempo de respuesta para estas API es alto.
Problema 2513773: las reglas de IDFW no se aplican a las infraestructuras VDI después de que sus respectivos grupos de seguridad se quiten durante la sesión.
Las sesiones de VDI se descartan de forma aleatoria debido a la eliminación de los grupos de seguridad asociados a las reglas de IDFW.

Solución alternativa: Activa otra sincronización manual.
Problema 2509224: tabla de flujos excesivamente grande en NSX Edge en HA provoca descartes de conexión.
La sincronización excesiva de la tabla de seguimiento de la conexión desde una instancia de NSX Edge en espera hasta una instancia de NSX Edge activa hace que se descarten nuevas conexiones.

Solución alternativa: Ninguna.
Problema 2502739: tiempo de respuesta elevado desde la API de NSX Manager para las API de FW e IPSet.
Al consultar la configuración del firewall y los conjuntos de direcciones IP, el tiempo de respuesta para estas API es alto.

Solución alternativa: Ninguna.
Problema 2498988: tiempo de respuesta elevado cuando se consultan los objetos de agrupaciones.
Al consultar objetos de agrupaciones, el tiempo de respuesta para estas API es elevado.
Problema 2458746: las configuraciones de LIF no admitidas tuvieron como resultado una PSoD en varios hosts.
Se implementaron validaciones de host para no agregar LIF duplicadas en diferentes DLR.

Solución alternativa: Para asegurarse de que el cable virtual no esté en dos DLR diferentes, elimine uno de ellos.
Problema 2452833: el host ESXi de mantenimiento de una máquina virtual de control de DLR puede mostrar una PSoD si se consume la misma VXLAN en el puente, así como una LIF en dos DLR diferentes.
Un ESXi que dé servicio de la máquina virtual de control de DLR puede causar una PSoD si se consume la misma conexión virtual para el puente y como una LIF.

Solución alternativa: Espere a que se complete el trabajo actual y confirme que no hay trabajos pendientes antes de pasar a otra instancia de Edge para la configuración.
Problema 2451586: las reglas de aplicación de LB no funcionan después de actualizar NSX a la versión 6.4.6.
Cuando los servidores back-end HTTP(s) están detrás de un equilibrador de carga de NSX como parte de NSX Edge, los clientes se comunican con los servidores back-end a través del equilibrador de carga. El equilibrador de carga envía encabezados en minúsculas, aunque en realidad los servidores los enviaron en mayúsculas y minúsculas.
Problema 2448449: las reglas de aplicación configuradas con req_ssl_sni pueden generar un error de análisis cuando se actualiza a NSX for vSphere 6.4.6.
Tras la actualización a NSX for vSphere 6.4.6, si se configura un equilibrador de carga con una regla relacionada con SNI, o cuando se crea o configura una nueva regla relacionada con SNI en esta versión, es posible que se produzca un error al actualizar o al crear la regla relacionada.

Solución alternativa: Consulte el artículo 75281 de la base de conocimientos de VMware.
Problema 2444275: el host muestra una PSoD cuando la función de latencia de la infraestructura virtual está habilitada.
El host ESXi muestra una PSoD cuando la función de latencia de la infraestructura virtual está habilitada en VRNI en un entorno compuesto por más de 975 túneles BFD por host. En un entorno de escala, el host ESXi mostrará una PSoD si se habilita la latencia.

Solución alternativa: Deshabilite la función de latencia/mapa térmico en un entorno de escala.
Problema 2493095: se ha eliminado la compatibilidad con listas de direcciones IP separadas por comas en DFW desde la interfaz de usuario y la base de datos.
Después de actualizar desde versiones anteriores de NSX-v a NSX-v 6.4.6, se quitó la dirección IP separada por comas en DFW.
Problema 2459936: no se puede dividir la red en dos partes mediante rutas estáticas con la red (0.0.0.0/1 y 128.0.0.0/1).
Solo se permite la ruta estática con la red 0.0.0.0/0.

Solución alternativa: Ninguna.
Problema 2448235: después de actualizar a NSX-v 6.4.6, es posible que no pueda filtrar las reglas de firewall mediante el protocolo, el puerto de origen y el puerto de destino.
No podrá filtrar las reglas de firewall mediante los filtros Protocolo, Puerto de origen y Puerto de destino.
Problema 2445183: NSX Manager no se puede ver en vSphere Web Client después de reemplazar el certificado SSL de NSX Manager.
Después de reemplazar el certificado SSL de NSX Manager, NSX Manager no estará visible en vSphere Web Client.

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

Problemas conocidos de interoperabilidad de soluciones