RSS
 

VMware SD-WAN Versão 4.3.2 | 17 de fevereiro de 2023

  • VMware SD-WAN™ Orchestrator versão R432-20221108-GA

  • VMware SD-WAN™ Gateway versão R432-20221115-GA

  • VMware SD-WAN™ Edge versão R432-20221115-GA

Verifique se existem adições e atualizações a estas notas de versão.

O que está nas notas de versão

As notas de versão abrangem os seguintes tópicos:

Utilização recomendada

Esta versão é recomendada para todos os clientes que necessitem das funcionalidades disponibilizadas pela primeira vez na versão 4.3.0, bem como para os clientes afetados pelos problemas indicados abaixo que foram resolvidos desde a versão 4.3.1.

A versão 4.3.2 contém todas as correções do Edge, Gateway e Orchestrator que estão listadas nas notas de versão 4.3.0 ou 4.3.1.

Compatibilidade

A versão 4.3.2 dos Orchestrators, Gateways e Edges Hub suporta todas as versões anteriores do VMware SD-WAN Edge iguais ou superiores à versão 3.4.0 

Isto significa que as versões anteriores à 3.4.0 não são suportadas.

Foram explicitamente testadas as seguintes combinações de interoperabilidade:

Orchestrator

Gateway

Edge

Hub

Ramo/Spoke

4.3.2

3.4.1

3.4.4

3.4.4

4.3.2

4.3.2

3.4.4

3.4.4

4.3.2

4.3.2

4.3.2

3.4.4

4.3.2

4.3.2

3.4.4

4.3.2

4.3.2

3.4.1

3.4.6

3.4.6

4.3.2

4.3.2

3.4.6

3.4.6

4.3.2

4.3.2

4.3.2

3.4.6

4.3.2

4.3.2

3.4.6

4.3.2

4.3.2

4.2.2

4.2.2

4.2.2

4.3.2

4.3.2

4.2.2

4.2.2

4.3.2

4.3.2

4.3.2

4.2.2

4.3.2

4.3.2

4.2.2

4.3.2

4.3.2

4.3.1

4.3.1

4.3.1

4.3.2

4.3.2

4.3.1

4.3.1

4.3.2

4.3.2

4.3.2

4.3.1

4.3.2

4.3.2

4.3.1

4.3.2

4.3.1

4.3.2

4.3.1

4.3.1

4.3.1

4.3.2

4.3.2

4.3.1

4.3.1

4.3.2

4.3.1

4.3.2

5.0.1.0

4.3.2

4.3.2

4.3.2

4.5.1

4.3.2

4.3.2

4.3.2

Nota: a versão 3.x não suportava adequadamente o AES-256-GCM, o que significava que os clientes que utilizavam o AES-256 estavam sempre a utilizar os Edges com o GCM desativado (AES-256-CBC). Se um cliente estiver a utilizar o AES-256, deverá desativar explicitamente o GCM do Orchestrator antes de atualizar os Edges para a versão 4.x. Uma vez que todos os Edges estão a executar a versão 4.x, o cliente pode escolher entre o AES-256-GCM e o AES-256-CBC.

As versões 3.2.x e 3.3.x do VMware SD-WAN para todos os componentes e a versão 3.4.x para o Orchestrator e o Gateway chegaram ao fim do suporte.

  • As versões 3.2.x e 3.3.x chegaram ao fim do suporte geral (EOGS) a 15 de dezembro de 2021 e ao fim da orientação técnica (EOTG) a 15 de março de 2022.

  • A versão 3.4.x do Orchestrator e do Gateway chegou ao fim do suporte geral (EOGS) a 30 de março de 2022 e chegará ao fim da orientação técnica (EOTG) a 30 de setembro de 2022.

  • Nota: Diz apenas respeito ao Orchestrator e ao Gateway. A versão 3.4.x do Edge está agendada para chegar ao fim do suporte a partir de 31 de dezembro de 2022.

  • Para mais informações, consulte o artigo da Base de Dados de Conhecimentos: Anúncio: fim do período de suporte para a versão 3.x (84151) do VMware SD-WAN

A versão 4.0.x do VMware SD-WAN chegou ao fim do suporte para Gateways e Orchestrators. As versões 4.2.x e 4.3.x estão a aproximar-se do fim de suporte.

  • A versão 4.0.x chegou ao fim do suporte geral (EOGS) a 30 de setembro de 2022 e ao fim da orientação técnica (EOTG) a 31 de dezembro de 2022. 

  • A versão 4.2.x dos Orchestrators e dos Gateways chegou ao fim do suporte geral (EOGS) a 30 de dezembro de 2022 e chegará ao fim da orientação técnica (EOTG) a 30 de março de 2023.

  • A versão 4.2.x dos Edges chegará ao fim do suporte geral (EOGS) a 30 de junho de 2023 e ao fim da orientação técnica (EOTG) a 30 de setembro de 2025.

  • A versão 4.3.x dos Orchestrators e dos Gateways chegará ao fim do suporte geral (EOGS) a 30 de junho de 2023 e ao fim da orientação técnica (EOTG) a 30 de setembro de 2023.

  • A versão 4.3.x dos Edges chegará ao fim do suporte geral (EOGS) a 30 de junho de 2023 e ao fim da orientação técnica (EOTG) a 30 de setembro de 2025.

  • Para mais informações, consulte o artigo da Base de Dados de Conhecimentos: Anúncio: fim do período de suporte para a versão 4.x (88319) do VMware SD-WAN

Notas importantes

Misturar Edges capazes de Wi-Fi e não capazes de Wi-Fi em alta disponibilidade não é suportado 

A partir de 2021, o VMware SD-WAN introduziu modelos Edge que não incluem um módulo de Wi-Fi: os modelos Edge 510N, 610N, 620N, 640N e 680N. Embora estes modelos pareçam idênticos aos seus congéneres com Wi-Fi, com exceção do Wi-Fi, a implementação de um Edge com capacidade de Wi-Fi e um Edge sem capacidade de Wi-Fi do mesmo modelo (por exemplo, um Edge 640 e um Edge 640N) como um par de alta disponibilidade não é suportada. Os clientes devem verificar se os Edges implementados como um par de alta disponibilidade são do mesmo tipo: ambos com capacidade de Wi-Fi, ou ambos sem capacidade de Wi-Fi.

Alteração ao delimitador da configuração de filtro BGPv4 para o AS-PATH precedente

Até à versão 3.x, a configuração de filtro BGPv4 para o AS-PATH precedente do VMware SD-WAN suportava delimitadores baseados em vírgula e espaço. No entanto, a partir da versão 4.0.0 e posterior, o VMware SD-WAN irá suportar apenas um delimitador baseado em espaço numa configuração de AS-Path precedente. Os clientes que atualizem da versão 3.x para a versão 4.x devem editar as configurações de AS-PATH precedente para “substituir vírgulas por espaços” antes de efetuarem a atualização para evitar uma seleção incorreta do melhor caminho BGP.

Reverse Path Forwarding (RPF) ativado por predefinição

Em versões anteriores, os pacotes com origem desconhecida eram permitidos na interface LAN de um VMware SD-WAN Edge. Este comportamento prendia-se com o facto de as interfaces LAN do Edge não terem o Reverse Path Forwarding (RPF) ativado por predefinição. Como parte do Problema 52628 resolvido adicionado pela primeira vez com a versão 3.4.5, este comportamento foi alterado com a ativação do RPF em todas as interfaces LAN do Edge, sendo que os pacotes de interfaces LAN só seriam permitidos se tivessem origem na sub-rede LAN configurada.

Agora, os túneis Zscaler utilizam o IKEv2

Assim que um Orchestrator e os Gateways forem atualizados para a versão 4.3.0 ou posterior, os túneis de todos os Destinos Não-SD-WAN via Gateway que utilizem um tipo Zscaler serão alterados para o IKEv2 e deixarão de utilizar o IKEv1.

Tempo de atualização alargado para os modelos Edge 3x00

As atualizações para esta versão podem demorar mais do que o normal (3 a 5 minutos) nos modelos Edge 3x00 (ou seja, 3400, 3800 e 3810). Isto deve-se a uma atualização de firmware que resolve o problema 53676. Se um Edge 3400 ou 3800 tivesse atualizado previamente o seu firmware na versão 3.4.5 ou posterior; 4.0.2; 4.2.0 ou posterior; ou 4.3.0, o Edge seria atualizado conforme esperado. Para obter mais informações, consulte Problema 53676 resolvido nas notas da versão 3.4.5, 4.0.2, 4.2.0 ou 4.3.0.

Limitação com a automatização da WAN Virtual do Azure e do BGP através de IPsec no Edge e no Gateway.

A funcionalidade do BGP através de IPsec no Edge e no Gateway não é compatível com a automatização da WAN Virtual do Azure no Edge ou no Gateway. Apenas os caminhos estáticos são suportados ao automatizar a conetividade de um Edge ou Gateway para uma vWAN do Azure.

Limitação ao desativar a negociação automática nos modelos VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 e 3810

Quando um utilizador desativa a negociação automática para codificar a velocidade e o duplex nas portas GE1–GE4 num modelo VMware SD-WAN Edge 620, 640 ou 680; nas portas GE3 ou GE4 num Edge 3400, 3800 ou 3810; ou num Edge 520/540 quando um SFP com interface de cobre é utilizado nas portas SFP1 ou SFP2, o utilizador pode descobrir que, mesmo após um reinício, a ligação não aparece.

Tal deve-se ao facto de cada um dos modelos Edge indicados utilizar o Intel Ethernet Controller i350, que tem a seguinte limitação: quando a negociação automática não é utilizada em ambos os lados da ligação, não consegue detetar dinamicamente os fios adequados para transmitir e receber (MDIX automático). Se ambos os lados da ligação estiverem a transmitir e a receber nos mesmos fios, a ligação não será detetada. Se o lado do par também não suportar o MDIX automático sem a negociação automática e a ligação não aparecer com um cabo reto, será necessário um cabo Ethernet cruzado para estabelecer a ligação.

Para obter mais informações, consulte o artigo da BDC Limitação ao desativar a negociação automática nos modelos VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 e 3810 (87208).

Histórico de revisões do documento

16 de novembro de 2022. Primeira edição

22 de novembro de 2022. Segunda edição

  • Atualização da compilação do Edge de R432-20221109-GA para R432-20221115-GA. A compilação do Edge R432-20221109-GA foi erroneamente listada como a compilação GA do Edge inicial.

  • Foi adicionado o Problema resolvido 51486 à secção Resolvidos no Edge/Gateway para a versão do Edge R432-20221109-GA. Este problema foi acidentalmente omitido da edição original.

  • Foi adicionado o Problema pendente 97559 à secção Problemas conhecidos do Edge/Gateway.

06 de dezembro de 2022. Terceira edição

  • Foi adicionado o Problema resolvido 92758 à secção Resolvidos no Edge/Gateway para a versão do Edge R432-20221109-GA. Este problema foi acidentalmente omitido da edição original.

  • Foi adicionado o Problema pendente 86994 à secção Problemas conhecidos do Edge/Gateway.

30 de janeiro de 2023. Quarta edição.

  • O pedido 89217 corrigido foi revisto para refletir uma versão (R5012-20230123-GA-103475) revista do Edge e a versão (R131-20221216-GA) do firmware da plataforma necessárias para resolver o problema. O pedido também adiciona uma ligação para o artigo da BDC que aborda o problema 89217 e inclui instruções passo a passo para atualizar um Edge 6x0.

  • Na secção Compatibilidade, foi revista a Nota importante relativa ao fim do suporte da versão 4.2.x e foi adicionada a versão 4.3.x para refletir as datas recentemente revistas para o software SD-WAN Edge.

17 de fevereiro de 2023. Quinta edição.

  • Problema 39659 removido da secção Problemas conhecidos do Edge/Gateway já que este é um duplicado de outro pedido, 39501 que foi resolvido na Versão 4.3.0.

Resolvido no Edge/Gateway

Resolvido na versão R432-20221115-GA do Edge e do Gateway

A versão R432-20221115-GA do Edge e do Gateway foi lançada em 16/11/2022 e resolve os seguintes problemas desde a versão R431-20220608-GA do Edge/Gateway.

