VMware NSX 3.2 | 16 DIC 2021 | Compilación 19067070 Compruebe si existen actualizaciones adicionales a las notas de la versión. |
VMware NSX 3.2 | 16 DIC 2021 | Compilación 19067070 Compruebe si existen actualizaciones adicionales a las notas de la versión. |
Las notas de la versión contienen los siguientes temas:
El equipo de VMware NSX ha identificado un problema con la actualización de versiones anteriores a NSX-T Data Center 3.2.0 y ha decidido retirar la versión de las páginas de descarga en favor de NSX-T Data Center 3.2.0.1.
Los clientes que descargaron e implementaron NSX-T Data Center 3.2.0 siguen siendo compatibles, pero se recomienda actualizar a NSX-T Data Center 3.2.0.1.
NSX-T Data Center 3.2.0 es una versión principal que ofrece muchas funciones nuevas en todas las verticales de NSX-T: redes, seguridad, servicios e incorporación. Estas son algunas de las principales mejoras.
Seguridad distribuida independiente del conmutador: Capacidad para extender la microsegmentación a las cargas de trabajo implementadas en redes vSphere.
Seguridad de la puerta de enlace: Identificadores de aplicación de capa 7 mejorados, detección y espacio aislado de malware, filtrado de URL, firewall de ID de usuario, inspección de TLS (vista previa técnica) y servicio de prevención y detección de intrusiones (IDS/IPS).
Seguridad distribuida mejorada: Prevención y detección de malware, IDS/IPS de comportamiento, identidades de aplicaciones mejoradas para el firewall de capa 7.
Integración mejorada con NSX Advanced Load Balancer (anteriormente Avi): Instale y configure NSX ALB (Avi) desde la interfaz de usuario de NSX-T; Migre NSX for vSphere LB a NSX ALB (Avi).
Migración de NSX for vSphere a NSX-T. Mejoras importantes en el coordinador de migración para ampliar la cobertura de las topologías de NSX for vSphere compatibles y proporcionar flexibilidad en las topologías de NSX-T de destino.
Protección mejorada contra la vulnerabilidad Log4j: Se actualizó Apache Log4j a la versión 2.16 para solucionar CVE-2021-44228 y CVE-2021-45046. Para obtener más información sobre estas vulnerabilidades y su impacto en los productos VMware, consulte VMSA-2021-0028.
Además de estas funciones, se agregan muchas otras capacidades en todas las áreas del producto.
Compatibilidad con enlaces de NIC duales en servidores físicos Windows: ahora se admiten conexiones que usan enlaces de NIC física (pNIC) duales en servidores físicos. Esto permite configurar el enlace activo/activo o activo/en espera. Esta función es compatible con VLAN y redes superpuestas.
Directiva de formación de equipos con reconocimiento de NUMA: ahora, NSX admite el procesamiento del tráfico en el mismo nodo de NUMA que las pNIC utilizadas para dejar ESXi. Esta función mejora el rendimiento de la implementación aprovechando las directivas de formación de equipos en varios NUMA.
Nuevas capacidades de ruta de datos mejoradas: el conmutador de ruta de datos mejorada ahora admite las capacidades de firewall distribuido (DFW), equilibrador de carga distribuido (DLB) y creación de reflejo del puerto.
Compatibilidad con el modo de servidor de enrutamiento de EVPN de capa 3: ahora, ESXi puede enviar directamente el tráfico de VXLAN a los enrutadores de tejido del centro de datos omitiendo el nodo de Edge en la ruta de datos. En este modelo de implementación, el SR (enrutador de servicio) de nivel 0 alojado en el nodo de Edge sigue siendo necesario solo para controlar el plano de control, es decir, anunciar los prefijos conectados a través de la familia de direcciones l2vpn de EVPN en el tejido. ESXi ahora admite ECMP para varios enrutadores físicos en el tejido y probar la disponibilidad de los enrutadores con BFD.
ECMP de 5 tuplas en ESXi y KVM: el enrutador distribuido (DR) alojado en ESXi ahora admite el algoritmo de hash de 5 tuplas cuando ECMP está habilitado. Con esta función, el hash se basa en el origen de la dirección IP, el destino de la dirección IP, el protocolo IP, el origen del puerto de capa 4 y el destino del puerto de capa 4. Esto permite una mejor distribución del tráfico entre todos los enrutadores de servicio (SR) disponibles.
Compatibilidad con ARP de proxy en la puerta de enlace de nivel 0 activa/activa: en topologías simples sin necesidad de enrutamiento dinámico, ahora se puede utilizar una puerta de enlace de nivel 0 en modo de alta disponibilidad activa/activa, lo que proporciona un mayor rendimiento.
Compatibilidad con Activo/Activo en SR de nivel 0 para tráfico de multidifusión: ahora NSX admite ECMP de tráfico de multidifusión en varios SR (enrutadores de servicio) de nivel 0, lo que ofrece un mejor rendimiento para el tráfico de multidifusión.
Compatibilidad con UEFI en instancias de Edge nativas: ahora, NSX admite la implementación de nodos de Edge nativos en servidores que se ejecutan en modo UEFI. Esto permite que los nodos de Edge se implementen en un conjunto más amplio de servidores.
El firewall distribuido admite máquinas virtuales implementadas en grupos de puertos distribuidos en conmutadores de VDS: en versiones anteriores, NSX solo podía aplicar funciones de seguridad distribuida para puertos de conmutadores de N-VDS. Ahora permite aprovechar las capacidades de firewall distribuido para redes VLAN basadas en VDS sin tener que convertir el puerto de conmutador en N-VDS.
Compatibilidad con criterios de etiqueta dinámica en grupos de direcciones IP.
Compatibilidad con firewall distribuido para servidores físicos: sistema operativo RedHat Enterprise Linux 8.0.
Adición de más identificadores de aplicación para el uso de firewall de capa 7.
Prevención de malware para firewall distribuido (caso práctico E-O): NSX Distributed Firewall ahora tiene capacidades de detección y prevención de malware de día cero mediante técnicas avanzadas de aprendizaje automático y capacidades de espacio aislado.
Configuración de la sincronización selectiva de AD para IDFW: la configuración de AD del firewall de identidad ahora admite la adición selectiva de usuarios y unidades de usuario.
Estadísticas del firewall de identidad: se ha mejorado el panel de control Información general de seguridad para incluir estadísticas del firewall de identidad para usuarios activos y sesiones de usuario activas.
Compatibilidad del firewall de identidad con el protocolo SMB.
El IDS/IPS distribuido es compatible con las máquinas virtuales implementadas en grupos de puertos distribuidos en VDS.
IDS/IPS distribuido ahora es compatible con la detección y prevención basadas en comportamiento: ahora hay disponible una nueva clase de firmas de IDS tanto en el IDPS distribuido como en Edge. En lugar de intentar identificar comportamientos específicos de malware, estas firmas intentan identificar los comportamientos de red que podrían asociarse a la señal de una infección exitosa. Esto incluye, por ejemplo, la identificación de la comunicación Tor en la red, la presencia de certificados TLS autofirmados en puertos altos o detecciones con estado más sofisticados, como la detección del comportamiento de señalización. Esta clase de firmas se caracteriza por el nivel de gravedad "informativo". Si NSX NDR está habilitado, se aplicará un procesamiento basado en ML adicional en las alertas producidas por estas firmas para dar prioridad a los casos con gran probabilidad de ser anómalos en el entorno supervisado específico.
Conservación y combinación de firmas de VMware y Trustwave: el conjunto de firmas de IDS/IPS de NSX ahora permite acceder a un nuevo conjunto de reglas de IDS desarrollado y seleccionado por VMware para garantizar una eficacia de alta seguridad y minimizar la probabilidad de falsos positivos. El conjunto de reglas combina detecciones desarrolladas por proveedores de terceros, como Trustwave y Emerging Threats, con una colección de firmas desarrolladas por VMware y optimizadas para los motores de NSX IDS.
Control de acceso basado en la identidad del usuario: el firewall de puerta de enlace incluye las siguientes capacidades adicionales de firewall de identidad de usuario:
Para las implementaciones en las que se utiliza Active Directory como sistema de autenticación de usuarios, NSX aprovecha los registros de Active Directory.
Para los demás sistemas de autenticación, NSX ahora puede aprovechar los registros basados en vRealize Log Insight para identificar la identidad del usuario y la asignación de direcciones IP.
Conjunto mejorado de appID de capa 7: las capacidades de firewall de puerta de enlace se han mejorado para identificar una cantidad más completa de aplicaciones de capa 7.
Inspección de TLS para el tráfico entrante y saliente (🔎vista previa técnica, no para implementaciones de producción): cada vez más tráfico se cifra en la red. Con la función de inspección de TLS, ahora puede aprovechar NSX Gateway Firewall para realizar también una inspección profunda de paquetes y servicios de detección y prevención de amenazas para el tráfico cifrado.
Filtrado de URL (incluye categorización y reputación de URL): ahora puede controlar el tráfico enlazado a Internet según la nueva función de filtrado de URL. Esta función le permite controlar el acceso a Internet en función de las categorías de URL y la reputación de las URL. El repositorio de URL, incluidos los datos de categorización y reputación, se actualiza de forma continua para actualizar la protección.
Compatibilidad con el análisis de malware y el espacio aislado: NSX Gateway Firewall ahora proporciona detección de malware conocido y de malware de día cero mediante técnicas avanzadas de aprendizaje automático y capacidades de espacio aislado. Los datos de malware conocidos se actualizan de forma continua. (Consulte el problema conocido 2888658 antes de trabajar en implementaciones de producción activas).
Prevención y detección de intrusiones (🔎vista previa técnica, no para implementaciones de producción): para NSX Gateway Firewall, las capacidades de detección y prevención de intrusiones (IPS) se introducen en un modo de "Vista previa técnica". Puede probar el conjunto de funciones en implementaciones que no sean de producción.
NSX Application Platform: VMware NSX Application Platform es una nueva solución basada en contenedores que se introdujo en NSX-T 3.2.0. Proporciona una arquitectura altamente disponible, resistente y de escalado horizontal para ofrecer un conjunto de servicios de plataforma principales que permite varias funciones nuevas de NSX, como las siguientes:
NSX Intelligence |
NSX Metrics |
NSX Network Detection and Response |
Prevención de malware de NSX |
El proceso de implementación de NSX Application Platform está totalmente orquestado a través de la interfaz de usuario de NSX Manager y requiere un entorno de Kubernetes compatible. Consulte la guía Implementar y administrar VMware NSX Application Platform para obtener más información sobre los requisitos previos y los requisitos de infraestructura para la instalación.
VMware NSX Network Detection and Response correlaciona los eventos de IDPS, malware y anomalía en campañas de intrusión que ayudan a identificar amenazas y actividades malintencionadas en la red.
Correlación en campañas de amenazas en lugar de eventos, lo que permite a los operadores de SOC centrarse en clasificar solo un pequeño conjunto de amenazas procesables.
NSX Network Detection and Response recopila eventos de IDPS desde IDPS distribuido, eventos de malware (solo archivos malintencionados) de puerta de enlace y eventos de anomalías de red de NSX Intelligence.
Los eventos de IDPS de puerta de enlace (vista previa técnica) no se recopilan mediante NSX Network Detection and Response en NSX-T 3.2.
La funcionalidad NSX Network Detection and Response se ejecuta en la nube y está disponible en dos regiones de nube: EE. UU. y UE.
Para obtener más información sobre cómo activar, utilizar, administrar y solucionar los problemas de la función NSX Network Detection and Response, consulte la sección NSX Network Detection and Response de la Guía de administración de NSX-T Data Center.
Alarmas de nivel de servicio mejoradas para VPN: detalles del estado del servicio IPSec.
Detalles de registro adicionales para el seguimiento de paquetes: muestra información de SPI e intercambio para IPSec.
Mejoras de Guest Introspection: Guest Introspection proporciona un conjunto de API en el plano de datos para el consumo dentro del contexto del invitado. Esta mejora garantiza que solo se proporcione este acceso a los usuarios con la autorización adecuada.
Compatibilidad con sistemas operativos adicionales para GI: Guest Introspection ahora es compatible con CentOS 8.2, RHEL 8.2, SLES15 SP1 y Ubuntu 20.04.
Aunque las versiones de NSX anteriores a la 3.2.0 admitían la incorporación de sitios de Local Manager existentes, esta compatibilidad se retrasa a partir de la versión 3.2.0. Se volverá a introducir en una versión posterior de 3.2.
Compatibilidad con la replicación de etiquetas de máquina virtual entre Local Managers: durante la recuperación ante desastres (DR), las máquinas virtuales replicadas se reinician en la ubicación de recuperación ante desastres. Si la directiva de seguridad se basa en etiquetas de máquina virtual de NSX, las máquinas virtuales replicadas en la ubicación de recuperación ante desastres deben tener dichas etiquetas de NSX en el Local Manager remoto en el momento de la recuperación. federación de NSX 3.2 ahora admite la replicación de etiquetas de máquina virtual entre los Local Manager. La directiva de replicación de etiquetas solo se puede configurar a través de la API.
Supervisión de comunicaciones de Federation: la página del administrador de ubicaciones ahora ofrece una vista sobre la latencia y el uso de los canales entre los Global Managers y los Local Managers. Esto proporciona una mejor visibilidad del estado entre los distintos componentes de Federation.
Borradores de firewall: el borrador de las directivas de seguridad ahora está disponible en Global Manager. Esto incluye compatibilidad con borradores automáticos y borradores manuales.
Compatibilidad con LDAP de Global Manager: Global Manager ahora admite la configuración de orígenes LDAP para el control de acceso basado en funciones (RBAC) de forma similar a la compatibilidad con los Local Managers.
Antrea para NSX-T Integración: se agregó la capacidad de definir directivas de red de Antrea desde la interfaz de usuario de firewall distribuido NSX-T. Las directivas se aplican a los clústeres de K8s que ejecutan Antrea 1.3.1-1.2.2 mediante el controlador de interfuncionamiento. También agrega una recopilación de inventario: Los objetos de K8s, como pods, espacios de nombres y servicios, se recopilan en el inventario de NSX-T y se etiquetan para que se puedan seleccionar en las directivas de DFW. Antrea Traceflow ahora se puede controlar desde la página de la interfaz de usuario de NSX-T Traceflow, y se pueden recopilar paquetes de registros de los clústeres de K8s mediante Antrea. No hay requisitos obligatorios para tener el plano de datos de NSX-T habilitado en los nodos del clúster de Antrea de K8s.
Mejoras de agrupamiento: se agregó compatibilidad con objetos de contenedor de Antrea. Se agregó compatibilidad con el operador Not in en los criterios de etiqueta de puerto de segmento. Agrega compatibilidad con el operador AND entre los criterios de pertenencia a grupos que implican segmentos y puertos de segmentos.
La instalación de VMware NSX Advanced Load Balancer (Avi) a través de NSX: VMware NSX Advanced Load Balancer (Avi) ahora se puede instalar a través de la interfaz de usuario de NSX-T Manager, que proporciona un panel único para la instalación de todos los componentes de NSX.
Interfaz de usuario de VMware NSX Advanced Load Balancer (Avi) de inicio cruzado desde la interfaz de usuario de NSX-T Manager: inicie la interfaz de usuario de VMware NSX ALB (Avi) desde elNSX-T Manager para acceder a funciones avanzadas.
Interfaces de usuario avanzadas del equilibrador de carga (Avi) que se muestran en NSX: configure VMware NSX Advanced Load Balancer (Avi) desde NSX Manager.
Migrar el equilibrio de carga desde NSX for vSphere a VMware NSX Advanced Load Balancer (Avi): migre los equilibradores de carga a VMware NSX ALB (Avi) cuando utilice el modelo Traiga su propia topología con el coordinador de migración.
Casos prácticos del equilibrador de carga distribuido (DLB) para vSphere with Kubernetes (K8s)
Compatibilidad para que funcionen juntos el sistema de detección de intrusiones distribuido (DIDS) y DLB.
Compatibilidad con vMotion.
Algoritmo de selección de miembros de grupo de DLB adicionales: Conexión mínima y hash de IP de origen.
Comandos de solución de problemas adicionales.
Equilibrador de carga nativo de NSX-T: las funciones de equilibrio de carga no se agregarán ni mejorarán en el futuro. Las mejoras en la plataforma de NSX-T no se extenderán al equilibrador de carga nativo de NSX-T.
Recomendación sobre el equilibrio de carga
Si utiliza equilibrio de carga en NSX-T, se recomienda migrar a VMware NSX Advanced Load Balancer (Avi), que proporciona un superconjunto de las funcionalidades de equilibrio de carga de NSX-T.
Si adquirió NSX Data Center Advanced, NSX Data Center Enterprise Plus, NSX Advanced o NSX Enterprise, tendrá derecho a la edición Basic de VMware NSX Advanced Load Balancer (Avi), que tiene paridad de funciones con NSX-T LB.
Se recomienda adquirir VMware NSX Advanced Load Balancer (Avi) Enterprise para desbloquear el equilibrio de carga de nivel empresarial, GSLB, análisis avanzados, entrada de contenedores, seguridad de aplicaciones y WAF.
Se recomienda que las nuevas implementaciones con NSX-T Data Center aprovechen VMware NSX Advanced Load Balancer (Avi) con la versión v20.1.6 o posterior y no utilicen el equilibrador de carga de NSX-T nativo.
Para obtener más información:
Página de VMware NSX Advanced Load Balancer (Avi): https://www.vmware.com/products/nsx-advanced-load-balancer.html
Migrar a VMware NSX Advanced Load Balancer (Avi): https://www.vmware.com/products/nsx/migrate-to-advanced-load-balancing.html
Implementar VMware NSX Advanced Load Balancer (Avi) en VCF con Equilibrio de carga avanzados para la solución VCF validada por VMware
Cómo aplicar la licencia de NSX Data Center a VMware NSX Advanced Load Balancer (Avi): https://avinetworks.com/docs/
Ediciones de VMware NSX Advanced Load Balancer (Avi): https://avinetworks.com/docs/21.1/nsx-license-editions/
Compatibilidad ampliada con sistemas operativos en NSX Cloud: NSX Cloud ahora es compatible con los siguientes sistemas operativos, además de los que ya se admiten:
Ubuntu 20.04
RHEL 8.next
Compatibilidad de NSX Cloud con las funciones de seguridad avanzada (capa 7) en PCG (🔎vista previa técnica, no para implementaciones de producción): NSX Cloud ofrece cierta capacidad de seguridad avanzada (capa 7) en la PCG en Azure y AWS, lo que le permite beneficiarse de la seguridad de la capa de aplicaciones para las cargas de trabajo en la nube pública. Puede probar el conjunto de funciones en implementaciones que no sean de producción.
Compatibilidad de NSX Cloud con IDFW para VDI de usuario único (🔎vista previa técnica, no para implementaciones de producción): NSX Cloud ofrece firewall de identidad para ofrecer seguridad basada en usuarios para la implementación de VDI. Podrá asociar a una máquina virtual un perfil de seguridad asignado al usuario conectado, lo que simplificará la administración de seguridad y reforzará la seguridad. Puede probar el conjunto de funciones en implementaciones que no sean de producción.
Comando 'del nsx' para limpiar NSX en un servidor físico o nativo: en continuación con la compatibilidad de la función 'del nsx' en servidores ESX, hay disponible un comando de la CLI del nsx
para eliminar NSX de un servidor físico o nativo que ejecute un sistema operativo Linux. Si tiene un servidor nativo/físico con VIB de NSX en un estado obsoleto y no puede desinstalar NSX de ese host, puede utilizar el comando de la CLI del nsx
para realizar un proceso paso a paso de eliminación de NSX de ese host y volver a un estado limpio que permita volver a instalar NSX.
Análisis de tráfico activo a través de la interfaz de usuario de NSX Manager: la función Análisis de tráfico activo ahora está disponible en la interfaz de usuario NSX Manager, lo que le permite analizar fácilmente los flujos de tráfico activo entre los centros de datos. Estas funciones proporcionan un enfoque unificado de diagnóstico mediante la combinación de Traceflow y la captura de paquetes. Puede realizar ambas acciones en una sola captura: rastrear paquetes activos y realizar una captura de paquetes en el origen. El análisis de tráfico activo ayuda a determinar con precisión los problemas en el tráfico de red y proporciona la capacidad de realizar el análisis en flujos específicos para evitar ruidos.
Creación de reflejo del puerto selectiva: creación de reflejo mejorada con capacidad de filtrado basada en flujos y requisitos de recursos reducidos. Ahora puede centrarse en los flujos pertinentes para solucionar problemas de forma efectiva.
Comprobación de configuración de MTU de tejido: Una comprobación de MTU periódica y a petición estará disponible en la interfaz de usuario de NSX Manager para verificar la configuración de MTU para la red superpuesta; se activaron alertas por faltas de coincidencia de MTU.
Compatibilidad con Traceflow en redes lógicas respaldadas por VLAN: puede realizar Traceflow en una red lógica respaldada por VLAN. Esta función está disponible a través de la API.
Registro mejorado: Registro mejorado mediante la detección y la supresión de mensajes de registro repetitivos emitidos con demasiada frecuencia para evitar que se pierdan o se sobrecarguen mensajes de registro importantes.
Guía de CLI mejorada y comandos adicionales: se introdujo un conjunto de nuevos comandos de CLI asignados con las construcciones de interfaz de usuario (Directiva), como para el segmento de instancia. Esto permite un consumo más simple de la CLI para los usuarios. También se introdujo una guía de CLI completamente reformada para simplificar el consumo.
Límites de capacidad: el panel de control Capacidad ahora tiene en cuenta el tamaño de implementación de NSX Manager para algunos límites de capacidad y puede generar alarmas cuando se supera la capacidad recomendada después de actualizar a NSX-T 3.2. Se recomienda a los clientes que necesiten capacidad adicional actualizar desde un NSX Manager de tamaño mediano a un NSX Manager de tamaño grande, o bien reducir el uso para que siga siendo compatible.
Supervisión de series temporales proporciona la capacidad de recopilar y almacenar métricas durante un período más largo de hasta un año con NSX Application Platform. Las métricas de serie temporal ayudan a supervisar la tendencia en los indicadores clave de rendimiento, se calculan antes y después del análisis, y proporcionan el contexto histórico útil para la solución de problemas. Las métricas de serie temporal están disponibles para el nodo de Edge, las puertas de enlace de nivel 0 y nivel 1, NSX Manager, NSX Application Platform y las funciones de seguridad, que incluyen la inspección de TLS, IDPS y el firewall de puerta de enlace. Estas métricas de serie temporal están disponibles a través de las API de NSX-T y un subconjunto de estas métricas también están disponibles en la interfaz de usuario de NSX Manager.
Eventos y alarmas
Certificados: Actualización del paquete de CA recomendada
Operación: clúster inactivo, clúster no disponible, canal de administración al nodo de Manager inactivo, canal de administración a nodo de Manager inactivo mucho tiempo
Federation: Advertencia de latencia de GM a GM, Advertencia de sincronización de GM a GM, Error de sincronización de GM a GM, Advertencia de latencia de GM a LM, Advertencia de sincronización de GM a LM, Error de sincronización de GM a LM, Restauración de LM mientras la importación de la configuración está en curso, Umbral de ocupación de cola superado
Estado del nodo de transporte: vínculo superior del nodo de transporte inactivo
Firewall distribuidol: recuento de sesiones de DFW alto, error de VMotion de DFW
Edge: se cambió la configuración del nodo de Edge y la configuración de vSphere, la configuración del nodo de Edge no coincide, la configuración de la máquina virtual de Edge vSphere no coincide, la ubicación vSphere de Edge no coincide
Estado de Edge: rendimiento de NIC de ruta de datos de Edge alto, capacidad de proceso de NIC de ruta de datos de Edge muy alta, dominio de error inactivo
VPN: servicio IPSec inactivo
NAT: El uso del puerto SNAT en la puerta de enlace es alto
Equilibrador de carga: No se realizó la configuración del equilibrio de carga debido a falta de memoria
Comprobación de MTU: error de coincidencia de MTU en la zona de transporte, MTU de enrutador global demasiado grande
Comunicación de NSX Application Platform: retraso detectado en el desbordamiento de mensajería, retraso detectado en Rawflow de mensajería, exportador de flujo de TN desconectado
Estado de NSX Application Platform: unas 55 alarmas para supervisar el estado de la plataforma
Personalizar mensajes de inicio de sesión y banners: puede configurar y personalizar el mensaje de inicio de sesión desde NSX Manager y especificar los campos obligatorios que el usuario debe aceptar antes de iniciar sesión.
Mejoras en la búsqueda y los filtros: se ha mejorado la capacidad de filtrado y búsqueda existente en la interfaz de usuario de NSX. Una pantalla inicial muestra las posibles frases de búsqueda y los elementos de búsqueda más recientes. Hay un panel independiente disponible para la "Búsqueda avanzada" que permite a los usuarios personalizar y configurar "Búsquedas". Las consultas de búsqueda ahora exponen información de etiquetas y alarmas.
VPAT: se solucionan las correcciones para reducir la brecha de accesibilidad en el producto.
Topología de NSX: visualiza el tejido subyacente asociado con las puertas de enlace. Esta función proporciona la capacidad de visualizar los clústeres de Edge, la configuración del conmutador de host y recopilar detalles sobre las configuraciones de Edge y de host.
Mejora de la facilidad de uso del selector de objetos en la interfaz de usuario: esta función permite seleccionar varios objetos que se encuentran en la misma categoría. Además, puede seleccionar todos los objetos.
Información general de la seguridad rediseñada: ha rediseñado la página Información general de seguridad para proporcionar una visión holística de las configuraciones de seguridad. Puede ver "Amenazas y respuestas" en diferentes funciones, así como ver la configuración y la capacidad existentes del sistema.
Interfaz de usuario de NSX-T integrada en vCenter: NSX-T ahora se puede instalar y configurar a través de la interfaz de usuario de vCenter con el complemento de vCenter para NSX-T. Esta función solo se admite a partir de vCenter 7.0U3.
Asistente de implementación de NSX-T para casos de uso comunes: cuando se instala a través del complemento de vCenter, NSX-T ahora puede habilitar funciones de NSX-T basadas en casos de uso comunes, lo que permite a los usuarios activar rápidamente funciones de NSX-T aprovechando los asistentes de implementación. Esta versión admite dos asistentes, uno para habilitar las funciones de seguridad de NSX y el otro para habilitar las funciones de redes virtuales de NSX.
Herramienta de promoción de NSX Manager a Directiva: proporciona la capacidad de promocionar la configuración existente de NSX Manager a Directiva sin interrumpir la ruta de datos ni eliminar o volver a crear objetos existentes. Una vez que los objetos de NSX Manager se promueven a Directiva, los objetos de NSX Manager se establecen en solo lectura a través de la interfaz de usuario o la API de Manager y, a continuación, podrá interactuar con los mismos objetos a través de la interfaz de usuario o API de Directiva.
Mejoras en la administración de certificados para la inspección técnica de TLS (🔎vista previa técnica, no para implementaciones de producción): con la introducción de la función de inspección de TLS, la administración de certificados ahora admite la adición y modificación de paquetes de certificación y la capacidad de generar certificados de CA que se utilizarán con la función de inspección de TLS. Además, la interfaz de usuario general de administración de certificados puede transportar modificaciones que simplifican la importación y la exportación de certificados.
Mejoras de alta disponibilidad y escala para la integración de LDAP: la configuración de LDAP ahora admite la configuración de varios servidores LDAP por dominio y la compatibilidad con la "confianza" de varios certificados asociados con diferentes servidores LDAP por dominio.
Mayor escala: hay varios aumentos en la escala admitida para las implementaciones más grandes. Para obtener información detallada sobre cambios de escala, consulte la herramienta de valores máximos de configuración de VMware.
Comprobación de licencia: NSX-T ahora garantiza que los usuarios tengan una licencia válida restringiendo el acceso a las funciones basadas en la edición de la licencia. Los nuevos usuarios pueden acceder únicamente a las funciones que están disponibles en la edición que hayan adquirido. Los usuarios existentes que hayan utilizado funciones que no se encuentren en la edición de su licencia solo pueden ver los objetos; no se les permitirá crear ni editar.
Nuevas licencias: se agregó compatibilidad con el nuevo VMware NSX Gateway Firewall y federación de NSX Add-On, y continúa admitiendo las licencias de NSX Data Center (Standard, Professional, Advanced, Enterprise Plus, Remote Office Branch Office) introducidas en junio de 2018 y las claves de licencia de VMware NSX for vSphere anteriores. Consulte el artículo 52462 de la base de conocimientos de VMware para obtener más información sobre las licencias de NSX.
Migración de VMware Integrated OpenStack: se agregó la capacidad de realizar la migración de NSX for vSphere a NSX-T en entornos de VIO sin interrumpir la representación de OpenStack de los objetos. Esta función requiere la compatibilidad de las capacidades de migración de la versión de VMware Integrated OpenStack que se utiliza.
Traiga su propia topología: el coordinador de migración amplía su modelo para ofrecer la migración entre NSX for vSphere y una topología definida por el usuario en NSX-T. Esto ofrece más flexibilidad para que los usuarios definan su topología de NSX-T y amplía el número de topologías que se pueden migrar de NSX for vSphere a NSX-T.
Esta función solo se puede utilizar para la migración de configuración con el fin de habilitar lift-and-shift o como parte del flujo de trabajo completo que realiza la migración local.
Compatibilidad con la migración de OSPF para topologías fijas: el coordinador de migración admite topologías fijas con OSPF (en lugar de BGP y estático). Esto permite que los usuarios que deseen utilizar topologías fijas (y no BYOT) lo hagan incluso cuando tienen OSP configurado para la conectividad de N/S entre LAG y la parte superior del rack (OSPF entre ESG y DLR ya era compatible y se reemplazó por el enrutamiento interno de NSX-T).
Mayor escala para el coordinador de migración: la escala del coordinador de migración aumenta para abarcar entornos más grandes y acercarse a escala máxima de NSX for vSphere.
Migración de Guest Introspection: se agregó la migración de NSX for vSphere a NSX-T para GI en el coordinador de migración. Puede usar esta función siempre que el proveedor asociado también admita el coordinador de migración.
Migración de IDFW/RDSH: el coordinador de migración ahora admite configuraciones de firewall basadas en identidad.
NSX-T Data Center 3.2 ofrece varias funciones para la vista previa técnica. VMware no admite las funciones de vista previa técnica para un uso de producción. No se han probado completamente y es posible que algunas no funcionen según lo esperado. Sin embargo, estas vistas previas ayudan a VMware a mejorar la funcionalidad actual de NSX-T y a desarrollar mejoras en el futuro.
Para obtener más información sobre estas funciones técnicas de vista previa, consulte la documentación disponible en la Guía de administración de NSX-T Data Center 3.2. La siguiente lista contiene vínculos que describen brevemente estas características técnicas de vista previa. Los temas incluyen Vista previa técnica en sus títulos.
En VMware, valoramos la inclusión y la diversidad. Para promover estos principios entre nuestros clientes, socios y comunidades internas, estamos realizando un esfuerzo en toda la empresa para reemplazar el lenguaje no inclusivo en nuestros productos. Estamos sustituyendo terminología problemática en la interfaz de usuario, la documentación, las API, las CLI y los registros de NSX-T Data Center por alternativas más inclusivas. Por ejemplo, el término no inclusivo lista negra se reemplazó por el término alternativo lista de no permitidos.
Para obtener información sobre compatibilidad y requisitos del sistema, consulte las matrices de interoperabilidad de productos de VMware y la Guía de instalación de NSX-T Data Center.
NSX-T tiene dos métodos para configurar la seguridad y las redes lógicas: El modo Manager y el modo Directiva. La API de Manager contiene URI que comienzan por /api
, y la API de Directiva contiene URI que comienzan por /policy/api
.
Tenga en cuenta que VMware pretende eliminar la compatibilidad de las API de NSX-T Manager y las IU de NSX Advanced en una próxima versión menor o mayor de NSX-T, que se espera estará disponible dentro de menos de un año a partir de la fecha de este mensaje, 16/12/2021. Las API de NSX-T Manager que se van a eliminar se marcan como "obsoletas" en la Guía de la API de NSX Data Center, con instrucciones sobre las API de sustitución.
Se recomienda que las nuevas implementaciones de NSX-T aprovechen las API de directiva de NSX y las URI de directiva de NSX. Para las implementaciones que actualmente aprovechan las API de NSX Manager y las interfaces avanzadas de de NSX, consulte la página Promoción de objetivos de Manager a Directiva y Guía de la API de NSX Data Center para ayudar en la transición.
NSX-T 3.0.0 y versiones posteriores se pueden ejecutar en el conmutador vSphere VDS 7.0 y versiones posteriores. Esto proporciona una integración más estrecha con vSphere y una adopción más sencilla de NSX-T para los clientes que agregan NSX-T a su entorno de vSphere.
Tenga en cuenta que VMware pretende eliminar la compatibilidad del conmutador virtual N-VDS de NSX-T en hosts ESXi en una próxima versión de NSX-T, que se espera estará disponible dentro de menos de un año a partir de la fecha de este mensaje (17 de abril de 2021). N-VDS seguirá siendo un conmutador virtual compatible en KVM, los nodos de NSX-T Edge, los agentes de NSX de nube pública nativa y las cargas de trabajo nativas.
Se recomienda que las nuevas implementaciones de NSX-T y vSphere aprovechen esta estrecha integración y se implementen mediante el conmutador VDS versión 7.0 y posteriores. Además, para las implementaciones actuales de NSX-T que utilizan N-VDS en hosts ESXi, VMware recomienda usar NSX-T en VDS. Para facilitar este proceso, VMware proporcionó una herramienta de migración de conmutadores basada en CLI, disponible por primera vez en NSX-T 3.0.2, así como una herramienta de preparación para la actualización basada en GUI, disponible por primera vez en NSX-T 3.1.1 (consulte la documentación de NSX para obtener más detalles sobre estas herramientas).
En NSX-T 3.2.0, la herramienta de migración de N-VDS a VDS no está disponible. Los clientes que deseen migrar sus cargas de trabajo de N-VDS a VDS en esta versión pueden hacerlo migrando manualmente las cargas de trabajo.
Hay que tener en cuenta las siguientes consideraciones de implementación al pasar de N-VDS a VDS:
Las API de N-VDS y VDS son diferentes, y el tipo de respaldo para las API de interfaz de vmkernel y de máquina virtual para los conmutadores N-VDS y VDS también es diferente. A medida que empiece a usar VDS en su entorno, deberá invocar las API de VDS en lugar de las API de N-VDS. Este cambio del ecosistema deberá realizarse antes de convertir el N-VDS a VDS. Consulte más información en el artículo 79872 de la base de conocimientos. Nota: No hay ningún cambio en las API de N-VDS ni VDS.
VDS se configura a través de vCenter. N-VDS es independiente de vCenter. Como NSX-T se admite en VDS y N-VDS quedará obsoleto en el futuro, NSX-T estará estrechamente ligado a vCenter, y vCenter tendrá que habilitar NSX en entornos vSphere.
Las versiones 3.x son las últimas que admiten distribuciones de KVM y que no son de VIO OpenStack, incluidas, entre otras, RedHat OpenStack Platform, Canonical/Ubuntu OpenStack, SUSE OpenStack Cloud, OpenStack y OpenStack basadas en la comunidad, que no tienen un proveedor específico. Se recomienda a los clientes que utilicen OpenStack que no sean de VIO con NSX que consideren reemplazar sus implementaciones con vRealize Automation o VMware Cloud Director.
Las API del equilibrador de carga de NSX-T se marcarán como obsoletas. Esto se aplica a todas las API que contienen URI que comienzan con /policy/api/v1/infra/lb-
Tenga en cuenta que VMware pretende eliminar la compatibilidad del equilibrador de carga de NSX-T en una próxima versión de NSX-T, que se espera estará disponible dentro de menos de un año a partir de la fecha de este mensaje (16 de diciembre de 2021). Las API de NSX-T Manager que se van a eliminar se marcan como "obsoletas" en la Guía de la API de NSX Data Center.
Se recomienda que las nuevas implementaciones con NSX-T Data Center aprovechen VMware NSX Advanced Load Balancer (Avi) con la versión v20.1.6 o posterior.
El desuso de la API no se aplica al equilibrador de carga distribuido.
Alarmas de comunicaciones de NSX Intelligence reemplazadas por alarmas de comunicación de NSX Application Platform.
Alarmas de estado de NSX Intelligence reemplazadas por alarmas de estado de NSX Application Platform.
DNS: alarma de reenviador deshabilitado.
Servicio de infraestructura: la alarma de estado inactivo del servicio de Edge se cubrirá como parte de la alarma de cambio de estado del servicio de Edge.
Estado del nodo de transporte: la alarma de vínculo superior inactivo de NVDS se reemplazó por la alarma de vínculo superior inactivo del nodo de transporte.
Las API de MP de análisis de tráfico activo se han marcado como obsoletas en NSX-T 3.2.0.
La opción Recuento de paquetes se elimina del análisis de tráfico activo en NSX-T 3.2.0. El análisis de tráfico activo seguirá siendo compatible con el seguimiento y la captura de paquetes.
Se eliminaron los siguientes campos y tipos:
API de Directiva: Campos: count_config
, Tipos: PolicyCountObservation
API de MP: Campos : count_config
, count_results
, Tipos: CountActionConfig
, LiveTraceActionType
(RECUENTO: Una acción no compatible), CountActionArgument
, CountResult
, CountObservation
, BaseCountObservation
Eliminación de las API obsoletas de NSX: las siguientes API han quedado obsoletas hace más de un año y se eliminaron en NSX-T 3.2.0.
API eliminada |
Reemplazo |
---|---|
|
Reemplazado por |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
No hay reemplazo en la API de NSX-T. |
|
|
|
|
|
No hay reemplazo en la API de NSX-T. |
|
|
|
|
|
Flujos de trabajo gestionados de forma diferente mediante las API de perfil de nodo de transporte (TNP) y recopilación de nodos de transporte (TNC) |
|
Flujos de trabajo gestionados de forma diferente mediante las API de perfil de nodo de transporte (TNP) y recopilación de nodos de transporte (TNC) |
|
Flujos de trabajo gestionados de forma diferente mediante las API de perfil de nodo de transporte (TNP) y recopilación de nodos de transporte (TNC) |
|
Flujos de trabajo gestionados de forma diferente mediante las API de perfil de nodo de transporte (TNP) y recopilación de nodos de transporte (TNC) |
|
Flujos de trabajo gestionados de forma diferente mediante las API de perfil de nodo de transporte (TNP) y recopilación de nodos de transporte (TNC) |
|
Flujos de trabajo gestionados de forma diferente mediante las API de perfil de nodo de transporte (TNP) y recopilación de nodos de transporte (TNC) |
|
Flujos de trabajo gestionados de forma diferente mediante las API de perfil de nodo de transporte (TNP) y recopilación de nodos de transporte (TNC) |
|
Flujos de trabajo gestionados de forma diferente mediante las API de perfil de nodo de transporte (TNP) y recopilación de nodos de transporte (TNC) |
|
Flujos de trabajo gestionados de forma diferente mediante las API de perfil de nodo de transporte (TNP) y recopilación de nodos de transporte (TNC) |
|
Flujos de trabajo gestionados de forma diferente mediante las API de perfil de nodo de transporte (TNP) y recopilación de nodos de transporte (TNC) |
|
Utilice |
|
Utilice |
|
Utilice |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
API eliminada después de cambios en la arquitectura interna en NSX-T |
|
API eliminada después de cambios en la arquitectura interna en NSX-T |
|
API eliminada después de cambios en la arquitectura interna en NSX-T |
|
API eliminada después de cambios en la arquitectura interna en NSX-T |
|
API eliminada después de cambios en la arquitectura interna en NSX-T |
|
API eliminada después de cambios en la arquitectura interna en NSX-T |
|
API eliminada de NSX-T Manager debido a que NSX Intelligence ahora está alojado en NSX Application Platform |
|
API eliminada de NSX-T Manager debido a que NSX Intelligence ahora está alojado en NSX Application Platform |
|
API eliminada de NSX-T Manager debido a que NSX Intelligence ahora está alojado en NSX Application Platform |
|
Estas API se utilizaron para configurar Bridge en ESXi, que es una función obsoleta y eliminada. Se admite la creación de puentes y el clúster de Edge se puede configurar en el segmento con perfiles de puente de Edge. (Consulte la documentación de Edge Bridge) |
|
Estas API se utilizaron para configurar Bridge en ESXi, que es una función obsoleta y eliminada. Se admite la creación de puentes y el clúster de Edge se puede configurar en el segmento con perfiles de puente de Edge. (Consulte la documentación de Edge Bridge) |
Eliminación de los campos de API obsoletos de NSX: los siguientes campos de API han quedado obsoletos hace más de un año y se eliminaron en NSX-T 3.2.0. (La API en sí no se eliminará, solo el campo mencionado).
Eliminación de campo de API de zona de transporte:
POST /api/v1/transport-zones
{
"display_name":"tz1",
"host_switch_name":"test-host-switch-1", <<==== WILL BE REMOVED
"host_switch_mode": "STANDARD", <<==== WILL BE REMOVED
"description":"Transport Zone 1",
"transport_type":"OVERLAY"
}
Eliminación del campo API del nodo de transporte para la máquina virtual del nodo de Edge:
POST /api/v1/transport-nodes
POST /api/v1/transport-node-profiles
{
"node_id": "92f893b0-1157-4926-9ce3-a1787100426c",
"host_switch_spec": {
"host_switches": [
{
...
...
"transport_zone_endpoints": [ <<<==== SHOULD BE USED INSTEAD
{
"transport_zone_id": "1b3a2f36-bfd1-443e-a0f6-4de01abc963e"
}
],
}
],
"resource_type": "StandardHostSwitchSpec"
},
"transport_zone_endpoints": [], <<<<=== WILL BE REMOVED
"node_deployment_info": {
"deployment_type": "VIRTUAL_MACHINE",
"deployment_config": {
"vm_deployment_config": {
"vc_id": "23eaf46e-d826-4ead-9aad-ed067574efb7",
"compute_id": "domain-c7",
"storage_id": "datastore-22",
"management_network_id": "network-24",
"hostname": "edge", <-- will be removed
"data_network_ids": [
"network-24"
],
"search_domains": [ "vmware.com" ] <<<<=== WILL BE REMOVED (replacement in out block)
"dns_servers": [ "10.172.40.1" ], <<<<=== WILL BE REMOVED
"enable_ssh": true, <<<<=== WILL BE REMOVED
"allow_ssh_root_login": true, <<<<=== WILL BE REMOVED
"placement_type": "VsphereDeploymentConfig"
},
...
"node_settings": {
"hostname": "edge", <<<<=== This should be used - REPLACEMENT
"search_domains": ["eng.vmware.com" ], <<<<=== This should be used - REPLACEMENT
"dns_servers": [ "10.195.12.31"], <<<<=== This should be used - REPLACEMENT
"enable_ssh": true, <<<<=== This should be used - REPLACEMENT
"allow_ssh_root_login": true <<<<=== This should be used - REPLACEMENT
},
"resource_type": "EdgeNode",
"id": "90ec1776-f3e2-4bd0-ba1f-a1292cc58707",
...
"display_name": "edge", <<<<=== WILL BE REMOVED (replacement in out block)
"_create_user": "admin", <<<<=== WILL BE REMOVED
"_create_time": 1594956232211, <<<<=== WILL BE REMOVED
"_last_modified_user": "admin", <<<<=== WILL BE REMOVED
"_last_modified_time": 1594956531314, <<<<=== WILL BE REMOVED
"_system_owned": false, <<<<=== WILL BE REMOVED
"_protection": "NOT_PROTECTED", <<<<=== WILL BE REMOVED
"_revision": 2 <<<<=== WILL BE REMOVED
},
"failure_domain_id": "4fc1e3b0-1cd4-4339-86c8-f76baddbaafb",
"resource_type": "TransportNode",
"id": "90ec1776-f3e2-4bd0-ba1f-a1292cc58707",
"display_name": "edge", <<<<=== This should be used - REPLACEMENT
"_create_user": "admin", <<<<=== This should be used - REPLACEMENT
"_create_time": 1594956232373, <<<<=== This should be used - REPLACEMENT
"_last_modified_user": "admin", <<<<=== This should be used - REPLACEMENT
"_last_modified_time": 1594956531551, <<<<=== This should be used - REPLACEMENT
"_system_owned": false, <<<<=== This should be used - REPLACEMENT
"_protection": "NOT_PROTECTED", <<<<=== This should be used - REPLACEMENT
"_revision": 1 <<<<=== This should be used - REPLACEMENT
}
Para obtener instrucciones sobre la actualización de los componentes de NSX-T Data Center , consulte la Guía de actualización de NSX-T Data Center.
Se recomienda a los clientes que vayan a actualizar a NSX-T 3.2.0.1 que ejecuten la Herramienta de evaluación de actualización de NSX antes de iniciar el proceso de actualización. Esta herramienta comprueba el estado y la preparación de las instancias de NSX Manager para garantizar que la actualización se realice correctamente.
Consulte developer.vmware.com para usar las API o las CLI de NSX-T Data Center para la automatización.
La documentación de la API está disponible en la pestaña Referencia de la API. La documentación de la CLI está disponible en la pestaña Documentación.
NSX-T Data Center se ha localizado a varios idiomas: alemán, chino simplificado, chino tradicional, coreano, español, francés, inglés, italiano y japonés. Como la localización de NSX-T Data Center utiliza la configuración de idioma del navegador, asegúrese de que la configuración coincida con el idioma deseado.
Fecha de revisión |
Edición |
Cambios |
---|---|---|
16 de diciembre de 2021 |
1 |
Edición inicial. |
3 de enero de 2022 |
2 |
Se agregó una nota a la sección Federation en Novedades. Se agregó el problema conocido 2882574. |
5 de enero de 2022 |
3 |
Se agregó un problema conocido a las secciones Notas para la actualización de esta versión y Problemas conocidos. |
21 de enero de 2022 |
4 |
Se agregó la sección Información importante sobre NSX-T Data Center 3.2.0. Se agregó información sobre la herramienta de evaluación de actualización de NSX en la sección Notas para la actualización de esta versión. Se agregó el problema conocido 2890348. |
4 de febrero de 2022 |
5 |
Compatibilidad del firewall de identidad con el protocolo SMB. |
15 de febrero de 2022 |
6 |
Se agregó una viñeta sobre los límites de capacidad en Novedades. |
22 de febrero de 2022 |
7 |
Se agregó un requisito para implementar NSX Application Platform. |
29 de abril de 2022 |
8 |
Se agregaron los problemas conocidos 2885820, 2871440 y 2945515. Se eliminaron entradas duplicadas para los problemas conocidos 2685550, 2566121 y 2848614. |
5 de mayo de 2022 |
9 |
Se agregaron los problemas conocidos 2875563, 2875667, 2883505, 2914934, 2921704 y 2933905. |
16 de mayo de 2022 |
10 |
Se agregó el problema conocido 2927442. |
6 de junio de 2022 |
11 |
Se agregó el problema conocido 2937810. |
2 de agosto de 2022 |
12 |
Se agregó el problema conocido 2989696. |
24 de agosto de 2022 |
13 |
Se agregó el problema conocido 3015843. |
1 de septiembre de 2022 |
14 |
Se actualizó la información de ubicación de la documentación de VMware NSX Network Detection and Response. |
7 de septiembre de 2022 |
15 |
Se agregó el problema conocido 3012313. |
14 de septiembre de 2022 |
16 |
Se agregó el problema conocido 3025104. |
6 de febrero de 2023 |
17 |
Se agregó una viñeta sobre la funcionalidad adicional del equilibrador de carga distribuido para vSphere en Novedades. |
23 de febrero de 2023 |
18 |
Actualización editorial. |
Problema solucionado 2692344: Si elimina el punto de implementación de Avi, se eliminarán todos los objetos realizados de la directiva, lo que eliminará todas las entidades realizadas del objeto predeterminado de la directiva. Si se agrega un nuevo punto de implementación, no se podrá volver a sincronizar el objeto predeterminado desde el controlador Avi.
No podrá utilizar los objetos predeterminados del sistema después de la eliminación y de volver a crearlas en el punto de implementación de AVIConnectionInfo.
Problema solucionado 2858893: Se produce un error en la limpieza de la implementación del servicio para la implementación basada en clústeres.
Ningún impacto funcional. Error al limpiar el servicio si se intenta eliminar del registro ServiceDefinion con Instancias o ServiceDeployment pendientes. Deberá realizar una limpieza manual/forzada de la base de datos.
Problema solucionado 2557287: Las actualizaciones de TNP realizadas después de la copia de seguridad no se restauran.
No se realizará ninguna actualización de TNP después de hacer una copia de seguridad en un dispositivo restaurado.
Problema solucionado 2679614: Cuando se reemplaza el certificado de API en Local Manager, la interfaz de usuario del Global Manager mostrará el mensaje "Se produjo un error general".
Cuando se reemplaza el certificado de API en Local Manager, la interfaz de usuario del Global Manager mostrará el mensaje "Se produjo un error general".
Problema solucionado 2658687: La API de cambio de Global Manager informa de un error cuando se produce un error en la transacción.
Se produce un error en la API, pero se completa el cambio de Global Manager.
Problema solucionado 2652418: Eliminación lenta cuando se elimina un gran número de entidades.
La eliminación será más lenta.
Problema solucionado 2649499: La creación de reglas de firewall tarda mucho tiempo cuando se crean reglas individuales una detrás de otra.
La API lenta tarda más tiempo en crear reglas.
Problema solucionado 2649240: La eliminación es lenta cuando se elimina un elevado número de entidades mediante las API de eliminación individuales.
El proceso de eliminación tarda mucho tiempo en completarse.
Problema solucionado 2606452: La incorporación está bloqueada cuando se intenta incorporar a través de la API.
Se produce un error en la API de incorporación y aparece el mensaje de error "No se encuentra la zona de transporte predeterminada en el sitio".
Problema solucionado 2587513: La directiva muestra un error cuando se configuran varios rangos de VLAN en el enlace del perfil de puente.
Verá un mensaje de error "Identificadores de VLAN no válidos".
Problema solucionado 2662225: Cuando el nodo de Edge activo se convierte en un nodo de Edge no activo durante el flujo de tráfico de S-N, se experimenta una pérdida de tráfico.
La secuencia S->N actual se está ejecutando en el nodo activo de multidifusión. La ruta preferida en TOR a origen debe ser solo a través del nodo de Edge activo de multidifusión. La puesta en marcha de otra instancia de Edge puede demorar el nodo activo de multidifusión (el rango inferior es el nodo de multidifusión activo). El tráfico S->N actual experimentará una pérdida de hasta cuatro minutos. Esto no afectará a la nueva secuencia si la secuencia actual se detiene y se vuelve a iniciar.
Problema solucionado 2625009: Las sesiones de iBGP entre SR siguen oscilando cuando los enrutadores intermedios o las NIC físicas tienen una MTU menor o igual que el puerto entre SR.
Esto puede afectar a la conectividad entre sitios de las topologías de Federation.
Problema solucionado 2521230: Es posible que el estado de BFD que aparece en ‘get bgp neighbor summary’ no refleje correctamente el estado de la sesión de BFD más reciente.
BGP y BFD pueden configurar las sesiones de forma independiente. Como parte de ‘get bgp neighbor summary’, BGP también muestra el estado de BFD. Si el BGP está inactivo, no procesará ninguna notificación de BFD y continuará mostrando el último estado conocido. Esto podría derivar en mostrar el estado obsoleto de la BFD.
Problema solucionado 2550492: Durante una actualización, se muestra temporalmente el mensaje "Las credenciales son incorrectas o la cuenta especificada se bloqueó" y el sistema se recupera automáticamente.
Mensaje de error transitorio durante la actualización.
Problema solucionado 2682480: Posible alarma falsa para el estado de NCP.
La alarma del estado de NCP puede ser poco confiable, ya que se activa cuando el sistema NCP está en buen estado.
Problema solucionado 2655539: Los nombres de host no se actualizan en la página Administrador de ubicaciones de la interfaz de usuario de Global Manager cuando se actualizan los nombres de host mediante la CLI.
Se muestra el nombre de host anterior.
Problema solucionado 2631703: Cuando se realiza la copia de seguridad o la restauración de un dispositivo con la integración de vIDM, se interrumpirá la configuración de vIDM.
Por lo general, cuando se actualiza o se restaura un entorno, si se intenta restaurar un dispositivo en el que la integración de vIDM está activa y en ejecución, la integración se romperá y tendrá que volver a configurarla.
Problema solucionado 2730109: Cuando la instancia de Edge se está encendiendo, intenta establecer la vecindad OSPF con el elemento del mismo nivel usando su dirección IP de vínculo de enrutador como un routerID de OSPF a pesar de que está presente el bucle invertido.
Después de volver a cargar la instancia de Edge, OSPF selecciona la dirección IP de vínculo inferior (la dirección IP más alta) como router-id hasta que recibe la configuración de router-id de OSPF debido al orden de secuencia de configuración. La entrada de vecino con el router-id más antiguo se convertirá con el tiempo en una entrada obsoleta al recibir OSPF HELLO con el nuevo router-id y caducará después de que caduque el temporizador de inactividad en el elemento del mismo nivel.
Problema solucionado 2610851: Los espacios de nombres, la recopilación de recursos informáticos, el filtro de cuadrícula de servicios de L2VPN pueden no devolver datos de algunas combinaciones de filtros de tipo de recurso.
La aplicación de varios filtros para unos cuantos tipos al mismo tiempo no devolvió resultados, aunque los datos estén disponibles con criterios coincidentes. No se trata de un escenario común y el filtro solo producirá errores en estas cuadrículas para las siguientes combinaciones de atributos de filtro: Para la cuadrícula de espacios de nombres ==> Filtro Nombre de clúster y Nombre de pods. Para la página Topología de red ==> En el servicio L2VPN que aplica un filtro de IP remoto. Para la recopilación de recursos informáticos ==> En el filtro ComputeManager
Problema solucionado 2482580: La configuración de IDFW/IDS no se actualiza cuando un clúster de IDFW/IDS se elimina de vCenter.
Cuando se elimina un clúster con IDFW/IDS habilitado de vCenter, el plano de administración de NSX no recibe notificaciones de las actualizaciones necesarias. Esto da como resultado un recuento correcto de clústeres habilitados para IDFW/IDS. El funcionamiento no se ve afectado. Solo el recuento de clústeres habilitados es incorrecto.
Problema solucionado 2587257: En algunos casos, el paquete PMTU que envía NSX-T Edge se omite al recibir el destino.
Se produce un error en la detección de PMTU y se produce una fragmentación y un reensamblado y una caída de paquetes. Esto da como resultado una caída de rendimiento o una interrupción del tráfico.
Problema solucionado 2622576: Los errores debidos a una configuración duplicada no se propagan correctamente al usuario.
Mientras el proceso de incorporación esté en curso, verá un mensaje de "error de incorporación".
Problema solucionado 2638673: El inventario no detecta las vNIC de SRIOV para máquinas virtuales.
Las vNIC de SRIOV no aparecen en el cuadro de diálogo Agregar nueva sesión de SPAN. No verá las vNIC de SRIOV al agregar una nueva sesión de SPAN.
Problema solucionado 2643749: No se puede anidar un grupo de una región personalizada creada en un sitio específico en el grupo que pertenece a una región específica del sitio creado por el sistema.
No verá el grupo creado en la región personalizada específica del sitio al seleccionar el grupo secundario como miembro del grupo en la región creada por el sistema con la misma ubicación.
Problema solucionado 2805986: No se pueden implementar máquinas virtuales de Edge administradas por NSX-T.
Se produce un error al implementar NSX-T Edge cuando se termina de usar la interfaz de usuario de ESX.
Problema solucionado 2685550: El estado de realización de la regla de firewall siempre se muestra como "En curso" cuando se aplica a los segmentos de puente.
Cuando se aplican reglas de firewall a un NSGroup que contiene segmentos enlazados como uno de sus miembros, el estado de realización siempre aparece como en curso. No podrá comprobar el estado de realización de las reglas de firewall que se aplican a los segmentos de puente.
Problema 3025104: Host que muestra el estado "Error" cuando la restauración se realiza en una IP diferente y el mismo FQDN.
Cuando la restauración se realiza usando diferentes direcciones IP de nodos de MP que utilizan el mismo FQDN, los hosts no pueden conectarse a los nodos de MP.
Solución alternativa: Actualice la memoria caché de DNS para el host. Use el comando /etc/init.d/nscd restart.
Problema 3012313: No se puede actualizar de Prevención de malware de NSX o NSX Network Detection and Response de la versión 3.2.0 a NSX ATP 3.2.1 o 3.2.1.1.
Después de que NSX Application Platform se actualice de NSX 3.2.0 a NSX ATP 3.2.1 o 3.2.1.1, se produce un error al actualizar las funciones Prevención de malware de NSX (MP) o NSX Network Detection and Response (NDR) con uno o varios de los siguientes síntomas.
La ventana Actualizar interfaz de usuario muestra un estado FAILED
para los pods de NSX NDR y cloud-connector.
Para una actualización de NDR NSX, algunos pods con el prefijo nsx-ndr
tienen el estado ImagePullBackOff
.
Para una actualización de MP NSX, algunos pods con el prefijo cloud-connector
tienen el estado ImagePullBackOff
.
Se produce un error al actualizar después de hacer clic en ACTUALIZAR, pero las funcionalidades NSX MP y NSX NDR siguen funcionando igual que antes de que se iniciara la actualización. Sin embargo. Es posible que NSX Application Platform se vuelva inestable.
Solución alternativa: Consulte el artículo 89418 de la base de conocimientos de VMware.
Problema 2989696: Las copias de seguridad programadas no se inician después de la operación de restauración de NSX Manager.
La copia de seguridad programada no genera copias de seguridad. Las copias de seguridad manuales continúan funcionando.
Solución alternativa: Consulte el artículo 89059 de la base de conocimientos.
Problema 3015843: El identificador de registro de paquetes de DFW cambió en NSX-T 3.2.0 y no se mencionó en las notas de la versión.
No se pueden ver los registros de paquetes de DFW con el identificador de registro utilizado en versiones anteriores.
Los siguientes campos syslog de NSX-T se cambiaron para ajustarse al cumplimiento de RFC:
FIREWALL_PKTLOG
se cambió a FIREWALL-PKTLOG
DLB_PKTLOG
se cambió a DLB-PKTLOG
IDPS_EVT
se cambió a IDPS-EVT
nsx_logger
se cambió a nsx-logger
Dado que estos cambios se realizaron para ajustarse al cumplimiento de RFC, no está previsto que en versiones futuras de NSX que reviertan a la estructura de registros de versiones anteriores.
Problema 2355113: No se admiten las máquinas virtuales de carga de trabajo que ejecutan RedHat y CentOS en instancias de redes aceleradas de Azure.
En Azure, cuando se habilitan las redes aceleradas en sistemas operativos basados en RedHat o CentOS y con el agente NSX instalado, la interfaz de Ethernet no obtiene una dirección IP.
Solución alternativa: Deshabilite las redes aceleradas para los sistemas operativos basados en RedHat y CentOS.
Problema 2283559: Las API del plano de administración /routing-table y /forwarding-table devuelven un error si la instancia de Edge tiene más de 65.000 rutas para RIB y más de 100.000 rutas para FIB.
Si la instancia de Edge tiene más de 65.000 rutas para RIB y más de 100.000 rutas para FIB, la solicitud del plano de administración a la instancia de Edge tarda más de 10 segundos y hace que el tiempo de espera se agote. Estas API son de solo lectura y tienen impacto solo si es necesario descargar las más de 65.000 rutas para RIB y más de 100.000 rutas para FIB mediante una API/interfaz de usuario.
Solución alternativa: Existen dos formas de recuperar rutas de RIB/FIB. Estas API admiten opciones de filtrado en función de los prefijos de red o del tipo de ruta. Utilice estas opciones para descargar las rutas que sean de su interés. Compatibilidad de CLI en caso de que se necesite toda la tabla de FIB/RIB y no haya tiempo de espera para ello.
Problema 2693576: El nodo de transporte muestra "Error en la instalación de NSX" después de actualizar la KVM RHEL 7.9 a RHEL 8.2.
Después de actualizar RHEL 7.9 a la versión 8.2, faltan las dependencias nsx-opsagent y nsx-cli. El host se marca como error de instalación. El error no se puede resolver desde la interfaz de usuario: No se pudo instalar el software en el host. Dependencias sin resolver: [PyYAML, python-mako, python-netaddr, python3]
Solución alternativa: Instale manualmente los VIB de NSX RHEL 8.2 después de actualizar el sistema operativo del host y, a continuación, resuélvalo desde la interfaz de usuario.
Problema 2628503: La regla de DFW permanece aplicada incluso después de eliminar de forma forzada nsgroup de Manager.
Solución alternativa: No elimine de forma forzada un nsgroup que siga siendo utilizado por una regla de DFW. En su lugar, asegúrese de que el nsgroup esté vacío o elimine la regla de DFW.
Problema 2684574: Si la instancia de Edge tiene más de 6000 rutas para la base de datos y las rutas, se agotará el tiempo de espera de la API de Directiva.
Estas API de Directiva para la base de datos OSPF y las rutas OSPF devuelven un error si Edge tiene más 6000 rutas: /tier-0s/<tier-0s-id>/locale-services/<id-servicio-local>/ospf/routes /tier-0s/<tier-0s-id>/locale-services/<id-servicio-local>/ospf/routes?format=csv /tier-0s/<tier-0s-id>/locale-services/<id-servicio-local>/ospf/database /tier-0s/<tier-0s-id>/locale-services/<id-servicio-local>/ospf/database?format=csv Si la instancia de Edge tiene más de 6000 rutas para la base de datos y las rutas, se agota el tiempo de espera de la API de directiva. Esta es una API de solo lectura y afecta solo si se utiliza la API o la interfaz de usuario para descargar más de 6000 rutas para la base de datos y las rutas de OSPF.
Solución alternativa: Utilice los comandos de la CLI para recuperar la información de la instancia de Edge.
Problema 2663483: NSX Manager de un solo nodo se desconectará del resto del entorno de federación de NSX si reemplaza el certificado de APH-AR en ese NSX Manager.
Este problema solo se produce con federación de NSX y con clústeres de NSX Manager de un solo nodo. NSX Manager de un solo nodo se desconectará del resto del entorno de federación de NSX si reemplaza el certificado de APH-AR en ese NSX Manager.
Solución alternativa: La implementación de clústeres de NSX Manager de un solo nodo no está admitida, por lo que debe tener un clúster de NSX Manager de tres nodos.
Problema 2636771: La búsqueda puede devolver un recurso cuando un recurso etiquetado con varios pares de etiquetas, etiqueta y ámbito coincide con cualquier valor de etiqueta y ámbito.
Esto afecta a la consulta de búsqueda con la condición en la etiqueta y el ámbito. El filtro puede devolver datos adicionales si la etiqueta y el ámbito coinciden con cualquier par.
Solución alternativa: Ninguna.
Problema 2668717: Se puede observar una pérdida de tráfico intermitente en el enrutamiento este-oeste entre las redes creadas por vRA conectadas a segmentos que comparten el nivel 1.
En los casos en los que vRA crea varios segmentos y se conecta a una ESG compartida, V2T convertirá dicha topología en un nivel 1 compartido conectado a todos los segmentos del lado compartido de NSX-T. Durante la ventana de migración del host, se puede observar una pérdida de tráfico intermitente para el tráfico este-oeste entre las cargas de trabajo conectadas a los segmentos que comparten el nivel 1.
Solución alternativa: Ninguna.
Problema 2490064: No se puede deshabilitar VMware Identity Manager con "LB externo" activado.
Después de habilitar la integración de VMware Identity Manager en NSX con "LB externo", si intenta deshabilitar la integración desactivando "LB externo", después de un minuto, volverá a aparecer la configuración inicial y se sobrescribirán los cambios locales.
Solución alternativa: Al intentar deshabilitar vIDM, no desactive la marca "LB externo". Desactive solo la integración de vIDM. Esto hará que la configuración se guarde en la base de datos y se sincronice con los demás nodos.
Problema 2526769: Se produce un error al restaurar un clúster de varios nodos.
Cuando se inicia una restauración en un clúster de varios nodos, se produce un error y es necesario volver a implementar el dispositivo.
Solución alternativa: Implemente una nueva configuración (un clúster de nodo) e inicie la restauración.
Problema 2534933: No se pueden aplicar los certificados que tienen CDP (puntos de distribución de CRL) basados en LDAP como certificados de clúster/Tomcat.
No puede usar certificados firmados por una entidad de certificación que tengan CDP de LDAP como certificado de clúster/Tomcat.
Solución alternativa: Existen dos opciones.
Utilice un certificado que tenga CDP basado en HTTP.
Deshabilite la comprobación de CRL mediante la API PUT https://<manager>/api/v1/global-configs/SecurityGlobalConfig (en la carga útil de PUT, asegúrese de que "crl_checking_enabled" sea false).
Problema 2566121: Aparece un mensaje de error incorrecto que indica que algunos componentes del dispositivo no funcionan correctamente cuando el servidor está sobrecargado.
Cuando se realizan demasiadas llamadas API a NSX, la interfaz de usuario/API muestra el error "Algunos componentes del dispositivo no funcionan correctamente" en lugar de "El servidor está sobrecargado".
Solución alternativa: Ninguna.
Problema 2613113: Si la incorporación está en curso y se lleva a cabo la restauración del Local Manager, el estado del Global Manager no cambiará de IN_PROGRESS.
La interfaz de usuario muestra IN_PROGRESS en el Global Manager para la incorporación de Local Manager. No se puede importar la configuración del sitio restaurado.
Solución alternativa: Reinicie el clúster de Global Manager, un nodo a la vez.
Problema 2690457: Cuando se une un MP a un clúster de MP donde publish_fqdns está configurado en el clúster de MP y donde el servidor DNS externo no está configurado correctamente, es posible que el servicio Proton no se reinicie correctamente en el nodo de unión.
El administrador que se está uniendo no funcionará y la interfaz de usuario no estará disponible.
Solución alternativa: Configure el servidor DNS externo con las entradas de DNS directas e inversas para todos los nodos de Manager.
Problema 2574281: La directiva solo permitirá un máximo de 500 sesiones de VPN.
Las notificaciones de NSX admiten 512 sesiones de VPN por instancia de Edge en el factor de forma grande. Sin embargo, debido a que la directiva asocia automáticamente las directivas de seguridad, la directiva solo permitirá un máximo de 500 sesiones de VPN. Tras configurar la sesión de VPN número 501 en el nivel 0, se muestra el siguiente mensaje de error: {'httpStatus': 'BAD_REQUEST', 'error_code': 500230, 'module_name': 'Policy', 'error_message': 'GatewayPolicy path=[/infra/domains/default/gateway-policies/VPN_SYSTEM_GATEWAY_POLICY] has more than 1,000 allowed rules per Gateway path=[/infra/tier-0s/inc_1_tier_0_1].'}
Solución alternativa: Utilice las API del plano de administración para crear sesiones de VPN adicionales.
Problema 2658092: Se produce un error en la incorporación cuando NSX Intelligence está configurado en el Local Manager.
La incorporación genera un error de identidad de entidad de seguridad y no puede incorporar un sistema con un usuario de identidad de entidad de seguridad.
Solución alternativa: Cree un usuario de identidad de entidad de seguridad temporal con el mismo nombre de identidad de entidad de seguridad que utiliza NSX Intelligence.
Problema 2639424: Se producirá un error al corregir un host en un clúster de vLCM con implementación basada en host después al llegar al 95 % del progreso de corrección.
El progreso de corrección de un host se bloqueará en el 95 % y, a continuación, se producirá un error después de que se complete el tiempo de espera de 70 minutos.
Solución alternativa: Consulte el artículo 81447 de la base de conocimientos de VMware.
Problema 2636420: El host pasará al estado "Instalación de NSX omitida" y el clúster al estado "Error" después de la restauración si se ejecuta la acción "Quitar NSX" en el clúster después de la copia de seguridad.
Se mostrará "Instalación de NSX omitida" para el host.
Solución alternativa: Después de la restauración, deberá volver a ejecutar el comando "Quitar NSX" en el clúster para alcanzar el estado que había después de la copia de seguridad (estado sin configurar).
Problema 2558576: Las versiones de Global Manager y Local Manager de una definición de perfil global pueden ser diferentes y pueden tener un comportamiento desconocido en Local Manager.
Los perfiles de inundación, sesión o DNS global creados en Global Manager no se pueden aplicar a un grupo local desde la interfaz de usuario, pero se pueden aplicar desde la API. Por lo tanto, un usuario de API puede crear accidentalmente asignaciones de vinculación de perfiles y modificar la entidad global en Local Manager.
Solución alternativa: Utilice la interfaz de usuario para configurar el sistema.
Problema 2491800: No se comprueba periódicamente la validez de los certificados SSL del canal AR, lo que podría derivar en el uso de un certificado caducado/revocado para una conexión existente.
La conexión estaría usando un SSL caducado/revocado.
Solución alternativa: Reinicie APH en el nodo Manager para activar una reconexión.
Problema 2561988: Todas las sesiones de IKE/IPSEC se interrumpen temporalmente.
La interrupción del tráfico se verá durante algún tiempo.
Solución alternativa: Modifique los endpoints locales en fases en lugar de todos al mismo tiempo.
Problema 2584648: La conmutación de la puerta de enlace principal para la puerta de enlace T0/T1 afecta a la conectividad en dirección norte.
El tiempo de conmutación por error de la ubicación provoca interrupciones durante unos segundos y puede afectar la conmutación por error o la prueba de conmutación por recuperación de la ubicación.
Solución alternativa: Ninguna.
Problema 2636420: El perfil de nodo de transporte se aplica a un clúster en el que se llama a "eliminar nsx" después de la copia de seguridad.
Los hosts no están en estado preparado, pero el perfil de nodo de transporte aún se aplica en el clúster.
Solución alternativa: Después de la restauración, vuelva a ejecutar "Quitar NSX" en el clúster para alcanzar el estado que había después de la copia de seguridad (estado sin configurar).
Problema 2687084: Después de actualizar o reiniciar, la API de búsqueda puede devolver el error 400 con el código 60508, "Volver a crear índices, esto puede tardar algún tiempo."
Según la escala del sistema, la API de búsqueda y la interfaz de usuario no se podrán utilizar hasta que se complete la reindizado.
Solución alternativa: Ninguna.
Problema 2782010: La API de directiva permite cambiar vdr_mac/vdr_mac_nested incluso cuando "allow_cha changes_vdr_mac_in_use" es false
La dirección MAC de VDR se actualizará en TN incluso si allow_changing se establece en false. El error no se envía.
Solución alternativa: Vuelva a cambiar la dirección MAC de VDR al valor anterior si no tenía la intención de cambiar el campo.
Problema 2791490: Federation: No se pueden sincronizar los objetos con el Global Manager (GM) en espera después de cambiar la contraseña de GM en espera.
No se puede observar el GM activo en el administrador de ubicaciones del GM en espera, ya sea cualquier actualización del GM activo.
Solución alternativa: Solicite una sincronización forzada en la interfaz de usuario del GM en espera.
Problema 2799371: Las alarmas de IPSec para VPN de Capa 2 no se borran aunque las sesiones de VPN de Capa 2 e IPSec estén activas.
Sin impacto funcional, excepto que se ven alarmas abiertas innecesarias.
Solución alternativa: Resolver alarmas manualmente.
Problema 2838613: Para versiones de ESX anteriores a la 7.0.3, la funcionalidad de seguridad de NSX no está habilitada en VDS actualizado de la versión 6.5 a una versión superior después de la instalación de seguridad en el clúster.
Las funciones de seguridad de NSX no están habilitadas en las máquinas virtuales conectadas al VDS actualizado de 6.5 a una versión posterior (6.6 o superior), donde se admite la función NSX Security en vSphere DVPortgroups.
Solución alternativa: Después de actualizar VDS, reinicie el host y encienda las máquinas virtuales para habilitar la seguridad en las máquinas virtuales.
Problema 2839782: no se puede actualizar de NSX-T 2.4.1 a 2.5.1 porque la entidad de CRL es grande, y Corfu impone un límite de tamaño en la versión 2.4.1, lo que impide que la entidad de CRL se cree en Corfu durante la actualización.
No se puede actualizar.
Solución alternativa: Reemplace el certificado por un certificado firmado por otra CA.
Problema 2851991: Se produce un error en IDFW si el grupo de directivas con el grupo de AD también tiene un grupo de origen vacío anidado.
Se produce un error en IDFW si el grupo de directivas con el grupo de AD tiene un grupo de origen vacío anidado.
Solución alternativa: Elimine el grupo secundario vacío.
Problema 2852419: Aparece un mensaje de error cuando la ruta estática se configura con el próximo salto de IPv4/v6 no local con varios valores de ámbito.
Se rechazará la API de ruta estática con IP de próximo salto no local que tenga varios valores de ámbito.
Solución alternativa: Cree varios próximos saltos en lugar de varios valores de ámbito y asegúrese de que cada próximo salto tenga una dirección IP diferente.
Problema 2853889: Al crear la configuración de tenant de EVPN (con asignación de vlan-vni), se crean segmentos secundarios, pero el estado de realización del segmento secundario pasa al estado de error durante unos 5 minutos y se recupera automáticamente.
La configuración del tenant de EVPN tarda 5 minutos.
Solución alternativa: Ninguna. Espere 5 minutos.
Problema 2854139: Adición/eliminación continua de rutas BGP en RIB para una topología en la que el SR de nivel 0 en el perímetro tiene varios vecinos de BGP y estos vecinos de BGP envían prefijos de ECMP al SR de nivel 0.
Descarte de tráfico para los prefijos que se agregan o eliminan continuamente.
Solución alternativa: Agregue un mapa de ruta entrante que filtre el prefijo BGP que se encuentra en la misma subred que la ruta estática nexthop.
Problema 2864250: Se observa un error en la realización del nodo de transporte si se utiliza el perfil de NIOC personalizado al crear un nodo de transporte.
El nodo de transporte no está listo para usarse.
Solución alternativa: Cree el nodo de transporte con el perfil de NIOC predeterminado y, a continuación, actualícelo aplicando el perfil de NIOC personalizado.
Problema 2866682: En Microsoft Azure, cuando se habilitan las redes aceleradas en máquinas virtuales de carga de trabajo SUSE Linux Enterprise Server (SLES) 12 SP4 con el agente NSX instalado, la interfaz de Ethernet no obtiene una dirección IP.
El agente de máquina virtual no se inicia y la máquina virtual se queda sin administrar.
Solución alternativa: Deshabilite Las redes aceleradas.
Problema 2867243: Las API de pertenencia efectiva para un grupo de directivas o un grupo NSGroup sin miembros efectivos no devuelven los campos 'results' y 'result_count' en la respuesta de la API.
El funcionamiento no se ve afectado.
Solución alternativa: Ninguna.
Problema 2868235: En el cuadro de diálogo Inicio rápido: redes y seguridad, la visualización muestra VDS duplicados cuando hay varias PNIC asociadas al mismo VDS.
La visualización muestra VDS duplicado. Es posible que sea difícil encontrar o desplazarse hasta la sección Personalizar conmutador de host si el foco esté en el gráfico de visualización.
Solución alternativa: Para el problema de desplazamiento, pulse la tecla Tab o mueva el puntero del mouse fuera del área de visualización y desplácese hasta la sección personalizar la configuración del conmutador.
Problema 2870085: El registro de nivel de directiva de seguridad para habilitar/deshabilitar el registro para todas las reglas no funciona.
No podrá cambiar el registro de todas las reglas cambiando "logging_enabled" de la directiva de seguridad.
Solución alternativa: Modifique cada regla para habilitar o deshabilitar el registro.
Problema 2870529: La información de tiempo de ejecución del firewall de identidad (IDFW) no está disponible si no se utiliza exactamente el caso del nombre de NetBIOS cuando se agrega el dominio de AD.
No puede obtener fácilmente el estado o la información de tiempo de ejecución actuales de IDFW. No se pueden determinar los inicios de sesión activos actuales.
Solución alternativa: Edite el dominio en cuestión y corrija el nombre de netbios. Una vez que se apliquen los cambios, todos los eventos de IDFW futuros se informarán correctamente.
Problema 2870645: En respuesta a la API /policy/api/v1/infra/realized-state/realized-entities, 'publish_status_error_details' muestra detalles del error aunque 'publish_status' sea "SUCCESS", lo que significa que la realización se realizó correctamente.
El funcionamiento no se ve afectado.
Solución alternativa: Ninguna.
Problema 2871585: La eliminación del host de DVS y la eliminación de DVS se permite para las versiones de DVS anteriores a la 7.0.3 después de habilitar la función NSX Security on vSphere DVPortgroups en los clústeres mediante DVS.
Es posible que tenga que resolver cualquier problema en la configuración del nodo de transporte o del clúster que surja de la eliminación de DVS o de un host de DVS.
Solución alternativa: Ninguna.
Problema 2874236: Después de la actualización, si solo se vuelve a implementar una puerta de enlace de nube pública (PCG) en un par de HA, se vuelve a utilizar la compilación anterior de AMI/VHD de HA.
Esto ocurre solo después de la actualización en la primera reimplementación de PCG.
Solución alternativa: Proporcione la AMI o VHD correcta después de la actualización a través de la API.
Problema 2875385: Cuando un nuevo nodo se une al clúster, si se cambió el nombre de los usuarios locales (admin, audit, guestuser1, guestuser2) a otro nombre, es posible que estos usuarios locales no puedan iniciar sesión.
El usuario local no puede iniciar sesión.
Solución alternativa: Existen dos soluciones alternativas.
Solución 1: Cambie el nombre del usuario a cualquier cosa y, a continuación, vuelva al nombre deseado.
Solución 2: Si no puede cambiar el nombre de los usuarios, reinicie NSX Manager.
Problema 2848614: Al unir un MP a un clúster de MP donde se establece publish_fqdns en el clúster de MP, y donde falta la entrada de búsqueda directa o inversa en el servidor DNS externo o la entrada de DNS para el nodo de unión, las alarmas directas o inversas no se generan para el nodo de unión.
Las alarmas directas o inversas no se generan para el nodo de unión, aunque falte la entrada de búsqueda directa/inversa en el servidor DNS o la entrada de DNS para el nodo de unión.
Solución alternativa: Configure el servidor DNS externo para todos los nodos de Manager con entradas de DNS directas e inversas.
Problema 2719682: Los campos calculados de la controladora Avi no se sincronizan con la intención en Directiva, lo que provoca discrepancias en los datos mostrados en la interfaz de usuario de Avi y en la interfaz de usuario de NSX-T.
Los campos calculados del controlador Avi se muestran en blanco en la interfaz de usuario de NSX-T.
Solución alternativa: Conmutador de aplicaciones que se utilizará para comprobar los datos de la interfaz de usuario de Avi.
Problema 2747735: Después de la restauración, se interrumpe la conectividad de VIP debido a problemas de compatibilidad de red.
Al restaurar la copia de seguridad, los clientes pueden actualizar la VIP antes del paso "AddNodeToCluster".
[Enter the workaround, if any, else state “None”] La restauración se pausa en el paso "AddNodeToCluster", en el que se solicita al usuario que agregue nodos de Manager adicionales. En ese paso, (a) primero elimine/actualice la VIP para que use una nueva dirección IP de la página ‘systems/appliances UI’ y (b) agregue nodos adicionales a un clúster de 1 nodo restaurado una vez que corregida la VIP.
Problema 2816781: Los servidores físicos no se pueden configurar con una directiva de formación de equipos basada en el equilibrio de carga, ya que admiten un solo VTEP.
No podrán configurar servidores físicos con una directiva de formación de equipos basada en el equilibrio de carga.
Solución alternativa: Cambie la directiva de formación de equipos a una directiva de formación de equipos basada en conmutación por error o cualquier directiva que tenga un solo VTEP.
Problema 2856109: Si se agrega el miembro del grupo número 2000, se producirá un error de límite si la versión del controlador Avi es 21.1.2.
El controlador Avi 21.1.2 permite 1999 miembros de grupo en lugar de 2000.
Solución alternativa: Utilice la versión del controlador Avi para 20.1.7 o 21.1.3.
Problema 2862418: El primer paquete podría perderse en el análisis de tráfico directo (LTA) al configurar LTA para rastrear el número exacto de paquetes.
No puede ver el primer seguimiento de paquetes.
Solución alternativa: Ninguna.
Problema 2864929: El recuento de miembros del grupo es mayor cuando se migra de NSX for vSphere a Avi Load Balancer en NSX-T Data Center.
Verá un mayor número de miembros del grupo. El monitor de estado marcará esos miembros del grupo como inactivos, pero el tráfico no se enviará a los miembros del grupo inaccesibles.
Solución alternativa: Ninguna.
Problema 2865273: El motor de búsqueda de Advanced Load Balancer (Avi) no se conectará al controlador Avi si hay una regla de DFW para bloquear los puertos 22, 443, 8443 y 123 antes de la migración de NSX for vSphere a NSX-T Data Center.
El motor de búsqueda de AVI no puede conectarse al controlador de Avi.
Solución alternativa: Agregue reglas de DFW explícitas para permitir los puertos 22, 443, 8443 y 123 para las máquinas virtuales de SE o excluir las máquinas virtuales de SE de las reglas de DFW.
Problema 2866885: El recopilador de registros de eventos (ELS) requiere que el nombre de NetBIOS esté configurado en el dominio de AD para que coincida con el del servidor de AD.
ELS no detectará el inicio de sesión del usuario.
Solución alternativa: Cambie el nombre de NetBIOS para que coincida con el del servidor de AD.
Problema 2868944: Los comentarios de la interfaz de usuario no se muestran al migrar más de 1000 reglas de DFW de NSX for vSphere a NSX-T Data Center, sino que las secciones se subdividen en secciones de 1000 reglas o menos.
No se muestran los comentarios de la interfaz de usuario.
Solución alternativa: Consulte los registros.
Problema 2878030: La actualización del nodo de orquestador para el cambio de sitio de Local Manager no muestra ninguna notificación.
Si se cambia el nodo de Orchestrator después de actualizar UC y continúa con el flujo de trabajo de la interfaz de usuario haciendo clic en cualquier botón de acción (comprobación previa, inicio, etc.), no verá ningún progreso en la interfaz de usuario de actualización. Esto solo se aplica si se accede a la interfaz de usuario de actualización de Local Manager en la interfaz de usuario de Global Manager mediante el conmutador de sitios.
Solución alternativa: Vaya al Local Manager de ese sitio y continúe con la actualización para ver la notificación esperada.
Problema 2878325: En la vista del panel de control de capacidad de inventario de Manager, el recuento de atributos "Grupos basados en conjuntos de direcciones IP" no incluye los grupos que contienen direcciones IP que se crean desde la interfaz de usuario de Directiva.
En la vista Panel de control de capacidad de inventario de Manager, el recuento de "Grupos basados en conjuntos de direcciones IP" no se representa correctamente si hay grupos de directivas que contienen direcciones IP.
Solución alternativa: Ninguna.
Problema 2879133: La función de prevención de malware puede tardar hasta 15 minutos en empezar a funcionar.
Cuando la función de prevención de malware está configurada por primera vez, la función puede tardar hasta 15 minutos en inicializarse. Durante esta inicialización, no se realizará ningún análisis de malware, pero no hay ninguna indicación de que se esté produciendo la inicialización.
Solución alternativa: Espere 15 minutos.
Problema 2879734: Se produce un error en la configuración cuando se utiliza el mismo certificado autofirmado en dos endpoints locales de IPsec diferentes.
No se establecerá la sesión de IPsec con errores hasta que se resuelva el error.
Solución alternativa: Utilice un certificado autofirmado único para cada endpoint local.
Problema 2879979: Es posible que el servicio IKE no inicie una nueva sesión basada en rutas de IPsec después de que se haya producido una "detección de pares inactivos" debido a que no se puede acceder al elemento del mismo nivel de IPsec.
Es posible que se produzca una interrupción en una sesión específica basada en rutas de IPsec.
Solución alternativa: Habilitar o deshabilitar en la sesión de IPsec puede resolver el problema.
Problema 2881281: Es posible que se produzca un error al configurar simultáneamente varios servidores virtuales para algunos.
Es posible que se agote el tiempo de espera de las conexiones de cliente a los servidores virtuales.
Solución alternativa: Ejecute la siguiente API para volver a activar el flujo de trabajo del enrutador lógico.
https://{ip}/api/v1/logical-routers/<id>? action=reprocess
Problema 2881471: El estado de la implementación del servicio no se actualiza cuando el estado de la implementación cambia de error a correcto.
Es posible que vea que el estado de implementación del servicio permanece inactivo para siempre junto con la alarma que se activó.
Solución alternativa: Utilice la API de estado de implementación del servicio para comprobar el estado.
API: https://{{ip-nsx-mgr}}/api/v1/serviceinsertion/services/{{id-service}}/service-deployments/{{service-deployment-id}}/status
Problema 2882070: Los miembros y los criterios de NSGroup no se muestran para los grupos globales en la lista de API de Manager.
Ningún impacto funcional.
Solución alternativa: Consulte las definiciones de grupos globales a través de la API de Directiva en Local Manager.
Problema 2882769: Las etiquetas de los objetos NSService y NSServiceGroup no se transfieren después de actualizar a NSX-T 3.2.
No hay ningún impacto funcional en NSX, ya que las etiquetas de NSService y NSServiceGroup no están siendo consumidas por ningún flujo de trabajo. Puede haber un impacto en los scripts externos que tienen flujos de trabajo que dependen de etiquetas en estos objetos.
Solución alternativa: Después de actualizar a NSX-T 3.2, se pueden agregar las etiquetas que faltan a NSService y NSServiceGroup mediante la actualización de las entidades.
Problema 2884939: El límite de velocidad de NSX de 100 solicitudes por segundo se alcanza cuando se migra una gran cantidad de servicios virtuales de NSX for vSphere a NSX-T ALB y todas las API se bloquean durante algún tiempo.
La API de la Directiva de NSX-T genera un error: El cliente 'admin' superó la tasa de solicitudes de 100 por segundo (Código de error: 102) durante algún tiempo después de que se alcance la configuración de migración en la migración.
Solución alternativa: Actualice el límite de frecuencia de la API del cliente a 200 solicitudes por segundo.
Problema 2792485: La IP de NSX Manager se muestra en lugar del FQDN para el administrador instalado en vCenter.
La interfaz de usuario de NSX-T integrada en vCenter muestra la IP de NSX Manager en lugar del FQDN del administrador instalado.
Solución alternativa: Ninguna.
Problema 2884518: Recuento incorrecto de máquinas virtuales conectadas al segmento en la interfaz de usuario de topología de red después de actualizar un dispositivo de NSX a NSX-T 3.2.
Verá un recuento incorrecto de máquinas virtuales conectadas al segmento en la topología de red. Sin embargo, el recuento real de máquinas virtuales asociadas con el segmento se mostrará al expandir el nodo de la máquina virtual.
Solución alternativa:
Inicie sesión en el dispositivo de NSX en modo de ingeniería.
Ejecute el comando: curl -XDELETE http://localhost:9200/topology_manager
Problema 2874995: La prioridad de los LCores puede permanecer alta aunque no se utilicen, lo que las hace inutilizables para algunas máquinas virtuales.
Degradación del rendimiento de las máquinas virtuales de "latencia normal".
Solución alternativa: Existen dos opciones.
Reinicie el sistema.
Elimine los LCores de alta prioridad y vuelva a crearlos. A continuación, volverán de forma predeterminada a los LCores de prioridad normal.
Problema 2772500: Habilitar la superposición anidada en ENS puede provocar una PSOD.
Puede resultar en PSOD.
Solución alternativa: Deshabilite ENS.
Problema 2832622: El perfil IPv6 ND no se verá afectado después de editarlo o modificarlo.
La red seguirá haciendo referencia al perfil de NDRA anterior.
Solución alternativa: Reinicie ccp para actualizar el perfil IPv6 ND.
Problema 2840599: La API de normalización de MP genera un error de INVALID_ARGUMENT.
Experiencia deficiente en la interfaz de usuario.
Solución alternativa: Ninguna.
Problema 2844756: Se produce un error al eliminar el segmento.
No podrá eliminar el segmento.
Solución alternativa: Fuerce la eliminación de los puertos asociados al segmento.
Recupere todos los puertos lógicos conectados a ese segmento mediante la siguiente API. Por ejemplo, para PolicySegment01.
GET : https://<IP NSX MANAGER>/policy/api/v1/infra/segments/PolicySegment01/ports
Para cada puerto lógico enumerado en la llamada anterior, realice la siguiente llamada.
DELETE : https://<IP NSX MANAGER>/api/v1/logical-ports/<LOGICAL PORT UUID>?detach=true
Una vez que se eliminan todos los puertos asociados, se puede eliminar el segmento.
Problema 2866751: La API de pertenencia efectiva consolidada no enumera las direcciones IP estáticas en la respuesta de un grupo de sombra.
Sin impacto funcional o de ruta de datos. No verá las direcciones IP estáticas en la API de pertenencia efectiva consolidada GET para un grupo de sombra. Esto solo se aplica a un grupo de sombra (también denominado grupos de referencia).
Solución alternativa: Compruebe la pertenencia efectiva consolidada de un grupo de sombra en su sitio original.
Problema 2869356: Aparece un error en el plano de administración al hacer clic en la pestaña "Información general" de un grupo NSGroup con miembros de IPSet.
Experiencia de usuario deficiente.
Solución alternativa: Ninguna.
Problema 2872658: Después del registro del sitio, la interfaz de usuario muestra un error de tipo "No se pudo importar debido a las siguientes funciones no compatibles: IDS”.
El funcionamiento no se ve afectado. No se admite la importación de configuración en NSX-T 3.2.
Solución alternativa: Elimine la configuración de IDS del Local Manager y vuelva a intentar el registro.
Problema 2877628: Al intentar instalar la función de seguridad en una versión de VDS de conmutador de host ESX anterior a la versión 6.6, se muestra un mensaje de error poco claro.
El mensaje de error se muestra a través de la interfaz de usuario y la API.
Solución alternativa: Utilice una versión de VDS posterior o igual a 6.6 en ESX para instalar NSX Security.
Problema 2877776: El resultado de "get controllers" puede mostrar información obsoleta sobre controladores que no son el principal en comparación con el archivo controller-info.xml.
Este resultado de la CLI es confuso.
Solución alternativa: Reinicie nsx-proxy en ese TN.
Problema 2879119: Cuando se agrega un enrutador virtual, la interfaz de red del kernel correspondiente no aparece.
Se produce un error en el enrutamiento en vrf. No se establece ninguna conectividad para las máquinas virtuales conectadas a través de vrf.
Solución alternativa: Reinicie el servicio de plano de datos.
Problema 2881168: El resultado de la API GET del puerto lógico tiene el formato expandido "fc00:0:0:0:0:0:0:1" en comparación con el formato anterior "fc00::1".
El resultado de la API LOGICALPort GET en NSX-T 3.2 tiene el formato expandido "fc00:0:0:0:0:0:0:1" en comparación con el formato "fc00::1" de NSX-T 3.0.
Solución alternativa: Ninguna.
Problema 2882822: Los conjuntos de IP temporales no se agregan a los grupos de seguridad utilizados en las reglas de firewall de EDGE o los miembros del grupo de equilibradores de carga durante la migración de configuración de NSX for vSphere a NSX-T.
Durante la migración, puede haber una brecha hasta que las VM/VIF se detectan en NSX-T y forman parte de las SG a las que se aplican a través de pertenencia estática/dinámica. Esto puede provocar que el tráfico se descarte o se permita en contra de las reglas de firewall de Edge en el período entre la transferencia norte-sur (tráfico de N/S que pasa a través de la puerta de enlace de NSX-T) hasta el final de la migración.
Solución alternativa: Agregue una regla de DFW falsa en la que el origen o el destino contengan todos los grupos de seguridad consumidos en el firewall de Edge. Otra opción es mover el origen y el destino de las reglas de firewall de Edge a los conjuntos de direcciones IP antes de la migración.
Problema 2884070: Si no coincide la configuración de MTU entre el vínculo superior de NSX-T Edge y el enrutador de emparejamiento, el envío vecino OSPF se bloquea en el estado Desiniciado. Durante la migración de NSX for vSphere a NSX-T, la MTU no se migra automáticamente, por lo que una falta de coincidencia puede afectar al plano de datos durante la migración total de Edge norte-sur.
La adyacencia de OSPF se bloquea en el estado de inicio exstart.
Solución alternativa: Configure manualmente la MTU coincidente en las interfaces de vecino OSPF antes de realizar la migración total de Edge.
Problema 2884416: El estado del equilibrador de carga no se puede actualizar a tiempo.
Estado incorrecto del equilibrador de carga.
Solución alternativa: Detenga la recopilación de estadísticas del equilibrador de carga.
Problema 2885009: Global Manager tiene perfiles de conmutación predeterminados adicionales después de la actualización.
Ningún impacto funcional.
Solución alternativa: No se espera que utilice los perfiles de conmutación predeterminados que comienzan con el prefijo "nsx-default".
Problema 2885248: En el caso de InterVtep, si las VNIC de Edge están conectadas a grupos de puertos de NSX (independientemente de la VLAN en la máquina virtual de Edge y el host ESX), el tráfico norte-sur entre las máquinas virtuales de las cargas de trabajo en ESX y Edge deja de funcionar como paquetes destinados al VTEP de Edge.
Solución alternativa: Para actualizar EdgeTN, desconecte los segmentos de sus interfaces y vuelva a conectarlos.
Problema 2885330: No se muestra el miembro efectivo para el grupo de AD.
No se muestran los miembros efectivos del grupo de AD. Ningún impacto en la ruta de datos.
Solución alternativa: Ninguna.
Problema 2885552: Si ha creado un origen de identidad LDAP que utiliza OpenLDAP y hay más de un servidor LDAP definido, solo se utilizará el primer servidor.
Si el primer servidor LDAP deja de estar disponible, se producirá un error en la autenticación, en lugar de intentar el resto de los servidores OpenLDAP configurados.
Solución alternativa: Si es posible colocar un equilibrador de carga delante de los servidores OpenLDAP y configurar NSX con la dirección IP virtual del equilibrador de carga, puede tener alta disponibilidad.
Problema 2886210: Durante la restauración, si el VC está inactivo, aparecerá un cuadro de diálogo de copia de seguridad/restauración que indica al usuario que se asegure de que el VC esté activo y en ejecución. Sin embargo, no se muestra la dirección IP del VC.
la dirección IP de VC no se muestra durante la restauración de la conectividad de VC.
Solución alternativa: Compruebe que todos los VC registrados se estén ejecutando antes de continuar con el siguiente paso de restauración.
Problema 2886971: Los grupos creados en Global Manager no se limpian después de la eliminación. Esto ocurre solo si ese grupo es un grupo de referencia en un sitio de Local Manager.
Sin impacto funcional; sin embargo, no puede crear otro grupo con la misma ruta de directiva que el grupo eliminado.
Solución alternativa: Ninguna.
Problema 2887037: Después de la promoción de objetos de Manager a Directiva, las reglas NAT no se pueden actualizar ni eliminar.
Esto sucede cuando un usuario de PI (identidad principal) crea reglas NAT en Manager antes de que se active la promoción. Las reglas NAT creadas por el usuario de PI no se pueden actualizar ni eliminar después de la promoción de objetos de Manager a Directiva.
Solución alternativa: Las reglas NAT con la misma configuración se pueden crear con un usuario no protegido como "admin" antes de la promoción de objetos de Manager a Directiva.
Problema 2888207: No se pueden restablecer las credenciales de usuario local cuando vIDM está habilitado.
No podrá cambiar las contraseñas de los usuarios locales mientras vIDM esté habilitado.
Solución alternativa: debe deshabilitar (temporalmente) la configuración de vIDM, restablecer las credenciales locales durante este tiempo y volver a habilitar la integración.
Problema 2889748: Error al eliminar el nodo de Edge si se produjo un error en la reimplementación. La eliminación deja una intención obsoleta en el sistema que se muestra en la interfaz de usuario.
Aunque se eliminará la máquina virtual de Edge, la intención de Edge obsoleta y los objetos internos se conservarán en el sistema y la operación de eliminación se volverá a intentar internamente. Sin impacto en la funcionalidad, ya que las máquinas virtuales de Edge se eliminan y solo la intención tiene entradas obsoletas.
Solución alternativa: Ninguna.
Problema 2875962: El flujo de trabajo de actualización para las configuraciones nativas en la nube es diferente de NSX-T 3.1 a NSX-T 3.2.
Si sigue el flujo de trabajo habitual, se borrarán todos los datos de CSM.
Solución alternativa: La actualización requiere la asistencia de VMware. Póngase en contacto con el soporte de VMware.
Problema 2888658: Impacto significativo en el rendimiento en términos de conexiones por segundo y rendimiento observado en el firewall de puerta de enlace de NSX-T cuando las funciones de detección de malware y espacio aislado están habilitadas.
Cualquier tráfico sujeto a la detección de malware experimenta latencias significativas y posibles errores de conexión. Cuando la detección de malware está habilitada en la puerta de enlace, también afecta al tráfico de L7FW, lo que provoca latencias y errores de conexión.
Solución alternativa: Limite la cantidad de tráfico que está sujeto a la detección de malware escribiendo reglas de IDS que coincidan solo con una pequeña subsección del tráfico.
Problema 2882574: Se bloquearon las API 'Brownfield Config Onboarding' en NSX-T 3.2.0, ya que la función no es totalmente compatible.
No podrá utilizar la función 'Brownfield Config Onboarding'.
Solución alternativa: Ninguna.
Problema 2890348: Al cambiar el nombre del grupo de VNI predeterminado se produce un grupo de VNI incoherente al actualizar a NSX-T 3.2.
La asignación de VNI y las operaciones relacionadas pueden fallar.
Solución alternativa: Antes de actualizar a NSX-T 3.2, cambie el nombre del grupo de VNI predeterminado a DefaultVniPool
mediante la API PUT https://{{url}}/api/v1/pools/vni-pools/<vni-pool-id>
.
Problema 2885820: Faltan traducciones para algunas direcciones IP del rango de IP a partir de 0.0.0.0.
El grupo NSGroup con rango de IP a partir de 0.0.0.0 (por ejemplo, "0.0.0.0-255.255.255.0") tiene problemas de traducción (falta la subred 0.0.0.0/1).
El grupo NSGroup con el rango de IP "1.0.0.0-255.255.255.0" no se ve afectado.
Solución alternativa: Para configurar grupos con un rango de IP a partir de 0.0.0.0, agregue manualmente 0.0.0.0/1 en la configuración del grupo.
Problema 2871440: Las cargas de trabajo protegidas con NSX Security en vSphere dvPortGroups pierden su configuración de seguridad cuando se migra con vMotion a un host conectado a una instancia de NSX Manager inactiva.
En el caso de los clústeres instalados con NSX Security en la función dvPortGroups de vSphere, las máquinas virtuales que se migran con vMotion a hosts conectados a una instancia de NSX Manager inactiva no aplican sus reglas de seguridad y DFW. Esta configuración de seguridad se vuelve a aplicar cuando se restablece la conectividad con NSX Manager.
Solución alternativa: Evite utilizar vMotion en los hosts afectados cuando NSX Manager esté inactivo. Si otros nodos de NSX Manager están funcionando, migre con vMotion la máquina virtual a otro host que esté conectado a una instancia de NSX Manager en buen estado.
Problema 2945515: La actualización de herramientas de NSX en Azure puede fallar en las máquinas virtuales con Redhat Linux.
De forma predeterminada, las herramientas de NSX están instaladas en el directorio /opt. Sin embargo, durante la instalación de herramientas de NSX, la ruta predeterminada se puede sobrescribir con la opción "--chroot-path" que se pasa al script de instalación.
No hay suficiente espacio en disco en la partición en la que se instalan las herramientas de NSX. Se puede producir un error en la actualización de las herramientas de NSX.
Solución alternativa: Ninguna.
Problema 2875563: Eliminar la sesión de LTA IN_PROGRESS puede provocar una pérdida de archivos PCAP.
El archivo PCAP se perderá si se elimina una LTA con la acción PCAP cuando el estado de la sesión de LTA es "IN_PROGRESS". Esto puede provocar que la partición /tmp del ESXi se llene.
Solución alternativa: Borrar la partición /tmp puede ser útil.
Problema 2875667: Al descargar el archivo PCAP de LTA, se produce un error cuando la partición /tmp de NSX está llena.
No se puede descargar el archivo PCAP de LTA porque la partición /tmp está llena.
Solución alternativa: Borrar la partición /tmp puede ser útil.
Problema 2883505: PSoD en hosts ESXi durante la migración V2T de NSX.
PSOD (pantalla púrpura de la muerte) en varios hosts ESXi durante la migración V2T. Esto produce una interrupción en la ruta de datos.
Solución alternativa: Ninguna.
Problema 2914934: Las reglas de DFW en dvPortGroups se pierden después de migrar NSX-V a NSX-T.
Después de una migración de NSX-V a NSX-T, cualquier carga de trabajo que aún esté conectada a dvPortGroup de vSphere no tendrá configuración de DFW.
Solución alternativa: Después de una migración de NSX-V a NSX-T, los segmentos de VLAN se configuran con una configuración de DFW idéntica. Utilice los segmentos de VLAN en lugar de dvPortGroups.
Otra solución alternativa es desinstalar NSX-V e instalar NSX-T en modo de solo seguridad. A continuación, podrá utilizar cargas de trabajo en los dvPortGroups existentes.
Problema 2921704: La CPU del servicio de Edge puede experimentar un pico debido a un bloqueo del proceso nginx cuando se utiliza el equilibrador de carga de capa 7 con el algoritmo de equilibrio de carga de hash de IP.
No es posible la conexión a los servidores back-end detrás del equilibrador de carga.
Solución alternativa: Cambie al motor de capa 4 para corregir el problema. Si desea seguir usando el equilibrador de carga de capa 7, cambie el algoritmo de equilibrio de carga a round-robin en lugar de ip-hash.
Problema 2933905: Al reemplazar una instancia de NSX-T Manager, los nodos de transporte pierden la conexión con el controlador.
Agregar o eliminar un nodo en el clúster de Manager puede provocar que algunos nodos de transporte pierdan conectividad con el controlador.
Solución alternativa: Reinicie el servicio nsx proxy en los nodos de transporte afectados cada vez que se agregue o elimine una instancia de Manager del clúster de administración. Esto volverá a rellenar controller-info.xml y permitirá que aparezca la conexión del controlador.
Problema 2927442: El tráfico a veces alcanza la regla de denegación de DFW predeterminada en las máquinas virtuales en diferentes hosts y clústeres desde la actualización de NSX-T 3.2.0.1.
Se produjeron algunos problemas de PSOD después de la migración de NSX for vSphere a NSX-T 3.1.3. Por lo tanto, se recomendó actualizar a 3.2.0.1. No obstante, los hosts no aplican las reglas de firewall distribuido de forma coherente. Los diferentes hosts coinciden con diferentes reglas que no son coherentes y no se esperan.
Solución alternativa:
- Si se observa la excepción anterior en un controlador específico, se podrá reiniciar para resolver temporalmente el problema.
- Además, si el problema afecta al DFW, se podrán crear reglas de permiso cualquiera/cualquiera en la parte superior de la lista de reglas para omitir las reglas de bloque no deseadas.
Problema 2937810: El servicio de ruta de datos no se inicia y algunas funciones de puente de Edge (por ejemplo, el puerto de puente de Edge) no funcionan.
Si el puente de Edge está habilitado en los nodos de Edge, el plano de control central (CCP) envía las reglas de DFW a los nodos de Edge, que solo se deben enviar a los nodos del host. Si las reglas de DFW contienen una función que no es compatible con el firewall de Edge, los nodos de Edge no podrán controlar la configuración de DFW no compatible, lo que provocará que la ruta de datos no se inicie.
Solución alternativa: Elimine o deshabilite las reglas de DFW, que no son compatibles con el firewall de Edge.