VMware NSX for vSphere 6.4.1 | Publicado el jueves, 24 de mayo de 2018 | Compilación 8599035

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

NSX for vSphere 6.4.1 agrega mejoras de mantenimiento y de uso, 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.1:

Servicios de seguridad

  • Firewall relacionado con el contexto:
    • Soporte adicional de contexto de aplicaciones de Capa 7: SYMUPD (tráfico Symantec LiveUpdate, que incluye definiciones de spyware, reglas de firewall, archivos de firmas de antivirus y actualizaciones de software), MAXDB (conexiones y consultas de SQL realizadas a un servidor MaxDB SQL) y GITHUB (Git basado en Internet o repositorio para controlar la versión y servicio de alojamiento en Internet).
    • Soporte de SO para Identity Firewall: Identity Firewall admite sesiones de usuario en servidores de aplicaciones y escritorios remotos (RDSH) ahora se amplían para incluir Server 2012 con VMware Tools 10.2.5 y Windows 2012 R2 con VMware Tools 10.2.5.

Interfaz de usuario de NSX

  • VMware NSX: actualizaciones de funciones para vSphere Client (HTML):
  • Firewall, mejoras en la interfaz de usuario:
    • Mayor visibilidad: incluye un resumen de estado, una barra de herramientas de acciones y una vista de detalles de membresía de grupos para la tabla del firewall.
    • Creación de reglas eficiente: incluye soporte para acciones masivas, multiselección, reglas de clones y edición directa.
    • Administración eficiente de secciones: se puede arrastrar y soltar, así como insertar de forma posicional las secciones y las reglas. La sección se queda fija al desplazarse.
    • Deshacer operaciones: se puede revertir cambios sin publicar de las secciones y las reglas en el lado cliente de la interfaz de usuario.
    • Configuración de tiempo de espera del firewall: se pueden apreciar los valores de los protocolos a simple vista sin que sean necesarios cuadros de diálogos emergentes.
  • Application Rule Manager, mejoras en la interfaz de usuario:
    • Administración de la sesión: puede ver una lista de sesiones, sus estados (recopilación de datos, análisis completo) y duración correspondientes.
    • Planificación de reglas: puede ver recuentos de resumen de objetos agrupados y las reglas de firewall, así como las recomendaciones de View para las reglas de firewall universales.
  • Mejoras de Agrupar objetos (Grouping Objects):
    • Se mejoró la visibilidad de donde se usa Agrupar objetos (Grouping Objects).
    • Puede ver una lista de los miembros efectivos del grupo en términos de máquinas virtuales, IP, MAC y vNIC.
  • SpoofGuard, mejoras en la interfaz de usuario:
    • Soporte de acciones masivas: puede aprobar o borrar varias IP al mismo tiempo.

Mejoras de NSX Edge

  • Escala del equilibrador de carga: aumenta el soporte de miembros de grupo de LB de 32 a 256.

Funcionamiento y solución de problemas

  • Instalación, mejoras en la interfaz de usuario:
    • Lista de filtros por estado: Todo (All), Instalado (Installed): Correcto (Healthy), Instalado (Installed): Necesita atención (Needs Attention), No instalado (Not Installed)
    • Vista de resumen del clúster: muestra el estado del canal de comunicación.
  • Alarmas sobre la caducidad de los certificados: se generan eventos del sistema y alertas SNMP antes de que caduquen los certificados y hasta ese momento. Se puede configurar el intervalo de tiempo, con un valor predeterminado de 7 días antes del momento de caducidad.
  • Copias de seguridad automáticas antes de actualizar: 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. Consulte Actualizar NSX Manager y Administrar las copias de seguridad de NSX Manager creadas durante la actualización para obtener más información.

Interoperabilidad de soluciones

  • Soporte para vSphere 6.7 Al actualizar a vSphere 6.7, debe instalar primero NSX for vSphere 6.4.1 o una versión posterior, o actualizar a alguna de dichas versiones. Consulte cómo actualizar vSphere en un entorno de NSX en la Guía de actualización de NSX y el artículo 53710 de la base de conocimientos sobre cómo actualizar la secuencia para vSphere 6.7 y los productos compatibles de VMware.

