VMware NSX Container Plugin 3.1.1   |   4 de febrero de 2021   |   Compilación 17559186 Compruebe regularmente las adiciones y actualizaciones a este documento.

Contenido de las notas de la versión

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

• Novedades
• Requisitos de compatibilidad
• Problemas resueltos
• Problemas conocidos

Novedades

NSX Container Plugin (NCP) 3.1.1 tiene la siguiente función nueva:

• Simplificación de la implementación y administración de NCP para clústeres de Kubernetes a través Operator
• Establecer la condición NetworkUnavaialble del nodo cuando nsx-node-agent no está disponible en el nodo (a través de Operator)
• Habilitar el registro para reglas SNAT
• Particionamiento del enrutador para OCP4
• Multidifusión a nivel 1 para un clúster de Kubernetes
• Habilitar el registro de acceso en el servidor virtual de entrada
• Habilitar multiplexación de TCP en el equilibrador de carga
• Acceso a pods a través de hostPort

Aviso de obsolescencia

La anotación "ncp/whitelist-source-range" quedará obsoleta en NCP 3.3. A partir de NCP 3.1.1, se usará la anotación "ncp/allowed-source-range" en su lugar.

Requisitos de compatibilidad

Producto	Versión
Mosaico de NCP/NSX-T para Tanzu Application Service (PCF)	3.1.1
NSX-T	3.0.2, 3.1.0, 3.1.1
vSphere	6.7, 7.0
Kubernetes	1.18 (P1), 1.19, 1.20
OpenShift 3	3.11 Nota: OpenShift 3.x quedará obsoleto en próximas versiones.
OpenShift 4	RHCOS 4.5, 4.6
Sistema operativo de máquina virtual de host de Kubernetes	Ubuntu 18.04, Ubuntu 20.04 CentOS 7.8, CentOS 7.9, CentOS 8.2 RHEL 7.8, RHEL 7.9, RHEL 8.3 (Nota: RHEL dejará de admitir Vanilla Kubernetes en próximas versiones.) Consulte las notas a continuación.
Sistema operativo de máquina virtual de host de OpenShift	RHEL 7.7, RHEL 7.8 (Nota: RHEL dejará de admitir Vanilla Kubernetes en próximas versiones.)
Tanzu Application Service (Pivotal Cloud Foundry)	Ops Manager 2.7 + PAS 2.7 (LTS) Ops Manager 2.9 + PAS 2.9 Ops Manager 2.10 + PAS 2.10
Tanzu Kubernetes Grid Integrated (TKGI)	1.10

Notas:

La instalación del módulo nsx-ovs kernel en CentOS/RHEL requiere una versión de kernel específica. Las versiones compatibles del kernel RHEL son 1127, 1160 y 193, independientemente de la versión de RHEL. Tenga en cuenta que la versión predeterminada del kernel es 1127 para RHEL 7.8, 1160 para RHEL 7.9 y 193 para RHEL 8.2. Si está utilizando una versión de kernel diferente, puede omitir la instalación del módulo de kernel nsx-ovs configurando "use_nsx_ovs_kernel_modnel" como "False" en la sección "nsx_node_agent" del mapa de configuración de nsx-node-agent.

Para ejecutar el módulo de kernel nsx-ovs en RHEL 8.2 (versión de kernel 193), debe deshabilitar la opción "Arranque seguro UEFI" de "Opciones de arranque" en los ajustes de la máquina virtual en vCenter Server.

Versiones desde las que se puede actualizar a esta versión:

• NCP 3.1 y todas las versiones NCP 3.0.x

 

Problemas resueltos

• Problema 2671647: Los flujos de OVS se pierden al reiniciar el trabajo de monit para los daemons de OVS ovsdb-server y ovs-vswitchd

  Los flujos de OVS creados por nsx-node-agent se pierden si se reinicia el trabajo monit para los daemons openvswitch con el comando "monit restart <nombre-proceso>"

  Solución alternativa: Reinicie nsx-node-agent una vez que los daemons de openvswitch vuelvan al estado "En ejecución" mediante el comando "monit restart nsx-node-agent"

