VMware NSX Data Center for vSphere 6.4.7 | Publicado el 9 de julio de 2020 | Compilación 16509800

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

Información importante acerca de NSX for vSphere 6.4.7

Nota: VMware identificó un problema en VMware NSX for vSphere 6.4.7 que puede afectar tanto a nuevos clientes de NSX como a clientes que actualicen versiones anteriores de NSX. Como resultado, VMware decidió dejar de distribuir NSX 6.4.7. La versión disponible de NSX for vSphere actualmente es la 6.4.6. VMware está trabajando en el lanzamiento de la siguiente versión para reemplazar NSX for vSphere 6.4.7.

Consulte el artículo 80238 de la base de conocimientos de VMware.

NSX Data Center for vSphere 6.4.7 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.7:

Soporte para vSphere 7.0
Mejoras de multidifusión: Se agregó soporte para los siguientes elementos:
- PIM a través de un túnel GRE, excepto PIM sobre cualquier otro vínculo superior al mismo tiempo.
- Rutas estáticas utilizadas por la conectividad de unidifusión.
- Modo Activo-En espera.
- Firewall de Edge para multidifusión.
- Firewall distribuido para multidifusión.
VMware NSX: actualizaciones de funciones para vSphere Client (HTML): Para ver la lista de funciones compatibles, consulte Funciones del complemento de IU VMware NSX for vSphere en vSphere Client.

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.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. Nota: vSphere 6.0 ha alcanzado el final de la asistencia general y no es compatible con NSX 6.4.7 y versiones posteriores.
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	Asegúrese de que la máquina virtual invitada tenga una versión compatible de Linux instalada. Consulte la guía de administración de VMware NSX para obtener la lista más reciente de versiones compatibles de Linux.

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.
En NSX 6.4.7, la siguiente función ha quedado obsoleta en vSphere Client 7.0:
- NSX Edge: SSL VPN-Plus (consulte el artículo 79929 de la base de conocimientos para obtener más información)
- Herramientas: Supervisión de endpoints (todas las funciones)
- Herramientas: Supervisión de flujo (panel de control de flujo, detalles por servicio y configuración)
- Eventos del sistema NSX Ticket Logger

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.7: VIO no es compatible con la 6.4.7 de NSX debido a varios problemas de escala.
- 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.
No se admite la funcionalidad de definiciones de servicio en interfaz de usuario de NSX 6.4.7 con vSphere Client 7.0:
Por ejemplo, si tiene una definición de servicio de Trend Micro antigua registrada con vSphere 6.5 o 6.7, siga cualquiera de estas dos opciones:
- Opción 1: Antes de actualizar a vSphere 7.0, desplácese hasta la pestaña Definición de servicio (Service Definition) en el vSphere Web Client, edite la definición de servicio a 7.0 y, a continuación, actualice a vSphere 7.0.
- Opción 2: Después de actualizar a vSphere 7.0, ejecute la siguiente NSX API para agregar o editar la definición de servicio en 7.0.

POST https://<nsmanager>/api/2.0/si/service/<id-servicio>/servicedeploymentspec/versioneddeploymentspec

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.
Después de actualizar a NSX 6.4.7, las interfaces y los puentes de un DLR no se pueden conectar a dvPortGroups que pertenezcan a diferentes VDS: Si hay una configuración de este tipo, la actualización de NSX Manager a la versión 6.4.7 se bloqueará en las comprobaciones de validación previas a la actualización. Para solucionar este paso, asegúrese de que las interfaces y los puentes de capa 2 de un DLR estén conectados a un solo VDS.
Después de actualizar a NSX 6.4.7, DLR no se puede conectar a grupos de puertos respaldados por VLAN si la zona de transporte a la está conectado el conmutador lógico abarca más de un VDS: Esto garantiza la correcta alineación entre instancias del DLR con dvPortGroups de conmutadores lógicos en los hosts. Si hay una configuración de este tipo, la actualización de NSX Manager a la versión 6.4.7 se bloqueará en las comprobaciones de validación previas a la actualización. Para solucionar este problema, asegúrese de que no haya interfaces lógicas conectadas a grupos de puertos respaldados por VLAN si existe una interfaz lógica que tenga un conmutador lógico que pertenezca a una zona de transporte que abarque varios VDS.
Después de actualizar a NSX 6.4.7, diferentes DLR no pueden tener sus interfaces y puentes de capa 2 en una misma red: Si hay una configuración de este tipo, la actualización de NSX Manager a la versión 6.4.7 se bloqueará en las comprobaciones de validación previas a la actualización. Para solucionar este problema, asegúrese de que la red se utilice únicamente en un solo DLR.

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