Ediciones de las licencias de NSX

  • Licencias de NSX Data Center: admite las nuevas licencias de NSX Data Center (Standard, Professional, Advanced, Enterprise Plus y Remote Office Branch Office), que se introdujeron en junio de 2018, y sigue admitiendo las claves de licencia anteriores de VMware NSX for vSphere. Consulte el artículo 2145269 de la base de conocimientos de VMware para obtener más información sobre las licencias de NSX.

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. 

  • Para vSphere 6.7
    Compatibilidad: 6.7
    Versión recomendada: 6.7
    Importante: Si va a actualizar una instalación existente de vSphere a vSphere 6.7, no actualice conmutadores distribuidos de vSphere a la versión 6.6. Consulte el artículo 2197754 para obtener más información. 

Nota: vSphere 5.5 no se admite en NSX 6.4.
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.

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

Cambios y eliminaciones en la interfaz de usuario

En NSX 6.4.1, se elimina Service Composer Canvas.

Eliminaciones de la API y cambios del comportamiento

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

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

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

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

Notas sobre la actualización de los componentes de NSX

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 enrutador lógico distribuido

  • Se agrega la validación a NSX 6.4.1 para garantizar que, 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. La interfaz de usuario ya no muestra el vSphere Distributed Switch no admitido.

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

24 de mayo de 2018: Primera edición.
29 de mayo de 2018: Segunda edición. Se agregó el problema conocido 2127813.
8 de junio de 2018: Tercera edición: Se agregaron la información sobre las licencias de NSX Data Center y el problema conocido 2130563.
20 de julio de 2018: Cuarta edición. Se agregó el problema conocido 2147002.
5 de septiembre de 2018: Quinta edición. Se agregaron los problemas conocidos 2186968 y 2183584.
19 de septiembre de 2018: Sexta edición. Se agregó el problema conocido 2197754 y una nota relacionada en la tabla de requisitos del sistema.
5 de octubre de 2018: Séptima edición. Se agregó el problema conocido 2164138.

Problemas resueltos

Los problemas resueltos se agrupan del siguiente modo:

Problemas conocidos resueltos
  • Problema solucionado 1993691, 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.

  • Problema solucionado 1809387: Se eliminó el soporte para el protocolo de transporte de seguridad débil TLS v.10.

    A partir de NSX-v 6.4.1, no se admite TLS v1.0.

  • Problema solucionado 2002679: En un entorno Cross-vCenter NSX con HW VTEP implementado en el tráfico del sitio principal, este entorno puede sufrir una interrupción de red cuando se reinicia el NSX Manager secundario

    En un entorno Cross-vCenter NSX con HW VTEP implementado en el tráfico del sitio principal, este entorno puede sufrir una interrupción de red cuando se reinicia el NSX Manager secundario.

  • Problema solucionado 2065225: Se produce el siguiente error en la instalación de NSX Guest Introspection en un entorno NSX 6.4.0: "un parámetro especificado no es correcto Property.info.key[9]" (a specified parameter is not correct Property.info.key[9])

    Las implementaciones de GI muestran un error incorrecto de instalación y el estado del servicio aparece como desconocido para varios hosts.

  • Problema solucionado 2094364: El proceso USVM no se pudo reiniciar después de un bloqueo porque el proceso watchdog no pudo reiniciar el proceso USVM

    La USVM se encuentra en estado de advertencia después de que el proceso finalice.

  • Problema solucionado 2105632: Las USVM intentan sincronizar la hora con servidores (externos) NTP de Google

    Se modificó el servicio de sincronización de hora para evitar este comportamiento.

  • Problema solucionado 2031099: Se produce el siguiente error EAM en la preparación de hosts de NSX: "El host ya no está en el inventario de vCenter" ("Host is no longer in vCenter inventory")

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

  • Problema solucionado 2064298: No se puede descargar los registros de soporte técnico si el mes contiene una letra acentuada

    Si NSX Manager usa la configuración regional francesa, no se pueden descargar los registros de soporte técnico durante un mes que incluya una letra acentuada en su abreviatura.

  • Problema solucionado 2017141: El usuario del ámbito Edge no puede acceder al certificado (globalroot-0) del ámbito global

    El siguiente mensaje de error aparece cuando el usuario del ámbito Edge intenta acceder a la función del equilibrador de carga de Edge:
    "El usuario no tiene autorización para acceder al objeto Global ni a la función truststore.trustentity_management, compruebe
    el ámbito de acceso a objetos y los permisos para las funciones del usuario" ("User is not authorized to access object Global and feature truststore.trustentity_management, please check object access scope and feature permissions for the user.").