• Problema 2674503: nsx-ncp-bootstrap no admite la instalación de módulos kernel de NSX OVS en CentOS 7.8, 8.1, 8.2 o RHEL 7.8, 8.1, 8.2

  El contenedor nsx-ncp-bootstrap no admite la instalación de módulos de kernel de OVS de NSX en CentOS 7.8, 8.1, 8.2 o RHEL 7.8, 8.1, 8.2.

  Solución alternativa: Establezca use_nsx_ovs_kernel_modnel en False en ConfigMap del agente de nodo de NSX y utilice el módulo de kernel OVS ascendente de Linux.

Problemas conocidos

• Problema 2131494: La entrada de Kubernetes de NGINX sigue funcionando después de cambiar la clase de entrada de NGINX a NSX

  Cuando se crea una entrada de Kubernetes de NGINX, NGINX crea reglas de reenvío de tráfico. Si cambia la clase de entrada a cualquier otro valor, NGINX no elimina las reglas y las sigue aplicando, incluso si elimina la entrada de Kubernetes después de cambiar la clase. Esta es una limitación de NGINX.

  Solución alternativa: Para eliminar las reglas creadas por NGINX, elimine la entrada de Kubernetes cuando el valor de clase sea NGINX. A continuación, vuelva a crear la entrada de Kubernetes.

• Para un servicio de Kubernetes de tipo ClusterIP, no se admite la afinidad de sesión basada en IP de cliente

  NCP no es compatible con la afinidad de sesión basada en IP de cliente para un servicio de Kubernetes de tipo ClusterIP.

  Solución alternativa: Ninguno

• Para un servicio de Kubernetes de tipo ClusterIP, no se admite la marca de modo horquilla

  NCP no es compatible con la marca de modo horquilla para un servicio de Kubernetes de tipo ClusterIP.

  Solución alternativa: Ninguno

• Problema 2192489: Después de deshabilitar 'BOSH DNS server’ en la configuración de director de PAS, el servidor DNS de Bosh (169.254.0.2) sigue apareciendo en el archivo resolve.conf del contenedor

  En un entorno de PAS que ejecute PAS 2.2, después de deshabilitar 'BOSH DNS server’ en la configuración de director de PAS, el servidor DNS de Bosh (169.254.0.2) sigue apareciendo en el archivo resolve.conf del contenedor. Esto provoca que un comando de ping con un nombre de dominio completo tome mucho tiempo. Este problema no existe con PAS 2.1.

  Solución alternativa: Ninguna. Este es un problema de PAS.

• Problema 2224218: Después de eliminar un servicio o una aplicación, son necesarios dos minutos para volver a liberar la IP de SNAT al grupo de direcciones IP

  Si elimina un servicio o una aplicación, y vuelve a crearlos en menos de dos minutos, obtendrán una nueva IP de SNAT del grupo de direcciones IP.

  Solución alternativa: Tras eliminar un servicio o una aplicación, espere dos minutos antes de volver a crearlos si desea volver a utilizar la misma dirección IP.

• Problema 2404302: Si hay varios perfiles de aplicaciones del equilibrador de carga para el mismo tipo de recurso (por ejemplo, HTTP) en NSX-T, NCP elegirá cualquiera de ellos para conectarse a los servidores virtuales.

  Si hay varios perfiles de aplicaciones del equilibrador de carga de HTTP en NSX-T, NCP elegirá uno de ellos con la configuración de x_forwarded_for adecuada para asociarlo al servidor virtual HTTP y HTTPS. Si hay varios perfiles de aplicaciones de FastTCP y UDP en NSX-T, NCP elegirá cualquiera de ellos para conectarse a los servidores virtuales TCP y UDP, respectivamente. Es posible que los perfiles de aplicaciones del equilibrador de carga hayan sido creados por diferentes aplicaciones con diferentes configuraciones. Si NCP elige asociar uno de estos perfiles de aplicaciones del equilibrador de carga a los servidores virtuales creados por NCP, podría romper el flujo de trabajo de otras aplicaciones.

  Solución alternativa: Ninguno

• Problema 2397621: Error de instalación de OpenShift 3

  La instalación de OpenShift 3 espera que el estado de un nodo esté listo y esto es posible después de la instalación del complemento CNI. En esta versión, no hay ningún archivo del complemento CNI independiente, lo que provoca un error en la instalación de OpenShift.

  Solución alternativa: Cree el directorio /etc/cni/net.d en cada nodo antes de iniciar la instalación.