9 de julio de 2020: Primera edición.
4 de agosto de 2020: Segunda edición. Se agregó el problema conocido 2614777.
17 de agosto de 2020: Tercera edición. Se agregó el problema resuelto 2306230.

Problemas resueltos

Problema solucionado 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.
Problema solucionado 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 solucionado 2306230: La infraestructura de mensajería deja de funcionar para los hosts debido a un retraso de latido.
Se restablecen las contraseñas de los hosts. Es posible que los usuarios no puedan configurar en los hosts durante el tiempo de desconexión.
Problema solucionado 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.
Problema solucionado 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").
Problema solucionado 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.
Problema solucionado 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.
Problema solucionado 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.
Problema solucionado 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
Problema solucionado 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 6.3.6 a NSX 6.4.6.
Las reglas de firewall con la dirección IP 0.0.0.0/0 en el origen o el destino no se pueden publicar.
Problema solucionado 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 solucionado 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.
Problema solucionado 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.
Problema solucionado 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.
Problema solucionado 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 solucionado 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.
Problema solucionado 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.
Problema solucionado 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 solucionado 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.
Problema solucionado 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.
Problema solucionado 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. Los usuarios con una configuración de firewall con direcciones IP separadas por comas no pudieron actualizar la configuración.
Problema solucionado 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).
De NSX 6.4.0 a 6.4.6 se permitía la ruta estática con solo la red 0.0.0.0/0. A partir de NSX 6.4.7, se permite agregar una ruta estática con la red 0.0.0.0/x, donde 0 <= x <= 32.
Problema solucionado 2430886: Se muestra un estado de host incorrecto en la base de datos de NSX Manager para los clústeres que están deshabilitados.
La página de preparación del host muestra el estado del firewall como erróneo incluso cuando el clúster tiene habilitado el firewall.
Problema solucionado 2383382: En la lista de comandos predeterminados de la CLI de NSX Manager, el comando de eliminación muestra información de ayuda incorrecta.
La información de ayuda para el comando de eliminación se muestra como "Mostrar información del sistema en ejecución" (Show running system information).
Problema solucionado 2407662: El servicio Guest Introspection no funciona cuando el host ESXi y vCenter Server se reinician de forma simultánea.
El estado del servicio Guest Introspection no es verde después de reiniciar el host ESXi o cuando la máquina virtual de GI se enciende manualmente mientras no se ejecuta vCenter.

