This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

VMware NSX for vSphere 6.4.0 | Publicado el martes, 16 de enero de 2018 | Compilación 7564187

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 de NSX 6.4.0

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

Cambios introducidos en NSX for vSphere 6.4.0:

Servicios de seguridad:

  • Firewall de identidad: El firewall de identidad (IDFW) admite ahora sesiones de usuario en servidores de aplicaciones y escritorios remotos (RDSH) que comparten una única dirección IP. Así mismo, la nueva arquitectura "ruta de acceso rápida" mejora la velocidad de procesamiento de las reglas del IDFW. Ahora, la integración de Active Directory permite realizar sincronizaciones selectivas para que las actualizaciones de AD sean más rápidas.

  • Firewall distribuido (Distributed Firewall): El firewall distribuido (DFW) agrega contexto de Capa 7 basado en aplicaciones al control de flujo y a la planificación de microsegmentación. El Administrador de reglas de aplicaciones (ARM) recomienda ahora las directivas y los grupos de seguridad para realizar una estrategia de microsegmentación compacta y administrable.

  • Las reglas de firewall distribuido pueden crearse ahora como reglas sin estado a un nivel de sección por DFW.

  • El firewall distribuido admite la detección de la IP de la máquina virtual en el hipervisor. Esto permite a los usuarios comprobar si la IP de una máquina virtual determinada forma parte de un grupo de seguridad, clúster, grupo de recursos o host que se utilice en los campos Origen (Source), Destino (Destination) y Aplicado a (AppliedTo) de una regla de DFW.

  • Mecanismos de detección de dirección IP para máquinas virtuales: La aplicación autoritativa de directivas de seguridad según los nombres de máquinas virtuales u otros atributos basados en vCenter requiere que NSX conozca la dirección IP de la máquina virtual. NSX 6.2 incorporó la opción para detectar la dirección IP de las máquinas virtuales con intromisión DHCP o intromisión ARP. En NSX 6.4.0, el número de direcciones IP detectadas en el ARP aumentó hasta 128 y se pueden configurar desde la 1 hasta la 128.  Estos mecanismos de detección nuevos permiten que NSX aplique las reglas de seguridad basadas en dirección IP en máquinas virtuales que no tienen VMware Tools instalado.

  • Guest Introspection:  En la versión 6.5 de vCenter y versiones posteriores, las máquinas virtuales de Guest Introspection (GI) se denominan Guest Introspection (XX.XX.XX.XX), donde XX.XX.XX.XX es la dirección IPv4 del host en el que reside la máquina de GI. Esto ocurre durante la implementación inicial de GI.

Interfaz de usuario de NSX:

  • Compatibilidad con vSphere Client (HTML5): Incorpora el complemento de IU de VMware NSX para vSphere Client (HTML5). Para ver la lista de funciones compatibles, consulte Funciones del complemento de IU VMware NSX for vSphere en vSphere Client.
  • Compatibilidad con HTML5 en vSphere Web Client (Flash): Las funciones de NSX desarrolladas en HTML5 como por ejemplo, el panel de control, siguen siendo compatibles tanto con vSphere Client como con vSphere Web Client y además, ofrecen una experiencia sin igual a los usuarios que no pueden cambiar de forma inmediata a vSphere Client.
  • Menú de navegación mejorado: Disminuye el número de clics para acceder a funciones clave como Agrupar objetos (Grouping Objects), Etiquetas (Tags), Lista de exclusión (Exclusion List) y Configuración del sistema (System Configuration).

Funcionamiento y solución de problemas:

  • El coordinador de actualización proporciona un portal único para facilitar la planificación y la ejecución de las actualizaciones de NSX.  El coordinador de actualización proporciona una visión completa del sistema de todos los componentes de NSX con las versiones actual y de destino, los medidores del curso de la actualización, los planes de actualización personalizada o de un solo clic y las comprobaciones previas y posteriores.
  • Hay disponible un nuevo panel de control en HTML5 mejorado con muchos componentes nuevos. El panel de control es ahora la página de inicio predeterminada.  También puede personalizar los widgets definidos por el sistema así como crear sus propios widgets personalizados a través de la API.
  • El nuevo panel de control Escala de sistema (System Scale) recopila información sobre la escala del sistema actual y muestra los valores de configuración máximos para los parámetros de escala admitidos.  Las alertas y las advertencias también pueden configurarse cuando los límites se aproximan o se superan.
  • Mejoras de fiabilidad y solución de problemas en Guest Introspection.  Ciertas funciones tales como la notificación de estado de EAM, el curso de la actualización, los nombres personalizados de las máquinas virtuales seguras, la memoria adicional, etc., mejoran la fiabilidad y la solución de problemas de las implementaciones de GI.
  • La CLI Central para el conmutador lógico, el enrutador lógico y el firewall distribuido de Edge reducen el tiempo de solución de problemas con un acceso centralizado a las funciones de la red distribuida.
  • Hay disponible una nueva pestaña Paquete de soporte (Support Bundle) que le ayudará a recopilar el paquete de soporte a través de la interfaz de usuario con un solo clic. Ahora, ya puede recopilar los datos del paquete de soporte para ciertos componentes de NSX tales como NSX Manager, los hosts, las instancias de Edge y los controladores. Puede descargar este paquete de soporte agregado o bien cargarlo directamente en un servidor remoto. Puede ver el estado general de la recopilación de datos y el estado de cada componente.
  • Hay disponible una nueva pestaña Captura de paquetes (Packet Capture) para capturar paquetes a través de la interfaz de usuario. Si algún host no está en buen estado, puede obtener el volcado del paquete de dicho host para que el administrador pueda examinar la información del paquete y realizar una mayor depuración.
  • Ahora, ya puede habilitar el modo Operación con controlador desconectado (Controller Disconnected Operation, CDO) en la pestaña Administración (Management) en el sitio secundario para evitar problemas temporales de conectividad. El modo CDO garantiza que la conectividad del plano de datos no se vea afectada en un entorno de varios sitios cuando el sitio principal pierda la conectividad. 
  • Compatibilidad para varios servidores syslog (máximo de 5).
  • Mejoras de la API, incluida la compatibilidad con JSON.  NSX ofrece ahora la posibilidad de elegir entre JSON o XML para los formatos de datos.  XML sigue siendo el valor predeterminado de compatibilidad con versiones anteriores.
  • Algunos de los mensajes de eventos del sistema de NSX Edge incluyen ahora parámetros de ID de Edge o de la máquina virtual. Por ejemplo, el código de evento 30100, 30014 o 30031.
    Estos parámetros de mensajes no estarán disponibles para los eventos del sistema más antiguos. En dichos casos, el mensaje del evento mostrará {0} o {1} para los parámetros de ID de Edge o de la máquina virtual.

  • Ahora puede utilizar NSX API para conocer el estado del hipervisor. Supervisar el estado de túnel del hipervisor resulta útil para solucionar problemas rápidamente. La respuesta de la API incluye el estado de pNIC, el estado del túnel, el estado de la conexión del hipervisor con el plano de control y el estado de la conexión del hipervisor con el plano de administración.

