Notas de la versión de VMware NSX for vSphere 6.2.0

|

VMware NSX for vSphere 6.2.0 | 20 de agosto de 2015 | Compilación 2986609 | Documento actualizado el 22 de noviembre de 2015

Contenido de las notas de la versión

Las notas de la versión contienen los siguientes temas:

Novedades

NSX for vSphere 6.2 incluye las características nuevas y modificadas siguientes:

  • Cross vCenter Networking and Security

    • NSX 6.2 con vSphere 6.0 es compatible con Cross vCenter NSX donde los conmutadores lógicos (logical switches, LS), los enrutadores lógicos distribuidos (distributed logical routers, DLR) y Distributed Firewall (DFW) pueden implementarse en varias instancias de vCenter para habilitar funciones de seguridad y redes lógicas de aplicaciones con cargas de trabajo (máquinas virtuales) que abarcan varias instancias de vCenter o varias ubicaciones físicas.

    • Directiva de firewall coherente entre varias instancias de vCenter: Las secciones de reglas de firewall (Firewall Rule Sections) en NSX ahora se pueden marcar como "Universal", por lo cual las reglas definidas en estas secciones se replican en varias instancias de NSX Manager. Esto simplifica los flujos de trabajo que involucran la definición de una directiva de firewall coherente que abarque varias instalaciones de NSX.

    • Cross vCenter vMotion con DFW: Las máquinas virtuales que tienen directivas definidas en las secciones "Universal" se pueden mover entre hosts que pertenecen a distintas instancias de vCenter que implementan una directiva de seguridad coherente.

    • Grupos de seguridad universales: Los grupos de seguridad en NSX 6.2 basados en dirección IP, conjunto IP, dirección MAC y conjunto MAC se pueden utilizar ahora en las reglas universales, por lo que los grupos y la pertenencia a grupos se sincronizan en varias instancias de NSX Manager. Esto mejora la coherencia entre las definiciones de grupos de objetos en varias instancias de NSX Manager y permite la aplicación de directivas coherentes.

    • Conmutador lógico universal (Universal Logical Switch, ULS): Esta nueva funcionalidad, incorporada en NSX 6.2 como parte de Cross vCenter NSX, permite la creación de conmutadores lógicos que pueden abarcar varias instancias de vCenter, lo que permite al administrador de red crear un dominio L2 contiguo para una aplicación o una empresa.

    • Enrutador lógico distribuido universal (Universal Distributed Logical Router, UDLR): Esta nueva funcionalidad, incorporada en NSX 6.2 como parte de Cross vCenter NSX, permite la creación de enrutadores lógicos distribuidos que pueden abarcar varias instancias de vCenter. Los enrutadores lógicos distribuidos universales permiten el enrutamiento en los conmutadores lógicos universales que se describieron anteriormente. Además, el UDLR de NSX tiene la capacidad de enrutamiento norte-sur localizado según la ubicación física de las cargas de trabajo.

  • Mejoras en la solución de problemas y el funcionamiento

    • Nueva herramienta para la solución de problemas Traceflow: Traceflow es una herramienta para la solución de problemas que ayuda a identificar si el problema está en la red virtual o física. Proporciona la capacidad de rastrear un paquete desde el origen hasta el destino y ayuda a observar cómo ese paquete pasa a través de las diversas funciones de red en la red virtual.

    • Flow Monitoring y separación de IPFIX: En NSX 6.1.x, NSX era compatible con los informes IPFIX, pero los informes IPFIX podían habilitarse solo si el informe de flujo a NSX Manager también estaba habilitado. A partir de NSX 6.2.0, estas características son independientes. En NSX 6.2.0 y posteriores, se puede habilitar IPFIX de manera independiente de la supervisión del flujo en NSX Manager.

    • Nuevos comandos para la solución de problemas y supervisión de CLI en la versión 6.2: Consulte el artículo de la base de conocimientos para obtener más información.

    • CLI central: La CLI central reduce el tiempo de solución de problemas de las funciones de red distribuidas. Los comandos se ejecutan en la línea de comandos de NSX Manager y recuperan información de las controladoras, los hosts y NSX Manager. Esto permite acceder y comparar la información rápidamente desde varios orígenes. La CLI central brinda información sobre conmutadores lógicos, enrutadores lógicos, Distributed Firewall y perímetros.

    • El comando ping de la CLI agrega el tamaño configurable del paquete y la marca no fragmentar: A partir de NSX 6.2.0, el comando ping de la CLI de NSX ofrece opciones para especificar el tamaño del paquete de datos (sin incluir el encabezado ICMP) y para establecer la marca no fragmentar. Consulte Referencia de la CLI de NSX para ver más detalles.

    • Mostrar estado de los canales de comunicación: NSX 6.2.0 incluye la capacidad de supervisar el estado del canal de comunicación. El estado de mantenimiento del canal entre NSX Manager y el agente de firewall, entre NSX Manager y el agente de plano de control, y entre el host y NSX Controller se puede ver desde la interfaz de usuario de NSX Manager. Además, esta característica detecta cuándo los mensajes de configuración de NSX Manager se perdieron antes de aplicarlos a un host, e indica al host que vuelva a cargar la configuración de NSX cuando se producen tales errores de mensaje.

    • CLI de cliente de VPN L2 Edge independiente: Antes de NSX 6.2, se podía configurar un cliente de VPN L2 para NSX Edge independiente solo a través de parámetros OVF. Se agregaron los comandos específicos para una instancia independiente de NSX Edge a fin de permitir la configuración con la interfaz de línea de comandos. OVF ahora se utiliza solo para la configuración inicial.

  • Enrutamiento y redes lógicas

    • Interoperabilidad de puente L2 con enrutador lógico distribuido: Con VMware NSX for vSphere 6.2, los puentes L2 ahora pueden participar en el enrutamiento lógico distribuido. La red VXLAN a la que está conectada la instancia de puente se utiliza para conectar la instancia de enrutamiento con la instancia de puente.

    • Compatibilidad con prefijos /31 en las interfaces de ESG y DLR según RFC 3021.

    • Compatibilidad mejorada de solicitud DHCP retransmitida en el servidor DHCP ESG.

    • Capacidad de mantener las etiquetas VLAN por VXLAN.

    • Coincidencia exacta para filtros de redistribución: El filtro de redistribución tiene el mismo algoritmo de coincidencia que la ACL, por lo que la coincidencia del prefijo es exacta de forma predeterminada (excepto si se utilizan las opciones LE o GE).

    • Compatibilidad con distancia administrativa para ruta estática.

    • Capacidad para habilitar, reducir o deshabilitar la comprobación por interfaz en Edge.

    • Mostrar ruta de acceso AS en comando de CLI show ip bgp.

    • Exclusión de interfaz de HA de la redistribución a los protocolos de enrutamiento en la máquina virtual de control de DLR.

    • La sincronización forzada del enrutador lógico distribuido (distributed logical router, DLR) evita la pérdida de datos del tráfico de enrutamiento de Este a Oeste en el DLR. El puente y el enrutamiento de Norte a Sur pueden seguir teniendo interrupciones.

    • Ver perímetro activo en par HA: En el cliente web NSX 6.2, se puede ver si un dispositivo NSX Edge es el dispositivo activo o el de copia de seguridad en un par HA.

    • Compatibilidad de API REST con filtro de ruta de acceso inversa (rp_filter) en Edge: Con la API REST de control del sistema, rp_filter sysctl se puede configurar a través de la interfaz de usuario y también se expone a través de la API REST para interfaces y subinterfaces de vNIC. Consulte la documentación de NSX API para obtener más información.

    • Comportamiento de los filtros de ruta BGP del prefijo IP GE y prefijo IP LE: En NSX 6.2, se hicieron las mejoras siguientes a los filtros de ruta BGP:

      • No se permiten las palabras clave LE/GE: En la dirección de red de ruta nula (definida como CUALQUIERA [ANY] o en formato CIDR 0.0.0.0/0), las palabras clave menor-o-igual-que (LE) y mayor-o-igual-que (GE) ya no se permiten. En versiones anteriores, estas palabras clave estaban permitidas.

      • Los valores LE y GE en el rango de 0 a 7 ahora se toman como válidos. En las versiones anteriores, este rango no era válido.

      • En un prefijo de ruta específico, ya no se puede especificar un valor GE mayor que el valor de LE especificado.

  • Servicios Edge y de redes

    • Se cambió el nombre de la interfaz de administración de DLR a interfaz de HA. Se hizo esto para resaltar el hecho de que los keepalive de HA viajan por esta interfaz y de que las interrupciones en el tráfico de esta interfaz pueden provocar una condición de cerebro dividido.

    • Mejoras en la supervisión del estado del equilibrador de carga: Proporciona una supervisión de estado granular que brinda información sobre errores, realiza un seguimiento de la última comprobación de estado y del cambio de estado, e informa sobre los motivos de los errores.

    • Compatibilidad con rango de puertos de grupo y VIP: Habilita la compatibilidad del equilibrador de carga con las aplicaciones que requieren un rango de puertos.

    • Cantidad máxima aumentada de direcciones IP virtuales (VIP): La compatibilidad con VIP aumenta a 1024.

  • Mejoras en el servicio de seguridad

    • Nuevos mecanismos de detección de dirección IP para máquinas virtuales: La aplicación autoritativa de directivas de seguridad según los nombres de máquinas virtuales u otros atributos basados en vCenter requiere que NSX conozca la dirección IP de la máquina virtual. En NSX 6.1 y anteriores, la detección de dirección IP para cada máquina virtual dependía de la presencia de VMware Tools (vmtools) en esa máquina virtual o de la autorización manual de la dirección IP para esa máquina virtual. NSX 6.2 incorpora la opción para detectar la dirección IP de las máquinas virtuales con intromisión DHCP o intromisión ARP. Estos mecanismos de detección nuevos permiten que NSX aplique las reglas de seguridad basadas en dirección IP en máquinas virtuales que no tienen VMware Tools instalado.

  • Interoperabilidad de soluciones

    • Compatibilidad con las topologías de vSphere 6.0 Platform Services Controller: NSX ahora es compatible con Platform Services Controller (PSC), además de con las configuraciones de PSC integradas ya compatibles.

    • Compatibilidad con el complemento vRealize Orchestrator para NSX 1.0.2: Con la versión NSX 6.2, se introduce el complemento NSX-vRO v1.0.2 en vRealize Automation (vRA).

Requisitos del sistema e instalación

Las características basadas en Guest Introspection y Network Introspection en NSX son compatibles con versiones específicas de VMware Tools (VMTools). Para habilitar el componente opcional controlador de NSX Network Introspection empaquetado con VMware Tools, actualice VMware Tools a las versiones siguientes:

  • VMware Tools 5.1 P07 y posteriores

  • VMware Tools 5.5 P04 y posteriores

  • VMware Tools 6.0