Se muestra el siguiente mensaje de error en "/usr/local/usvmmgmt/logs/eventmanager.log":
```
ERROR taskScheduler-4 PasswordChangeHelper:139 - Cmd does not exit normally, exit value = 1
```
Problema solucionado 2410743: La conexión de las interfaces lógicas de un DLR a dvPorGgroups de varios vSphere Distributed Switch provoca una interrupción del tráfico en algunas de las interfaces lógicas.
El tráfico de algunas de las interfaces lógicas no funciona correctamente. Los hosts muestran que las interfaces lógicas se asocian a vSphere Distributed Switch incorrectos.
Problema solucionado 2413213: Las tareas de mantenimiento no se programan y la tabla ai_useripmap aumenta.
La tabla "ai_useripmap" no está limpia.
Problema solucionado 2430753: Al crear un grupo de direcciones IP, si se agrega espacio adicional en la dirección IP de la puerta de enlace, el host ESXi no crea la IP de puerta de enlace para el VTEP.
La conectividad de VTEP a VTEP se interrumpe debido a que falta la puerta de enlace en la configuración del grupo de direcciones IP.
Problema solucionado 2438649: Algunos enrutadores lógicos distribuidos en el host pierden todas sus interfaces lógicas.
Las máquinas virtuales pierden conectividad con el DLR debido a que faltan interfaces lógicas en el DLR.
Problema solucionado 2439627: No se puede obtener el archivo muxconfig.xml en el host de ESXi una vez se ha actualizado NSX Manager.
El servicio Guest Introspection no está disponible. El estado del servicio de GI muestra el siguiente mensaje de advertencia para todos los hosts:
```
El servicio Guest Introspection no está listo.
```
Problema solucionado 2440903: El uso de la CLI centralizada de NSX para NSX Edge muestra datos de Edge pasivo.
El resultado de la CLI centralizada de NSX para NSX Edge puede provenir de una máquina virtual de Edge incorrecta.
Problema solucionado 2445183, 2454653: Después de reemplazar el certificado SSL del dispositivo de NSX Manager no está disponible en el inventario de vSphere.
Se muestra el siguiente mensaje de error en vSphere Client:
```
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.)
```
Problema solucionado 2446265: vSphere Web Client envía el GUID de vCenter como nulo en la llamada de API al recuperar la lista de máquinas virtuales excluidas.
En vSphere Web Client, cuando se hace clic en el botón Agregar (Add) para agregar nuevos miembros de la lista de exclusión, se muestra el siguiente mensaje de error antes de que se carguen datos completos en la interfaz de usuario:
```
Error al comunicarse con vCenter Server.
```
El cuadro de diálogo Agregar miembros excluidos no se muestra correctamente (Failed to communicate with vCenter Server. The Add Excluded Members dialog box is not displayed correctly.)
Problema solucionado 2447697: NSX Edge entra en un estado incorrecto debido a un error de configuración y un error de reversión.
Edge se puede administrar después de un error de configuración.
Problema solucionado 2453083: La entrada obsoleta en la tabla vnvp_vdr_instance hace que se produzca un error en las actualizaciones de la configuración de DLR y que no haya interfaces lógicas en el host.
El flujo de tráfico se interrumpe. Se produce un error al intentar volver a implementar, sincronizar o actualizar el DLR.
Problema solucionado 2460987: La máquina virtual de servicio obtiene tramas etiquetadas con prioridad.
Las tramas encapsuladas de VXLAN en vínculos superiores con bit de dot1p establecido provocan que SVM reciba tramas etiquetadas prioritarias. Los paquetes se descartan en los puertos SVM.
Problema solucionado 2461125: En la página panel del control del sistema de NSX, se muestra un recuento incorrecto de vecinos de BGP para UDLR.
Este problema se produce debido a varias entradas para la función de enrutamiento en la tabla edge_service_config.
Problema solucionado 2465697: Se produce un error en la implementación del controlador cuando NSX Manager tiene la versión 6.4.x y las instancias de NSX Controller tienen la versión 6.3.x
Tras la actualización de NSX Manager de la versión 6.3.x a la 6.4.x, y antes de que NSX Controller se actualice a la versión 6.4.x, si se implementan instancias de NSX Controller 6.3.x, se produce un error en la implementación, ya que el servidor syslog no es compatible con la versión 6.3.x.
Problema solucionado 2465720: Mientras se actualizan los dispositivos virtuales de Edge para Edge-A, los dispositivos virtuales de Edge-B se actualizan de forma involuntaria.
Edge-A y Edge-B entran en estado de reimplementación. Debido a cambios no deseados o involuntarios en otros dispositivos Edge, pueden producirse varios problemas, como la latencia de red, el impacto en los servicios empresariales, etc.
Problema solucionado 2467360: El servicio Guest Introspection está bloqueado en estado de advertencia, ya que una máquina virtual no está presente en el inventario de NSX.
El servicio Guest Introspection está atascado en estado de advertencia debido a que no se puede encontrar una máquina virtual durante la supervisión del estado de mantenimiento del endpoint. El XML de estado de mantenimiento que envía MUX contiene una máquina virtual que no está presente en el inventario de NSX.
Problema solucionado 2468786: Si sospecha que se interrumpió antes de la sincronización de Active Directory, la integridad de la base de datos (ai_group tiene un valor nulo para primary_id) e impide que se realicen todas las sincronizaciones futuras de Active Directory, por lo que las actualizaciones futuras no estarán visibles en NSX.-
La sincronización de Active Directory sigue fallando y NSX no ve los cambios futuros de Active Directory. Aunque las reglas de firewall existentes funcionan para los usuarios y los grupos existentes, NSX no ve los cambios de Active Directory. Los usuarios no pueden ver los grupos de Active Directory creados recientemente ni tampoco otros cambios de Active Directory, como, por ejemplo, usuarios nuevos, usuarios eliminados, usuarios agregados o eliminados de grupos de Active Directory, etc.
Problema solucionado 2470918: Los comandos de la CLI relacionados con "show ip bgp *" generan un volcado de núcleo.
Las rutas se eliminan hasta que se reinicia el daemon de enrutamiento. Esto hace que se produzca una interrupción del servicio hasta que se vuelvan a agregar las rutas.
Problema solucionado 2475392: Cuando se utiliza el mismo conmutador lógico como puente y una interfaz lógica en dos DLR diferentes, es posible que se muestre una PSoD en el host en el que se encuentra la máquina virtual de control de DLR con puente.
Esta configuración puede pasar cuando se realiza la configuración en el segundo DLR antes de que se complete el trabajo pendiente en el primer DLR. Antes de la PSoD, se muestra el siguiente mensaje de error en el archivo vsm.log:
```
No se pueden conectar dos enrutadores distribuidos Edge-A y Edge-B a la misma red recuento-x.
```
Problema solucionado 2478262: El comando "show host <id-host> health-status" muestra el estado crítico aunque la comunicación del controlador esté en buen estado.
El estado de mantenimiento que se muestra en este comando es un falso positivo. No hay ningún impacto en la función.
Problema solucionado 2479599: el proceso vserrdd satura el uso de la CPU.
La CPU está saturada y esto probablemente afecta a los otros procesos.
Problema solucionado 2480450: Error en la ruta del error cuando el host ESXi está fuera de la memoria de pila.
Es posible que se muestre una PSoD cuando el host ESXi está fuera de la memoria de pila en un momento inoportuno.
Problema solucionado 2488759: Ruta de acceso de almacén de datos incorrecta en la base de datos de NSX Manager durante Storage vMotion.
MUX se bloquea repetidamente y el sistema operativo invitado se detiene con frecuencia.
Problema solucionado 2491042: Carga de CPU alta en NSX Manager provocada por el proceso postgres.
Los procesos postgres consumen casi todos los recursos de la CPU que se muestran en el comando superior.
Problema solucionado 2491749: El paquete de SYN retransmitido no siempre se controla correctamente en el código de seguimiento de máquinas de estado TCP.
En función de los números de secuencia, un paquete SYN retransmitido puede provocar una pérdida de paquetes posterior.
Problema solucionado 2491914: Al utilizar la extensibilidad de red (NetX), después de vMotion, las sesiones establecidas con TCP no respetan el tiempo de espera de estado.
Después de aplicar vMotion a los estados con NetX, aunque la sesión de TCP continúe, el temporizador inactivo se iniciará y finalizará después de 12 horas. La sesión TCP finaliza de forma inesperada y los flujos se interrumpen.
Problema solucionado 2499225: La retransmisión de DHCP en un enrutador lógico distribuido no transmite correctamente la difusión.
Cuando un equipo cliente envía una detección de DHCP o un mensaje de solicitud con el conjunto de bits de difusión, la retransmisión de DHCP en el DLR no envía el paquete de respuesta como difusión. Esto puede provocar que algunas máquinas cliente no reciban el paquete de respuesta.
Problema solucionado 2503002: Se agota el tiempo de espera de la operación de publicación de DFW, pero las reglas siguen publicadas
Este problema se produce en un entorno de gran escala con una gran cantidad de reglas de DFW. La página de DFW se carga lentamente en la interfaz de usuario. El archivo localhost_access_log.txt muestra que la API de publicación del firewall tarda más de 2 minutos. La API publica la configuración de la regla de DFW. Sin embargo, en la interfaz de usuario, se muestra el mensaje de tiempo de espera.
Problema solucionado 2506402: La interfaz de usuario de Edge y la CLI de la máquina virtual muestran discrepancias para las conexiones simultáneas.
A partir de NSX 6.4.0, una mejora en el cambio de alta disponibilidad sincroniza los flujos desde el nodo de Edge activo hasta el nodo de Edge en espera. Esto hace que las estadísticas de la interfaz de Edge muestren el doble de datos.
Problema solucionado 2510798: El campo Descripción (Description) de NSX Edge no se puede editar después de la implementación.
El campo Descripción (Description) no se puede editar desde la interfaz de usuario y la API después de implementar la instancia de Edge.
Problema solucionado 2524239: El registro de cambios de estado de BFD no puede imprimirse en el servidor syslog.
El registro de cambios de estado de BFD se imprime como un mensaje incompleto y el servidor syslog no puede recibirlo.
Problema solucionado 2531966: La operación de publicación de reglas de firewall da como resultado el tiempo de espera de vCenter.
Cuando la configuración del firewall supera las 7000 reglas, al agregar o eliminar una sección de reglas de firewall, se agota el tiempo de espera de la comunicación entre vCenter y NSX Manager.
Problema solucionado 2541643: La tarea de purga no gestiona los trabajos con el tipo de programación FIXED_DATE.
Es posible que el sistema se ralentice debido a que el espacio en disco es insuficiente o a un consumo de memoria elevado. Las tablas relacionadas con el trabajo contienen un gran número de registros.
Problema solucionado 2544344: No se puede crear un túnel GRE con usuarios que no sean administradores y tengan privilegios de administrador asignados.
Los usuarios que no sean administradores asignados con privilegios administrativos empresariales completos no pueden crear túneles GRE. Sin embargo, los administradores sí puede crear túneles GRE.
Problema solucionado 2554069: El equilibrador de carga en NSX Edge se bloquea en NSX 6.4.6.
Los errores de segmentación seguidos del servicio HAProxy se reinician con frecuencia.
Problema solucionado 2556706: No se puede especificar un FQDN local para algunas configuraciones de NSX Controller.
En la API de syslog de NSX Controller, cuando se especifica la dirección local como un FQDN, se produce un error en la configuración.
Problema solucionado 2560152: Se muestra una PSoD en el host ESXi mientras se exportan paquetes de registros de host en el clúster preparado para NSX.
Este problema se produce cuando hay más de 100 VTEP en un conmutador lógico. Se generan Vmkernel zdumps en /var/core.
Problema 2560422: La interfaz de usuario no muestra los datos correctos en la página de la lista de exclusión de máquinas virtuales.
La interfaz de usuario realiza varias llamadas de API para recuperar la lista de exclusión. Los datos se cargan lentamente en la página de la lista de exclusión de la interfaz de usuario. Es posible que la página solo muestre una parte de la lista de exclusión en la cuadrícula.
Problema solucionado 2561009: El daemon del servidor VPN de SSL se bloquea cuando un número elevado de usuarios intentan iniciar sesión con una sola credencial de usuario.
El daemon de VPN de SSL se bloquea y se reinicia.
Problema solucionado 2566512: El firewall de NSX Edge no es compatible con las reglas de firewall configuradas con mensajes de pertenencia a IGMP de tipo "query", "report" y "leave".
El dispositivo de NSX Edge no admite aún los servicios IGMP Leave e IGMP Membership.
Problema solucionado 2567085: El proceso VSFWD podría bloquearse debido a un procesamiento de número de aciertos de reglas.
El archivo de núcleo de VSFWD aparece en el host con seguimiento inverso que apunta al procesamiento de aciertos de reglas. El guardián de VSFWD reinicia automáticamente el proceso después del bloqueo.
Problema solucionado 2444941, 2574374: En un entorno de NSX de gran tamaño, se muestra una PSoD en hosts ESXi cuando se habilita la latencia.
Cuando BFD está habilitado, se habilita la medición de latencia de red. La PSoD puede aparecer cuando el número de sesiones de BFD supera las 975.
Problema solucionado 2586872: El daemon del servidor VPN de SSL se bloquea cuando el usuario intenta cambiar la contraseña del cliente VPN de SSL y no se encuentra la sesión.
El daemon de VPN de SSL se bloquea y se reinicia. Se finalizan todas las sesiones de VPN de SSL existentes y es necesario reiniciarlas. Todos los clientes VPN de SSL perderán su sesión y tendrán que volver a iniciar sesión en el servidor VPN de SSL.
Problema solucionado 2358130: Cuando se habilitan conjuntos de direcciones globales y se produce una exportación de vMotion, las tablas no se migran al host de destino.
Es posible que vMotion se haya completado correctamente, pero las tablas no existirán en el host de destino hasta que se publique la configuración desde el plano de administración.