Mejoras de NSX Edge:

  • Mejora de la comprobación de estado de equilibrador de carga de Edge. Se han agregado tres monitores nuevos de comprobación de estado: DNS, LDAP y SQL.
  • Ahora, puede filtrar las rutas de redistribución en función de LE/GE en la longitud del prefijo de la dirección IP de destino.
  • Compatibilidad con BGP y enrutamiento estático mediante túneles GRE.
  • NAT64 proporciona traducción de IPv6 a IPv4.
  • Conmutación por error más rápida de los servicios de enrutamiento de Edge.
  • Los eventos de enrutamiento generan ahora eventos del sistema en NSX Manager.
  • Mejoras de la resistencia y el rendimiento de la VPN de Capa 3.

 

Instalación, versiones y requisitos del sistema

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 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 o póngase en contacto con su representante del soporte técnico de VMware para obtener más información sobre problemas específicos antes de planificar una actualización.

vSphere

  • Para vSphere 6.0:
    Compatibilidad: versiones 6.0U2 y 6.0U3
    Versión recomendada: 6.0U3. vSphere 6.0U3 soluciona el problema de VTEP duplicados que aparecen en los hosts ESXi después de reiniciar vCenter Server. Consulte el artículo 2144605 de la base de conocimientos de VMware para obtener más información.

  • Para vSphere 6.5:
    Compatibilidad: 6.5a y 6.5U1
    Versión recomendada: 6.5U1. vSphere 6.5U1 soluciona el problema de EAM con tipo OutOfMemory. Consulte el artículo 2135378 de la base de conocimientos de VMware para obtener más información. 

Nota: vSphere 5.5 no es compatible con NSX 6.4.0.
Guest Introspection para Windows Se admiten todas las versiones de VMware Tools. Algunas funciones basadas en Guest Introspection requieren versiones de VMware Tools más recientes:
  • Use VMware Tools 10.0.9 y 10.0.12 para habilitar el componente de controlador de introspección de red opcional de Thin Agent que se incluye con VMware Tools.
  • Actualice a VMware Tools 10.0.8 y a versiones posteriores para resolver el problema relacionado con el bajo rendimiento de las máquinas virtuales tras actualizar VMware Tools en NSX/vCloud Networking and Security (consulte el artículo 2144236 de la base de conocimientos de VMware).
  • Use VMware Tools 10.1.0 y versiones posteriores para garantizar su compatibilidad con Windows 10.
  • Utilice VMware Tools 10.1.10 y versiones posteriores para garantizar su compatibilidad con Windows Server 2016.
Guest Introspection para Linux Esta versión de NSX admite las siguientes versiones de Linux:
  • RHEL 7 GA (64 bits)
  • SLES 12 GA (64 bits)
  • Ubuntu 14.04 LTS (64 bits)

Requisitos del sistema e instalación

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

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

Funciones obsoletas y suspendidas

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

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

  • NSX for vSphere 6.1.x llegó a las etapas de fin de disponibilidad (End of Availability, EOA) y de fin de soporte técnico general (End of General Support, EOGS) el 15 de enero de 2017. (Consulte también el artículo 2144769 de la base de conocimientos de VMware).

  • vCNS Edge ya no es compatible. Debe actualizar a una instancia de NSX Edge antes de actualizar a NSX 6.3 o versiones posteriores.

  • NSX for vSphere 6.2.x llegará a la etapa de fin de soporte técnico general (End of General Support, EOGS) el 20 de agosto de 2018.

Eliminaciones de la API y cambios del comportamiento

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

Nota: Para obtener una lista de problemas conocidos que afectan a la instalación y las actualizaciones, consulte la sección 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.
    • Actualizar a NSX 6.4: NSX 6.4 no es compatible con vSphere 5.5.
    • Actualizar a vSphere 6.5a o a una versión posterior: Al actualizar de vSphere 6.0 to 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.
  • Compatibilidad con servicios de partner: Si su sitio web utiliza servicios de partners de VMware para Guest Introspection o para Network Introspection, consulte la Guía de compatibilidad de VMware antes de realizar la actualización para comprobar que el servicio del proveedor sea compatible con esta versión de NSX.
  • Complemento de Redes y seguridad: Después de actualizar NSX Manager, debe cerrar sesión y volver a iniciarla en vSphere Web Client. Si el complemento de NSX no se muestra correctamente, borre el historial y la memoria caché del explorador. Si el complemento de Redes y seguridad no aparece en vSphere Web Client, restablezca el servidor de vSphere Web Client como se explica en la Guía de actualización de NSX.
  • Entornos sin estado: En las actualizaciones de NSX en un entorno de host sin estado, los VIB nuevos se agregan previamente al perfil de imagen del host durante el proceso de actualización de NSX. Como resultado, el proceso de actualización de NSX en hosts sin estado sigue esta secuencia:

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

    1. Busque la URL nueva de VIB en https://<nsxmanager>/bin/vdn/nwfabric.properties.
    2. Obtenga los VIB de la versión de host ESX requerida desde la URL correspondiente.
    3. Agréguelos al perfil de imagen del host.
       

Notas sobre la actualización de los componentes de NSX

Actualización de NSX Manager

Actualización de Controller

  • El clúster de NSX Controller debe contar con tres nodos del controlador para actualizar a NSX 6.3.3. 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

  • 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"
}

Actualización de Guest Introspection

  • Las máquinas virtuales de Guest Introspection ahora contienen información adicional para identificar los hosts en un archivo XML de la máquina. Al iniciar sesión en la máquina virtual de Guest Introspection, el archivo "/opt/vmware/etc/vami/ovfEnv.xml" debe incluir información para identificar los hosts.

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

16 de enero de 2018: Primera edición. 
17 de enero de 2018: Segunda edición. Se agregaron los problemas resueltos: 1461421, 1499978, 1628679, 1634215, 1716464, 1753621, 1777792, 1787680, 1792548, 1801685 y 1849043.
22 de enero de 2018: Tercera edición. Se agregó el problema conocido 2036024.
24 de enero de 2018: Cuarta edición. Notas actualizadas sobre la actualización.
1 de febrero de 2018: Quinta edición. Se actualizó la información de cumplimiento de FIPS.
22 de febrero de 2018: Sexta edición. Se agregaron los problemas resueltos 1773240, 1839953, 1920574, 1954964 y 1965589. Se agregaron los problemas conocidos 2013820, 2016689, 2017806 y 2026069.
2 de marzo de 2018: Séptima edición. Sección de novedades actualizada.
6 de abril de 2018 Octava edición. Se agregó el problema conocido 2014400. Se agregaron los problemas resueltos 2029693 y 2003453. Se actualizaron los cambios de comportamiento y los desusos.
27 de abril de 2018: novena edición. Se actualizaron los cambios de comportamiento y los desusos.
7 de mayo de 2018: décima edición. Se agregaron los problemas resueltos 1772473 y 1954628. Se agregaron los problemas conocidos 1993691, 2005900 y 2007991.
14 de septiembre de 2018: Undécima edición. Se agregó el problema conocido 2006576.
5 de octubre de 2018: Duodécima edición. Se agregó el problema conocido 2164138.

Problemas resueltos

Los problemas resueltos se agrupan del siguiente modo:

Problemas conocidos resueltos
  • Problema solucionado 1783528: El uso que hace NSX Manager de los recursos de la CPU aumenta el viernes por la noche/el sábado por la mañana

    NSX realiza una sincronización completa con LDAP todos los viernes por la noche. No existe ninguna opción para configurar unidades organizativas o contenedores de Active Directory específicos, por lo que NSX sincroniza todos los objetos relacionados con el dominio proporcionado.

  • Problema solucionado 1801685: No se pueden ver los filtros en ESXi después de actualizar de la versión 6.2.x a la 6.3.0 debido a un error al conectarse al host
    Tras actualizar NSX de la versión 6.2.x a la 6.3.0 y los VIB de clúster a 6.3.0 bits, aunque el estado de la instalación se muestre como correcto y esté habilitado el firewall, el "estado del canal de comunicación" mostrará la conectividad de NSX Manager para el agente firewall y la conectividad de NSX Manager para el agente de plano de control como inactivo. Esto generará errores en la publicación de reglas del firewall y la directiva de seguridad, y provocará que la configuración de VXLan no se envíe a los hosts.
  • Problema solucionado 1780998: NSX Manager conserva solo 100.000 entradas de registro de auditoría en lugar del 1.000.000 de entradas documentadas

    Solo hay disponibles 100.000 entradas de registro en los registros de auditoría.

  • Problema solucionado 1874735: El vínculo "Actualización disponible" ("Upgrade Available") no aparece si el clúster tiene una alarma

    Los usuarios no pueden publicar la nueva especificación del servicio en EAM porque el vínculo no aparece y el servicio no se actualizará.

  • Problema solucionado 1893299: El escaneado ODS de archivos que no sean normales tales como dispositivos de bloqueo o dispositivos de caracteres puede hacer que el sistema se se bloquee o no responda

    ODS escanea únicamente archivos normales y vínculos simbólicos. No tiene acceso a archivos que no sean normales como dispositivos de bloqueo o archivos de caracteres directamente, pero puede acceder a ellos si dichos archivos son el destino de los vínculos simbólicos. El acceso a estos archivos puede hacer, de forma no intencionada, que el sistema se bloquee o no responda, etc.

  • Problema solucionado 1897878: El uso elevado de memoria (y algunas veces de la CPU) en la USVM causa problemas de funcionamiento en las máquinas virtuales del mismo host

    El uso elevado de memoria causa errores de falta de respuesta en las máquinas virtuales al iniciar sesión.

  • Problema solucionado 1882345: El uso de la CPU sigue aumentando con el tiempo hasta llegar al 100% y permanece en dicho porcentaje

    Si la intromisión ARP está habilitada como un mecanismo de detección de IP y el entorno tiene máquinas virtuales con varias direcciones IP por vNIC, el uso de la CPU sigue aumentando hasta llegar al 100%, lo que viene acompañado por una degradación grave del rendimiento. 

  • Problema solucionado 1920343: Se puede crear un certificado de servidor sin una clave privada

    Si los datos de la clave privada aparecen en el contenido del certificado, se ignora la clave privada. 

  • Problema solucionado 1926060: La casilla de verificación Negar origen (Negate source) de la página Firewall > Especificar origen y destino (Specify Source or Destination) se marca aunque haga clic fuera de ella 

    La casilla de verificación Negar origen (Negate source) se selecciona cuando mueve objetos de la lista Objetos disponibles (Available objects) a la lista Objetos seleccionados (Selected objects). 

  • Problema solucionado 1965589: La publicación de borradores DFW generados en versiones anteriores a la 6.4.0 produce un error en la versión 6.4.0.

    Los borradores creados con versiones anteriores a la 6.4 no tienen las secciones de capa 2 con el atributo de marca sin estado. Cuando uno de estos borradores se carga o se publica en la configuración de la versión 6.4, se produce un error porque se supone que las secciones de capa 2 tienen la marca sin estado configurada en true en NSX 6.4 y versiones posteriores. Al no haber atributo, se utiliza el valor predeterminado (false), por lo que se produce un error de validación de la configuración y el borrador no se publica.