A versão 4.3.2 contém todas as correções do Edge e Gateway que estão listadas nas notas de versão 4.3.0 ou 4.3.1.

  • Problema 34234 resolvido: uma ligação WAN num VMware SD-WAN Edge pode apresentar um valor de capacidade de largura de banda incorreto na IU do Orchestrator e o cliente pode observar que a ligação WAN não está a ser utilizada na capacidade de largura de banda real.

    Com este problema, a ligação WAN não é medida novamente para obter o valor de capacidade de largura de banda mais atual com a frequência especificada. Isto deve-se ao facto de o serviço repor a data na cache do valor da largura de banda sempre que um túnel fica inativo/ativo (ou seja, um flap) na ligação WAN. Como o valor da largura de banda em cache é reposto, o serviço SD-WAN é enganado e considera que este é um novo valor, pelo que não são necessários testes de largura de banda adicionais. Numa ligação WAN onde existem flaps de túnel frequentes, este valor da largura de banda da ligação WAN pode ser bastante antigo e não representa os valores atuais da largura de banda da ligação WAN, o que irá provocar problemas de tráfego ao cliente, uma vez que o serviço SD-WAN não utilizará a ligação WAN na sua capacidade real.

  • Problema 35807 resolvido: Uma interface encaminhada por DPDK será completamente desativada se a interface for desativada e novamente ativada no VMware SD-WAN Orchestrator.

    Desativar uma porta encaminhada desassocia esse dispositivo de rede do hardware controlado por DPDK e volta a associá-lo ao driver Linux do Edge após o reinício do serviço Edge. O ficheiro DPDK do Edge é atualizado para remover esta interface, pelo que, na reativação, o ficheiro não é atualizado para ser desassociado do Linux de volta para o driver controlado por DPDK.

    Num Edge sem esta correção, a solução alternativa é reiniciar o Edge para limpar o estado e voltar a um estado de arranque padrão para voltar a adicionar dispositivos à camada DPDK do Edge.

  • Problema 37813 resolvido: num local de cliente que utiliza uma topologia de Alta Disponibilidade melhorada, ao executar o “Estado da Interface” (Interface Status) de diagnóstico remoto, as interfaces do Edge em standby não mostram velocidade e negociação automática.

    O VMware SD-WAN Edge na função ativa não obtém os detalhes de velocidade e negociação automática do Edge em standby onde a interface está ativa, pelo que os detalhes não podem ser apresentados.

  • Problema 45545 resolvido: as informações podem não ser precisas para a consulta SNMP da interface do VMware SD-WAN Edge.

    O processo do Edge para o SNMP MIB-IF é extrair estatísticas de interface do SO do Linux, em vez de extrair estatísticas de interface da execução do comando debug.py --interfaces. O comando debug.py --interfaces fornece sempre informações precisas de interface, ao passo que existe a possibilidade de os resultados do Linux não serem precisos.

  • Problema 48017 resolvido: os caminhos OSPF e BGP podem demorar mais tempo do que o esperado para convergir no Controlo de fluxo de overlay (OFC).

    Sob carga elevada, pode surgir uma situação em que alguns ou todos os caminhos aprendidos num VMware SD-WAN Edge podem não aparecer no OFC ou não ter atribuído o valor de anúncio e de preferência necessário (isto ocorre quando o Cálculo dinâmico de custos (DCC) não é utilizado). Isto pode levar a que o Edge volte constantemente a repetir a sincronização desses caminhos para o VMware SD-WAN Orchestrator, o que aumentará ainda mais a carga no Orchestrator.

  • Problema 49165 resolvido: para um Edge virtual do VMware SD-WAN implementado no GCP (Google Cloud Platform), um caminho ligado ativado por DHCP não é anunciado quando a opção “Anunciar” (Advertise) está marcada na interface.

    Depois de configurar o caminho ligado no Edge virtual do tipo GCP, o utilizador observaria que o prefixo não está presente no Controlo de fluxo de overlay (OFC) e que o fluxo de tráfego é interrompido para esse caminho.

    Num Edge virtual sem esta correção, a única solução alternativa é configurar um caminho estático para a interface configurada localmente com a opção “Anunciado” (Advertised) marcada na interface para o caminho a ser anunciado.

  • Problema 50920 resolvido: o VMware SD-WAN Edge não envia um aviso quando o número de túneis ligados atinge 60% do limite definido pelo hardware para esse modelo Edge.

    O Edge envia um aviso quando o número de túneis ligados atinge o respetivo limite de hardware que diz “A contagem de túneis estabelecidos excede a capacidade do dispositivo” (Established tunnel count exceeds the device capacity). Uma vez atingido este limite, o Edge não permitirá túneis dinâmicos adicionais até que os túneis existentes estejam inativos. No entanto, não é enviado nenhum aviso intermédio para avisar o cliente de que este limite de túneis pode ser atingido, o que deixa o cliente sem um tempo de antecedência adequado para gerir a rede.

  • Problema 51036 resolvido: as ifStats comunicam o valor errado ao consultar um VMware SD-WAN Edge através do SNMP se as interfaces do Edge estiverem configuradas para utilizar o DPDK.

    Este é um comportamento esperado para portas configuradas por DPDK tanto em Edges de hardware como virtuais. A única forma de obter os valores de velocidade para as portas configuradas por DPDK é utilizar o comando debug.py --dpdk_ports. No entanto, o módulo SNMP do Edge não depende deste comando para extrair valores de velocidade para portas configuradas por DPDK. O SNMP apenas consulta através da interface de kernel do Linux do Edge, que, infelizmente, não preenche os valores de velocidade para dpdk_ports. Numa compilação do Edge com uma correção para este problema, o SNMP depende do comando debug.py --dpdk_ports para recolher estatísticas para portas configuradas por DPDK.

  • Problema 51486 resolvido: O utilizador não consegue realizar o SSH num VMware SD-WAN Edge com uma interface de retorno.

    Após a remoção da interface de gestão e a introdução de interfaces de retorno no Edge, o suporte para SSH para qualquer interface virtual (sempre ativa) do Edge não é suportado.

    A partir da versão 4.3.2 do Edge, o utilizador pode realizar o SSH num Edge com uma interface de retorno.

  • Problema 57281 resolvido: um VMware SD-WAN Edge pode entrar num estado em que o Edge desencadeia uma exceção e reinicia.

    Este problema pode ser encontrado numa empresa de cliente com uma topologia Hub/Spoke onde são utilizados vários Hubs. A exceção é desencadeada devido a um acesso inválido à memória nos caminhos de destino no controlo de fluxo e é causada pela falta de uma confirmação adequada para tal situação.

  • Problema 63577 resolvido: para uma empresa de cliente que utiliza um Serviço de Segurança na Cloud (CSS) do tipo Zscaler, se o túnel principal ficar inativo, ocorrer a recuperação automática do tráfego para o túnel secundário e, em seguida, o túnel principal for restaurado, o tráfego no túnel secundário volta imediatamente para o túnel principal.

    Neste cenário, quando o túnel principal do Zscaler voltar a ficar ativo, espera-se que os fluxos existentes no túnel secundário sejam mantidos durante, pelo menos, 30 minutos antes de voltarem ao túnel principal. Neste problema, os fluxos existentes voltam ao túnel principal imediatamente após o respetivo restauro. Este comportamento mantém-se em todos os tipos de túneis, incluindo IPsec e GRE.

  • Problema 66691 resolvido: num modelo VMware SD-WAN Edge 6x0 (610/620/640/680), o estado de negociação automática não é apresentado corretamente.

    A negociação automática não é suportada na SFP1 e SFP2 como resultado da NIC Intel x553 utilizada por todos os modelos Edge 6x0. Todavia, a negociação automática é suportada no GE1-GE6 (portas de cobre). No entanto, o ethtool do Edge comunica que a negociação automática está sempre ativa para todas as portas devido a um defeito no controlador ixgbe.

  • Problema 66944 resolvido: Um VMware SD-WAN Gateway pode encontrar uma falha do Serviço dataplane e, como resultado, reiniciar.

    Este problema ocorre raramente, mas é desencadeado por um Gateway que realiza um processo de limpeza de caminhos que encontra uma cadeia AS local com um valor nulo, o que não era esperado.

  • Problema 68335 resolvido: para uma empresa de clientes que utiliza uma topologia Hub/Spoke onde os Hubs são Clusters, os VMware SD-WAN Spoke Edges que não se conseguem ligar a um cluster de Hub podem consumir grandes quantidades de largura de banda que é classificada como tráfego de controlo SD-WAN.

    Quando um Spoke Edge não estabelece overlays com os respetivos clusters de Hub do centro de dados, o Edge solicita aos controladores que reatribuam um membro de cluster diferente, o que faz com que os controladores enviem eventos de controlo contínuos e consumam largura de banda da ligação.

    Num Edge sem uma correção para este problema, a solução alternativa será criar e atribuir um perfil temporário sem atribuir o cluster de Hub inacessível no respetivo perfil.

  • Problema 70919 resolvido: num VMware SD-WAN Edge com a versão 4.2.1 GA que também seja compatível com Wi-Fi, os utilizadores poderão não conseguir ligar-se ao Wi-Fi do Edge e não é transmitido qualquer SSID.

    Quando o Edge não está a transmitir Wi-Fi, a interface wlan0 (WLAN1 na IU do Orchestrator) não é detetada quando são verificados os registos. Este é o resultado de uma exceção no firmware da placa de Wi-Fi que ocorre sob tráfego intenso. Esta exceção faz com que o Wi-Fi falhe.

    No registo do kernel, o utilizador verá mensagens como as seguintes:

    2021-08-26T01:05:21.397 WARNIN kern kernel:[244841.443763] ath10k_pci 0000:01:00.0: SWBA overrun on vdev 1, skipped old beacon 2021-08-26T01:05:21.539 INFO kern kernel:[244841.586338] ieee80211 phy0: Hardware restart was requested 2021-08-26T01:05:24.207 WARNIN kern kernel:[244844.254081] ath10k_warn: 17 callbacks suppressed 2021-08-26T01:05:24.207 WARNIN kern kernel:[244844.254091] ath10k_pci 0000:01:00.0: failed to receive control response completion, polling.. 2021-08-26T01:05:24.223 ERR kern kernel:[244844.270245] ath10k_pci 0000:01:00.0: firmware crashed! (guid n/a)

    A remediação para este problema é utilizar um script que deteta uma falha de firmware e recarrega os módulos de kernel do Wi-Fi. Como parte do recarregamento do módulo, o script também executa uma reposição PCIe do dispositivo Wi-Fi, o que reinicia o firmware e prepara o dispositivo para a utilização. A deteção de uma falha e a subsequente recuperação podem demorar entre 30 e 40 segundos e, durante este tempo, o Wi-Fi não estará disponível. Esta deve ser vista como uma correção defensiva e não como uma correção completa que evita que o problema ocorra.

    Sem o script, para restaurar o Wi-Fi, o utilizador tem de reiniciar ou encerrar e voltar a ligar o Edge.

  • Problema 71719 resolvido: a ligação PPTP não é estabelecida ao longo do caminho Edge para Cloud.

    A ligação a um servidor PPTP por trás de um VMware SD-WAN Edge não é estabelecida.

    Num Edge sem uma correção para este problema, não existe uma solução alternativa, nem mesmo um reinício ou reinicialização do Edge.

  • Problema 71785 resolvido: O caminho SNMP pode não funcionar corretamente numa versão 4.3.0 ou posterior em execução do Edge.

    Quando um Edge é atualizado para a versão 4.3.0, alguns IPs que o SNMP utiliza estão bloqueados e as definições de Firewall têm de ser alteradas para permitir o tráfego na Porta 161. 

  • Problema 71788 resolvido: Para um cliente implementado com uma topologia de alta disponibilidade, existe potencial para ocorrer uma recuperação automática de HA inesperada no site que inclui uma perturbação do cliente ao nível do tráfego.

    Este é um problema inconsistente que não é facilmente recriado, mas quando é encontrado, o thread de manipulador periódico do Edge HA executa mais de 180 ms durante a sincronização de fluxo entre o Edge ativo e em standby, o que causa um impasse e desencadeia uma mensagem SIGKILL no thread mutex mon do Edge ativo, resultando num núcleo e num reinício do Edge.

  • Problema 71977 resolvido: para um cliente que utilize o VMware Edge Network Intelligence, quando a Análise está ativada para um VMware SD-WAN Edge, tal pode resultar em múltiplas falhas do Serviço dataplane e fazer com que o serviço Edge seja reiniciado em cada falha.

    Este problema é desencadeado quando um utilizador ativa a Análise enquanto o número de sessões criadas dinamicamente no Edge excede o limite máximo permitido. As falhas do serviço interrompem o tráfego do cliente e, se houver três falhas consecutivas, o Serviço dataplane será desligado para esse Edge. Embora o tráfego do cliente continue a ser transmitido e o Edge possa ser configurado através do Orchestrator, o tráfego do cliente não beneficiará da Otimização dinâmica de vários caminhos (DMPO). A falta da DMPO significa que a qualidade do tráfego do cliente pode ser afetada, porque não há priorização de tráfego, direção de ligação nem correção de erros.

    O utilizador terá de reiniciar o Edge para recuperar o Serviço dataplane. Tal pode ser efetuado no Orchestrator, através de Ações remotas > Reiniciar Edge (Remote Actions > Reboot Edge), mas só deverá ser feito num período de administração, pois o tráfego do cliente será interrompido durante 2 a 3 minutos.

  • Problema 72245 resolvido: Se um VMware SD-WAN Hub Edge for utilizado como fuga da Internet de uma rede MPLS, os túneis de gestão (VCMP) da interface privada de um Edge Spoke ligado para quaisquer Gateways públicos podem ficar inativos ou não aparecer.

    Os pacotes de gestão (VCMP) da interface privada de um Edge Spoke para o Gateway público são enviados através do Edge Hub. Neste cenário, o Hub considera este fluxo como um fluxo direto e emite estes pacotes para a Internet através de uma interface pública. No entanto, devido a problemas de routing, estes fluxos podem ser marcados como “Via Gateway”, o que os pode afetar e provocar o problema descrito acima.

  • Problema 72270 resolvido: Para Edges implementados numa alta disponibilidade, as atualizações de software que também incluem uma atualização de firmware podem fazer com que os Edges HA sejam inesperadamente atualizados e reiniciados em conjunto e desencadeiem perturbações no tráfego de clientes e na aprendizagem de caminhos OSPF ou BFD.

    Isto é verdade para os modelos Edge 3x00 que se atualizam para uma compilação que inclui uma atualização de firmware CPLD. Deverão ser realizadas primeiro as atualizações do Edge em standby e depois a recuperação automática para o Ativo para que o Ativo se possa atualizar, mas o Ativo aguarda a recuperação automática ou, na ausência de uma recuperação automática, observa um atraso de cinco minutos antes de também se atualizar. O Edge em standby também está a atualizar o seu firmware, incluindo o kernel do SO, que pode demorar mais de cinco minutos e criaria um cenário em que tanto o Edge em standby como o Edge ativo estão a atualizar e a reiniciar simultaneamente, causando perturbações no tráfego do cliente e a forçar os caminhos OSPF ou BFD, o que já é disruptivo. Aqui a correção é simplesmente estender o temporizador do Standby para garantir que apenas um Edge está a atualizar de cada vez.

  • Problema 72425 resolvido: os caminhos OSPF não são anunciados nas localizações remotas, mesmo que um utilizador possa ver o caminho recebido pelo VMware SD-WAN Edge local.

    O problema é o resultado de uma condição race no Edge ao processar eventos NSM (Computador de estado de vizinho) do OSPF e adições de caminhos. No estado de problema, quando é adicionado o caminho OSPF à RIB (Base de informações de encaminhamento), o Edge não processa as informações de vizinho do OSPF, porque não processou o evento de estado NSM do OSPF. Com tal, o Edge adiciona o caminho OSPF com o IP de vizinho de 0. Se o IP de vizinho for 0, o Edge não sincronizará o caminho com o Orchestrator nem o anunciará ao Gateway, motivo pelo qual o caminho não será visto nem no Controlo de fluxo de overlay (OFC) nem no Gateway.

  • Problema 72498 resolvido: um cliente pode observar que um VMware SD-WAN Edge está a consumir uma percentagem cada vez maior da memória e, em modelos com menores quantidades de memória disponíveis (por exemplo, Edge 510, 520, 610s), o Edge pode iniciar um reinício de serviço para limpar a memória, o que causará uma interrupção de 5 a 10 segundos no tráfego do cliente.

    Este problema é caudado por uma fuga de memória. Numa implementação de rede em que o Edge a Edge Dinâmico está ativado e o Edge está a criar e a remover dinamicamente um elevado número de túneis com outros Edges na rede, o Edge não limpa os IKEs antigos dos túneis removidos, o que lentamente consome memória ao longo do tempo com o potencial de que os Edges de pouca memória poderem atingir um nível crítico, fazendo com que um serviço Edge seja reiniciado para limpar a memória.

    Sem a correção, o utilizador poderia reiniciar preventivamente o serviço Edge numa janela de manutenção para limpar a memória. No entanto, ocorreria novamente uma fuga lenta de memória do Edge.

  • Problema 72859 resolvido: um VMware SD-WAN Edge pode registar uma falha no Serviço dataplane e, como resultado, ser reiniciado, provocando uma interrupção no tráfego do cliente de 10 a 15 segundos ou uma recuperação automática de alta disponibilidade, dependendo da topologia do cliente.

    Este problema é provocado quando o Edge recebe fragmentos de pacotes em que o protocolo é indefinido ou algo inesperado. Quando este problema ocorre, o Edge remove o pacote. Contudo, antes de o remover, o Edge efetua uma pesquisa e o serviço Edge espera que essa pesquisa seja sempre bem-sucedida, apesar de poder falhar. E, quando a pesquisa falha, desencadeia um problema no Serviço dataplane do Edge e faz com que falhe e seja reiniciado. O problema é corrigido através da inclusão de uma verificação NULL, que impede o Serviço dataplane de falhar numa pesquisa de pacotes falhada.

  • Problema 72925 resolvido: para um cliente que utiliza consultas SNMP para monitorizar a sua empresa e implementa modelos inferiores de VMware SD-WAN Edges (por exemplo, os modelos Edge 510, 520 ou 610) que estão a executar uma versão de software 4.x, as consultas SNMP demoram bastante tempo a processar e podem, inclusivamente, exceder o limite de tempo.

    Este problema reduz significativamente a eficácia das consultas SNMP para monitorização de redes ao utilizar Edges das séries 510, 5x0 e 6x0. Este problema é causado pelo SNMPAgent da versão 4.x, que demora bastante tempo a percorrer a lista de comandos de depuração, o que não é efetivamente necessário para o processo SNMP.

  • Problema 73830 resolvido: o tráfego de aplicações do System Center Configuration Manager (SCCM) é incorretamente classificado pelo VMware SD-WAN Edge como tráfego do Business Intelligence Service (BITS) e os clientes que utilizem Políticas empresariais ou Regras de firewall concebidas para o tráfego do SCCM observarão um impacto no tráfego.

    O motor de Inspeção profunda de pacotes (DPI) do Edge classifica incorretamente os pacotes de aplicações do SCCM como tráfego do BITS e, caso haja Políticas empresariais ou Regras de firewall concebidas para direcionar esse tráfego ou garantir que o mesmo é permitido pelas regras de firewall, as classificações incorretas poderão fazer com que o tráfego do SCCM seja bloqueado, levando a uma interrupção para o cliente. A remediação deste problema envolveu corrigir os mapas de aplicação 4.5.1 e posteriores predefinidos, para assegurar que esta classificação incorreta é evitada.

  • Problema 74149 resolvido: Para um cliente que utilize um Serviço de Segurança na Cloud do tipo Zscaler, em que a verificação de estado de funcionamento de L7 está ativada, se um VMware SD-WAN Edge for reiniciado enquanto uma ligação WAN também estiver inativa, o processo de verificação de estado de funcionamento de L7 pode não enviar sondas para o serviço Zscaler mesmo depois de o Edge e as ligações WAN estarem totalmente restaurados.

    Este problema não é consistente e raramente acontece, mesmo quando são cumpridas as condições indicadas. Quando o Edge está a ser reiniciado e a verificação de estado de funcionamento de L7 estiver ativada e se a interface WAN do Edge for submetida a uma transição de estado Ativa/Inativa, durante o tempo de reinicialização e inicialização, o Edge pode falhar no envio de sondas L7.

    Sem a correção, a única forma de fazer com que o Edge retome o envio de sondas L7 é desativar/reativar (desativar, guardar as alterações e, depois, reativar e guardar as alterações) a verificação de estado de funcionamento de L7.

  • Problema 74291 resolvido: Um VMware SD-WAN Edge numa topologia de alta disponibilidade pode aparecer como offline após uma recuperação automática, apesar de ter acesso à Internet e um DNS funcional.

    Este problema pode ocorrer após uma recuperação automática de alta disponibilidade e é provocado por um token de erro no recentemente promovido Edge Ativo, o que resulta numa falha do heartbeat para o Orchestrator. Sem o heartbeat, o Orchestrator marca o Edge como inativo e um utilizador não poderia emitir quaisquer alterações de configuração para este Edge HA até que a conectividade fosse restaurada ao Orchestrator.

    Sem uma compilação do Edge com a correção, a forma de remediar o problema é forçar localmente outra recuperação automática através da IU local ou através do arranque do Edge ativo.

  • Problema 74306 resolvido: Um utilizador que realize uma chamada de Skype por trás de um VMware SD-WAN Edge pode experienciar uma qualidade de chamada pior do que o esperado.

    Por predefinição, o serviço VMware SD-WAN classifica todos os pacotes do Skype e MS Teams, incluindo pacotes de chamadas, como classe APP_CLASS_INTERNET_INSTANT_MESSAGING (10). A classe de mensagens instantâneas tem uma prioridade menor e, portanto, as chamadas podem ser afetadas por não serem uma prioridade da largura de banda e da qualidade de ligação. A correção altera os pacotes correspondentes ao Skype e ao MS Teams para APP_CLASS_BUSINESS_COLLABORATION (5), o que significa que as chamadas receberiam o tratamento de nível de qualidade de Prioridade alta/Tempo real esperado.

    Sem esta correção, a solução foi personalizar o mapa de aplicação para que o Skype e o MS Teams fossem classificados como Colaboração Empresarial.

  • Problema 75186 resolvido: quando a ligação ao software é configurada num VMware SASE Orchestrator ou num VMware SD-WAN Gateway, o endereço MAC da interface de ligação não é exclusivo em todo o sistema, o que pode originar conflitos de endereços MAC na rede.

    Isto só ocorrerá se os sistemas forem implementados na mesma sub-rede com a ligação de software ativada. O endereço MAC da interface de ligação de software é derivado de /etc/machine-id. Este ficheiro não é aleatorizado durante a implementação nas versões do Orchestrator e do Gateway anteriores à versão 4.2.1.

    Um cliente que utilize a ligação de software num Orchestrator ou Gateway com sistemas implementados na mesma sub-rede a partir de uma imagem de software anterior à 4.2.1 deve contactar o suporte VMware para a resolução.

  • Problema 75578 resolvido: ao executar o “Estado da interface” (Interface Status) do Diagnóstico remoto, a saída não apresenta a velocidade nem o modo da interface com a Alta disponibilidade ativada.

    O estado da interface do Diagnóstico remoto (Remote Diagnostics) não apresenta a velocidade nem o modo da interface com HA ativada. A interface HA, que liga os dois Edges, é geralmente GE1 na maioria das plataformas Edge.

  • Problema 75827 resolvido: Um VMware SD-WAN Gateway pode encontrar uma falha do Serviço dataplane e, como resultado, reiniciar.

    Nos registos, um utilizador observaria uma falha do processo de Gateway com de2e_info_reply_msg_recieved. A causa principal é uma exceção do apontador NULL que não é manuseada no processo de Gateway que aciona uma exceção e causa a falha de serviço e o reinício.

  • Problema 75890 resolvido: o endereço IP de retorno de um Edge Spoke do VMware SD-WAN aparece como acessível durante cerca de 2 minutos num Hub Edge regional através de um Hub Edge do centro de dados, mesmo que não haja nenhum caminho entre esses Hub Edges e o Edge Spoke.

    Os caminhos permanecem verdadeiros durante 2 minutos e, finalmente, são limpos após esse período como parte da limpeza de caminhos inacessíveis pelos pares. Isto só acontece com o endereço IP de retorno e todos os outros endereços IP do Spoke Edge estão devidamente marcados como Falsos neste cenário.

  • Problema 75989 resolvido: o agente Telegraf do VMware SD-WAN Gateway pode falhar ao exportar métricas recolhidas a partir de vcg_metrics.sh.

    Os registos Telegraf do Gateway mostram o erro vcgCommand timeout, o que significa que não foi possível executar o script dentro do prazo especificado.

  • Problema 75992 resolvido: no caso de uma empresa de um cliente com vários VMware SD-WAN Edges, em que alguns Edges estão a executar uma versão 3.4.x do Edge e outros estão a executar uma versão 4.3.x do Edge, o cliente pode observar interrupções no serviço e no tráfego.

    Em algumas implementações de clientes com o VMware SD-WAN Gateway com a versão 4.3.0 do Gateway e Edges com uma combinação das versões 3.4.x e 4.3.x, o Edge com a versão 3.4.x foi visto com alguns caminhos inválidos que têm um endereço de rede diferente de zero, mas uma máscara de zero. Quando esse caminho é instalado na FIB, ocorrerá o problema de encaminhamento.

  • Problema 76140 resolvido: um VMware SD-WAN Edge que está ligado tanto a um Destino Não-SD-WAN (NSD) como a um Gateway de parceiro pode sofrer uma falha do Serviço dataplane e reiniciar para recuperar o serviço, o que causa uma breve interrupção do tráfego do cliente.

    Nas topologias da empresa de cliente onde os caminhos para um prefixo podem vir tanto do NSD como do Gateway de parceiro, existe a possibilidade de um problema de tempo entre o NSD e o Gateway de parceiro e de desencadear uma exceção que faz com que o serviço Edge falhe e reinicie.

  • Problema 76165 resolvido: um VMware SD-WAN Edge pode encontrar uma falha do Serviço dataplane e, como resultado, ser reiniciado.

    Quando um Edge faz parte de uma empresa com um grande número de caminhos (por exemplo, cerca de 20 mil caminhos), se for recolhido um pacote de diagnóstico, a CPU do Edge poderá ficar suprimida durante o processo de geração de registos e registar um reinício de falha de serviço por causa da supressão da CPU.

  • Problema 76173 resolvido: para um cliente que utiliza Edges virtuais do VMware SD-WAN baseados em AWS, quando o Edge virtual é reiniciado, podem faltar caminhos ligados, o que afeta o tráfego do cliente.

    Os caminhos não são apresentados no FIB do Edge (base de informações de encaminhamento) e isso irá afetar significativamente o tráfego do cliente. Isto é provocado por um problema de tempo: quando um Edge baseado em AWS é reiniciado e aparece, as mensagens netlink surgem antes de as interfaces ficarem disponíveis para todos os caminhos ligados, o que faz com que os caminhos ligados estejam em falta.

  • Problema 76196 resolvido: uma ligação WAN num VMware SD-WAN Edge pode apresentar um valor de capacidade de largura de banda incorreto na IU do Orchestrator e o cliente pode observar que a ligação WAN não está a ser utilizada na capacidade de largura de banda real.

    As medições da largura de banda da ligação WAN têm dois principais comportamentos predefinidos relacionados com este problema. Em primeiro lugar, se o resultado de um teste da largura de banda da ligação WAN for inferior a 90% do valor atual da largura de banda, o Edge aciona automaticamente um segundo teste para garantir que a medição não se trata de uma anomalia, mas é, de facto, o novo valor mais baixo. Em segundo lugar, quando um teste da largura de banda da ligação WAN falha (o teste não é concluído devido a algum tipo de instabilidade da ligação), é reagendado um teste da largura de banda para um momento posterior, quando a instabilidade da ligação tiver sido eliminada.

    O problema aqui é que, se o teste da largura de banda falhar e for reagendado um novo teste para mais tarde e esse teste devolver um resultado inferior a 90% do valor atual, o Edge NÃO aciona um novo teste para garantir a validade deste novo valor mais baixo. O resultado é um valor de ligação WAN potencialmente mais baixo que não representa a capacidade real da ligação, o que causa problemas de tráfego ao cliente porque o serviço SD-WAN irá tratar a ligação como tendo menos capacidade do que realmente tem.

  • Problema 76315 resolvido: um utilizador operador pode observar um VMware SD-WAN Gateway a eliminar os primeiros pacotes de cada fluxo que o Gateway envia.

    A razão da eliminação será listada como gwrouting_vpn_unreachable. O problema é o resultado de um atraso de processamento das mensagens de sincronização QoS (Qualidade de serviço) do protocolo de gestão, o que faz com que os primeiros pacotes de cada fluxo sejam classificados e eliminados incorretamente.

  • Problema 76586 resolvido: os clientes com a topologia Hub/Spoke podem observar que o Edge Spoke do VMware SD-WAN muda de “Direto” para “Gateway” depois de receber respostas do Hub Edge para interfaces com overlay WAN ativado e faz com que o fluxo seja interrompido, com a interrupção resultante no tráfego do cliente desse fluxo.

    Este é um cenário em que a intenção do cliente é encaminhar fluxos de forma assimétrica através de underlay (MPLS sem overlay WAN) no caminho de encaminhamento através de uma Política empresarial de ligação fixa e através do overlay (Hub Edge) no caminho inverso, o que leva à interrupção do fluxo.

    O motivo desta interrupção do fluxo prende-se com o facto de que, quando os caminhos finais remotos respondem através de um Hub Edge (overlay), o Edge remoto encara esse fluxo como sendo um fluxo novo e iniciado localmente e envia um pedido de sincronização QoS para atualizar os parâmetros de encaminhamento do fluxo, o que leva à interrupção desse encaminhamento. O pedido de sincronização QoS é rejeitado para evitar que o modo de ligação configurado seja substituído.

  • Problema 76589 resolvido: um cluster Edge VMware SD-WAN pode não realizar um reequilíbrio do Spoke Edge após uma falha do lado da LAN.

    Um cluster de Hub pode não realizar um reequilíbrio do Spoke Edge após uma falha do lado da LAN com a vizinhança BGP IPv4 ou IPv6 no cluster de Hub porque o Hub obtém dados incorretos sobre Spoke Edges para todos os outros clusters de Hub.

  • Problema 76661 resolvido: para um site implementado com uma topologia de alta disponibilidade, os Edges HA VMware SD-WAN podem entrar num estado Ativo/Ativo e perder o contacto com o Orchestrator, e o site pode ser marcado como inativo.

    Este problema é o resultado de o caminho predefinido para o Orchestrator ser eliminado para ambas as interfaces de overlay WAN do Edge HA, o que faz com que ambos os Edges tenham uma falha de reverse path forwarding (RPF) no caminho de origem. Isto leva o Orchestrator a marcar o site como inativo, uma vez que nenhum tráfego de gestão está a alcançá-lo a partir dos Edges, e também leva ambos os Edges HA a pensar que o outro Edge está inativo, causando o estado Ativo/Ativo.

    A única forma de corrigir este problema na ausência de uma correção nos Edges é reiniciar ambos os Edges para restaurar o caminho predefinido para o Orchestrator.

  • Problema 76690 resolvido: um utilizador pode constatar que faltam registos importantes ao tentar resolver problemas de um VMware SD-WAN Edge porque o espaço foi ocupado por entradas repetidas de um evento de menor importância.

    Num pacote de diagnóstico, velocloud/log pode ter registos repetidos do evento vc_peer_qos_update_cos_qlimits. O nível de registo deste evento é o plano de gestão e o mesmo pode ser registado repetidamente até ao ponto de o registo ser excedido e substituir outras entradas. Num cenário de resolução de problemas, isto pode resultar em mensagens de registo importantes em falta, dado que foram substituídas e eliminadas.

  • Problema 76864 resolvido: um VMware SD-WAN Edge pode deixar de passar o tráfego com um evento do Edge a indicar que o “serviço edged” está desativado.

    O serviço edged é o Serviço dataplane do Edge, que trata do tráfego do cliente. Neste problema, o serviço é desativado após 3 falhas consecutivas durante uma janela em que o serviço dataplane do Edge é reiniciado devido a uma alteração da configuração. Nesta janela, um processo subordinado contém uma referência a páginas enormes necessárias por um processo principal reinicializado. Quando o Edge está neste estado, o reinício/arranque do Edge é a única forma de o recuperar.

  • Problema 77357 resolvido: Um VMware SD-WAN Edge 3400 ou 3800 que é implementado no Japão pode bloquear e reiniciar espontaneamente.

    O Edge 3400 e o 3800 têm um limiar de aviso de tensão incorreto (100V) definido no Controlador de gestão de baseboard (Baseboard Management Controller) (BMC) do sistema, que por acaso corresponde à alimentação elétrica de 100 V no Japão. O resultado de um Edge 3400 ou 3800 nesta região é uma série contínua de alarmes de alimentação e se o volume de alarmes for suficientemente frequente, o Edge bloqueia e reinicia.

    Este é um seguimento do problema 51291 do Edge, que foi corrigido nas versões 3.4.5, 4.0.1, 4.2.0 e todas as versões 4.3.x. Embora a correção tenha sido bem-sucedida na resolução do problema, não foi duradoura porque os limiares de tensão definidos manualmente estavam a ser limpos por uma atualização CPLD. Fora disso, o sintoma e a descrição são os mesmos, mas a correção aqui garante que os limiares de tensão persistem em todas as atualizações subsequentes do Edge.

  • Problema 77586 resolvido: num site implementado com uma topologia de alta disponibilidade que utiliza a versão 4.2.2 GA e OSPF, o tráfego do cliente pode sofrer uma interrupção.

    O IP de HA está a ser dado pelo serviço do Edge aos protocolos de routing do VMware SD-WAN e o serviço OSPF utiliza-o no LSA (anúncio de estado de ligação). Num caso comunicado no campo, o IP de HA é escolhido como router-id OSPF quando o Edge está a executar a versão 4.2.1 e, depois de atualizar os Edges HA para 4.2.2, o router-id é alterado para outro IP da interface. No entanto, o LSA do IP de HA persiste e é anunciado, o que perturba o cálculo de SPF (o caminho mais curto primeiro) e pode levar a uma falha na rede.

    Este problema pode ser observado em qualquer plataforma e qualquer versão sem a correção e não se limita ao caso de campo anteriormente indicado.

  • Problema 77642 resolvido: o cliente pode observar um número cada vez mais elevado de handoff queue drops e quedas de pacotes que resultam na degradação do desempenho num VMware SD-WAN Edge.

    No serviço Edge, existe um thread responsável por monitorizar os fluxos assíncronos que pode tornar-se 100% utilizado e isso provocaria as handoff queue drops e a consequente degradação do desempenho.

  • Problema 77732 resolvido: Num site implementado com uma topologia de Alta disponibilidade melhorada com uma camada de transporte duplo (Internet + MPLS), o endereço IP público não é apresentado para a ligação ativa na subinterface do Edge em standby.

    Para o túnel de gestão IPv4, o IP de origem está definido como 0.0.0.0, o que é causado pela ação errada da interface HA FSM (Finite State Machine). Especificamente, quando o temporizador HA wait_for_peer expira, tenta aplicar informações de sincronização de interfaces para determinar se existem eventos IP Refresh provenientes do Edge em standby e atualiza o endereço IP mesmo que não existam alterações no IP/Próximo hop e isso leva a este problema. 

  • Problema 78050 resolvido: um VMware SD-WAN Edge pode sofrer uma falha do Serviço dataplane quando um servidor PPTP estiver presente no lado da LAN.

    Quando um servidor PPTP está presente no lado da LAN e um cliente PPTP da Internet se liga ao mesmo através de uma regra da firewall de entrada, o serviço do Edge pode falhar devido a uma falha de pesquisa do canal de controlo PPTP. Esta pesquisa do canal de controlo é necessária para garantir que o canal de dados GRE é enviado através da mesma ligação para um cliente PPTP.

    Num Edge com uma compilação sem uma correção para este problema, a única alternativa de um cliente é não utilizar sessões PPTP.

  • Problema 78212 resolvido: o comando de depuração do resumo do caminho “debug.py --rsummary” num VMware SD-WAN Gateway pode apresentar uma contagem de caminhos BGP imprecisa.

    Quando a VPN Ramo a Ramo é desativada para uma empresa de cliente, os caminhos BGP dos VMware SD-WAN Edges são retirados do Gateway. No entanto, o Gateway continua a apresentar uma contagem de caminhos BGP no comando de depuração debug.py --rsummary que inclui os caminhos removidos da tabela de caminhos.

  • Problema 76690 resolvido: um utilizador pode constatar que faltam registos importantes ao tentar resolver problemas de um VMware SD-WAN Edge porque o espaço foi ocupado por entradas repetidas de um evento de menor importância.

    Num pacote de diagnóstico, velocloud/log pode ter registos repetidos do eventovc_peer_qos_update_cos_qlimits. O nível de registo deste evento é o plano de gestão e o mesmo pode ser registado repetidamente até ao ponto de o registo ser excedido e substituir outras entradas. Num cenário de resolução de problemas, isto pode resultar em mensagens de registo importantes em falta, dado que foram substituídas e eliminadas.

  • Problema 78300 resolvido: Se um VMware SD-WAN Edge estiver a utilizar uma ligação WAN configurada como de backup, um utilizador pode observar registos ou Eventos do Orchestrator que sugerem que os túneis estão a ficar ativos ou inativos para esta ligação.

    Propositadamente, os túneis não são estabelecidos para ligações de backup. Mas qualquer pedido de túnel a partir de uma extremidade remota (normalmente um túnel dinâmico Edge-to-Edge) pode alterar o estado da ligação à medida que passa pela pilha. Nesta correção, foram tomados cuidados para que nenhum registo indique que qualquer formação de túnel ou remoção está a acontecer para a ligação de backup.

  • Problema 78391 resolvido: o tráfego com a classificação da aplicação Speedtest não está a funcionar corretamente.

    Tanto speedtest.net como fast.com têm novos endereços IP de servidor de speedtest que estão em falta no mapa de aplicação predefinido e, consequentemente, a política empresarial que lida com estas aplicações não é aplicada.

    Se não for atualizado para a versão 4.5.1 ou 5.0.1, o operador poderá adicionar os IPs de speedtest necessários a um mapa de aplicação existente com o Editor de mapa de aplicação do VMware SASE Orchestrator (VMware SASE Orchestrator's Application Map Editor).

  • Problema 78637 resolvido: um VMware SD-WAN Gateway pode registar uma falha no Serviço dataplane com uma mensagem SIGXCPU e um reinício de serviço resultante.

    O Gateway também gerará um núcleo. O problema tem origem no momento em que o Gateway recebe um pacote com o comprimento de TLV opcional de 0. O Gateway acaba por entrar num ciclo infinito, que resulta no SIGXCPU e no reinício de serviço e no núcleo.

  • Problema 79261 resolvido: o tráfego de aplicações do Office 365/Microsoft 365 é incorretamente classificado como tráfego de aplicações Tencent Meeting (VooV Meeting) no VMware SD-WAN Edge.

    Este problema pode ser disruptivo para os clientes que dependem de políticas empresariais ou de firewall para o routing e a definição de prioridades do tráfego do Office 365/Microsoft 365, pois esse tráfego é classificado como sendo do Tencent Meeting, sendo regido por uma regra completamente diferente. O problema tem origem em sub-redes de mapa de aplicação incorretas para o Tencent e que estão corrigidas no mapa de aplicação predefinido da versão 4.3.2. É possível corrigir este problema para um cliente que não utilize a versão 4.3.2 através de um operador que edite o mapa de aplicação através do Editor de mapa de aplicação do Orchestrator para corrigir as sub-redes do Tencent.

  • Problema 79437 resolvido: a implementação de um VMware SD-WAN Gateway implementado num servidor com uma NIC Intel X710 com SR-IOV ativado para as interfaces pode falhar.

    Se esta falha ocorrer, o operador verá as interfaces X710 SR-IOV removidas do DPDK, que não serão vistas ao executar debug.py --dpdk_ports_d. Além disso, /opt/vc/etc/dpdk.json não apresentará as interfaces SR-IOV. A implementação de um Gateway para a versão 4.3.2 garante que este problema não ocorre.

  • Problema 80028 resolvido: num site implementado com uma topologia de alta disponibilidade, o Edge em standby pode sofrer uma falha do Serviço dataplane e, como resultado, reiniciar.

    Este problema ocorre apenas no Edge em standby e nunca no Edge ativo. O problema é causado por uma condição de corrida quando o motor de Inspeção profunda de pacotes invocou uma limpeza enquanto ainda há pacotes a serem processados no pipeline e pode acontecer a qualquer momento.

    Não há qualquer impacto para um cliente que utilize uma configuração HA padrão, uma vez que o Edge em standby não passa o tráfego, mas numa implementação de HA melhorada, onde o Edge em standby também está a passar tráfego, o reinício do serviço Edge em standby interromperia brevemente o tráfego do cliente que passa pelo standby durante, aproximadamente, 15 segundos. 

  • Problema 80068 resolvido: um VMware SD-WAN Edge pode encontrar uma falha do Serviço dataplane e reiniciar para recuperar, o que causa uma interrupção do tráfego do cliente de 10-15 segundos.

    O problema pode ocorrer em empresas de clientes que utilizam BGP onde um caminho de vizinho BGP é bloqueado quando deve ser libertado e desencadeia uma exceção no serviço Edge.

  • Problema 80479 resolvido: um VMware SD-WAN Gateway pode registar uma falha no Serviço dataplane e o Gateway reinicia o serviço para recuperar, com um impacto de cerca de 15 a 30 segundos no respetivo tráfego.

    Este problema poderá ocorrer se um VMware SD-WAN Edge estiver ligado ao Gateway com Edge-a-Edge (E2E) ativado e um caminho de interface de retorno anunciado. Quando um utilizador desativa o E2E nesse Edge, é acionado um início de caminho, mas o caminho de retorno não é eliminado e o caminho atualiza a respetiva flag de perfil. Em seguida, se o utilizador remover o anúncio do caminho de retorno, o caminho do FIB será eliminado, mas permanecerá inativo na tabela E2E no Gateway. Se o caminho de retorno for de novo anunciado e adicionado ao FIB e, posteriormente, o E2E for ativado, o que, mais uma vez, apenas atualizará o sinalizar, apesar de o caminho estar presente na tabela E2E do Gateway (que está inativa), a ref_count do caminho real não será correta. Finalmente, se o túnel for removido, ocorrerá uma falha do Serviço de dataplane no Gateway.

    Sem a correção, um operador terá de se certificar de que os caminhos são removidos antes de um perfil ser alterado para o Edge.

  • Problema 80496 resolvido: o envio de um ping de um VMware SD-WAN Edge para um endereço IP de retorno de ramo do Edge remoto através de um túnel do SD-WAN pode não funcionar.

    O problema ocorre em pings com tamanhos de pacotes suficientemente grandes para provocar fragmentações. Quando o ping é iniciado com um tamanho de pacote grande de um Edge para o endereço IP de retorno de um ramo remoto do Edge, a resposta fragmentada do ICMP consegue aceder ao Edge que inicia o ping, mas não consegue aceder à aplicação de ping, pois o fragmento seguinte é removido.

  • Problema 80814 resolvido: num VMware SD-WAN Edge em que a regra de permissão da firewall padrão está configurada, que possui um endereço IP de origem de cliente Edge local e um cliente remoto como endereço IP de destino e que também possui a regra “Recusar tudo” (Deny All) para outro tráfego, o tráfego do cliente remoto para o cliente local é ignorado.

    Este problema é encontrado quando existe uma incompatibilidade do endereço IP da VLAN entre os anfitriões de origem e de destino. Quando os anfitriões de origem e de destino fazem parte de VLANs diferentes, o serviço SD-WAN prefere o endereço IP de origem/destino do primeiro pacote, dado que está na chave de pesquisa da firewall. Como resultado, existe uma incompatibilidade dos fluxos de entrada de overlay e o tráfego atinge a regra da firewall Recusar tudo (Deny All).

    Sem a correção, a solução alternativa para este problema consiste em reverter a regra na direção do primeiro pacote IP do fluxo, para que o pacote consiga corresponder à regra da firewall.

  • Problema 81196 resolvido: o utilizador não pode iniciar sessão na IU local de um VMware SD-WAN Edge desativado com a palavra-passe predefinida de fábrica.

    Um utilizador pode “Desativar” um Edge através da IU local com Repor Definição > Repor Configuração (Reset Setting > Reset Configuration) ou, no VMware SASE Orchestrator, ao selecionar Ações Remotas > Desativar (Remote Actions > Deactivate) para o Edge. Após o utilizador “Desativar” o Edge, todas as configurações devem ser libertadas e as credenciais de início de sessão da IU local devem reverter para os valores predefinidos, mas não o fazem. As credenciais permanecem as mesmas de antes da desativação e, se um utilizador tiver alterado as credenciais predefinidas da IU locais para outro valor, esse novo valor persiste para além da desativação do Edge. Se as credenciais locais da IU nunca tivessem sido atualizadas, o utilizador não teria qualquer problema, uma vez que as credenciais antes e depois da desativação permaneceriam as predefinidas.

  • Problema 81221 resolvido: se um cliente configurar uma regra NAT 1:1 para um VMware SD-WAN Edge e esse Edge for reiniciado, a regra deixará de funcionar.

    Após o reinício, o Edge atribui o endereço NAT como o endereço da interface do Edge em que a regra NAT está a ser aplicada, pelo que não são criados túneis para o tráfego que corresponde a essa regra.

    Sem a correção, a única remediação é executar “Esvaziar NAT” do diagnóstico remoto, que esvazia toda a tabela NAT e restabelece o correto funcionamento da regra NAT.

  • Problema 81224 resolvido: Num site implementado com uma topologia de alta disponibilidade, quando ocorre no site uma recuperação automática de HA, as etiquetas de caminho OSPF podem não propagar a recuperação automática de HA posterior.

    Numa recuperação automática de HA, os LSA externos de OSPF (anúncios de estado de ligação) não têm uma etiqueta de caminho, o que leva a um routing impróprio com um efeito adverso no tráfego do cliente.

    Num site de HA onde os Edges não têm a correção para este problema, o OSPF tem de ser reiniciado nos Edges que não recebem a etiqueta de caminho correta.

  • Problema 81859 resolvido: Ao ativar um VMware SD-WAN Edge 610-LTE, a interface CELL pode não aparecer após o Edge concluir a sua ativação.

    Este problema não é consistente, mas, quando ocorre, pode ter um grande impacto se a única ligação pública do Edge 610-LTE for a ligação CELL móvel, uma vez que o Edge estará efetivamente inativo e a intervenção para o mesmo terá de ser local, consistindo em desligar e ligar Edge para o recuperar.

    Num Edge sem uma correção para este problema, se encontrar este problema e o 610-LTE tiver outras ligações WAN públicas com fios, o utilizador terá de reiniciar o serviço Edge através do Orchestrator com Ações remotas > Reinício do serviço (Remote Actions > Service Restart) numa janela de manutenção adequada ou reiniciar o modem do Edge para restaurar a interface CELL.

    Se o 610-LTE utilizar apenas uma interface CELL para a Internet, alguém no local onde se encontra o Edge terá de desligar e ligar o Edge, dado que este estará inacessível através do Orchestrator.

    Se o Edge 610-LTE que está a ser ativado utilizar apenas CELL para a Internet, o Edge deve ser ativado com alguém presente para, potencialmente, o desligar e ligar caso fique inativo após a conclusão da ativação.

    Solução alternativa: se encontrar este problema e o 610-LTE tiver outras ligações WAN públicas com fios, o utilizador terá de reiniciar o serviço Edge através do Orchestrator com Ações remotas > Reinício do serviço (Remote Actions > Service Restart) numa janela de manutenção adequada ou reiniciar o modem do Edge para restaurar a interface CELL.

    Se o 610-LTE utilizar apenas uma interface CELL para a Internet, alguém no local onde se encontra o Edge terá de desligar e ligar o Edge, dado que este estará inacessível através do Orchestrator.

    Se o Edge 610-LTE que está a ser ativado utilizar apenas CELL para a Internet, o Edge deve ser ativado com alguém presente para, potencialmente, o desligar e ligar caso fique inativo após a conclusão da ativação.

  • Problema 82104 resolvido: Em casos raros, os VMware SD-WAN Edges ativados numa topologia de alta disponibilidade podem não ser capazes de comunicar com um VMware SASE Orchestrator que marcará o site como inativo e impedirá qualquer intervenção através do Orchestrator para o site.

    Este problema apenas ocorre quando uma configuração incomum e inválida é aplicada aos Edges HA. A configuração especifica que a porta HA está configurada como “ramal” (trunk) (o que não deve ser permitido), com zero VLANs (que também não deve ser permitido), mas onde “todas as VLANs” (all VLANs) estão definidas. Em vez de lançar um erro nesta configuração e impedir um utilizador de ativar a HA para os Edges, o Orchestrator permite que isso ocorra e esta configuração desencadeia uma falha do plano de gestão nos Edges HA que já não enviam um heartbeat ao Orchestrator. A correção aqui permite que esta configuração inválida funcione num par Edge HA sem interromper o tráfego de gestão para o Orchestrator.

  • Problema 82182 resolvido: para um modelo VMware SD-WAN Edge 510 ou 510-LTE, quando um utilizador tenta reiniciar o serviço do Edge, o Edge pode também reiniciar.

    Um reinício do Edge interromperia o tráfego do cliente durante 2-3 minutos durante o processo o processo de reinicialização. Num Edge 510/510-LTE, existe um script de monitorização de paragem de dispositivo Wi-Fi cuja paragem pode falhar durante o reinício do serviço do Edge, o que desencadeia a reinicialização.

    Sem a correção, um utilizador precisaria de reiniciar o serviço Edge, mas os reinícios do serviço Edge para estes modelos só deve ser efetuado numa janela de manutenção ou tendo a noção de que este problema pode ocorrer.

  • Problema 82188 resolvido: para os modelos VMware SD-WAN LTE (Edge 510-LTE, 610-LTE), quando a definição IPv6 é desativada, os túneis através da interface CELL podem falhar.

    • Quando a caixa de verificação IPv6 nas Definições do dispositivo (Device Settings) é desmarcada, o estado interno da interface CELL muda para DESCONHECIDO (UNKNOWN). Esse estado não é atualizado mesmo que a definição IPv6 seja ativada para a interface CELL. Consequentemente, os túneis através da interface CELL falharão. Se o LTE Edge estiver a utilizar apenas interfaces CELL para o tráfego, o Edge ficará offline e removerá todo o tráfego do Edge, o que seria muito disruptivo para o cliente.

      Sem a correção, um utilizador teria de reiniciar o serviço Edge depois de desativar a definição IPv6. Se o Edge estiver offline porque utiliza apenas a interface CELL para a largura de banda, os utilizadores locais terão de encerrar e voltar a ligar o Edge para o recuperar.

  • Problema 82432 resolvido: um VMware SD-WAN Edge pode encontrar uma falha do Serviço dataplane e reiniciar para recuperar, o que causa uma interrupção de 10-15 segundos do tráfego do cliente.

    O serviço do Edge pode falhar ao processar um número consistentemente elevado de pacotes fragmentados (por exemplo, como observado no tráfego RADIUS). Estes pacotes fragmentados podem exceder a memória atribuída para processar pacotes fragmentados e desencadear uma exceção no serviço Edge.

  • Problema 82485 resolvido: num modelo VMware SD-WAN Edge de nível básico (por exemplo, Edge 510, 510-LTE ou 610), se um utilizador executar o diagnóstico remoto “Esvaziar tabela de caminhos” (Route Table Dump), a página da IU do Orchestrator pode exceder o tempo limite e não devolver um resultado.

    O problema é encontrado se existirem mais de 16 000 caminhos, dado que o Edge demora mais de 30 segundos a devolver os resultados. 30 segundos é o tempo limite do WebSocket da página e, portanto, nenhum resultado é devolvido. A correção deste problema otimiza o percurso da tabela de caminhos, para garantir que os tempos limites não são excedidos.

  • Problema 83040 resolvido: uma empresa de cliente com uma topologia Hub/Spoke que utiliza um Gateway de parceiro como um Destino Não-SD-WAN (NSD) pode observar tráfego que deveria utilizar um NSD e, em vez disso, utiliza um Hub.

    O Spoke Edge teria uma política empresarial que faz o backhaul do tráfego para o NSD e, se também estiver configurado um handoff do Gateway de parceiro para o mesmo, o Spoke envia tráfego que deveria utilizar um NSD para o Hub Edge. O Hub, por sua vez, envia o tráfego diretamente para a Internet. Se o handoff do Gateway de parceiro estiver desativado, este tráfego do NSD é encaminhado corretamente.

  • Problema 83411 resolvido: quando a alta disponibilidade é ativada com um VMware SD-WAN Edge recentemente ativado, o par Edge HA pode ficar offline.

    Quando a HA é ativada, todos os endereços MAC da interface Edge são alterados para endereços MAC virtuais e, durante o estado de emissão, a configuração DPDK não é atualizada com estes endereços VMAC. Como resultado, os pacotes de heartbeat destinados ao Orchestrator são ignorados devido a uma incompatibilidade do MAC de destino e o Orchestrator assinala o par Edge HA como inativo.

  • Problema 83432 resolvido: num site implementado com uma topologia de alta disponibilidade, quando são adicionados outros túneis ao site, o Edge em standby do VMware SD-WAN pode sofrer uma falha do Serviço dataplane e gerar um núcleo.

    Uma forma comum de adicionar túneis consiste em adicionar ligações WAN aos Edges HA. Quando o número de túneis que o Edge em standby precisa de sincronizar com o Edge ativo ultrapassa os 80, isto aciona uma exceção e uma falha do Serviço dataplane no Edge em standby. Quando este problema é encontrado numa topologia HA convencional, o impacto no cliente deverá ser mínimo, dado que o Edge em standby não está a passar o tráfego do cliente. Numa implementação HA melhorada, onde o Edge em standby também está a passar tráfego, os reinícios perturbarão algum tráfego do cliente. 

  • Problema 83611 resolvido: o cliente pode observar um número invulgarmente elevado de eventos EDGE_NEW_DEVICE a partir de um VMware SD-WAN Hub Edge na IU do VMware SASE Orchestrator.

    Este problema pode ser encontrado com a seguinte topologia: Dispositivo cliente > Spoke Edge – Hub Edge --Servidor DHCP. Com esta topologia, sempre que um utilizador cliente que utiliza um Edge Spoke envia um pacote DHCP, o Edge Spoke aciona corretamente um evento Edge_New_Device para este dispositivo do cliente. No entanto, quando o Hub Edge recebe o pacote de reencaminhamento DHCP, o Hub Edge aciona novamente um evento Edge_New_Device para o Orchestrator e este evento está incorreto.

  • Problema 83946 resolvido: Os clientes do lado da LAN do VMware SD-WAN Edge podem observar perturbações no tráfego e, para um site que utilize a autenticação RADIUS, os utilizadores do cliente podem observar falhas de autenticação.

    Os pacotes grandes serão fragmentados e estes pacotes fragmentados podem ser removidos pelo Edge. Os pacotes podem ser removidos devido a uma fuga de memória durante a tradução da identificação do IP do fragmento durante alguns cenários de erro e, se o limite do Edge para os pacotes fragmentados for excedido, este poderá remover ainda mais pacotes fragmentados.

    Para os clientes que utilizam o RADIUS em situações em que estão envolvidos pacotes grandes de um cliente sem fios para um Edge que utiliza a autenticação RADIUS, isto pode causar falhas de autenticação. Por exemplo, os pacotes grandes de um controlador LAN sem fios (WLC) para um servidor RADIUS podem ser removidos.

  • Problema 84439 resolvido: uma flag segura (também conhecida como flag “S”) pode estar em falta para um caminho do Gateway de parceiro no VMware SD-WAN Edge.

    Ter o mesmo caminho de sub-rede configurado a partir da página do Gateway de parceiro e também na página de handoff do Gateway de parceiro pode levar a um anúncio inconsistente de caminhos para o Edge. Por exemplo, o anúncio de um caminho não preferencial e não seguro quando está disponível um caminho estático seguro.

  • Problema 84501 resolvido: para uma empresa de cliente que utiliza a autenticação 802.1x (por exemplo, RADIUS, Cisco ISE), quando os VMware SD-WAN Edges são atualizados para a versão 4.3.1 ou posterior, os dispositivos do cliente ligados ao Edge podem falhar a autenticação no servidor de acesso à rede (NAS) que está alojado na WAN.

    O endereço IP do NAS é definido, por predefinição, como um endereço IP de retorno nos pacotes RADIUS ou ISE enviados do Edge (autenticador) para o servidor ISE ou RADIUS e isto pode fazer com que os pacotes de autenticação não cheguem ao NAS, causando a falha de autenticação.

    Para remediar o problema, as compilações com esta correção definem o endereço IP do NAS como o endereço IP da interface de origem selecionado e configurado com as definições de autenticação 802.1x. Se “Automático” (Auto) for selecionado como a interface de origem, o IP de retorno será definido como o endereço IP do NAS por predefinição.

  • Problema 84741 resolvido: um utilizador observa estatísticas de débito imprecisas nos ecrãs de Monitorizar > Transporte (Monitor > Transport).

    Os pacotes RX (entrada) e as estatísticas de ligação não são incrementados para o Orchestrator para o tráfego que é enviado diretamente numa interface onde o Reverse Path Forwarding (RPF) está desativado no overlay WAN.

  • Problema 84790 resolvido: quando um VMware SD-WAN Edge é reiniciado, o Edge comunica erradamente o evento crítico “Não é possível lançar o serviço wifihang” (Unable to launch service wifihang) ao VMware SASE Orchestrator.

    Este erro pode induzir um cliente a pensar que algo está errado com o Wi-Fi do Edge quando o processo está a funcionar corretamente. Os modelos Edge onde isto não ocorre são as linhas de modelos Edge 510 e Edge 6x0. Todos os outros modelos estão sujeitos a este problema.

  • Problema 84825 resolvido: Num site implementado com uma topologia de alta disponibilidade onde o BGP está configurado, se o site tiver configuradas mais de 512 regras BGPv4 correspondência/definição, o cliente poderá observar o par Edge HA a falhar continuamente sem nunca recuperar.

    Mais de 512 regras BGPv4 de correspondência e definição são compreendidas como o cliente configurar mais de 256 regras no filtro de entrada e 256 regras no filtro de saída. Este problema seria disruptivo para o cliente, dado que a recuperação automática repetida causaria fluxos de tráfego em tempo real, por exemplo, chamadas de voz que falham continuamente e, em seguida, são recriadas. Quando os Edges HA registam este problema, o processo que sincroniza os threads da CPU do Edge falha, fazendo com que o Edge reinicie para recuperar, mas o Edge promovido também regista o mesmo problema e reinicia por sua vez sem que nenhuma recuperação chegue ao site.

    Sem uma correção para este problema, o cliente deve garantir que não estão configuradas mais de 512 regras BGPv4 de correspondência e definição para um site de HA.

    Se um site estiver a registar este problema e tiver configuradas mais de 512 regras BGP/v4 de correspondência e definição, o cliente deverá reduzir imediatamente o número de regras para 512 ou menos para recuperar o site.

    Em alternativa, se o cliente tiver configuradas mais de 512 regras BGPv4 de correspondência e definição, poderá mudar para a versão 3.4.6 dos Edges HA, onde este problema não é encontrado, mas perderá as funcionalidades do Edge presentes nas versões posteriores. Esta mudança só poderá ser realizada se o modelo Edge for suportado na 3.4.6. O cliente deverá confirmar isso antes de mudar para uma versão anterior.

  • Problema 84828 resolvido: um VMware SD-WAN Edge pode encontrar uma falha do Serviço dataplane e reiniciar para recuperar, o que causa uma interrupção do tráfego do cliente de 10-15 segundos.

    O Edge geraria um núcleo com o evento SIGXCPU. O problema é causado por um Edge que excede o valor de tempo limite para executar um comando, o que leva o monitor mutex a concluir que existe um thread bloqueado e a desencadear o núcleo e o reinício. Mesmo que um engenheiro de suporte da VMware possa aumentar o valor de tempo limite para o monitor mutex, o serviço Edge não está a respeitar o valor aumentado.

  • Problema 85154 resolvido: quando um Edge virtual do VMware SD-WAN no AWS com o tipo de instância C4.xlarge é atualizado de uma versão do Edge mais antiga para uma versão mais recente (incluindo a versão 4.3.1) e, depois, a versão é mudada novamente para uma versão mais antiga do Edge, este entra no estado desativado no qual não forma túneis de gestão com o Gateway e o Orchestrator.

    O motivo do problema está no facto de o Orchestrator desativar incorretamente o Edge, o que faz com que Orchestrator detete como erro de correspondência o número de série.

    Não existe uma solução alternativa para este problema para além de NÃO mudar para uma versão anterior à versão mais recente do Edge quando o Edge AWS estiver nesta versão.

  • Problema 85461 resolvido: Se um VMware SD-WAN Edge for utilizado para encaminhar o DNS e os dispositivos LAN ligados ao Edge estiverem a utilizar o Edge para o routing do DNS, todo o tráfego do DNS pode falhar.

    Todo o tráfego de routing do DNS é afetado e não apenas o DNS condicional. Consoante o software do Edge, este problema pode ser encontrado num Edge da seguinte forma:

    • Se o Edge estiver a utilizar a versão 4.2.2, o Edge poderá deparar-se com este problema se o Edge estiver a utilizar portas LAN encaminhadas sem um endereço IP especificado. As portas LAN comutadas + VLANs não são afetadas na versão 4.2.2. 

    • Se o Edge estiver a utilizar a versão 4.3.0/4.3.1, 4.5.0/4.5.1 ou 5.0.0.x, o Edge poderá deparar-se com o problema se o Edge estiver a utilizar portas LAN comutadas e VLANs ou se o Edge estiver a utilizar portas LAN encaminhadas sem um endereço IP especificado.

    Para interfaces comutadas, a causa do problema decorre da depreciação e remoção da interface do IP de gestão para dar lugar a uma interface de retorno nas versões 4.3.x, 4.5.x, 5.0.0.x e posteriores. Como o DNS utiliza o NAT do segmento, o pacote DNS não tem qualquer entrada correspondente para o IP de destino quando o Edge faz uma procura na tabela do NAT do segmento e o Edge ignora o pacote.

    Para interfaces encaminhadas, a falta de um IP do Gateway significa que o pacote DNS é encaminhado para o Edge como o próximo hop e o Edge não prossegue com o routing do pacote DNS.

    Quando um Edge utiliza uma compilação sem uma correção para este problema, a solução alternativa é não utilizar o Edge para encaminhar o DNS ou, quando utilizar a versão 4.3.x ou 4.5.x, utilizar apenas portas LAN encaminhadas com um endereço IP do Gateway especificado. 

  • Problema 85679 resolvido: não é possível fazer a depuração remota de um VMware SD-WAN Edge com uma ferramenta GDB.

    Em alguns cenários de suporte, um engenheiro de suporte técnico da VMware pode trabalhar com um cliente para resolver remotamente problemas de um Edge através de uma sessão SSH. Uma ferramenta que um engenheiro pode utilizar é um Depurador de Projetos GNU (GDB). Neste problema, a utilização da ferramenta GDB termina a sessão SSH, limitando assim a capacidade da engenharia de resolver problemas de um Edge em direto.

  • Problema 85752 resolvido: um VMware SD-WAN Edge que utiliza um Gateway de parceiro pode receber duas vezes o mesmo caminho estático do prefixo do Gateway de parceiro.

    O Edge deve receber apenas um caminho a partir de um Gateway a qualquer momento. Este problema ocorre quando o mesmo caminho de prefixo é configurado na página Gateway como NAT e na página Handoff de Gateway como LAN identificada.

  • Problema 85892 resolvido: a ferramenta de métricas Wavefront comunica métricas inconsistentes para pontos finais do Destino Não-SD-WAN (NSD) se os pontos finais do NSD tiverem a redundância ativada.

    Ao ligar-se a um ponto final do NSD com a redundância ativada, o serviço VMware SD-WAN Gateway acaba por criar contadores internos com o mesmo nome para ambos os pontos finais (principal e secundário). Isto leva a comunicações inconsistentes na Wavefront.

  • Problema 86098 resolvido: Num site que utiliza uma topologia de alta disponibilidade melhorada onde é utilizada uma ligação PPPoE WAN no Edge em Standby, um utilizador pode observar que o caminho de proxy predefinida não está instalado no Edge Ativo e o tráfego que usa essa ligação falha.

    Quando um par Edge HA melhorado surge, a ligação PPPoE sincroniza-se com o Edge em standby e fornece um caminho predefinido com um hop seguinte de 0.0.0.0. Como resultado, este caminho não é instalado no Edge ativo e o tráfego que utiliza esta ligação é ignorado.

  • Problema 86314 resolvido: um VMware SD-WAN Edge pode efetuar uma pesquisa incorreta de regras de firewall com estado quando o fluxo NAT do lado da LAN é iniciado por um par remoto.

    Quando um utilizador configura uma NAT de origem do lado da LAN (por exemplo, para ocultar uma sub-rede IP interna por trás do Edge) num Edge no qual a Firewall com estado é utilizada, e um par remoto iniciar um fluxo, é efetuada uma pesquisa de firewall errada para o primeiro pacote de retorno.

    Por exemplo, suponha que um Edge tem a seguinte configuração:

    NAT do lado da LAN: [origem] endereço interno: 10.0.2.25/32 endereço externo: 7.0.2.25/32 caminho estático: 7.0.2.25/32 [anunciar] próximo hop: 10.0.2.1

    Um cliente remoto a enviar um ping para 7.0.2.25 a partir de 10.0.1.25 resultará em duas pesquisas de regras de firewall no Edge. O primeiro pacote de entrada resultará numa pesquisa de firewall para 10.0.1.25 > 7.0.2.25 e, depois, o primeiro pacote de retorno resultará numa pesquisa de regras de firewall ao utilizar o IP não NAT para 10.0.2.25 > 10.0.1.25. Esta segunda pesquisa de regras de firewall é feita por engano.

    Sem esta correção, o utilizador teria de criar uma regra de firewall adicional para permitir o primeiro pacote de retorno do fluxo.

  • Problema 86719 resolvido: quando um VMware SD-WAN Edge é atualizado da versão 3.4.x para 4.3.1, as sessões OSPF do Edge podem não surgir e o Edge não receberá caminhos.

    As vizinhanças OSPF podem estar inativas depois de o Edge ser atualizado devido a uma incompatibilidade do formato de área OSPF entre o Orchestrator e o Edge.

  • Problema 86808 resolvido: Alguns caminhos BGP são anunciados quando não o devem ser, de acordo com os filtros do BGP (ou não são anunciados quando deveriam ser).

    Para uma determinada regra do mapa de caminhos, o Edge pode ter uma configuração de lista de prefixos ou de lista da comunidade para o encaminhamento do Edge com base no tipo de correspondência da regra. No entanto, para funções de anulação de aplicação do mapa de caminhos, o Edge está a tentar eliminar tanto a lista de prefixos como a lista da comunidade para cada regra, uma das quais tem de ser inexistente.

    Anteriormente, esta situação não causava problemas, uma vez que os comandos para as listas de prefixos e/ou listas da comunidade inexistentes costumavam ser enviados para o processo de encaminhamento do Edge como um comando vtysh separado, que acabaria simplesmente por não ter operações e não afetaria os outros comandos. Nessa altura, esta foi uma decisão deliberada, uma vez que mantinha as coisas simples nas funções de anulação de aplicação do mapa de caminhos.

    No entanto, como parte da correção do problema 84825, o Edge começou a criar lotes de vários comandos vtysh de remoção de listas de prefixos/listas da comunidade para serem enviados para o processo de encaminhamento do Edge. Agora, ao tentar eliminar a lista de prefixos/lista da comunidade inexistente faz com que todo o lote de comandos falhe e encha o Edge com configurações obsoletas de listas de prefixos/listas da comunidade no processo de encaminhamento do Edge.

    Num Edge sem uma correção para este problema, um utilizador precisa de reiniciar o serviço Edge para garantir que todos os caminhos BGP são corretamente anunciados.

  • Problema 86885 resolvido: quando um site é implementado com uma topologia de alta disponibilidade, e os Edges HA são movidos de um perfil para um perfil diferente, o Edge HA ativo não faz uma recuperação automática para concluir a migração para um perfil diferente, o que pode levar a uma interrupção do tráfego do cliente.

    A expectativa é que, após atribuir um Edge HA a um perfil diferente, deve acontecer uma recuperação automática, o que altera o Edge ativo antes de concluir a atribuição. Desta forma, cada Edge aplica a configuração e reinicia o respetivo serviço de forma sequencial para garantir que não há interrupções do tráfego do cliente. O problema ocorre porque, durante uma mudança de migração de perfil, os heartbeats são suprimidos do Edge ativo, o que faz com que ambos os Edges apliquem a configuração ao mesmo tempo e reiniciem separadamente e, portanto, sem recuperação automática.

  • Problema 87205 resolvido: para um cliente que implementa um VMware SD-WAN Edge com um Gateway de parceiro, quando um Edge aprende novos caminhos a partir do Gateway de parceiro, o tráfego do cliente pode ser interrompido.

    Este problema é causado porque o tráfego é associado à política empresarial errada. Por exemplo, o tráfego DHCP destinado ao Gateway de parceiro poderia, em vez disso, ser associado à regra de Backhaul da Internet com uma consequente interrupção do tráfego do cliente.

    Sem a correção, o problema é remediado através do esvaziamento dos fluxos do Edge utilizando o Diagnóstico remoto “Esvaziar fluxos” (Flush Flows). Esta remediação não impede futuras ocorrências potenciais quando o Edge aprende novos caminhos para o Gateway de parceiro.

  • Problema 87304 resolvido: Se um utilizador desativar uma interface LAN num VMware SD-WAN Edge com a IU do VMware SASE Orchestrator, a interface continuará a ser comunicada como “Ativa” (UP) pelo SNMP.

    o processo de depuração principal para a saída das interfaces não inclui os detalhes da porta física para interfaces LAN do Edge (por exemplo, GE1 ou GE2). Como resultado, quando o SNMP sonda essas interfaces, devolve sempre um resultado de UP, independentemente da configuração das interfaces.

  • Problema 87552 resolvido: num site que utilize um Destino Não-SD-WAN (NSD) via Edge, o Serviço dataplane do VMware SD-WAN Edge pode sofrer periodicamente uma falha e reiniciar quando os túneis Edge para NSD estiverem instáveis.

    Quando um túnel Edge para NSD fica inativo, é executada a versão incorreta de um túnel anteriormente escolhido, o que desencadeia uma exceção no Serviço dataplane do Edge e é necessário um reinício para restaurar o serviço. Reiniciar o serviço do Edge resultará numa interrupção de 10-15 segundos do tráfego do cliente. 

    Num Edge sem uma correção para este problema, a solução alternativa é limitar um NSD via Edge a uma ligação WAN, o que diminui a probabilidade de este problema ocorrer.

  • Problema 87565 resolvido: para uma empresa de cliente configurada com uma topologia Hub/Spoke, um VMware SD-WAN Spoke Edge pode encaminhar o tráfego para um Hub Edge inesperado, causando problemas com o tráfego do cliente a partir desse Edge.

    O comprimento do caminho AS para os caminhos BGP remotos não é calculado corretamente em alguns cenários. Por isso, os caminhos de Hub Edges inesperados têm um comprimento do caminho AS maior e são preferidos em relação aos Hub Edges esperados.

    Para Edges que não têm esta correção, o problema é temporariamente remediado ao retirar e, em seguida, voltar a anunciar o caminho que deve ser preferencial.

  • Problema 87612 resolvido: para um VMware SD-WAN Edge com inserção VNF em uma ou mais VLANs, os utilizadores cliente nessas VLANs não conseguem obter endereços IP a partir de um servidor de reencaminhamento DHCP.

    O Edge não está a encaminhar os pacotes de reencaminhamento DHCP e, portanto, os utilizadores clientes não estão a receber endereços IP.

    Sem a correção, a única solução alternativa é desativar a inserção VNF na VLAN.

  • Problema 87923 resolvido: quando um pacote ICMP mal formado é enviado para um VMware SD-WAN Edge, o Edge pode encontrar uma falha do Serviço dataplane e, como resultado, reiniciar.

    O Edge não valida o comprimento do pacote IP (por exemplo, um pacote ICMP com um comprimento de pacote IP de 24) e isto pode levar a danos na memória do Edge que desencadeiam a falha do Serviço dataplane e o reinício. 

  • Problema 87982 resolvido: Um VMware SD-WAN Edge que utiliza um módulo SFP do tipo Metanoia com uma ligação PPPoE WAN privada pode não conseguir estabelecer um peering BGP e ligar-se a outros sites.

    Os pacotes marcados da VLAN que utilizam uma ligação PPPoE privada são corrompidos pelo Edge e como resultado nunca chegam ao seu destino. Este problema não afeta as ligações públicas PPPoE.

  • Problema 88148 resolvido: para um site implementado com uma topologia de alta disponibilidade melhorada, uma ligação WAN no Edge em Standby HA pode não aparecer e permanecer num estado “Inicial” (Initial).

    O problema ocorre devido a uma condição de corrida em que o endereço IP da interface para uma interface “USE_PEER” é colocado a zeros. Como parte da sincronização da interface HA, o iface->ip_addr é confirmado, mas o IP da interface não é, e isto faz com que a ligação WAN no Edge em standby permaneça num estado inicial, uma vez que não tem um endereço IP.

  • Problema 88152 resolvido: os pedidos SNMP à subinterface de um VMware SD-WAN Edge não funcionam.

    Este é um comportamento de um dia e todos os pedidos SNMP para uma subinterface do Edge vão atingir o tempo limite. A correção para este problema adiciona suporte para estes pedidos SNMP à subinterface de um Edge.

  • Problema 88317 resolvido: num VMware SD-WAN Edge que utiliza ligações públicas e privadas e tem SD-WAN acessível (SD-WAN Reachable) configurado, quando uma ligação pública fica inativa, o tráfego direto não utiliza a ligação privada como esperado.

    Quando uma política empresarial é definida para preferir a ligação pública, o fluxo não utiliza a ligação privada SD-WAN acessível enquanto a ligação pública preferida estiver inativa. A correção adiciona a lógica para permitir ligações SD-WAN acessíveis também quando a seleção da ligação direta tenta descobrir ligações privadas como último recurso.

  • Problema 88450 resolvido: o SSH através de um endereço IPv4 não está a funcionar num VMware SD-WAN Edge.

    Quando as regras da tabela de IP são alteradas para permitir que um pacote SSH seja proveniente de um cliente do lado da WAN (por exemplo, um Servidor VCMP), a regra não está presente. Como resultado, o SSH de um cliente do lado da WAN para um Edge através de um endereço IPv4 após a alteração da preferência de overlay falha.

  • Problema 88550 resolvido: para os clientes que utilizam o Edge Network Intelligence, um VMware SD-WAN Edge não é capaz de comunicar com o serviço Edge Network Intelligence quando um DNS não está explicitamente configurado.

    Quando o DNS não está configurado explicitamente, o serviço Edge Network Intelligence utiliza o DNS da Google por predefinição. Se o DNS escolher uma interface de retorno como interface de origem, então a capacidade de acesso ao serviço é interrompida devido a uma falha de pesquisa de DNS.

    Para uma empresa de cliente que não utilize uma compilação do Edge com a correção, a solução alternativa é configurar o DNS explicitamente no Orchestrator e escolher uma interface real como interface de origem em vez de uma interface de retorno virtual.

  • Problema 88604 resolvido: Num site que utilize uma topologia de alta disponibilidade, caso uma interface WAN fique inativa e, depois, fique operacional num VMware SD-WAN Edge em espera, o evento não é registado no VMware SASE Orchestrator.

    Um utilizador não tem visibilidade sobre os eventos da interface do Edge em espera, o que é especialmente impactante nas implementações de HA melhorada em que o Edge em espera também está a transmitir tráfego.

  • Problema 88757 resolvido: um utilizador que executa o diagnóstico remoto “Esvaziar tabela de caminhos” (Route Table Dump) na IU do Orchestrator pode constatar que a tentativa excede o tempo limite e a página não devolve resultados.

    O diagnóstico Esvaziar tabela de caminhos (Route Table Dump) excede o tempo limite porque o tempo limite do WebSocket é de 30 segundos e, para um site com um número elevado de caminhos, o tempo que o comando de depuração demora a entregar todos os caminhos ao Orchestrator pode exceder esse limite. A correção consiste em reduzir o tempo limite do processo de esvaziamento de caminho para menos de 30 segundos e impedir que o WebSocket exceda o tempo limite antes disso, o que garante que o diagnóstico Esvaziar tabela de caminhos (Route Table Dump) irá devolver um resultado.

  • Problema 89235 resolvido: Na empresa de um cliente que utiliza uma topologia Hub/Spoke e empregue políticas de backhaul da Internet, o tráfego de backhaul a partir de um Edge Spoke do VMware SD-WAN que se destina à Internet pode ser ignorado pelo Edge Hub.

    Quando este problema é encontrado, os utilizadores clientes notarão problemas no tráfego destinado à Internet. O problema ocorre após um dos seguintes: um ciclo de energia do Edge (por exemplo, após uma falha de energia), um reinício do serviço do Edge ou uma alteração da configuração e o problema é provocado por um problema de temporização entre o tráfego de backhaul com origem num Edge Spoke e o caminho anunciado a partir do Edge Spoke.

    Ao encontrar este problema num Edge Spoke sem a correção, um utilizador deve esvaziar os fluxos no Edge Spoke afetado para restaurar o encaminhamento normal do tráfego de backhaul. Isto pode ser realizado no Orchestrator através de Diagnóstico remoto > Esvaziar fluxos (Remote Diagnostics > Flush Flows).

  • Problema 89364 resolvido: para um site que utiliza uma topologia de alta disponibilidade melhorada, se um utilizador executar Diagnóstico remoto > Estado da interface (Remote Diagnostics > Interface Status), a velocidade de ligação da interface do Edge em standby é apresentada como 0 Mbps/Half duplex.

    Os detalhes da velocidade e da negociação automática não são obtidos do Edge em standby onde a interface está ativa e os detalhes não são apresentados corretamente.

  • Problema 89596 resolvido: um VMware SD-WAN Edge pode encontrar uma falha do Serviço dataplane e, como resultado, ser reiniciado, interrompendo o tráfego do cliente.

    Este problema pode ocorrer quando um cliente tiver configurado o NAT. Quando um novo fluxo que utiliza o NAT é estabelecido, existe uma condição de corrida muito rara que pode desencadear uma exceção no serviço Edge, o que causa uma falha e um reinício.

    Sem uma correção para este problema, a única forma de evitar o problema é desativar o NAT.

  • Problema 89627 resolvido: num VMware SD-WAN Gateway em que o serviço Telegraf seja utilizado, um utilizador pode observar um nível de utilização da memória crescente que acabará por levar a um reinício do serviço de Gateway para limpar a memória.

    Quando o Telegraf é utilizado, é obtido e exportado um conjunto de métricas do serviço de Gateway. Durante a operação de obtenção de dados, ocorre uma pequena fuga de memória e a memória utilizada para armazenar as métricas não é libertada.

    Sem a correção, a solução consiste em desativar o serviço Telegraf para evitar a fuga de memória ou monitorizar cuidadosamente a utilização de memória no Gateway. Quando a utilização de memória atingir ~60%, agende um reinício preventivo do serviço de Gateway para limpar a memória. A segunda solução dá tempo até atualizar o Gateway para uma compilação com uma correção do problema enquanto continua a utilizar o Telegraf.

  • Problema 89722 resolvido: a consulta SNMP não funciona quando o servidor SNMP está na Internet pública.

    As alterações de routing a partir da versão 4.3.x afetam negativamente os clientes que querem utilizar o SNMP para consultar um VMware SD-WAN Edge a partir de um servidor SNMP na Internet pública. Criticamente, quando um pedido do SNMP chega numa ligação WAN pública, a resposta é enviada através de uma interface diferente da interface em que o pedido entrou, mas também através de um SD-WAN Gateway, e isso interrompe efetivamente o SNMP neste cenário.

  • Problema 89725 resolvido: nos VMware SD-WAN Edges que utilizem a versão de software 4.3.1 do Edge, os utilitários de Diagnóstico remoto Teste de largura de banda da ligação WAN (WAN Link Bandwidth Test) e Traceroute não funcionam.

    Os utilitários Teste de largura de banda da ligação WAN e Traceroute necessitam de uma entrada adicional para a interface (para o teste de largura de banda) ou o endereço IP (para o Traceroute). Com este problema, o utilizador não pode configurar essas entradas, uma vez que a opção do menu pendente não é mostrada e, portanto, o teste, em qualquer um dos casos, resulta num erro.

  • Problema 89861 resolvido: um VMware SD-WAN Edge pode encontrar uma fuga de memória quando as políticas empresariais que utilizam grupos de objetos estiverem configuradas para o mesmo e tal pode acabar por conduzir a um reinício do serviço Edge não programado para limpar a memória.

    Sempre que um grupo de objetos é atualizado, ocorre uma pequena fuga de memória do Edge e, com um número suficientemente grande de políticas empresariais com grupos de objetos (por exemplo, aproximadamente 400) que são configuradas e atualizadas com alguma frequência, tal levará a um consumo significativo de memória do Edge. Quando a quantidade de memória atinge 60% ou mais, o Edge desencadeia defensivamente um reinício do Serviço Edge para limpar a memória, o que provoca uma interrupção de 10-15 segundos do tráfego do cliente.

    Para um Edge com uma versão sem uma correção para este problema, a única forma de evitar que o mesmo afete os sites dos clientes é monitorizar a memória. Quando a utilização da memória atingir os 40% e o Orchestrator registar um Evento de aviso de memória, agende um reinício do Serviço Edge numa janela de manutenção para limpar a memória e garantir um impacto mínimo no cliente.

  • Problema 89873 resolvido: Um utilizador pode observar um aumento da utilização da memória num VMware SD-WAN Edge, resultando num Evento de aviso de utilização de memória no Orchestrator e, potencialmente, num reinício não programado do Serviço Edge para recuperar a memória do Edge.

    Este problema ocorre quando o UDP flui com um endereço IP único e as portas são processadas a uma taxa elevada no Edge. A criação do fluxo é processada de forma assíncrona no Edge e, quando vários pacotes de um mesmo fluxo são colocados na fila do serviço de criação do fluxo, os objetos de fluxo são vazados e resultam numa fuga de memória do Edge. O impacto é geralmente mais observado nos modelos Edge de nível de entrada (por exemplo, 510, 610 ou 620), que têm quantidades menores de memória do Edge. Contudo, durante um período suficiente, cada modelo Edge pode atingir um nível crítico de memória (utilização de memória de 60% por mais de 90 segundos) e ser reiniciado. Um reinício não planeado do Serviço Edge para limpar a memória pode provocar uma breve perturbação no tráfego do cliente.

    Para um Edge com uma versão sem uma correção para este problema, a única forma de evitar que o mesmo afete os sites dos clientes é monitorizar a memória. Quando a utilização da memória atingir os 40% e o Orchestrator registar um Evento de aviso de memória, agende um reinício do Serviço Edge numa janela de manutenção para limpar a memória e garantir um impacto mínimo no cliente.

  • Problema 90151 resolvido: para o BGP através de IPsec no Gateway, aplicar diferentes filtros BGP aos vizinhos principais e secundários pode não funcionar como esperado.

    Quando são aplicados filtros diferentes a um Destino Não-SD-WAN (NSD)-BGP nos vizinhos principais e secundários do VMware SD-WAN Gateway, apenas um é aplicado a ambos os vizinhos BGP.

    O motivo deste problema é que, relativamente ao Gateway de parceiro (PG)-BGP, o serviço SD-WAN identifica os filtros BGP com uma combinação de enterprise_logical_id e segment_id e a utilização de enterprise_logical_id era suficiente para o Gateway de parceiro-BGP, porque, para uma determinada combinação de segmento-empresa, só poderíamos ter 1 vizinho PG-BGP.

    No entanto, este método foi herdado para o NSD-BGP no Gateway, onde pode haver até 2 vizinhos BGP (principal e secundário) para a mesma combinação de segmento-empresa. Como resultado, a combinação de enterprise_logical_id e segment_id não é suficiente para diferenciar entre filtros de 2 vizinhos NSD-BGP diferentes.

  • Problema 90216 resolvido: o Traceroute pode não mostrar o endereço IP correto de um VMware SD-WAN Hub Edge quando o fluxo de tráfego é de Cliente > Spoke Edge > Hub > Servidor (Client > Spoke Edge > Hub > Server).

    Se um Spoke Edge tiver uma Política empresarial (Business Policy) configurada para fazer o backhaul do respetivo tráfego para um Hub Edge com Grupo de transporte (Transport Group) configurado para utilizar Privado com fios (Private Wired) e Obrigatório (Mandatory), quando o pacote Traceroute chega ao Hub Edge, o Hub Edge responde com o endereço IP incorreto (neste caso, o endereço IP público, em vez do endereço IP privado) ao Traceroute.

  • Problema 90280 resolvido: num site implementado com uma topologia de Alta Disponibilidade e configurado para utilizar o Edge-a-Edge dinâmico, o VMware SD-WAN HA Edge pode falhar inesperadamente.

    Este problema pode ocorrer num site que tenha uma elevada taxa de criação e eliminação de túneis dinâmicos entre outros Edges. Neste cenário, o Edge pode contabilizar incorretamente o número de interfaces que estão a funcionar, o que pode levar o serviço Edge a concluir que todas as ligações estão inativas e acionar uma recuperação automática HA.

  • Problema 90283 resolvido: um cliente pode ter má qualidade de áudio e/ou vídeo em chamadas VoIP e de videotelefonia se a contabilização de underlay for ativada para a ligação WAN que está a ser utilizada no VMware SD-WAN Edge.

    Ao verificar os registos, o utilizador pode observar pacotes para tráfego bidirecional em que o tráfego é assimetricamente encaminhado e um dos caminhos é pelo underlay. Por outras palavras, quando os caminhos de um fluxo são assimétricos de uma forma em que o tráfego segue por um caminho de underlay numa direção e utiliza um caminho de overlay na direção oposta e onde a Contabilização de underlay (Underlay Accounting) está ativada para essa ligação WAN, poderá ocorrer perda de pacotes em fluxos bidirecionais, que são típicos de chamadas VoIP e de videotelefonia, mas não se limitam às mesmas.

  • Problema 90513 resolvido: um utilizador pode não conseguir fazer o SSH num VMware SD-WAN Edge, apesar de ter configurado um endereço IP que era permitido para essa atividade.

    Ao adicionar um endereço IP a ser permitido para o SSH remoto num Edge, pode verificar-se uma condição de corrida que faz com que as tabelas de IP não sejam atualizadas com uma falha de comando. O resultado é que o SSH é bloqueado para o Edge.

  • Problema 90797 resolvido: um VMware SD-WAN Edge pode encontrar uma falha do Serviço dataplane e reiniciar para recuperar, o que causa uma interrupção de 10-15 segundos do tráfego do cliente para cada reinício.

    O problema é desencadeado por um evento de acesso à memória inválido no Motor de Inspeção profunda de pacotes (DPI) do Edge. Os fluxos do Motor de DPI não são limpos regularmente, o que leva a danos na memória nesse módulo. A correção para este problema elimina os fluxos para cada fluxo do Motor de DPI logo que a classificação do pacote esteja concluída.

    Se este problema acontecer com Edges membros de um cluster de Hub, também há uma interrupção do tráfego do cliente, uma vez que haveria um reequilíbrio do tráfego após o reinício de cada membro do cluster.

  • Problema 90876 resolvido: O DNS falha num Segmento não global para um cliente à distância de um hop que esteja ligado a um VMware SD-WAN Edge por uma interface LAN ou por uma subinterface encaminhada sem um IP do Gateway.

    A causa do problema difere dependendo do tipo de interface Edge que o cliente a um hop de distância está a utilizar.

    • Se o cliente a um hop de distância estiver ligado a um Edge através de uma porta LAN, a resolução DNS falhará para o Segmento não global, dado que o Edge que encaminha o pacote de resposta para o cliente é a interface VCE1 e o processo do Edge trata-o como um segmento Global. Como resultado, o pacote de resposta é ignorado à medida que um caminho estático fica disponível na tabela de encaminhamento do Segmento global.

    • Se o cliente a um hop de distância estiver ligado a um Edge via uma porta de subinterface encaminhada que não tem um endereço IP de Gateway e um caminho estático para o cliente no Orchestrator, a resolução DNS falhará para o cliente, dado que o Edge não tem um caminho para o cliente. Corresponde ao caminho ligado e envia um ARP para o próprio IP de destino, o ARP falha e a resposta não é enviada.

    Para um Edge que não tem uma correção para este problema, a solução alternativa para um cliente que utiliza uma LAN do Edge é utilizar apenas o Segmento global. Para um cliente que utiliza uma subinterface encaminhada, a solução alternativa é indicar um endereço IP de Gateway e, se tal não for possível, utilizar apenas o Segmento global.

  • Problema 91203 resolvido: para uma empresa de cliente configurada com uma topologia Hub/Spoke onde o VMware SD-WAN Spoke Edge está configurado para fazer o backhaul do tráfego através de um Hub Edge, um utilizador pode observar um fraco desempenho de tráfego para fluxos com backhaul.

    A ramificação do backhaul no Hub Edge é determinada pelos tipos de caminho de Origem e Destino (por outras palavras, Origem = empresa, Destino = cloud), mas esta abordagem pode levar a um comportamento inconsistente, uma vez que depende de incidentes baseados em alterações de caminho e pode resultar em pacotes removidos de fluxos com backhaul. A correção para este problema é fazer a determinação da ramificação do backhaul com base nas mensagens do Spoke Edge.

  • Problema 91365 resolvido: para um cliente que utilize o Edge Network Intelligence, um VMware SD-WAN Edge no qual a Análise está configurada sofre uma fuga de memória, o que faz com que o Edge acione um reinício do Serviço Edge para limpar a memória.

    Quando a função Análise está ativada num Edge, o serviço de Dataplane do Edge começa a vazar memória a uma taxa constante, o que resultará na necessidade de acionar um reinício de serviço não agendado por parte do Edge para limpar a fuga de memória quando atingir um nível crítico (utilização da memória de 60% durante mais de 90 segundos). Um reinício do Serviço Edge provoca uma interrupção de 10-15 segundos no tráfego do cliente. No terreno, o tempo necessário para acionar um reinício do Serviço Edge tem sido de aproximadamente 3 a 4 dias e, depois de limpa a memória, a fuga é retomada com a mesma janela de tempo geral no próximo reinício do Serviço Edge. O período em que o Edge atinge um nível crítico de utilização da memória depende do modelo Edge e da quantidade de informações que a funcionalidade Análise está a registar para esse Edge.

    Para um Edge que não inclua uma correção para este problema, o cliente tem duas opções: a) desativar temporariamente a Análise no Edge até que seja disponibilizada uma compilação do Edge corrigida; ou b) monitorizar a memória do Edge. Quando a utilização da memória atingir os 40% e o Orchestrator registar um Evento de aviso de memória, agende um reinício manual do Serviço Edge numa janela de manutenção para limpar a memória e garantir um impacto mínimo no cliente.

  • Problema 91746 resolvido: Um VMware SD-WAN Edge que utilize a autenticação 802.1x com fios ou sem fios (por exemplo, RADIUS, Cisco ISE) pode sofrer falhas de autenticação de certificados e todo o tráfego que exige esta autenticação é descartado no Edge.

    O problema é provocado pela alteração inadequada dos cabeçalhos L4 dos pacotes fragmentados do IP por parte do Edge, o que faz com que os pacotes fiquem danificados antes de saírem do Edge. O problema afeta principalmente os pacotes UDP e, visto que estes pacotes são utilizados para a autenticação de certificados 802.1x, tem o potencial de fazer com que os clientes com fios ou sem fios 802.1x falhem.

    Num Edge sem uma correção para este problema, a solução é desativar a autenticação 802.1x.

  • Problema 91875 resolvido: Para um cliente que tenha configurado uma ligação WAN como backup num VMware SD-WAN Edge, este pode observar que a ligação WAN de backup se torna ativa de forma intermitente, mesmo que as condições que exijam que a ligação se torne ativa não estejam presentes.

    O problema é causado por uma condição de corrida num processo Edge que leva o Edge a pensar erradamente que a ligação WAN de backup é necessária e avançar para a criação de um túnel para essa ligação onde o Edge não tem segurança para detetar e remover este túnel errado.

  • Problema 92216 resolvido: um utilizador pode observar um alerta a indicar que um VMware SD-WAN Edge está a utilizar 60% do limite de túneis especificado.

    Este “Alarme de limite superior suave” para os túneis do Edge confunde o cliente, pois não existe qualquer limite nos 60% de utilização. O único limite significativo é o limite máximo de túneis especificado para um modelo Edge. Os limites de túneis do Edge para todos os modelos Edge estão disponíveis na ficha técnica Especificações da Plataforma VMware SD-WAN Edge. Está disponível uma ligação de transferência da ficha técnica mais atual na parte inferior da página Guia de Hardware do VMware SD-WAN.

  • Problema 92454 resolvido: o Diagnóstico remoto > Traceroute (Remote Diagnostic > Traceroute) não funciona quando um nome de domínio que apenas é resolvido para um endereço IPv4 é introduzido no campo Destino (Destination).

    Se um nome de domínio for resolvido apenas para um endereço IPv4, o comando Traceroute executado através de Diagnóstico remoto (Remote Diagnostics) não funciona. Isto acontece porque o VMware SD-WAN Edge tenta sempre resolver o nome de domínio para o registo IPv6 e não encontra o endereço IPv4.

    Num Edge sem esta correção, a solução alternativa é utilizar o endereço IPv4 correspondente ao nome de domínio diretamente no comando Traceroute. O endereço IPv4 pode ser obtido ao fornecer o nome de domínio ao Diagnóstico remoto > Teste de DNS (Remote Diagnostic > DNS Test).

  • Problema 92758 resolvido: Um site com uma topologia de alta disponibilidade pode registar vários problemas diferentes nos VMware SD-WAN HA Edges, incluindo um estado de LED incorreto ou de falha HA.

    O estado de LED incorreto no Edge Ativo é apresentado a amarelo em vez de verde, apesar de o Edge estar ativo e de as ligações WAN estarem ativas e estáveis.

    Este problema é atribuído a uma corrupção da memória partilhada no Edge que se manifesta de várias formas. Isto pode ser confirmado obtendo os contadores com a ferramenta getcntr para um domínio específico, como vcedge.com. A saída da ferramenta apresenta a mensagem “O domínio não existe” (Domain does not exist) e o nome do contador não é encontrado.

    O VMware SD-WAN baseia-se na chamada de sistema ftok() para derivar chaves de memória partilhada SYSV. O ftok() utiliza os últimos 16 bits de inode para calcular a chave. Isto pode provocar uma colisão de chave quando os números de inode diferem em, pelo menos, 64K. Quando ocorre essa colisão, os contadores de memória partilhada de túnel dinâmico podem corromper as variáveis de memória partilhada, resultando em vários problemas possíveis com o Edge, incluindo um estado de LED incorreto, inoperacionalidade dos contadores ou uma falha HA.

  • Problema 92964 resolvido: quando um VMware SD-WAN Edge é configurado como um agente de reencaminhamento DHCP, o pacote DHCP NACK não é encaminhado através da subinterface para o cliente.

    Quando o anfitrião solicita um endereço IP que não esteja no intervalo de IP atual, o servidor DHCP deve enviar uma mensagem NACK (confirmação negativa) para o pedido de DHCP do anfitrião. No entanto, quando o servidor DHCP envia pacotes DHCP NACK, o Edge que está configurado como reencaminhamento DHCP removerá os pacotes sem encaminhar.

  • Problema 93052 resolvido: os utilizadores clientes por trás de um VMware SD-WAN Edge podem observar uma qualidade de tráfego degradada, incluindo latência alta e velocidades de débito lentas.

    Esta causa imediata do problema é um thread do caminho FSM (Máquina de Estados Finitos) que funciona com uma utilização de 100% da CPU do Edge. Quando uma CPU do Edge está em funcionamento a 100%, tal resultará numa qualidade do caminho degradada.

    A razão pela qual o thread do caminho FSM está a esgotar a CPU do Edge é o resultado de valores do contador pouco fiáveis que levam o thread do caminho FSM a concluir que há mais mensagens na fila (quando, na realidade, não há nenhuma) que é servida por este thread. Isto resultava no funcionamento contínuo do thread sem inatividade. A correção adiciona uma API que verifica as estruturas reais de dados de fila para determinar o estado da fila.

  • Problema 93062 resolvido: quando um utilizador executa o diagnóstico remoto “Estado da interface” (Interface Status) no VMware Orchestrator, o Orchestrator devolve um erro para esse teste e não é concluído ou o teste não devolve resultados para as interfaces encaminhadas.

    A mensagem de erro que pode ser visualizada é “erro ao ler os dados para o teste” (error reading data for test). Se o teste for concluído, os resultados das interfaces encaminhadas estão vazios sem quaisquer informações sobre velocidade ou duplex. De qualquer forma, o estado da interface é inválido. O problema está relacionado com o comando de depuração subjacente ao estado da interface omitir as portas DPKD ativadas.

  • Problema 93141 resolvido: num site implementado com uma topologia de alta disponibilidade, um cliente que utiliza um interruptor L2 a montante do par Edge HA pode observar evidências de um ciclo de tráfego L2 nos registos do interruptor, embora não exista realmente um ciclo.

    O problema é provocado pelo Edge HA enviar o heartbeat da interface HA com o endereço MAC virtual para o Orchestrator em vez do endereço MAC real da interface, o que é causado pelo Edge HA armazenar o endereço MAC virtual no ficheiro MAC. Como resultado, o interruptor L2 ligado deteta tráfego do mesmo MAC de origem proveniente de duas interfaces Edge diferentes e regista-o como um ciclo L2. Este problema é cosmético ao nível do registo, dado que não existe realmente um ciclo L2 e não existe nenhuma interrupção do tráfego do cliente nem perda de contacto com o Orchestrator decorrente do mesmo.

    Num Edge sem esta correção, o cliente pode ignorar os eventos de deteção de ciclo L2 dos interruptores a montante provenientes da interface de HA do Edge (normalmente GE1). 

  • Problema 93237 resolvido: um VMware SD-WAN onde estão configurados 1000 ou mais grupos de objetos vai encontrar uma falha do Serviço dataplane e reiniciar para recuperar, o que causa uma interrupção do tráfego do cliente de 10-15 segundos.

    Quando 1000 ou mais grupos de objetos são configurados na página Configurar > Política empresarial (Configure > Business Policy) da IU do Orchestrator, a configuração que é emitida para o Edge desencadeia danos na memória do Edge, o que faz com que o serviço Edge falhe e reinicie.

  • Problema 93383 resolvido: Sintoma: Um VMware SD-WAN Edge pode sofrer uma ou mais falhas do serviço do dataplane com uma interrupção no tráfego do cliente.

    O problema é provocado por uma rara instância de incompatibilidade no número de interfaces armazenadas no Edge em duas estruturas de dados diferentes, o que desencadeia uma exceção e resulta na falha do serviço do Edge uma ou mais vezes. O serviço Edge precisa de reiniciar para recuperar, o que numa implementação não HA, provocaria uma interrupção de 10 a 15 segundos do tráfego do cliente. No entanto, se o serviço do Edge falhar três vezes consecutivas, o Edge precisará de um reinício ou ciclo de energia para recuperar.

  • Problema 93853 resolvido: um VMware SD-WAN Gateway sobrecarregado pode encontrar uma falha do Serviço dataplane com um código SIGXCPU e reiniciar o serviço para recuperar.

    Com uma sobrecarga, vários threads do Gateway que executam várias atividades, tais como routing e registos, são privados de recursos da CPU e não são capazes de concluir a tarefa dentro do prazo estipulado. O serviço Gateway interpreta estes threads atrasados como estando num estado de impasse e emite o sinal SIGXCPU com uma subsequente terminação do processo dataplane do Gateway.

  • Problema 94204 resolvido: Um utilizador pode observar que as tentativas para gerar um pacote de diagnóstico para um VMware SD-WAN Edge com capacidade VNF falham.

    Um pacote de diagnóstico falha a conclusão num Edge com capacidade VNF, dado que o Edge fica sem espaço em disco. Isto pode acontecer se o Edge tiver gerado um ou mais núcleos e é provocado pelo Edge enviar estes núcleos para a pasta /vnf/tmp. Cada núcleo é descomprimido na pasta /vnf/tmp e devido ao tamanho do núcleo descompactado, este rapidamente enche esta pasta, o que faz com que o pacote de diagnóstico falhe. 

    Os Edges com capacidade para VNF (Função de rede virtual) incluem os modelos que se seguem: 520v, 620, 640, 680 e 840.

  • Problema 94395 resolvido: num site implementado com uma topologia de alta disponibilidade, a recuperação automática HA pode falhar, uma vez que o Edge Standby não é movido para o estado Ativo após o Edge ativo ter falhado, resultando numa interrupção do tráfego do cliente.

    Este problema pode surgir quando mais de um par de Edges HA estão ligados aos mesmos comutadores WAN a montante ou à mesma rede de transmissão. Neste cenário, os Edges HA podem processar heartbeats HA WAN não parceiros, o que afeta o estado de HA local e leva a um comportamento de HA imprevisível, incluindo a não promoção do Edge em standby para Ativo.

    Num par HA que não tem uma correção para este problema, a solução alternativa é evitar a partilha da mesma rede de transmissão entre dois pares HA diferentes.

  • Problema 94401 resolvido: num VMware SD-WAN Edge onde a firewall com estado está ativada, um fluxo TCP estabelecido pode atingir o tempo limite demasiado depressa e ser esvaziado.

    O fluxo TCP estabelecido é tratado como um fluxo TCP não estabelecido e está sujeito a um tempo limite mais curto. Quando existe uma reposição TCP (RST) observada num fluxo TCP, seguido de um handshake TCP de 3 vias, mesmo que o estado de TCP seja apresentado como Estabelecido, o fluxo é esvaziado depois de ser submetido a um tempo limite de fluxo TCP não estabelecido.

  • Problema 94430 resolvido: Na empresa de um cliente que utilize uma topologia Hub/Spoke onde vários Hubs são implementados, um utilizador que utiliza um Edge Spoke do VMware SD-WAN pode observar problemas com o tráfego destinado a um Edge Hub.

    Os problemas de tráfego do cliente ocorrem quando o Spoke Edge encaminha o tráfego para um Hub diferente daquele que se espera receber o tráfego. O problema é provocado pelo comprimento do caminho AS devido aos caminhos BGP remotos não serem devidamente calculados em determinadas situações. Devido a este motivo, os caminhos a partir dos Hubs que deveriam ter uma preferência de encaminhamento inferior acabam por ter um comprimento de AS_PATH superior e podem ser preferidos.

    Se encontrar este problema sem uma correção, um cliente poderá retirar e anunciar novamente o caminho que se espera que seja o preferido.

  • Problema 94775 resolvido: numa empresa de cliente que utiliza uma topologia Hub/Spoke onde o VMware SD-WAN Spoke Edge faz o backhaul do respetivo tráfego através de um Hub Edge, os utilizadores clientes podem observar problemas de desempenho de tráfego.

    Isto é causado porque é definida a flag errada para tráfego de backhaul. Os pacotes de backhaul são processados no Spoke Edge como se estivessem num Hub Edge. Isto leva a problemas de pesquisa de caminhos no Hub e os pacotes de backhaul são removidos.

  • Problema 95047 resolvido: quando um utilitário de análise de portas de segurança analisa um VMware SD-WAN Edge onde o Edge Network Intelligence (Análise) não está ativado, a análise vai comunicar que a porta de Syslog 514 está fechada, o que significa que pode estar acessível.

    O Edge Network Intelligence escuta na porta 514 (Syslog). Se a Análise (Analytics) não for ativada, a porta 514 continua acessível, mas não responderá aos pedidos. Por isso, um scanner de portas comunica que a porta está “fechada” (ou seja, a porta está acessível, mas não há nenhuma aplicação à escuta na mesma).

  • Problema 95073 resolvido: numa empresa de cliente que utiliza uma topologia Hub/Spoke onde o VMware SD-WAN Spoke Edge faz o backhaul do respetivo tráfego através de vários Hub Edges, os utilizadores clientes podem observar problemas significativos no tráfego de backhaul.

    O problema é causado por uma falha de pesquisa de caminhos no Spoke Edge para o tráfego que corresponde a uma regra de backhaul. O Spoke Edge remove os fluxos com backhaul que não conseguem um caminho para um Hub Edge.

  • Problema 95121 resolvido: quando um “SIM bloqueado” (um SIM que está bloqueado por palavra-passe) for utilizado num modelo VMware SD-WAN Edge 510-LTE ou 610-LTE, o cliente encontrará falhas ao estabelecer a ligação na rede.

    Os utilizadores encontram falhas no estabelecimento de caminhos quando utilizam cartões SIM LTE bloqueados com as ranhuras SIM dos modelos Edge 510-LTE e 610-LTE porque o desbloqueio do SIM não está a funcionar a partir do Orchestrator e isso deve-se à falta de suporte para SIMs bloqueados nos scripts ModemManager do Edge.

  • Problema 95501 resolvido: para uma empresa de cliente que utiliza uma topologia Hub/Spoke e BGP para routing, os utilizadores clientes nos VMware SD-WAN Spoke Edges podem observar um fraco desempenho de tráfego.

    Um administrador observaria que o Spoke Edge prefere caminhos marcados com a comunidade de transmissão de um Hub não incluído no respetivo perfil em vez do Hub Edge configurado para ser utilizado para esse Spoke Edge. Isto porque o tráfego do Spoke Edge está a seguir por um caminho Ramo a Ramo Dinâmico para prefixos de transmissão.

    O problema é causado porque o SD-WAN faz a reposição da flag de transmissão para mensagens de routing recebidas de um Hub Edge. Como resultado, quando um túnel Ramo a Ramo Dinâmico é formado, são instalados caminhos diretos para estes prefixos de transmissão que resultam em routing de qualidade inferior à ideal e ao desempenho de tráfego degradado.

  • Problema 95503 resolvido: Em situações raras, um cliente pode ver um modelo 610, 610N ou 610-LTE do VMware SD-WAN Edge apresentar o mesmo endereço MAC para todas as interfaces da Ethernet.

    Um Edge 610 (qualquer tipo) pode mostrar um endereço MAC eth0 que termina em 0xF*. Nestes casos, as portas GE1 a GE6 recebem o mesmo endereço MAC devido a um problema com o script que calcula e atribui endereços MAC.

    A correção corrige este comportamento do script e um modelo Edge 610 afetado deveria calcular e alocar corretamente endereços MAC únicos quando o Edge é atualizado para uma compilação que o inclui.

  • Problema 96441 resolvido: num site que utilize uma topologia de alta disponibilidade, o cliente pode observar recuperações automáticas de HA frequentes.

    O problema é acionado pela interface de HA ser marcada pelo Edge como inativa e, em seguida, regressar em 500 a 1000 ms, o que pode acionar um recuperação automática da HA. No entanto, estes eventos de interface inativa são falsos e provocados por uma interface ativada por DPDK com consultas em intervalos de 500 ms para determinar o estado da interface. Utilizando este método, o controlador do dispositivo subjacente pode, por vezes, comunicar falsamente um evento de interface inativa e cada evento faz com que o Edge marque a interface como inativa até que a próxima consulta do estado da interface (em 500 ms) comunicar que a interface está ativa.

  • Problema 96626 resolvido: quando uma interface VMware SD-WAN Edge tem um endereço IP secundário atribuído, as ligações através do endereço IP secundário falham.

    Qualquer pedido proveniente de outro ramo para um IP na rede secundária gerará um ARP a partir do endereço IP principal em vez do endereço IP secundário. Consequentemente, o ARP permaneceria por resolver, levando a falhas no tráfego através do endereço IP secundário.

  • Problema 96739 resolvido: quando um utilizador observa o separador Monitorizar > Aplicação (Monitor > Application) de um VMware SD-WAN Edge num VMware SASE Orchestrator, o ecrã pode mostrar FQDNs de destino com os nomes de domínio errados.

    Este problema pode ocorrer quando as estatísticas do Edge atingem o respetivo limite (conhecido como uma condição excedida) e, em vez de apresentar estas estatísticas como excedidas, o Orchestrator apresenta nomes de domínio aleatórios no FQDN de destino do separador Aplicação (Application).

  • Problema 96888 resolvido: Em certas condições de carga, os protocolos de routing para o BGP ou OSPF podem reiniciar aleatoriamente, levando a uma nova convergência do caminho e à interrupção do tráfego.

    Em condições de carga mais elevadas, os processos de protocolo de routing do BGP e do OSPF são forçados a esperar mais tempo do que o esperado pela CPU do Edge para serem agendados, o que leva a um atraso e ao reinício do protocolo de routing. O atraso no protocolo de routing é provocado por uma alocação insuficiente de largura de banda na CPU e pode ocorrer em qualquer modelo Edge.

  • Problema 96994 resolvido: ao fazer um percurso SNMP num VMware SD-WAN Edge, algumas das interfaces podem não estar visíveis.

    As interfaces em falta podem ser interfaces válidas que deveriam ser visíveis no snmpwalk. No entanto, devido ao aparecimento de uma interface inválida na lista de hardware do Edge, as interfaces válidas que aparecem após a inválida na lista não serão visíveis ou devolvidas por snmpwalk. Uma interface aqui é inválida se aparecer na lista de hardware, mas não aparecer ao executar o comando ifconfig no Edge.

    Embora este problema possa potencialmente afetar qualquer Edge, há uma maior probabilidade de ser encontrado num Edge virtual implementado com o Azure. Isto deve-se à tendência do Edge Azure de listar um maior número de interfaces na respetiva lista de hardware em comparação com o número de interfaces identificadas no próprio Edge ao utilizar ifconfig.

  • Problema 97152 resolvido: quando uma empresa de cliente tem uma política empresarial configurada com um grupo de serviço como algo com fios e o modo de ligação como “Disponível” (Available), o tráfego não é direcionado para uma ligação sem fios quando as ligações com fios ficam inativas e o tráfego dos utilizadores clientes no site que corresponde a essa regra falha.

    Quando uma regra da política empresarial que inclui utilizar um grupo de serviço de ligações WAN com um Modo de ligação (Link Mode) “Disponível” (Available) e há uma ou mais ligações WAN sem fios no site, a expectativa é que o tráfego que utiliza essa regra seja recuperado automaticamente para as ligações WAN sem fios se as ligações com fios no grupo de serviço ficarem inativas (por outras palavras, caso se tornem indisponíveis) para garantir um fluxo ininterrupto do tráfego que corresponde a essa regra. Neste problema, não está a ocorrer o direcionamento do tráfego para as ligações WAN sem fios.

  • Problema 97225 resolvido: as redes principais e secundárias não são instaladas nos caminhos de outros Edges depois de ativar/desativar endereços IP principais e secundários, o que resulta em vários problemas relacionados com endereços IPv6.

    Algumas das formas de impacto deste problema no cliente incluem:

    • Endereços IPv6 em falta nas interfaces.

    • Túneis que não se formam com endereços IPv6.

    • A comunicação entre o Edge e o Orchestrator é interrompida, o que tem implicações sérias porque o Orchestrator vai marcar o Edge como offline e não permitirá ter mais controlo nem configurar o Edge através da IU do Orchestrator.

    O problema é causado por uma condição de corrida entre o processo Dataplane do Edge e o daemon (netifd) da interface de rede do Edge quando são reiniciados devido a uma alteração num endereço IP VLAN que leva a que os endereços IPv6 sejam removidos das interfaces, o que provoca os impactos acima referidos.

  • Problema 97321 resolvido: Quando a Análise do Edge Network Intelligence é ativada num VMware SD-WAN Edge, o Edge pode acionar um reinício do Serviço do Edge, o que provoca uma interrupção de 10-15 segundos do tráfego do cliente.

    Quando a Análise estiver ativada no Edge, o Edge pode experienciar uma condição de falta de memória seguido de um estado de memória “dupla memória livre”. O Edge reinicia o serviço para restaurar a memória. Os sintomas para este problema podem ocorrer várias vezes enquanto a Análise está ativada.

  • Problema 98136 resolvido: Para as empresas de clientes que usam uma topologia Hub/Spoke onde a VPN Ramo a Ramo Dinâmica está configurada, os utilizadores cliente atrás de um SD-WAN Edge Spoke podem observar que algum tráfego tem latência inesperada, resultante do tráfego utilizar um caminho que não o ideal.

    O tráfego do Spoke Edge que sofre este problema utiliza um caminho que era inicialmente um caminho de não-transmissão para um Hub Edge não incluído no perfil que o Spoke Edge estava a utilizar. Um túnel de VPN Ramo a Ramo Dinâmica pode ser formado do Edge Spoke para o Edge Hub devido ao tráfego ser enviado em direção a outro prefixo não relacionado e, nesta instância, um caminho não de transmissão é instalado no Edge Spoke.

    Como resultado deste caminho de não transmissão, todo o tráfego direcionado para este prefixo começa a passar pelo Edge Hub e o caminho de não transmissão torna-se de transmissão (mudança de comunidade para comunidade de transmissão), mas o caminho de não transmissão instalado anteriormente não é revogado e o tráfego utiliza o caminho do Edge Hub enquanto o túnel da VPN Ramo a Ramo Dinâmica permanece ativo.

    Num Edge sem uma correção para este problema, aguarde a desativação do túnel de VPN Ramo a Ramo Dinâmica, após a qual o caminho de transmissão não será instalado no Spoke Edge quando for formado um novo túnel de VPN Ramo a Ramo Dinâmica em direção ao Hub Edge.

  • Problema 97691 resolvido: numa empresa de cliente que utiliza o BGP e tem um Destino Não-SD-WAN via Edge configurado, a vizinhança NSD para BGP no Edge pode não surgir.

    Os pacotes para estabelecer a vizinhança BGP são removidos com o motivo from_cloud_to_direct_dc_drop. Isto acontece porque a pesquisa do caminho de origem é feita incorretamente no FIB (base de informações de encaminhamento) e não na tabela de routing local do Edge. Uma vez que o FIB não tem o próprio caminho de IP local do BGP, associa o caminho de cloud principal, o que faz com que o tráfego do BGP iniciado pelo Edge seja removido.

  • Problema 97743 resolvido: Numa empresa cliente com topologia de Alta Disponibilidade, quando uma interface LAN ou WAN de VMware SD-WAN HA Edge falha, o Edge Ativo pode não responder.

    Quando o Edge ativo deteta que o respetivo par Edge em standby tem um maior número de interfaces LAN/WAN, muda para um estado de standby e deixa de responder ou fica num impasse com uma utilização de 100% da CPU. A única forma de recuperar o Edge HA afetado é reiniciá-lo.

  • Problema 98514 resolvido: Numa empresa do cliente implementada com uma topologia de alta disponibilidade, sempre que uma alteração à configuração é aplicada nos Edges do VMware SD-WAN, o utilizador deveria observar um evento que indica “O serviço de gestão falhou” (Management service failed) no Edge em standby e que em resultado de tal o serviço de gestão está a reiniciar.

    Uma vez que este é um serviço de gestão (que não envolve o tráfego do cliente) e no Edge em standby, não existe nenhum impacto negativo para os utilizadores de clientes no local de HA quando o serviço de gestão do Edge em standby reinicia. Ainda assim, trata-se de um evento crítico registado nos Eventos do Edge que será de grande preocupação para os administradores de cliente.

  • Problema 99718 resolvido: o vizinho BGP não é estabelecido quando o endereço IP secundário numa SVI (Interface Virtual de Switch) é utilizado.

    Quando o Edge processa pacotes de entrada, verifica se o endereço de destino do pacote de entrada coincide com o endereço IP da interface de entrada. Uma vez que apenas os endereços IP principais são comparados, os pacotes com um endereço IP de destino como um endereço IP secundário são removidos. Como resultado, a sessão BGP não é formada neste IP secundário.

  • Problema 100089 resolvido: um utilizador pode observar caminhos inesperados nos vizinhos OSPF ou BGP dos VMware SD-WAN Edges.

    O Edge redistribui os respetivos caminhos de gestão internos que têm um prefixo de (169.254.129.x) em BGP/OSPF e estes são recebidos pelos respetivos vizinhos OSPF/BGP ligados ao Edge.

    Num Edge sem uma correção para este problema, um utilizador poderia configurar filtros de saída BGP/OPSF para estes prefixos (169.254.129.x).

  • Problema 100363 resolvido: um VMware SD-WAN Gateway pode encontrar uma falha do Serviço dataplane e desencadear um reinício do serviço, o que resulta numa interrupção do tráfego de 1-5 segundos.

    Este problema ocorreu durante os testes de esforço com a falha que ocorreu no futex_abstimed_wait e é o resultado de um thread num estado de impasse que desencadeia a falha do serviço e o reinício.

  • Problema 100796 resolvido: para uma empresa de cliente implementada com uma topologia de alta disponibilidade melhorada, quando um utilizador executa o Diagnóstico remoto > Estado da interface (Remote Diagnostic > Interface Status) para o par Edge HA, o VMware SASE Orchestrator devolve uma mensagem de erro “Erro ao ler os dados para teste” (Error reading data for test).

    Este problema é específico apenas dos Edges em HA melhorada. Este problema não é encontrado em Edges autónomos nem em Edges configurados numa topologia de HA legada. O problema é o resultado de um defeito na API que deve obter o estado de ligação de HA melhorada.

  • Problema 101049 resolvido: Se uma empresa do cliente utilizar caminhos seguros e não seguros, poderá registar perdas de caminho elevadas.

    Um exemplo da utilização tanto de caminhos seguros como caminhos não seguros seria uma empresa onde um Gateway de parceiro é usado e o Edge aprende sub-redes de um vizinho BGP (não seguro) e, em seguida, o Edge aprende essas mesmas sub-redes de outra Edge na rede (seguro). Neste cenário o caminho seguro é o preferencial, mas se o caminho seguro for revogado, o tráfego não é comutado para o caminho não seguro. O problema é provocado pelo serviço do Edge não sequenciar os túneis de gestão responsáveis por um encaminhamento correto.