En el archivo vmkernel.log del host de origen, aparece el siguiente mensaje:
```
Create tbl failed: -1
```
Problema solucionado 2382346: Cuando se agrega el servidor de registro de eventos de WIN2K8 mediante la interfaz de usuario, el servidor de registro de eventos se detecta de forma incorrecta como WIN2K3.
Identifique la función del firewall (IDFW).
Problema solucionado 2397810: Cuando la configuración regional de la interfaz de NSX Manager está configurada como inglés de EE. UU. (en_US) y la configuración regional del navegador está configurada como francés, algunos campos de syslog se registran incorrectamente en francés.
Los cambios realizados en las reglas de firewall se registran en francés en el servidor syslog en lugar de registrarse en inglés.
Problema solucionado 2417536: La conversión de IP de los grupos de seguridad con grupos de recursos como miembros consume mucha memoria y CPU cuando hay varias vNIC por cada máquina virtual en el sistema.
El uso elevado de la CPU hace que NSX Manager se reinicie con frecuencia.
Problema solucionado 2449644: La cola de trabajo de NSX Manager está sobrecargada.
Las acciones del plano de administración no se realizan en el hipervisor.

Problema solucionado 2459817: La sincronización del inventario de NSX falla repetidamente.

Se detectaron UUID de instancia similares en vCenter para diferentes máquinas virtuales. Esto hace que se generen los mismos identificadores de vNIC para distintas vNIC. Los usuarios deben detectar este problema en el archivo vsm.log.

