This site will be decommissioned on January 30th 2025. After that date content will be available at techdocs.broadcom.com.

 

Actualizado el 8 de junio de 2022

VMware SD-WAN™ Orchestrator versión R421-20211216-GA
VMware SD-WAN™ Gateway versión R421-20210407-GA
VMware SD-WAN™ Edge versión R421-20210624-GA-57011-60130

Compruebe periódicamente si existen adiciones y actualizaciones a estas notas de la versión.

Contenido de las notas de la versión

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

Uso recomendado

Esta versión se recomienda para todos los clientes que necesiten las funcionalidades que se ponen a su disposición en la versión 4.2.0, así como para los clientes afectados por los problemas que se indican a continuación y que se han resuelto desde la versión 4.2.0.

Compatibilidad

La versión 4.2.1 de las instancias de Orchestrator, Gateway y Hub Edge admite todas las versiones anteriores de VMware SD-WAN Edge posteriores o iguales a la versión 3.0.0. 
Nota: Esto significa que no se admiten las versiones anteriores a la versión 3.0.0.

Las siguientes combinaciones de interoperabilidad se probaron explícitamente:

Orchestrator

Gateway

Edge

Hub

Sucursal/Radio

4.2.0

4.2.0

4.2.0

4.2.1

4.2.0

4.2.0

4.2.1

4.2.1

4.2.1 

3.4.2

3.4.2

3.4.2

4.2.1 

4.2.1 

3.4.2

3.4.2

4.2.1 

4.2.1 

4.2.1 

3.4.2

4.2.1 

4.2.1 

3.4.2

4.2.1 

4.2.1 

4.2.1 

3.4.5

3.4.5

4.2.1 

4.2.1 

4.2.1

3.4.3, 3.4.4, 3.4.5

4.2.1 

4.2.1 

3.4.3, 3.4.4, 3.4.5

4.2.1

4.2.1 

3.3.2 P3 

3.3.2 P3

3.3.2 P3 

4.2.1 

4.2.1 

3.3.2 P3 

3.3.2 P3 

4.2.1 

4.2.1 

4.2.1 

3.3.2 P2, 3.3.2 P3

4.2.1 

4.2.1 

3.3.2 P2 

4.2.1 

4.2.1 

3.2.2 

3.2.2 

3.2.2 

4.2.1 

4.2.1 

3.2.2 

3.2.2 

4.2.1 

4.2.1 

4.2.1 

3.2.2 

4.2.1 

4.2.1 

3.2.2 

4.2.1 

4.2.1

4.0.0

4.0.0

4.0.0

4.2.1

4.0.0

4.0.1

4.2.1

4.2.1

4.2.1

4.0.0

4.0.1

Advertencia: las versiones 4.0.x y 4.2.x de VMware SD-WAN se aproximan a su fecha de fin de soporte técnico. 

  • La versión 4.0.x llegará a la fecha de fin de soporte técnico (EOGS) el 30 de septiembre de 2022 y a la fecha de fin de orientación técnica (EOTG) el 31 de diciembre de 2022. 
  • La versión 4.2.x para Orchestrator y Gateway llegarán a la fecha de fin de soporte técnico (EOGS) el 30 de diciembre de 2022 y a la fecha de fin de orientación técnica (EOTG) el 30 de marzo de 2023.   
  • La versión 4.2.x para Edge llegará a la fecha de fin de soporte técnico (EOGS) el 30 de junio de 2023 y a la fecha de fin de orientación técnica (EOTG) el 30 de septiembre de 2023.
  • Para obtener más información, consulte el artículo de la base de conocimientos: Anuncio: fin del plazo de compatibilidad de VMware SD-WAN versión 4.x (88319)

Nota: La versión 3.x no admitía correctamente AES-256-GCM, lo cual significaba que los clientes que usaban AES-256 siempre usaban sus instancias de Edge con GCM deshabilitado (AES-256-CBC). Si un cliente utiliza AES-256, debe deshabilitar de forma explícita GCM desde Orchestrator antes de actualizar las instancias de Edge a una versión 4.x. Una vez que todas las instancias de Edge ejecuten una versión 4.x, el cliente puede elegir entre AES-256-GCM y AES-256-CBC.

Notas importantes

Cambio del delimitador de configuración del filtro BGPv4 para anteponer AS-PATH

A través de la versión 3.x, la configuración del filtro BGPv4 de VMware SD-WAN para anteponer AS-PATH admite delimitadores basados en espacios y comas. Sin embargo, a partir de la versión 4.0.0 y versiones posteriores, VMware SD-WAN solo admitirá un delimitador basado en espacio en una configuración de anteposición de AS-PATH.
Los clientes que actualicen de 3.x a 4.x deben editar las configuraciones de anteposición de AS-PATH para "reemplazar comas por espacios" antes de la actualización para evitar una selección incorrecta de la mejor ruta de BGP.

Tiempo de actualización ampliado para los modelos Edge 3x00

Las actualizaciones a esta versión pueden tardar más de lo normal (3-5 minutos) en los modelos Edge 3x00 (es decir, 3400, 3800 y 3810). Esto se debe a una actualización de firmware que resuelve el problema 53676. Si una instancia de Edge 3400 o 3800 había actualizado previamente su firmware cuando estaba en la versión 3.4.5 o 4.0.2, la instancia de Edge se actualizaba según lo previsto. Para obtener más información, consulte el problema resuelto 53676.

Limitación al deshabilitar la autonegociación en los modelos de VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 y 3810

Cuando un usuario deshabilita la autonegociación para velocidad de codificación rígida y dúplex en los puertos GE1-GE4 en un modelo de VMware SD-WAN Edge 620, 640 o 680; en los puertos GE3 o GE4 en un modelo de Edge 3400, 3800 o 3810; o en un modelo de Edge 520/540 cuando se utiliza SFP con una interfaz de cobre en los puertos SFP1 o SFP2, el usuario puede percibir que, incluso después de reiniciar, el vínculo no aparece.

Esto se debe a cada uno de los modelos de Edge enumerados utiliza Intel Ethernet Controller i350, que tiene una limitación que le impide, cuando no se utiliza la autonegociación en ambos lados del vínculo, detectar dinámicamente los cables adecuados para transmitir y recibir (MDIX automático). Si ambos lados de la conexión transmiten y reciben a través de los mismos cables, no se detectará el vínculo. Si el lado del mismo nivel tampoco admite MDIX automático sin autonegociación y el vínculo no viene con un cable lineal, se necesitará un cable Ethernet cruzado para activar el vínculo.

Para obtener más información, consulte el artículo de la base de conocimientos Limitación al deshabilitar la autonegociación en los modelos de VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 y 3810 (87208).

Historial de revisiones del documento

9 de abril de 2021. Primera edición.

13 de abril de 2021. Segunda edición.

  • Se agregó el problema resuelto 53676 a la sección Problemas resueltos de Edge/Gateway.  Este problema se omitió por error de las Notas de la versión originales.
  • Se agregó una sección de Notas importantes que recoge el problema del tiempo de actualización ampliado que experimentará un dispositivo 3x00 si su firmware debe actualizarse como parte de la corrección para el problema 53676.

21 de abril de 2021. Tercera edición.

  • Se agregó una nueva compilación de Orchestrator: R421-20210415-GA como la compilación más actual.  Se agregó una nueva sección para R421-20210415-GA a la sección Problemas resueltos de Orchestrator.
  • Se agregó el ticket #61312 a la sección Problemas resueltos de Orchestrator para la compilación R421-20210415-GA.

7 de mayo de 2021. Cuarta edición.

  • Se ha revisado la tabla de Compatibilidad para incluir dos nuevas combinaciones probadas:
    • Orchestrator y Gateway en la versión 4.2.0 se ha probado como compatible con una instancia de Edge de hub con 4.2.0 y una instancia de Edge de radios con 4.2.1.
    • Orchestrator y Gateway en la versión 4.2.0 se ha probado como compatible con una instancia de Edge de hub con 4.2.1 y una instancia de Edge de radios con 4.2.1.
  • Se agregaron los problemas solucionados 55949 y 56149 a la sección correspondiente de Edge/Gateway. Estos tickets deben estar incluidos en las Notas de la versión de GA originales.

15 de junio de 2021. Quinta edición.

  • Se modificó el problema solucionado de Edge/Gateway 56876 para dar cuenta de un segundo escenario que resuelve la solución para este problema, que también tiene en cuenta la administración de memoria que conlleva una detención de kernel de Edge y un reinicio.
  • Se agregó el problema resuelto 54001 de Edge/Gateway, que se omitió erróneamente en las ediciones anteriores.

5 de agosto de 2021. Sexta edición.

  • Se agregaron seis problemas conocidos a la sección de Problemas abiertos de Edge/Gateway: #60006, #60225, #61361, #62552, #63359 y #67790.

11 de agosto de 2021. Séptima edición.

  • Se agregó una nueva versión de Edge R421-20210624-GA-57011-60130 y se desplazaron los tickets existentes 57011 y 60130 a la nueva sección creada para la compilación de Edge.

16 de septiembre de 2021. Octava edición. 

  • Se agregó a las Notas importantes la nota siguiente: Cambio del delimitador de configuración del filtro BGPv4 para anteponer AS-PATH.

21 de diciembre de 2021. Novena edición.

  • Se agregó una nueva compilación de Orchestrator, R421-20211216-GA, a los Problemas resueltos de Orchestrator. Esta compilación de Orchestrator corrige la vulnerabilidad CVE-2021-44228, relacionada con Apache Log4j, mediante la actualización a Log4j versión 2.16.0. Para obtener más información sobre la vulnerabilidad de Apache Log4j, consulte el aviso de seguridad de VMware VMSA-2021-0028.5.
  • Se agregó a las Notas importantes la nota siguiente: Limitación al deshabilitar la autonegociación en los modelos de VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 y 3810. Esta nota abarca un problema que puede surgir al configurar una velocidad forzada en algunos puertos Ethernet de los modelos de Edge enumerados.

24 de marzo de 2022, décima edición

  • Se agregó el problema resuelto #84825 a la sección Problemas conocidos de Edge/Gateway.

7 de junio de 2022. Duodécima edición

  • Se agregó el problema resuelto #54493 a la sección Problemas resueltos de Edge/Gateway. Este problema se omitió por error en la edición original de las Notas de la versión 4.2.1.

Problemas resueltos

Los problemas resueltos se agrupan de la siguiente manera.

Problemas resueltos de Edge

Resuelto en la versión R421-20210624-GA-57011-60130