Problemas resolvidos do Orchestrator

Resolvido na versão R432-20221108-GA do Orchestrator

A versão R432-20221108-GA do Orchestrator foi lançada a 16/11/2022 e resolve os seguintes problemas desde a versão R431-20220715-GA do Orchestrator. 

A versão 4.3.2 contém todas as correções do Orchestrator que estão listadas nas notas de versão 4.3.0 ou 4.3.1.

  • Problema 71490 resolvido: um cliente que utilize um VMware SD-WAN Orchestrator que aloje um grande número de Edges com um grande número de eventos de caminhos aprendidos pode observar lentidão no processamento dos respetivos pedidos de saída. Os administradores do Orchestrator observariam que o desempenho do Orchestrator era afetado por uma elevada utilização da CPU.

    Este problema afetaria um Orchestrator com ~5000 Edges, onde cada Edge emitiria ~20 eventos de caminhos aprendidos a cada 30 segundos. O problema era causado por ineficiências na forma como o Orchestrator processa estes eventos de routing aprendidos do Edge e esta compilação inclui otimizações à lógica de processamento de caminhos para evitar que este problema se repita.

  • Problema 73234 resolvido: para uma empresa de cliente onde o Cálculo dinâmico de custos (DCC) não é utilizado e há um grande número de caminhos aprendidos, o VMware SASE Orchestrator pode demorar muito tempo a anunciar os caminhos BGP após o início ou o reinício do BGP.

    Este problema afeta empresas com, pelo menos, algumas centenas de caminhos aprendidos e onde há um número ainda maior de caminhos (por exemplo, cerca de 2 mil), o Orchestrator pode demorar 10 minutos ou mais para anunciar todos os caminhos. A correção para o problema melhora a velocidade da convergência dos caminhos na ausência do DCC.

  • Problema 75895 resolvido: Uma geração de alerta de túnel do Serviço de Segurança na Cloud do Edge (CSS) pode ser ignorada para alguns eventos de túneis CSS.

    Quando um cliente tem um Edge configurado com um Serviço de Segurança na Cloud e existem eventos de túnel Ativo/Inativo (Up/Down) no Edge ao mesmo tempo, o VMware SASE Orchestrator pode não gerar alertas para todos os eventos.

  • Problema 76442 resolvido: foram observados erros de validação da API falsos ao atualizar as configurações de handoff de Gateway de parceiro de um cliente a seguir à remoção de um Gateway do Conjunto de Gateways atribuído do cliente.

    Quando um Gateway de parceiro cujas definições de handoff tenham sido configuradas anteriormente é removido de um Conjunto de Gateways, o Orchestrator não limpa as definições de handoff desse Gateway nas definições de handoff ao nível de cliente. Como resultado, as tentativas subsequentes de atualizar as definições de handoff ao nível do cliente através da API falham, a menos que o cliente da API remova deliberadamente as definições inativas do Gateway.

    Sem a correção, o cliente poderá contornar este problema da seguinte forma: ao atualizar as definições de handoff do Gateway do cliente, os clientes da API podem garantir proativamente que todos os Gateways representados nas definições estão atualmente presentes no Conjunto de Gateways do cliente.

  • Problema 78684 resolvido: para a empresa de um cliente que utilize um Destino Não-SD-WAN via Gateway do tipo Azure, é possível que uma nova sincronização não propague os caminhos estáticos na configuração, conforme esperado.

    Na IU do Orchestrator, quando uma sub-rede é adicionada ou removida, é transmitido um conjunto de parâmetros através da API. Contudo, durante a nova sincronização, os parâmetros não são semelhantes aos que a API espera. Por este motivo, a opção de ressincronização não está a funcionar corretamente. Quando este problema ocorre, mesmo que as sub-redes tenham sido atualizadas no ambiente do Azure, podem não se propagar adequadamente para outros locais da configuração.

  • Problema 82835 resolvido: um Edge 610N (modelo não Wi-Fi) é apresentado como um Edge 610 (compatível com Wi-Fi) no VMware SASE Orchestrator.

    Este é puramente um problema cosmético e o Orchestrator não expõe interfaces Wi-Fi para o Edge 610N. No entanto, isto causa confusão ao cliente que procura acompanhar os respetivos modelos Edge. Se um utilizador verificar o Edge 610N na interface de utilizador local, verá o tipo de modelo correto mostrado.

  • Problema 83165 resolvido: um utilizador operador não consegue transferir um Cliente para um Parceiro no VMware SASE Orchestrator com a indicação de não terem o mesmo Conjunto de Gateways, apesar de terem.

    Este problema é causado por uma chamada da API network/getNetworkEnterpriseProxies que não devolve os detalhes do Conjunto de Gateways e que faz com que o Orchestrator pense que o Parceiro e o Cliente não têm o mesmo Conjunto de Gateways e rejeite a atribuição.

  • Problema 83694 resolvido: quando um utilizador inicia sessão na IU local de um VMware SD-WAN Edge, o VMware SASE Orchestrator não regista nem apresenta esta ação em Monitorizar > Eventos (Monitor > Events).

    Os administradores do cliente não teriam conhecimento de quaisquer inícios de sessão do utilizador locais na interface de utilizador local de um Edge.

  • Problema 88120 resolvido: No VMware SASE Orchestrator, ao olhar para a página Monitor > Edge > Visão Geral (Monitor > Edge > Overview) na IU clássica versus a nova IU, existem discrepâncias no estado de ligação ao ser apresentado no “Modo ao Vivo”.

    A discrepância específica encontra-se na nova IU, em que uma ligação WAN pode apresentar o estado “Standby” quando deve apresentar o estado “Estável”. A IU clássica apresenta corretamente o estado da ligação. 

  • Problema 91179 resolvido: para um VMware SD-WAN Edge que tem uma ligação WAN configurada como reserva dinâmica, se o estado da ligação da reserva dinâmica for Standby, a nova IU do VMware SASE Orchestrator apresenta o estado incorreto para a ligação da reserva dinâmica (Ativa).

    A IU clássica do Orchestrator apresenta o estado correto da ligação (Inativa), pelo que este problema está limitado apenas à nova IU. O problema é provocado pela nova IU não obter a atualização correta sobre a alteração de estado de uma ligação WAN de reserva dinâmica. 

  • Problema 93846 resolvido: para parceiros e operadores que gerem o inventário do Edge através do ZTP, quando um utilizador tenta reatribuir um VMware SD-WAN Edge a um cliente diferente que foi anteriormente atribuído a um cliente e depois eliminado, o VMware SASE Orchestrator devolve o erro “O Edge não foi encontrado” (Edge is not found).

    O Orchestrator determina que o Edge não existe porque não vê o Edge lógico depois de ser eliminado de uma empresa de cliente e um utilizador não pode reatribuí-lo a outro cliente.