Por ejemplo, se muestran los siguientes mensajes de información en el archivo vsm.log:

INFO ViInventoryThread VimVnic:159 - - [nsxv@6876 comp="nsx-manager" level="INFO" subcomp="manager"] Existing portgroupId : null , New portgroupId : dvportgroup-40  << indicate network change INFO ViInventoryThread VimVnic:217 - - [nsxv@6876 comp="nsx-manager" level="INFO" subcomp="manager"] network id : dvportgroup-40 , vnic id : 501c0ab1-e03c-b3ee-b662-9fd4649005d4.000 <= vnic id derived from instance uuid 501c0ab1-e03c-b3ee-b662-9fd4649005d4.

Problema solucionado 2462523: Alta latencia detectada en el tráfico de la máquina virtual.
Un elevado número de renovaciones de configuración de NSX conduce a una latencia de la máquina virtual. Cuando un número elevado de configuraciones llega al hipervisor, el plano de control local intenta configurar la ruta de datos, lo que bloquea momentáneamente el tráfico, provocando la latencia. La renovación de la configuración puede deberse a las máquinas virtuales que se encienden o se apagan continuamente en un centro de datos en el que se utilizan estas máquinas virtuales en los grupos.

Para mitigar este problema, habilite el conjunto de direcciones global que reducirá la configuración solo a una instancia en lugar de a una instancia por filtro en el hipervisor. De forma alternativa, mantenga el número de filtros aproximadamente entre 25 y 40.
Problema solucionado 2535292: No se acepta el CIDR IPv6 superior a /64 debido a la validación del plano de administración.
Se produce un error en la regla de firewall cuando contiene un CIDR de IPv6 con un prefijo superior a /64 en el origen o el destino de la definición de la regla.
Problema solucionado 2214872: Como parte de la integración de vSphere Update Manager y ESX Agent Manager, EAM invoca la API de importación de VUM con la URL http y el paquete de descargas de VUM desde esa URL.
La API FileUploadManagerImpl::ImportFile() de VUM está diseñada para funcionar solo con direcciones URL, que contienen una extensión o, al menos, "." en la URL. Si no se cumple esta condición, el métodoGetUrlFileNameExtension() genera una excepción. Las agencias EAM de vSphere correspondientes a los clústeres en la pestaña Preparación de hosts de NSX-V (NSX-V Host Preparation) se muestran como erróneas.