Problemas resueltos de NSX Edge y redes lógicas
  • Problema resuelto: Los registros del controlador se desbordan con el puente "Error al agregar/eliminar un registro mac de MacRecrod para una instancia de puente que no existe" ("Fail to add/delete a mac record MacRecord for non-existing bridge instance").

    Cuando se realizan cambios en las particiones, el puente falla al enviar la unión al controlador. Solucionado en 6.4.0

  • Problema solucionado 2014400: El NSX Edge en espera empieza a responder al tráfico IPv6 cuando la función de firewall en Edge está deshabilitada.

    Con IPv6 habilitado en NSX Edge, si una conmutación por error se activa, los dispositivos ascendentes se actualizarán con la MAC del Edge en espera, por lo que el tráfico N-S se puede reenviar a un Edge incorrecto. Solucionado en 6.4.0

     

  • Problema solucionado 1783065: No se puede configurar el equilibrador de carga para el puerto UDP junto con TCP mediante direcciones IPv4 e IPv6 conjuntamente.
    UDP solo admite ipv4-ipv4, ipv6-ipv6 (frontend-backend). Hay un error en NSX Manager que hace que incluso la dirección local de vínculo IPv6 se lea e inserte como dirección IP del objeto de agrupamiento y no se le permite seleccionar el protocolo de IP para utilizarlo en la configuración de LB.

    A continuación se presenta una configuración de LB de muestra que demuestra este problema:
    En la configuración del equilibrador de carga, el grupo "vCloud Connector" se configura con un objeto de agrupamiento (vm-2681) como miembro de grupo. Este objeto contiene tanto direcciones IPv4 como IPv6, que no admite el motor LB L4.

     

    {
              "algorithm" : {
        ...
    },
              "members" : [
        {
            ...  ,
            ...
        }
              ],
              "applicationRules" : [],
              "name" : "vCloud_Connector",
              "transparent" : {
                 "enable" : false
              }
        }

  {
              "value" : [
                 "fe80::250:56ff:feb0:d6c9",
                 "10.204.252.220"
              ],
              "id" : "vm-2681"
            }

     

  • Problema solucionado 1764258: Tráfico bloqueado hasta 8 minutos después de que se produzca un error de HA o una sincronización forzada en NSX Edge configurada con una subinterfaz
    Si se activa un error de HA o inicia una sincronización forzada en una subinterfaz, el tráfico se bloqueará hasta 8 minutos.

     

  • Problema solucionado 1850773: Configuración no válida de los informes NAT de NSX Edge cuando se utilizan varios puertos en la configuración del equilibrador de carga
    Este problema ocurre cada vez que configure un servidor virtual del equilibrador de carga con más de un puerto. Debido a esto, NAT no se podrá administrar mientras exista este estado de configuración para las instancias de NSX Edge afectadas.

     

  • Problema solucionado 1733282: NSX Edge ya no es compatible con las rutas estáticas del dispositivo
    NSX Edge no admite la configuración de rutas estáticas con la dirección de salto siguiente NULL.

     

  • Problema solucionado 1711013: Se tarda aproximadamente 15 minutos en sincronizar la FIB entre el NSX Edge activo y en espera tras reiniciar la máquina virtual en espera.
    Cuando un NSX Edge en espera se desconecta, no se cierra la sesión TCP entre el modo en espera y el activo. El Edge activo detectará que la espera está inactiva tras el error Keepalive (15 minutos). Tras 15 minutos, se establece una nueva conexión de socket con el Edge en espera y la FIB se sincroniza entre el Edge activo y el que está en espera.

     

  • Problema solucionado 1781438: En los dispositivos NSX Edge de DLR o ESG, el servicio de enrutamiento no envía ningún mensaje de error si recibe más de una vez el atributo de ruta BGP MULTI_EXIT_DISC.
    El enrutador de Edge o el enrutador lógico distribuido no envían ningún mensaje de error si reciben el atributo de ruta BGP MULTI_EXIT_DISC más de una vez. Según la sección 5 de RFC 4271, el mismo atributo (atributo del mismo tipo) no puede aparecer más de una vez en el campo Atributos de ruta (Path Attributes) de un mensaje ACTUALIZAR (UPDATE) en particular.

     

  • Problema solucionado 1860583: Evite usar un servidor de sysloggers remoto como FQDN si el DNS no está accesible.
    En una instancia de NSX Edge, si se configuran los servidores de sysloggers remotos mediante FQDN y el DNS no está accesible, es posible que la funcionalidad de enrutamiento se vea afectada. El problema podría no producirse de forma coherente.

     

  • Problema solucionado 1242207: El cambio del ID del enrutador durante el tiempo de ejecución no se refleja en la topología OSPF

    Si se intenta cambiar el ID del enrutador sin deshabilitar OSPF, no vuelve a generarse ningún anuncio sobre el estado del vínculo (LSA) con este ID de enrutador, lo que provoca la pérdida de rutas externas de OSPF.

  • Problema solucionado 1767135: Se producen errores al intentar acceder a los perfiles de aplicaciones y certificados que se encuentran en el equilibrador de carga
    Los usuarios con privilegios de Administrador de seguridad (Security Admin) y alcance de Edge no pueden acceder a los perfiles de aplicaciones y certificados que se encuentran en el equilibrador de carga. vSphere Web Client muestra mensajes de error.
  • Problema solucionado 1844546: La dirección IP configurada asignada al usuario en la interfaz de HA de DLR no funciona.

    No se puede introducir una dirección IP única asignada a un usuario específico para la interfaz de HA de un DLR. Si se introduce más de una dirección IP, se produce un "error interno en el servidor".

  • Problema solucionado 1874782: NSX Edge no se puede administrar debido a un problema al conectar con el bus de mensajes

    Si NSX Edge tiene problemas para conectarse con el bus de mensajes, NSX Manager no podrá cambiar la configuración ni recuperar información de NSX Edge.

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

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

  • Problema solucionado 1499978: Los mensajes de syslog de Edge no llegan al servidor syslog remoto
    Inmediatamente después de la implementación, el servidor syslog de Edge no puede resolver los nombres de host de ningún servidor syslog remoto configurado.
  • Problema solucionado 1916360: La conmutación por error de HA puede fallar debido a que el disco está lleno cuando se instalan menos de 100 enrutadores

    Cuando se instalan más de 100 enrutadores, el demonio vmtools del Edge en espera enviará dos mensajes de advertencia de registro cada 30 segundos. Los registros se guardan en un archivo llamado /var/log/vmware-vmsvc.log, que puede crecer hasta llenar la partición de registros. La rotación de registros no está configurada para este archivo de registros. Cuando esto ocurre, la conmutación por error de HA puede fallar.

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

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

  • Problema solucionado 1716464: El equilibrador de carga NSX no enrutará las máquinas virtuales etiquetadas recientemente con una etiqueta de seguridad (Security).
    Si se implementan dos máquinas virtuales con una etiqueta dada y, a continuación, se configura un LB para enrutar a esa etiqueta, el LB se enrutará correctamente a esas dos máquinas virtuales. Sin embargo, si se implementa una tercera máquina virtual con esa etiqueta, el LB solo enrutará las dos primeras.
  • Problema solucionado 1935204: DLR tarda de 1 a 1,5 segundos en el proceso de resolución de ARP

    Cuando se produce un error en la supresión de ARP, la resolución ARP del DLR local para una máquina virtual que se ejecuta en un host remoto tarda entre 1 y 1,5 segundos. 

  • Problema solucionado 1777792: La conexión de IPSec falla si se establece un endpoint par como "CUALQUIERA" (ANY).
    Cuando la configuración de IPSec de NSX Edge establece un endpoint par remoto como CUALQUIERA (ANY), Edge actúa como un "servidor" IPSec y espera que los pares remotos inicien las conexiones. No obstante, cuando un iniciador envía una solicitud de autenticación utilizando PSK+XAUTH, Edge muestra este mensaje de error: "mensaje de modo principal inicial recibido en XXX.XXX.XX.XX:500, pero no se ha establecido ninguna conexión autorizada mediante policy=PSK+XAUTH" (initial Main Mode message received on XXX.XXX.XX.XX:500 but no connection has been authorized with policy=PSK+XAUTH) e IPSec no se puede establecer.
  • Problema solucionado 1881348: Problema con AS_TRANS (ASN 23456) al configurar el número local del sistema autónomo (ASN) de BGP.

    Al configurar AS_TRANS (ASN 23456) para el número local del sistema autónomo (ASN) de BGP se produce un problema en ESG/DLR y 
    los vecinos BGP no aparecen incluso tras revertir el número del sistema autónomo (ASN) a cualquier número válido.

  • Problema solucionado 1792548: NSX Controller puede quedarse atascado en el mensaje: "Esperando unirse al clúster" (Waiting to join cluster)
    NSX Controller puede quedarse atascado en el mensaje: "Esperando unirse al clúster" ("Waiting to join cluster") (comando de la CLI:show control-cluster status). Esto se produce porque se configuró la misma dirección IP para las interfaces eth0 y breth0 del controlador al mismo tiempo que este aparece. Para comprobarlo, utilice en el controlador el siguiente comando de la CLI: show network interface
  • Problema solucionado 1983497: Aparece una pantalla de color púrpura cuando cambian la conmutación por error del puente y la configuración de este al mismo tiempo

    Cuando se cambian la conmutación por error del puente y la configuración de este al mismo tiempo, es posible que se produzca un interbloqueo y aparezca una pantalla de color púrpura. Las posibilidades de que se produzca un interbloqueo son bajas. 

  • Problema solucionado 1849042/1849043: Se bloquea la cuenta del administrador después de configurar la caducidad de la contraseña en el dispositivo NSX Edge
    Si se configura la caducidad de la contraseña del usuario administrador en el dispositivo NSX Edge, cuando esta caduca, existe un periodo de 7 días durante el cual se le solicitará al usuario que cambie la contraseña cuando inicie sesión en el dispositivo. El error que se produce al cambiar la contraseña puede provocar que se bloquee la cuenta. Además, si la contraseña se cambia cuando se inicia sesión en la solicitud de CLI, es posible que la nueva contraseña no cumpla la directiva de contraseña segura que aplican la IU y REST.
  • Problema solucionado 1982690: El controlador de NSX no almacena la entrada de MAC de la máquina virtual de carga de trabajo en el host ESXi donde se ejecuta la máquina virtual de control del puente L2 activo.

    Es posible que observe una caída del tráfico en todas las máquinas virtuales de carga de trabajo que estén instaladas en el hipervisor en el que se ejecuta la máquina virtual de control del puente activo. 

  • Problema solucionado 1753621: Cuando Edge con AS local y privada envía enrutamientos a pares EBGP, todas las rutas privadas AS se eliminan de las actualizaciones de enrutamiento BGP enviadas.

    NSX for vSphere tiene actualmente una limitación que evita que comparta la ruta AS completa con vecinos eBGP cuando la ruta AS solo contiene rutas AS privadas. Mientras que este es el comportamiento esperado en la mayoría de los casos, existen casos en los que el administrador pueda querer compartir rutas AS privadas con un vecino externo BGP. Esta revisión permite cambiar el comportamiento de la "ruta AS privada" de los pares BGP externos. El comportamiento predeterminado de esta función es "eliminar ASN privado", que está alineado con versiones anteriores de NSX for vSphere.

  • Problema solucionado 1954964: El estado del motor de HA no se actualiza correctamente en ESG en modo de espera tras una recuperación de cerebro dividido

    En algunos casos, después de la recuperación de cerebro dividido, es posible que el estado del motor de configuración de ESG en modo de espera no se actualice correctamente. Se trata de un estado incoherente que puede hacer que los clientes experimenten caídas de tráfico intermitentes.

  • Problema solucionado 1920574: No se pueden configurar subinterfaces para una instancia de Edge

    Se produce un error al crear subinterfaces en Edge con NSX for vSphere 6.3.2/6.3.3 (no se puede publicar la subinterfaz con IP).

  • Problema solucionado 1772473: Los clientes SSLVPN no pueden obtener la IP de ippool

    Los clientes no pueden conectarse a la red privada porque no se asignó ninguna IP de ippool. La IP de ippool se consume en la reconexión automática.

    Los clientes no pueden conectarse a la red privada porque no hay direcciones IP asignadas desde el grupo de IP cuando el cliente se reconecta automáticamente con el servidor. Además, la IP asignada anteriormente al cliente desde el grupo de IP no se limpia.