Los siguientes problemas se han resuelto desde Edge versión R421-20210407-GA.

  • Problema 57011 resuelto: Para un sitio configurado con una topología de alta disponibilidad (HA), cada vez que se agregan segmentos y, a continuación, se eliminan en ese sitio, una de las instancias de Edge de HA puede experimentar un error en el servicio de plano de datos y, si el error de servicio se encuentra en la instancia de Edge activa, el sitio también experimentará una conmutación por error de HA.

    Cuando se agregan segmentos y, a continuación, se eliminan de un sitio de HA, existe la posibilidad de que haya segmentos obsoletos (es decir, es posible que los segmentos eliminados aún se muestren en una de las instancias de Edge del par de HA). Debido a esta falta de coincidencia en la información de segmentos entre las instancias de Edge de HA, cualquier evento destinado al segmento obsoleto puede enviarse a la otra instancia de Edge, lo cual da como resultado un error en el servicio de plano de datos, una conmutación por error de HA si el error del servicio se encuentra en la instancia de Edge activa y la generación de un volcado de núcleo que se detectará en un paquete de diagnóstico adoptado después de la conmutación por error. No hay ninguna solución alternativa para este problema.

  • Problema 60130 resuelto: Un sitio puede experimentar períodos intermitentes de alto volumen de pérdida de paquetes y problemas de conectividad.

    La causa de esto es que la API comprueba la resolución de ARP para avisar a Edge de que la resolución de ARP de un dispositivo se ha realizado correctamente al proporcionar una dirección MAC 00:00:00:00.  Esta dirección se mantiene en la caché de ARP y se descartan todos los paquetes destinados al dispositivo donde la dirección MAC aparece como cero. En este problema, se entregan muchas de estas instancias de ARP correctas con cero direcciones MAC y se origina un alto volumen de pérdida de paquetes y problemas de conectividad.

    Esta solución corrige los problemas con el valor en caché de las direcciones MAC en un flujo (la causa más común del problema). Sin embargo, esta solución no soluciona un escenario más inusual en el que ARP se almacena en caché y, a continuación, devuelve una dirección MAC cero. Esto se abordará en 62552. Además de disponer de una imagen de Edge con la corrección, no hay ninguna solución alternativa para este problema.

Problemas resueltos de Edge/Puerta de enlace

Resuelto en la versión R421-20210407-GA

Los siguientes problemas se han resuelto desde la versión de Edge R420-20201218-GA y la versión de Puerta de enlace R420-20210208-GA-53243-54800.

  • Problema 51025 solucionado: Cuando un vínculo WAN oscila (alterna rápidamente entre un estado activo e inactivo) en una instancia de VMware SD-WAN Edge, es posible que la entrada de la tabla de rutas de la puerta de enlace predeterminada de la interfaz enrutada se elimine y no se vuelva a aplicar.

    Cuando una instancia de Edge detecta este problema, existe una oscilación de vínculo y se elimina la entrada de ruta de puerta de enlace predeterminada para la interfaz que utiliza ese vínculo, lo cual da como resultado una tabla de rutas vacía para la interfaz. Sin embargo, si se queda con una tabla de rutas vacía, el seguimiento de conexiones de Linux (conntrack) se enruta a la siguiente tabla de forma predeterminada y provoca que todos los paquetes salgan a través de la interfaz enrutada incorrecta.

  • Problema 52102 solucionado: Para una empresa que utiliza una topología de hub o radios, los flujos existentes se descartan en una instancia de VMware SD-WAN Edge de radios al recuperarse de una conmutación por error de Edge de hub para una tupla determinada.

    La secuencia de eventos genera este problema cuando una instancia de Edge de hub principal se recupera de la conmutación por error:
    1. Cuando la instancia de Edge de hub principal deja de funcionar, la ruta se elimina de la FIB de la instancia de Edge de hub principal mientras se conservan las rutas en la RIB.
    2. Los flujos existentes ahora cambiarán a la instancia de Edge de hub secundaria.
    3. Cuando se realiza una copia de seguridad de la instancia de hub principal, se establece inmediatamente un túnel entre la instancia de hub principal desde la instancia de Edge de radios.
    4. Las rutas de la RIB aprendidas anteriormente desde la instancia de hub principal a través de la instancia de Puerta de enlace se examinan y las rutas se instalan en la FIB que apunta a esta instancia de hub principal.
    5. El tráfico volverá a la instancia de hub principal, mientras que la instancia de hub principal no habrá aprendido las rutas de su vecino BGP.
    6. Esto hace que la búsqueda de rutas coincida en la ruta predeterminada y que el tráfico de retorno esté indicado con una marca de una red de retorno.
    7. La instancia de Edge de radios no espera que se devuelva el tráfico con una marca de red de retorno establecida y esto provoca que se descarte el tráfico. 

    Sin esta corrección, la solución alternativa es desplazarse hasta la instancia de Edge de hub y ejecutar el diagnóstico remoto "Vaciar flujos" (Flush Flows) para la tupla determinada; así se restaurará el tráfico.

  • Problema 53415 solucionado: En una empresa de cliente con Edge Network Intelligence (ENI) habilitado, si la instancia de VMware SD-WAN Edge de la empresa tiene una conexión Wi-Fi habilitada, la página de ENI puede mostrar una dirección MAC incorrecta para el punto de acceso Wi-Fi y la IP del punto de acceso se mostrará como 160.254.3.1.

    El problema es el resultado de una configuración errónea de la dirección MAC del punto de acceso Wi-Fi, que se establece en un valor llamado "selfMacAddress" y la dirección IP del punto de acceso siempre se configura como 160.254.3.1 en la página de ENI. La solución derivará la dirección MAC de la interfaz de Wi-Fi wlan0 y la dirección IP de la interfaz de análisis.

  • Problema 53477 solucionado: Cuando las instancias de Edge de VMware SD-WAN configuradas en una topología de alta disponibilidad se mueven a un perfil de configuración diferente, las instancia de Edge experimentan reinicios repetidos del servicio de Edge.   

    Para este problema, una de las instancias de Edge de alta disponibilidad (HA) está configurada para tener más interfaces de LAN o WAN que la otra instancia de Edge de HA (por ejemplo, un puerto de WAN está deshabilitado en una de las instancias de Edge) y, si estas instancias de Edge se mueven a un perfil diferente, experimentarán reinicios continuos del servicio de Edge.

  • Problema 53651 solucionado: En un sitio de cliente que utiliza una topología de alta disponibilidad mejorada, al realizar un cambio de configuración en un ajuste del dispositivo VMware SD-WAN Edge que requiere el reinicio del servicio de Edge, pueden producirse dos conmutaciones por error de alta disponibilidad (HA) de forma sucesiva.

    Para un cambio de configuración de dispositivo que requiere el reinicio del servicio de Edge, el módulo de HA actualiza incorrectamente el recuento de LAN/WAN a VMware SD-WAN Gateway antes de que el servicio de Edge se reinicie durante el procesamiento de la configuración. Como resultado, cuando se produce la conmutación por error inicial de HA y el servicio de Edge en modo Activo actual se reinicia como parte de la degradación a En espera, Gateway interpreta erróneamente que la nueva instancia de Edge En espera tiene un mejor recuento de LAN/WAN y envía un comando de conmutación por error a la instancia de Edge en modo Activo recientemente promocionada, provocando la segunda conmutación por error.

    Nota: una lista de cambios en la configuración de Edge que pueden activar un reinicio del servicio. Consulte el artículo de la base de conocimientos, Cambios de configuración de VMware SD-WAN Edge que pueden activar un reinicio del servicio (60247)

  • Problema 53676 solucionado: En la plataforma Edge 3x00 de VMware SD-WAN, unos períodos muy breves de inestabilidad de voltaje de entrada, tan solo de 4 milisegundos., pueden provocar el reinicio de Edge.

    Por lo general, este problema se observa cuando se utiliza una fuente de alimentación ininterrumpida (UPS) que experimenta una leve inestabilidad de voltaje de salida al cambiar de estar conectada a la corriente a utilizar la batería. La solución para este problema actualiza el firmware de Edge para tolerar entre 20 y 30 ms de inestabilidad de voltaje antes de reiniciar Edge.

    Nota: La actualización del firmware de 3x00 ampliará el tiempo de actualización de la instancia de Edge a 3-5 minutos si la instancia de Edge no actualizó previamente su firmware cuando se utilizaban las versiones 3.4.5 o 4.0.2.

    Para un modelo de Edge 3x00 sin esta solución, la única opción del cliente es utilizar una UPS más sofisticada que pueda cambiar su entrada sin inestabilidad de voltaje de salida. 

  • Problema 53789 solucionado: En instancias de VMware SD-WAN Virtual Edge que se ejecutan en ESXi, /var/log/messages se rellena con un mensaje de error falso cada 30 segundos.

    El mensaje de error falso se mostrará como GuestInfoGetDiskDevice: Missing disk device name; VMDK mapping unavailable for "/", fsName: "/dev/root" y siempre inicia sesión en /var/log/messages, rellenando /var/log/messages y su correspondiente guardado /velocloud/log/messages*, lo cual provoca que los mensajes más importantes vayan rotando y se pierdan al consultar los registros de la instancia de Edge afectada.

  • Problema 53929 solucionado: En un sitio de cliente que utiliza una topología de alta disponibilidad mejorada, después de una conmutación por error de HA, los flujos de "Nube a través de puerta de enlace" (Cloud via Gateway) cambian a una ruta de tipo "Directo a la nube" (Direct to Cloud).

    Después de la conmutación por error de HA, si la ruta a VMware SD-WAN Gateway no está activa cuando el tráfico llega a la instancia de VMware SD-WAN Edge, el tráfico pasa "Directo a la nube" (Direct to Cloud), en lugar de pasar por la "Nube a través de puerta de enlace" (Cloud Via Gateway). Esto puede tener un impacto considerable para los flujos que dependen de optimizaciones de múltiples rutas dinámicas, como el tráfico en tiempo real (por ejemplo, voz y vídeo), ya que el tráfico directo no utiliza estas optimizaciones.

  • Problema 54001 solucionado: Una instancia de Edge de VMware no puede enviar tráfico después de que una cola de transmisión se cuelgue en las interfaces de SFP.

    En muy contadas ocasiones, cuando la instancia de Edge envía un paquete de tamaño no válido (menos de 17 bytes o más de 1.526 bytes) a DPDK, la cola de transmisión se detiene y hace que la instancia de Edge no reenvíe más tráfico. El reinicio de Edge corrige temporalmente el problema, pero puede producirse de nuevo cuando se envía un paquete de tamaño no válido desde el servicio de Edge a DPDK. Solo la actualización a un nivel con la solución evita este problema.

  • Problema 54493 solucionado: Un operador o un administrador de socios pueden observar un aumento de la cantidad de descartes de cola de entrega en el tráfico de Edge en una instancia de VMware SD-WAN Gateway. 

    Con este problema, Gateway no tendría problemas de uso de CPU o descartes de DPDK. El problema se activa como consecuencia de un evento del plano de control (por ejemplo, un recálculo de las rutas) y Gateway comienza a descartar paquetes de Edge durante la entrega a diferentes subprocesos en la canalización de Gateway. La causa del problema es que el tamaño de cola no es lo suficientemente grande como para almacenar paquetes en búfer.

  • Problema 54694 solucionado: Cuando un cliente utiliza un sondeo de SNMP, la supervisión de SNMP genera mediciones imprecisas para el tráfico saliente

    La llamada SNMP para IF-MIB::ifHCOutOctets envía paquetes de transmisión en lugar de bytes de transmisión, lo cual da lugar a recuentos de octetos salientes imprecisos que afectan a la capacidad del cliente para supervisar su empresa. Este problema es el resultado de la supervisión por parte del proceso snmpagent de paquetes de transmisión en comparación con los bytes de transmisión.

  • Problema 55949 solucionado: En algunos casos, un túnel de destino que no es de SD-WAN (NSD) a través de Puerta de enlace se desactiva y no se recupera durante un período de tiempo.

    En una situación en la que VMware SD-WAN Gateway activa una regeneración de clave de IKE con cualquier otro destino NSD y la regeneración de claves no se realiza correctamente debido a un problema de red en medio de la negociación, la regeneración de claves IKE sigue intentando ejecutarse. Cuando se vuelve a establecer un vínculo, es posible que el evento Dead Peer Detection (DPD) elimine una asociación de seguridad (SA) de fase 1 recién creada. Esto hace que la SA de IPsec se elimine también con algunos elementos del mismo nivel, sobre todo con Zscaler. Cuando un elemento del mismo nivel elimina una SA de IPsec, Gateway no puede detectarla y un túnel se desactivará hasta la próxima vez que se regeneren claves.  Sin la solución, la única forma de forzar esta regeneración de claves es recuperar el túnel deshabilitando y volviendo a habilitar el NSD afectado a través de VMware SD-WAN Orchestrator.

  • Problema 56149 solucionado: Después de habilitar el cálculo de costes dinámicos (DCC) en una empresa cliente que utiliza BGP, VMware SD-WAN Edge puede mostrar un valor de preferencia de ruta incorrecto para las rutas corregidas automáticamente si la ruta BGP de la ruta subyacente oscila.

    El impacto para el cliente es un enrutamiento asimétrico debido a que la preferencia de ruta remota no es correcta, lo cual se traduce en una latencia más alta y un bajo rendimiento en todas las aplicaciones del cliente. Después de habilitar DCC, el nuevo valor de preferencia de base de información de enrutamiento (RIB) debe actualizarse en la ruta, y la ruta debe volverse a anunciar a VMware SD-WAN Gateway con el nuevo valor de preferencia de RIB, que posteriormente se comunica a todas las instancias de Edge. La causa del problema es que, cuando la ruta se corrige automáticamente, esta preferencia de RIB no se actualiza en la tabla FIB de la instancia de Edge del mismo nivel, que conserva el valor anterior a DCC. 

  • Problema 56346 solucionado: Un cliente puede percibir la colocación de colas de entrega al observar la página Supervisar (Monitor) > Sistema (System) de VMware SD-WAN Edge.

    Una actualización de eventos de ruta de VCRP (VeloCloud Route Protocol) provoca la caída de las colas de entrega en el subproceso de datos de VCMP (VeloCloud Management Plane).  Esto se debe a que, cuando se recibe una actualización de ruta, se invalidan todas las rutas del segmento respectivo. Esto da lugar a nuevas búsquedas de rutas en la ruta de datos. Una función específica llamada como parte de la búsqueda de rutas realiza una costosa operación de enumeración hash, lo cual provoca un aumento del 40 % en el uso de subprocesos de datos de VCMP.  Cuando se detectó este problema en un entorno real, la cantidad de colocaciones de colas de entrega no era suficiente para afectar al rendimiento de la red.

  • Problema 56483 resuelto: Los valores de pérdida de paquetes, vibración y latencia no se muestra en la supervisión en directo del vínculo WAN en VMware SD-WAN Orchestrator, en la pantalla Supervisar (Monitor) > Transporte (Transport).

    Un usuario no puede obtener datos en tiempo real sobre pérdida de paquetes, vibración o latencia para un vínculo WAN concreto en Supervisar (Monitor) > Transporte (Transport) y el gráfico se muestra como una línea plana. Además, al observar la pantalla Supervisar (Monitor) > Edge > Información general (Overview), todos los valores de pérdida, vibración y latencia se expresan como "0". Las estadísticas históricas se mostrarán correctamente en Supervisar (Monitor) > Transporte (Transport), este problema solo afecta a las estadísticas del "Modo en directo" (Live Mode). 

  • Problema 58535 solucionado: Cuando un cliente ha configurado un firewall con estado y bajo la protección de red y contra inundación también ha configurado una lista de no permitidos, la lista de no permitidos se establece automáticamente en los ajustes más agresivos para las nuevas conexiones y el firewall con estado bloquea cualquier conexión nueva.

    El problema tiene un impacto crítico para los clientes que utilizan un firewall con estado, ya que hace que la función de lista de no permitidos no se pueda utilizar. Una vez habilitada la función de lista de no permitidos, los eventos de firewall se rellenan con los registros: "FLOOD_ATTACK_DETECTED" y "Blacklisting source: xxx.xxx.x.x exceeded CPS limit : 0 per source".  Donde la dirección IP es la dirección IP de administración de Edge y CPS son las conexiones por segundo. El límite de Nuevo umbral de conexión (New Connection Threshold) se establece en 0 %, lo cual significa de forma efectiva que cualquier intento de conexión activará la lista de no permitidos para bloquear todas las conexiones.  El valor predeterminado de Nuevo umbral de conexión (New Connection Threshold) es un 25 %.

  • Problema 56876 resuelto: VMware SD-WAN Edge puede encontrar un problema relacionado con la administración de memoria y activar una detención de kernel, que provocará un reinicio de Edge.

    Este problema resuelto incluye correcciones para dos escenarios diferentes que implican la administración de memoria en una instancia Edge, que activa una detención de kernel:

    1. En el primer escenario, donde una instancia de Edge utiliza una conexión de sucursal a sucursal dinámica, se crean los túneles dinámicos y se reserva una pequeña cantidad de memoria para almacenar contadores entre pares. Cuando el túnel dinámico pasa a estar inactivo, esta memoria no se limpia, por lo que para optimizar el tiempo de activación, la próxima vez se conecta el mismo par. En una instancia de Edge pequeña (por ejemplo, Edge 500, 510, 520, 610) que se conecta a un gran número de destinos diferentes a lo largo del tiempo, esta acción puede agotar la memoria disponible y activar una detención de kernel y un reinicio de Edge.  Sin esta solución, un usuario debe reiniciar de forma proactiva el servicio de Edge si el uso de memoria es superior al 90 % de las estadísticas de estado al mirar la pantalla Supervisar (Monitor) > Sistema (System) de Edge en VMware SD-WAN Orchestrator.
    2. En el proceso de corrección de la fuga de memoria provocada por la conexión de sucursal a sucursal dinámica, se observó que malloc_trim (un proceso que borra la memoria fragmentada) no se invocaba correctamente y este proceso también se modificó para esta corrección. Si no se invoca correctamente malloc_trim, puede generarse un problema diferente que puede afectar a cualquier instancia de Edge (no solo a las de menor tamaño) donde no se requiera que Edge utilice una conexión de sucursal a sucursal dinámica ni que Supervisar (Monitor) > Sistema (System) muestre un uso de memoria superior al 90 %. Este escenario es mucho más probable si la instancia de Edge tiene un número elevado de flujos.
  • Problema 56931 solucionado: Un sitio del cliente que ha configurado un destino que no es de SD-WAN (NSD) a través de Edge puede mostrar estadísticas de estado de Edge incorrectas en la interfaz de usuario de VMware SD-WAN Orchestrator.

    Cuando se configura un NSD desde Edge, el servicio de SD-WAN envía estadísticas de estado de Edge a Orchestrator con una hora de inicio de 0 la primera vez después del reinicio. Como resultado, Orchestrator muestra los datos incorrectos después de reiniciar Edge.

  • Problema 57063 solucionado: Si la hora de inicio y finalización de una llamada de API se superpone exactamente con la hora en la que una instancia de Edge de VMware SD-WAN exporta datos a VMware SD-WAN Orchestrator, se observarán dos comportamientos: a) Las llamadas de API de métricas de vínculo emitidas desde la interfaz de usuario de Orchestrator o los clientes de SDK observarán un valor superior al normal devuelto en la respuesta. b) Las llamadas API de la serie de vínculos emitidas desde la interfaz de la usuario de Orchestrator o los clientes de SDK observarán que el valor de la serie de última hora será superior a lo habitual.

    Un usuario puede observar esta discrepancia al consultar la pestaña Supervisar (Monitor) > Transporte (Transport) en la interfaz de usuario de Orchestrator o cuando un cliente de SDK invoca las llamadas de API getEdgeLinkMetrics, getEdgeLinkSeries o getAggregateLinkMetrics.  En cualquier caso, las horas reales que se observarán son extrañas si se tienen en cuenta los requisitos indicados en la descripción de Síntoma.