• Problema 2413383: Se produce un error al actualizar OpenShift 3 porque no todos los nodos están listos

  De forma predeterminada, el pod de arranque de NCP no está programado en el nodo principal. Como resultado, el estado del nodo principal siempre está en estado No listo.

  Solución alternativa: Asigne el nodo principal con la función "compute" para permitir que los DaemonSets nsx-ncp-bootstrap y nsx-node-agent creen pods. El estado del nodo cambiará a "Listo" una vez que nsx-ncp-bootstrap instale NSX-CNI.

• Problema 2451442: después de reiniciar NCP varias veces y de volver a crear un espacio de nombres, es posible que NCP no pueda asignar direcciones IP a los pods.

  Si elimina y vuelve a crear repetidamente el mismo espacio de nombres al reiniciar NCP, puede que NCP no pueda asignar direcciones IP a los pod en ese espacio de nombres.

  Solución alternativa: elimine todos los recursos de NSX obsoletos (enrutadores lógicos, conmutadores lógicos y puertos lógicos) asociados al espacio de nombres y vuelva a crearlos.

• Problema 2460219: el redireccionamiento de HTTP no funciona si no hay un grupo de servidores predeterminado.

  Si el servidor virtual HTTP no se enlaza con un grupo de servidores, se producen errores en el redireccionamiento de HTTP. Este problema ya existe en NSX-T 2.5.0 y versiones anteriores.

  Solución alternativa: cree un grupo de servidores predeterminado o actualice a NSX-T 2.5.1.

• Problema 2518111: NCP no pueden eliminar recursos de NSX-T que se actualizaron desde NSX-T

  NCP crea recursos de NSX-T en función de las configuraciones que especifique. Si realiza actualizaciones a esos recursos de NSX-T a través de NSX Manager o de la API de NSX-T, es posible que NCP no pueda eliminar esos recursos y volver a crearlos cuando sea necesario.

  Solución alternativa: No actualice los recursos de NSX-T creados por NCP a través de NSX Manager o de la API de NSX-T.

• Problema 2524778: NSX Manager muestra NCP como inactivo o en mal estado después de que se elimine el nodo principal de NCP

  Después de eliminar un nodo principal de NCP (por ejemplo, después de que se realice correctamente el cambio a un nodo de copia de seguridad, el estado de NCP sigue apareciendo como inactivo cuando debería aparecer como activo).

  Solución alternativa: Utilice la API de Manager DELETE /api/v1/systemhealth/container-cluster/<id-clúster>/ncp/status para borrar el estado obsoleto de forma manual.

• Problema 2517201: No se puede crear un pod en un host ESXi

  Después de eliminar un host ESXi de un clúster de vSphere y volver a agregarlo al clúster, se produce un error al crear un pod en el host.

  Solución alternativa: Reinicie NCP.

• Problema 2416376: NCP no puede procesar un ASG (grupo de seguridad de aplicaciones) de PAS vinculado a más de 128 espacios

  Debido a un límite en el firewall distribuido de NSX-T, NCP no puede procesar un ASG de PAS vinculado a más de 128 espacios.

  Solución alternativa: Cree varios ASG y vincule cada uno de ellos a un máximo de 128 espacios.

• Problema 2534726: Si se produce un error al actualizar a NCP 3.0.1 a través del mosaico NSX-T, el uso de la línea de comandos BOSH para rehacer la actualización provocará problemas de rendimiento

  Cuando se actualiza a NCP 3.0.1 a través del mosaico NSX-T en OpsMgr, el proceso de actualización marcará los perfiles de conmutación de HA en NSX Manager utilizados por NCP como inactivos. Los perfiles de conmutación se eliminarán cuando se reinicie NCP. Si se produce un error en la actualización y se utiliza un comando de BOSH, como “bosh deploy -d <id-implementación> -n <implementación>.yml” para rehacer la actualización, no se eliminarán los perfiles de conmutación de HA. NCP seguirá ejecutándose, pero el rendimiento se degradará.

  Solución alternativa: Actualice siempre NCP a través de OpsMgr y no de la línea de comandos de BOSH.