Para ver la lista completa de requisitos previos para la instalación de NSX, consulte la sección Requisitos del sistema para NSX en Instalación de NSX 6.2.

Notas sobre la actualización

  • La matriz de interoperabilidad de productos VMware proporciona los detalles sobre las rutas de acceso de actualización compatibles de VMware NSX.

  • No se admiten las actualizaciones de NSX 6.1.5 a NSX 6.2.0. Debe actualizar de NSX 6.1.5 a NSX 6.2.1 o posterior.

  • Cuando actualiza NSX en contexto con otras actualizaciones de productos VMware, como vCenter y ESXi, es importante seguir la secuencia de actualización compatible documentada en este artículo de la base de conocimientos.

  • Consulte la sección Problemas conocidos de instalación y actualización más adelante en este documento para ver una lista de los problemas conocidos relacionados con la actualización.

  • Los requisitos de memoria y CPU para la instalación y actualización de NSX Manager cambiaron. Consulte Requisitos del sistema para NSX en la documentación de instalación de NSX 6.2 o actualización de NSX 6.2 .

  • Cambio de comportamiento de los filtros de redistribución en el enrutador lógico distribuido y la puerta de enlace de servicios Edge: A partir de la versión 6.2, las reglas de redistribución del DLR y de la ESG funcionan como ACL solamente. Es decir, si una regla es una coincidencia exacta, se lleva a cabo la acción correspondiente.

  • Antes de actualizar a NSX 6.2.0, debe asegurarse de que la instalación no utilice un identificador de túnel VXLAN 4094 en ningún túnel. El identificador de túnel VXLAN 4094 ya no está disponible. Para evaluar y abordar este tema, siga estos pasos:

    1. En vCenter, desplácese hasta Inicio (Home) > Redes y seguridad (Networking and Security) > Instalación (Installation) y seleccione la pestaña Preparación del host (Host Preparation).
    2. Haga clic en Configurar (Configure) en la columna VXLAN.

    3. En la ventana Configurar redes VXLAN (Configure VXLAN Networking), establezca el identificador de VLAN (VLAN ID) en un valor entre 1 y 4093.

  • Después de actualizar NSX Manager, debe restablecer el servidor vSphere Web Client como se explica en la documentación de actualización de NSX. Hasta entonces, es posible que no aparezca la pestaña Redes y seguridad (Networking and Security) en vSphere Web Client.

  • Las actualizaciones de NSX en un entorno de host sin estado utilizan URL de VIB nuevas: En las actualizaciones de NSX en un entorno de host sin estado, los VIB nuevos se agregan previamente al perfil de imagen del host durante el proceso de actualización de NSX. Como resultado, el proceso de actualización de NSX en hosts sin estado sigue esta secuencia:

    1. Se descargan manualmente los VIB de NSX más recientes de NSX Manager desde una URL fija.

    2. Se agregan los VIB al perfil de imagen del host.

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

    • Busque la URL de VIB nueva en https://<NSX-Manager-IP>/bin/vdn/nwfabric.properties.
    • Obtenga los VIB de la versión de host ESX requerida desde la URL correspondiente.
    • Agréguelos al perfil de imagen del host.
  • Antes de actualizar VMware vCloud Network and Security 5.x a VMware NSX for vSphere 6.2: Si desea actualizar a VMware NSX for vSphere 6.2 a partir de VMware vCloud Network and Security 5.5.x, compruebe si falta la información del nombre del puerto del vínculo superior en las tablas mediante la ejecución de la llamada API REST siguiente:
    GET https://<nsxmgr-IP>/api/2.0/vdn/switches
    En el resultado, busque el campo uplinkPortName. Por ejemplo:

    <?xml version="1.0" encoding="UTF-8"?>
    <vdsContexts>
       <vdsContext>
          <switch>
             <objectId>dvs-22</objectId>
          <objectTypeName>VmwareDistributedVirtualSwitch</objectTypeName>
             <nsxmgrUuid>4236F6CA-3B1A-56BE-4B55-1EF82B8CA12D</nsxmgrUuid>
             <revision>2</revision>
             <type>
                <typeName>VmwareDistributedVirtualSwitch</typeName>
             </type>
             <name>1-vds-20</name>
             <scope>
                <id>datacenter-3</id>
                <objectTypeName>Datacenter</objectTypeName>
                <name>datacenter-1</name>
             </scope>
             <clientHandle />
             <extendedAttributes />
          </switch>
          <mtu>1600</mtu>
          <teaming>FAILOVER_ORDER</teaming>
          <uplinkPortName>uplink2</uplinkPortName>
          <promiscuousMode>false</promiscuousMode>
       </vdsContext>
    </vdsContexts>
    

    Si el resultado de este comando contiene, al menos, un nombre de puerto de vínculo superior para cada conmutador distribuido de vSphere, puede proceder con la actualización. Si en el resultado falta el nombre del puerto de vínculo superior, consulte el artículo de la base de conocimientos.

Problemas conocidos

Los problemas conocidos se agrupan de la siguiente manera:

Problemas conocidos generales

Error Bloquearía (Would block) en el enrutador lógico distribuido
Es posible que se produzca un error en los enrutadores lógicos distribuidos de NSX después de realizar cambios en la configuración del host. Este problema se produce cuando vSphere no puede crear un puerto VDR requerido en el host. Es posible que este error se vea como un error de conexión de DVPort en vmkernel.log o un error SIOCSIFFLAGS en el invitado. Esto puede suceder cuando los VIB se cargan después de que vCenter transmite las propiedades de DVS.

Solución alternativa: Consulte el artículo 2107951 de la base de conocimientos de VMware

Aparece una pantalla de diagnóstico morada en VMware ESXi 5.x y 6.x cuando se utiliza detección de direcciones IP
Al utilizar detección de direcciones IP en conmutadores lógicos en VMware NSX for vSphere 6.2.0, en el host ESXi 5.x y 6.x aparece una pantalla de diagnóstico morada que muestra un error.

Solución alternativa: consulte la página http://kb.vmware.com/kb/2134329 para obtener instrucciones.

La interfaz de usuario permite la creación de reglas de firewall de NSX de entrada/salida que no se pueden aplicar a las instancias de Edge
El cliente web, incorrectamente, permite la creación de una regla de firewall de NSX aplicada a una o más instancias de NSX Edge cuando la regla tiene tráfico que se traslada en dirección "de entrada" o "de salida", y cuando PacketType es IPV4 o IPV6. La interfaz de usuario no debería permitir la creación de tales reglas, dado que NSX no puede aplicarlas a las instancias de NSX Edge.

Solución alternativa: Ninguna.

El usuario debe descargar los registros de NSX Controller de forma secuencial
Se pueden descargar los registros de NSX Controller para la solución de problemas. Debido a un problema conocido, no se puede descargar más de un registro de la controladora de forma simultánea. Incluso cuando se realiza una descarga desde varias controladoras, se debe esperar a que la descarga de la controladora actual finalice antes de iniciar la descarga de la controladora siguiente. Además, se debe tener en cuenta que no se puede cancelar una descarga de registro una vez que se inició.

Solución alternativa: Espere a que finalice la descarga del registro del controlador actual antes de iniciar otra descarga de registro.

Los archivos de registro exportados como CSV desde NSX Manager tienen la marca de tiempo de época en lugar de fecha y hora
Cuando se exportan archivos de registro, como CSV, desde NSX Manager con vSphere Web Client, es posible observar que los archivos de registro tienen la marca de tiempo de época en milisegundos en lugar de la hora adecuada según la zona horaria.

Solución alternativa: Ninguna.

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

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

Flow Monitoring descarta flujos que exceden el límite de 2 millones de flujos cada 5 minutos
NSX Flow Monitoring retiene registros de hasta 2 millones de flujos. Si los hosts generan más de 2 millones de registros en 5 minutos, los flujos nuevos se descartan.

Solución alternativa: Ninguna.

NSX API devuelve el formato JSON en vez de XML en determinadas circunstancias
En algunas ocasiones, una solicitud API devuelve al usuario el formato JSON, no XML.

Solución alternativa: Agregue Accept: application/xml al encabezado de la solicitud.

NSX Manager no acepta cadenas de búsqueda de DNS con delimitador de espacio
NSX Manager no acepta cadenas de búsqueda de DNS con delimitador de espacio. Solo se puede utilizar la coma como delimitador. Por ejemplo, si el servidor DHCP anuncia eng.sample.com y sample.com para la lista de búsqueda de DNS, NSX Manager se configura con eng.sample.com sample.com.

Solución alternativa: Utilice comas como separadores. NSX Manager solo acepta el separador coma como cadenas de búsqueda de DNS.

En las implementaciones de Cross vCenter NSX, se replican varias versiones de las configuraciones guardadas en las instancias de NSX Manager secundarias
La sincronización universal guarda varias copias de la configuración universal en las instancias de NSX Manager secundarias. La lista de configuraciones guardadas contiene varios borradores creados por la sincronización en NSX Manager con el mismo nombre y en el mismo momento o con una diferencia de 1 segundo.

Solución alternativa: Ejecute la llamada API para eliminar los borradores duplicados.

DELETE : https://<nsxmgr-ip>/api/4.0/firewall/config/drafts/

Busque los borradores que se deben eliminar; para ello vea todos los borradores:

GET: https://<nsxmgr-ip>/api/4.0/firewall/config/drafts

En los resultados de muestra siguientes, los borradores 143 y 144 tienen el mismo nombre y se crearon a la misma hora, por lo tanto, son duplicados. Lo mismo sucede con los borradores 127 y 128: tienen el mismo nombre y una diferencia de 1 segundo; también son duplicados.

<firewallDrafts>
    <firewallDraft id="144" name="AutoSaved_Wednesday, August 5, 2015 11:08:40 PM GMT" timestamp="1438816120917"> 
        <description>Auto saved configuration</description>
        <preserve>false</preserve>
        <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
        <mode>autosaved</mode>
    </firewallDraft>
    <firewallDraft id="143" name="AutoSaved_Wednesday, August 5, 2015 11:08:40 PM GMT" timestamp="1438816120713">
        <description>Auto saved configuration</description>
        <preserve>false</preserve>
        <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
        <mode>autosaved</mode>
    </firewallDraft>
   <firewallDraft id="128" name="AutoSaved_Wednesday, August 5, 2015 9:08:02 PM GMT" timestamp="1438808882608">
        <description>Auto saved configuration</description>
        <preserve>false</preserve>
        <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
        <mode>autosaved</mode>
    </firewallDraft>
    <firewallDraft id="127" name="AutoSaved_Wednesday, August 5, 2015 9:08:01 PM GMT" timestamp="1438808881750">
        <description>Auto saved configuration</description>
        <preserve>false</preserve>
        <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
        <mode>autosaved</mode>
    </firewallDraft>