Problemas resueltos de NSX Edge y redes lógicas
  • Problema solucionado 1907141: Se acepta GARP como respuesta válida cuando se envía una solicitud ARP

    Algunos dispositivos antiguos envían GARP como respuesta a la solicitud de ARP. Las direcciones fijas aceptan GARP como una respuesta ARP válida.

  • Problema solucionado 2039443: Cuando se crea DLR sin interfaces, la instancia DLR no se crea en el host; sin embargo, la máquina virtual de control sigue intentando conectarse al host

    Si un DLR se crea sin LIF, la instancia VDR no se crea en el host. En una configuración así, la máquina virtual de control DLR intentará establecer una conexión VMCI, pero esta fallará. Este problema no afecta a la ruta de datos y se puede ignorar.

  • Problema solucionado 2070281: Pérdida de memoria lenta cuando la función DNS está habilitada y la resolución del nombre falla con errores de acceso a la red

    Los registros de Edge se rellenan con errores de resolución de nombre. Después de un tiempo, en los eventos del sistema aparece que el uso de la memora de las máquinas virtuales de Edge es elevado (más del 90 % de uso).

  • Problema solucionado 2084281: El túnel VPN no aparece cuando el tráfico se inicia desde detrás de la ESG una vez agotado el tiempo de espera de inactividad de la VPN

    El túnel VPN sigue inactivo debido a una lógica incorrecta que eliminó las entradas spd de IPSEC.

  • Problema solucionado 2092730: NSX Edge deja de responder con una partición /var/log que usa todo el disco

    /var/log de la puerta de enlace NSX Edge se está llenando en el Edge activo.

Problemas de NSX Manager resueltos
  • Problema solucionado 1984392: Los objetos universales (zona de transporte, UDLR, ULS y los segmentos) no se pueden sincronizar con el NSX Manager secundario

    El subproceso del replicador que replica datos al NSX Manager secundario se bloqueó y no puede procesar nuevas solicitudes.

  • Problema solucionado 2064258: Error al verificar el nombre de NetBIOS

    En 6.4.0, se introdujo un nuevo parámetro en la funcionalidad de sincronización de dominios. Este parámetro es el nombre de NetBIOS, que verifica el backend de NSX. Se produce un error al verificar el nombre de NetBIOS en ciertas estructuras de AD, como en una configuración de confianza especial entre dominios no raíz, conocida como Confianza de acceso directo, y cuando la confianza entre dominios raíz y dominios no raíz es Tree Root.

  • Problema solucionado 1971683: NSX Manager registra un mensaje falso de IP duplicada

    Se mejoró el registro en cuanto a falsos positivos.

  • Problema solucionado 2085654: Si existen criterios dinámicos duplicados en el mismo conjunto (especialmente con el valor = null), falla la actualización de criterios dinámicos

    Se produce un error en NSX Manager al iniciarse después de una actualización. No se puede administrar NSX después de la actualización.

Problemas de servicios de seguridad resueltos
  • Problema solucionado 1991702: En ciertas condiciones, aparece el mensaje de error "No se puede iniciar la recopilación de datos en SG sin máquinas virtuales" ("Unable to start data collection on SG with no VMs")

    Aparece un error al iniciar una sesión de supervisión de endpoints en una SG basada en la identidad que se asigna a un grupo de AD: "No se puede iniciar la recopilación de datos en SG sin máquinas virtuales" ("Unable to start data collection on SG with no VMs").

  • Problema solucionado 2052634: La traducción de los grupos de seguridad anidados con miembros excluidos devuelve un resultado incorrecto

    La regla del firewall bloquea o permite de forma incorrecta el tráfico si se usan grupos de seguridad con miembros excluidos y anidados.

  • Problema solucionado 2089957: La traducción de máquinas virtuales muestra una excepción de puntero nulo que se refiere a un grupo de AD eliminado

    Si se elimina un grupo de AD y existe un grupo de seguridad con referencia al grupo de AD eliminado, Grupo de seguridad (Security Group)-> Traducción de máquina virtual (VM translation) mostrará una excepción de puntero nulo. Se produce un error al publicar la regla.

Problemas de instalación y actualización resueltos
  • Problema solucionado 2035026: Interrupción de red de alrededor de 40-50 segundos en la actualización de Edge

    Durante la actualización de Edge, la interrupción de red se reduce a 10-20 segundos.

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

Problemas conocidos

Los problemas conocidos se dividen del siguiente modo.