Problemas resueltos de Orchestrator

Orchestrator versión R421-20211216-GA

Orchestrator versión R421-20211216-GA se publicó el 20/12/2021. Esta compilación de Orchestrator corrige la vulnerabilidad CVE-2021-44228, relacionada con Apache Log4j, mediante la actualización a Log4j versión 2.16.0. Para obtener más información sobre la vulnerabilidad de Apache Log4j, consulte el aviso de seguridad de VMware VMSA-2021-0028.5.

    ___________________________________________________________________

    Resuelto en la versión R421-20210415-GA

    Los siguientes problemas se han resuelto desde Orchestrator versión R421-20210326-GA.

    • Problema 61312 solucionado: Una instancia de VMware SD-WAN Orchestrator puede encontrarse con un problema en el que las rutas ya no se actualizan y el uso de CPU del Orchestrator queda cerca del 100 %, especialmente después de actualizar Orchestrator.

      Este problema se manifiesta cuando una instancia de Edge envía ~2K+ actualizaciones de ruta a la API de enrutamiento de Orchestrator. En aquellos escenarios en los que Orchestrator no puede procesar el conjunto completo de rutas enviadas en una llamada de API determinada en un plazo de 60 segundos, se agota el tiempo de espera de esa llamada, lo cual a su vez provoca que la llamada de API se rechace por completo. Edge recibe este rechazo e intenta volver a enviar las mismas 2K+ rutas a Orchestrator, provocando el mismo escenario anterior, en el que se crea un bucle que sobrecarga los recursos de vCPU del Orchestrator. Cuando se produce este problema, puede evitar que se procese la actualización de la ruta. 

      Para solucionarlo, se agregaron dos propiedades del sistema:

      edge.learnedRoute.maxRoutePerCall Esta propiedad garantiza que solo se procese una cantidad limitada de rutas desde un Edge. Si el valor de la propiedad es "200", se procesarán 200 rutas por solicitud de Edge, lo cual garantiza que se envíe una confirmación a Edge a tiempo.

      vco.learnedRoute.simultaneous.maxQueue Esta propiedad garantiza que solo el número configurado de instancias de Edge pueda tener solicitudes de ruta en cola de forma simultánea. Si el valor de la propiedad es "8", solo se permitirá que 8 instancias de Edge envíen solicitudes de ruta de forma simultánea y las que superen el valor configurado se rechazarán inmediatamente antes de que se procesen las rutas.

    ______________________________________

    Resuelto en la versión R421-20210326-GA

    Los siguientes problemas se han resuelto desde Orchestrator versión R420-20210306-GA.

    • Problema 20900: Si el servicio de geolocalización MaxMind está habilitado y no puede acceder al servidor de MaxMind, no funcionarán las nuevas activaciones de Edge de VMware SD-WAN.

      Edge crea una conexión HTTPS con VMware SD-WAN Orchestrator para activarse. El tiempo de espera predeterminado de la solicitud es de 120 segundos, y para la conexión con proxy, de 60 segundos. Mientras Orchestrator intenta geolocalizar la instancia de Edge (dirección remota IPv4), las cargas esperan la respuesta del servicio de Maxmind a fin de continuar con la activación. Por lo tanto, después de 60 segundos, NGINX detiene la respuesta del servicio de carga y cierra la conexión. Por lo tanto, se produce un error en la activación debido a un tiempo de espera 504 de NGINX. 

      Con la nueva propiedad del sistema service.maxmind.timeout.seconds, la llamada a la API de Maxmind se realiza con un tiempo de espera personalizado. Si se agota el tiempo de espera, la llamada continúa con el flujo de trabajo de activación y, por lo tanto, la instancia de Edge se activa correctamente.

    • Problema 49997 solucionado: Si el modo de análisis (Analytics Mode) de VMware Edge Network Intelligence está habilitado en VMware SD-WAN Orchestrator, cuando se crea un nuevo usuario operador, ese operador no puede conectarse con las secciones de análisis de la interfaz de usuario de Orchestrator.

      Los usuarios de operador creados después de activar el modo de análisis deben poder acceder a la interfaz de usuario de VMware Edge Network Intelligence de todos los clientes empresariales que tengan habilitado el acceso de soporte, y esto no es así.

    • Problema 52379 solucionado: VMware SD-WAN Orchestrator envía un correo electrónico de alerta de tipo "Edge inactivo" (Edge Down) si VMware SD-WAN Edge se recupera dentro del intervalo de retraso configurado.

      Es posible los administradores reciban un mensaje falso sobre una instancia de Edge inactiva en su red aunque se haya configurado un retraso para permitir que una instancia de Edge esté inactiva durante un período de tiempo antes de desencadenar esa alerta.

    • Problema 53525 solucionado: Cuando se utiliza la nueva interfaz de usuario en VMware SD-WAN Orchestrator y se visualiza la página de descripción general de Edge, la columna Vínculos (Links) no muestra el estado del vínculo (por ejemplo, Copia de seguridad [Backup], En espera [Standby]).

      Esta información de estado del vínculo se muestra correctamente en la interfaz de usuario anterior y, con esta solución, se mostrará según lo previsto en la nueva interfaz de usuario.

    • Problema 53652 solucionado: Cuando una empresa de cliente que utiliza un mapa de aplicaciones personalizado se actualiza de 3.x a 4.x, el cliente puede observar nombres aleatorios para sus aplicaciones personalizadas creadas antes de la actualización.

      Si un mapa de aplicaciones personalizado está configurado con un identificador de aplicación (appId) que ya existe como parte del mapa de aplicaciones inicial predeterminado, VMware SD-WAN Orchestrator siempre visualiza el nombre para mostrar del mapa de aplicaciones inicial predeterminado y reemplaza el nombre definido por el cliente. Esto también sucede cuando Orchestrator se actualiza desde una versión anterior a una versión superior y el mapa de aplicaciones inicial predeterminado de una versión superior tiene un appId que entra en conflicto con un appId de las aplicaciones personalizadas creadas en una versión anterior.  Después de la actualización de Orchestrator, esas aplicaciones personalizadas mostrarán un nombre de visualización incorrecto, que es el nombre para mostrar del appId del mapa de aplicaciones inicial predeterminado de la versión superior.

    • Problema 53752 solucionado: Se produce un error en una migración empresarial de cliente cuando se intenta desde VMware SD-WAN Orchestrator con una versión 3.4.x a una instancia de Orchestrator con la versión 4.2.0.

      La herramienta de migración empresarial más reciente no era compatible con la versión 4.2.x, lo cual provocaba errores de migración.

    • Problema 53857 solucionado: Una implementación de VMware SD-WAN Orchestrator que utiliza una imagen de KVM basada en la versión 4.0.0 no se implementará.

      El motivo del error es que la imagen de KVM tiene un tamaño de disco virtual incorrecto y que los volúmenes no se expandirán al tamaño requerido.  En una implementación, los scripts de Orchestrator expanden automáticamente los volúmenes de Orchestrator para que adopten el 80 % del tamaño máximo de los discos subyacentes (volúmenes físicos).  En este caso, debido al tamaño virtual incorrecto, esa expansión no es adecuada para los requisitos de base de datos de Orchestrator y se produce un error en la implementación.  Es posible implementar Orchestrator con una compilación anterior sin esta solución, pero el tamaño de los volúmenes debe ajustarse manualmente.

    • Problema 53987 solucionado: En VMware SD-WAN Orchestrator, no se puede buscar el evento de Edge "MTU de vínculo detectada" (Link MTU Detected) en la interfaz de usuario de Orchestrator.

      Este problema se ha observado en instancias de Orchestrator que utilizan la versión 4.0.x y versiones posteriores.  Al realizar una búsqueda de eventos en la interfaz de usuario de Orchestrator en la página Eventos, "MTU de vínculo detectada" (Link MTU Detected) no está disponible en la lista de eventos para filtrar, lo cual dificulta aislar el evento como parte de una actividad de solución de problemas.

    • Problema 54035 solucionado: Si el modo de análisis de VMware Edge Network Intelligence está habilitado, los paquetes destinados a los daemons de syslog, aruba y snmptrap de VMware SD-WAN Edge se descartan y estos datos no se mostrarán en el visor de Edge Network Intelligence.

      Los paquetes destinados a los daemons de Edge Network Intelligence (syslogd, amond y snmptrapd) se descartan en el proceso de plano de datos de Edge debido a que faltan las reglas de iptable correspondientes. Como resultado, las estadísticas correspondientes no se reciben en el back-end de Edge Network Intelligence.

    • Problema 55259 solucionado: Cuando un administrador crea una nueva instancia de VMware SD-WAN Edge en la interfaz de usuario de VMware SD-WAN Orchestrator, falta el campo "Establecer ubicación" (Set Location).

      Con este problema, el administrador puede crear la instancia de Edge, pero sin información de ubicación, y Orchestrator no puede realizar la geolocalización automática para la instancia de Edge y asignar las instancias de Gateway correctas.  El administrador debe realizar un paso adicional después de que se cree la instancia de Edge para entrar y rellenar la información de ubicación de Edge en la página Configurar (Configure) > Edge > Información general de Edge (Edge Overview).

    • Problema 55871 solucionado: Algunas llamadas de API a REST APIv2 (/sdwan) HTTP hacen que el servidor genere errores de tipo HTTP 500.

      En algunos casos en los que los datos del cliente no cumplen exactamente el esquema que espera la API, la API genera un error HTTP 500 en lugar de devolver datos que no son coherentes con el esquema de API documentado. Este comportamiento estaba basado en una decisión de diseño modificada desde entonces. Sabemos que las llamadas a "GET /enterprises", "GET /enterprises/{enterpriseLogicalId}/edges" y "GET /enterprises/{enterpriseLogicalId}/clientDevices" se ven afectadas.

    • Problema 56763 solucionado: En una instancia de VMware SD-WAN Orchestrator que utilice la versión 4.x o posterior con informes habilitados, si un informe no se genera por cualquier motivo, los informes subsiguientes de todos los clientes que utilizan la instancia de Orchestrator tampoco se generarán hasta que se reinicie el servicio back-end de Orchestrator.

      Este problema tiene un impacto significativo en una instancia de Orchestrator afectada, ya que todos los clientes que utilicen Orchestrator no podrán obtener informes hasta que se reinicie el servicio back-end de Orchestrator. Este problema se debe al error de un solo informe que pone el servicio de informes en un estado anómalo del cual no se puede recuperar si no es reiniciando el servicio back-end en Orchestrator.  Esto se debe a que la generación de informes nuevos no se produce de forma independiente de la generación de informes anteriores.  La solución garantiza que el servicio de generación de informes siga generando nuevos informes independientemente de un error de generación de informes.

    • Problema 56824 solucionado: En una instancia de VMware SD-WAN Orchestrator que utiliza la versión 4.2.x, se produce un error en la entrega de alertas a destinatarios de webhook cuando la URL del destinatario incluye un número de puerto explícito.

      Los usuarios que configuraron previamente direcciones URL de destinatario de webhook que incluían números de puerto explícitos pueden percibir que la entrega de alertas falla de forma indefinida para dichos destinatarios. Sin la solución en esta compilación, un administrador deberá configurar un proxy inverso para pasar solicitudes junto con el destinatario original del webhook y actualizar la URL del destinatario del webhook para que apunte al proxy inverso.

    • Problema 56896 solucionado: El usuario podría experimentar errores de API y tiempos de espera de Gateway.

      Este problema es el resultado de que el almacenamiento en disco de VMware SD-WAN Orchestrator se llena debido a una acumulación de archivos. Esta acumulación se produce porque existe una manera de deshabilitar el procesamiento de estadísticas de flujo para una instancia de VMware SD-WAN Edge o una lista de instancias de Edge que se asemeja a una característica de lista de bloqueos/lista de no permitidos. Aunque se omite el procesamiento de flujos para estas instancias de Edge, el problema es que los archivos permanecen en el disco de Orchestrator sin ser eliminados. En una instancia de este problema detectada en un entorno real, había suficiente supervisión para detectar el problema y evitar cualquier problema de la experiencia del usuario, pero en una instancia de Orchestrator donde había menos supervisión, esto podía afectar al tráfico del cliente. Sin esta solución, un operador de Orchestrator deberá eliminar manualmente los archivos del almacenamiento en disco de Orchestrator con una marca de tiempo de más de 24 horas.

    • Problema 56909 solucionado: En una instancia de VMware SD-WAN Orchestrator que utiliza la versión 4.x, la generación de informes puede fallar cuando se incluye un vínculo de copia de seguridad.

      Si un vínculo no tiene registros de estadísticas de vínculo, se produce un error en la generación del informe.  Un vínculo configurado para realizar una copia de seguridad no generará estadísticas de vínculo si se mantiene estrictamente como copia de seguridad durante el período seleccionado para el informe. Sin esta solución, la única forma de generar un informe es anular la selección del vínculo de copia de seguridad al generar un informe para que el vínculo tenga algunos datos estadísticos para su registro.

    • Problema 57087 solucionado: Cuando el usuario intenta cambiar un perfil de VMware SD-WAN Edge desde la pantalla Configurar (Configure) > Edge, el usuario verá un error de validación que incluye un cuadro de notificación con un mensaje de error genérico en lugar del motivo real.

      El error genérico observado muestra el mensaje "Error al procesar el elemento. Inténtelo de nuevo" (Error processing item. Please try again). Para ver el motivo real del error de validación, el usuario tenía que comprobar la consola de depuración de un explorador web. Después de la corrección, se muestra el motivo o el error de validación correspondientes.

    • Problema 58627 solucionado: Los usuarios configurados para recibir alertas pueden recibir una alerta de vínculo activo cuando, en realidad, el vínculo permanece inactivo.

      En ocasiones, después de marcar un vínculo como "Inactivo" (Down), es posible que las estadísticas de ese vínculo que se generaron antes de que el vínculo quedara inactivo no se envíen a VMware SD-WAN Orchestrator hasta un minuto después del evento.  Una vez que Orchestrator recibe estas estadísticas de vínculo retrasadas, lo normal es que piense que se está haciendo una copia de seguridad del vínculo y, por lo tanto, desencadena una alerta de vínculo activo si la configuración de la alerta es agresiva (p. ej., 0 minuto de retraso).  La solución garantiza que Orchestrator no interpreta las estadísticas de vínculo demoradas como una indicación de que el vínculo está actualmente activo.

    • Problema 59094 solucionado: Cuando un operador intenta actualizar una instancia de VMware SD-WAN Orchestrator, el script de actualización no proporciona un mensaje de advertencia adecuado sobre los requisitos de actualización del esquema.

      Si un operador pierde el paso para aplicar cambios de esquema en tablas más grandes, es posible que se haya producido un error en los servicios de Orchestrator.  Además, no hay una manera fácil de averiguar qué cambios faltan. Esta corrección soluciona este problema cuando, después de reiniciar el servicio de back-end, vuelve a generar los cambios de esquema que faltan necesarios en una tabla grande.

    • Problema 59967 solucionado: Después de actualizar una instancia de VMware SD-WAN Orchestrator a una versión 4.2.x o posterior, cuando un usuario operador intenta acceder a las páginas Configurar (Configure) > Directiva empresarial (Business Policy) o Configurar (Configure) > Directiva de firewall (Firewall Policy), la página no se cargará y el usuario verá un error.

      El error es "Se ha producido un error desconocido" (An unexpected error has occurred). Esto afecta a los usuarios operadores, no a los administradores de socios o clientes. Las páginas no se cargan debido a que falta el privilegio READ: OBJECT_GROUP para operadores, es decir, Orchestrator no reconoce a un operador como poseedor de los privilegios necesarios para acceder a las páginas Directiva empresarial (Business Policy) y Firewall.

    Problemas conocidos

    Problemas abiertos en la versión 4.2.1

    Los problemas conocidos se agrupan de la siguiente manera.

    Problemas conocidos de Edge/Puerta de enlace
    • Problema 14655:

      Conectar o desconectar un adaptador SFP puede hacer que el dispositivo deje de responder en la instancia de Edge 540, Edge 840 y Edge 1000, y requiere un reinicio físico.

      Solución alternativa: La instancia de Edge debe reiniciarse físicamente.  Esto puede realizarse en Orchestrator mediante Acciones remotas (Remote Actions) > Reinicio de una instancia de Edge (Reboot Edge) o apagando y encendiendo la instancia de Edge.

    • Problema 25504:

      Los costes de rutas estáticas superiores a 255 pueden provocar un pedido de rutas impredecible.  

      Solución alternativa: Utilice un coste de ruta entre 0 y 255

    • Problema 25595:

      Es posible que se requiera reiniciar para que los cambios en el SLA estático en una superposición de WAN funcionen correctamente.  

      Solución alternativa: Reiniciar Edge después de agregar y eliminar el SLA estático de la superposición de WAN

    • Problema 25742:

      El tráfico contabilizado subyacente se limita a un máximo de la capacidad hacia la instancia de Puerta de enlace de VMware SD-WAN, incluso si es menor que la capacidad de un vínculo WAN privado que no está conectado a la instancia de Puerta de enlace.  

    • Problema 25758:

      Es posible que los vínculos WAN USB no se actualicen correctamente cuando cambie de un puerto USB a otro hasta que se reinicie la instancia de Edge de VMware SD-WAN.  

      Solución alternativa: Reinicie la instancia de Edge después de mover los vínculos WAN USB de un puerto a otro.

    • Problema 25855:

      Una actualización de la configuración grande en la puerta de enlace de socio (por ejemplo, 200 VRF con BGP habilitado) puede provocar que la latencia aumente durante unos 2-3 segundos para cierto tráfico a través de la instancia de Puerta de enlace de VMware SD-WAN.

      Solución alternativa: No hay ninguna solución alternativa disponible.

    • Problema 25921:

      La conmutación por error de alta disponibilidad del hub de VMware SD-WAN tarda más de lo esperado (hasta 15 segundos) cuando hay 3000 instancias sucursales de Edge conectadas al hub.  

    • Problema 25997:

      Es posible que Edge de VMware SD-WAN requiera un reinicio para que el tráfico pase correctamente en una interfaz con enrutamiento que se convirtió en un puerto conmutado.  

      Solución alternativa: Reinicie la instancia de Edge después de hacer el cambio de configuración.

    • Problema 26421:

      La puerta de enlace de socio principal de cualquier sitio de sucursal también debe estar asignada a un clúster de hubs de VMware SD-WAN para que los túneles se establezcan en el clúster.  

    • Problema 28175:

      Se produce un error en la NAT de la directiva empresarial cuando la IP de NAT se superpone con la IP de la interfaz de Puerta de enlace de VMware SD-WAN.  

    • Problema 31210:

      VRRP: ARP no se resuelve en el cliente LAN de la dirección IP virtual de VRRP cuando la instancia de Edge de VMware SD-WAN es principal con un segmento de CDE no global que se ejecuta en la interfaz de LAN. 

    • Problema 32731:

      Es posible que las rutas predeterminadas condicionales anunciadas a través de OSPF no se retiren correctamente cuando la ruta esté desactivada. Si se vuelve a habilitar o se deshabilita la ruta, se retraerá correctamente. 

    • Problema 32960:

      El estado de la interfaz "Autonegociación" (Autonegotiate) y "Velocidad" (Speed) puede mostrarse de forma incorrecta en la interfaz de usuario web local para los las instancias de Edge de VMware SD-WAN activadas.

    • Problema 32981:

      La velocidad y el dúplex de codificación rígida en un puerto habilitado para DPDK pueden requerir un reinicio de Edge de VMware SD-WAN para que las configuraciones surtan efecto, ya que es necesario deshabilitar DPDK.

    • Problema 34254:

      Cuando se crea un CSS de Zscaler y el segmento global tiene configurados los ajustes de FQDN/PSK, esta configuración se copia en segmentos no globales para formar túneles de IPsec en un CSS de Zscaler.

    • Problema 35778:

      Cuando hay varios vínculos WAN definidos por el usuario en una sola interfaz, solo uno de esos vínculos WAN puede tener un túnel de GRE a Zscaler. 

      Solución alternativa: Use una interfaz diferente para cada vínculo WAN que necesite para crear túneles de GRE a Zscaler.

    • Problema 35807:

      Una interfaz enrutada DPDK se deshabilitará por completo si la interfaz está deshabilitada y se vuelve a habilitar desde VMware SD-WAN Orchestrator. 

    • Problema 36923:

      Es posible que el nombre de clúster no se actualice correctamente en la descripción de la interfaz de NetFlow de una instancia de Edge de VMware SD-WAN que está conectada a ese clúster como hub.

    • Problema 38682:

      Es posible que una instancia de Edge de VMware SD-WAN que actúa como servidor DHCP en una interfaz habilitada para DPDK no genere correctamente eventos de tipo "Nuevo dispositivo cliente" (New Client Device) para todos los clientes conectados.

    • Problema 38767:

      Cuando una superposición de WAN que tiene túneles de GRE a Zscaler configurados se cambia de detección automática a definida por el usuario, los túneles obsoletos pueden permanecer hasta el próximo reinicio.

      Solución alternativa: Reinicie la instancia de Edge para borrar el túnel obsoleto.

    • Problema 39134:

      Es posible que no se notifique correctamente la estadística de mantenimiento del sistema "Porcentaje de CPU" (CPU Percentage) en Supervisar (Monitor) > Edge > Sistema (System) para la instancia de Edge de VMware SD-WAN y en Supervisar (Monitor) > Puertas de enlace (Gateways) para la puerta de enlace de SD-WAN VMware.

      Solución alternativa: Los usuarios deben utilizar descartes de cola de entrega para supervisar la capacidad de Edge, no el porcentaje de CPU.

    • Problema 39374:

      Si se cambia el orden de las puertas de enlace de socio de VMware SD-WAN asignadas a una instancia de Edge de SD-WAN VMware, es posible que la puerta de enlace 1 no se establezca correctamente como puerta de enlace local para las pruebas de ancho de banda.

    • Problema 39608:

      La salida del diagnóstico remoto "Prueba de ping" (Ping test) puede mostrar brevemente el contenido no válido antes de mostrar los resultados correctos.

    • Problema 39624:

      Es posible que se produzca un error al hacer ping a través de una subinterfaz cuando la interfaz principal está configurada con PPPoE.

    • Problema 39659:

      En un sitio configurado para una alta disponibilidad mejorada, con un vínculo WAN en cada instancia de Edge de VMware SD-WAN, cuando la instancia de Edge en espera tiene únicamente PPPoE con conexión y la instancia activa solo tiene únicamente no PPPoE con conexión, el estado de cerebro dividido (activo/activo) puede ser posible si se produce un error en el cable de alta disponibilidad.

    • Problema 39753:

      Al deshabilitar la VPN de sucursal a sucursal dinámica, se puede producir que los flujos existentes que se envían actualmente con la sucursal a sucursal dinámica se detengan.

    • Problema 40096:

      Si se reinicia una instancia de Edge de VMware SD-WAN 840, existe la posibilidad de que un módulo SFP conectado a Edge deje de pasar tráfico a pesar de que el vínculo se enciende, y VMware SD-WAN Orchestrator mostrará el puerto como "activo". 

      Solución alternativa: Desconecte el módulo SFP y, a continuación, vuelva a conectarlo al puerto.

    • Problema 40421:

      Traceroute no muestra la ruta de acceso cuando pasa a través de una instancia de Edge de VMware SD-WAN con una interfaz configurada como un puerto conmutado.

    • Problema 42278:

      Para un tipo específico de configuración errónea del mismo nivel, la instancia de Puerta de enlace de VMware SD-WAN puede enviar mensajes de inicialización de IKE de forma continua a un elemento del mismo nivel que no sea SD-WAN. Este problema no interrumpe el tráfico de los usuarios a la puerta de enlace; sin embargo, los registros de la puerta de enlace se rellenarán con errores de IKE, lo cual puede ocultar entradas de registro útiles.

    • Problema 42388:

      En una instancia de Edge de VMware SD-WAN 540, no se detecta un puerto SFP después de deshabilitar y volver a habilitar la interfaz desde VMware SD-WAN Orchestrator.

    • Problema 42488:

      En una instancia de VMware SD-WAN Edge donde VRRP está habilitado para un puerto conmutado o enrutado, si el cable se desconecta del puerto y se reinicia el servicio de Edge, se anuncian las rutas conectadas a la LAN.

      Solución alternativa: No hay ninguna solución alternativa para este problema.

    • Problema 42872:

      Habilitar el aislamiento de perfiles en un perfil de hub donde se asocia un clúster de hubs no revoca las rutas de hub de la base de información de enrutamiento (RIB).

    • Problema 43373:

      Cuando se extrae la misma ruta de BGP de varias instancias de Edge de VMware SD-WAN, si esta ruta se mueve de preferida a salida elegible en el Control de flujo superpuesto, la instancia de Edge no se elimina de la lista de anuncios y se mantiene anunciada.

      Solución alternativa: Habilite el cálculo de costes distribuidos en VMware SD-WAN Orchestrator.

    • Problema 44526: Para el caso una empresa en la que dos sitios diferentes implementan sus instancias de Edge de VMware SD-WAN como hubs mientras también utilizan una topología de alta disponibilidad, y cada sitio utiliza el otro sitio de hub como hub en su perfil,  si uno de los sitios de hub activa una conmutación por error de HA, es posible que las dos instancias de Edge de hub tarden hasta 30 minutos en restablecer los túneles entre sí. 

      En una conmutación por error de HA, ambas instancias de Edge de hub intentan iniciar un túnel entre sí al mismo tiempo, y ninguna responde al elemento del mismo nivel; el intercambio de paquetes entre ambos hubs se produce, pero IKE nunca se realiza correctamente. Esto da lugar a un interbloqueo que se observó que puede tardar hasta 30 minutos en resolverse por su cuenta. El problema es intermitente y no ocurre después de cada conmutación por error de HA. 

      Solución alternativa: Para evitar que se produzca este problema, el cliente debe configurar solo uno de los dos sitios de hub de HA para que use el otro sitio de hub como hub para sí mismo.  Por ejemplo, si hay dos sitios de hub de HA, Hub1 y Hub2, Hub1 podría tener a Hub2 como hub para sí mismo en su perfil, pero Hub2 no debe utilizar Hub1 como hub en su perfil.

    • Problema 44832:

      El tráfico de un destino que no es de SD-WAN a través de Edge a otros destinos que no son de SD-WAN a través de Edge, por ejemplo, "redirección al origen" (hairpinning) o "bucle invertido de NAT" (NAT loopback) se descarta en Edge de VMware SD-WAN.

    • Problema 44995:

      Las rutas de OSPF no se revocan de las instancias de VMware SD-WAN Gateway y las instancias de VMware SD-WAN Edge de radios cuando las rutas se retiran del clúster de hubs.

    • Problema 45189:

      Con NAT del lado de la LAN de origen configurado, el tráfico de una instancia de VMware SD-WAN Edge de radios a una instancia de Edge de hub se permite incluso sin la configuración de la ruta estática para la subred NAT.

    • Problema 45302:

      En un clúster de hubs de VMware SD-WAN, si un hub pierde conectividad durante más de 5 minutos con todas las instancias de Puerta de enlace de VMware SD-WAN comunes entre sí y sus instancias de Edge de radios asignadas, es posible que los radios no puedan retener las rutas del hub después de 5 minutos. El problema se resuelve cuando el hub vuelve a obtener contacto con las instancias de Puerta de enlace.

    • Problema 46053:

      La preferencia de BGP no se corrige automáticamente para las rutas superpuestas cuando se cambia su vecino a un vecino de enlace ascendente.

      Solución alternativa: Un reinicio del servicio de Edge solucionará este problema.

    • Problema 46137:

      Una instancia de Edge de VMware SD-WAN que ejecute el software 3.4.x no inicia un túnel con el cifrado AES-GCM aunque la instancia de Edge esté configurada para GCM.

    • Problema 46216:

      En un destino que no es SD-WAN a través de Puerta de enlace o Edge donde el elemento par es una instancia de AWS, cuando el elemento par inicia la regeneración de claves de fase 2, IKE de fase 1 también se elimina y fuerza una regeneración de claves.  Esto significa que el túnel se desconecta y se vuelve a generar, lo cual provoca la pérdida de paquetes durante la reconstrucción del túnel.

      Solución alternativa: Para evitar la destrucción del túnel, configure los destinos que no son de SD-WAN a través de la puerta de enlace/Edge o un temporizador de regeneración de claves de IPSec CSS a menos de 60 minutos.  Esto evita que AWS inicie la regeneración de claves.

    • Problema 46391:

      Para una instancia de Edge de VMware SD-WAN 3800, las interfaces SFP1 y SFP2 tienen problemas con SFP de varias velocidades (es decir, 1/10G) y no deben utilizarse en esos puertos.

      Solución alternativa: Use SFP de una sola velocidad, según el artículo de la base de conocimientos con la Lista de módulos SFP compatibles con VMware SD-WAN (79270).  Se pueden utilizar SFP de varias velocidades con SFP3 y SFP4.

    • Problema 46918:

      Una instancia de VMware SD-WAN Edge de radios con la versión 3.4.2 no actualiza correctamente el identificador de red privada de un nodo de clúster de hubs.

    • Problema 47084:

      Una instancia de Edge de hub de VMware SD-WAN no puede establecer más de 750 vecinos PIM (multidifusión independiente de protocolo) cuando tiene 4000 instancias de Edge de radios conectadas.

    • Problema 47244:

      En una instancia de Edge de VMware SD-WAN 6x0  activada con DPDK habilitado, algunos SFP de cobre, la instancia de Edge mostrará el vínculo como "activo" aunque no se haya insertado ningún cable en la interfaz de usuario de VMware SD-WAN Orchestrator.

      Solución alternativa: Al conectar y desconectar un cable, se elimina el estado falso.

    • Problema 47355:

      Cuando se conoce la misma ruta a través de BGP subyacente local, BGP de hub y/o configurado de forma estática en la puerta de enlace de socio, el orden de clasificación de las rutas es incorrecto con la preferencia de BGP de hub sobre la instancia de BGP subyacente.

    • Problema 47664:

      En una configuración de hub y radios donde está deshabilitada la VPN de sucursal a sucursal a través de hub, el intento de retornar un tráfico de sucursal a sucursal mediante una ruta de resumen en un conmutador o enrutador de capa 3 provocará bucles de enrutamiento.

      Solución alternativa: Configure la VPN de nube para habilitar la VPN de sucursal a sucursal y seleccione "Usar hubs para VPN" (Use Hubs for VPN).

    • Problema 47681:

      Cuando un host en el lado de la LAN de una instancia de Edge de VMware SD-WAN utiliza la misma IP que la interfaz de WAN de Edge, no funciona la conexión del host de LAN a WAN.

    • Problema 47787:

      Una instancia de VMware SD-WAN Edge de radios configurada con una directiva empresarial de red de retorno envía el tráfico de forma incorrecta a través de la ruta de VMware SD-WAN Gateway si ese flujo se inicia desde la instancia de Edge de hub hacia esa instancia de Edge de radios.

    • Problema 48166:

      No se admite una instancia de VMware SD-WAN Edge virtual en KVM cuando se utiliza un sistema operativo de virtualización Ciena y la instancia de Edge experimenta errores de servicio de plano de datos recurrentes.

    • Problema 48175:

      Una instancia de Edge de VMware SD-WAN que ejecuta la versión 3.4.2 formará una adyacencia de OSPF en un segmento no global si el segmento no global tiene una interfaz configurada en el mismo rango de IP que una interfaz configurada en el segmento global

    • Problema 48530:

      Los modelos de Edge de VMware SD-WAN 6x0 no realizan la negociación automática de los SFP de cobre de triple velocidad (10/100/1000 Mbps).

      Solución alternativa: El modelo Edge 520/540 admite un SFP de cobre de triple velocidad, pero este modelo se marcó para su retirada comercial el primer trimestre de 2021.

    • Problema 48597: La vecindad BGP de salto entre redes no permanece activa si una de las dos rutas al elemento del mismo nivel deja de funcionar

      Si existe una vecindad BGP de salto entre redes con un elemento del mismo nivel en el que hay varias rutas de acceso y una de ellas deja de funcionar, el usuario verá que la vecindad BGP deja de funcionar y no utiliza las otras rutas disponibles. Esto también incluye el caso de vecindad de bucle invertido de IP local.

      Solución alternativa: No hay ninguna solución alternativa para este problema.

    • Problema 48666:

      El cálculo de MTU de ruta de acceso de puerta de enlace de IPSec no tiene en cuenta la sobrecarga de IPSec de 61 bytes, lo cual da como resultado un anuncio de MTU mayor para el cliente LAN y la subsiguiente fragmentación de paquetes de IPSec.

      Solución alternativa: No hay ninguna solución alternativa para este problema.

    • Problema 49172:

      No funciona una regla de NAT basada en directivas configurada con la misma subred NAT para dos instancias diferentes de Edge de VMware SD-WAN.

    • Problema 49738:

      En algunos casos, cuando una instancia de VMware SD-WAN Edge de radios está configurada para usar varias instancias de Edge de hub, es posible que la instancia de Edge de radios no forme túneles en uno de los hubs configurados en la lista de hubs.

    • Problema 50518:

      En una instancia de Puerta de enlace de VMware SD-WAN donde PKI está habilitado, es posible que no aparezcan todos los túneles si >6000 túneles de PKI intentan conectarse a la instancia de Puerta de enlace, ya que no se eliminan las instancias de SA entrantes.

      Nota: Los túneles que usan la autenticación de clave compartida previamente (PSK) no tienen este problema.

    • Problema 51428: Es posible que se produzca una pérdida de tráfico de multidifusión en un sitio en el que la instancia de Edge de VMware SD-WAN tiene una subinterfaz configurada con PIM.

      Cuando una subinterfaz configurada con PIM se traslada de un segmento a otro sobre la marcha, pimd (el proceso que administra PIM) puede reiniciarse y el sitio experimentará una pérdida de tráfico de multidifusión intermitente.

      Solución alternativa: Deshabilite primero la subinterfaz y, a continuación, mueva la subinterfaz a otro segmento. Una vez trasladada, vuelva a habilitar la subinterfaz.

    • Problema 51436: Para un sitio que utiliza una topología de alta disponibilidad mejorada mientras se implementa una instancia de Edge de VMware SD-WAN con un módem LTE, si el sitio entra en un estado de "bicefalia" (split-brain), la conmutación por error de alta disponibilidad tarda ~5-6 minutos.

      Como parte de la recuperación desde un estado de bicefalia, los puertos de LAN se desactivan en la instancia de Edge activa y esto afecta al tráfico de LAN durante el tiempo que los puertos están inactivos y hasta que el sitio puede recuperarse.

      Solución alternativa: No hay ninguna solución alternativa para este problema.

    • Problema 52483: Si se han habilitado las cuentas subyacentes para una interfaz, Edge de VMware SD-WAN reenvía el tráfico de forma incorrecta a la misma interfaz, en lugar de reenviarlo a la superposición.

      Este comportamiento se debe a un problema con las cuentas subyacentes y una resolución de ruta recursiva.

      Solución alternativa: Deshabilite las cuentas subyacentes para la interfaz afectada.

    • Problema 53219: Después de volver a equilibrar un clúster de hub de SD-WAN VMware, es posible que algunas instancias de Edge de radios no tengan la interfaz de RPF o IIF configurados correctamente.

      En las instancias de Edge de radios afectadas, el tráfico de multidifusión se verá afectado. Lo que ocurre es que después de volver a equilibrar un clúster, algunas de las instancias de Edge de radios no pueden enviar una unión de PIM.

      Solución alternativa: Este problema persistirá hasta que la instancia de Edge de radios afectada corrijan el problema y se reinicie el servicio de Edge.

    • Problema 53337: Es posible que se observen descartes de paquetes con una instancia de AWS de Puerta de enlace de VMware SD-WAN cuando el rendimiento sea superior a 3200 Mbps.

      Cuando el tráfico presenta un rendimiento por encima de 3200 Mbps y un tamaño de paquete de 1300 bytes, se observan descartes de paquetes en RX y en la entrega de IPv4 BH.

      Solución alternativa: No hay ninguna solución alternativa para este problema.

    • Problema 53359: Es posible que se produzca un error en la sesión de BGP/BFD en algunos escenarios de ataque de tipo DDoS.

      Si el tráfico del cliente conectado a la interfaz enrutada al cliente de LAN se desborda, se puede producir un error en la sesión de BGP/BFD. Asimismo, cuando el tráfico de alta prioridad en tiempo real hacia el destino de superposición se desborda, se puede producir un error en la sesión de BGP/BFD.

      Solución alternativa: No hay ninguna solución alternativa para este problema.

    • Problema 53830: En una instancia de Edge de VMware SD-WAN, es posible que algunas de las rutas en la vista BGP no tengan los valores de preferencia y anuncio correctos cuando se habilita la marca de DCC, lo cual provocará un orden de clasificación incorrecto en la FIB de la instancia de Edge.

      Cuando el cálculo de costes distribuidos (DCC) está habilitado en un escenario escalado con un gran número de rutas en una instancia de Edge, cuando se observa un paquete de diagnóstico de Edge para el registro bgp_view es posible que algunas de las rutas no se actualicen correctamente con los valores de preferencia y anuncio.  Este problema, si se produce, se detectará en algunas instancias de Edge como parte de una empresa de gran tamaño (100 o más instancias de Edge de radios conectadas a instancias de Edge de hub o clústeres de hub).  

      Solución alternativa: Este problema se puede solucionar si vuelven a aprenderse las rutas de BGP subyacentes o se ejecuta una opción de "Actualización" (Refresh) en la página OFC de VMware SD-WAN Orchestrator para las rutas afectadas. Tenga en cuenta que al realizarse una "Actualización" (Refresh) de una ruta, volverán a aprenderse las rutas de todas las instancias de Edge de la empresa.

    • Problema 53934: En una empresa donde se configura un clúster de hub de VMware SD-WAN, si el hub principal tiene vecindades BGP de salto entre redes en el lado de la LAN, es posible que el cliente experimente caídas de tráfico en una instancia de Edge de radios cuando se produzca un error en el lado de la LAN o cuando se haya deshabilitado BGP en todos los segmentos.

      En un clúster de hub, el hub principal tiene una vecindad BGP de salto entre redes con un dispositivo del mismo nivel para aprender las rutas. Si la interfaz física en el hub por la que se establece la vecindad BGP se desactiva, las rutas de LAN de BGP pueden no pasar a ser cero a pesar de que la vista BGP esté vacía. Esto puede hacer que no se produzca el reequilibrio del clúster de hub. El problema también puede producirse cuando BGP está deshabilitado para todos los segmentos y cuando hay una o más vecindades BGP de salto entre redes.

      Solución alternativa: Reinicie la instancia de hub que tuvo un error en el lado de la LAN (o BGP deshabilitado).

    • Problema 56218: En el caso de un sitio de cliente implementado con una topología de alta disponibilidad (HA) o donde se acaba de habilitar HA, cuando las instancia de Edge se actualizan desde la versión 3.2.x a la 3.4.x, es posible que la instancia de Edge en modo En espera se desactive.

      Cuando HA está habilitado o las instancias de Edge de HA se actualizan desde la versión 3.2.2 a la 3.4.x después de configurar un ajuste de WAN mediante la interfaz de usuario local, la interfaz de HA (p. ej., LAN1 o GE1 según el modelo de Edge) se eliminará de la instancia de Edge en modo En espera (Standby) y el estado de HA se establecerá como HA_FAILED en VMware SD-WAN Orchestrator.

      Solución alternativa: reiniciar la instancia de Edge en espera para recuperarla

    • Problema 60006: Cuando la HA está habilitada en instancias de VMware SD-WAN Edge basadas en hardware como 620 y 640, la instancia de Edge en espera puede reiniciarse.

      Cuando la HA está habilitada en 620 o 640 (estos son los modelos en los que se ha observado este problema), la instancia de Edge en espera puede detectar un estado de alarma activo/activo y la instancia de Edge en espera se reiniciará para corregir el estado activo/activo. Este problema se debe a lo siguiente: durante la inicialización de Edge, existe la posibilidad de que se produzca una condición de carrera entre la inicialización de la interfaz de HA y la inicialización de la máquina de estado de HA. En otras palabras, la máquina de estado de HA se inicia mucho antes de que se complete la inicialización del controlador de interfaz de HA y, como resultado, la máquina de estado de HA no detecta ningún latido de la instancia de Edge del mismo nivel y pasa a un estado activo.  Este problema ocurre con poca frecuencia y, si ocurre, lo hace en un sitio concreto, es poco probable que ocurra dos veces en la misma sesión. En otras palabras, no se espera que el sitio entre en un ciclo interminable de reinicios de Edge en espera.

      Solución alternativa: No hay ninguna solución alternativa para este problema, pero, por lo general, el modo de espera se recupera después del primer reinicio.

    • Problema 60225: Al ejecutar el diagnóstico remoto de "Estado de la interfaz" (Interface Status) para una instancia de VMware SD-WAN Edge, la salida de VMware SD-WAN Orchestrator para interfaces SFP muestra información de velocidad y dúplex incorrecta.

      Los datos de Orchestrator no son correctos para las interfaces SFP. Por ejemplo, se muestra 0 Mbps o dúplex medio donde, si se visualiza directamente en Edge, los datos muestran dúplex completo a 1000 Mbps o algo similar.

      Solución alternativa: No existe ningún solución alternativa.

    • Problema 60523: Error de ping a una dirección IP de cliente enrutado si se habilita un sondeo de SLA.

      El paquete de respuesta de ICMP no puede procesarse mediante el servicio de plano de datos de Edge si se habilita un sondeo de SLA para la dirección IP del cliente enrutado.  Sin la corrección, la única forma de resolver este problema es deshabilitar el sondeo de ICMP.

      Solución alternativa: Deshabilite el sondeo de ICMP.

    • Problema 61361: Al aplicar una actualización de software para actualizar una instancia de VMware SD-WAN Edge 3400, 3800 y 3810 a la versión de Edge 3.4.5, 4.0.2 o 4.2.1, es posible que los modelos de Edge no se reinicien inmediatamente después de la actualización.

      Las versiones 3.4.5, 4.0.2 y 4.2.1 incluyen una actualización de firmware específica para el dispositivo lógico programable complejo (CPLD), y la actualización activa un reinicio que a veces puede "bloquearse", lo cual requerirá un ciclo de energía manual para reiniciar el sistema.

      Solución alternativa: Apague y encienda manualmente la instancia de Edge para completar la actualización.

    • Problema 61543: Si se configura más de una regla NAT 1:1 en diferentes interfaces con la misma IP interior, el tráfico entrante puede recibirse en una interfaz y los paquetes salientes del mismo flujo pueden enrutarse a través de otra interfaz diferente.

      Para los flujos de NAT desde el exterior al interior, las reglas NAT 1:1 se compararán con la IP externa y la interfaz donde se reciben los paquetes. Para los paquetes salientes del mismo flujo, VMware SD-WAN Edge intentará hacer coincidir las reglas NAT de nuevo comparando la IP interior, y el tráfico saliente se puede enrutar a través de la interfaz configurada en la primera regla coincidente con "Tráfico saliente" (Outbound Traffic) habilitado.

      Solución alternativa: No hay ninguna solución alternativa para este problema que no sea garantizar que no haya más de una regla NAT 1:1 configurada con una dirección IP interna en particular.

    • Problema 62552: Un sitio puede experimentar períodos intermitentes de alto volumen de pérdida de paquetes y problemas de conectividad.

      La causa de esto es que la API comprueba la resolución de ARP para notificar a Edge que la resolución de ARP de un dispositivo se ha realizado correctamente al proporcionar una dirección MAC 00:00:00:00.  Esta dirección se mantiene en la caché de ARP y se descartan todos los paquetes destinados al dispositivo donde la dirección MAC aparece como cero.  En este problema, se entregan muchas de estas instancias de ARP correctas con cero direcciones MAC y se origina un alto volumen de pérdida de paquetes y problemas de conectividad.

      Nota: Tanto el problema 60130 como este tienen el mismo comportamiento subyacente y la misma causa, pero las correcciones previstas para cada ticket son diferentes. El problema 60130 tendrá una corrección alternativa defensiva, mientras que el problema 62552 tendrá una corrección completa que evitará que se reproduzca.

      Solución alternativa: No hay ninguna solución alternativa para este problema.

    • Problema 63359: Para un sitio configurado con una topología de alta disponibilidad y OSPF, y donde las instancias de VMware SD-WAN Edge utilizan una compilación de Edge de MGMT-IP, cuando estas instancias de Edge se actualizan de la versión 3.4.x a una compilación de MGMT-IP 4.2.x, la conectividad de OSPF puede interrumpirse después de la actualización. 

      Cuando las instancias de Edge de HA se actualizan a una compilación de MGMT-IP 4.2.x, los sistemas de HA pueden definir su identificador de enrutador como 169.254.2.2. Este no es el comportamiento previsto, ya que la selección de Edge del identificador de enrutador no debe tener en cuenta la dirección IP de la interfaz de HA. Este identificador de enrutador interrumpe la conectividad de OSPF y se produce una desconexión completa, ya que ya no se produce el intercambio de rutas.

      Solución alternativa: Reinicie el servicio de Edge (activando una conmutación por error de HA), ya que esto forzará una nueva selección del identificador de enrutador, que debe ser correcto después del reinicio.

    • Problema 67790: Para una empresa de cliente que utiliza BGP u OSPF y ha configurado filtros de entrada para ignorar ciertas rutas, cuando el cálculo de costes dinámicos (DCC) está habilitado en esta empresa, los filtros de entrada ya no estarán activos y el tráfico intentará utilizar esas rutas.

      Antes de habilitar DCC, la base de información de reenvío (FIB) no incluirá las rutas que se establecieron en IGNORAR en el filtro de entrada de BGP/OSPF.  Después de habilitar DCC, la FIB ahora incluye estas rutas y el tráfico intentará utilizar estas rutas, con la posibilidad de una interrupción significativa del tráfico para la empresa del cliente.  

      Solución alternativa: Es necesario reiniciar OSPF/BGP para que el filtro de entrada se aplique correctamente.

    • Problema 84825: Si en un sitio implementado con una topología de alta disponibilidad donde se ha configurado BGP hay establecidas más de 512 reglas de tipo match y set de BGPv4, el cliente puede observar que el par de instancias de Edge de HA conmuten por error constantemente sin recuperarse.

      Cuando hay más de 512 reglas de tipo match y set de BGPv4, se entiende como que un cliente ha configurado más de 256 de este tipo de reglas en el filtro entrante y otras tantas en el filtro saliente. Este problema podría ser disruptivo para el cliente, ya que la conmutación por error reiterada podría provocar que los flujos de tráfico en tiempo real (como las llamadas de voz) se descartaran y volvieran a crearse una y otra vez. Cuando una instancia de Edge de HA experimenta este problema, se produce un error en el proceso que sincroniza los subprocesos de CPU de Edge (lo que hace que Edge se reinicie), pero este mismo problema se experimenta también en la instancia de Edge promocionada, que se reinicia sin posibilidad de recuperación en el sitio.

      Solución alternativa: Sin una solución para este problema, el cliente debe procurar no configurar más de 512 reglas de tipo match y set de BGPv4 para un sitio de HA.

      Si un sitio experimenta este problema y hay más de 512 reglas de tipo match y set de BGPv4 configuradas, el cliente debe reducir inmediatamente la cantidad de reglas a 512 o menos para recuperar el sitio.

      Como opción alternativa, si el cliente debe tener más de 512 reglas de tipo match y set de BGPv4, puede cambiar las instancias de Edge de HA a la versión 3.4.6, donde este problema no sucede, pero a costa de prescindir de las funciones de Edge disponibles en versiones posteriores. Esto solo se puede hacer si el modelo de Edge es compatible con 3.4.6. El cliente debe confirmar que es así antes de cambiar a una versión anterior.

    Problemas conocidos de Orchestrator
    • Problema 19566:

      Tras la conmutación por error de alta disponibilidad, es posible que el número de serie de la instancia de Edge de VMware SD-WAN en espera aparezca como el número de serie activo en Orchestrator.

    • Problema 21342:

      Al asignar puertas de enlace de socio por segmento, es posible que la lista adecuada de asignaciones de puerta de enlace no se muestre en la opción del operador de "Vista" (View) de puertas de enlace en la lista de supervisión de Edge de VMware SD-WAN.

    • Problema 24269:

      Supervisar (Monitor) > Transporte (Transport) > (Loss) no indica de forma gráfica la pérdida de vínculos WAN observados, mientras que los gráficos de Calidad de la experiencia (QoE) reflejan esta pérdida. 

    • Problema 25932:

      VMware SD-WAN Orchestrator permite que las instancias de Puerta de enlace de VMware SD-WAN se eliminen del grupo de puertas de enlace aunque estén en uso.

    • Problema 32335:

      La página del acuerdo de servicio de usuario final (EUSA) genera un error cuando un usuario intenta aceptar el acuerdo.

      Solución alternativa: Asegúrese de que no se haya espacios iniciales ni finales en el nombre de la empresa.

    • Problema 32435:

      Se permite un reemplazo de Edge de VMware SD-WAN para una configuración de NAT basada en directivas para tuplas que ya están configuradas en el nivel del perfil y viceversa.

    • Problema 32856:

      A pesar de que una directiva empresarial está configurada para utilizar el clúster de hubs para el tráfico de Internet de red de retorno, el usuario puede anular la selección del clúster de hubs de un perfil en una instancia de VMware SD-WAN Orchestrator actualizada de la versión 3.2.1 a la versión 3.3.x.

    • Problema 32913:

      Después de habilitar la alta disponibilidad, los detalles de multidifusión de Edge de VMware SD-WAN no se muestran en la página Supervisión (Monitoring). Una conmutación por error resuelve el problema.

    • Problema 33026:

      La página del acuerdo de servicio de usuario final (EUSA) no se vuelve a cargar correctamente después de eliminar el acuerdo.

    • Problema 34828:

      El tráfico no puede pasar entre una instancia de VMware SD-WAN Edge de radios que utiliza la versión 2.x y una instancia de Edge de hub que utiliza la versión 3.3.1.

    • Problema 35658:

      Cuando se mueve un Edge de VMware SD-WAN de un perfil a otro que tiene una configuración de CSS diferente (por ejemplo, IPSec en profile1 a GRE en profile2), la configuración de CSS de nivel de Edge continuará usando la configuración anterior de CSS (por ejemplo, IPSec frente a GRE). 

      Solución alternativa: Deshabilite y vuelva a habilitar GRE en el nivel de Edge para resolver el problema.

    • Problema 35667:

      Cuando se mueve una instancia de Edge de VMware SD-WAN de un perfil a otro que tenga la misma configuración de CSS, pero un nombre de CSS de GRE diferente (los mismos endpoints), algunos túneles de GRE no se mostrarán en la supervisión.

      Solución alternativa: Deshabilite y vuelva a habilitar GRE en el nivel de Edge para resolver el problema.

    • Problema 36665:

      Si VMware SD-WAN Orchestrator no puede acceder a Internet, es posible que las páginas de la interfaz de usuario que requieran acceder a la API de Google Maps no se carguen por completo.

    • Problema 38056:

      El archivo export.csv de licencias de Edge no muestra los datos de región.

    • Problema 38843:

      Cuando se inserta un mapa de aplicaciones, no hay ningún evento de operador y el evento de Edge es de utilidad limitada.

    • Problema 39633:

      El hipervínculo de superpuerta de enlace no funciona después de que un usuario asigna la puerta de enlace alternativa como superpuerta de enlace.

    • Problema 39790:

      VMware SD-WAN Orchestrator permite que un usuario configure una interfaz con enrutamiento de Edge de VMware SD-WAN para que tenga más que las 32 subinterfaces admitidas, lo cual crea el riesgo de que un usuario pueda configurar 33 o más subinterfaces en una interfaz, lo cual provocará un error en el servicio de plano de datos para la instancia de Edge.

    • Problema 40341:

      A pesar de que la aplicación Skype está categorizada correctamente en back-end como tráfico en tiempo real, al editar la directiva empresarial de Skype en VMware SD-WAN Orchestrator, la clase de servicio puede mostrar de forma errónea "Transaccional" (Transactional).

    • Problema 41691:

      El usuario no puede cambiar el campo "Número de direcciones" (Number of addresses), a pesar de que el grupo de DHCP no está agotado en la página Configurar (Configure) > Edge > Dispositivo (Device).

    • Problema 43276:

      El usuario no puede cambiar el tipo de segmento si una instancia de Edge de VMware SD-WAN o un perfil tiene una puerta de enlace de socio configurada.

    • Problema 44153:

      VMware SD-WAN Orchestrator no envía de forma coherente correos electrónicos de alerta a las direcciones de correo electrónico configuradas en la sección "Alertas y notificaciones" (Alerts and Notifications).

    • Problema 46254:

      Durante una activación de Edge de VMware SD-WAN, VMware SD-WAN Orchestrator no detecta una MTU de vínculo WAN modificada ni la presencia de un identificador de VLAN para las interfaces configuradas por DHCP.

    • Problema 47269:

      Es posible que aparezca la interfaz de VMware SD-WAN 510-LTE para los modelos de Edge que no admiten una interfaz de LTE.

    • Problema 47713:

      Si se configura una regla de directiva empresarial mientras la VPN de nube está deshabilitada, la configuración de NAT debe volver a configurarse al habilitar la VPN de nube.

    • Problema 47820:

      Si una VLAN está configurada con DHCP deshabilitado en el nivel del perfil y a la vez también tiene un reemplazo de Edge para esta VLAN en esa instancia de Edge con DHCP habilitado, y existe una entrada para el campo de servidor DNS establecida en ninguno (ninguna IP configurada), el usuario no podrá realizar ningún cambio en la página Configurar (Configure) > Edge > Dispositivo (Device) y obtendrá un mensaje de error de "Dirección IP no válida [ ]" (Invalid IP address) que no explica ni apunta al problema real.

    • Problema 48085:

      VMware SD-WAN Orchestrator permite a un usuario eliminar una VLAN que está asociada con una interfaz.

    • Problema 48737:

      En una instancia de VMware SD-WAN Orchestrator que utiliza la nueva interfaz de usuario de la versión 4.0.0, si un usuario se encuentra en una página Supervisar (Monitor) y cambia el intervalo de tiempo de inicio y finalización y, a continuación, se desplaza entre las pestañas, Orchestrator no actualiza el tiempo de intervalo de inicio y finalización a los nuevos valores.

    • Problema 49225:

      VMware SD-WAN Orchestrator no aplica un límite de 32 VLAN totales.

    • Problema 49790:

      Cuando se activa una instancia de Edge de VMware SD-WAN a la versión 4.0.0, la activación se publica dos veces en Eventos (Events).

      Solución alternativa: Ignore el evento duplicado.

    • Problema 50531:

      Cuando dos operadores con privilegios diferentes usan la misma ventana del navegador al acceder a la nueva interfaz de usuario de la versión 4.0.0 de VMware SD-WAN Orchestrator y el operador con menos privilegios intenta iniciar sesión después del operador con más privilegios, el operador con menos privilegios observará varios errores que indican que el usuario no tiene privilegios.

      Nota: No hay ningún aumento de privilegios para el operador con menos privilegios; solo se muestran los mensajes de error.

      Solución alternativa: El siguiente operador puede actualizar esa página antes de iniciar sesión para evitar que se vean los errores, o bien cada operador puede utilizar diferentes ventanas del navegador para evitar este problema de visualización.

    • Problema 51722: En la versión 4.0.0 de VMware SD-WAN Orchestrator, el selector de intervalo de tiempo no supera las dos semanas para las estadísticas de las pestañas Supervisar (Monitor) > Edge.

      El selector de intervalo de tiempo no muestra opciones superiores a "Últimas 2 semanas" (Past 2 Weeks) en las pestañas Supervisar (Monitor) > Edge, incluso si el período de retención de un conjunto de estadísticas es mucho mayor que 2 semanas.  Por ejemplo, las estadísticas de flujo y vínculo se conservan durante 365 días de forma predeterminada (lo cual se puede configurar), mientras que las estadísticas de ruta se conservan solo durante 2 semanas de forma predeterminada (también se puede configurar).  Este problema consiste en hacer que todas las pestañas de supervisión cumplan el tipo de estadísticas retenido más bajo, en lugar de permitir que un usuario seleccione un período de tiempo coherente con el período de retención de esa estadística.

      Solución alternativa: Un usuario puede utilizar la opción "Personalizado" (Custom) en el selector de intervalo de tiempo para ver los datos de más de 2 semanas.

    • Problema 60039: La reactivación de RMA no funciona cuando se cambia el modelo de VMware SD-WAN Edge.

      Cuando se realiza una reactivación de RMA para un sitio en el que también se cambia el modelo de Edge, VMware SD-WAN Orchestrator no guarda el cambio de modelo, lo cual hace que el vínculo de reactivación no sea eficaz. Esto solo afecta a las reactivaciones de RMA en las que se cambia el modelo de Edge; una reactivación de RMA en la que el modelo de Edge sigue siendo el mismo funcionará según lo esperado.

      Solución alternativa: Si utiliza un modelo de Edge diferente para un sitio, el usuario deberá crear una nueva instancia de Edge y aplicar manualmente toda la configuración específica de Edge.

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