Problemas conhecidos

Problemas em aberto na versão 4.3.2

Os problemas conhecidos são agrupados da seguinte forma:

Problemas conhecidos do Edge/Gateway

  • Problema 14655:

    Ligar ou desligar um adaptador SFP pode fazer com que o dispositivo pare de responder no Edge 540, Edge 840 e Edge 1000 e exija um reinício físico.

    Solução alternativa: o Edge deve ser reiniciado fisicamente. Este procedimento pode ser realizado no Orchestrator utilizando Ações Remotas > Reiniciar Edge (Remote Actions > Reboot Edge) ou através do ciclo de ativação do Edge.

  • Problema 25504:

    Custos do caminho estático superiores a 255 podem resultar numa ordenação de caminho imprevisível.

    Solução alternativa: utilize um custo de caminho entre 0 e 255.

  • Problema 25742:

    O tráfego contabilizado de underlay está limitado à capacidade máxima do VMware SD-WAN Gateway, mesmo que seja inferior à capacidade da ligação WAN privada que não está ligada ao Gateway.

  • Problema 25758:

    As ligações WAN USB podem não ser corretamente atualizadas quando são trocadas de uma porta USB para outra, até que o VMware SD-WAN Edge seja reiniciado.

    Solução alternativa: reinicie o Edge após mover as ligações WAN USB de uma porta para outra.

  • Problema 25855:

    Uma grande atualização de configuração no Gateway de parceiro (por exemplo, 200 VRFs ativados por BGP) pode provocar um aumento da latência durante cerca de 2 a 3 segundos para algum tráfego através do VMware SD-WAN Gateway.

    Solução alternativa: nenhuma solução alternativa disponível.

  • Problema 25921:

    A recuperação automática do VMware SD-WAN Hub de alta disponibilidade demora mais do que o esperado (até 15 segundos) quando existem três mil Edges de ramo ligados ao Hub.

  • Problema 25997:

    O VMware SD-WAN Edge pode precisar de um reinício para passar corretamente tráfego numa interface encaminhada que foi convertida para uma porta comutada.

    Solução alternativa: reinicie o Edge após fazer a alteração de configuração.

  • Problema 26421:

    O Gateway de parceiro primário para qualquer site do ramo também deve ser atribuído a um cluster do VMware SD-WAN Hub para túneis ao cluster a ser estabelecido.

  • Problema 28175:

    O NAT de Política Empresarial falha quando o IP do NAT se sobrepõe ao IP de interface do VMware SD-WAN Gateway.

  • Problema 31210:

    VRRP: o ARP não é resolvido no cliente LAN para o endereço IP virtual VRRP quando o VMware SD-WAN Edge é primário com um segmento CDE não global em execução na interface LAN.

  • Problema 32731:

    Os caminhos predefinidos condicionais anunciados através de OSPF não podem ser retirados corretamente quando o caminho está desligado. Ativar e desativar novamente o caminho vai retraí-lo com sucesso.

  • Problema 32960:

    O estado da interface de “Negociação automática” (Autonegotiation) e “Velocidade” (Speed) pode ser apresentado incorretamente na IU de Web Local para os VMware SD-WAN Edges ativados.

  • Problema 32981:

    A velocidade de pré-programação e o duplex numa porta ativada por DPDK podem precisar de um reinício do VMware SD-WAN Edge para que as configurações entrem em vigor, uma vez que exigem a desativação do DPDK.

  • Problema 35778:

    Quando existem múltiplas ligações WAN definidas pelo utilizador numa única interface, apenas uma dessas ligações WAN pode ter um túnel GRE para o Zscaler.

    Solução alternativa: utilize uma interface diferente para cada ligação WAN que precisa de criar túneis GRE para o Zscaler.

  • Problema 36923:

    O nome do cluster não pode ser atualizado corretamente na descrição da interface de NetFlow para um VMware SD-WAN Edge que está ligado a esse Cluster como o seu Hub.

  • Problema 38682:

    Um VMware SD-WAN Edge que atua como um servidor DHCP numa interface ativada por DPDK pode não gerar corretamente eventos de “Novo dispositivo de cliente” para todos os clientes ligados.

  • Problema 38767:

    Quando um overlay WAN que tenha túneis GRE configurados para o Zscaler é alterado da deteção automática para definido pelo utilizador, os túneis obsoletos podem permanecer até ao próximo reinício.

    Solução alternativa: reinicie o Edge para limpar o túnel obsoleto.

  • Problema 39134:

    A estatística de estado de funcionamento do Sistema “Percentagem de CPU” (CPU Percentage) pode não ser comunicada corretamente em Monitorizar > Edge > Sistema (Monitor > Edge > System) para o VMware SD-WAN Edge e em Monitorizar > Gateways (Monitor > Gateways) para o VMware SD-WAN Gateway.

    Solução alternativa: os utilizadores devem utilizar as Handoff Queue Drops para monitorizar a capacidade do Edge e não a percentagem de CPU.

  • Problema 39608:

    A saída do “Teste de Ping” (Ping Test) de Diagnóstico Remoto pode apresentar brevemente conteúdos inválidos, antes de apresentar os resultados corretos.

  • Problema 39624:

    O ping através de uma subinterface pode falhar quando a interface principal estiver configurada com PPPoE.

  • Problema 39753:

    A desativação da VPN Ramo-a-Ramo Dinâmica pode fazer com que os fluxos existentes que estão atualmente a ser enviados utilizando Ramo-a-Ramo Dinâmica sejam atrasados.

  • Problema 40096:

    Se um VMware SD-WAN Edge 840 ativado for reiniciado, existirá possibilidade de um módulo SFP ligado ao Edge parar de passar o tráfego, mesmo que as luzes de ligação e o VMware SD-WAN Orchestrator indiquem a porta como “ATIVA” (UP).

    Solução alternativa: desligue o módulo SFP e, em seguida, volte a ligá-lo na porta.

  • Problema 40421:

    O Traceroute não está a apresentar o caminho quando passa através de um VMware SD-WAN Edge com uma interface configurada como uma porta comutada.

  • Problema 42872:

    Ativar o Isolamento de Perfil num perfil de Hub onde um cluster de Hub está associado não revoga os caminhos do Hub na base de informações de routing (RIB).

  • Problema 43373:

    Quando o mesmo caminho BGP é aprendido a partir de vários VMware SD-WAN Edges, se este caminho for movido da saída preferencial para a saída elegível no Controlo de fluxo de overlay, o Edge não será removido da lista de anúncios e continuará a ser anunciado.

    Solução alternativa: Ative o cálculo de custos distribuídos no VMware SD-WAN Orchestrator.

  • Problema 44526: Numa empresa onde dois sites diferentes implementam os seus VMware SD-WAN Edges como Hubs, ao mesmo tempo que utilizam uma topologia de alta disponibilidade, e cada site utiliza o outro site do Hub como um Hub no seu perfil, se um dos sites do Hub desencadear uma recuperação automática HA, pode demorar até 30 minutos para ambos os Hub Edges restabelecerem os túneis entre si.

    Numa recuperação automática HA, ambos os Hub Edges tentam iniciar um túnel entre si ao mesmo tempo e nenhum responde ao par, a troca de pacotes entre ambos os Hubs ocorre, mas o IKE nunca se sucede. Isto leva a um impasse que se verificou demorar até 30 minutos para se resolver por si só. O problema é intermitente e não ocorre após cada recuperação automática HA.

    Solução alternativa: para evitar que este problema ocorra, o cliente deve configurar apenas um dos dois sites do Hub de HA para utilizar o outro site do Hub como um Hub para si mesmo. Por exemplo, se existirem dois sites do Hub de HA, o Hub1 e o Hub2, o Hub1 pode ter o Hub2 como Hub para si no seu perfil, mas o Hub2 não deve utilizar o Hub1 como Hub no seu perfil.

  • Problema 45302:

    Num cluster do VMware SD-WAN Hub, se um Hub perder durante mais de 5 minutos a conetividade a todos os VMware SD-WAN Gateways comuns entre si e os seus Spoke Edges atribuídos, os Spokes poderão, em condições raras, ser incapazes de manter os caminhos do hub após 5 minutos. A questão resolve-se sozinha quando o Hub recupera o contacto com os Gateways.

  • Problema 46053:

    A preferência do BGP não é corrigida automaticamente para caminhos de overlay quando o seu vizinho é alterado para um vizinho de vínculo superior.

    Solução alternativa: um reinício do serviço Edge corrigirá este problema.

  • Problema 42278:

    Para um tipo específico de configuração de par, o VMware SD-WAN Gateway pode enviar continuamente mensagens de iniciação de IKE a um par Não-SD-WAN. Este problema não perturba o tráfego do utilizador para o Gateway; no entanto, os registos do Gateway serão preenchidos com erros IKE e isso poderá ocultar entradas de registo úteis.

  • Problema 42388:

    Num VMware SD-WAN Edge 540, uma porta SFP não é detetada após desativar e ativar novamente a interface no VMware SD-WAN Orchestrator.

  • Problema 42488:

    o tráfego pode ser colocado numa condição de buraco negro para o caminho ligado para interfaces do VMware SD-WAN Edge que não têm uma ligação. Se a ligação numa porta do Edge for removida e a interface não for desativada, o Edge não revogará o caminho do Gateway, fazendo com que outros Edges encaminhem o tráfego para o Edge sem ligação.

    Solução alternativa: desative a interface se não existir nenhuma ligação.

  • Problema 44995:

    Os caminhos OSPF não são revogados a partir do VMware SD-WAN Gateway e dos Spoke Edges do VMware SD-WAN quando os caminhos são retirados do Cluster de Hub.

  • Problema 45189:

    Com o NAT do lado LAN de origem configurado, o tráfego de um Edge Spoke do VMware SD-WAN para o Edge Hub é permitido mesmo sem a configuração de caminho estático para a sub-rede NAT.

  • Problema 46216: Em Destinos Não-SD-WAN via Gateway ou Edge, em que o par é uma instância AWS, quando o par inicia a Fase-2 de recodificação, a Fase-1 do IKE também é eliminada e força uma recodificação. Isto significa que o túnel é desmontado e reconstruído, provocando a perda de pacotes durante a reconstrução do túnel.

    Em Destinos Não-SD-WAN via Gateway ou Edge, em que o par é uma instância AWS, quando o par inicia a Fase-2 de recodificação, a Fase-1 do IKE também é eliminada e força uma recodificação. Isto significa que o túnel é desmontado e reconstruído, provocando a perda de pacotes durante a reconstrução do túnel.

    Solução alternativa: para evitar a destruição do túnel, configure os Destinos Não-SD-WAN via Gateway/Edge ou o temporizador de recodificação IPsec CSS para menos de 60 minutos. Isto impede que o AWS inicie a recodificação.

  • Problema 46391:

    Para um VMware SD-WAN Edge 3800, as interfaces SFP1 e SFP2 têm problemas com os SFPs multitaxa (isto é, 1/10G) e não devem ser utilizadas nessas portas.

    Solução alternativa: Utilize SFPs de taxa única de acordo com o artigo BDC Lista de módulos SFP suportados por VMware SD-WAN (79270). Os SFPs multitaxa podem ser utilizados com SFP3 e SFP4.

  • Problema 47681:

    Quando um anfitrião no lado LAN de um VMware SD-WAN Edge utiliza o mesmo IP que a interface WAN do Edge, a ligação do anfitrião LAN para a WAN não funciona.

  • Problema 47355:

    Quando o mesmo caminho é aprendido através do BGP de underlay local, do Hub BGP e/ou estaticamente configurado no Gateway de parceiro, a sequência de ordenação dos caminhos é a incorreta, com o Hub BGP a ter preferência sobre o BGP de underlay.

  • Problema 48530:

    Os modelos do VMware SD-WAN Edge 6x0 não realizam a negociação automática para a velocidade tripla (10/100/1000 Mbps) dos SFPs de cobre.

    Solução alternativa: o Edge 520/540 suporta SFPs de cobre de velocidade tripla, mas este modelo foi assinalado para Fim de Venda até ao 1.º trimestre de 2021.

  • Problema 48597:

    A vizinhança BGP multihop não permanece ativa se um dos dois caminhos para o par ficar inativo. Se existir uma vizinhança BGP multihop com um par para o qual existem vários caminhos e um deles ficar inativo, o utilizador notará que a vizinhança BGP fica inativa e não será ativada com outros caminhos disponíveis. Isto inclui também o caso de vizinhança de retorno de IP local.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 50518:

    Num VMware SD-WAN Gateway onde o PKI está ativado, se mais de 6000 túneis PKI tentarem ligar-se ao Gateway, os túneis poderão não surgir todos devido aos SAs de entrada não serem eliminados.

    Nota: os túneis que utilizam a autenticação de chave pré-partilhada (PSK) não têm este problema.

  • Problema 51428:

    Podem ser observadas perdas de tráfego multicast num site onde o VMware SD-WAN Edge tem uma subinterface configurada com PIM. Quando uma subinterface configurada com PIM é rapidamente movida de um segmento para outro, o pimd (o processo que gere o PIM) pode reiniciar e o site pode sofrer uma perda de tráfego multicast intermitente.

    Solução alternativa: desative primeiro a subinterface e, em seguida, mova a subinterface para outro segmento. Uma vez movida, reative-a.

  • Problema 52955:

    A recusa DHCP não é enviada a partir do Edge e o reenlace do DHCP não é reiniciado após a falha do DAD no DHCP Dinâmico. Se o servidor DHCPv6 atribuir um endereço que é detetado como duplicado pelo kernel durante uma verificação DAD, o cliente DHCPv6 não enviará nenhuma recusa. Isto levará a tráfego ignorado, uma vez que o endereço de interface será assinalado como verificação DAD falhada e não será utilizado. Esta ação não levará a nenhum ciclo de tráfego na rede, mas será observado um bloqueio de tráfego.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 53147:

    os valores limite de hop não predefinidos anunciados nos anúncios do router não são cumpridos pelo VMware SD-WAN Edge. O valor limite de hop do túnel está sempre definido como 64. O valor predefinido do limite de hop é 64. Se desejar ter um valor de limite de hop não predefinido anunciado através de anúncios do router, o Edge não processará os campos de limite de hop no pacote e os valores permanecem em 64.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 53219: Após um reequilíbrio do cluster do VMware SD-WAN Hub, alguns Spoke Edges podem não ter a interface RPF/IIF com a definição correta.

    Nos Spoke Edges afetados, o tráfego multicast será afetado. O que acontece é que depois de um reequilíbrio do cluster, alguns dos Spoke Edge não enviam uma junção PIM.

    Solução alternativa: este problema persistirá até que o Edge Spoke afetado reinicie o Serviço Edge.

  • Problema 53337:

    os pacotes ignorados podem ser observados numa instância do AWS de um VMware SD-WAN Gateway quando o débito é superior a 3200 Mbps. Quando o tráfego excede um débito superior a 3200 Mbps e um tamanho de pacote de 1300 bytes, são observados pacotes ignorados no handoff do IPv4 BH e RX.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 53687:

    quando um VMware SD-WAN Spoke Edge prefere um túnel IPv6/v4, a MTU dos túneis v4/v6 não preferenciais também vai influenciar a MTU que é vista nos túneis preferenciais. Um Edge (Spoke ou Hub) mantém uma MTU de nível de sistema, que é o mínimo de todas as MTU de ligação e esta MTU é trocada como a MTU anunciada. Dado que uma MTU de ligação não preferencial ainda pode ser considerada para determinação da MTU de nível do sistema, pode ser anunciada uma MTU inferior e, em seguida, a MTU de caminho real.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 53830: Num VMware SD-WAN Edge, alguns dos caminhos na vista BGP podem não ter a preferência correta e anunciar valores quando o sinalizador DCC está ativado provocando uma sequência de ordenação incorreta no FIB do Edge.

    Quando o Cálculo de custos distribuídos (DCC) é ativado num cenário à escala com um grande número de caminhos num Edge, ao analisar o pacote de diagnóstico do Edge para o registo bgp_view alguns dos caminhos podem não ser corretamente atualizados com os valores de preferência e anúncio. Este problema, caso seja encontrado, pode potencialmente ser encontrado em alguns Edges que fazem parte de uma grande empresa (mais de 100 Spoke Edges ligados a Edges Hub ou Clusters de Hub).

    Solução alternativa: Este problema pode ser corrigido reaprendendo os caminhos BGP de underlay ou executando a opção “Atualizar” (Refresh) na página OFC do VMware SD-WAN Orchestrator para os caminhos afetados. Tenha em atenção que ao realizar a “Atualização” (Refresh) de um caminho vai reaprender os caminhos de todos os Edges na empresa.

  • Problema 53934: Numa empresa onde está configurado um cluster do VMware SD-WAN Hub, se o Hub principal tiver uma vizinhança BGP multihop no lado LAN, o cliente poderá sofrer situações de tráfego ignorado num Spoke Edge quando existe uma falha do lado LAN ou quando o BGP está desativado em todos os segmentos.

    Num cluster de Hub, o Hub principal tem a vizinhança BGP multihop com um dispositivo de par para aprender caminhos. Se a interface física no Hub, através da qual a vizinhança do BGP é estabelecida, ficar inativa, os caminhos da BGP LAN não poderão ser zero, apesar da vista BGP estar vazia. Isto pode fazer com que o reequilíbrio do Cluster de Hub não ocorra. O problema também pode ser observado quando o BGP é desativado para todos os segmentos e quando existe uma ou mais vizinhanças BGP multihop.

    Solução alternativa: reinicie o Hub que teve a falha do lado da LAN (ou BGP desativado).

  • Problema 54099: Os pacotes IPv6 fragmentados serão ignorados pelo VMware SD-WAN Edge.

    Os pacotes IPv6 fragmentados ser ignorados pelo Edge.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 54378: A verificação de deteção de endereço duplicado (DAD) da interface ativada de endereço estático IPv6 falha devido a um NA ignorado.

    A verificação DAD de endereço estático não ocorrerá e, se existir um endereço duplicado na rede para os endereços estáticos configurados, este não será detetado.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 54536: A verificação da deteção de endereços duplicados (DAD) não é ativada após um reinício do VMware SD-WAN Edge.

    Se existir um endereço duplicado na rede, não será detetado se esta verificação DAD não for realizada após o reinício.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 54687: a mensagem de solicitação DHCPv6 não é enviada por um VMware SD-WAN Edge após ser proporcionada ao servidor uma configuração de valores T1 superiores a T2.

    Se um servidor DHCPv6 fornecer inicialmente um valor T1 superior ao valor de T2, o Edge não aceitará o prefixo fornecido, mas mesmo depois desta configuração ter sido corrigida no servidor, o Edge não enviará nenhuma mensagem de solicitação DHCPv6 após três tentativas. Neste ponto, só quando o Serviço dataplane Edge é reiniciado é que o problema será eliminado.

    Solução alternativa: reinicie o serviço Edge.

  • Problema 54731: as mensagens de renovação são enviadas com uma elevada frequência até que seja atingido o tempo de reenlace (t2) quando um utilizador altera o valor do intervalo de endereços IPv6 no servidor.

    Quando um endereço IP que foi atribuído a um VMware SD-WAN Edge é removido do intervalo válido de endereços fornecidos por um servidor, o cliente continua a enviar mensagens de renovação para o servidor até que o tempo T2 seja alcançado. Isto pode resultar num utilizador cliente observar uma grande quantidade de tráfego DHCPv6.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 56454: quando configura ligações IPv4 e IPv6 como ligações de deteção automática numa interface e, em seguida, tem túneis formados através da ligação não preferencial. As estatísticas de ligação não apresentam informações consolidadas de uma ligação IPv4 e IPv6.

    Quando uma interface tem sobreposições IPv4 e IPv6 configuradas como túneis e sobreposições de deteção automática formadas através de ambas as ligações, as estatísticas das ligações refletem apenas o estado da ligação preferencial. As informações de tráfego ou o estado da ligação não preferencial não são corretamente refletidas. Como resultado, as estatísticas observadas para a ligação na página Edge > Monitorização (Edge > Monitoring), que incluem a largura de banda e o débito, devem ser utilizadas como uma diretriz para medir o desempenho dos túneis formados apenas através da família de endereços IP preferidos.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 57957: Se uma interface DPDK for alterada de Autonegociar=ligado (Autonegotiate=on) para Autonegociar=desligado (Autonegotiate=off), o Edge descarregará o controlador KNI e carregará o controlador Linux para essa interface durante a sequência de reinício do Serviço do Edge (a partir de vc_dpdk.py).

    Após carregar a nova interface Linux e dar-lhe o nome, vc_dpdk.py, também será necessário invocar “set_interface_neg.py” para aplicar as definições de negociação automática. No entanto, devido às novas definições de negociação automática e ao controlador de Linux ser recarregado, a interface de base já não está sob o controlo do DPDK.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 59970: o cliente observará a queda de tráfego de um VMware SD-WAN Edge para o centro de dados através de um Zscaler IaaS ao mudar de um gateway primário para um secundário.

    Quando o Gateway principal fica inativo e o Orchestrator muda para o Gateway secundário, o fluxo de tráfego atual inverte o caminho de um Nó de Imposição do Zscaler (ZEN) e não funciona.

    Solução alternativa: a solução alternativa seria reiniciar todo o fluxo de tráfego. O Zscaler é notificado sobre este problema e é confirmado que o caminho do tráfego inverso não está a funcionar corretamente do seu lado.

  • Problema 61882: Quando for efetuada uma alteração à configuração do parâmetro de segurança (por exemplo, alteração do tempo de vida de SA) no VMware SD-WAN Orchestrator, o cliente poderá observar tráfego ignorado durante um certo período de tempo.

    Isto foi visto numa implementação em larga escala com mais de 1000 Edges numa topologia Hub/Spoke. Se os parâmetros de segurança (tempo de vida, algoritmos de criptografia, modo de autenticação) forem alterados, os túneis atuais serão desatualizados e posteriormente recriados. Numa implementação em larga escala, pode levar a problemas com a estabilidade do tráfego. O lado do dispositivo de resposta (Edge Hub) pode não ser capaz de lidar com todos os túneis a tempo e isto pode levar a que o tráfego seja ignorado. Eventualmente, os túneis serão estabelecidos, mas pode demorar algum tempo com base no número de túneis existentes.

    Solução alternativa: recomenda-se a realização de alterações à configuração numa janela de manutenção, dado que o tempo de recuperação é desconhecido com base no número de túneis existente.

  • Problema 62685: Se o NAT do lado LAN estiver configurado com o mesmo IP externo para diferentes sub-redes LAN com tipo NAT como origem, o tráfego destinado à Cloud não funcionará.

    Para o IP externo utilizado nas regras NAT do lado LAN, configuramos um caminho estático e anunciamo-lo nos ramos remotos. Para que o tráfego de retorno seja encaminhado para a sub-rede LAN correta, a pesquisa de caminho deve ser realizada com base no IP Interno configurado na regra NAT do lado LAN em vez do próximo hop no caminho estático. Mas para o tráfego de retorno na cloud, a pesquisa de caminho é realizada com base no próximo hop no caminho estático e o tráfego pode ser encaminhado para a sub-rede LAN errada.

    Solução alternativa: utilize um IP externo diferente para sub-redes LAN diferentes.

  • Problema 62701: Para um VMware SD-WAN Edge implementado como parte de um cluster de Edge Hub, se a VPN de cloud não estiver ativada no segmento global, mas estiver ativada num segmento não global, uma atualização do plano de controlo enviada pelo Orchestrator pode fazer com que todas as ligações WAN fiquem instáveis no Edge Hub.

    As ligações WAN do Edge Hub que fiquem inativas e, em seguida, ativas numa sucessão rápida (instabilidade) afetam o tráfego em tempo real, como chamadas de voz. Este problema foi observado numa implementação de clientes em que a VPN de cloud não estava ativada no segmento global do Edge Hub, mas a configuração do cluster estava ativada, o que significa que este Edge Hub fazia parte de um cluster (e a configuração de um cluster é aplicável a todos os segmentos). Quando uma alteração da configuração é emitida para o Edge Hub, o dataplane do Edge Hub inicia a análise dos dados e começa com o segmento global, onde verá que a VPN de cloud não está ativada, e o Edge Hub assume erradamente que o clustering está desativado neste segmento global. Como resultado, o Edge Hub derruba todos os túneis das ligações WAN do Hub, o que provoca instabilidades de ligação em todas as ligações WAN desse Edge. Para qualquer incidente deste tipo, as ligações WAN só ficam inativas e recuperam uma vez por atualização do plano de controlo.

    A causa principal deste problema continua sob investigação.

    Solução alternativa: A solução alternativa é ativar a VPN de cloud em todos os segmentos, o que implica o segmento global e todos os segmentos não globais.

  • Problema 62725: Um VMware SD-WAN Edge numa rede que utilize o BGP pode sofrer uma utilização elevada de memória em determinadas condições raras.

    Se um Edge aprender um caminho BGP com um endereço IP de próximo hop, que é diferente do endereço IP de par, o próximo hop será rastreado quanto a acessibilidade pelo módulo de Rastreamento de próximo hop (NHT) do Edge. em seguida, se o BGP for desativado quando o endereço IP rastreado estiver inacessível no Edge, o NHT rastreado não poderá ser eliminado. Nos casos raros em que existem muitas entradas NHT obsoletas, pode ser observada uma elevada utilização da memória do Edge.

    Solução alternativa: reinicie o Edge para eliminar as entradas NHT com fugas de memória.

  • Problema 62897: O comando de depuração tcpdump não funciona corretamente num VMware SD-WAN Gateway.

    Execute o comando tcpdump na interface eth0 ou eth1 do Gateway. A saída não está correta. tcpdump.sh e vctcdump também não estão a funcionar. Foi tentada uma correção, em que é adicionado um perfil de reclamação AppArmor para vctcpdump (com base no perfil tcpdump) que permite ao tcpdump herdar o confinamento de vctcpdump, mas o tcpdump ainda não está a funcionar. Essencialmente, o AppArmor faz com que o Stdout deixe de funcionar para tcpdump. Este é um problema conhecido com o AppArmor.

    Solução alternativa: “pipe tcpdump output to cat., por exemplo, tcpdump -nnplei eth0 | cat”

  • Problema 63125: Quando a MTU é aumentada para qualquer interface/ligação num VMware SD-WAN Hub Edge, esta não será refletida na MTU de caminho no Spoke Edge (para caminhos com esse Edge Hub).

    Se o utilizador aumentar a MTU de uma interface ou ligação num Hub, o caminho do Spoke Edge não captará a definição da MTU alterada.

    Solução alternativa: reinicie o Edge Spoke, a MTU aumentada será refletida na MTU de caminho no Spoke.

  • Problema 65885: Para um cliente que tenha implementado um Destino Não-SD-WAN (NSD) via Gateway e que esteja a utilizar uma configuração de Gateway redundante, se o Gateway principal ficar inativo, ocorrerá uma condição race em que antes de o intercâmbio de PG-BGP no Gateway principal surgir, o NSD já anunciará as rotas antigas aprendidas através do Gateway redundante para o Gateway principal.

    Uma vez que não são suportados multicaminhos do BGP, a rota que o Gateway principal deveria aprender através da interface de handoff parece ser aprendida como centro de dados do NSD. Apesar de estes caminhos serem válidos, isto não deveria acontecer, uma vez que o tráfego deve passar por NSD > Gateway principal > Interface de handoff (NSD > Primary Gateway > Handoff Interface) quando o Gateway principal está ativo. O impacto para o cliente não é em termos de desempenho, uma vez que o tráfego ainda chega ao destino, mas tem um impacto negativo na gestão de rede do cliente. O cliente espera que o tráfego chegue através de um caminho e instalará políticas de QoS para o gerir, mas o tráfego está a passar por outro caminho não esperado na política de QoS.

    Solução alternativa: o cliente deve filtrar os caminhos de saída no Destino Não-SD-WAN via Gateway para que este não anuncie um caminho aprendido através de um Gateway redundante para um Gateway principal.

  • Problema 67458: Quando um VMware SD-WAN Hub Edge com um grande número de Edges Spoke é atualizado para a versão 4.2.1 ou posterior, alguns túneis para outros Edges Spoke não aparecerão para o Edge Hub.

    Entende-se por um grande número de Edges Spoke ~1000 ou mais. Este problema não é consistente, mas, geralmente, ~1/3 dos túneis do Protocolo de gestão do VeloCloud (VCMP) não são estabelecidos entre o Edge Hub e os Edges Spoke ligados. Isto é causado pelo Hub Edge ignorar o MP_INITs dado que o número de TDs meio abertos excede o limite superior do Edge Hub.

    Solução alternativa: o reinício do Serviço Edge restabelecerá a conetividade total do túnel.

  • Problema 75668: a etiqueta DSCP é reposta para o tráfego do lado da LAN quando é encaminhado para um destino de LAN interno.

    Para o tráfego de utilizador encaminhado/direto, o Edge repõe a etiqueta DSCP para 0 e o tráfego que entra e sai no mesmo Edge (ou seja, permanece local para o Edge) tem a etiqueta DSCP modificada para uma marcação de CSP=0DSCP e é reposto para CS0 para tráfego de underlay quando percorre o Edge.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 76292: Um VMware SD-WAN Edge configurado como um Spoke não prefere um caminho de transmissão com o melhor atributo BGP mesmo depois de formar um túnel dinâmico.

    Um cliente poderá ser afetado por este comportamento se o caminho de transmissão através de um túnel dinâmico for utilizado para encaminhar o tráfego. Nesse caso, não funcionará e todo o tráfego deste caminho será encaminhado para o Hub.

    A ideia subjacente aos caminhos de transmissão era criar um caminho especial para fugir do Edge Hub, e não ser utilizados em qualquer outro caso. Estes são os caminhos externos que o VMware SD-WAN não pretende anunciar como outros caminhos VCRP. Estes devem ser anunciados pelos Hubs aos respetivos Spokes, o que significa apenas através de túneis estáticos.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 76837: Um cliente que utilize o BGP pode observar que um router de pares não está a enviar tráfego para um VMware SD-WAN Edge na respetiva rede.

    A resolução do problema revelaria que o caminho predefinido através da origem predefinida não está a ser anunciado pelo Edge. O problema é provocado pelo truncamento de uma cadeia de mapas de caminhos associada ao caminho predefinido e, assim, o Edge não corresponde ao caminho predefinido em nada no respetivo mapa de caminhos, o que faz com que router de pares elimine o tráfego ou envie o mesmo com um caminho inválido onde o tráfego é adicionado à lista negra.

    Solução alternativa: O utilizador terá de configurar um caminho estático no router de pares para o caminho predefinido até ser possível atualizar para uma versão do Edge que inclua a correção.

  • Problema 79220: Num site implementado com uma topologia de alta disponibilidade, o cliente pode observar vários reinícios do VMware SD-WAN do Edge em standby com uma potencial disrupção do tráfego do cliente.

    Uma enchente de eventos do Edge Ativo para o Edge em standby pode sobrecarregar alguns threads no Edge em standby, o que iria atrasar o processamento do heartbeat e leva a que o Edge em standby seja incorretamente promovido a Ativo. Num estado ativo-ativo, o tie-break vai para o Edge ativo e o Edge em standby é reiniciado para o despromover de volta ao seu estado rm standby adequado. Quando este problema é encontrado numa topologia HA convencional, o impacto no cliente deverá ser mínimo, dado que o Edge em standby não está a passar o tráfego do cliente. Numa implementação HA melhorada, onde o Edge em standby também está a passar tráfego, os reinícios perturbarão algum tráfego do cliente.

    Neste pedido, foram realizadas algumas otimizações ao Edge para processar eventos de forma mais eficiente a partir dos Edges em standby e Edges ativos, para minimizar o número de eventos, ao impedir que alguns eventos inválidos sejam sincronizados de Ativo para Em standby.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 85156: Num site implementado com uma topologia de alta disponibilidade, o cliente pode observar vários reinícios do VMware SD-WAN do Edge em standby com uma potencial disrupção do tráfego do cliente.

    A lógica de processamento de sincronização de dados de controlo HA no Edge em standby para os dados recebidos através de TCP pode levar a que os dados só sejam lidos parcialmente. Isto pode fazer com que estas mensagens curtas sejam processadas no modo em standby, o que tornar mais lento o nó em standby. Nas plataformas Edge no limite inferior (por exemplo, modelos Edge 510, 520, 610 e 620), esta lentidão pode ter um impacto significativo no processamento heartbeat entre Ativo e Em standby, o que leva ao Edge em standby a ser incorretamente promovido a Ativo. Num estado ativo-ativo, o tie-break vai para o Edge ativo e o Edge em standby é reiniciado para o despromover de volta ao seu estado rm standby adequado. Quando este problema é encontrado numa topologia HA convencional, o impacto no cliente deverá ser mínimo, dado que o Edge em standby não está a passar o tráfego do cliente. Numa implementação HA melhorada, onde o Edge em standby também está a passar tráfego, os reinícios perturbarão algum tráfego do cliente. 

    Este pedido adiciona melhorias à lógica de processamento da mensagem TCP do Edge, para melhorar o desempenho no Edge em standby e evitar a lentidão do sistema.

    Solução alternativa: não existe uma solução alternativa para este problema.

  • Problema 86994: Numa empresa cliente em que Ramo a ramo dinâmico (Dynamic Branch to Branch) está ativado, quando tenta resolver problemas num VMware SD-WAN Edge nesta empresa, o comando de depuração dispcnt não funciona.

    O comando de depuração dispcnt não fornece todos os valores de contador e falha com o erro Domain (null) does not exist. Isto também falha quando se refere aos registos relevantes num pacote de diagnóstico do Edge. Esta situação dificulta significativamente a resolução de problemas de um problema de rede de um cliente.

    Este problema ocorre em empresas nas quais Ramo a ramo dinâmico (Dynamic Branch-to-Branch) está ativado devido à grande quantidade de túneis que são criados e removidos para cada par. Os contadores para armazenamento de várias métricas de pares são guardados numa memória partilhada e, com o decorrer do tempo, estes segmentos de memória partilhada ficam em mau estado devido a uma colisão e ao facto de os contadores não serem obtidos através do comando dispcnt.

    Solução alternativa: Este problema só pode ser eliminado realizando um reinício de serviço do Edge afetado.

  • Problema 89217: Um VMware SD-WAN Edge na linha de modelo 6x0 (610, 610N, 610-LTE, 620, 620N, 640, 640N, 680, 680N) pode desligar-se subitamente sem motivo.

    O 6x0 Edge teria todas as luzes apagadas, incluindo o LED de estado frontal e as luzes traseiras da porta Ethernet, e só pode ser recuperado através de um arranque manual do Edge.

    A causa do problema tem origem num microcontrolador PIC, exclusivo da linha Edge 6x0, que utiliza a versão de firmware de PIC de v20M ou anterior (v20L, v20K, v20J). Este problema só pode ocorrer quando o Edge 6x0 utiliza uma versão de PIC de v20M ou anterior. Contudo, mesmo com esta versão, as probabilidades de se deparar com o problema de desligamento são raras (aproximadamente 1/1000). O problema não pode ocorrer num Edge 6x0 com uma versão de firmware de PIC de v20N ou posterior.

    é possível determinar um firmware Edge 6x0 que inclua a versão de PIC num Orchestrator que utilize 5.x ao aceder à página Monitor > Edge > Visão geral(Monitor > Edge > Overview) desse Edge e clicar na caixa de informações pendente ao lado do nome do Edge que inclui as Informações do Edge, a Versão do Dispositivo e o Firmware do Dispositivo. No entanto, funciona apenas em Edges que utilizem a versão 4.5.1.

    O problema resolve-se através da atualização do Edge 6x0 para o firmware de plataforma 1.3.1 (R131-20221216-GA), que inclui a versão de PIC v20N. Para isso, o Edge 6x0 tem de ser ligado a um VMware SASE Orchestrator com a versão 5.x (5.0.0 ou posterior) e tem primeiro de atualizar o Edge 6x0 para a compilação de correção do Edge R5012-20230123-GA-103475. Quando atualizar o Edge 6x0 para R5012-20230123-GA-103475, o utilizador deverá atualizar o firmware de plataforma do Edge 6x0 para a versão R131-20221216-GA da mesma forma que uma versão de software do Edge é modificada.

    Para obter mais informações e um guia passo a passo para atualizar um Edge 6x0 para o firmware da plataforma 1.3.1, consulte o artigo da BDC: Os VMware SD-WAN Edges do modelo 6X0 podem desligar-se sem LEDs e exigir um ciclo de energia para voltarem a um estado funcional (88970). Este artigo da BDC foi atualizado a 27 de janeiro de 2023 para refletir o novo software do Edge e da plataforma necessário para resolver o problema.

    Para obter informações sobre como carregar um pacote de firmware de plataforma para um Orchestrator, consulte a secção Imagens de firmware da plataforma e de fábrica com a nova IU do Orchestrator do Guia do Operador do VMware SD-WAN.

    Para obter informações sobre como atualizar o firmware de plataforma de um Edge 6x0, consulte a secção Ver ou modificar as informações do Edge do Guia de Administração do VMware SD-WAN.

    Solução alternativa: para recuperar o Edge do estado problemático:

    1. Desligue o Edge da fonte de alimentação.

    2. Espere 20 segundos.

    3. Volte a ligar o Edge à fonte de alimentação.

    Se não pretender atualizar o firmware da plataforma, o utilizador poderá garantir que a energia para o Edge é consistente e não apresentará instabilidade rápida ou consistente. Uma boa forma de garantir uma fonte de energia fiável é ligar o Edge 6x0 a uma fonte de alimentação ininterrupta (UPS).

    Se o utilizador preferir manter o Edge numa versão de software mais baixa (por exemplo, versão 4.3.1 ou 4.5.1), o cliente poderá atualizar temporariamente o Edge para R5012-20230123-GA-103475, atualizar o firmware da plataforma para a versão 1.3.1 (R131-20221216-GA), para que a versão do PIC seja v20N, e mudar para uma versão anterior preferida do software do Edge. A mudança do software do Edge 6x0 para uma versão anterior não muda a versão do firmware da plataforma do Edge para uma versão anterior e o Edge continuará a utilizar a versão de firmware da plataforma 1.3.1. Neste caso de utilização, os Edges do cliente teriam de estar num Orchestrator que utilizasse a versão 5.x.

    Se o Edge 6x0 estiver num Orchestrator que não suporte a utilização da versão 5.x e tenha sofrido este problema e o respetivo firmware de PIC tiver de ser atualizado, o cliente poderá contactar o Suporte VMware SD-WAN, que atualizará manualmente a versão de PIC do Edge.

  • Problema 92676: numa implementação de cliente na qual um Destino Não VMware SD-WAN (NSD) via Gateway esteja configurado para utilizar túneis e Gateways redundantes e também esteja a utilizar BGP através de IPsec, caso os Gateways principais e secundários anunciem um prefixo com um caminho AS igual ao dos túneis NSD principais e secundários, o túnel NSD principal irá preferir um caminho do Gateway redundante em vez do Gateway principal.

    O impacto de o túnel NSD principal via Gateway preferir o caminho do Gateway redundante em vez do Gateway principal só é sentido para o tráfego de retorno do NSD para o Gateway.

    Solução alternativa: configure uma métrica mais alta (3 ou mais) no Gateway redundante para o prefixo interessado, pois tal ajudará o túnel principal do NSD a escolher o Gateway principal para o tráfego de retorno.

  • Problema 97041: uma empresa de cliente que utiliza uma configuração BGP multi-hop pode experienciar uma instabilidade do caminho BGP após modificar um filtro de saída.

     Um exemplo de um BGP multi-hop seria aquele em que o BGP é estabelecido com um router MPLS. Depois de um filtro de saída ser modificado e de as alterações serem guardadas, um utilizador observaria que a sessão BGP ficou inativa e que todos os caminhos têm de ser reconstruídos, causando uma interrupção do tráfego do cliente.

    Solução alternativa: para evitar uma interrupção do tráfego do cliente, modifique os filtros de saída BGP apenas durante uma janela de manutenção.

  • Problema 97559: No site de um cliente implementado com uma topologia de alta disponibilidade melhorada, uma ligação WAN ligada ao VMware SD-WAN Edge numa função Em espera pode aparecer como inativa no VMware SASE Orchestrator e não transmitir o tráfego do cliente, mesmo que a interface WAN do Edge onde a ligação WAN está ligada esteja ativa.

    Um utilizador que analisasse um tcpdump ou o registo de um pacote de diagnóstico observaria pedidos de ARP a chegar e o Edge em espera a não responder, como resultado do bloqueio da respetiva porta.

    Na HA melhorada, quando um Edge assume a função Em espera, devem ocorrer os seguintes eventos nesta sequência:

    1. O Edge em espera bloqueia todas as portas.

    2. O Edge em espera deteta que está implementado numa topologia de HA melhorada e desbloqueia as respetivas portas WAN para transmitir o tráfego.

    Quando este problema ocorre, Evento 1, o bloqueio inicial das portas demora inesperadamente muito tempo a ser concluído e o Evento 2 seguinte, o desbloqueamento de todas as portas WAN, é concluído antes da conclusão do Evento 1. Em seguida, o Evento 1 é concluído e, assim, o estado final é que todas as portas WAN estão bloqueadas no Edge em espera.

    Solução alternativa: Uma recuperação pós-falha de HA que promove o Edge em espera para ativo ativará as ligações WAN do Edge de HA.

  • Problema 101703: para um site de cliente com uma topologia de alta disponibilidade melhorada, quando um overlay WAN definido pelo utilizador é configurado com um endereço IP de origem personalizado numa subinterface ativada por DHCP, o endereço IP público mostra um valor de zero, embora o túnel associado a esta subinterface seja estável.

    O problema resulta de uma condição de corrida que pode ocorrer entre a atribuição de DHCP e a criação de caminhos e o endereço IP público é colocado a zeros, embora o túnel permaneça estável.

    Solução alternativa: não existe uma solução alternativa para este problema.

