VMware NSX Data Center for vSphere 6.4.8 | Publicado el 10 de agosto de 2020 | Compilación 16724220 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.8

VMware NSX for vSphere 6.4.8 resuelve un problema específico identificado en VMware NSX for vSphere 6.4.7 que podría afectar tanto a nuevos clientes de NSX como a clientes que actualicen versiones anteriores de NSX. Consulte la sección Problemas resueltos para obtener más información.

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

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

  2. Use la API de configuración de ajuste de NSX:
     PUT https://<nsxmanager>/api/4.0/edgePublish/tuningConfiguration
     para asegurarse de que los valores de edgeVCpuReservationPercentage y edgeMemoryReservationPercentage se encuentran dentro de los recursos disponibles para el factor de forma (consulte la tabla 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

10 de agosto de 2020: Primera edición.
17 de agosto de 2020: Segunda edición. Se agregó el problema resuelto 2306230.
21 de septiembre de 2020: Tercera edición. Se agregaron los problemas conocidos 2631548 y 2633165.
26 de abril de 2021. Cuarta edición. Se agregó el problema resuelto 2584256.

Problemas resueltos

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

• 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 2584256: Uso elevado de memoria notificado en NSX Edge que provoca un reinicio automático de Edge.

  Edge no responde y no se puede administrar. Advertencias críticas notificadas en la interfaz de usuario: "NSX Edge is out of memory. The Edge is rebooting in 3 seconds" (NSX Edge se ha quedado sin memoria. Edge se reiniciará dentro de 3 segundos).

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 2631548: el proceso netcpa de los hosts ESXi no se puede conectar a CCP en el puerto 1234 después de reiniciar un host ESXi preparado con VIB de NSX 6.4.8.

  La conexión de netcpa desde el host ESXi al clúster del controlador de NSX puede permanecer en el estado SYN_SENT después de reiniciar el host ESX debido a una condición de carrera en la secuencia de inicialización de los procesos netcpad y hostd, con el proceso netcpad inicializándose antes que hostd.

  Solución alternativa: Reinicie el proceso netcpad con el comando /etc/init.d/netcpad restart
  Consulte más información en el artículo 80607 de la base de conocimientos de VMware.

• Problema 2633165: Se produce un error en las llamadas REST API para crear/modificar/eliminar subinterfaces.

  Se produce un error en las operaciones de subinterfaz para crear, modificar o eliminar usando la REST API /api/4.0/edges/{edge-Id}/vnics/{vNic_Index}/subinterfaces/. El error solo se produce con la REST API con el URI 

  /api/4.0/edges/{edge-Id}/vnics/{vNic_Index}/subinterfaces/ y /api/4.0/edges/{edge-Id}/vnics/{vNic_Index}/subinterfaces/{subInterface-index}.

  Los clientes que utilizan scripts de automatización para crear, modificar o eliminar subinterfaces mediante la REST API /api/4.0/edges/{edge-Id}/vnics/{vNic_Index}/subinterfaces/ obtendrán el error en la operación de subinterfaz.

  Solución alternativa: Las operaciones de subinterfaz que se realizan mediante la interfaz de usuario o la REST API de vNIC se realizan correctamente.
  1) Utilice la interfaz de usuario para crear, modificar o eliminar subinterfaces.
  2) Utilice el comando PUT api/4.0/edges/{edge-Id}/vnics/{index} con carga útil para crear, actualizar o eliminar subinterfaces.

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