Problemas conocidos generales
  • Problema 2197754: Los hosts muestran la pantalla de diagnóstico de color morado cuando vSphere Distributed Switch se actualiza a la versión 6.6

    Si tiene instalado NSX 6.4 y actualiza vSphere Distributed Switch a la versión 6.6, ESXi muestra una pantalla de diagnóstico de color púrpura. Las nuevas instalaciones de vSphere 6.7 con vSphere Distributed Switch 6.6 no se ven afectadas.

    Solución alternativa: Use vSphere Distributed Switch 6.5 o una versión anterior al actualizar a vSphere 6.7.

  • Problema 2130563: Aparece un mensaje de advertencia al asignar la licencia de NSX Data Center: "La licencia seleccionada no admite algunas funciones que están disponibles en los activos con licencias" (The selected license does not support some of the features that are currently available to the licensed assets).

    Si tiene una licencia NSX for vSphere asignada y, a continuación, asigna una licencia de NSX Data Center, verá el siguiente mensaje de advertencia: "La licencia seleccionada no admite algunas funciones que están disponibles en los activos con licencias" (The selected license does not support some of the features that are currently available to the licensed assets). Esto se debe a que las dos licencias definen las funciones de NSX de forma diferente. Si asigna una licencia de una edición que permita las mismas funciones que su licencia actual, puede ignorar este mensaje.

    Consulte el artículo 2145269 de la base de conocimientos de VMware para obtener más información sobre las licencias de NSX.

    Solución alternativa: Compruebe que la nueva licencia admita la función que necesita e ignore el mensaje de advertencia.

  • Problema 2127813: No se puede seleccionar la clave de licencia de NSX ni asignarla a NSX Manager cuando usa vSphere Client (HTML5)

    Si inicia sesión en vSphere Client (HTML5) y agrega una clave de licencia de NSX, no puede asignar la clave desde Licencias (Licenses) > Activos (Assets) > Soluciones (Solutions). La nueva clave de licencia no está visible.

    Solución alternativa: Utilice vSphere Web Client para agregar y asignar licencias.

  • 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 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 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 2147002: Impacto de rendimiento y servicios con Guest Introspection instalado en NSX for vSphere 6.4.1

    El problema se observa cuando tarda mucho tiempo en utilizar vMotion o almacenar las máquinas virtuales de vMotion entre hosts con Guest Introspection habilitado.
    Se observan registros de eventos frecuentes "Mux desconectado" en el archivo vmware.log de la máquina virtual junto con el mensaje de ERROR "PANIC: NamespaceDb.cpp:AccessNamespaceDb():83 Function call to read_key failed" en el syslog del host.

    Solución alternativa: Consulte el artículo 56734 de la base de conocimientos de VMware 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 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 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 2106417: SVM de GI tiene un estado Error (Failed) después de que NSX Manager se actualice de 6.3.0 a 6.4.1

    Si utiliza vCenter Server 6.5 u1 y actualiza NSX Manager de 6.3.0 a 6.4.1, la actualización de SVM de GI puede fallar.

    Solución alternativa: Después de que aparezca el problema, elimine y vuelva a implementar las SVM de GI.

Problemas conocidos de NSX Manager
  • Problema 2088315: Se produce un error en la operación de copia de seguridad de NSX Manager

    Caducó el certificado rabbitmq presente en el archivo de copia de seguridad S01_NSX_00_00_00_Fri23Mar2018. Siga los pasos que se indican a continuación para comprobar el certificado de copia de seguridad.
    openssl enc -md sha512 -d -aes-256-cbc -salt -in S01_NSX_00_00_00_Fri23Mar2018 -out backup.tar -pass 'pass: )' tar -xvf backup.tar
    openssl x509 -enddate -noout -in home/secureall/secureall/.store/.rabbitmq_cert.pem

    El resultado es una fecha de caducidad:
    notAfter=Dec 26 20:20:40 1978 GMT

    Póngase en contacto con el soporte técnico. El soporte debe crear un nuevo certificado.

Problemas conocidos de NSX Edge y redes lógicas
  • 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 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 2186968: No se notifica el IPSet estático a la llamada de API containerset

    Si tiene dispositivos de servicio, NSX puede omitir los conjuntos de direcciones IP al comunicarse con los administradores del servicio de partners.  Esto puede provocar que los firewalls de los partners permitan o rechacen las conexiones de forma incorrecta.

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

  • Problema 2183584: Los grupos de seguridad creados en una sesión del Administrador de reglas de aplicaciones (Application Rule Manager) no aparecen en el menú desplegable de la columna Se aplica a (Applied-to) de la regla recomendada

    Los grupos de seguridad creados en una sesión del Administrador de reglas de aplicaciones (Application Rule Manager) no aparecen en el menú desplegable de la columna Se aplica a (Applied-to) de la regla recomendada.

    Solución alternativa: Consulte el artículo 57837 de la base de conocimientos de VMware para obtener una solución alternativa.

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