Problemas conhecidos do Orchestrator

  • Problema 19566:

    Após a recuperação automática da Alta Disponibilidade, o número de série do VMware SD-WAN Edge em espera pode ser apresentado como o número de série ativo no Orchestrator.

  • Problema 21342:

    Ao atribuir Gateways de parceiro por segmento, a lista correta de Atribuições de Gateway pode não aparecer na opção “Ver” (View) Gateways do Operador na lista de monitorização do VMware SD-WAN Edge.

  • Problema 24269:

    Monitorizar > Transportar > Perda não representada em gráficos (Monitor > Transport > Loss not graphing) – foi observada uma perda da ligação WAN enquanto os gráficos QoE refletiram esta perda.

  • Problema 25932:

    O VMware SD-WAN Orchestrator permite que os VMware SD-WAN Gateways sejam removidos do Conjunto de Gateways mesmo quando estão a ser utilizados.

  • Problema 32335:

    A página “Acordo de Serviços do Utilizador Final” (EUSA) (End User Service Agreement (EUSA)) apresenta um erro quando um utilizador está a tentar aceitar o acordo.

    Solução alternativa: certifique-se de que não existem espaços iniciais ou finais no nome da empresa.

  • Problema 32435:

    É permitida uma sobreposição de VMware SD-WAN Edge para uma configuração NAT baseada em políticas para cadeias de identificação que já estão configuradas ao nível do perfil e vice-versa.

  • Problema 32856:

    Embora a política empresarial esteja configurada para utilizar um cluster de Hub para realizar o backhaul do tráfego de Internet, o utilizador pode desmarcar o cluster de Hub de um perfil num VMware SD-WAN Orchestrator que foi atualizado da versão 3.2.1 para a versão 3.3.x.

  • Problema 32913:

    Após ativar a Alta Disponibilidade, os detalhes de Multicast para o VMware SD-WAN Edge não são apresentados na Página de Monitorização. Uma recuperação automática resolve o problema.

  • Problema 35658:

    Quando um VMware SD-WAN Edge é movido de um perfil para outro que tem uma definição CSS diferente (por exemplo, IPsec no perfil1 para GRE no perfil2), as definições CSS ao nível do Edge continuarão a utilizar as definições CSS anteriores (por exemplo, IPsec em comparação com GRE).

    Solução alternativa: desative e, em seguida, ative novamente o GRE ao nível do Edge para resolver o problema.

  • Problema 35667:

    Quando um VMware SD-WAN Edge é movido de um perfil para outro perfil que tem a mesma definição de CSS, mas um nome GRE CSS diferente (os mesmos pontos finais), alguns túneis GRE não vão aparecer na monitorização.

    Solução alternativa: desative e, em seguida, ative novamente o GRE ao nível do Edge para resolver o problema.

  • Problema 36665:

    Se o VMware SD-WAN Orchestrator não conseguir ligar-se à Internet, as páginas de interface do utilizador que requerem acesso à API do Google Maps poderão não conseguir carregar completamente.

  • Problema 38056:

    O ficheiro export.csv de licenciamento do Edge não mostra os dados da região.

  • Problema 38843:

    Ao fazer push a um mapa de aplicação, não existe nenhum Evento do operador e o Evento do Edge é de utilidade limitada.

  • Problema 39633:

    A hiperligação Supergateway não funciona após um utilizador atribuir o Gateway alternativo (Alternate Gateway) como o Supergateway (Super Gateway).

  • Problema 39790:

    O VMware SD-WAN Orchestrator permite a um utilizador configurar uma interface encaminhada do VMware SD-WAN Edge para que tenha mais do que as 32 subinterfaces suportadas, criando o risco de um utilizador configurar 33 ou mais subinterfaces numa interface, o que pode provocar uma falha do Serviço dataplane Edge.

  • Problema 41691:

    O utilizador não pode alterar o campo “Número de endereços” (Number of addresses), embora o conjunto DHCP não esteja esgotado na página Configurar > Edge > Dispositivo (Configure > Edge > Device).

  • Problema 43276:

    O utilizador não consegue alterar o tipo de segmento quando um VMware SD-WAN Edge ou Perfil tem um Gateway de parceiro configurado.

  • Problema 47820:

    Se uma VLAN estiver configurada com o DHCP desativado ao nível do perfil, enquanto também tem uma Anulação de Edge para esta VLAN nesse Edge com o DHCP ativado e existe uma entrada para o campo de servidor DNS definido para nenhum (nenhum IP configurado), o utilizador não poderá fazer qualquer alteração na página Configurar > Edge > Dispositivo (Configure > Edge > Device) e receberá uma mensagem de erro de “endereço IP inválido []” (invalid IP address []) que não explica nem indica o verdadeiro problema.

  • Problema 48085:

    O VMware SD-WAN Orchestrator permite que um utilizador elimine uma VLAN que esteja associada a uma interface.

  • Problema 49225:

    O VMware SD-WAN Orchestrator não impõe um limite de 32 VLANs totais.

  • Problema 51722: Na versão 4.0.0 do VMware SD-WAN Orchestrator, o seletor do intervalo de tempo não é superior a duas semanas para qualquer estatística nos separadores Monitorizar > Edge (Monitor > Edge).

    O seletor de intervalo de tempo não apresenta opções superiores a “Últimas 2 semanas” (Past 2 Weeks) nos separadores Monitorizar > Edge (Monitor > Edge), mesmo que o período de retenção para um conjunto de estatísticas seja largamente superior a 2 semanas. Por exemplo, as estatísticas de fluxo e ligação são mantidas durante 365 dias por predefinição (isto é configurável), enquanto as estatísticas de caminho são mantidas apenas durante 2 semanas por predefinição (também configurável). Este problema está a fazer com que todos os separadores de monitorização estejam em conformidade com o tipo de estatística retida mais baixa versus permitir que um utilizador selecione um período de tempo consistente com o período de retenção para essa estatística.

    Solução alternativa: um utilizador pode utilizar a opção “Personalizado” (Custom) no seletor de intervalo de tempo para ver dados durante mais de 2 semanas.

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