Problemas conocidos

Los problemas conocidos se dividen del siguiente modo.

Problemas conocidos de instalación y actualización
Problemas conocidos generales
Problemas conocidos de NSX Edge y redes lógicas
Problemas de interoperabilidad

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 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 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 2417029: Ruta de acceso incorrecta para los objetos de dominio en la base de datos de NSX Manager.
- Se produce un error en la actualización o la reimplementación de NSX Edge con el siguiente mensaje:
```
Cluster/ResourcePool resgroup-XXX needs to be prepared for network fabric to upgrade edge edge-XX.
```
- La lista desplegable de carpetas no muestra todas las carpetas de la máquina virtual en el cuadro de diálogo Agregar controlador (Add Controller).
- Uno o varios clústeres pueden provocar que el estado No listo (Not Ready).
Solución alternativa: Póngase en contacto con el equipo de soporte de VMware para solucionar este problema.
Problema 2238989: Tras la actualización de vSphere Distributed Switch en el host ESXi, la función RSS de software de VDS no surte efecto.
En los hosts que tienen habilitada la escala de lado de recepción de software (SoftRSS), la propiedad de VDS com.vmware.net.rdt.softrss no se restaura después de la actualización de VDS. Esto hace que SoftRSS se deshabilite. El archivo /var/run/log/VMkernel.log muestra los errores relacionados con la configuración de propiedades de softrss.

Solución alternativa:

Antes de actualizar VDS, elimine la propiedad softrss y vuelva a configurarla después de la actualización de VDS.
Problema 2107188: Cuando el nombre de un conmutador de VDS contiene caracteres que no son ASCII, NSX se produce un error en la actualización de VIB en hosts ESXi.
El archivo /var/run/log/esxupdate.log muestra el estado de la actualización.

Solución alternativa:

Cambie el nombre de VDS para que use caracteres ASCII y vuelva a actualizar.
Problema 2590902: Después de actualizar a NSX 6.4.7, cuando se asigna una dirección IPv6 estática a las máquinas virtuales de carga de trabajo en una red IPv6, las máquinas virtuales no pueden hacer ping en la interfaz de puerta de enlace IPv6 de la instancia de Edge.
Este problema se produce después de actualizar los conmutadores distribuidos de vSphere de 6.x a 7.0.