• Problema 2537221: Después de actualizar NSX-T a la versión 3.0, el estado de redes de los objetos relacionados con contenedores en la interfaz de usuario de NSX Manager se muestra como Desconocido

  En la interfaz de usuario de NSX Manager, la pestaña Inventario > Contenedores muestra los objetos relacionados con el contenedor y su estado. En un entorno de PKS, después de actualizar NSX-T a la versión 3.0, el estado de redes de los objetos relacionados con el contenedor se muestra como Desconocido. El problema se debe a que PKS no detecta el cambio de versión de NSX-T. Este problema no se produce si NCP se está ejecutando como pod y el sondeo de ejecución está activo.

  Solución alternativa: Después de la actualización de NSX-T, reinicie las instancias de NCP gradualmente (no más de 10 al mismo tiempo) para no sobrecargar NSX Manager.

• Problema 2550474: En un entorno de OpenShift, el cambio de una ruta HTTPS a HTTP puede hacer que la ruta HTTP no funcione según lo esperado

  Si se edita una ruta HTTPS y se eliminan los datos relacionados con TLS para convertirla en una ruta HTTP, es posible que la ruta HTTP no funcione según lo esperado.

  Solución alternativa: Elimine la ruta HTTPS y cree una nueva ruta HTTP.

• Problema 2552573: En un entorno de OpenShift 4.3, se puede producir un error en la instalación del clúster si DHCP está configurado con la interfaz de usuario de Directiva

  En un entorno de OpenShift 4.3, la instalación del clúster requiere que haya un servidor DHCP disponible para proporcionar información de DNS y direcciones IP. Si utiliza el servidor DHCP configurado en NSX-T mediante la interfaz de usuario de Directiva, es posible que se produzca un error en la instalación del clúster.

  Solución alternativa: Configure un servidor DHCP mediante la interfaz de usuario de Manager, elimine el clúster que no pudo instalar y vuelva a crear el clúster.

• Problema 2552564: En un entorno de OpenShift 4.3, el reenviador de DNS podría dejar de funcionar si se encuentra una dirección superpuesta

  En un entorno de OpenShift 4.3, la instalación del clúster requiere que se configure un servidor DNS. Si utiliza NSX-T para configurar un reenviador de DNS y existe una superposición de direcciones IP con el servicio DNS, el reenviador de DNS dejará de funcionar y se producirá un error al instalar el clúster.

  Solución alternativa: Configure un servicio DNS externo, elimine el clúster que no pudo instalar y vuelva a crear el clúster.

• Problema 2483242: El tráfico IPv6 de los contenedores está bloqueado por NSX-T SpoofGuard

  La dirección local de vínculo IPv6 no se encuentra en la lista blanca automática con SpoofGuard habilitado.

  Solución alternativa: Deshabilite SpoofGuard estableciendo nsx_v3.enable_spoofguard = False en la configuración de NCP.

• Problema 2552609: datos de X-Forwarded-For (XFF) y X-Forwarded-Port incorrectos

  Si configura XFF con INSERT o REPLACE para las reglas de entrada de HTTPS (Kubernetes) o las rutas HTTPS (OpenShift), es posible que aparezcan valores de X-Forwarded-For y X-Forwarded-Port incorrectos en encabezados XFF.

  Solución alternativa: Ninguna.

• Problema 2555336: El tráfico del pod no funciona porque hay puertos lógicos duplicados creados en modo Manager

  Es más probable que este problema se produzca cuando hay muchos pods en varios clústeres. Cuando se crea un Pod, no funciona el tráfico al pod. NSX-T muestra varios puertos lógicos creados para el mismo contenedor. En el registro de NCP, solo se puede encontrar el identificador de uno de los puertos lógicos. 

  Solución alternativa: Elimine el pod y vuelva a crearlo. Los puertos obsoletos de NSX-T se eliminarán cuando se reinicie NCP.

• Problema 2554357: El ajuste de escala automático del equilibrador de carga no funciona para IPv6

  En un entorno IPv6, un servicio de Kubernetes de tipo equilibrador de carga no estará activo cuando se alcance la escala del equilibrador de carga existente.

  Solución alternativa: Establezca nsx_v3.lb_segment_subnet = FE80::/10 en /var/vcap/jobs/ncp/config/ncp.ini para implementaciones de PKS y en nsx-ncp-configmap para otros. A continuación, reinicie NCP.

• Problema 2597423: Al importar objetos de Manager a Directiva, una reversión hará que se pierdan las etiquetas de algunos recursos

  Al importar objetos de Manager a Directiva, si es necesaria una reversión, no se restaurarán las etiquetas de los siguientes objetos:

  • Perfiles de Spoofguard (parte de los recursos compartidos y de clúster)
  • BgpneighbourConfig (parte de los recursos compartidos)
  • BgpRoutingConfig (parte de los recursos compartidos)
  • StaticRoute BfdPeer (parte de los recursos compartidos)

  Solución alternativa: Para los recursos que forman parte de los recursos compartidos, restaure manualmente las etiquetas. Utilice la función de copia de seguridad y restauración para restaurar recursos que formen parte de los recursos del clúster.