</firewallDrafts>

Cuando una directiva de firewall en Service Composer no está sincronizada debido a un grupo de seguridad eliminado, no se puede solucionar la regla de firewall en la interfaz de usuario

Solución alternativa: En la interfaz de usuario, puede eliminar la regla de firewall no válida y, a continuación, volver a agregarla. O, en la API, puede solucionar la regla de firewall eliminando el grupo de seguridad no válido. Después, sincronice la configuración del firewall: Seleccione Service Composer: Directivas de seguridad (Security Policies) y en cada directiva de seguridad que tenga reglas de firewall asociadas, haga clic en Acciones (Actions) y seleccione Sincronizar config. de firewall (Synchronize Firewall Config). Para evitar este problema, modifique las reglas de firewall para que no refieran a los grupos de seguridad antes de eliminar los grupos de seguridad.

No se puede encender la máquina virtual invitada
Cuando se enciende una máquina virtual invitada, es posible que se muestre el error En este momento, no están implementadas todas las máquinas virtuales de agente necesarias (All required agent virtual machines are not currently deployed).

Solución alternativa: Realice los pasos siguientes:

  1. En vSphere Web Client, haga clic en Inicio (Home) y, a continuación, en Administración (Administration).
  2. En Solución (Solution), seleccione Extensión de vCenter Server (vCenter Server Extension).
  3. Haga clic en vSphere ESX Agent Manager y, a continuación, haga clic en la pestaña Administrar (Manage).
  4. Haga clic en Resolver (Resolve).

Problemas conocidos de instalación y actualización

Antes de la actualización, lea la sección Notas sobre la actualización, más arriba en este documento.

DVPort no puede habilitarse con la opción Bloquearía (Would block) debido a un problema de preparación del host
En un host ESXi compatible con NSX, DVPort no puede habilitarse con la opción "Bloquearía" (Would block) debido a un problema de preparación del host. Cuando sucede esto, el mensaje de error que se observa primero varía (por ejemplo, es posible que se vea como un error de creación de VTEP en VC/hostd.log, un error de conexión de DVPort en vmkernel.log o un error SIOCSIFFLAGS en el invitado). Esto sucede cuando los VIB se cargan después de que vCenter transmite las propiedades de DVS. Esto puede suceder durante la actualización.

Solución alternativa: En NSX 6.1.4 y anteriores, es necesario volver a reiniciar para solucionar este tipo de errores de DVPort en sitios que utilizan un enrutador lógico de NSX. En NSX 6.2.0, el software NSX proporciona una mitigación. Esta mitigación ayuda a evitar un segundo reinicio en la mayoría de los casos. La causa principal es un problema conocido de vSphere. Consulte el artículo 2107951 de la base de conocimientos de VMware para obtener más detalles. Tenga en cuenta que esta mitigación también está disponible en NSX 6.1.5 y posteriores para los clientes que utilicen NSX 6.1.x.

El reemplazo del certificado de NSX Manager requiere el reinicio de NSX Manager y puede requerir el reinicio de vSphere Web Client.
Después de reemplazar el certificado del dispositivo NSX Manager, siempre se debe reiniciar el dispositivo NSX Manager. En ciertos casos, después del reemplazo del certificado, vSphere Web Client no muestra la pestaña "Redes y seguridad" (Networking and Security). Si sucede esto, siga los pasos en la solución alternativa a continuación.

Solución alternativa: Reinicie el dispositivo NSX Manager y, a continuación, reinicie vSphere Web Client.

Para reiniciar NSX Manager, realice los pasos siguientes:

  1. Inicie sesión en la CLI de NSX Manager.

  2. Cambie al modo habilitado/privilegiado. Para ello, escriba en.

  3. Detenga el servicio web-manager. Para ello, escriba no web-manager. Espere a que aparezca Aceptar (OK) como confirmación de que se detuvo.

  4. Escriba web-manager para iniciar NSX Manager. Espere a que aparezca Aceptar (OK) como confirmación de que se reinició.

  5. Para reiniciar vSphere Web Client, en vCenter 5.5, abra https://{vcenter-ip}:5480 y reinicie el servidor de Web Client.

  6. En el dispositivo vCenter 6.0, inicie sesión en el shell de vCenter Server como usuario raíz y ejecute los comandos siguientes:

    shell.set --enabled True

    shell

    localhost:~ # cd /bin

    localhost:~ # service-control --stop vsphere-client

    localhost:~ # service-control --start vsphere-client

  7. En vCenter Server 6.0, ejecute los comandos siguientes:

    cd C:\Program Files\VMware\vCenter Server\bin

    service-control --stop vsphere-client

    service-control --start vsphere-client

Después de la actualización de vCenter, es posible que vCenter pierda conectividad con NSX
Si se utiliza SSO integrado de vCenter y se actualiza vCenter 5.5 a vCenter 6.0, es posible que vCenter pierda conectividad con NSX. Esto sucede si vCenter 5.5 se registró con NSX con el nombre de usuario raíz. En NSX 6.2, el registro de vCenter con raíz es obsoleto. NOTA: Si se utiliza un SSO externo, no es necesario hacer cambios. Puede mantener el mismo nombre de usuario, por ejemplo, admin@miempresa.midominio, y la conectividad de vCenter no se perderá.

Solución alternativa: Registre vCenter con NSX con el nombre de usuario administrator@vsphere.local en lugar del de raíz.

Cerrar sistema operativo invitado para máquinas virtuales de agente (SVA) antes de apagar
Cuando se coloca un host en modo de mantenimiento, todos los dispositivos de servicio se apagan, en lugar de cerrarse de manera estable. Esto puede provocar errores en aplicaciones de terceros.

Solución alternativa: Ninguna.

No se puede encender el dispositivo de servicio que se implementó con la vista Implementaciones de servicios (Service Deployments)

Solución alternativa: Antes de continuar, compruebe lo siguiente:

  • Se completó la implementación de la máquina virtual.

  • Las tareas como clonación, reconfiguración, etc. están en curso en la máquina virtual que se muestra en el panel de tareas VC.

  • En el panel de eventos VC de la máquina virtual, se muestran los eventos siguientes una vez iniciada la implementación:
     
    Se aprovisionó la máquina virtual de agente <nombre de máquina virtual>(Agent VM <vm name> has been provisioned).
    Marque el agente como disponible para continuar con el flujo de trabajo del agente (Mark agent as available to proceed agent workflow).
     

    En tal caso, elimine la máquina virtual de servicio. En la interfaz de usuario de implementación de servicios, el estado de la implementación es Con errores (Failed). Cuando hace clic en el icono rojo, se muestra una alarma de una máquina virtual de agente no disponible para el host. Cuando resuelve la alarma, se vuelve a implementar la máquina virtual y se enciende.

Si no están preparados todos los clústeres del entorno, el mensaje de actualización de Distributed Firewall no aparece en la pestaña Preparación del host (Host Preparation) de la página Instalación (Installation)
Cuando se preparan los clústeres para la virtualización de red, se habilita Distributed Firewall en esos clústeres. Si no están preparados todos los clústeres del entorno, el mensaje de actualización de Distributed Firewall no aparece en la pestaña Preparación del host (Host Preparation).

Solución alternativa: Utilice la llamada REST siguiente para actualizar Distributed Firewall:

PUT https://<nsxmgr-ip>/api/4.0/firewall/globalroot-0/state

Si se modifica un grupo de servicios después de una actualización para agregar o quitar servicios, estos cambios no se ven reflejados en la tabla del firewall
Los grupos de servicios creados por el usuario se expanden en la tabla Firewall de Edge (Edge Firewall) durante la actualización, es decir, la columna Servicio (Service) de la tabla del firewall muestra todos los servicios incluidos en el grupo de servicios. Si se modifica el grupo de servicios después de una actualización para agregar o quitar servicios, estos cambios no se ven reflejados en la tabla del firewall.

Solución alternativa: Cree un grupo de servicios nuevo con un nombre distinto y, a continuación, utilice este grupo de servicios en la regla del firewall.

No se enciende la máquina virtual de servicios implementada desde la pestaña Implementaciones de servicios (Service Deployments) en la página Instalación (Installation)

Solución alternativa: Siga los pasos a continuación.

  1. Quite manualmente la máquina virtual de servicio del grupo de recursos Agentes de ESX (ESX Agents) en el clúster.
  2. Haga clic en Redes y seguridad (Networking and Security) y, a continuación, en Instalación (Installation).
  3. Haga clic en la pestaña Implementaciones de servicios (Service Deployments).
  4. Seleccione el servicio adecuado y haga clic en el icono Resolver (Resolve).
    Se vuelve a implementar la máquina virtual de servicio.

La MTU de vSphere Distributed Switch no se actualiza
Si se especifica un valor de MTU inferior al de la MTU del conmutador distribuido de vSphere cuando se prepara un clúster, vSphere Distributed Switch no se actualiza con este valor. Esto se hace para garantizar que el tráfico existente con el tamaño mayor de trama no se descarte de manera accidental.

Solución alternativa: Asegúrese de que la MTU que especifica cuando prepara el clúster sea mayor o igual que la MTU actual del conmutador distribuido de vSphere. La MTU mínima requerida para VXLAN es 1550.

No se puede volver a configurar SSO después de la actualización
Cuando el servidor de SSO configurado en NSX Manager es el nativo en vCenter Server, no se pueden volver a configurar las opciones de SSO en NSX Manager una vez que vCenter Server se actualizó a la versión 6.0 y NSX Manager a la versión 6.x.

Solución alternativa: Ninguna.

Después de la actualización de vCloud Networking and Security 5.5.3 a NSX for vSphere 6.0.5 o posterior, NSX Manager no arranca si se utiliza un certificado SSL con tamaño de clave DSA-1024
Los certificados SSL con tamaño de clave DSA-1024 no son compatibles con NSX for vSphere 6.0.5 y posteriores, por lo que la actualización no se completa correctamente.

Solución alternativa: Importe un certificado SSL nuevo con un tamaño de clave compatible antes de iniciar la actualización.

La VPN SSL no envía una notificación de actualización al cliente remoto
La puerta de enlace de la VPN SSL no envía una notificación de actualización a los usuarios. El administrador debe comunicar manualmente a los usuarios remotos que la puerta de enlace de la VPN SSL (servidor) está actualizada y que deben actualizar los clientes.