Solución 1:

Seleccione el VDS en el que se conectan todos los hosts, vaya a la configuración de edición y, en la opción Multidifusión (Multicast), cambie a Básico (Basic).

Solución 2:

Agregue las siguientes reglas en el firewall de Edge:
- Haga ping a la regla de permiso.
- La regla de permiso de detección de la escucha de multidifusión (MLD), que es icmp6, tipo 130 (v1) y tipo 143 (v2).

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 2543977: El recopilador de IPFIX de firewall distribuido no puede ver los flujos de los puertos UDP 137 o 138.
Cuando IPFIX está habilitado en la DFW, el host no envió los flujos de NetBIOS con los puertos 137 o 138.

Solución alternativa:

Use vSphere Client o NSX REST API para quitar los puertos excluidos 137 o 138 de las exclusiones de flujo.
Problema 2302171, 2590010: Cuando IPFIX está habilitado en un vSphere Distributed Switch con una frecuencia de muestreo de 100 %, el rendimiento baja.
Se produce una degradación del rendimiento de la ruta de datos y la capacidad de proceso de la ruta de datos disminuye a la mitad del límite de ancho de banda del canal de red.

Solución alternativa: Establezca la frecuencia de muestreo en menos del 10 %.
Problema 2574333: La configuración de vNIC de Edge tarda más de dos minutos cuando NAT está configurada con 8000 reglas.
vSphere Client muestra que NSX Manager no está disponible. Se agota el tiempo de espera de la interfaz de usuario después de dos minutos. La configuración de vNIC se completó correctamente en 2-3 minutos.

Solución alternativa: Ninguna
Problema 2443830: La degradación del rendimiento de la ruta de datos se produce sobre la red de VXLAN cuando se utiliza el controlador de la NIC ixgben.
Se reduce la capacidad de proceso en la red de VXLAN.

Solución alternativa:
- Ejecute el siguiente comando en el host ESXi:
```
esxcli system module parameters set -p "RSS=1,1" -m ixgben
```
- Reinicie el host.
Problema 2547022: Cuando se agrega un nuevo usuario de Active Directory al grupo secundario de Active Directory, el usuario no se incluye en el grupo de seguridad basado en el grupo de Active Directory principal.
El grupo de seguridad basado en el Active Directory principal no tiene el usuario.

Solución alternativa:

Agregue grupos de seguridad basados en el grupo secundario de Active Directory.
Problema 2614777: Se produce un error al publicar la regla de DFW si la regla consta de dos servicios con un puerto de servicio o rango de puertos de servicio superpuestos.
Error al publicar regla de DFW.

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

Problemas conocidos de NSX Edge y redes lógicas

Problema 1993241: No se admite la redundancia estática del túnel IPSec usando el enrutamiento estático
El tráfico IPSec fallará si el túnel principal se vuelve inactivo, lo que provoca la interrupción del tráfico. Este problema se conoce desde NSX 6.4.2.

Solución alternativa: Deshabilite y habilite el servicio.
Problema 2430805, 2576416: Las instancias de DLR se envían a todos los hosts preparados para NSX que estén conectados a VDS.
Se ven problemas relacionados con una instancia designada de VLAN. El tráfico de VLAN se interrumpe cuando la instancia designada de VLAN llega a un host no válido.

Solución alternativa:
- Configure VXLAN en hosts preparados para NSX con el mismo VDS.
- Reinicie el host para que obtenga la nueva configuración.
Problema 2576294: Cuando las interfaces lógicas de un DLR están conectadas a varios VDS, las interfaces lógicas se asocian a un VDS incorrecto en el host cuando este forma parte de dos VDS de VXLAN.
Si el DLR se sincroniza a la fuerza o se reimplementa en un estado mal configurado, todas las interfaces lógicas del DLR se adjuntarán al VDS incorrecto. Además, las interfaces lógicas de todas las nuevas DLR se adjuntan a un VDS incorrecto en el host. Se interrumpe el tráfico de la ruta de datos.

Solución alternativa:
- Elimine el segundo VDS que no se utiliza para la preparación de VXLAN del clúster.
- Según el estado actual de la configuración del host, puede volver a implementar o forzar la sincronización, o bien sincronizar el servicio de ruta para corregir la configuración en el host.
Problema 2582197: Cuando se configura una interfaz de NSX Edge con la máscara de subred /32, la ruta conectada no se ve en la tabla de enrutamiento o de reenvío.
Es posible que el tráfico a esa interfaz siga funcionando, pero se necesitará una ruta estática para llegar a los elementos del mismo nivel. Los usuarios no pueden utilizar interfaces con la máscara de subred /32. No se produce ningún problema si se utiliza cualquier otra máscara de subred.