• Problema 2579968: Cuando se realizan cambios en los servicios de Kubernetes de tipo LoadBalancer con una frecuencia alta, algunos servidores virtuales y grupos de servidores no se eliminan según lo esperado

  Cuando se realizan cambios en los servicios de Kubernetes de tipo LoadBalancer con una frecuencia alta, es posible que algunos servidores virtuales y los grupos de servidores permanezcan en el entorno de NSX-T cuando deberían eliminarse.

  Solución alternativa: Reinicie NCP. De forma alternativa, elimine manualmente los servidores virtuales obsoletos y sus recursos asociados. Un servidor virtual está obsoleto si ningún servicio de Kubernetes de tipo equilibrador de carga tiene el identificador del servidor virtual en la etiqueta external_id.

• Problema 2536383: Después de actualizar NSX-T a la versión 3.0 o una posterior, la interfaz de usuario de NSX-T no muestra correctamente la información relacionada con NCP

  Después de actualizar NSX-T a la versión 3.0 o una posterior, la pestaña Inventario > Contenedores de la interfaz de usuario de NSX-T muestra el estado de red de los objetos relacionados con el contenedor como Desconocido. Además, los clústeres de NCP no aparecen en la pestaña Sistema > Tejido > Nodos > Clústeres de NCP. Por lo general, este problema se ve en un entorno de PKS.

  Solución alternativa: Después de la actualización de NSX-T, reinicie las instancias de NCP gradualmente (no más de 10 al mismo tiempo).

• Problema 2622099: Se produce un error al inicializar el servicio de Kubernetes de tipo LoadBalancer con el código de error NCP00113 y el mensaje de error "Otro usuario ha modificado el objeto. Vuelva a intentarlo."

  En una implementación de un solo nivel con API de directiva, si utiliza una puerta de enlace de nivel 1 existente como la puerta de enlace de nivel superior y el tamaño de asignación de grupo de la puerta de enlace es ROUTING, es posible que un servicio de Kubernetes de tipo LoadBalancer no pueda inicializarse mostrando el código de error NCP00113 y el mensaje "Otro usuario ha modificado el objeto. Vuelva a intentarlo."

  Solución alternativa: Si aparece este problema, espere 5 minutos. A continuación, reinicie NCP. El problema se resolverá.

• Problema 2633679: NCP Operator no es compatible con los nodos de OpenShift asociados a un segmento de nivel 1 creado con la API /policy/api/v1/infra/tier-1s/<id-nivel1>/segments/<id-segmento>

  NCP Operator no es compatible con los nodos de OpenShift asociados a un segmento de nivel 1 creado con la API /policy/api/v1/infra/tier-1s/<id-nivel1>/segments/<id-segmento>.

  Solución alternativa: Use la API /policy/api/v1/infra/segments/<id-segmento> para crear el segmento.

• NCP no puede iniciarse si la opción de "registro en archivo" está habilitada durante la instalación de Kubernetes

  Este problema se produce cuando uid:gid=1000:1000 en el host de contenedor no tiene permiso para la carpeta de registros.

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

  • Cambie el modo de la carpeta de registros a 777 en los hosts de contenedor.
  • Conceda el permiso "rwx" de la carpeta de registros a uid:gid=1000:1000 en los hosts del contenedor.
  • Deshabilite la función de "registro en archivo".
• Problema 2653214: Se produjo un error al buscar el puerto de segmento de un nodo después de cambiar la dirección IP del nodo

  Después de cambiar la dirección IP del nodo, si actualiza NCP o si se reinicia el pod de NCP Operator, al comprobar el estado de NCP Operator con el comando "oc describe co nsx-ncp", se mostrará el mensaje de error "Se produjo un error al buscar el puerto del segmento para el nodo..."

  Solución alternativa: Ninguna. No se puede agregar una dirección IP estática en una interfaz de nodo que también tenga configuración de DHCP.