Después de actualizar NSX de la versión 6.0 a 6.0.x o 6.1, no aparecen los dispositivos NSX Edge en la interfaz de usuario
Cuando se actualiza de NSX 6.0 a NSX 6.0.x o 6.1, es posible que el complemento de vSphere Web Client no se actualice correctamente. Esto puede provocar problemas en la visualización de la interfaz de usuario, como, por ejemplo, que no se muestren los dispositivos NSX Edge.
Este problema no se presenta si la actualización se realiza desde NSX 6.0.1 o posterior.

Solución alternativa: Siga los pasos a continuación.

  1. En vCenter MOB, haga clic en Contenido (Content).

  2. En la columna Valor (Value), haga clic en ExtensionManager.

  3. Busque el valor de propiedad extensionList (por ejemplo, com.vmware.vShieldManager) y copie la cadena.

  4. En el área Métodos (Methods), haga clic en UnregisterExtension.

  5. En el campo Value (Valor), pegue la cadena que copió en el paso 3.

  6. Haga clic en Invocar método (Invoke Method).

Esto asegura la implementación del paquete de complementos más reciente.

No se puede actualizar NSX Edge si la VPN L2 está habilitada en Edge
La actualización de la configuración de la VPN L2 de 5.x o 6.0 a 6.1 no es compatible. Por lo tanto, no se puede actualizar Edge si tiene configurada una VPN L2.

Solución alternativa: Elimine la configuración de la VPN L2 antes de actualizar NSX Edge. Después de la actualización, vuelva a configurar la VPN L2.

Si se reinicia vCenter durante el proceso de actualización de NSX for vSphere, se muestra un estado del clúster incorrecto
Cuando se realiza la preparación del host en un entorno con varios clústeres preparados con NSX durante una actualización y vCenter Server se reinicia después de que se preparó al menos un clúster, los demás clústeres pueden mostrar el estado de clúster como No listo (Not Ready) en lugar de mostrar un vínculo de actualización. Los hosts en vCenter también pueden mostrar el estado Reinicio necesario (Reboot Required).

Solución alternativa: No reinicie vCenter durante la preparación del host.

Pérdida momentánea de la protección antivirus de terceros durante la actualización
Cuando se actualiza de NSX 6.0.x a NSX 6.1.x o 6.2.0, es posible que se produzca una pérdida momentánea de la protección antivirus de terceros en las máquinas virtuales. Este problema no afecta las actualizaciones de NSX 6.1.x a NSX 6.2.

Solución alternativa: Ninguna.

Aparece un mensaje de error del host mientras se configura Distributed Firewall
Durante la configuración del firewall distribuido, si aparece un mensaje de error sobre el host, se debe comprobar el estado de la característica del tejido com.vmware.vshield.nsxmgr.messagingInfra. Si el estado es rojo, se debe aplicar la solución alternativa siguiente.

Solución alternativa: Utilice la llamada API REST siguiente para restablecer la comunicación entre NSX Manager y un solo host o todos los hosts de un clúster.

POST https://<NSX Manager IP>/api/2.0/nwfabric/configure?action=synchronize

<nwFabricFeatureConfig>
    <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
    <resourceConfig>
        <resourceId>{HOST/CLUSTER MOID}</resourceId>
    </resourceConfig>
</nwFabricFeatureConfig>

El copiado y pegado de una regla de firewall con la opción de origen/destino negativos habilitada enumerará una regla nueva con la opción Negativo (Negate) deshabilitada
Si se copia y pega una regla de firewall con la opción de origen/destino negativos habilitada, después de la operación de pegado habrá una regla de firewall nueva; sin embargo, la opción de origen/destino negativos estará deshabilitada.

Solución alternativa: Ninguna.

El registro de NSX Manager recopila mensajes WARN messagingTaskExecutor-7 después de la actualización a NSX 6.2
Después de actualizar de NSX 6.1.x a NSX 6.2, el registro de NSX Manager se llena de mensajes similares al siguiente: WARN messagingTaskExecutor-7 ControllerInfoHandler:48 - host is unknown: host-15 return empty list. No afectan el funcionamiento.

Solución alternativa: Ninguna.

Después de actualizar de vCNS 5.5.4 a NSX 6.2.0, el firewall en la pestaña Preparación del host (Host Preparation) permanece deshabilitado
Después de actualizar de vCNS 5.5.x a NSX 6.2.0 y de actualizar todos los clústeres, el firewall en la pestaña Preparación del host (Host Preparation) permanece deshabilitado. Además, la opción para actualizar el firewall no aparece en la interfaz de usuario. Esto sucede solo cuando hay hosts que no son parte de ningún clúster preparado en el centro de datos, porque los VIB no se instalan en esos hosts.

Solución alternativa: Para resolver el problema, mueva los hosts a un clúster preparado de NSX 6.2.

Durante una actualización, las reglas de firewall L2 y L3 no se publican en los hosts
Después de publicar un cambio en la configuración de Distributed Firewall, el estado permanece en curso (in progress) tanto en la interfaz de usuario como en la API de manera indefinida, y no se escribe ningún registro para las reglas L2 o L3 en el archivo vsfwd.log.

Solución alternativa: Durante una actualización de NSX, no publique los cambios en la configuración de Distributed Firewall. Para salir del estado en curso (in progress) y resolver el problema, reinicie el dispositivo virtual NSX Manager.