Problemas de NSX Manager resueltos
  • Problema solucionado 1804116: El enrutador lógico entra en un estado Incorrecto (Bad) en un host que ha perdido la comunicación con NSX Manager.
    Si un enrutador lógico se alimenta o reimplementa en un host que ha perdido la comunicación con NSX Manager (debido a un problema de comunicación del host o a un error en la actualización/instalación de NSX VIB), el enrutador lógico entrará en un estado Incorrecto (Bad) y fallará la operación de recuperación automática continua mediante la sincronización forzada.
  • Problema solucionado 1786515: Un usuario con privilegios "Administrador de seguridad" (Security Administrator) no puede editar la configuración del equilibrador de carga utilizando la IU de vSphere Web Client
    Un usuario con privilegios "Administrador de seguridad" (Security Administrator) para un NSX Edge específico no puede editar la Configuración global del equilibrador de carga (Global Load Balancer Configuration) de ese Edge mediante la IU de vSphere Web Client. Aparece el siguiente mensaje de error: "El usuario no tiene autorización para acceder al objeto Global ni a la función si.service. Compruebe el ámbito de acceso del objeto y los permisos para las funciones de este usuario" ("User is not authorized to access object Global and feature si.service, please check object access scope and feature permissions for the user").
  • Problema solucionado 1801325: Registros y eventos del sistema "Críticos" (Critical) generados en el NSX Manager con un elevado uso de disco o de CPU
    Es posible que aparezcan algunos de los siguientes problemas si tiene un elevado uso de espacio de disco, una renovación de datos del trabajo elevada o una cola de trabajos con gran tamaño en NSX Manager:
    • Eventos del sistema "Críticos" (Critical) en vSphere Web Client
    • Uso elevado de disco en NSX Manager para la partición /common
    • Uso elevado de CPU durante periodos prolongados o intervalos regulares.
    • Impacto negativo en el rendimiento de NSX Manager

    Solución alternativa: Póngase en contacto con el servicio de atención al cliente de VMware. Consulte el artículo 2147907 de la base de conocimientos de VMware para obtener más información.

  • Problema solucionado 1902723: El paquete de archivos de NSX Edge no se elimina del directorio /common/tmp después de cada publicación y llena el directorio /common

    El directorio /common se llena y NSX Manager se queda sin espacio porque el paquete de archivos de NSX Edge (sslvpn-plus config) no se elimina de /common/tmp.

  • Problema solucionado 1954628: La operación de restauración falló después de llenarse el disco /common

    Si se restaura la copia de seguridad en un NSX Manager que tenga el disco /common lleno, la restauración puede fallar. Se notifica el fallo en la página de resumen del dispositivo. NSX Manager tiene un estado inconsistente del que no se puede recuperar.

Problemas de servicios de seguridad resueltos
  • Problema solucionado 2029693: En un entorno de escala DFW (con 65 K y reglas), es posible que los usuarios tengan que esperar más tiempo para publicar reglas de DFW.

    Las reglas de firewall se aplican después de 10-15 minutos tras su publicación. Solucionado en 6.4.0

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

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

    Este problema se produce normalmente en las situaciones siguientes:

    • Después de actualizar de una versión anterior a la versión más reciente de NSX-v.
    • Al sacar un host de un clúster y volver a introducirlo en él.
    • Al mover un host de un clúster a otro.
  • Problema solucionado 1496273: La interfaz de usuario permite la creación de reglas de firewall de NSX de entrada/salida que no se pueden aplicar a las instancias de Edge
    El cliente web, incorrectamente, permite la creación de una regla de firewall de NSX aplicada a una o más instancias de NSX Edge cuando la regla tiene tráfico que se traslada en dirección "de entrada" o "de salida", y cuando PacketType es IPV4 o IPV6. La interfaz de usuario no debería permitir la creación de tales reglas, dado que NSX no puede aplicarlas a las instancias de NSX Edge.
  • Problema solucionado 1854661: En una configuración cross-VC, las reglas del filtro del firewall no muestran el valor del índice si cambia entre diferentes NSX Manager
    Después de aplicar un criterio de filtrado por reglas a un NSX Manager y de cambiar a otro diferente, el índice de reglas muestra el valor "0" para todas las reglas del filtro, en lugar de mostrar la posición real de la regla.
  • Problema solucionado 2000749: El firewall distribuido permanece en estado Publicando (Publishing) con algunas configuraciones de firewall

    El firewall distribuido permanece en estado "Publicando" (Publishing) si tiene un grupo de seguridad que contenga un IPSet con 0.0.0.0/0 como miembro EXCLUDE, un miembro INCLUDE o como parte de una "intersección que contiene membresía dinámica (AND)" [dynamic membership containing Intersection(AND)].

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

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

  • Problema solucionado 1787680: Error al eliminar la sección del firewall universal cuando NSX Manager está en modo de tránsito
    Cuando intenta eliminar una sección del firewall universal de la UI de un NSX Manager en modo de tránsito y publica, se produce un error en la publicación como resultado de que no puede establecer el NSX Manager en modo independiente.
  • Problema solucionado 1773240: El rol de administrador de seguridad no tiene permiso para editar y publicar reglas de redireccionamiento/inserción de servicio

    Si un administrador de seguridad intenta crear, modificar o publicar reglas de inserción de servicio, se producirá un error.

  • Problema solucionado 1845174: Todos los grupos de seguridad desaparecen de la IU una vez que se asigna la directiva de seguridad

    Todos los grupos de seguridad desaparecen de la IU una vez que se asigna la directiva de seguridad.

  • Problema solucionado 1839953: Error de supresión de ARP en las direcciones IP de subinterfaz de máquinas virtuales invitadas

    La resolución de ARP de estas interfaces tarda un poco más de lo habitual (1 segundo) la primera vez.