• Problema 2664457: Al utilizar DHCP en OpenShift, es posible que se pierda temporalmente la conectividad cuando nsx-node-agent se inicia o se reinicia

  nsx-ovs crea y activa cinco perfiles de conexión temporales para configurar ovs_bridge, pero su activación puede seguir fallando temporalmente en NetworkManager. Como resultado, no hay ninguna IP (conectividad) presente en la máquina virtual en ovs_uplink_port ni o en ovs_bridge.

  Solución alternativa: Reinicie la máquina virtual o espere a que NetworkManager pueda activar correctamente todos los perfiles.

• Problema 2672677: En un entorno de OpenShift 4 muy estresado, un nodo puede dejar de responder

  En un entorno de OpenShift 4 con un alto nivel de densidad de pods por nodo y una alta frecuencia de eliminación y creación de pods, un nodo de RHCOS puede pasar al estado "No está listo". Los pods que se ejecutan en el nodo afectado, a excepción de los miembros de daemonset, se expulsarán y se volverán a crear en otros nodos del entorno.

  Solución alternativa: Reinicie el nodo afectado.

• Problema 2706551: Se produce un error en la instalación automatizada de pila completa de OpenShift (conocida como IPI) porque los nodos no están listos durante la instalación

  El pod cuya conexión se ha mantenido agrega el VIP de Kubernetes al ovs_bridge en los nodos maestros antes de que el servidor de la API de Kubernetes empiece a ejecutarse en ellos. Como resultado, fallan todas las solicitudes enviadas al servidor de la API de Kubernetes y no se puede completar la instalación.

  Solución alternativa: Ninguno

• Problema 2707883: nsx-ncp-operator no crea un recurso de Kubernetes relacionado con NCP si el recurso se eliminó cuando nsx-ncp-operator no se estaba ejecutando

  Por ejemplo, si se elimina DaemonSet de nsx-node-agent o nsx-ncp-bootstrap cuando nsx-ncp-operator no se está ejecutando, no se volverá a crear cuando nsx-ncp-operator se esté ejecutando de nuevo.

  Solución alternativa: Actualice cualquier campo en ConfigMap de nsx-ncp-operator; por ejemplo, log_level en la sección [Default] cuando nsx-ncp-operator se está ejecutando de nuevo.

• Problema 2697547: No se admite HostPort en los nodos de RHEL/CentOS/RHCOS

  Puede especificar hostPorts en Kubernetes nativo y PKS en nodos de Ubuntu configurando 'enable_hostport_snat' como True en ConfigMap de nsx-node-agent. Sin embargo, en los nodos de RHEL/CentOS/RHCOS no se admite hostPort y se omite el parámetro 'enable_hostport_snat'.

  Solución alternativa: Ninguno

• Problema 2707174: Un pod que se elimina y se vuelve a crear con el mismo nombre y nombre de espacio no tiene conectividad de red

  Si se elimina un pod y se vuelve a crear con el mismo nombre y espacio de nombre cuando NCP no se está ejecutando y se está ejecutando nsx-ncp-agents, es posible que el pod obtenga configuraciones de red erróneas y no pueda acceder a la red.

  Solución alternativa: Elimine el pod y vuelva a crearlo cuando se esté ejecutando NCP.

• Problema 2713782: Las llamadas de NSX API fallan con el error "SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC"

  A veces, al iniciarse, es posible que NCP se reinicie o no inicialice los servicios del equilibrador de carga. Además, mientras NCP se está ejecutando, es posible que se notifique que un endpoint de NSX está fuera de servicio durante un breve período de tiempo (menos de 1 segundo). Si el equilibrador de carga no se inicializa, el registro de NCP mostrará el mensaje "No se pudieron inicializar los servicios de equilibrador de carga".

  Solución alternativa: Aumente el valor del parámetro nsx_v3.conn_idle_timeout. Tenga en cuenta que esto puede aumentar el tiempo de espera para que los endpoints se detecten como disponibles después de una desconexión temporal cuando se utiliza el equilibrio de carga del lado del cliente.

• Problema 3033821: Después de la migración de Manager a Directiva, las reglas de firewall distribuido no se aplican correctamente

  Después de una migración de Manager a Directiva, las reglas de firewall distribuido (DFW) relacionadas con directivas de red recién creadas tendrán mayor prioridad que las reglas de DFW migradas.

  Solución alternativa: Utilice la API de Directiva para cambiar la secuencia de reglas de DFW según sea necesario.