Solución alternativa: Utilice cualquier otra máscara de subred excepto la máscara de subred /32.
Problema 2594802: En Service Composer, los usuarios no pueden mover una directiva de seguridad más allá de la ubicación 200 mediante el cuadro de diálogo Administrar prioridad (Manage Priority).
Este problema se observa en NSX 6.4.3 y versiones posteriores, y solo se produce cuando hay más de 200 directivas de seguridad. El cuadro de diálogo Administrar prioridad (Manage Priority) solo muestra las primeras 200 directivas y, por lo tanto, los usuarios no pueden mover una directiva de seguridad más allá de la posición 200.

Solución alternativa:

Identifique el peso de la directiva de seguridad de modo que se pueda mover a esa clasificación en particular. Por ejemplo, supongamos que la posición 300 tiene un peso de 1000 y que la posición 301 tiene un peso de 1200. Para mover la directiva de seguridad a la posición 301, proporcione un peso de 1100 (es decir, un número entre 1200 y 1100).

Realice estos pasos:
1. Abra el cuadro de diálogo Editar directiva de seguridad (Edit Security Policy).
2. Edite el peso de su directiva de seguridad a 1100 para que se pueda mover a la posición 301.
3. Haga clic en Finalizar (Finish).
4. Observe que la directiva se movió a la posición 301.
Problema 2395158: La sección de firewall aparece atenuada cuando la función de administrador empresarial está asignada a un grupo de Active Directory.
Para asignar la función de administrador empresarial a un grupo de Active Directory, desplácese a Usuarios y dominios > Usuarios > Usuario de identidad > Especificar el grupo de vCenter (Users and Domains > Users > Identity User > Specify vCenter Group). Cuando los usuarios que pertenecen a un grupo de Active Directory inician sesión y bloquean una sección de firewall, la sección bloqueada aparece atenuada para estos usuarios después de actualizar la página.

Solución alternativa:

En lugar de asignar la función de administrador empresarial al grupo de Active Directory, asigne esta función directamente a los usuarios. Para ello, desplácese hasta Usuarios y dominios > Usuarios > Usuario de identidad > Especificar usuario de vCenter (Users and Domains > Users > Identity User > Specify vCenter User).
Problema 2444677: Se produce un error de pánico de kernel en NSX Edge cuando se transfieren archivos grandes a través de una VPN de capa 2 por túneles VPN de IPSec.
Este error se produce cuando la MTU se establece en 1500 bytes.

Solución alternativa:

Establezca el valor de MTU en 1600 bytes.
Problema 2574260: La actualización de una configuración de conmutador lógico existente para habilitar el uso de VLAN de invitado (etiquetado de invitado virtual o etiquetado de VLAN 802.1q) no produce el resultado esperado.
El grupo de puertos de VDS que está asociado al conmutador lógico no se actualiza según corresponde.

Solución alternativa: Ninguna
Problema 2562965: Cuando se guarda una configuración de regla de DFW, el botón Guardar (Save) gira durante unos minutos y, por último, se produce un error en la interfaz de usuario.
Se muestra el siguiente mensaje de error en vSphere Client:
```
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.)
```
Este problema solo se produce al guardar la configuración de regla de DFW. No hay ningún impacto en la publicación de la regla de DFW.

Solución alternativa: Ninguna
Problema 2595144: En NSX 6.4.6, el uso de memoria de Edge de cuádruple tamaño supera el 90 % cuando el recuento de interfaces activas es 6 o más.
Este problema se observa en NSX 6.4.6 y versiones posteriores debido al cambio introducido para el tamaño del búfer de anillo de RX a 4096 en las instancias de Edge de cuatro grandes.
- NSX Edge informa sobre el uso de memoria alta cuando el número de interfaces es 6 o más.
- En la máquina virtual de NSX Edge, la salida del comando top -H muestra el uso del espacio de usuario normal.
- La salida del comando slabtop -o muestra un número de objetos de más de 100 000 para skbuff_head_cache.
Solución alternativa: Póngase en contacto con el equipo de soporte de VMware para solucionar este problema.

Problemas de interoperabilidad

Problema 2586381: VMware Integrated OpenStack (VIO) no es compatible con NSX 6.4.7 debido a problemas de escalado múltiple.
NSX 6.4.7 no admite la interoperabilidad con VIO.

Solución alternativa: Ninguna