Parece que la llamada API REST de NSX para habilitar o deshabilitar la detección de IP no surte efecto
Si no se completó la preparación del clúster del host, la llamada API REST de NSX para habilitar o deshabilitar la detección de IP (https://<nsxmgr-ip>/api/2.0/xvs/networks/universalwire-5/features) no surte efecto.

Solución alternativa: Antes de emitir esta llamada API, asegúrese de que se haya completado la preparación del clúster del host.

Los clientes de la VPN SSL de NSX 6.0.7 no se pueden conectar a las puertas de enlace de la VPN SSL de NSX 6.2
En las puertas de enlace de la VPN SSL de NSX 6.2, los protocolos SSLv2 y SSLv3 están deshabilitados. Esto significa que la puerta de enlace de la VPN SSL solo acepta el protocolo TLS. Los clientes de la VPN SSL versión 6.2 se actualizaron para utilizar el protocolo TLS de forma predeterminada durante el establecimiento de la conexión. En NSX 6.0.7, el cliente de VPN SSL utiliza una versión anterior de la biblioteca OpenSSL y el protocolo SSLv3 para establecer una conexión. Cuando un cliente NSX 6.0.x intenta conectarse a una puerta de enlace de NSX 6.2, se produce un error en el establecimiento de la conexión en el nivel del protocolo de enlace de SSL.

Solución alternativa: Actualice el cliente de VPN SSL a NSX 6.2 después de haber actualizado a NSX 6.2. Para ver las instrucciones de actualización, consulte la documentación de actualización de NSX.

PSOD durante actualización de ESXi
Cuando se actualiza un host vSphere 5.5U2 compatible con NSX a vSphere 6.0, es posible que algunas actualizaciones del host ESXi se detengan en una pantalla de diagnóstico de color púrpura (también conocida como PSOD).

Solución alternativa: Reinicie el host ESXi y continúe con la actualización.

Se debe crear un grupo de identificadores de segmentos para los enrutadores lógicos nuevos o actualizados
En NSX 6.2, debe haber un grupo de identificadores de segmentos con identificadores de segmentos disponibles para poder actualizar un enrutador lógico a 6.2 o crear un enrutador lógico 6.2 nuevo. Esto aplica incluso si no se planean utilizar conmutadores lógicos NSX en la implementación.

Solución alternativa: Si la implementación de NSX no tiene un grupo de identificadores de segmentos local, cree uno como requisito previo para la instalación o actualización del enrutador lógico NSX.

Error en la configuración de la puerta de enlace de VXLAN
Cuando se configura una VXLAN con un grupo de direcciones IP estáticas (en Redes y seguridad [Networking & Security] >Instalación [Installation] > Preparación del host [Host Preparation] >Configurar VXLAN [Configure VXLAN]) y la configuración no puede establecer una IP de puerta de enlace de grupo de direcciones IP en VTEP (debido a que la puerta de enlace no está correctamente configurada o no es posible comunicarse con ella), el estado de configuración de la VXLAN entra en estado de error (ROJO) en el clúster del host.

El mensaje de error es La puerta de enlace de la VXLAN no puede establecerse en el host y el estado de error es VXLAN_GATEWAY_SETUP_FAILURE. En la llamada API REST, GET https://<nsxmgr-ip>/api/2.0/nwfabric/status?resource=<cluster-moid>, el estado de la VXLAN es el siguiente:

<nwFabricFeatureStatus>
  <featureId>com.vmware.vshield.nsxmgr.vxlan</featureId>
  <featureVersion>5.5</featureVersion>
  <updateAvailable>false</updateAvailable>
  <status>RED</status>
  <message>VXLAN Gateway cannot be set on host</message>
  <installed>true</installed>
  <enabled>true</enabled>
  <errorStatus>VXLAN_GATEWAY_SETUP_FAILURE</errorStatus>
</nwFabricFeatureStatus>

Solución alternativa: Existen dos opciones para solucionar el error.

  • Opción 1: Quite la configuración de la VXLAN del clúster del host, solucione la configuración de la puerta de enlace subyacente en el grupo de direcciones IP (asegúrese de que la puerta de enlace esté configurada correctamente y de que se pueda establecer una comunicación con ella) y, a continuación, vuelva a configurar la VXLAN del clúster del host.

  • Opción 2: Realice los pasos siguientes.

    1. Solucione la configuración de la puerta de enlace subyacente en el grupo de direcciones IP; para ello, asegúrese de que la puerta de enlace esté configurada correctamente y de que se pueda establecer una comunicación con ella.

    2. Coloque el host (o los hosts) en modo de mantenimiento para asegurar que no haya tráfico de máquina virtual activo en el host.

    3. Elimine los VTEP de la VXLAN del host.

    4. Finalice el modo de mantenimiento del host. Al finalizar el modo de mantenimiento del host, se activa el proceso de creación de VTEP de la VXLAN en NSX Manager. NSX Manager intenta recrear los VTEP necesarios en el host.

En una implementación de Cross vCenter, es posible que una sección de configuración universal esté bajo (subordinada a) una sección de configuración local
Si se traslada una instancia de NSX Manager secundaria al estado independiente (tránsito) y, a continuación, se la regresa al estado secundario, cualquier cambio en la configuración local que se haya hecho mientras se encontraba de forma temporal en modo independiente puede aparecer sobre las secciones de configuración universal replicadas heredadas de la instancia de NSX Manager principal. Esto genera la condición de error la sección universal debe estar sobre todas las demás secciones en las instancias de NSX Manager secundarias (universal section has to be on top of all other sections on secondary NSX Managers).

Solución alternativa: Utilice la opción de la interfaz de usuario para mover las secciones hacia arriba o abajo de modo que la sección local se encuentre debajo de la universal.

Después de una actualización, es posible que las reglas de firewall y los servicios de introspección de red no estén sincronizados con NSX Manager
Después de actualizar de NSX 6.0 a NSX 6.1 o 6.2, la configuración del firewall de NSX muestra el mensaje de error: error de sincronización/no sincronizado (synchronization failed / out of sync). La acción Forzar servicios de sincronización: Firewall (Force Sync Services: Firewall) no resuelve el problema.

Solución alternativa: En NSX 6.1 y NSX 6.2, tanto los grupos de seguridad como los dvPortgroups pueden estar enlazados a un perfil de servicio, pero no los dos al mismo tiempo. Para resolver este problema, modifique los perfiles de servicio.

El VIB esx-dvfilter-switch-security ya no está presente en el resultado del comando "esxcli software vib list | grep esx"
A partir de NSX 6.2, los módulos esx-dvfilter-switch-security se incluyen en el VIB esx-vxlan. Los únicos VIB de NSX instalados para la versión 6.2 son esx-vsip y esx-vxlan. Durante una actualización de NSX a 6.2, el VIB antiguo esx-dvfilter-switch-security se quita de los hosts ESXi.

Solución alternativa: Ninguna.

Después de la actualización, es posible que los enrutadores lógicos con formación de equipos por conmutación por error explícita configurada no puedan reenviar correctamente los paquetes
Cuando los hosts ejecutan ESXi 5.5, la directiva de formación de equipos de NSX 6.2 por conmutación por error explícita no es compatible con varios vínculos superiores activos en los enrutadores lógicos distribuidos.

Solución alternativa: Altere la directiva de formación de equipos por conmutación por error explícita de modo que haya solo un vínculo superior activo y que los demás vínculos superiores se encuentren en modo en espera.

La desinstalación de NSX de un clúster de hosts a veces genera una condición de error
Cuando se utiliza la acción Desinstalar (Uninstall) en la pestaña Instalación (Installation): Preparación del host (Host Preparation) es posible que ocurra un error y aparezca el mensaje eam.issue.OrphanedAgency en los registros de EAM de los hosts. Después de utilizar la acción Resolver (Resolve) y de reiniciar los hosts, el estado de error continúa a pesar de que se desinstalaron correctamente los VIB de NSX.

Solución alternativa: Elimine la agencia huérfana de vSphere ESX Agent Manager (Administración [Administration]: Extensiones de vCenter Server [vCenter Server Extensions]: vSphere ESX Agent Manager).

SSLv2 y SSLv3 obsoletos en NSX 6.2
A partir de NSX 6.2, la puerta de enlace de la VPN SSL solo acepta el protocolo TLS. Después de la actualización de NSX, cualquier cliente de NSX 6.2 nuevo que cree utilizará automáticamente el protocolo TLS durante el establecimiento de la conexión. Cuando un cliente NSX 6.0.x intenta conectarse a una puerta de enlace de NSX 6.2, se produce un error en el establecimiento de la conexión en el paso del protocolo de enlace de SSL.

Solución alternativa: Después de la actualización a NSX 6.2, desinstale los clientes de la VPN SSL antiguos e instale la versión NSX 6.2 de los clientes de la VPN SSL.

vSphere Web Client no muestra la pestaña Redes y seguridad (Networking and Security) después de la copia de seguridad y restauración en NSX for vSphere 6.2
Cuando realiza una operación de copia de seguridad y restauración después de la actualización a NSX for vSphere 6.2, vSphere Web Client no muestra la pestaña Redes y seguridad (Networking and Security).

Solución alternativa: Cuando se restaura una copia de seguridad de NSX Manager, se cierra la sesión del Administrador de dispositivos (Appliance Manager). Espere unos minutos antes de iniciar sesión en vSphere Web Client.

Después de la actualización a NSX 6.2, NSX Manager tiene un porcentaje superior a 100 de memoria física asignada
A partir de NSX 6.2, NSX Manager requiere 16 GB de memoria reservada. El requisito anterior era de 12 GB.

Solución alternativa: Aumente la memoria reservada del dispositivo virtual NSX Manager a 16 GB.

Después de la actualización de NSX, Guest Introspection no se puede comunicar con NSX Manager
Después de actualizar de NSX 6.0.x a NSX 6.1.x o de NSX 6.0.x a NSX 6.2 y antes de que se actualice el servicio Guest Introspection, NSX Manager no se puede comunicar con Universal Service Virtual Machine (USVM) de Guest Introspection. La pérdida de comunicación entre NSX Manager y Guest Introspection lleva a una pérdida de protección de las máquinas virtuales en el clúster de NSX cuando hay un cambio en las máquinas virtuales, como adiciones de máquinas virtuales, migraciones de vMotion o eliminaciones. La pestaña Instalación de NSX (NSX Installation) > Implementaciones de servicios (Service Deployments) muestra la versión actual de Guest Introspection. Cuando se presenta este problema, aparece una advertencia en la columna Estado de servicio (Service Status). El mensaje de advertencia incluye la lista de hosts afectados y el mensaje de error Guest Introspection no está listo.

Solución alternativa: Para resolver el problema, siga el procedimiento para actualizar Guest Introspection en la documentación de actualización de NSX.

El estado del servicio Data Security se muestra como Activo (UP) incluso si no hay conectividad IP
Es posible que el dispositivo Data Security no haya recibido la dirección IP del DHCP o que esté conectado a un grupo de puertos incorrecto.

Solución alternativa: Asegúrese de que el dispositivo Data Security obtenga la dirección IP del grupo de direcciones IP/DHCP y de que se pueda establecer una comunicación con él desde la red de administración. Compruebe que se haga ping hacia el dispositivo Data Security desde NSX/ESX correctamente.

Problemas conocidos de NSX Manager

Service Composer pierde la sincronización cuando se realizan cambios en la directiva mientras una de las instancias de Service Manager está inactiva.
Esto se relaciona con las instancias de varios servicios/Service Manager registrados y con las directivas creadas que hacen referencia a esos servicios. Si se hacen cambios en Service Composer a dicha directiva cuando una de las instancias de Service Manager está inactiva, se produce un error en los cambios debido al error de devolución de llamada a la instancia de Service Manager inactiva. Como resultado, Service Composer pierde la sincronización.

Solución alternativa: Asegúrese de que Service Manager responda y, a continuación, emita una sincronización forzada desde Service Composer.

No se muestra la pestaña Redes y seguridad (Networking and security) en vSphere Web Client
Una vez que vSphere se actualizó a la versión 6.0, no se puede ver la pestaña Redes y seguridad (Networking and Security) cuando se inicia sesión en vSphere Web Client con el nombre de usuario raíz.

Solución alternativa: Inicie sesión como administrator@vsphere.local o como cualquier otro usuario de vCenter que existía en vCenter Server antes de la actualización y cuyo rol se definió en NSX Manager.

Una vez restaurada la copia de seguridad de NSX Manager, la llamada REST muestra el estado de la característica del tejido com.vmware.vshield.nsxmgr.messagingInfra en rojo
Cuando se restaura la copia de seguridad de una instancia de NSX Manager y se comprueba el estado de la característica del tejido com.vmware.vshield.nsxmgr.messagingInfra con una llamada API REST, se muestra en rojo en lugar de verde.

Solución alternativa: Utilice la llamada API REST siguiente para restablecer la comunicación entre NSX Manager y un solo host o todos los hosts de un clúster.

POST https://<NSX Manager IP>/api/2.0/nwfabric/configure?action=synchronize

<nwFabricFeatureConfig>
    <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
    <resourceConfig>
        <resourceId>{HOST/CLUSTER MOID}</resourceId>
    </resourceConfig>
</nwFabricFeatureConfig>

No se puede quitar y volver a agregar un host a un clúster protegido por Guest Introspection y soluciones de seguridad de terceros
Si se desconecta y quita un host de vCenter Server con el fin de quitarlo de un clúster protegido por Guest Introspection y soluciones de seguridad de terceros, es posible que surjan problemas si se intenta volver a agregar el mismo host al clúster.

Solución alternativa: Para quitar un host de un clúster protegido, primero coloque el host en modo de mantenimiento. Después, mueva el host a un clúster sin protección o fuera de todos los clústeres y, a continuación, desconecte y quite el host.

Es posible que vMotion de NSX Manager muestre el error "El adaptador de red 1 de la tarjeta Ethernet virtual no es compatible" (Virtual ethernet card Network adapter 1 is not supported)
Se puede ignorar este error. Las redes funcionan correctamente después de vMotion.

Syslog muestra el nombre del host de la instancia de NSX Manager de la que se realizó una copia de seguridad en la instancia de NSX Manager restaurada
Supongamos que el nombre de host de la primera instancia de NSX Manager es A y que se crea una copia de seguridad de esa instancia de NSX Manager. Ahora se instala y configura una segunda instancia de NSX Manager en la misma dirección IP que la instancia de Manager antigua según los documentos de restauración de copia de seguridad, pero el nombre de host es B. Se ejecuta una restauración en esta instancia de NSX Manager. La instancia de NSX Manager restaurada muestra el nombre de host A justo después de la restauración y el nombre de host B nuevamente después del reinicio.

Solución alternativa: El nombre de host de la segunda instancia de NSX Manager debe configurarse para que sea igual a la instancia de NSX Manager de la que se realizó una copia de seguridad.

La página de resumen del dispositivo virtual NSX Manager no muestra ningún nombre DNS
Cuando se inicia sesión en el dispositivo virtual NSX Manager, la página Resumen (Summary) tiene un campo para el nombre DNS. Este campo permanece en blanco a pesar de que se definió un nombre DNS para el dispositivo NSX Manager.

Solución alternativa: Puede ver el nombre de host y los dominios de búsqueda de NSX Manager en la página Administrar (Manage): Red (Network).

La interfaz de usuario de NSX Manager no cierra automáticamente la sesión de los usuarios después de cambiar la contraseña con NSX Command Line Interface
Si se está conectado a NSX Manager y se acaba de cambiar la contraseña con la CLI, es posible continuar conectado a la interfaz de usuario de NSX Manager con la contraseña antigua. Por lo general, el cliente NSX Manager debería cerrar la sesión automáticamente si se agota el tiempo de espera de la sesión por inactividad.

Solución alternativa: Cierre la sesión de la interfaz de usuario de NSX Manager y vuelva a iniciar sesión con la contraseña nueva.

NSX Manager independiente permite incorrectamente la importación de la configuración de firewall universal
Por lo general, NSX Manager con el rol independiente debería permitir solo la importación de reglas de firewall locales. A partir de NSX 6.2, NSX Manager puede ejecutarse con el rol independiente (para la administración de redes de una instancia de vCenter) o en el modo Cross vCenter en el que permite, incorrectamente, importar una regla de firewall universal en un entorno NSX Manager que se ejecuta con el rol independiente. Una vez importadas, no se pueden eliminar las reglas de firewall universales a través de la API REST o de vSphere Web Client. Esto se debe a que el administrador se ejecuta actualmente con el rol independiente en el que la sección universal se trata como una local.

Solución alternativa: Si ejecuta NSX Manager con el rol independiente, no importe una configuración de firewall que contenga reglas universales. Si ya importó una regla de firewall universal en una instancia de NSX Manager independiente, solucione el problema importando un archivo de configuración de firewall guardado que no contenga reglas universales, y publique ese archivo de configuración cargándolo en la tabla Firewall.
Realice los pasos siguientes:

  1. Inicie sesión en vSphere Web Client.

  2. Haga clic en Redes y seguridad (Networking & Security) y, a continuación, en Firewall.

  3. Haga clic en la pestaña Firewall.

  4. Haga clic en la pestaña Configuraciones guardadas (Saved Configurations).

  5. Haga clic en el icono Importar configuración (importar) (Import configuration [import]).

  6. Haga clic en Examinar (Browse) y seleccione el archivo que contiene la configuración que desea importar.

    Las reglas se importan según los nombres de las reglas. Durante la importación, el firewall se asegura de que cada objeto al que se hace referencia en la regla exista en el entorno. Si no se encuentra un objeto, la regla se marca como no válida. Si una regla hacía referencia a un grupo de seguridad dinámico, el grupo de seguridad dinámico se crea en NSX Manager durante la importación.

  7. Vuelva a agregar el nodo como un nodo secundario. La sincronización entre las instancias de NSX Manager sincroniza automáticamente la sección universal de forma correcta mediante cualquier limpieza necesaria.

    Una vez que se haya publicado correctamente el archivo de configuración, las reglas se transmiten al host e impactan en la ruta de datos. El sistema funciona del modo esperado.

No se puede editar un nombre de host de red
Una vez que inicia sesión en el dispositivo virtual NSX Manager y se desplaza hasta Administración de dispositivos (Appliance Management), hace clic en Administrar configuración de dispositivos (Manage Appliance Settings) y en Red (Network) en la sección Configuración (Settings) para editar el nombre de host de red, es posible que aparezca un error de lista de nombres de dominio no válida. Esto sucede cuando los nombres de dominio especificados en el campo Buscar dominios (Search Domains) se separan con caracteres de espacios en blanco en lugar de comas. NSX Manager solo acepta nombres de dominio separados por coma.
Solución alternativa: Realice los pasos siguientes:

  1. Inicie sesión en el dispositivo virtual NSX Manager.

  2. En Administración de dispositivos (Appliance Management), haga clic en Administrar configuración de dispositivos (Manage Appliance Settings).

  3. En el panel Configuración (Settings), haga clic en Red (Network).

  4. Haga clic en Editar (Edit) junto a Servidores DNS (DNS Servers).

  5. En el campo Buscar dominios (Search Domains), reemplace todos los caracteres de espacios en blanco por comas.

  6. Haga clic en Aceptar (OK) para guardar los cambios.

Se genera un evento falso del sistema incluso después de restaurar correctamente NSX Manager desde una copia de seguridad
Después de restaurar correctamente NSX Manager desde una copia de seguridad, aparecen los eventos del sistema siguientes en vSphere Web Client cuando se desplaza hasta Redes y seguridad (Networking & Security): NSX Manager: Monitor (Supervisar): Eventos del sistema (System Events).

  • Restore of NSX Manager from backup failed (with Severity=Critical).

  • Restore of NSX Manager successfully completed (with Severity=Informational).

Solución alternativa: Si el mensaje del evento del sistema final muestra que se completó correctamente, puede omitir los mensajes de eventos generados por el sistema.

Cambio en el comportamiento de la llamada API REST de NSX para agregar un espacio de nombre en un centro de datos
En NSX 6.2, la llamada API REST POST https://<nsxmgr-ip>/api/2.0/namespace/datacenter/ devuelve una URL con una ruta de acceso absoluta, por ejemplo, http://198.51.100.3/api/2.0/namespace/api/2.0/namespace/datacenter/datacenter-1628/2. En las versiones anteriores de NSX, esta llamada API devolvía una URL con una ruta de acceso relativa, por ejemplo: /api/2.0/namespace/datacenter/datacenter-1628/2.

Solución alternativa: Ninguna.

Problemas conocidos de enrutamiento lógico y NSX Edge

El enrutador lógico distribuido anuncia un salto siguiente incorrecto de la ruta predeterminada cuando el filtro vecino BGP está establecido en "CUALQUIERA , FUERA , DENEGAR" (ANY , OUT , DENY)
Con la opción Origen predeterminado (Default Originate) habilitada en un enrutador lógico distribuido (DLR) de NSX, establecer un filtro vecino BGP "CUALQUIERA , FUERA , DENEGAR" (ANY , OUT , DENY) en el DLR hace que el DLR anuncie una dirección de salto siguiente incorrecta para la ruta predeterminada. Este error se produce solo cuando se agrega un filtro vecino BGP con los atributos siguientes:

  • Dirección: FUERA (OUT)
  • Acción: Denegar (Deny)
  • Red: Cualquiera (Any)

Solución alternativa: Ninguna.

Deshabilitar un protocolo de enrutamiento en NSX Edge puede provocar una pérdida temporal del tráfico de datos
Al deshabilitar un protocolo de enrutamiento en NSX Edge no se envía una solicitud route-withdraw a un elemento del mismo nivel, por lo que el tráfico permanece en un agujero negro hasta que se agota el temporizador de inactividad/retención.

Solución alternativa: Ninguna.

Las rutas LIF del enrutador lógico se anuncian mediante la puerta de enlace de servicios Edge ascendente incluso si el protocolo OSPF del enrutador lógico está deshabilitado
La puerta de enlace de servicios Edge ascendente sigue anunciando los LSA externos de OSPF que se conocieron por las interfaces conectadas del enrutador lógico aun cuando el protocolo OSPF del enrutador lógico está deshabilitado.

Solución alternativa: Deshabilite la redistribución de rutas conectadas a OSPF manualmente y publique antes de deshabilitar el protocolo OSPF. Esto garantiza que las rutas se retiren correctamente.

Syslog de ESG no puede hacer envíos al servidor remoto, muestra que no puede resolver el nombre de host; sin embargo, la resolución DNS funciona
Inmediatamente después de la implementación de Edge, Syslog no puede resolver los nombres de host de ningún servidor Syslog remoto configurado.

Solución alternativa: Configure los servidores de Syslog remotos con sus direcciones IP o utilice la interfaz de usuario para forzar la sincronización de Edge. Este problema se observó por primera vez en la versión 6.2.

Los ajustes de configuración del cliente DNS del enrutador lógico no se aplicaron por completo luego de la actualización de la API Edge REST

Solución alternativa: Cuando utilice una API REST para configurar el reenviador de DNS (resolución), realice los pasos siguientes:

  1. Especifique la misma configuración de los servidores XML del cliente DNS que para el reenviador de DNS.

  2. Habilite el reenviador de DNS y asegúrese de que la configuración del reenviador sea la misma que la configuración de los servidores del cliente DNS especificada en XML.

  3. Mensaje de error y validación ausentes en salto siguiente no válido en la ruta estática, con ECMP habilitado
    Cuando se intenta agregar una ruta estática, con ECMP habilitado, si la tabla de enrutamiento no contiene una ruta predeterminada y hay un salto siguiente al que no se puede acceder en la configuración de la ruta estática, no se muestra ningún mensaje de error y la ruta estática no se instala.

    Solución alternativa: Ninguna.

    Si una máquina virtual NSX Edge con una subinterfaz respaldada por un conmutador lógico se elimina a través de la interfaz de usuario de vCenter Web Client, es posible que la ruta de datos no funcione para una máquina virtual nueva que se conecta al mismo puerto
    Cuando se elimina la máquina virtual Edge a través de la interfaz de usuario de vCenter Web Client (y no desde NSX Manager), el tronco de VXLAN configurado en dvPort por canal opaco no se restablece. Esto se debe a que NSX Manager administra la configuración del tronco.

    Solución alternativa: Elimine manualmente la configuración del tronco de VXLAN con los pasos siguientes:

    1. Desplácese hasta el Explorador de objetos administrados de vCenter (vCenter Managed Object Browser); para ello, escriba lo siguiente en la ventana del explorador:
      https://<vc-ip>/mob?vmodl=1
    2. Haga clic en Contenido (Content).
    3. Recupere el valor dvsUuid con los pasos siguientes.
      1. Haga clic en el vínculo rootFolder (por ejemplo, group-d1(Datacenters)).
      2. Haga clic en el vínculo del nombre del centro de datos (por ejemplo, datacenter-1).
      3. Haga clic en el vínculo networkFolder (por ejemplo, group-n6).
      4. Haga clic en el vínculo del nombre de DVS (por ejemplo, dvs-1)
      5. Copie el valor de uuid.
    4. Haga clic en DVSManager y, a continuación, en updateOpaqueDataEx.
    5. En selectionSet, agregue el XML siguiente.
      <selectionSet xsi:type="DVPortSelection">
        <dvsUuid>value</dvsUuid>
        <portKey>value</portKey> <!--port number of the DVPG where trunk vnic got connected-->
      </selectionSet>
    6. En opaqueDataSpec, agregue el XML siguiente.
      <opaqueDataSpec>
        <operation>remove</operation>
        <opaqueData>
          <key>com.vmware.net.vxlan.trunkcfg</key>
          <opaqueData></opaqueData>
        </opaqueData>
      </opaqueDataSpec>
    7. Establezca isRuntime en falso.
    8. Haga clic en Invocar método (Invoke Method).
    9. Repita los pasos 5 a 8 para cada puerto troncal configurado en la máquina virtual Edge eliminada.

    Problemas conocidos de los servicios de seguridad

    No se pueden crear reglas universales nuevas y las reglas universales existentes no se pueden editar desde la interfaz de usuario de Flow Monitoring

    Solución alternativa: No se pueden agregar ni editar reglas universales desde la interfaz de usuario de Flow Monitoring. Se deshabilitará automáticamente EditRule.

    Configuración del firewall de Service Composer no sincronizada
    En NSX Service Composer, si cualquier directiva de firewall no es válida (por ejemplo, si se eliminó un grupo de seguridad que se utilizaba en una regla de firewall en ese momento), eliminar o modificar otra directiva de firewall hace que Service Composer pierda la sincronización y se muestra el mensaje de error Configuración de firewall no sincronizada.

    Solución alternativa: Elimine cualquier regla de firewall no válida y, a continuación, sincronice la configuración del firewall. Seleccione Service Composer: Directivas de seguridad (Security Policies) y en cada directiva de seguridad que tenga reglas de firewall asociadas, haga clic en Acciones (Actions) y seleccione Sincronizar config. de firewall (Synchronize Firewall Config). Para evitar este problema, solucione o elimine siempre las configuraciones de firewall no válidas antes de realizar más cambios de configuración en el firewall.

    El nombre de la directiva de seguridad no permite más de 229 caracteres
    El campo Nombre de directiva de seguridad (Security Policy Name) en la pestaña Directiva de seguridad (Security Policy) de Service Composer puede aceptar hasta 229 caracteres. Esto se debe a que los nombres de las directivas están antecedidos por un prefijo.

    Solución alternativa: Ninguna.

    Algunas versiones de VM-Series de Palo Alto Networks no funcionan con la configuración predeterminada de NSX Manager
    Algunos componentes de NSX 6.1.4 deshabilitan SSLv3 de forma predeterminada. Antes de realizar la actualización, es necesario comprobar que todas las soluciones de terceros integradas en la implementación de NSX no dependan de la comunicación de SSLv3. Por ejemplo, algunas versiones de la solución VM-Series de Palo Alto Networks requieren compatibilidad con SSLv3, por lo que es necesario comprobar los requisitos de la versión con los proveedores.

    En las instalaciones de NSX actualizadas, es posible que la publicación de una regla de firewall de como resultado la excepción de puntero nulo (Null Pointer exception) en Web Client
    En las instalaciones de NSX actualizadas, es posible que la publicación de una regla de firewall de como resultado la excepción de puntero nulo (Null Pointer exception) en la interfaz de usuario. Se guardan los cambios realizados en la regla. Este es solo un problema de visualización.

    Si se elimina la configuración de firewall con una llamada API REST, no se puede cargar y publicar la configuración guardada
    Cuando se elimina la configuración de firewall, se crea una sección predeterminada nueva con un identificador de sección nuevo. Cuando se carga un borrador guardado (con el mismo nombre de sección, pero un identificador de sección anterior), los nombres de sección entran en conflicto y muestran el error siguiente:
    Los valores clave duplicados infringen la restricción exclusiva firewall_section_name_key (Duplicate key value violates unique constraint firewall_section_name_key)

    Solución alternativa: Realice una de las tareas siguientes:

    • Cambie el nombre de la sección de firewall predeterminada actual después de cargar una configuración guardada.
    • Cambie el nombre de la sección predeterminada en una configuración guardada cargada antes de publicarla.

    Problemas conocidos de servicios de supervisión

    No se pueden agregar más de ocho interfaces de vínculo superior durante la implementación del enrutador lógico distribuido (DLR) con vSphere Web Client

    Solución alternativa: Espere a que finalice la implementación de DLR y, a continuación, agregue interfaces adicionales al enrutador lógico distribuido.

    Problemas resueltos

    Los problemas siguientes se resolvieron en la versión 6.2.0:

    Los problemas resueltos se agrupan de la siguiente manera:

    Problemas de instalación y actualización resueltos

    • Después de actualizar NSX for vSphere de la versión 6.0.7 a la 6.1.3, ocurre un error en la pantalla de inicio de sesión de vSphere Web Client
      Después de actualizar NSX Manager de la versión 6.0.7 a la 6.1.3, se muestran excepciones en la pantalla de inicio de sesión de la interfaz de usuario de vSphere Web Client. No es posible iniciar sesión ni realizar operaciones en vCenter o NSX Manager.

      Este problema se solucionó en NSX 6.2.0.

    • Error en la instalación de Guest Introspection
      Cuando se instala Guest Introspection en un clúster, se produce el error siguiente en la instalación:
      Formato de módulo VIB no válido (Invalid format for VIB Module)

      Este problema se solucionó en NSX 6.2.0.

    • Error en los intentos de eliminar la puerta de enlace de NSX Edge existente en un entorno actualizado a NSX 6.1.4
      En las instalaciones de NSX que se actualizaron de la versión 6.1.3 a la 6.1.4, no se pueden eliminar las puertas de enlace de NSX Edge existentes después de la actualización a la versión 6.1.4. Este problema no afecta a las puertas de enlace Edge nuevas creadas después de la actualización. Las instalaciones que se actualizaron directamente desde la versión 6.1.2 o anterior no se ven afectadas por este problema.

      Este problema se solucionó en NSX 6.2.0.

    • El cifrado AES no está disponible cuando se realiza una copia de seguridad de NSX con una copia de seguridad de FTP protegida por terceros

      Este problema se solucionó en NSX 6.2.0.

    • La interfaz de usuario de NSX Manager no muestra mensajes de error fáciles de comprender para el usuario durante el reinicio del host
      En esta versión 6.2, la interfaz de usuario de NSX Manager se actualizó para mostrar mensajes de error detallados que describen los problemas que se pueden presentar durante el reinicio del host y proporcionan soluciones posibles.

      Este problema se solucionó en NSX 6.2.0.

    • No se puede instalar la instalación de VIB de NSX
      Es posible que la instalación de VIB de NSX no se complete como se esperaba si el controlador ixgbe no se carga correctamente desde el módulo de terceros porque se bloqueó, y esto evita que se utilice para la instalación.

      Este problema se solucionó en NSX 6.2.0.

    • No se puede iniciar el servicio NSX Manager después de actualizar de vCloud Networking and Security (vCNS) 5.5.3
      Después de actualizar vCloud Networking and Security (vCNS) 5.5.3 a NSX 6.1.3, el servicio NSX Manager no responde y no se puede iniciar correctamente.

      Este problema se solucionó en NSX 6.2.0.

    • Aleatoriamente, el bus de mensajes no se inicia después del reinicio de NSX Edge
      Después de reiniciar una máquina virtual Edge, con frecuencia, el bus de mensajes no se inicia correctamente después del encendido y es necesario reiniciar nuevamente.

      Este problema se solucionó en NSX 6.2.0.

    Problemas de NSX Manager resueltos

    • Agregar dominio (Add Domain) muestra un error en la opción LDAP con Utilizar credenciales de dominio (Use Domain Credentials)
      En NSX 6.1.x, cuando el usuario intenta agregar un dominio LDAP, el cliente web muestra el error No se especificó el nombre de usuario (User Name was not specified), incluso cuando se proporcionó un nombre de usuario en la interfaz de usuario. Este problema se solucionó en NSX 6.2.0.

      Este problema se solucionó en NSX 6.2.0.

    • La importación del certificado firmado por una entidad de certificación requiere el reinicio de NSX Manager para poder aplicarse
      Cuando se importa un certificado firmado por una entidad de certificación de NSX Manager, el certificado recién importado no se aplica hasta que se reinicia NSX Manager.

      Este problema se solucionó en NSX 6.2.0.

    • No se puede importar NSX Manager en el dominio LDAPS
      Cuando se intenta agregar NSX Manager al dominio LDAPS, aparece el mensaje de error siguiente.
      No es posible conectarse al host <FQDN del servidor>
      mensaje de error: error de enlace simple: <FQDN del servidor:Número> (Cannot connect to host <Server FQDN> error message: simple bind failed: <Server FQDN:Number>)

      Este problema se solucionó en NSX 6.2.0.

    • NSX Manager no funciona después de ejecutar el comando write erase
      Cuando se reinicia NSX Manager después de ejecutar el comando write erase, es posible que NSX Manager no funcione como se espera; por ejemplo, se restableció la contraseña para acceder al shell de Linux, falta el comando de configuración, etc.

      Este problema se solucionó en NSX 6.2.0.

    Problemas de redes lógicas resueltos

    • Los filtros BGP demoran aproximadamente 40 segundos para aplicarse de forma efectiva
      Durante este período, todas las directivas de redistribución se aplican sin filtros. Esta demora corresponde solo al enrutador lógico distribuido (DLR) NSX para las direcciones FUERA (OUT).

      Este problema se solucionó en NSX 6.2.0.

    • En las subinterfaces NSX Edge, los redireccionamientos de ICMP se envían, incluso cuando la opción Enviar redireccionamiento de ICMP (Send ICMP redirect) está deshabilitada
      De forma predeterminada, las subinterfaces NSX Edge tienen la opción Enviar redireccionamiento de ICMP (Send ICMP redirect) deshabilitada. A pesar de que está opción está deshabilitada, los redireccionamientos de ICMP se envían en las subinterfaces de Edge.

      Este problema se solucionó en NSX 6.2.0.

    • No se pueden agregar caracteres no ASCII en el nombre de puente o empresa en el enrutador lógico
      Las API de NSX Controller no son compatibles con caracteres no ASCII.

      Este problema se solucionó en NSX 6.2.0.

    • Cuando se modifica una regla de filtro de vecino BGP, es posible que los filtros existentes no se apliquen por hasta 40 segundos
      Cuando se aplican filtros BGP a una instancia de NSX Edge que ejecuta IBGP, es posible que los filtros demoren hasta 40 segundos en aplicarse en la sesión IBGP. Durante este período, es posible que NSX Edge anuncie rutas que se deniegan en el filtro BGP para el IBGP del mismo nivel.

      Este problema se solucionó en NSX 6.2.0.

    • Una de las controladoras NSX Controller no entrega el rol maestro a otras controladoras cuando se apaga
      Por lo general, cuando una controladora asume el rol maestro de operaciones y se prepara para apagarse, entrega automáticamente el rol maestro a otras controladoras. En este caso, la controladora no entrega el rol a otras controladoras y el estado se interrumpe y, a continuación, pasa a modo desconectado.

      Este problema se solucionó en NSX 6.2.0.

    • No se puede pasar tráfico de VXLAN entre hosts con unidifusión o multidifusión
      Cuando las máquinas virtuales se encuentran en el mismo host, pueden comunicarse en toda la VXLAN con unidifusión o multidifusión, pero no pueden comunicarse cuando las máquinas virtuales se encuentran en hosts diferentes.

      Este problema se solucionó en NSX 6.2.0.

    • La eliminación de varias reglas BGP en NSX Edge/DLR al mismo tiempo provoca errores en el cliente web

      Este problema se solucionó en NSX 6.2.0. Ahora puede eliminar varias reglas BGP al mismo tiempo.

    • La dirección del protocolo se muestra brevemente después de agregar la regla de denegación de Border Gateway Protocol (BGP)
      Es posible que se observe que la dirección del protocolo se muestra brevemente después de agregar la regla de denegación de Border Gateway Protocol (BGP) en la puerta de enlace de servicios NSX Edge.

      Este problema se solucionó en NSX 6.2.0.

    • Las máquinas virtuales se desconectan durante la ejecución de vMotion
      Es posible que se observe que las máquinas virtuales se desconectan durante la ejecución de vMotion o que se reciban alertas por máquinas virtuales con NIC desconectadas.

      Este problema se solucionó en NSX 6.2.0.

    • No se puede descargar instantánea de controladora
      Cuando se descargan instantáneas de la controladora, es posible que no se pueda descargar la instantánea de la última controladora. Por ejemplo, si hay tres controladoras, una puede descargar correctamente las instantáneas de las primeras dos, pero es posible que ocurra un error al descargar la instantánea de la tercera controladora.

      Este problema se solucionó en NSX 6.2.0.

    Problemas de servicios Edge y de redes resueltos

    • Cuando HA está habilitado en la puerta de enlace de servicios Edge, los intervalos de saludo y de inactividad de OSPF configurados con valores distintos a 30 segundos y 120 segundos respectivamente pueden provocar cierta pérdida de tráfico durante la conmutación por error
      Cuando se produce un error en el NSX Edge principal con OSPF en ejecución y HA habilitado, el tiempo requerido para que el modo inactivo asuma el control excede el tiempo de espera de reinicio estable y hace que los vecinos OSPF quiten las rutas conocidas de su tabla de base de información de reenvío (Forwarding Information Base, FIB). Esto genera una interrupción en el plano de datos hasta que converjan los reinicios de OSPF.

      Este problema se solucionó en NSX 6.2.0.

    • Las máquinas virtuales no pueden recibir el ping del servidor DHCP Edge
      Las máquinas virtuales pueden hacer ping en la puerta de enlace de Edge pero no pueden recibir un ping DHCP de un tronco de puerta de enlace de Edge a través de una red superpuesta. El servidor DHCP Edge está configurado como un puerto troncal y no puede pasar ni recibir nada de tráfico. Sin embargo, cuando la puerta de enlace de Edge y Edge DHCP se encuentran en el mismo host, pueden hacerse ping mutuamente. Cuando Edge DHCP se mueve a otro host, Edge DHCP no puede recibir un ping de la puerta de enlace de Edge.

      Este problema se solucionó en NSX 6.2.0.

    • Las estadísticas del equilibrador de carga Edge no se muestran correctamente en vSphere Web Client
      El equilibrador de carga no muestra la cantidad de estadísticas de conexión simultáneas en el gráfico de la interfaz de usuario de vSphere Web Client.

      Este problema se solucionó en NSX 6.2.0.

    • Cuando se quita la red agregada directa en una subred local y remota de un canal VPN IPsec, la ruta agregada a las subredes indirectas de la instancia de Edge del mismo nivel también desaparece
      Cuando no hay una puerta de enlace predeterminada en Edge y se quitan todas las subredes de conexión directa en subredes locales y parte de las subredes remotas al mismo tiempo cuando se configura IPsec, las subredes del mismo nivel restantes quedan fuera del alcance de la VPN IPsec.

      Este problema se solucionó en NSX 6.2.0.

    • No se puede pasar tráfico a través del equilibrador de carga después de actualizar a NSX 6.1.2 o posterior
      Cuando se utiliza la opción Insertar X-Forwarded-For (Insert X-Forwarded-For) en el equilibrador de carga de NSX Edge, es posible que el tráfico no pase por el equilibrador de carga.

      Este problema se solucionó en NSX 6.2.0.

    • La ejecución del comando clear ip ospf neighbor devuelve un error de segmentación

      Este problema se solucionó en NSX 6.2.0.

    • No se pueden procesar las solicitudes de Kerberos
      Se produce un error en ciertas solicitudes de Kerberos cuando se equilibran con una instancia de NSX Edge.

      Este problema se solucionó en NSX 6.2.0.

    Problemas de servicios de seguridad resueltos

    • El vsfwd.log se sobrescribe rápidamente con una gran cantidad de actualizaciones del contenedor
      Una vez que se modifica la directiva SpoofGuard, NSX Manager envía sin demora el cambio al host, pero el host demora más en procesar el cambio y actualizar el estado de SpoofGuard de la máquina virtual.

      Este problema se solucionó en NSX 6.2.0.

    • No se puede configurar el firewall de NSX con grupos de seguridad u otros objetos de agrupación definidos en el alcance global
      Los usuarios administradores definidos en el alcance de NSX Edge no pueden acceder a los objetos definidos en el alcance global. Por ejemplo, si el usuario abc se define en el alcance de Edge y el grupo de seguridad sg-1 se define en el alcance global, abc no puede utilizar sg-1 en la configuración de firewall en NSX Edge.

      Este problema se solucionó en NSX 6.2.0.

    • Movimiento demorado del mouse cuando se visualizan reglas de firewall
      En la sección Redes y seguridad de NSX (NSX Networking and Security) de vSphere Web Client, cuando se pasa el mouse sobre las filas en la pantalla Reglas de firewall (Firewall Rules) ocurre una demora de 3 segundos.

      Este problema se solucionó en NSX 6.2.0.

    • La interfaz de usuario muestra el mensaje Error de publicación de firewall (Firewall Publish Failed) a pesar de la correcta publicación
      Si se habilita Distributed Firewall en una subred de clústeres en el entorno y se actualiza un grupo de aplicaciones que se utiliza en una o más reglas de firewall activas, todas las acciones de publicación en la interfaz de usuario muestran un mensaje de error con los identificadores de los hosts que pertenecen a los clústeres que no tienen el firewall de NSX habilitado.
      A pesar de los mensajes de error, las reglas se publican y aplican correctamente en los hosts que tienen Distributed Firewall habilitado.

      Este problema se solucionó en NSX 6.2.0.

    • La eliminación de reglas de seguridad por medio de REST muestra un error
      Si se utiliza una llamada API REST para eliminar las reglas de seguridad creadas por Service Composer, el conjunto de reglas correspondientes no se elimina en realidad de la memoria caché del perfil del servicio, lo que provoca el error ObjectNotFoundException.

      Este problema se solucionó en NSX 6.2.0.

    • Las reglas de firewall no reflejan la máquina virtual agregada recientemente
      Cuando se agregaron máquinas virtuales nuevas al conmutador lógico, las reglas de firewall no se actualizaron correctamente para incluir las máquinas virtuales agregadas recientemente. Si se realiza un cambio en el firewall y se publican los cambios, los objetos nuevos se agregan a la directiva.

      Este problema se solucionó en NSX 6.2.0.

    • No se pueden seleccionar objetos de Active Directory cuando se configuran grupos de seguridad
      En NSX 6.1.x, los objetos de dominio de AD/LDAP demoraron mucho en regresar a la pantalla de selección Objeto de grupo de seguridad (Security Group Object).

      Este problema se solucionó en NSX 6.2.0.

    • No se puede agregar la regla de firewall con origen/destino como varias direcciones IP separadas por coma

      Este problema se solucionó en NSX 6.2.0.

    • No se puede mover la sección de Distributed Firewall (DFW) de NSX a la parte superior de la lista
      Cuando se utiliza Service Composer para crear una directiva de grupo de seguridad, la sección creada en la tabla de DFW no se puede agregar a la parte superior de la lista. No hay manera de mover la sección DFW hacia arriba o abajo.

      Este problema se solucionó en NSX 6.2.0.

    • La directiva de seguridad configurada como un rango de puertos hace que el firewall pierda sincronización
      La configuración de directivas de seguridad como un rango de puertos (por ejemplo, "5900-5964") hace que el firewall pierda la sincronización y muestre el error NumberFormatException.

      Este problema se solucionó en NSX 6.2.0.

    Problemas de servicios de supervisión resueltos

    • El comando #show interface no muestra la velocidad o el ancho de banda de la interfaz de vNic_0
      Después de ejecutar el comando "#show interface", se muestra una velocidad de dúplex completo de 0M/s, pero no se muestran la velocidad o el ancho de banda de la interfaz de NSX Edge vNic_0.

      Este problema se solucionó en NSX 6.2.0.

    • Cuando está habilitada la configuración IPFIX para Distributed Firewall, es posible que se quiten los puertos de firewall en la interfaz de administración de ESXi de NetFlow para vDS o SNMP
      Cuando un puerto y una IP del recopilador se definen para IPFIX, el firewall de la interfaz de administración de ESXi se abre en dirección de salida para los puertos recopiladores UDP especificados. Es posible que esta operación quite la configuración del conjunto de reglas dinámico del firewall de interfaz de administración de ESXi para los servicios siguientes si anteriormente estaban configurados en el host ESXi:

      • Configuración del puerto recopilador NetFlow en vDS

      • Configuración del puerto de destino SNMP


      Este problema se solucionó en NSX 6.2.0.

    • No se pueden procesar los eventos Denied/Block mediante el protocolo IPFIX
      Por lo general, el proceso de usuario vsfwd se ocupa de la recopilación de flujos, incluidos los desechados/denegados, y los procesa para IPFIX. Esto sucede cuando el recopilador IPFIX no puede ver los eventos Denied/Block porque la cola de descarte de paquetes de vSIP es demasiado limitada o está rodeada de eventos de flujo inactivos. En esta versión, se implementa la capacidad para enviar eventos Denied/Block con el protocolo IPFIX.

      Este problema se solucionó en NSX 6.2.0.

    Problemas de interoperabilidad de soluciones resueltos

    • No se puede configurar la red organizativa
      Cuando se intenta configurar una red para toda la organización, vCloud Director muestra un mensaje de error.

      Este problema se solucionó en NSX 6.2.0.

    • No se pueden iniciar varias máquinas virtuales con la configuración de VIO
      Los usuarios que utilizaban VMware Integrated OpenStack no podían iniciar una gran cantidad de máquinas virtuales o publicar grandes cantidades de reglas de firewall en un período breve. Esto generaba el mensaje Error publishing ip for vnic en el registro.

      Este problema se solucionó en NSX 6.2.0.

    Historial de revisión del documento

    20 de agosto de 2015: Primera edición de NSX 6.2.0.
    4 de septiembre de 2015: Segunda edición de NSX 6.2.0. Se quitó la advertencia de actualización innecesaria.
    22 de noviembre de 2015: Tercera edición de NSX 6.2.0. Se trasladó el problema de la opción "Bloquearía" (would-block) (1328589) de la lista de problemas solucionados a la lista de problemas conocidos. Este problema se sigue considerando como conocido hasta que se proporcione una solución en vSphere. En NSX 6.1.5 y 6.2.0, NSX añade mitigaciones para el problema.