Problemas conocidos

Los problemas conocidos se dividen del siguiente modo.

Problemas conocidos generales
  • Problema 1931236: En las pestañas de la IU aparece texto del sistema

    En las pestañas de la IU aparece texto del sistema, por ejemplo, "Dashboard.System.Scale.Title" en vez de "Escala de sistema" ("System Scale").

    Solución alternativa: Borrar las cookies del navegador y actualizar el navegador o bien cerrar sesión y volver a iniciarla en vSphere Client.

  • 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 1944031: El monitor DNS utiliza el puerto 53 predeterminado para la comprobación de estado en lugar de utilizar otros puertos

    El monitor de servicio utiliza el puerto de supervisión del miembro del grupo para realizar las comprobaciones de estado en el servidor backend. El monitor DNS utiliza el puerto 53 predeterminado independientemente de cuál sea el puerto de supervisión definido. Si cambia el puerto de escucha del servidor DNS backend a un puerto que no sea el 53, se producirá un error en el monitor DNS.

  • Problema 1874863: No se puede autenticar con una contraseña modificada después de habilitar o deshabilitar el servicio VPN SSL con el servidor de autenticación local

    Cuando el servicio VPN SSL está deshabilitado y se vuelve a habilitar con la autenticación local, los usuarios no podrán iniciar sesión con las contraseñas que se modificaron.

    Consulte el artículo 2151236 de la base de conocimientos de VMware para obtener más información.

  • Problema 1702339: Los escáneres de vulnerabilidad podrían notificar sobre la vulnerabilidad CVE-2016-4049 bgp_dump_routes de Quagga

    Los escáneres de vulnerabilidad podrían notificar sobre la vulnerabilidad CVE-2016-4049 bgp_dump_routes de Quagga en NSX for vSphere. NSX for vSphere usa Quagga, pero la funcionalidad BGP (incluida la vulnerabilidad) no está habilitada. Esta alerta de vulnerabilidad se puede ignorar de forma segura.

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

  • Problema 1926467: El cursor no se ve en la versión 59.0.3071.115 de Chrome en el Administrador de aplicaciones de NSX Manager

    Al abrir el dispositivo de NSX Manager con la versión 59.0.3071.115 de Chrome, no se ve el cursor para introducir el nombre de usuario o la contraseña. Aunque el cursor no se vea, puede introducir sus credenciales. 

    Solución alternativa: Actualizar el navegador Chrome a la versión 61.0.3163.100, 64.0.3253.0 o versiones posteriores. 

  • Problema 2015520: Se produce un error en la configuración del puente cuando el nombre de puente tiene más de 40 caracteres

    Se produce un error en la configuración del puente cuando el nombre de puente tiene más de 40 caracteres.

    Solución alternativa: Al configurar el puente, no se le debe asignar un nombre con más de 40 caracteres.

  • Problema 1934704: No se puede asignar al puente un nombre que no tenga caracteres ascii

    Si configura un nombre de puente en VDR que no tenga caracteres ascii, la configuración del puente no aparecerá en el host y la ruta de acceso de datos del puente no funcionará.

    Solución alternativa: Utilizar caracteres ascii para el nombre del puente.

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

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

  • Problema 2013820: El miembro del grupo de objetos de agrupamiento no se puede compartir con otros grupos que utilicen directivas de filtro de IP diferentes

    El miembro del grupo de objetos de agrupamiento no se puede compartir con otros grupos que utilicen directivas de filtro de IP diferentes.

    Solución alternativa:

    1. Si el miembro del grupo de objetos de agrupamiento se debe compartir entre varios grupos, asegúrese de que todos los grupos usen la misma directiva de filtro de IP.
    2. Utilice la dirección IP del objeto de agrupamiento directamente como miembro del grupo si debe compartirlo con varios grupos que usen directivas de filtro de IP diferentes.
  • Problema 2016689: La aplicación de SMB no se admite para los usuarios de RDSH

    Si crea un regla de firewall de RDSH que bloquea o permite la aplicación de SMB, la regla no se activa.

    Solución alternativa: Ninguna.

  • Problema 2007991: DFW no clasifica como protocolo de Capa 7 el servidor del escritorio remoto (RDP) o las versiones cliente 4.0, 5.0, 5.1, 5.2 y 6.0

    Si el entorno de cliente usa el servidor RDP o las versiones cliente 4.0, 5.0, 5.1, 5.2 o 6.0, la regla de DFW de Capa 7 que usa APP_RDP como servicio no clasifica ni identifica el tráfico RDP como tal. Si se espera que la regla de DFW bloquee el tráfico RDP, es posible que este no se bloquee.

    Solución alternativa: Cree la regla de Capa 4 usando el servicio RDP de Capa 4 para que coincida con el tráfico RDP.

  • Problema 1993691: Si se elimina un host sin eliminarlo primero como nodo de replicación, pueden aparecer entradas antiguas en NSX Manager

    Si un host actúa como un nodo de replicación para HW VTEP y se debe eliminar de su clúster principal, asegúrese primero de que ya no sea un clúster de replicación antes de eliminarlo del clúster. Si esto no se hace, en algunos casos se mantiene su estado como nodo de replicación en la base de datos de NSX Manager, lo que puede provocar errores cuando se manipulen nodos de replicación.

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

  • Problema 2164138: Al preparar un clúster para NSX, el controlador ixgbe se vuelve a cargar en hosts con NIC físicas que ejecutan el controlador ixgbe

    El controlador ixgbe se vuelve a cargar para habilitar la opción RSS (ajuste de escala en lado de recepción) para mejorar el rendimiento de vxlan. Cargar de nuevo el controlador ixgbe causa que los elementos vmnic que lo utilicen se inactiven durante varios segundos y se realice una copia de seguridad. De forma excepcional, se puede producir un error en el controlador ixgbe al volver a cargar, y los elementos vmnics que usen el controlador ixgbe seguirán inactivos hasta que el host ESXi se reinicie.

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

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 2036024: Se bloquea la actualización de NSX Manager en "Verificando archivo cargado" (Verifying uploaded file) debido al uso del disco de la base de datos

    Además, el archivo de registro de actualización vsm-upgrade.log contiene este mensaje: "El uso del disco de la base de datos está al 75 %, cuando debería ser inferior a 70 %" ("Database disk usage is at 75%, but it should be less than 70%"). Puede consultar vsm-upgrade.log en el paquete de soporte técnico de NSX Manager. Acceda a Redes y seguridad (Networking & Security) > Paquete de soporte técnico (Support Bundle) y seleccione que se incluya en los registros de NSX Manager.

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

  • Problema 2033438: vSphere Web Client muestra "No hay disponible ninguna instancia de NSX Manager" (No NSX Manager available) si solo está habilitada la actualización a NSX 6.4.0 y TLS 1.0

    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.

    Solución alternativa: Iniciar sesión en la IU de la web de administración del dispositivo de NSX en https://nsx-mgr-ip/ y habilitar TLS 1.1 y TLS 1.2. De esta forma se reinicia el dispositivo de NSX Manager.

  • Problema 2006028: Es posible que se produzca un problema en la actualización del host si el sistema vCenter Server se reinicia durante la actualización

    Si el sistema vCenter Server asociado se reinicia durante una actualización del host, es posible que se produzca un error en dicha actualización y deje al host en modo de mantenimiento. Aunque haga clic en Resolver (Resolve), el host no saldrá del modo de mantenimiento. El estado del clúster es "No está listo" ("Not Ready").

    Solución alternativa: Sacar manualmente al host del modo de mantenimiento. Haga clic en "No está listo" ("Not Ready") y "Resolver todo" ("Resolve All") en el clúster.

  • Problema 1959940: Error al implementar el formato OVF de NSX Manager mediante ovftool: "Se especificó un nombre OVF no válido (VSMgmt) en la asignación de red"

    A partir de NSX 6.4.0, VSMgmt ya no es un nombre válido para la asignación de red en el OVF del dispositivo y se reemplaza por "Red de administración".

    Solución alternativa: Utilizar "Red de administración" en su lugar. Por ejemplo, en lugar de --net:VSMgmt='VM Network', utilice --net:'Management Network=VM Network'.

  • Problema 2001988: Durante la actualización del clúster de hosts de NSX, el estado de Instalación (Installation) en la pestaña Preparación del host (Host Preparation) alterna entre "no está listo" ("not ready") e "instalando" ("installing") para todo el clúster cuando se está actualizando cada uno de los hosts del clúster

    Durante la actualización de NSX, al hacer clic en "actualización disponible" ("upgrade available") para el clúster preparado de NSX, se activa la actualización del host. Para los clústeres configurados con la opción DRS AUTOMÁTICO COMPLETO (DRS FULL AUTOMATIC), el estado de instalación alterna entre "instalando" ("instaling") y "no está listo" ("not ready"), aunque los hosts se actualicen en segundo plano sin problemas.

    Solución alternativa: Se trata de un problema de la interfaz de usuario y se puede ignorar. Espere a que se actualice el clúster de hosts para continuar.

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

    Solución alternativa: Sacar manualmente el host del modo de mantenimiento. Este problema no se producirá si el host está administrado por la versión 6.5a y posteriores de vCenter Server.

  • Problema 1797929: Canal de bus de mensajes inactivo tras la actualización del clúster de hosts
    Tras una actualización del clúster de hosts, vCenter 6.0 (y versiones anteriores) no genera el evento "reconectar" (reconnect) y, como resultado, NSX Manager no establece la infraestructura de mensajería en el host. Este problema se solucionó en vCenter 6.5.

    Solución alternativa: Vuelva a sincronizar la infraestructura de mensajería de la siguiente manera:
    POST https://<ip>:/api/2.0/nwfabric/configure?action=synchronize

    <nwFabricFeatureConfig>
        <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
        <resourceConfig>
            <resourceId>host-15</resourceId>
        </resourceConfig>
    </nwFabricFeatureConfig>

  • 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 1979457: Si la SVM de GI se elimina o se quita durante el proceso de actualización y con el modo de compatibilidad con versiones anteriores, el firewall de identidad a través de Guest Introspection (GI) no funcionará a menos que se actualice el clúster de GI.

    El firewall de identidad no funcionará y no se podrá ver ningún registro relacionado con el firewall de identidad. La protección del firewall de identidad se suspenderá a menos que se actualice el clúster. 

    Solución alternativa: Actualice el clúster para que todos los hosts utilicen la versión más reciente de la SVM de GI

    o

    habilite Log Scraper para que el firewall de identidad funcione.

  • Problema 2016824: El motor de contexto de NSX no se puede iniciar tras la instalación o actualización de Guest Introspection

    Este problema se produce cuando Guest Introspection (GI) se instala o actualiza antes de que la preparación del host finalice. El firewall de identidad para las máquinas virtuales de RDSH no funcionará si el motor de contexto no está iniciado.

    Solución alternativa: Consultar el artículo 51973 de la base de conocimientos de VMware para obtener más detalles.

  • Problema 2027916: En el coordinador de la actualización puede aparecer que todos los controladores que no se pudieron actualizar se actualizaron correctamente

    En un clúster del controlador con tres nodos, si se produjo un error en el tercer controlador durante la actualización y se elimina, se puede marcar que la actualización del clúster del controlador se realizó correctamente aunque fallara.

    Solución alternativa: Compruebe la pestaña Instalar y actualizar > Administración (Install & Upgrade > Management) y asegúrese de que todos los controladores aparecen como "Actualizados" (Upgraded" antes de actualizar otros componentes (hosts y Edges, entre otros).

Problemas conocidos de NSX Manager
  • Problema 1991125: La agrupación de objetos creada en la sesión 6.3.x del Administrador de reglas de aplicaciones (Application Rule Manager) no se reflejará en el panel de control tras actualizar NSX Manager a la versión 6.4.0

    La agrupación de objetos creada en la sesión 6.3.x del Administrador de reglas de aplicaciones (Application Rule Manager) no se reflejará en el panel de control tras actualizar NSX Manager a la versión 6.4.0.

    Solución alternativa: La agrupación de objetos creada en la sesión 6.3.x del Administrador de reglas de aplicaciones (Application Rule Manager) estará disponible tras actualizar NSX Manager a 6.4.0. La agrupación de objetos estará disponible en la página correspondiente de la sección Agrupar objetos (Grouping Objects).

  • Problema 1892999: No se puede modificar los criterios de selección única, aunque no existan máquinas virtuales conectadas a la etiqueta de seguridad universal

    Si se elimina una máquina virtual conectada a una etiqueta de seguridad universal, un objeto interno que representa la máquina virtual seguirá conectado a esta. Esto ocasiona que el cambio en los criterios de selección universal genere un error que indica que hay etiquetas de seguridad universal que aún están conectadas a las máquinas virtuales.

    Solución alternativa: Elimine todas las etiquetas de seguridad universal y, a continuación, cambie los criterios de selección universal.

Problemas conocidos de NSX Edge y redes lógicas
  • Problema 1983902: En un entorno de instalación a escala, tras reiniciar NSX Manager, netcpad no se conecta inmediatamente a vsfwd

    Esto no afecta a la ruta de acceso a los datos. El sistema se recupera sin intervención tras 13 minutos.

    Solución alternativa: Ninguna

  • Problema 1747978: Las adyacencias OSPF se eliminan con la autenticación MD5 después de la conmutación por error de NSX Edge HA
    En un entorno NSX for vSphere 6.2.4 donde NSX Edge está configurado para HA con el reinicio OSPF configurado y se usa MD5 para la autenticación, se produce un error al iniciar OSPF. Las adyacencias se forman solo después de que caduque el temporizador de inactividad en los nodos de los vecinos OSPF.

    Solución alternativa: Ninguna

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

    Solución alternativa: Ninguna.

  • Problema 1995142: El host no se elimina del clúster de replicación después de eliminarse del inventario de VC

    Si un usuario agrega un host a un clúster de replicación y, a continuación, elimina el host del inventario de VC antes de eliminarlo del clúster, el host heredado permanecerá en el clúster.

    Solución alternativa: Cada vez que se elimina un host, asegúrese antes de que ya se eliminó del clúster de replicación, si hay alguno.

  • Problema 2005973: El MSR de daemon de enrutamiento pierde la configuración de enrutamiento completa tras eliminar algunos túneles gre y posteriormente mediante una sincronización forzada del nodo de Edge desde el plano de administración

    Este problema puede producirse en una instancia de Edge con sesiones BGP mediante túneles GRE. Cuando se eliminan algunos de los túneles GRE y, a continuación, se realiza una sincronización forzada de la instancia de Edge desde el plano de administración, Edge pierde la configuración de enrutamiento completa.

    Solución alternativa: Reiniciar el nodo de Edge.

  • Problema 2015368: El registro de firewall puede causar problemas de memoria insuficiente en determinadas circunstancias

    Cuando el firewall de Edge está habilitado en las configuraciones de gran escala y el registro de firewall está habilitado en algunas o en todas las reglas, es posible, aunque poco corriente, que Edge encuentre un error de memoria insuficiente. Esto se produce con más certeza si las reglas de registro están soportando mucho tráfico. Si se produce un error de falta de memoria, la máquina virtual de Edge se reiniciará automáticamente.

    Solución alternativa: El registro de firewall se recomienda para fines de depuración. A continuación se debe volver a deshabilitar para su uso normal. Para evitar el problema de memoria insuficiente, deshabilite todos los registros de firewall.

  • Problema 2005900: El MSR de daemon de enrutamiento en Edge se bloquea al 100 % de CPU cuando todos los túneles GRE oscilan en una topología de escala ECMP de BGP con iBGP/multisalto de ocho vías

    Este problema puede suceder en una topología de escala en la que iBGP o BGP con multisalto se configura en ESG con varios vecinos que se ejecutan en varios túneles GRE. Cuando varios túneles GRE oscilan, MSR puede bloquearse de forma indefinida al 100 % de CPU.

    Solución alternativa: Reiniciar el nodo de Edge.

Problemas conocidos de los servicios de seguridad
  • Problema 1948648: Los cambios de la pertenencia a un grupo Active Directory (AD) no surten efecto inmediatamente para los usuarios conectados que utilicen las reglas de firewall de identidad de RDSH.

    Se crean reglas de firewall de identidad de RDSH. Cuando el usuario de Active Directory inicia sesión en su escritorio RDS, las reglas de firewall surten efecto. A continuación, el Administrador de AD realiza cambios en la pertenencia a un grupo Active Directory y se realiza una sincronización delta en NSX Manager. Sin embargo, el usuario no ve inmediatamente el cambio en la pertenencia al grupo Active Directory, que no se refleja en las reglas de firewall efectivas del usuario. Este comportamiento es una limitación de Active Directory.

    Solución alternativa: El usuario debe cerrar sesión y volver a iniciarla para que los cambios de la pertenencia a un grupo Active Directory (AD) surtan efecto. 

  • Problema 2017806: El mensaje de error no desparece al agregar miembros a grupos de seguridad utilizados en las secciones del firewall de RDSH sobre directivas de seguridad

    Si se utiliza un grupo de seguridad en las secciones del firewall de RDSH sobre directivas de seguridad, solo podrá agregar miembros de grupo de directorio. Si intenta agregar cualquier miembro que no sean del grupo de directorio, se mostrará el siguiente error:
    El grupo de seguridad está siendo utilizado por Service Composer, Firewall y no se puede modificar ("Security group is being used by service composer, Firewall and cannot be modified")

    El mensaje de error no significa que el grupo de seguridad no se pueda modificar porque se utiliza en las secciones del firewall de RDSH sobre directivas de seguridad.

    Solución alternativa: Ninguna.

  • Problema 2026069: Si se utiliza el cifrado Triple DES como algoritmo de cifrado del servicio de VPN de IPsec de NSX Edge, es posible que se pierdan túneles de IPsec a cualquier sitio de IPsec tras la actualización

    VMware no recomienda el uso de 3DES como algoritmo de cifrado en el servicio de VPN de IPsec de NSX Edge por motivos de seguridad. Sin embargo, está disponible hasta la versión 6.4 de NSX por motivos de interoperabilidad. Debido a las recomendaciones de seguridad, el soporte para este tipo de cifrado se eliminará en la próxima versión de NSX for vSphere. Por lo tanto, le solicitamos que deje de utilizar Triple DES como algoritmo de cifrado y que cambie a una de las claves de cifrado seguras 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.

    Solución alternativa: Modifique el algoritmo de cifrado en la configuración del sitio de IPsec para reemplazar Triple DES por una de las variantes AES admitidas (AES / AES256 / AES-GCM). Por ejemplo, para cada configuración de sitios de IPsec con el algoritmo de cifrado Triple DES, reemplácelo con AES. Actualice también la configuración de IPsec en el endpoint par.

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

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

  • Problema 2018077: Se produce un error en la publicación del firewall cuando la regla tiene el servicio L7 ALG personalizado sin protocolo ni puerto de destino

    Cuando se crea el servicio de Capa 7 mediante la selección de cualquiera las siguientes aplicaciones ALG de Capa 7 (APP_FTP, APP_TFTP, APP_DCERPC o APP_ORACLE) sin proporcionar protocolo ni puerto de destino y, a continuación, dichas aplicaciones se utilizan en las reglas de firewall, se produce un error en la publicación de la regla de firewall.

    Solución alternativa: Proporcionar los valores correspondientes del protocolo y el puerto de destino (TCP/UDP) al crear el servicio de Capa 7 personalizado para los siguientes servicios ALG:

    • APP_FTP: protocolo de puerto 21: TCP
    • APP_TFTP: protocolo de puerto 69: UDP
    • APP_DCERPC: protocolo de puerto 135: TCP
    • APP_ORACLE: protocolo de puerto 1521: TCP
  • Problema 1980551: NSX Manager no es compatible con TLSv1 de forma predeterminada

    Si intenta conectarse a NSX Manager mediante TLSv1, se produce un error. 

    Solución alternativa: Utilizar versiones posteriores de TLS: TLSv1.1 o TLSv1.2. 

    No se recomienda utilizar TLS v1.0 y se prevé su eliminación para versiones posteriores, pero es posible que se habilite para NSX Manager. Consulte "Trabajar con configuración de seguridad" ("Working with Security Settings") en la Guía de API de NSX for vSphere para obtener instrucciones. Tenga en cuenta que al cambiar la configuración de seguridad, NSX Manager se reiniciará. 

  • Problema 2006576: El estado guardado (información de conexión almacenada sobre el tráfico que soportan los filtros de inserción de servicio) se pierde cuando una máquina virtual invitada con filtro de inserción de servicio se mueve de un clúster a otro (suponiendo que ambos clústeres tengan el mismo servicio implementado).

    Las máquinas virtuales invitadas que tengan configuradas reglas de NetX (inserción de servicios) perderán temporalmente esas reglas de NetX si el clúster de destino de una migración con vMotion es distinto al clúster de origen.

    Solución alternativa: Limite la migración con vMotion de la máquina virtual invitada con filtro de inserción de servicio en el clúster.

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

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

check-circle-line exclamation-circle-line close-line
Scroll to top icon