Atualizado a 14 de novembro de 2022

VMware SASE™ Orchestrator versão R451-20220831-GA
VMware SD-WAN™ Gateway Versão R451-20220701-GA
VMware SD-WAN™ Edge Versão R451-20220916-GA
VMware Cloud Web Security™ com a versão R451-20220831-GA do Orchestrator
Versão do VMware Secure Access™ com a versão R451-20220831-GA do Orchestrator
VMware Edge Network Intelligence™ com a versão R451-20220831-GA do Orchestrator

Verifique regularmente 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.5.0, bem como para os clientes afetados pelos problemas indicados abaixo que foram resolvidos desde a versão 4.5.0.

Compatibilidade

A versão 4.5.1 dos Orchestrators, Gateways e Edges Hub suporta todas as versões anteriores do VMware SD-WAN Edge igual ou superior à versão 3.2.0 
Nota: isto significa que as versões anteriores à 3.2.0 não são suportadas.

Foram explicitamente testadas as seguintes combinações de interoperabilidade do SD-WAN:

Orchestrator

Gateway

Edge

Hub

Ramo/Spoke

4.5.0

4.5.1

4.5.0

4.5.0

4.5.0

4.5.1

4.5.1

4.5.1

4.5.0

4.5.0

4.5.1

4.5.0

4.5.1

3.4.6

3.4.6

3.4.6 

4.5.1

4.5.1

3.4.6

3.4.6

4.5.1

4.5.1

4.5.1

3.4.6

4.5.1

4.5.1

3.4.6

4.5.1

4.5.1

4.2.2

4.2.2

4.2.2

4.5.1

4.5.1

4.2.2

4.2.2

4.5.1

4.5.1

4.5.1

4.2.2

4.5.1

4.5.1

4.2.2

4.5.1

4.5.1

4.3.1

4.3.1

4.3.1

4.5.1

4.5.1

4.3.1

4.3.1

4.5.1

4.5.1

4.5.1

4.3.1

4.5.1

4.5.1

4.3.1

4.5.1

4.5.1

4.5.0

4.5.0

4.5.0

4.5.1

4.5.1

4.5.0

4.5.0

4.5.1

4.5.1

4.5.1

4.5.0

4.5.1

4.5.1

4.5.0

4.5.1

5.0.0

4.5.1

4.5.0

4.5.1

5.0.0

5.0.0

4.5.0

4.5.1

Nota: a tabela acima apenas é válida para clientes que utilizam serviços SD-WAN. Os clientes que precisem de acesso ao VMware Cloud Web Security ou ao VMware Secure Access têm de atualizar os Edges para a versão 4.5.0 ou 4.5.1.

Aviso: as versões 3.2.x e 3.3.x do VMware SD-WAN 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.

Aviso: a versão 3.4.x do VMware SD-WAN está a aproximar-se do fim do suporte para o Orchestrator e o Gateway.

  • 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

Aviso: as versões 4.0.x e 4.2.x do VMware SD-WAN aproximam-se do fim do suporte. 

  • A versão 4.0.x chegará 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 chegará ao fim do suporte geral (EOGS) a 30 de dezembro de 2022 e 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 2023.
  • 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

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.

Caminhos de atualização do Orchestrator, Gateway e Edge

Seguem-se os caminhos para os clientes que pretendem atualizar o Orchestrator, o Gateway ou o Edge de uma versão mais antiga para a versão 4.5.1

Orchestrator

Devido às alterações à infraestrutura no Orchestrator a partir da versão 4.0.0, qualquer Orchestrator que utilize uma versão 3.x deve ser atualizado primeiro para a versão 4.0.0 e, depois, para a versão 4.5.1. Os Orchestrators que utilizam a versão 4.0.0 ou posterior podem ser atualizados para a versão 4.5.1.  Assim, os caminhos de atualização do Orchestrator são os que se seguem:

Orchestrator com a versão 3.x → 4.0.0 → 4.5.1.

Orchestrator com a versão 4.x → 4.5.1.

Gateway

As atualizações do Gateway da versão 3.x para a versão 4.5.1 não são suportadas. Em vez de ser atualizado, um Gateway com a versão 3.x deve ser novamente implementado com os mesmos atributos de VM, sendo, em seguida, preterida a instância antiga.

A atualização de um Gateway com a versão 4.0.0 ou posterior é completamente suportada para todos os tipos de Gateway.

Edge

Um Edge pode ser atualizado diretamente para a versão 4.5.1 a partir de qualquer versão 3.x ou posterior.

Notas importantes

Problema com Edges que utilizam o Edge Network Intelligence

Relativamente a um cliente que utilize o Edge Network Intelligence, um Edge no qual a Análise está ativada, 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, que será repetido aproximadamente a cada 3-4 dias. Este problema está registado com o pedido 91365 na secção Problemas conhecidos do Edge/Gateway destas notas.

Este problema foi corrigido na compilação de correção do Edge R451-20220720-GA-91365, que se baseia na primeira compilação rollup do Edge R451-20220701-GA e adiciona a correção de 91365. Qualquer cliente que precise de acesso a esta compilação de correção pode contactar o Suporte da VMware SD-WAN.

Potencial problema com locais que utilizam uma topologia de alta disponibilidade

Um site onde um par de Edges são implementados numa topologia de alta disponibilidade pode deparar-se com um problema em que o Edge em standby reinicia uma ou mais vezes para resolver um estado Ativo-Ativo. Os reinícios do Edge em standby podem provocar a perturbação do tráfego do cliente, tendo um maior impacto em locais que utilizam uma topologia de HA melhorada, uma vez que o Edge em standby também transmite tráfego do cliente. O problema está a ser acompanhado pelo Problema 85369, que foi corrigido na primeira compilação rollup para a versão 4.5.1: R451-20220701-GA. O problema é acompanhado na secção Problemas resolvidos do Edge/Gateway para R451-20220701-GA nestas Notas de versão e recomenda-se vivamente que os clientes com sites de HA atualizem os respetivos Edges para R451-20220701-GA.

Aceder ao Cloud Web Security e ao Secure Access

Os clientes que pretendam aceder ao VMware Cloud Web Security ou ao VMware Secure Access devem atualizar os Edges para a versão 4.5.0 ou posterior.  Estes serviços estão inacessíveis em Edges que utilizam uma versão anterior à 4.5.0.

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 suporta 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.

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/3.4.6, 4.0.2, 4.2.1 ou 4.3.0, o Edge seria atualizado conforme esperado. Para obter mais informações, consulte Problema 53676 resolvido nas respetivas notas de versão.

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

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, 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).

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.

Histórico de revisões do documento

18 de maio de 2022. Primeira edição.

20 de maio de 2022. Segunda edição.

  • Foi adicionado o Problema pendente 89349 à secção Problemas conhecidos do Orchestrator. Trata-se de um problema estético em que um utilizador que implementa um Orchestrator 4.5.1 com a compilação R451-20220517-GA vê o aviso do contrato de licença beta na página de início de sessão. A R451-20220517-GA não é uma compilação beta e esta mensagem foi deixada por engano na compilação GA final. Este problema ficará corrigido com a próxima compilação rollup do Orchestrator.

24 de maio de 2022. Terceira edição.

  • Foi adicionada uma nova compilação rollup R451-20220520-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a primeira compilação rollup do Orchestrator e é a nova compilação GA do Orchestrator para a versão 4.5.1.
  • A compilação rollup R451-20220520-GA do Orchestrator inclui a correção para o problema 89349, que se encontra documentado nesta secção.

1 de junho de 2022, quarta edição.

  • Foi adicionado o Problema resolvido 81835 aos Problemas resolvidos do Orchestrator da compilação GA inicial. Este pedido foi omitido por engano da Primeira edição das Notas de lançamento da versão 4.5.1.
  • Foram adicionados os problemas 85369 e 85461 à secção Problemas conhecidos do Edge/Gateway.

8 de junho de 2022. Quinta edição.

  • Foi adicionada uma nova Nota importante: “Potencial problema com locais que utilizam uma topologia de alta disponibilidade” relativamente a problemas em curso com locais de clientes que utilizam uma topologia de alta disponibilidade para um par de Edges. Este problema continua a ser monitorizado pelo problema 85369 localizado nos Problemas conhecidos do Edge/Gateway.
  • Em Compatibilidade, foram corrigidas as datas de fim de vida para o software do Edge da versão 4.2.x. O software do Edge é discriminado como um item à parte e agora indica o seguinte: “A versão 4.2.x do 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 2023”.  A entrada separada do Orchestrator e do Gateway mantém as mesmas datas de fim de vida como anteriormente.

17 de junho de 2022. Sexta edição.

  • Foi adicionada uma nova compilação rollup R451-20220612-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a segunda compilação rollup do Orchestrator e é a nova compilação GA do Orchestrator para a versão 4.5.1.
  • A compilação rollup R451-20220612-GA do Orchestrator inclui os problemas resolvidos 86848 e 89800, que se encontram documentados nesta secção.
  • Foram adicionadas três novas combinações de interoperabilidade testadas e verificadas à tabela Compatibilidade.  As três combinações envolvem o software 4.5.0 do Orchestrator e Gateway e estão listadas no topo da tabela.

1 de julho de 2022. Décima nona edição.

  • Foram adicionados os Problemas pendentes 88604 e 91746 à secção Problemas conhecidos do Edge/Gateway.

14 de julho de 2022. Vigésima edição.

  • Foi adicionada uma nova compilação rollup R451-20220701-GA do Edge/Gateway à secção Problemas resolvidos do Edge/Gateway. Esta é a primeira compilação rollup do Edge/Gateway e é a nova compilação GA do Edge/Gateway para a versão 4.5.1.
  • A compilação do Edge/Gateway R451-20220701-GA inclui as correções para os problemas 64196, 78568, 83083, 85369, 85461, 87304, 89627, 89725, 89861, 89873, 90151, 90280, 91746 e 92216, que estão documentados nesta secção.
  • Foram adicionados os Problemas pendentes 81859, 91365, 92481, e 92676 à secção de Problemas conhecidos do Edge/Gateway.
  • Foi revista a Nota importante: “Potencial problema com sites que utilizam uma topologia de alta disponibilidade” para indicar agora que o problema 85369 foi corrigido na nova compilação do Edge R451-20220701-GA e que se recomenda aos clientes com sites de HA que atualizem os respetivos Edges para esta nova compilação o mais rápido possível.

Atualizado a 2 de agosto de 2022. Vigésima primeira edição.

  • Foi adicionada uma nova Nota importante: “Problema com Edges que utilizam o Edge Network Intelligence” sobre o Problema conhecido 91365, em que os clientes que utilizam o serviço Edge Network Intelligence registariam este problema em que qualquer Edge que utilize a Análise será reiniciado a cada 3-4 dias devido a uma fuga de memória. O problema 91365 foi corrigido numa nova compilação de correção R451-20220720-GA-91365 e continua a estar registado em Problemas conhecidos do Edge/Gateway.
  • Foram adicionados os problemas resolvidos 84214 e 86546 à secção de Problemas resolvidos do Orchestrator da compilação rollup do Orchestrator R451-20220520-GA. Ambos os pedidos foram omitidos por engano na publicação inicial desta primeira compilação rollup do Orchestrator.

11 de agosto de 2022. Vigésima segunda edição.

  • Foi adicionada uma nova compilação rollup R451-20220810-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a terceira compilação rollup do Orchestrator e é a nova compilação GA do Orchestrator para a versão 4.5.1.
  • A compilação rollup R451-20220810-GA do Orchestrator inclui os problemas resolvidos 80735, 83507, 88120, 90067, 91179 e 92082, que se encontram documentados nesta secção.

16 de agosto de 2022. Vigésima terceira edição.

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

26 de agosto de 2022. Vigésima quarta edição.

  • O problema 86808 foi movido dos Problemas conhecidos do Edge/Gateway para os Problemas resolvidos do Edge/Gateway na compilação GA original R451-20220513-GA.  Este problema foi classificado incorretamente como não corrigido na versão 4.5.1 quando a correção do mesmo tinha sido incluída na compilação do Edge da versão 4.5.1 GA original R451-20220513-GA.
  • O Problema pendente 49712 foi removido dos Problemas conhecidos do Edge/Gateway, uma vez que a Engenharia concluiu que foi provocado por um erro de configuração e não por um defeito no código.

9 de setembro de 2022. Vigésima quinta edição.

  • Foi adicionada uma terceira compilação rollup atualizada R451-20220831-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. A compilação R451-20220831-GA substitui a terceira compilação original R451-20220810-GA do Orchestrator e é a nova compilação GA do Orchestrator para a versão 4.5.1. Esta compilação atualizada não adiciona novos problemas resolvidos, mas contém alterações de resolução de problemas exigidas pela VMware Engineering.
  • Foram adicionados os problemas 87552 e 93383 à secção Problemas conhecidos do Edge/Gateway.

14 de setembro de 2022. Vigésima sexta edição.

  • Foi adicionado o problema 91875 à secção Problemas conhecidos do Edge/Gateway.

23 de setembro de 2022. Vigésima sétima edição.

  • Foi adicionada uma nova compilação rollup R451-20220916-GA do Edge à secção Problemas resolvidos do Edge/Gateway. Esta é a segunda compilação rollup do Edge e é a nova compilação GA do Edge para a versão 4.5.1. A compilação do Gateway permanece inalterada.
  • A compilação R451-20220916-GA do Edge inclui as correções para os problemas 86098, 93383, 94204, 94395, 95565, 96441 e 96888, que se encontram documentados nesta secção.
  • Foi adicionado o problema 87982 à secção Problemas conhecidos do Edge/Gateway.

5 de outubro de 2022. Vigésima oitava edição.

  • Foi adicionado o problema 98136 à secção Problemas conhecidos do Edge/Gateway.
  • Foi adicionado o problema 75117 à secção Problemas resolvidos do Edge/Gateway da compilação original R451-20220513-GA. Este problema foi omitido por engano nas Notas de lançamento originais da versão 4.5.1.

14 de novembro de 2022. Vigésima nona edição.

  • Foram adicionados os problemas 82104 e 97321 à secção Problemas conhecidos do Edge/Gateway.

Problemas resolvidos

Os problemas resolvidos são agrupados da seguinte forma.

Problemas resolvidos do Edge/Gateway

Resolvido na versão R451-20220916-GA do Edge

A versão R451-20220916-GA do Edge foi lançada a 22-09-2022 e é o segundo rollup do Edge para a versão 4.5.1.

Esta compilação rollup do Edge aborda os problemas críticos abaixo desde o primeiro rollup do Edge, versão R451-20220701-GA.

  • 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 disto, este caminho não é instalado como Ativo e o tráfego que usa esta ligação é ignorado.

  • Problema 93383 resolvido: 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. Para recuperar, o serviço do Edge tem de ser reiniciado, o que, numa implementação não HA, provocaria 10 a 15 segundos de interrupção no 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 94204 resolvido: Um utilizador pode observar que as tentativas para gerar um pacote de diagnóstico para um VMware SD-WAN Edge falham.

    Falha na conclusão dos pacotes de diagnóstico do Edge, dado que o Edge fica sem espaço em disco. Isto poderá ocorrer 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. 

  • 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 Standby para Ativo.

    Num par HA que não tenha uma correção para este problema, a solução é evitar partilhar a mesma rede de difusão entre dois pares HA diferentes.

  • Problema 95565 resolvido: Num site que utilize uma topologia de alta disponibilidade, o Edge Ativo do VMware SD-WAN pode sofrer uma falha do Serviço Dataplane com um núcleo gerado e aciona a recuperação automática de Alta Disponibilidade.

    O problema é acionado pelas ligações WAN do Edge ativo ficarem instáveis uma ou mais vezes (ficam inativas e rapidamente voltam a estar ativas) enquanto utilizam em simultâneo o SNMP onde existem consultas SNMP frequentes. Existe um problema de temporização onde o regresso da interface e a consulta SNMP em conjunto podem acionar um bloqueio total que faz com que o serviço Dataplane falhe e gere um núcleo. Embora uma única instabilidade da ligação WAN possa provocar este problema, quanto maior a frequência das instabilidades da ligação WAN, maior o potencial para este problema ocorrer.

    Num par Edge HA que regista este problema e não tem a correção, a solução alternativa é desativar o SNMP, uma vez que se trata de um problema de temporização e isto reduz o risco.

  • 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 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.

Problemas resolvidos do Edge/Gateway

Resolvido na versão R451-20220701-GA do Edge/Gateway

A versão R451-20220701-GA do Edge/Gateway foi lançada em 08-07-2022 e é o primeiro rollup do Edge/Gateway para a versão 4.5.1.

Esta compilação rollup do Edge/Gateway aborda os problemas críticos abaixo desde a compilação GA original 4.5.1 do Edge/Gateway, versão R451-20220513-GA.

  • Problema 64196 resolvido: num VMware SD-WAN Edge em que estejam configuradas uma ou mais políticas de BGP com filtros de saída, caso seja efetuada uma alteração à configuração de um filtro de saída, os caminhos tornam-se instáveis e os filtros de saída podem ser aplicados de forma inconsistente, com perturbações no tráfego do cliente.

    Uma alteração de configuração pode ser modificar um filtro existente ou adicionar um novo filtro de saída. Ao deparar-se com este problema, o cliente pode observar um vizinho BGP que utiliza uma política de BGP com um filtro de saída que está a negar todos os caminhos, quando está configurado para permitir que todos os caminhos sejam anunciados, resultando em problemas significativos no tráfego do cliente. Este problema é provocado pela associação do vizinho BGP a um mapa de caminhos obsoleto em vez de ao mapa atualizado resultante da alteração da configuração.

    Num Edge que não tenha a correção deste problema, se o Serviço Edge for reiniciado através do Orchestrator em Ações remotas (Remote Actions) > Reinício do serviço (Service Restart), todos os caminhos são restaurados após o reinício.

  • Problema 78568 resolvido: Para um cliente que utilize o BGP e esteja ligado a Gateways de parceiros do VMware SD-WAN, um Gateway de parceiro pode continuar a anunciar uma sub-rede da VLAN do VMware SD-WAN Edge depois de o sinalizador de anúncio da sub-rede estar definido como Falsa.

    Os caminhos continuam a ser anunciados porque, quando o Edge interrompe o estado de adjacência do vizinho BGP com um vizinho BGP L3, um dos Gateways de parceiro ligados mantém a propriedade da sub-rede da VLAN do Edge. Os caminhos obsoletos num Gateway de parceiro afetam negativamente o tráfego dos clientes e podem levar a que todos os fluxos dos clientes sejam removidos, porque o tráfego é encaminhado para caminhos agora inexistentes.

    Sem uma correção, a única forma de remediar o problema e limpar os caminhos BGP obsoletos é um parceiro ou operador reiniciar o serviço do Gateway de parceiro numa janela de manutenção adequada.

  • Problema 83083 resolvido: um VMware SD-WAN Gateway atualizado para a versão 4.3.1 ou posterior pode registar uma fuga de memória lenta, que pode levar ao reinício do serviço do Gateway para limpar a memória.

    Os reinícios dos Gateways podem ser disruptivos para o tráfego do cliente durante os 30 a 45 segundos que o reinício do serviço do Gateway demora. Cada vez que um utilizador operador executa o comando debug.py --flow_dump all all all no Gateway, este esvazia parte da memória.  Executar este comando de depuração vezes suficientes fará com que a utilização da memória do Gateway atinja um nível crítico e desencadeie um reinício do serviço do Gateway para limpar a memória.

    Num Gateway sem a correção, o operador tem de evitar executar o comando debug.py --flow_dump all all all no Gateway. Se a utilização deste comando de depuração for inevitável, monitorize a utilização da memória e agende as janelas de manutenção para reiniciar preventivamente o serviço para limpar a memória antes de um reinício não programado.

  • Problema 85369 resolvido: Num site implementado com uma topologia de alta disponibilidade, o cliente pode observar disrupções ao tráfego do cliente e, possivelmente, observar vários reinícios do VMware SD-WAN do Edge em standby.

    Uma condição acionada por eventos de carga e do sistema faz com que o Edge ativo sofra atrasos no fornecimento oportuno de heartbeats de HA para o Edge em standby. O atraso faz com que o Edge em standby perca heartbeats e assuma incorretamente o papel de Ativo, o que causa o estado Ativo-Ativo. Para recuperar do estado Ativo-Ativo, o Edge em standby reinicia, possivelmente várias vezes. 

    Se o site se tornar Ativo-Ativo, uma configuração HA convencional sofrerá uma disrupção mínima no tráfego, dado que o Edge em standby não passa tráfego nesta topologia, mas 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 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.

    sem uma correção para este problema, a solução é não utilizar o Edge para encaminhar o DNS ou...

    • Quando utilizar a versão 4.2.2 do Edge: utilize portas LAN comutadas ou portas LAN encaminhadas que incluam um endereço IP do Gateway.
    • Quando utilizar a versão 4.3.x ou 4.5.x: utilize apenas portas LAN encaminhadas com um endereço IP do Gateway especificado.
  • Problema 87304 resolvido: se uma interface LAN num VMware SD-WAN Edge estiver desativada no VMware SASE Orchestrator, continuará a ser comunicada como “Ativa” (UP) pelo SNMP.

    Descrição: 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 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 89725 resolvido: nos VMware SD-WAN Edges que utilizem a versão de software 4.5.1 GA do Edge, os utilitários de Diagnóstico remoto Teste de largura de banda da ligação WAN 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 utilizador pode observar um aumento constante na utilização da memória num VMware SD-WAN Edge em que exista uma utilização intensiva de Grupos de objetos com Políticas empresariais. 

    Ao utilizar Grupos de objetos com Políticas empresariais, em todas as atualizações efetuadas ao Grupo de objetos no Edge, ocorre uma fuga dos objetos de memória do Edge pertencentes ao grupo de endereços. Além disso, se as atualizações ao Grupo de objetos forem efetuadas regularmente (por exemplo, mediante a utilização de um script), a utilização de memória aumentará de forma contínua até atingir um nível crítico (60% de utilização de memória durante mais de 90 segundos) e acionar um reinício do Serviço Edge para recuperar a memória. 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. Este 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 e ser reiniciado.  

    Sem uma correção para este problema, a solução é limitar a frequência das atualizações do Grupo de objetos ou, se tal não for possível, monitorizar regularmente a memória e, quando a utilização da mesma atingir os 40% e receber um Evento de aviso de memória no Orchestrator, agendar um reinício do Serviço Edge numa janela de manutenção para limpar a memória e garantir o mínimo impacto 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. 

    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 enterprise_logical_id e segment_id não é suficiente para diferenciar entre filtros de 2 vizinhos NSD-BGP diferentes.

  • 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 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.

    Solução alternativa: num Edge onde este problema ocorra, as soluções são a) desativar a autenticação 802.1x ou b) reverter o Edge para uma compilação de software do Edge anterior, na qual a autenticação 802.1x funcionava corretamente porque este problema não existia.

  • 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.

Problemas resolvidos do Edge/Gateway

Resolvido na versão R451-20220513-GA do Edge/Gateway

Os problemas abaixo foram resolvidos desde a versão R450-20220413-GA do Edge e da versão R450-20211123-GA-74198-70416-74482-30022 do Gateway.

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

    Desativar uma porta encaminhada desassocia esse dispositivo de rede do hardware controlado por DPDK, volta a associá-lo ao driver Linux e reinicia o serviço Edge. O ficheiro /opt/vc/etc/dpdk.json é 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.

    Sem a correção, a única maneira de remediar o problema é 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 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 49787 resolvido: um utilizador que navegue até à página Diagnóstico remoto (Remote Diagnostics) de um VMware SD-WAN Edge na IU do VMware SD-WAN Orchestrator pode observar a IU a processar o pedido, mas a página de diagnóstico do Edge não é carregada.

    O problema pode ocorrer num Edge em que os certificados não sejam utilizados e é o resultado de a ligação do VMware SD-WAN Edge ser continuamente reposta porque o Edge renova repetidamente o respetivo certificado.

  • 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 53243 resolvido: o tráfego pode ser encaminhado para um Destino Não-SD-WAN (NSD) que utiliza um tipo de ponto de verificação porque o Gateway não elimina a associação de segurança (SA) de fase 2.

    Os pares estão dessincronizados em termos da SA e a ligação está inativa até que a SA expire. Num NSD que utilize um tipo de firewall de ponto de verificação, quando a ligação não é estável, é possível deparar-se com uma situação em que o par envia uma notificação de eliminação, mas o Gateway não pode eliminar a SA de fase 2, porque a SA de fase 1 correspondente já foi eliminada.

  • Problema 54846 resolvido: Os MIBs SNMP do VMware SD-WAN utilizam contadores para distorção, latência e perda de pacotes.

    Em MIBs SNMP do VMware, a latência, a distorção e a perda de pacotes são definidas como Counter64, o que não é apropriado para estes tipos. Os contadores devem ser utilizados para tipos de dados cujos valores aumentam constantemente e que nunca são repostos no SNMP, como bytes Tx/Rx. Em contrapartida, a latência, a distorção e a perda de pacotes nunca têm valores de aumento constante, mas sim valores ajustados dinamicamente, e não devem utilizar contadores.

  • Problema 55327 resolvido: a ligação SSH de um VMware SD-WAN Gateway a um VMware SD-WAN Edge pode não funcionar se ocorrerem flaps contínuos no túnel do Edge para o Gateway.

    Caso ocorram flaps contínuos no túnel do Edge para o Gateway, a entrada do caminho instalada no Edge para permitir a ligação SSH a partir do Gateway pode ser eliminada e causar a falha da ligação SSH.

  • Problema 57011 resolvido: Num site configurado com uma topologia de alta disponibilidade, sempre que os segmentos são adicionados e, em seguida, eliminados nesse site, um dos Edges de HA pode sofrer uma falha do Serviço dataplane e se a falha de serviço estiver ativada no Edge ativo, o site também sofrerá uma recuperação automática da HA.

    Quando os segmentos são adicionados e, em seguida, eliminados de um site de HA, existe o potencial para segmentos obsoletos (por outras palavras, os segmentos eliminados podem ainda aparecer num dos Edges do par de HA). Devido a esta incompatibilidade nas informações de segmento entre os Edges HA, qualquer evento destinado ao segmento obsoleto pode ser enviado para o outro Edge, resultando numa falha do serviço dataplane e na recuperação automática de HA se a falha de serviço estiver no Edge ativo, e na geração de um despejo de memória que será encontrado num pacote de diagnóstico obtido após a falha.

  • Problema 58759 resolvido: um percurso do SNMP de uma localização remota na cloud para uma interface WAN num VMware SD-WAN Edge excede o tempo limite.

    Enviar ping à mesma interface WAN funciona conforme esperado. Os pacotes de resposta SNMP são encaminhados para o Edge porque são aplicadas políticas de encaminhamento inadequadas aos mesmos.

  • Problema 65186 resolvido: No site de um cliente que utilize várias ligações WAN, se existir uma política empresarial configurada para utilizar uma ligação com uma política preferencial ou obrigatória, a carga do tipo de tráfego abrangido pela política empresarial continuará a ter balanceamento de carga em todas as ligações disponíveis.

    Mesmo que a política empresarial esteja configurada para encaminhar o tráfego para uma ligação WAN com uma configuração obrigatória ou preferencial, a carga do tráfego incluirá balanceamento de carga em várias ligações WAN.

  • Problema 66325 resolvido: o tráfego de um cliente que deveria corresponder a um caminho aprendido BGP é, em vez disso, correspondido a uma política empresarial com o potencial de perturbar o tráfego do cliente.

    Se a empresa de um cliente utilizar uma política empresarial que configura a Origem como o IP de um cliente encaminhado e o destino como Internet, o tráfego que deveria corresponder a um caminho aprendido BGP utilizará, em vez disso, a política empresarial, incluindo qualquer que seja a classificação de tráfego para essa política (por exemplo, Tempo real), o que pode causar perturbações no tráfego do cliente.

  • Problema 67458 resolvido: 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 facto de o Edge Hub ignorar os 
    MP_INITs, uma vez que o número de TDs meio abertos excede o limite superior do Edge Hub.

    Sem a correção, um utilizador teria de reiniciar o serviço Edge para restaurar a conetividade total do túnel.

  • Problema 67745 resolvido: um VMware SD-WAN Edge que tem uma ligação WAN a alguns routers fornecidos pelo ISP poderá enfrentar problemas de tráfego do cliente se esse caminho do ISP ficar inativo e, em seguida, for reativado.

    Quando uma ligação WAN do Edge a alguns routers do ISP (este problema foi encontrado com um router do ISP utilizado pela Spectrum) fica inativa ou o router do ISP fica inativo e, em seguida, é reativado, o router do ISP executa um diagnóstico que inclui a atribuição breve de um IP privado ao Edge na sub-rede 192.168.100.0/24 e, depois disso, atribui o endereço IP público. No entanto, o Edge instala o caminho ligado para 192.168.100.0/0 e este não é limpo depois de obter o endereço IP público.

  • Problema 67889 resolvido: a consulta de SNMPv3 pode não funcionar corretamente para um cliente que consulte vários VMware SD-WAN Edges.

    O problema prende-se com o facto de o VMware SD-WAN permitir que o respetivo processo SNMP (snmpd) gere um engine-id aleatório para cada Edge e, em muitos casos, esse engine-id é duplicado para vários Edges. Quando isso acontece, um dos Edges com o mesmo engine-id não comunica estatísticas ao coletor.

  • Problema 68044 resolvido: um VMware SD-WAN Edge com um VNF pode sofrer uma falha do Serviço dataplane e reiniciar.

    Para monitorizar se o tráfego passa através do VNF, o processo Edge envia ARPs gratuitos periódicos (GARP). Existe o potencial de corrupção de memória quando o temporizador para GARPs é executado ao mesmo tempo que o Edge atualiza a configuração VNF.

  • Problema 68224 resolvido: um VMware SD-WAN Edge pode registar uma falha do Serviço dataplane e ser reiniciado ao remover os caminhos de um PE (Edge do fornecedor) em grande escala.

    A escala elevada é definida como 100 mil ou mais caminhos.  O problema ocorre quando um thread tem de esperar demasiado tempo para obter um bloqueio da tabela de caminhos e o monitor mutex induz uma falha do Serviço dataplane para limpar o problema ao reiniciar o serviço. O problema é causado quando um thread diferente mantém o bloqueio da tabela de caminhos ao tentar efetuar uma pesquisa de tabela de hashes de redistribuição BGP e esse processo demora mais tempo do que o especificado. O processo demora demasiado tempo porque o processo de hash não distribui os nós uniformemente, o que resulta num excesso de colisões de tabelas hash e, assim, as pesquisas acabam por ser uma pesquisa de listas ligadas.

  • Problema 68785 resolvido: o software VMware SD-WAN Edge descarta os pacotes DHCP INFORM quando são recebidos numa interface configurada como um reencaminhamento DHCP.

    Os clientes DHCP podem solicitar informações adicionais de rede, como o servidor DNS ou o endereço do Gateway, com a mensagem DHCP INFORM após a aquisição de um endereço IP. Quando o Edge é configurado como um agente de reencaminhamento, estas mensagens INFORM devem ser encaminhadas para o servidor DHCP, mas, em vez disso, são descartadas.

  • Problema 68829 resolvido: nos modelos VMware SD-WAN Edge LTE (por outras palavras, o Edge 510-LTE ou o Edge 610-LTE), os caminhos IPv6 não são formados através das respetivas interfaces LTE.

    Os pacotes udp6 são enviados com uma soma de verificação de 0, fazendo com que sejam descartados no próximo hop. Isto resultava na colocação dos caminhos de gestão SD-WAN num estado INIT. O comportamento correto é preencher a soma de verificação para os pacotes udp6.

  • Problema 68840 resolvido: Para um cliente que utilize uma topologia de alta disponibilidade, a consulta de SNMP não consegue obter informações de LAN e WAN do VMware SD-WAN Edge em standby.

    Para HA SNMP GET, a contagem de LAN/WAN em standby (vceHaStandbyLanItfNum e vceHaStandbyWanItfNum) é apresentada parcialmente ou não é apresentada.

  • Problema 68923 resolvido: Na empresa de um cliente que utilize o BGP, um caminho predefinido pode ser redistribuído para um par de BGP, embora o estado de alcance para o caminho predefinido instalado seja definido como “Falso”.

    Se estiver configurado um caminho estático num VMware SD-WAN Edge que aponta para qualquer interface do Edge e da qual o parceiro BGP aprende o caminho predefinido a partir do Edge e essa interface for posteriormente desativada, o que altera a flag alcançável para esse caminho para Falso, o caminho continua a ser anunciado. É igualmente verdade que um caminho que não está a ser redistribuído porque a interface não estava disponível, mas que quando a interface surge e marca o estado do caminho como “Verdadeiro” (True), o caminho continuaria a não ser redistribuído. A causa em ambos os casos é que o Edge não volta a anunciar o caminho numa mudança de estado da interface que reflete o novo estado do caminho.

  • Problema 69462 resolvido: os caminhos do Gateway de parceiro (PG) e NAT aprendidos num VMware SD-WAN Gateway não são inicialmente anunciados num Destino Não-SD-WAN (NSD) via BGP.

    Os caminhos são anunciados depois de ativar os “caminhos BGP seguros” no handoff de parceiro do cliente. Os caminhos na cloud não são redistribuídos porque, quando o BGP de Gateway de parceiro aparece antes do BGP NSD, a configuração deste reescreve a tabela Redis, o que faz com que alguns dos caminhos do PG adicionados a essa tabela Redis sejam omitidos. A correção garante que, se a tabela Redis já estiver presente, o BGP NSD não a reescreverá.

  • Problema 69497 resolvido: os MIBs do VMware SD-WAN mostram o objeto SNMP vceLinkVpnState, apesar de o mesmo já não ser um objeto válido.

    O VMware SD-WAN já não mostra um estado de VPN diferenciado no VMware SD-WAN Orchestrator, mas, ainda assim, expõe isto no SNMP.  Mais especificamente, o coletor SNMP procura o SNMP OID 1.3.6.1.4.1.45346.1.1.2.3.2.2.1.26, o que já não deveria fazer.

  • Problema 69681 resolvido: se um VMware SD-WAN Edge estiver configurado com ligações WAN de reserva dinâmica e também utilizar a consulta de SNMP, o utilizador observará erros do SNMP.

    A mensagem de erro seria semelhante à seguinte:

    ERROR [oids (10028:MainThread:10028)] [VCE.Path]<update>: Path failed update buffer: KeyError('HOTSTANDBY_IDLE',) INFO [oids (10028:MainThread:10028)] [VCE]<update_if_stale>: Current MIB buffer size: 217 DEBUG [oids (10028:MainThread:10028)] [VCE.Link]<ip2octet>: Failed to convert IP to Octet for caller <class 'vcsnmp.oids.Link'>[publicIpAddress] on []: ValueError("invalid literal for int() with base 10: ''",), used default value[00 00 00 00] instead

    A causa do problema é que os estados do caminho SNMP não incluem estados de ligação de reserva dinâmica e isso causa problemas do SNMP, incluindo mensagens de erro.

  • Problema 69724 resolvido: um utilizador pode observar a perda de pacotes num VMware SD-WAN Gateway devido ao comprimento inválido do pacote.

    Por causa de um problema no pipeline de pacotes, é possível categorizar os pacotes como não seguros e as verificações MTU são efetuadas de acordo com essa classificação. No entanto, mais tarde, é enviada através de um túnel de gestão, que tem mais sobrecarga e, como resultado, esses pacotes podem ser removidos no último momento, porque o respetivo tamanho é superior ao da MTU de ligação.

  • Problema 70041 resolvido: um parceiro que atualize os respetivos VMware SD-WAN Gateways para a versão 4.3.0 observa que já não pode enviar um ping para o endereço IP VRF do Gateway.

    Quando o ping falha, o contador route_drop é incrementado. O envio de pings ao endereço IP VRF de uma interface de handoff foi removido com a versão 4.5.0 e é restaurado com a correção encontrada na versão 4.5.1.

  • Problema 70129 resolvido: quando o syslog está configurado para utilização num VMware SD-WAN Gateway de grande escala, a pasta /var/log pode ficar cheia de ficheiros de syslog num curto período de tempo.

    A grande escala é considerada como um Gateway com cerca de 4 mil pares e cerca de 6 mil túneis, em que existem, geralmente, perto de 100 a 150 mil fluxos e perto de 50 a 100 mil entradas NAT. O curto período de tempo pode ser de apenas 24 horas com um ficheiro syslog.log de tamanho >3,2 Gb. Isto é causado pelo facto de alguns registos NAT serem redirecionados para /var/log, mas que deveriam ser direcionados para outra pasta.

  • Problema 70154 resolvido: para a empresa de um cliente em que a Firewall com estado está ativada, o utilizador observará pacotes ignorados ao enviar pings bidirecionais entre clientes de ramos com o mesmo ID ICMP.

    Se for iniciado um ping do Cliente A no Ramo 1 para o Cliente B no Ramo 2 e vice-versa, os estados do ICMP de ambos os pings serão rastreados com o mesmo objeto de fluxo se o ID ICMP for o mesmo e isso poderá levar a vários pacotes ignorados devido à verificação do número de sequência.

    Sem esta correção, a solução é desativar a Firewall com estado ou gerar ping com IDs ICMP diferentes.

  • Problema 70349 resolvido: em casos raros, o tráfego NAT deixa de funcionar num VMware SD-WAN Gateway.

    Reiniciar o serviço do Gateway limpará a condição. Devido a uma condição de corrida no processo dataplane do Gateway, o Gateway poderá não conseguir estabelecer ligação com o natd (o daemon no Gateway que gere as alocações de NAT) e, assim, não será capaz de alocar entradas NAT. Isto fará com que todos os fluxos NAT através do Gateway falhem.

  • Problema 70438 resolvido: os clientes que têm tráfego que depende da NAT podem sofrer perturbações do mesmo quando um VMware SD-WAN Gateway é atualizado para a versão 4.5.0 ou é reiniciado durante a execução da versão 4.5.0.

    No arranque do Gateway, pode existir uma condição race que elimina a entrada NAT de “gwd_cloud_read”, apesar de a entrada NAT já poder estar colocada em cache no fluxo (fc->nat_tup) na direção SEND_TO_WAN. Apesar de a entrada NAT ser eliminada, o fluxo continuará a utilizar o nat_tup em cache para a aplicação de NAT. Enquanto isso, outro fluxo pode ter a mesma porta de origem atribuída com uma nova entrada NAT.

  • Problema 70586 resolvido: Quando uma interface encaminhada num VMware SD-WAN Edge for configurada para 802.1x (utiliza autenticação RADIUS), a autenticação dos clientes ligados nessa interface será silenciosamente desativada sempre que qualquer interface sofrer um flap (isto é, quando qualquer interface não 802.1x ficar inativa e ativa rápida e sucessivamente) e todo o seu tráfego falhará até que o cliente se desligue e se volte a ligar ao Edge.

    O Edge não está a verificar se a interface onde ocorreu um flap é realmente a que teve clientes 802.1x autenticados e, portanto, trata qualquer ocorrência de flap numa interface como se fosse um flap de interface de 802.1x e atua em conformidade.

    Sem a correção, a única solução alternativa é forçar o cliente a desligar-se fisicamente e ligar novamente para ser novamente autenticado.

  • Problema 70590 resolvido: uma tentativa de gerar um pacote de diagnóstico num VMware SD-WAN Gateway com a versão 4.3.0 pode falhar.

    Os pacotes de diagnóstico gerados num Gateway com a versão 4.3.0 falham porque o pacote de diagnóstico excede o limite de tamanho configurado no Orchestrator.  O tamanho excessivo do pacote de diagnóstico é causado pelo tamanho dos registos de auditoria, que crescem ao longo do tempo.

    Sem esta correção, a única forma de gerar com êxito um pacote de diagnóstico num Gateway é um utilizador operador iniciar sessão no Gateway e, antes de ativar o pacote de diagnóstico no Orchestrator, eliminar os ficheiros de registo de auditoria no diretório /var/log/audit do Gateway.

  • Problema 70855 resolvido: um VMware SD-WAN Gateway pode perder tráfego proveniente do VMware SD-WAN Orchestrator, podendo impedir alguma atualização da configuração do Gateway a partir do Orchestrator.

    Quando a carga do Gateway é elevada (por exemplo, cerca de 1,6 milhões de fluxos no Gateway com uma contagem de objetos NAT de cerca de 800 mil), o número de memórias intermédias de pacotes no sistema será esgotado e isso pode, por vezes, fazer com que o tráfego do Orchestrator seja ignorado no Gateway. Assim que o Gateway entrar neste estado, o tráfego do Orchestrator é sempre ignorado, mesmo que as memórias intermédias de pacotes fiquem disponíveis.

    Sem a correção, a única solução para este problema é reiniciar o Gateway.

  • 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 semelhantes às seguintes:

    2021-08-26T01:05:21.397 AVISO kern kernel:[244841.443763] ath10k_pci 0000:01:00.0: SWBA transbordo em vdev 1, beacon antigo ignorado 2021-08-26T01:05:21.539 INFO kern kernel:[244841.586338] ieee80211 phy0: O reinício do hardware foi solicitado 2021-08-26T01:05:24.207 AVISO kern kernel:[244844.254081] ath10k_warn: 17 chamadas de retorno suprimidas 2021-08-26T01:05:24.207 AVISO kern kern:[244844.254091] ath10k_pci 0000:01:00.0: falha ao receber a conclusão da resposta de controlo, a consultar. 2021-08-26T01:05:24.223 ERRO kern kernel:[244844.270245] ath10k_pci 0000:01:00.0: falha no firmware! (guid n/d)

    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 70933 resolvido: após a migração de um perfil de configuração, um VMware SD-WAN Edge em que seja utilizada a Alta Disponibilidade pode sofrer vários reinícios.

    Durante a migração de um perfil de configuração, apenas a configuração das definições do dispositivo é sincronizada imediatamente com o Edge em standby. As restantes configurações são sincronizadas apenas em resposta a um heartbeat do Edge em standby. Quando um Edge ativo reinicia para aplicar a configuração mais recente antes de receber o heartbeat do Edge em standby, o resultado será uma incompatibilidade na configuração entre o Edge ativo e o Edge em standby, o que causará vários reinícios do Edge para sincronizar as configurações de ambos os Edges HA.

  • Problema 70954 resolvido: o VMware SD-WAN Edge poderá sofrer várias falhas do Serviço dataplane se tiver uma política empresarial configurada com uma ligação obrigatória a um Serviço de Segurança na Cloud Zscaler e a interface dessa ligação obrigatória falhar.

    O Edge deveria descartar o tráfego para o Zscaler quando a interface obrigatória falhasse, em vez de sofrer uma falha de serviço.

  • Problema 71052 resolvido: quando o número de empresas de cliente a estabelecer ligação a um VMware SD-WAN Gateway é superior a 285, o Gateway experiencia uma falha do serviço dataplane.

    A partir do Gateway versão 4.3.0, a capacidade do Gateway de monitorizar clientes foi melhorada ao adicionar novos contadores para rastrear as informações relacionadas com o fluxo e o pacote ao nível da empresa do cliente. O problema é que o número de contadores inicializados para as empresas de cliente esgota-se após 285 empresas de cliente e a inicialização de contadores para qualquer novo cliente adicional irá falhar, o que provoca a falha do Serviço de dataplane do Gateway e força um reinício do serviço.

  • Problema 71189 resolvido: depois de mudar para uma versão anterior à versão 4.5.0 e voltar a atualizar para a 4.5.0, o VMware SASE Orchestrator não guarda as configurações da interface encaminhada após a ativação da opção IPv6.

    Depois de mudar para uma versão anterior à versão 4.5.0 e voltar a atualizar para a 4.5.0, o Orchestrator apresenta o erro “O wanoverlay IPv6 tem de estar desativado se o wanoverlay IPv4 estiver desativado para <nome da interface>” (IPv6 wanoverlay must be disabled when IPv4 wanoverlay is disabled for <interface name>) ao tentar ativar a opção IPv6.

    Sem a correção, antes de guardar a configuração, marque a caixa de verificação “Ativar overlay WAN” (Enable WAN Overlay) e, em seguida, desmarque-a.

  • Problema 71314 resolvido: numa localização com uma topologia de Alta disponibilidade, o cliente pode observar vários eventos de recuperação automática HA que fazem com que o serviço VMware SD-WAN Edge seja desligado, afetando a qualidade do tráfego do cliente.

    Este problema é inconsistente. Contudo, quando ocorre, está associado a um problema “split-brain” com origem num flap de ligação, no qual o Edge HA regista um problema de impasse entre o processo HA e o processo que lida com a alteração do estado da interface.  O impasse resulta numa falha tripla do Serviço dataplane para cada Edge HA (com os eventos de falha HA resultantes que daí advêm), culminando com a desativação do Serviço dataplane. Um Edge cujo Serviço dataplane está desativado passará o tráfego e poderá realizar alterações de configuração, pois o Serviço de gestão permanece operacional. Contudo, a Otimização dinâmica de vários caminhos já não é utilizada, o que significa que não há priorização de tráfego, encaminhamento de ligações nem correção de erros, uma vez que todo o tráfego é enviado diretamente para a cloud, o que afeta, de forma negativa, o tráfego de alta prioridade do cliente, até ser resolvido.

    Sem a correção, se esta condição for encontrada, o utilizador poderá utilizar Ações remotas > Reiniciar Edge (Remote Actions > Reboot Edge) para restaurar o Serviço dataplane para cada Edge HA com as recuperações automáticas HA que resultarão desta ação.

  • Problema 71465 resolvido: ao configurar um Destino Não-SD-WAN (NSD) via Gateway numa IU do Orchestrator do VMware SASE, no BGP, a IU mostra as opções para criar um filtro IPv6 ao configurar as definições BGP.

    O problema principal é que o IPv6 não é suportado em NSD via Gateways na versão 4.5.x.  A página Editor BGP (BGP Editor) é comum à configuração do BGP na página Configurar > Definições do dispositivo (Configure > Device Settings), tanto para o Edge como para o Perfil, o NSD via Gateway através da página Configurar > Serviços de rede (Configure > Network Services) e o Handoff de Gateway de parceiro através da página Configurar > Cliente (Configure > Customer). As alterações do IPv6 são efetuadas para a configuração do BGP na página Configurar > Definições do dispositivo (Configure > Device Settings) do Edge ou do Perfil e são apresentadas nas páginas NSD via Gateway e Handoff de Gateway de parceiro (Partner Gateway Handoff), onde não são suportadas.

  • Problema 71720 resolvido: na página Monitorização do gateway (Gateway Monitoring) do VMware SASE Orchestrator, um utilizador operador poderá não ver uma contagem precisa do número de handoff queue drops que ocorrem num VMware SD-WAN Gateway.

    Quando um Gateway está cheio, tal situação resulta em handoff queue drops devidos que devem ser comunicados ao Orchestrator e registados na página Gateway > Monitorizar (Gateway > Monitor) da IU no gráfico Handoff Queue Drops desse Gateway particular. Neste caso, o Gateway ainda está a comunicar os handoff queue drops ao Orchestrator. Contudo, devido a uma alteração na contagem de drops, o Orchestrator não comunica os drops de sobrecapacidade, o que faz com que o gráfico Handoff Queue Drops mostre consistentemente um valor de zero, mesmo que haja drops no Gateway.

  • 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 o Standby e isto causa um impasse e desencadeia uma mensagem SIGKILL no thread mutex mon do Edge ativo, o que resulta 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 72100 resolvido: num site que utiliza uma topologia de Alta Disponibilidade melhorada em que um par de VMware SD-WAN Edge 610 é utilizado para essa implementação, os túneis não serão estabelecidos através da ligação WAN no Edge 610 em standby.

    O problema só é observado no caso do modelo Edge 610 em que os túneis não estão a ser estabelecidos através do Edge em standby. Antes de ativar a HA, se a VLAN na interface GE1 não tiver um endereço IP, o serviço SD-WAN não mapeará a porta de comutação de hardware para o GE1 após a ativação da HA. Como resultado, os pacotes serão descartados no Edge em espera.

    Sem a correção, a solução para este problema é adicionar um endereço IP à VLAN para que a interface GE1 seja mapeada para uma porta no comutador de hardware.

  • 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 72358 resolvido: se o endereço IP de um nome DNS do VMware SASE Orchestrator mudar, o Serviço de gestão em cada VMware SD-WAN Gateway ligado a esse Orchestrator não conseguirá voltar a resolvê-lo corretamente.

    O Serviço de gestão no Gateway verifica periodicamente a resolução DNS do nome DNS do Orchestrator, para ver se este foi alterado recentemente para que se possa ligar ao anfitrião certo. Existe um problema com o código de resolução, pelo que todas estas verificações de resolução falham e o Gateway continua a utilizar o endereço antigo.

    Sem a correção, o operador não deve alterar o endereço IP do Orchestrator e, se tiver de ser alterado, todos os Gateways ligados terão de ser reativados.

  • 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 72567 resolvido: Se um utilizador configurar deliberadamente o routing assimétrico através de um underlay (MPLS sem overlay WAN) no caminho de routing através de uma política empresarial fixed_link e, em seguida, através de um overlay (por exemplo, um Edge Hub) no caminho inverso, o fluxo será interrompido e o tráfego desse fluxo não será bem-sucedido.

    Trata-se de um routing assimétrico de fluxos da cloud por design, em que o Edge tem uma política empresarial para forçar a saída dos fluxos do underlay (INTF_ROUTED). O Edge remoto encaminha a resposta de volta através de um Edge Hub (overlay). O Edge remoto vê o fluxo como um novo fluxo iniciado localmente e envia uma sincronização QoS para atualizar os parâmetros de routing de fluxo, o que leva a uma interrupção do mesmo. Na correção, a sincronização QoS é rejeitada para evitar que o link_mode configurado seja substituído.

  • Problema 72688 resolvido: o VMware SD-WAN Edge reinicia aleatoriamente o seu Serviço dataplane, o que resulta em interrupções do serviço.

    Os pacotes afixados a um thread de desencriptação são rejeitados pelo thread não proprietário quando flutuam para outro thread de desencriptação. No processo de rejeição dos pacotes, a referência criptográfica QAT associada era incorretamente libertada, causando exceções no Serviço dataplane, assim como uma falha e um reinício.

  • Problema 72841 resolvido: o VMware SD-WAN Orchestrator é inconsistente ao gerar eventos “Gateway ativo” (Gateway up). Sempre que o estado do Gateway é alterado de OFFLINE para LIGADO (CONNECTED), o evento “Gateway ativo” (Gateway up) não é registado em todos os casos.

    O problema ocorre de forma inconsistente, mas quando ocorre, existem mais de dois Gateways e o updateStateChange é ativado para ambos ao mesmo tempo. Quanto mais Gateways estiverem disponíveis, se todos sofrerem uma alteração de estado ao mesmo tempo, mais provável será a ocorrência do problema.

  • 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 clientes que utilizem consultas SNMP para monitorizar as respetivas empresas e implementam modelos inferiores de VMware SD-WAN Edges (por exemplo, os modelos Edge 510, 520 ou 610) que também 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 72939 resolvido: um utilizador pode observar a contagem de fluxos obsoletos de um VMware SD-WAN Gateway a aumentar constantemente até atingir os fluxos máximos suportados para as especificações desse Gateway e, assim, deixam de ser criados novos fluxos, o que causa perturbações para os utilizadores ligados a esse Gateway.

    A contagem crescente de fluxos obsoletos está associada a sites que enviam tráfego de um Destino Não-SD-WAN para um handoff de Gateway de parceiro. Foram adicionadas duas funções, “gw_nvs_to_pg_pkt” e “gw_send_nvs_pkt”, quando as contagens de fluxos não são libertadas após a procura.

    Sem a correção, a única solução é reiniciar o serviço do Gateway. 

  • Problema 73251 resolvido: os utilizadores que necessitem de efetuar a autenticação via RADIUS podem descobrir que não o conseguem fazer porque o tráfego fragmentado não está a ser enviado do VMware SD-WAN Edge.

    O tráfego RADIUS é sempre fragmentado e este problema afeta ainda mais os utilizadores que tentam efetuar a autenticação numa ligação sem fios. Quando este problema ocorre, a contagem de pacotes fragmentados é superior àquela com que o DPDK consegue lidar na interface específica afetada. A correção repõe proativamente a contagem de fragmentação para evitar perturbações no tráfego.

  • Problema 73320 resolvido: quando a interface de um VMware SD-WAN Edge é configurada com um tipo de endereço DHCP e o endereço IP atribuído à interface é atualizado, alguns dos fluxos diretos podem falhar devido à falha de NAT.

    Quando a concessão de DHCP expira, o endereço IP é removido para a interface. Antes de um novo IP ser atribuído à interface, são criadas entradas NAT para quaisquer novos fluxos com “0.0.0.0” como o IP NAT de origem e os pacotes são eliminados. Uma vez atribuído um endereço IP válido à interface, a entrada NAT existente não é eliminada e uma nova entrada NAT não é criada com um IP válido, o que faz com que o tráfego seja descartado.

  • 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 73987 resolvido: um VMware SD-WAN Edge pode encontrar uma falha no Serviço dataplane ao tentar gerar um pacote de diagnóstico.

    A parte principal do pacote de diagnóstico que está a causar o problema é quando o Edge precisa dos registos para “vcdgbdump -r remote_routes”. Neste cenário, quando há um grande número de caminhos remotos, existe tráfego que utiliza esses caminhos e é acionada uma recolha de pacotes de diagnóstico, existe o potencial de contenção de bloqueios.

  • Problema 74225 resolvido: Um VMware SD-WAN Gateway ou SD-WAN Edge pode ter problemas de tráfego e observar pacotes com zero endereços MAC nos registos.

    Mesmo que um Gateway ou Edge execute uma compilação que inclua a correção para o problema 62552, que também abordou um Gateway ou Edge a enviar pacotes com um endereço MAC 00:00:00:00, existiam localizações dentro do processo de plano de dados Gateway/Edge que ainda poderiam enviar pacotes com um endereço MAC de origem e/ou destino de zero. Nestes locais, a máquina de estado ARP não estava a validar a origem e destino do Endereço MAC. 

    A única forma de saber de forma fiável que este problema está a ocorrer é verificar registos de endereços MAC zero, especificamente os que utilizam tcpdump.

  • 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 de 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 74316 resolvido: um Edge Spoke do VMware SD-WAN pode não se ligar a um ou a nenhum Cluster Edge do Hub atribuído, mesmo que o Edge tenha um reinício de serviço ou um reinício completo.

    Existe um problema com a lógica de reatribuição de clusters, que cria o mapeamento de atribuição de clusters sem a informação de ponto final do membro do cluster num cenário específico de flap de sobreposição Membro de cluster para Supergateway. Como resultado, os Edges do Spoke atribuídos ao membro do Cluster de hub não recebem, subsequentemente, a informação de ponto final do membro do Cluster de hub, fazendo com que não haja overlays entre os Edges do Spoke e os Clusters de hub.

    Sem a correção, a única forma de remediar temporariamente esta condição é uma pessoa com acesso ao Gateway acionar uma reatribuição de cluster manualmente nos Supergateways.

  • Problema 74446 resolvido: os contadores de Handoff Queue Drop do Gateway não estão a servir o propósito de identificar picos de tráfego quando observados na IU do VMware SD-WAN Orchestrator.

    O Handoff Queue Drop do Gateway não é suficientemente granular para identificar picos de tráfego. A correção deste problema adiciona novos contadores de marca d’água: wmark_1min e wmark_5mins, que darão a profundidade máxima de uma fila de handoff dentro de 1 minuto e 5 minutos, respetivamente.

  • Problema 74450 resolvido: o VMware SD-WAN Orchestrator não exporta contadores de marca de água para uma aplicação externa, como o Telegraf ou o Prometheus.

    Este pedido está ligado ao problema 74446, cuja correção cria contadores de marca de água para Handoff Queue Drops do Gateway. Este pedido garante que essas métricas podem ser recolhidas por uma aplicação como o Telegraf ou o Prometheus.

  • Problema 75117 resolvido: Um utilizador pode observar quando a consulta do pacote de diagnóstico regista um grande número de entradas “DNS Cache Max Limit Reached. Falha ao adicionar entradas de cache” (DNS Cache Max Limit Reached. Failed to add cache entry) que aglomeram outras entradas de registo de maior importância.

    Num VMware SD-WAN Hardware Edge, se as consultas de DNS ultrapassarem os 32K, resulta num registo contínuo de DNS Cache que aglomera outras entradas de registo. Isto dificulta a capacidade de um utilizador de resolver outro problema ao consultar os registos num pacote de diagnóstico.

  • Problema 75121 resolvido: Um cliente pode observar um caminho inacessível para um fluxo de backhaul que leva a eliminações de pacotes.

    Existia um problema no código de pesquisa de fluxo de caminho do backhaul e interface que estava a captar o primeiro caminho mesmo que fosse inacessível. Como este caminho inacessível não é bom para transportar o pacote, os pacotes estavam a ser eliminados. A resolução determina uma verificação da capacidade de acesso do caminho para todos os tipos de fluxos.

  • 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 75309 resolvido: um utilizador pode observar uma queda de tráfego multicast num grupo específico num VMware SD-WAN Edge Spoke.

    O tráfego multicast num grupo específico não é recebido no Edge Spoke quando é proveniente de um Edge Hub. Os grupos IGMP não estão preenchidos na tabela de grupos IGMP do Edge Spoke, o que leva à perda de tráfego. Isto pode ser observado nos registos de pacotes de diagnóstico do Edge Spoke para o igmp. 

  • Problema 75578 resolvido: ao executar o “Estado da interface” 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 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 75772 resolvido: para um cliente que utilize o Edge Network Intelligence em que um VMware SD-WAN Edge tem a Análise ativa, o Edge pode ter uma fuga de memória que resulta no reinício do Edge para a limpar.

    Quando a Análise (Analytics) está ativada e o DHCP está ativado numa interface do Edge, os eventos de conectividade do cliente fazem com que a utilização da memória aumente. Durante um período de tempo suficiente, a utilização da memória pode chegar a um limiar crítico e o Edge reiniciaria defensivamente o serviço Edge para restaurar os níveis normais de memória.  Como em qualquer problema de fuga de memória, quanto menor for a pegada de memória inicial (por exemplo, um Edge 510, 520 ou 610) mais vulnerável é o reinício do 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 75968 resolvido: quando um utilizador configura o handoff de um endereço IP local para um VMware SD-WAN Gateway e, em seguida, remove esse handoff, o handoff não é removido do Gateway, o que faz com que o caminho do túnel fique inativo.

    Este problema pode causar grandes perturbações, uma vez que o Gateway não pode criar um novo túnel. 

    Sem a correção, o utilizador terá de reiniciar o Gateway para resolver o problema.

  • 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 “Tempo limite de vcgCommand excedido” (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 76005 resolvido: não é possível honrar uma regra NAT 1:1 depois de uma ligação WAN mudar repetidamente de ativada para desativada num VMware SD-WAN Edge.

    Ao procurar uma correspondência da regra NAT 1:1, se uma interface específica estiver inativa, será ignorada pelo Edge. Assim, se for criado um fluxo quando uma interface estiver inativa, mesmo que volte a ficar ativa, o Edge não a honrará.

  • 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 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 76564 resolvido:  para um local configurado com uma topologia de Alta Disponibilidade, quando a interface WAN do VMware SD-WAN Edge é ativada ou não ativada com a IU do VMware SD-WAN Orchestrator, o local pode sofrer um estado de “split-brain” Ativo/Ativo que é prejudicial para o tráfego do cliente.

    Quando as definições WAN de um Edge são alteradas, o serviço de rede do Edge é reiniciado, o que leva à perda temporária de pacotes HA. Tal faz com que o Orchestrator considere que o Edge ativo está inativo e promova o Edge em standby para ativo, o que, por sua vez, leva ao estado de “split-brain” Ativo/Ativo.

  • 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 76726 resolvido: um VMware SD-WAN Gateway pode encontrar uma falha no Serviço dataplane e gerar um núcleo.

    A causa da falha do serviço do Gateway e do núcleo prende-se com o facto de o pacote ctrl do protocolo de gestão ser trocado entre um Edge e o Gateway. O Gateway poderá falhar devido às afirmações e isso poderá causar uma paragem para vários clientes. Este problema é resolvido ao remover as afirmações e configurar o processamento adequado de erros.

  • 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.

    Nota: este é um seguimento do problema do Edge 51291 que, 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.  Caso contrário, o sintoma e a descrição são os mesmos, mas a correção aqui garante que os limiares de tensão persistem sobre qualquer atualização subsequente do Edge.

  • Problema 78252 resolvido: um VMware SD-WAN Edge pode registar uma falha no Serviço dataplane com uma mensagem SIGXCPU quando é implementado numa empresa de grande escala.

    Este problema é causado por um thread de trabalho do BGP/OSPF em execução com baixa prioridade estar a manter o bloqueio num objeto do qual os outros threads de alta prioridade estão à espera, o que resulta numa inversão da prioridade, originando a falha de serviço do Edge com a mensagem SIGXCPU.

  • Problema 78276 resolvido: num VMware SD-WAN Gateway, executar debug.py -qos_net falhará se o nome do VMware SD-WAN Edge incluir carateres não ASCII.

    Um exemplo prático deste problema foi a utilização de carateres chineses, mas aplica-se a todos os carateres não ASCII, e pode ser observado da seguinte forma: altere o nome de um Edge para incluir carateres não ASCII e reinicie o Edge. Em seguida, um Gateway ligado ao Edge executará o comando da CLI: “debug.py --lista 3”, para obter o ID lógico do Edge. Em seguida, execute o comando da CLI do Gateway: “debug.py -qos_net [logical ID] all stats” e o utilizador observará o comando a falhar.

  • 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 essas aplicações não é aplicada.

    Se não for atualizado para a versão 4.5.1, o operador poderá adicionar os IPs de speedtest necessários a um mapa de aplicações existente com o Editor de mapa de aplicação do VMware SASE Orchestrator.

  • 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 78678 resolvido: num site implementado com uma topologia de alta disponibilidade, o VMware SD-WAN Edge que desempenha a função Standby pode ser reiniciado quando processa mensagens de sincronização do Edge ativo.

    Quando o Edge de standby lida com um elevado número de mensagens de sincronização de fluxo, o serviço SD-WAN pode detetar uma condição de transbordo de buffer e desencadear um reinício do Edge de standby.

  • Problema 79132 resolvido: Para um VMware SD-WAN Edge configurado como um Spoke numa topologia Hub/Spoke, uma ligação pública apresenta a capacidade de largura de banda de descarregamento errada ao olhar para Monitorizar > Edge (Monitor > Edge) na IU VMware SASE Orchestrator.

    Para as ligações públicas do Spoke Edge, as estatísticas de ligações são carregadas com o valor medido em relação ao Hub Edge ligado do Spoke em vez do Gateway principal, que é depois enviado para o Orchestrator e apresentado para a largura de banda de descarregamento.

    Este problema é desencadeado quando o Gateway principal do Spoke Edge é reiniciado após o Spoke Edge estabelecer túneis Spoke/Hub. Assim, a única maneira de evitar este problema sem a correção é garantir que o Gateway não é reiniciado após estabelecimento de túnel com os Edges do Spoke e Hub.

  • 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 encaminhamento e 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.5.1.  É possível corrigir este problema para um cliente que não utilize a versão 4.5.1 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.5.1 garante que este problema não ocorre.

  • Problema 79572 resolvido: para um site implementado com uma topologia de alta disponibilidade, se um utilizador desativar a HA, o VMware SD-WAN Edge, agora autónomo, poderá ser desativado, perder o contacto com o VMware SASE Orchestrator e deixar de transmitir o tráfego inteiramente. 

    Quando a alta disponibilidade é desativada, o Edge standby aplica a configuração e passa para o estado desativado.  No entanto, devido a uma condição race, o Edge standby consegue, por vezes, enviar ao Orchestrator um heartbeat, o que induz em erro o Orchestrator e faz com que este envie uma ordem de desativação ao Edge ativo. Há um impacto significativo para o cliente quando este problema ocorre porque todo o tráfego do cliente é imediatamente removido e não é retomado até que um dos Edges seja reativado.

    Sem a correção, os clientes devem: a) desativar a HA numa janela de manutenção onde exista uma opção para alguém reativar o Edge, caso este problema ocorra, ou b) desativar e remover fisicamente o Edge standby da implementação do cliente e só então desligar a HA, uma vez que o Edge standby não conseguirá enviar o heartbeat falso que desencadeia o problema.

  • Problema 80006 resolvido: ao atualizar um VMware SASE Orchestrator ou um VMware SD-WAN Gateway, o script de atualização falha ao atualizar os módulos FIPS quando o sistema está no modo FIPS (modo=em conformidade).

    Os pacotes FIPS são copiados para uma localização especial do sistema (/var/lib/velocloud.fips) durante a atualização do sistema, mas o instalador do sistema não os recolhe. Para este problema, os repositórios FIPS não são atualizados no script de pré-instalação, pelo que não estão disponíveis novos pacotes durante o passo de atualização do sistema.

    Este problema não ocorre ao atualizar qualquer um dos componentes para a versão 4.5.1. No entanto, se um Operador atualizar um Orchestrator ou Gateway para uma versão sem a correção, o Operador terá de atualizar os módulos FIPS manualmente.

  • Problema 80010 resolvido: para a empresa de um cliente que utilize uma topologia Hub/Spoke em que o SD-WAN alcançável também está configurado, o caminho do Spoke para o Gateway (ao utilizar uma ligação WAN pública) através do caminho do Hub não é apresentado se o caminho do Spoke para o Hub for ponto a ponto.

    A funcionalidade SD-WAN alcançável, que é uma passagem para um Edge do Spoke se ligar a um Gateway através de um Hub ligado, não é suportada se o Edge do Spoke e o Edge do Hub estiverem ligados ponto a ponto (por outras palavras, o endereço IP do Spoke corresponde ao caminho ligado no Hub). A correção para este problema adiciona esta funcionalidade.

  • Problema 80196 resolvido: um VMware SD-WAN Gateway pode registar uma falha no Serviço dataplane com uma mensagem SIGXCPU 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 é verificado quando existe débito elevado nesse Gateway relativamente à capacidade de débito do mesmo, pelo que é mais provável que ocorra em implementações de grande escala (por exemplo, 4 mil Edges e 6 mil túneis).  Quando o tráfego a uma taxa elevada chega ao Gateway, em alguns casos, este registará um bloqueio de thread e gerará um núcleo durante o reinício. No núcleo, o utilizador verá: “Programa encerrado com sinal SIGXCPU, tempo limite da CPU excedido”.

  • 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 80897 resolvido: para uma empresa do cliente onde os VMware SD-WAN Edges estão ligados a Gateways de parceiro do VMware SD-WAN, os utilizadores podem observar um mau desempenho do tráfego do cliente.

    O mau desempenho é o resultado de problemas de routing decorrentes dos caminhos de distribuição do Gateway de parceiro para os Edges onde estão disponíveis caminhos estáticos seguros preferenciais, mas o Edge não identifica corretamente estes caminhos como seguros. O resultado é que o Edge pode anunciar caminhos não seguros não preferenciais em vez de caminhos seguros, uma vez que todos os caminhos são tratados da mesma forma quando o comportamento esperado é preferir sempre caminhos seguros em vez de caminhos não seguros.

    Nota: tanto o Gateway de parceiro como os Edges do cliente devem ser atualizados para uma compilação que inclua esta correção para resolver o problema.

  • 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.

  • Problema 81517 resolvido: Num site implementado com uma topologia de alta disponibilidade melhorada que utiliza os modelos VMware SD-WAN Edge 6x0, o estado de ligação HA não está a ser atualizado adequadamente.

    A ligação HA é a que liga o par HA Edge Melhorado e, se esta ligação não atualizar corretamente, o site pode ter problemas.

  • Problema 81575 resolvido: um VMware SD-WAN Gateway implementado com uma VM baseada em VMware OVA que utiliza NICs baseados em SR-IOV Intel x710 pode ter problemas de conetividade após uma atualização do software do Gateway.

    O problema surge porque os controladores de funções virtuais iavf do Linux não são instalados corretamente numa atualização do Gateway e, como resultado, os NICs baseados em SR-IOV x710 não funcionam no Gateway atualizado. Este problema não afeta um Gateway que utilize NICs baseados em Virtio ou VMNet.

  • Problema 81809 resolvido: quando um utilizador tenta aceder através de SSH a um IP VLAN num VMware SD-WAN Edge a partir de um cliente remoto por trás de outro Edge ou até mesmo por trás de um VMware SD-WAN Gateway, a tentativa de SSH falhará.

    Uma tentativa de SSH a partir de um cliente LAN para um IP Edge VLAN funcionará corretamente. Originalmente, foi utilizado o IP de Gestão do Edge para aceder através de SSH ao Edge. No entanto, após a descontinuação do IP de gestão do Edge, não havia opção para o utilizador aceder através de SSH ao Edge (através de overlay a partir de um cliente Edge), pois o IP de retorno continua sem suporte para SSH.

  • Problema 81920 resolvido: num VMware SD-WAN Gateway implementado com uma VM baseada em KVM que utiliza NICs baseados em SR-IOV Intel x710 pode ter problemas de conetividade após uma atualização do software do Gateway.

    O problema surge porque os controladores de funções virtuais iavf do Linux não são instalados corretamente numa atualização do Gateway e, como resultado, os NICs baseados em SR-IOV x710 não funcionam no Gateway atualizado. Este problema não afeta um Gateway que utilize NICs baseados em Virtio ou VMNet.

  • Problema 82182 resolvido: Para um Modelo VMware SD-WAN Edge 510 ou 510-LTE que esteja a executar a Versão 5.0.0.0 do Edge, 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 82314 resolvido: quando um VMware SD-WAN Gateway é atualizado, pode apresentar uma exceção com uma perda de conetividade ao utilizar NICs baseados em passagem PCIe Intel x710.

    Quando o Gateway é atualizado, parte da atualização é uma alteração do kernel, e a instalação do controlador i40e falha e não fica disponível no Gateway.  Devido à indisponibilidade dos controladores i40e, todos os NICs baseados em passagem PCIe x710 não vão funcionar corretamente no Gateway, resultando numa degradação do desempenho ou numa perda de conetividade. Este problema não afeta um Gateway que utilize NICs baseados em Virtio ou VMNet.

  • Problema 82522 resolvido: quando o tráfego de elevado débito chega a um VMware SD-WAN Edge, pode verificar-se uma queda no débito real observado no Edge.

    Com débito elevado, o thread do protocolo NDP (Neighbor Discovery Protocol) do Edge adquire um bloqueio duas vezes, mesmo para entradas do protocolo NDP que tenham sido marcadas como acessíveis, pelo que não é necessário mais processamento. Estes bloqueios duplicados fazem com que o débito diminua devido ao processamento adicional.

  • Problema 82790 resolvido: nos VMware SD-WAN Gateways implementados em ambientes do Azure, os contadores da interface do Gateway não são exportados para o serviço de monitorização Wavefront.

    O Azure é um ambiente onde o DPDK está desativado e apenas os contadores de interface do DPDK (taxa de débito, PPS e contadores de queda) são exportados para o serviço Wavefront. Este facto resulta em capacidades de monitorização reduzidas em plataformas como o Azure, em que o DPDK está desativado.

  • Problema 83029 resolvido: Para um VMware SD-WAN Edge autónomo ou um site implementado com uma topologia de alta disponibilidade onde são utilizadas uma ou mais ligações PPPoE, se o IP do ponto final PPPoE for alterado após ocorrer um flap na interface do Edge para essa ligação PPPoE ou quando um site HA tiver uma falha, o tráfego não passará nas ligações PPPoE afetadas.

    Num site que utiliza ligações PPPoE, em conjunto com uma alteração no IP do ponto final do PPPoE, o impacto significaria nenhum tráfego de clientes a passar. O problema é causado pela presença de um caminho predefinido, que é um caminho que utiliza o antigo endereço IP do ponto final PPPoE no Edge, que não é eliminado após recebido um novo endereço IP do ponto final do PPPoE.

    Sem a correção, um utilizador no local teria de desligar cada cabo PPPoE e voltar a ligá-lo para forçar uma renegociação ou reiniciar o Edge, o que também forçaria uma renegociação.

  • Problema 83402 resolvido: Num VMware SD-WAN Edge com várias ligações WAN, uma ou mais ligações WAN podem deixar de passar tráfego.

    Nas ligações WAN que deixam de passar tráfego, o endereço adquirido DHCP não é renovado e o endereço da interface WAN é perdido. O problema ocorre quando existem várias interfaces que adquirem endereços IP utilizando o DHCP e o servidor DHCP está numa rede diferente do cliente. A interface de saída de um pacote unicast de renovação DHCP é determinada através da procura de caminhos. Uma vez que existem vários caminhos predefinidos com diferentes valores de métricas aprendidos através de diferentes interfaces, os pacotes de pedidos DHCP podem ser enviados de uma interface diferente. 

    Sem a correção, um utilizador no local teria de a desligar e, em seguida, voltar a ligá-la na ligação WAN afetada a partir do Edge para a forçar a obter novamente o respetivo endereço IP.

  • Problema 83928 resolvido: Um VMware SD-WAN Edge pode sofrer uma elevada utilização da CPU e um fraco desempenho de tráfego do cliente. 

    Os utilizadores também poderiam observar pontuações QoE fracas ao consultar o ecrã Monitorizar > Edge > QoE (Monitor > Edge > QoE) do Orchestrator desse Edge. O problema é causado por uma regra da lista de controlo de acesso (ACL) que é instanciada várias vezes no Edge e está a forçar a capacidade da CPU do Edge a processar muitas regras ACL de uma só vez, o que faz com que o Edge não consiga processar o tráfego do cliente corretamente.

  • 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 84359 resolvido: quando uma interface do VMware SD-WAN Edge é ativada e desativada repetidamente, é possível que vários endereços IPv4 possam ser atribuídos à mesma.

    Quando uma interface, configurada com um cliente DHCP, é desativada e ativada repetidamente, todo o processo do cliente DHCP é executado novamente e poderá haver cenários em que um endereço IP diferente é adquirido de cada vez. Neste caso, o endereço IP mais antigo não é limpo nem ficará obsoleto.

    Sem esta correção, a única forma de remediar o problema é o utilizador eliminar manualmente os endereços IP da interface através da shell do Linux com o comando “ip address del”.

  • Problema 84825 resolvido: quando é aplicada uma grande configuração de encaminhamento em massa num VMware SD-WAN Edge num só passo, o Edge poderá experienciar falhas repetidas no Serviço dataplane, resultando em repetidos reinícios do serviço do Edge para recuperar de cada falha.

    Quando um Edge autónomo (não HA) se depara com este problema, há um impacto significativo no tráfego do cliente, porque embora um único reinício do serviço do Edge interrompa o tráfego durante cerca de 15 segundos, os reinícios repetidos resultam em interrupções de cerca de 60 segundos ou mais. Num site com topologia de Elevada disponibilidade, o cliente notaria uma recuperação automática repetida resultante dos reinícios do serviço do Edge, que também afetaria o tráfego.

    Este problema ocorre quando é aplicada uma configuração de encaminhamento em massa que envolve um grande número de vizinhos e mapas de caminhos a um Edge num único passo. O sistema do Edge enfrenta uma grande pressão ao converter estas configurações em especificações de comando e aplicá-las em protocolos de encaminhamento num curto espaço de tempo, o que provoca as repetidas falhas e reinícios do serviço do Edge.

    Numa compilação do Edge sem a correção, para mitigar o risco deste problema, o cliente teria de fazer o seguinte:

    • Em vez de aplicar uma configuração grande num único passo, a mesma deve ser dividida em várias secções menores com cada secção aplicada separadamente.
    • O número de filtros de encaminhamento deve ser minimizado.
    • O Edge só deve ser reiniciado deliberadamente numa janela de manutenção e o serviço do Edge deve ser, por norma, evitado se houver uma série de filtros de encaminhamento configurados, uma vez que toda a configuração do Edge é aplicada de uma só vez durante o reinício, o que aumentaria de forma considerável o risco de este problema ocorrer.
  • Problema 84847 resolvido: Os clientes que utilizam modems LTE baseados em USB ou modelos LTE VMware SD-WAN Edge (510-LTE ou 610-LTE) podem ter problemas intermitentes com túneis de criação na interface CELL após o reinício do modem. 

    Quando o modem LTE é reiniciado num dos seguintes cenários:

    Num Edge a utilizar um modem USB, ao remover e voltar a ligar ao modem na porta USB.

    Num Edge-LTE, após um reinício do Edge ou ao reiniciar a interface CELL1 através de Teste e Resolução de problemas > Diagnóstico remoto > Repor modem USB > CELL1 (Test & Troubleshoot > Remote Diagnostics > Reset USB Modem > CELL1).

    Em qualquer dos cenários, o dispositivo de rede subjacente muda de wwan0 para wwan1 e o Edge não respeita este novo nome porque parece ser uma interface duplicada.

    Sem a correção, a solução para restaurar a interface LTE é reiniciar o Serviço Edge através de Ações remotas > Reiniciar o serviço (Remote Actions > Restart Service).

  • Problema 86103 resolvido: Para uma empresa cliente que utiliza a autenticação RADIUS, os utilizadores clientes em determinados sites podem não conseguir ligar-se aos VMware SD-WAN Edges e passar o tráfego.

    Os problemas são causados pelo Edge que categoriza incorretamente os pacotes RADIUS fragmentados com o bit DF (Don't Fragment) definido no cabeçalho do IP como não fragmentado.  Um ou mais destes pacotes não conseguem aceder a vários Edges com o resultado de que o tráfego que depende da autenticação RADIUS não passará por esses Edges. Este problema pode ocorrer em qualquer topologia, incluindo Hub/Spoke e ramo a ramo simples.

    Sem a correção, a única solução alternativa é configurar o servidor RADIUS para não definir o bit DF no cabeçalho do IP enquanto envia pacotes fragmentados.

  • Problema 86314 resolvido: um VMware SD-WAN Edge pode efetuar uma pesquisa incorreta de regras de Firewall com estado quando o fluxo do 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 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 esta correção, a única forma de remediar o problema é reiniciar o serviço do Edge.

    Nota: nas edições das Notas da versão 4.5.1 até 22-08-2022, este problema foi apresentado como um problema conhecido. Isto não estava correto, uma vez que a correção do 86808 foi incluída na compilação GA original da versão 4.5.1 e o problema nunca esteve presente em qualquer compilação da versão 4.5.1.

Problemas resolvidos do Orchestrator

Resolvido na versão R451-20220831-GA do Orchestrator

A versão R451-20220831-GA do Orchestrator foi lançada a 06-09-2022 e é a terceira compilação rollup atualizada do Orchestrator para a versão 4.5.1. Esta compilação substitui a terceira compilação rollup original R451-20220810-GA, que foi lançada a 11-08-2022. A R451-20220831-GA não adiciona novos problemas resolvidos à R451-20220810-GA, mas inclui alterações de desempenho e resolução de problemas exigidas pela VMware Engineering.

Os clientes só devem utilizar a compilação R451-20220831-GA e não utilizar a R451-20220810-GA.

A compilação R451-20220831-GA aborda os seguintes problemas críticos desde o segundo rollup do Orchestrator, versão R451-20220612-GA.

  • Problema 80735 resolvido: quando um utilizador altera a configuração de um perfil que também está atribuído a um ou mais VMware SD-WAN Edges, os filtros do BGP ao nível do perfil são removidos.

    O utilizador veria “ERRO: ref. de filtro inválida” (ERR: invalid filter ref) na IU do VMware SASE Orchestrator nos locais onde o utilizador anteriormente podia ver os detalhes do filtro BGP. O impacto para a rede de um cliente que depende do BGP seria significativo e a única forma de restaurar os filtros BGP seria restaurá-los manualmente.

  • Problema 83507 resolvido: um VMware SASE Orchestrator atualizado para uma nova compilação continuava a utilizar a mesma versão mais antiga do software do servidor MySQL.

    O processo de compilação do Orchestrator estava a fixar a versão do servidor SQL que estava a ser utilizada, o que fez com que o software do servidor MySQL não incluísse as mais recentes correções de erros, que podem resultar em problemas de base de dados ao nível do Orchestrator.

  • 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 90067 resolvido: quando um VMware SASE Orchestrator é atualizado para 4.5.1 ou 5.0.0, o Operador pode observar problemas de utilização e carga de CPU elevada.

    Durante a atualização, o Orchestrator perde uma propriedade crítica do sistema: edge.learnedRoute.maxRoutePerCall.. Esta propriedade limita o número de eventos do protocolo de encaminhamento que podem ser recebidos pelo Orchestrator num dado momento. Na ausência desta propriedade, um Orchestrator poderia ser inundado com eventos do protocolo de encaminhamento que o colocam sob carga elevada podendo afetar o desempenho do Orchestrator. A correção garante que a propriedade do sistema edge.learnedRoute.maxRoutePerCall persiste após as atualizações do Orchestrator.

  • 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 92082 resolvido: um cliente que utilize o VMware Cloud Web Security pode observar que as regras de filtragem de conteúdos não honram o domínio configurado.

    As regras de filtragem de conteúdos substituem o domínio configurado fornecido se o utilizador tiver também selecionado TODAS em Categorias. Ou se o utilizador selecionar NENHUMA em Categorias, o assistente predefiniu esta escolha para significar TODAS as Categorias, daí que os domínios não foram honrados aqui também. Isto é provocado por um problema no assistente de filtragem de conteúdos e na API. Se o utilizador configurar, pelo menos, uma Categoria, o Domínio é honrado.

    Num Orchestrator sem esta correção, o utilizador teria de configurar categorias específicas juntamente com domínios e, então, o Orchestrator honraria os domínios na filtragem de conteúdos.

___________________________________________________________________

Resolvido na versão R451-20220612-GA do Orchestrator

A versão R451-20220612-GA do Orchestrator foi lançada a 13-06-2022 e é o segundo rollup do Orchestrator para a versão 4.5.1.

Esta compilação de rollup do Orchestrator aborda o problema crítico abaixo desde o primeiro rollup do Orchestrator, versão R451-20220520-GA.

  • Problema 86848 resolvido: quando um administrador do cliente faz uma tentativa de início de sessão falhada através do método Nativo (nome de utilizador/palavra-passe) na empresa do cliente no VMware SASE Orchestrator, o Orchestrator não regista a tentativa falhada na página Monitorizar > Eventos (Monitor > Events) da IU.

    O Orchestrator deve registar todas as tentativas de início de sessão, quer sejam bem-sucedidas ou não, de modo a garantir a devida responsabilização de todas as contas de utilizador e para que todos os administradores possam detetar atividades de início de sessão invulgares. O problema é causado pelo facto de o Orchestrator não incluir os metadados “enterpriseId” numa tentativa falhada de autorização de nome de utilizador/palavra-passe. Isto afeta apenas os utilizadores de clientes que utilizam a autorização Nativa (nome de utilizador/palavra-passe). As empresas de clientes que utilizam o início de sessão único (SSO) não são afetadas por este problema.

  • Problema 89800 resolvido: quando um utilizador atualiza a Propriedade do segmento (Segment Property) no VMware SASE Orchestrator, os túneis Edge para o Serviço de Segurança na Cloud Zscaler (CSS) ficam inativos e o tráfego encaminhado para o Zscaler é descartado.

    Se um utilizador tiver um CSS configurado em Configurar > Serviço de rede (Configure > Network Service) (qualquer tipo de CSS) e, em seguida, configurar os detalhes de autenticação FQDN e PSK em Configurar > Edge > Dispositivo > Serviço de Segurança na Cloud (Configure > Edge > Device > Cloud Security Service) com a Anulação de Edge (Edge Override), quando o utilizador atualizar qualquer segmento na secção Configurar > Segmento (Configure > Segment) do Orchestrator, a configuração de autenticação CSS do Edge é eliminada e o Edge já não consegue estabelecer ligação ao par Zscaler.

Problemas resolvidos do Orchestrator

Resolvido na versão R451-20220520-GA do Orchestrator

A versão R451-20220520-GA do Orchestrator foi lançada a 24-05-2022 e é o primeiro rollup do Orchestrator para a versão 4.5.1.

Esta compilação rollup do Orchestrator aborda o problema crítico abaixo desde a versão GA inicial R451-20220517-GA.

  • Problema 84214: Quando um utilizador operador estiver na página Gateways da IU de um VMware SASE Orchestrator, poderá não conseguir atribuir um Gateway em particular para a função Super Gateway.

    Quando um Gateway já está atribuído à função Super e à função Super Gateway alternativo, se o operador tentar editar a atribuição do Super Gateway de uma empresa na lista Utilização do cliente (Customer Usage) no ecrã Gateways > Configurar Gateways (Configure Gateways), a IU não encontrará corretamente os dados associados ao Super Gateway e a caixa de diálogo Atribuir Super Gateway (Assign Super Gateway) não será apresentada e apresentará um erro na consola. 

  • Problema 86546 resolvido: para clientes que utilizam o VMware Secure Access, um utilizador pode não conseguir utilizar o Secure Access em alguns PoPs SASE e outros podem até ser apresentados como offline no VMware SASE Orchestrator.

    Os Gateways VMware que não estão configurados para utilização com o Secure Access (por outras palavras, Gateways que não possuem um túnel Geneve com o servidor de túnel no PoP) também recebem informações sobre o serviço Secure Access pelo Orchestrator. Isto leva à escolha de um caminho inválido em alguns casos para encaminhar o tráfego de cliente. Este problema apenas pode ser encontrado quando mais de um Gateway é atribuído por PoP por Conjunto de Gateways num Orchestrator específico.

    Num Orchestrator que não possui a correção para este problema, a solução alternativa é adicionar e manter apenas um Gateway por PoP em cada Conjunto de Gateways, para que esse Gateway seja sempre escolhido pelo Secure Access e para o estabelecimento do caminho correto.

  • Problema 89349 resolvido: um utilizador que inicia sessão num VMware SASE Orchestrator que utiliza a compilação R451-20220517-GA do Orchestrator 4.5.1 observaria um contrato de licença beta na página de início de sessão.

    Um utilizador fica com a impressão errada de que está a utilizar uma compilação beta em vez de uma compilação GA qualificada do VMware SASE ao iniciar sessão no Orchestrator. A compilação R451-20220517-GA do Orchestrator é uma compilação GA autêntica, mas o contrato de licença beta foi deixado por engano e a respetiva apresentação é uma questão puramente estética.

Problemas resolvidos do Orchestrator

Resolvido na Versão R451-20220517-GA

Os problemas abaixo foram resolvidos a partir da Versão R450-20220502-GA do Orchestrator. 

  • Problema 45078 resolvido: ao configurar um VNF para um cliente no VMware SD-WAN Orchestrator, se um estado VNF for configurado ao nível do perfil de uma forma e, em seguida, configurado de uma forma diferente ao nível do site através da Anulação de Edge, quando a Anulação de Edge for desativada posteriormente, o site continuará a utilizar as definições de Anulação de Edge e não voltará às definições de perfil como esperado.

    Este problema ocorre ao configurar um parâmetro de inserção VNF num Perfil de configuração em que a definição oposta está configurada para um site que utiliza a Anulação de Edge e, posteriormente, a Anulação de Edge é desativada, mas a definição persiste.

  • Problema 53751 resolvido: a validação do caminho ligado nas definições de caminho estático falha numa VLAN sem cidrIp e cidrPrefix.

    O problema ocorre quando o utilizador cria uma VLAN sem um cidrIp e cidrPrefix.

  • Problema 54015 resolvido: O utilizador pode configurar um nome de pesquisa ICMP com caracteres especiais e scripts no VMware SASE Orchestrator.

    Ao configurar uma pesquisa ICMP com o script “<script>alert('test');</script>” e “test<script>alert('test');</script>” como entrada para a pesquisa ICMP, o nome apresenta o erro como “Um carácter não seguro “<” e “>” foi encontrado no campo ao guardar” (An unsafe character “<” and “>” was found in a field while saving).  O que deve ser devolvido é: {"error":{"code":-32603,"message":"script injection error"}}  

  • Problema 59784 resolvido: quando um utilizador está a tentar aceder a um ecrã num VMware SASE Orchestrator para o qual não tem permissões de acesso, é-lhe apresentado um ecrã vazio com um ícone de progresso infinito.  

    O utilizador não é redirecionado automaticamente para um ecrã “Acesso recusado” (Access Denied) quando tenta aceder a um ecrã/caminho proibido (por exemplo, Definições do dispositivo em que tenha a função só de leitura) através de uma “ligação profunda”, que é uma ligação que aponta para a secção proibida específica da empresa do cliente por oposição a carregar simplesmente a página principal.

  • Problema 62624 resolvido: o utilizador vê o nome do Cliente ao tentar desselecionar a caixa de verificação do Gateway de parceiro enquanto o Gateway de parceiro estiver a ser utilizado.

    Quando um utilizador desseleciona a caixa de verificação de Gateway de parceiro para um Gateway específico na IU do VMware SD-WAN Orchestrator enquanto o Gateway é utilizado por um ou mais clientes, assim como um perfil de cliente, o Orchestrator apresenta apenas o nome do Perfil e do Edge e não o nome dos clientes que estão a utilizar o Gateway.

  • Problema 67209 resolvido: ao configurar um Serviço de Segurança na Cloud (CSS) num VMware SASE Orchestrator, o Nome da cloud não é alinhado com o CSS configurado.

    A falta de alinhamento entre o Nome da cloud e o CSS pode causar confusão ao cliente.

  • Problema 67912 resolvido: o estado geral do túnel é diferente quando se olha para a página Serviços de rede (Network Services) e para a página Monitorização do Edge (Edge Monitoring) num VMware SASE Orchestrator.

    Quando um utilizador acede à página Monitorização do Edge (Edge Monitoring) e verifica o estado geral do túnel, pode observar um estado diferente do que está na página de monitorização dos Serviços de rede ao verificar o estado geral de um túnel na secção Serviço de Segurança na Cloud (CSS), o que provoca confusão quanto ao estado real desse túnel.

  • Problema 68387 resolvido: quando um utilizador tenta criar um novo utilizador operador ou administrador de cliente com um tipo não nativo (por outras palavras, um utilizador que não utilize um nome de utilizador/palavra-passe, mas sim a autenticação SSO ou RADIUS), o VMware SASE Orchestrator continua a exigir a introdução de uma palavra-passe para o novo utilizador.

    Quando um utilizador tenta criar um novo utilizador operador ou cliente, a IU do Orchestrator não limpa o campo de palavra-passe. Por seu lado, em vez de verificar primeiro se o tipo de utilizador é não nativo, o back-end executará uma verificação de força da palavra-passe e gerará um erro.

  • Problema 68463 resolvido: ao utilizar a nova IU no VMware SASE Orchestrator e olhar para a secção QoE, serão apresentados os valores do gráfico errado.  

    Ao entrar no QoE na IU antiga, é apresentada a mensagem “Latência razoável” (Latency Fair) no gráfico, pelo que quando visita a nova IU (para o mesmo Edge e hora) é apresentada “Distorção razoável” (Jitter Fair). Isto acontece porque o QoE está a ser incorretamente mapeado na nova IU.

    Sem a correção, a única solução é utilizar a IU antiga do Orchestrator para confirmar os valores de QoE corretos.

  • Problema 69181 resolvido: se um utilizador configurar um Gateway secundário protegido por IPsec na secção Definições do dispositivo > Handoff de Gateway (Device Settings > Gateway Handoff) do VMware SASE Orchestrator, o túnel IPsec não será estabelecido com o Gateway secundário protegido por IPsec.

    O utilizador não observaria a configuração IPsec aplicada e presente ao consultar debug.py --gateways.

  • Problema 69514 resolvido: a geração de relatórios pode falhar com o erro “Falha ao atualizar os dados de blobs para PDF” (Failed to update blob data for PDF).

    Quando o utilizador tenta criar um relatório offline, a geração do relatório falha com um erro interno. Isto acontecia devido a uma versão incorreta da biblioteca de geração de gráficos.

  • Problema 69534 resolvido: Para um cliente que utilize o VMware Edge Network Intelligence, quando um utilizador clica em qualquer lugar na página Monitorização (Monitoring) principal do cliente na nova IU do Orchestrator, as ligações de “Análise de aplicação” (Application Analytics) e “Análise de ramo” (Branch Analytics) desaparecem.

    Se o utilizador recarregar a página, essas ligações reaparecerão até o utilizador clicar em qualquer lugar na mesma página e, em seguida, desaparecerão novamente. Devido a isto, o utilizador não conseguirá ver os dados de monitorização de “Análise de aplicação” (Application Analytics) e “Análise de ramo” (Branch Analytics), a menos que saiba que tem de recarregar a página.

  • Problema 69869 resolvido: ao utilizar a nova IU no VMware SASE Orchestrator, a configuração BFD de um cliente será editável para os administradores de cliente mesmo quando o segmento selecionado não é delegado ao cliente.

    Quando a empresa de um cliente tem dois segmentos e o primeiro segmento é editável para os administradores de cliente e o outro não é delegado à empresa do cliente. A capacidade de configurar o BFD não é bloqueada quando um administrador do cliente muda do segmento editável para o segmento não editável.

  • Problema 69932 resolvido: ao utilizar a nova IU no VMware SASE Orchestrator, se um operador ou administrador de parceiro alternar entre clientes várias vezes, o comutador de aplicações (que seleciona SD-WAN/Cloud Web Security/Secure Access/Edge Network Intelligence) poderá desaparecer da IU.

    Além disso, ao alternar entre clientes, um cliente pode mostrar as definições do cliente anterior (por exemplo, ter o Cloud Web Security disponível quando esse serviço não estiver ativado para esse cliente.)

  • Problema 69981 resolvido: o estado geral do túnel é apresentado de forma diferente quando consulta a página Monitorizar > Edges (Monitor > Edges) versus a página Monitorizar > Serviços de rede (Monitor > Network Services) no VMware SASE Orchestrator.

    Quando um utilizador consulta a página Monitorizar > Edges (Monitor > Edges) e observa o estado geral de um túnel e, em seguida, compara esse estado com o que é visto na página Monitorizar > Serviços de rede (Monitor > Network Services), o utilizador poderá observar que o estado geral do túnel na secção Serviço de segurança na cloud (CSS) [Cloud Security Service (CSS)] não corresponderá ao estado visto na página Monitorizar > Edges (Monitor > Edges).

  • Problema 70018 resolvido: um VMware SD-WAN Orchestrator com a versão 4.3.0 ou superior pode não ser capaz de formar um par de recuperação de desastres.

    A origem do problema impede o Orchestrator de obter o tamanho do espaço livre em disco necessário para fazer o RD e o emparelhamento RD pode falhar como resultado, com a mensagem de erro “não há espaço em disco suficiente para copiar a BD”.

  • Problema 70350 resolvido: na nova IU do VMware SASE Orchestrator, qualquer utilizador pode configurar as definições do OSPF mesmo que não tenha privilégios para o fazer.

    A IU nova não inclui uma verificação de privilégios do utilizador para Definições do dispositivo > Configuração do OSPF (Device Settings > OSPF configuration).

  • Problema 70528 resolvido: as funções compostas personalizadas para um cliente não são apresentadas na secção de monitorização de sessão da página de autenticação do VMware SASE Orchestrator e não podem ser configuradas para limites de sessões.

    Este problema ocorre em Orchestrators com a versão 4.5.0, na qual a capacidade de função composta personalizada foi introduzida. Depois de criar uma função personalizada, o cliente não será capaz de configurar os limites de sessões para a função nova.

  • Problema 71242 resolvido: o utilizador não é capaz de configurar o BFD na IU do VMware SASE Orchestrator enquanto configura o Destino Não-SD-WAN (NSD) via Gateway.

    Ao configurar o NSD via Gateway em Configurar > Serviços de rede (Configure > Network Services), ao abrir a caixa de diálogo do BFD, a IU não oferece qualquer opção para configurar os parâmetros do BFD.

  • Problema 71778 resolvido: Quando um VMware SASE Orchestrator implementado numa topologia de Recuperação após desastre (DR) é atualizado para a Versão 4.5.0, um operador não consegue trocar manualmente os gateways para um objeto de Destino Não-SD-WAN (NSD).

    A chamada da API para mudar o Gateway começou a impor a validação do pedido a partir da 4.5.0, no entanto o cliente da IU do Orchestrator não forneceu um parâmetro necessário para a API.

  • Problema 71898 resolvido: Ao configurar um Serviço RADIUS, se um campo de configuração ficar vazio e o utilizador tentar guardar a configuração, a IU do VMware SASE Orchestrator apresenta um erro geral.

    A mensagem de erro “Ocorreu um erro inesperado” (An unexpected error has occurred) não apresenta quaisquer informações ao utilizador sobre o que precisa de ser corrigido. Além disso, o campo de configuração que precisa de ser corrigido não está realçado.

  • Problema 72039 resolvido: Ao trabalhar na página Configurar > Dispositivo do VMware SASE Orchestrator, o utilizador não consegue classificar as funcionalidades por aquelas que são conscientes de segmento e aquelas que são agnósticas de segmento.

    Algumas definições do dispositivo são aplicadas em segmentos versus aquelas que devem ser configuradas para cada segmento e não existe uma forma de ordenar apenas a IU para visualizar essas definições de modo a facilitar a utilização.

  • Problema 72444 resolvido: quando um utilizador configura os vizinhos BGP IPv4 e IPv6 para um VMware SD-WAN Edge e, em seguida, tenta desativar as definições BGP com o botão de deslize Ativar/Desativar, a configuração não é guardada e a IU do VMware SASE Orchestrator mostra “Nenhuma alteração” (No Changes).

    No caso raro em que um utilizador está a configurar a definição do BGP, mas também a desligá-lo, as ações dos utilizadores não são guardadas para as definições BGP como deveriam.

  • 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 74251 resolvido: O VMware SD-WAN Edge não honra o número de porta numa regra NAT do lado LAN que foi configurada através da API do Orchestrator.

    Este problema NÃO afeta os utilizadores que configuram as regras NAT do lado de LAN através da IU do Orchestrator. A porta configurada como parte da regra NAT do lado LAN não é emitida corretamente pelo VMware SASE Orchestrator para o Edge. Nos casos de uma regra NAT do lado LAN configurada através do método API updateConfigurationModule e um valor de cadeia passado para “insidePort” ou “outsidePort”, a API do Orchestrator permitiu anteriormente o pedido. No entanto, o Edge não honra esses valores de cadeia (em vez disso espera números inteiros). A lógica de validação da API do Orchestrator foi modificada para rejeitar valores de cadeia (e agora comporta-se de uma forma consistente com o que já estava documentado na referência da API).

  • Problema 74592 resolvido: As consultas de estatísticas de ligação de um período de tempo mais longo (por exemplo, um ano) demoram muito tempo a devolver um resultado no VMware SASE Orchestrator.

    As consultas demoram muito tempo devido à ausência do enterpriseLogicalID e o Orchestrator não possuir verificações suficientes no código para garantir o formato do carimbo de data/hora.

  • 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 75431 resolvido: ao examinar uma configuração de Destino Não-SD-WAN (NSD) na nova IU do VMware SASE Orchestrator, o “ID de autenticação local” (Local Auth ID, informações FQDN) está em falta.

    Um utilizador que navegue para Monitorizar > Serviços de rede > Destinos Não-SD-WAN via Gateway (Monitor > Network Services > Non SD-WAN Destinations via Gateway) e que selecione, em seguida, Detalhes (Details), não veria o campo “ID de autenticação local” (Local Auth ID) que contém as informações do FQDN.  Esta informação é apresentada corretamente na IU Clássica.

  • Problema 75656 resolvido: em alguns casos, depois de processar os eventos de encaminhamento de um VMware SD-WAN Edge, o VMware SASE Orchestrator responde com uma confirmação vazia (que é tão mau quanto não receber nenhuma resposta), o que resulta num aumento da carga no Orchestrator.

    Quando um Orchestrator envia um ack vazio para os eventos de routing de um Edge, o Edge tenta utilizar repetidamente os caminhos, causando o aumento da carga no Orchestrator.

  • Problema 75879 resolvido: em alguns casos, o VMware SASE Orchestrator não responde aos eventos de encaminhamento de um VMware SD-WAN Edge, o que resulta num aumento da carga no Orchestrator.

    Quando um Orchestrator não responde aos eventos de routing de um Edge, o Edge tenta utilizar repetidamente os caminhos, causando o aumento da carga no Orchestrator. Esta é a correção permanente para este problema.

  • 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 ativo/inativo no túnel no Edge ao mesmo tempo, o VMware SASE Orchestrator pode não gerar alertas para todos os eventos.

  • Problema 76001 resolvido: as datas dos gráficos nas páginas Monitorizar > Edges (Monitor > Edges) podem diferir ligeiramente entre a IU clássica e as interfaces de utilizador no VMware SASE Orchestrator.

    Se um utilizador navegar para a página de lista Monitorizar Edges, tanto na IU clássica como na nova, e, em seguida, selecionar um Edge e visualizar o separador Transporte (Transport) (IU clássica) ou Ligações (Links) (IU nova), reparará que as horas não correspondem exatamente.

  • Problema 76008 resolvido: Ao clonar uma empresa num VMware SASE Orchestrator, se o Perfil de Operador escolhido não for originalmente atribuído à empresa-mãe, a operação de clonagem falha.

    Se a nova empresa for atribuída a uma imagem de software que não seja atribuída à empresa que está a ser clonada, a chamada da API irá falhar com um erro.

    Sem a correção, a solução para este problema consiste inicialmente em atribuir à nova empresa a mesma imagem de software da empresa clonada e, posteriormente, alterar para o perfil de operador pretendido.

  • Problema 76016 resolvido: quando um handoff de Gateway de parceiro é configurado após a atualização de um VMware SASE Orchestrator para a versão 4.3.0 ou posterior, os subcomponentes no handoff, como os caminhos estáticos/BGP/BFD, não podem ser eliminados a partir da API ou da IU do Orchestrator por um Administrador de parceiro.

    Este problema ocorria devido a uma regressão na lógica de processamento da configuração de subcomponentes para eliminação no back-end do Orchestrator. Anteriormente, foi adicionada uma correção para conjuntos de Gateways mistos (Gateways de cloud + parceiro) em que, se um Administrador de parceiro modificasse um Gateway de parceiro, tal não afetava a configuração de handoff do Gateway de cloud. No entanto, esta correção não tinha em conta os casos que envolviam a eliminação de subcomponentes.

    Sem a correção, existem duas soluções alternativas: a) o parceiro poderá solicitar que um utilizador operador (por exemplo, o Suporte VMware) realize a eliminação sem qualquer problema. Afeta apenas os utilizadores MSP; ou b) todo o handoff do Gateway de Parceiro poderá ser removido e recriado com a configuração revista.

  • Problema 76078 resolvido: Alguns privilégios de função são removidos se um VMware SASE Orchestrator for atualizado para 4.5.0. Se o pacote de personalização de função incluir essa lista de privilégios, o pacote não será aplicado no Orchestrator.

    Depois de uma atualização do Orchestrator de uma versão inferior para 4.5.0, o Orchestrator não aplica pacotes de personalização de função existentes quando a lista de privilégios removidos no 4.5.0 está disponível nesse pacote.

  • 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 77515 resolvido: Quando um Administrador de parceiro com uma função Superutilizador atribui uma imagem de software a um cliente na página Configurar > Cliente (Configure > Customer), surge um erro ao tentar guardar a alteração e a ação falha.

    Para um utilizador parceiro durante o registo do evento “Modificou a lista de imagem de software atribuída” (Modified the assigned software image list) para atualizar “Imagens de software/firmware atribuídas” (Assigned Software/Firmware Images), se nenhuma Imagem de software/firmware tiver sido removida para esse evento em “removedSoftwareImages”, significa que estava a processar e a listar imagens de todos os módulos imageUpdate presentes em VELOCLOUD_CONFIGURATION_MODULE para o operador em particular. Com efeito, a lógica é quebrada para este processo quando um utilizador parceiro executa a ação e isto causa o erro e a falha ao alterar a imagem de software padrão 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 79981 resolvido: alguns termos da interface de utilizador em versões localizadas da IU do VMware SASE Orchestrator carecem de clareza para os clientes de todo o mundo que veem versões não inglesas da IU.

    As traduções dos termos da interface foram melhoradas no Orchestrator 4.5.1. Estas melhorias derivam do feedback dos clientes e resultam numa tradução da interface do utilizador globalmente melhorada para os clientes globais.

  • Problema 80197 resolvido: quando um utilizador cria túneis (GRE) do novo Serviço de Segurança na Cloud (CSS) para o Zscaler, a partir da perspetiva do VMware SD-WAN Edge e do ponto de vista do Zscaler, esses túneis foram implementados com sucesso e os eventos dos túneis são visíveis, mas o estado dos mesmos não é mostrado no VMware SASE Orchestrator.

    A opção predefinida de protocolo de túnel para a implementação automatizada é IPsec. Quando o utilizador seleciona a opção GRE e alterna a implementação automatizada para “Verdadeiro” (True), a opção predefinida é guardada como GRE, o que faz com que os registos do Destino Não-SD-WAN sejam ignorados e que os eventos de túneis perdidos sejam monitorizados.

    Sem a correção, o utilizador precisará de criar um fornecedor de CSS sem nunca ter de utilizar a caixa de verificação Protocolo de túnel (Tunneling Protocol).

  • Problema 80930 resolvido: se um utilizador adicionar uma nova Política empresarial à empresa de um cliente que utiliza Destinos Não-SD-WAN (NSD) através do Edge onde estão configurados túneis IPsec, poderão ser criadas entradas duplicadas no túnel IPsec.

    Quando este problema ocorre, as entradas duplicadas podem ser observadas na secção Configurar > Definições do dispositivo > Ramo a Destino Não-SD-WAN via Edge (Configure > Device Settings > Branch to Non SD-WAN Destination via Edge) da IU do Orchestrator quando é adicionada uma política empresarial. Estas entradas duplicadas têm de ser eliminadas e os detalhes da configuração têm de ser reintroduzidos quando este problema surgir.

  • Problema 80963 resolvido: Ao alterar o intervalo de intervalos de tempo no separador Edge > Monitorizar > QoE (Edge > Monitor > QoE), uma amostra refletida num carimbo de data e hora pode mudar e passar para um novo carimbo de data e hora, dependendo do intervalo de intervalos de tempo selecionado.

    Um problema de arredondamento nos tamanhos da amostra faz com que os carimbos de data e hora se alterem mais cedo para intervalos de tempo mais longos consultados no separador QoE. Por exemplo, um evento que ocorreu às 10:02 será apresentado adequadamente para pequenos intervalos de tempo (por exemplo, uma hora), mas quando é consultado um intervalo de tempo maior (por exemplo, seis horas), a amostra pode aparecer mais cedo às 10:00, o que resulta em confusões para o utilizador.

  • Problema 81835 resolvido: a página Monitorizar > Edge > QoE (Monitor > Edge > QoE) da IU do VMware SASE Orchestrator pode não representar com precisão o estado de uma ligação WAN (seja online, offline ou degradada) ou representar com precisão as métricas da ligação para o período selecionado. 

    Intervalos de tempo diferentes podem fazer com que o gráfico QoE apresente resultados diferentes para o estado de uma ligação WAN. E, para as métricas de uma ligação, o gráfico QoE pode apresentar um valor QoE específico (latência, perda ou distorção) que não reflete o valor da métrica real nessa hora exata.

    Este problema é provocado pelo facto de estar a ser atribuído o mesmo ID lógico de ligação a várias ligações WAN pertencentes a diferentes empresas, o que causa uma falha no processo de pós-aprovisionamento dos dados da ligação do Orchestrator. O Orchestrator assume erradamente que o ID lógico de ligação WAN é exclusivo porque não está ligado ao ID da empresa de um cliente. Isto permite duplicar os IDs lógicos de ligação e a possibilidade de métricas e estados de ligação incorretos.

    A correção para este problema armazena as chaves da ligação na base de dados do Orchestrator como uma combinação do ID lógico da empresa do cliente e do ID lógico da ligação WAN, o que garante que cada ligação WAN é exclusiva.

  • Problema 82725 resolvido: Um VMware SASE Orchestrator pode não gerar corretamente a ligação de reposição da palavra-passe.

    Este problema ocorre quando o URL para o Orchestrator não é exatamente https://domain/ ou https://domain/operator/.  No entanto, se, por exemplo, o URL for https://domain/test/ a ligação de reposição de palavra-passe não funcionará e será direcionado de volta para a página de início de sessão.

    Nos Orchestrators sem a correção: se o URL do Orchestrator não puder ser corrigido para um URL conforme apresentado acima, a única opção é que um Superutilizador ou Operador introduza manualmente uma nova palavra-passe para o utilizador e, em seguida, partilhe-a com o utilizador afetado para que possa, por sua vez, reconfigurar uma palavra-passe diferente para si mesmo uma vez que tenha iniciado a sessão com sucesso.

  • Problema 82839 resolvido: se um utilizador realizar uma ação de eliminação de automatização de IPsec para um túnel do Serviço de Segurança na Cloud Zscaler num VMware SASE Orchestrator, essa ação também eliminará todas as credenciais de VPN associadas à respetiva localização do Zscaler, resultando na eliminação da própria localização.

    A ação de eliminação da automatização de IPsec só deve eliminar a credencial de VPN que lhe está associada a partir da localização do Zscaler. Todas as outras credenciais de VPN associadas à respetiva localização do Zscaler devem permanecer intactas

  • 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 83699 resolvido: quando um VMware SD-WAN Gateway está definido para o modo desligado na nova IU do VMware SASE Orchestrator, quando o utilizador seleciona um novo Gateway de substituição, o Orchestrator não permite alterações de configuração no mesmo.

    Este problema ocorre depois de ativar o processo de migração do Destino Não-SD-WAN através da nova IU do Orchestrator, sendo que parte desse processo é selecionar um novo Gateway, que é aquele que substituirá o Gateway desligado. Quando o novo Gateway for designado como o Gateway de substituição, ao tentar efetuar qualquer alteração de configuração no Gateway de substituição, o Operador observará uma mensagem de erro semelhante a: “GATEWAY_SERVICE_STATE_INVALID: Não é possível alterar o estado do gateway para nulo, porque já está a ser utilizado como gateway de substituição”.

Problemas resolvidos do Cloud Web Security

Resolvido na Versão R451-20220517-GA

Os problemas abaixo foram resolvidos a partir da versão R450-20220502-GA. 

  • Problema 69211 resolvido: ao adicionar uma regra para filtragem de URL ao serviço Cloud Web Security, a IU apresenta totalmente o pedido de nome de domínio para Selecionar origem e destino (Select Source and Destination). 

    O domínio deve ser totalmente apresentado para garantir que foi configurado sem erros.

  • Problema 69346 resolvido: um utilizador consegue eliminar uma política do Cloud Web Security que esteja associada ao tráfego do Secure Access.

    O utilizador navegou para a IU do Cloud Web Security e para o separador Configurar (Configure) e seleciona uma Política de segurança que está associada ao tráfego do Secure Access e opta por eliminá-la, a tentativa é bem -sucedida, embora devesse falhar e emitir um erro.

  • Problema 69959 resolvido: a perda de tráfego é observada quando o serviço VMware Cloud Web Security é ativado.

    Depois de um utilizador ativar ou desativar o Cloud Web Security, os caminhos predefinidos para o Cloud Web Security são marcados como Falsos, apesar de a pesquisa estar a funcionar, e devido à capacidade de alcançar os caminhos do CWS não ser atualizada, o resultado é a remoção do tráfego.

  • Problema 70005 resolvido: ao utilizar o VMware Cloud Web Security, um utilizador pode editar uma Política de segurança existente e mudar o nome da mesma para um nome em branco ou vazio e guardá-lo.

    Um utilizador não pode criar uma Política de segurança com um nome vazio/em branco, mas pode editar uma política existente para configurar o nome de modo a que fique em branco e o Orchestrator permite a mudança e não emite nenhum erro.

  • Problema 71073 resolvido: para os clientes que utilizam o serviço VMware Cloud Web Security, se o CASB estiver configurado como desativado para a empresa de um cliente, um administrador do cliente continuará a ver uma IU do VMware SASE Orchestrator que inclui essa funcionalidade.

    Afeta apenas os administradores de clientes. Os operadores e administradores de parceiros verão o ecrã correto da IU.

  • Problema 74013 resolvido: o VMware SASE Orchestrator não se ajusta a uma alteração na licença CASB de Avançada para Padrão.

    Se um cliente começar com uma licença CASB Avançada e configurar uma regra específica para essa licença e, se posteriormente o cliente for mudado para uma licença CASB Padrão, o utilizador poderá alterar a regra criada pela licença CASB Avançada e aplicar as alterações.

  • Problema 86083 resolvido: para um cliente que utiliza o serviço VMware Cloud Web Security, o Registo de eventos do Cloud Web Security tem detalhes importantes em falta.

    O Registo de eventos não inclui os seguintes detalhes:

    • Para alterações de configuração, o nome de utilizador é incluído no evento, mas não é incluída a alteração que foi feita.
    • Quando uma regra do Cloud Web Security é eliminada, o Orchestrator não inclui os dados eliminados com o evento.
    • Ativar ou desativar a autenticação não inclui um carimbo de data/hora do evento.
    • Para eventos CASB, apenas é incluído o ID da aplicação e não o nome da aplicação.
Problemas resolvidos do Secure Access

Resolvido na Versão R451-20220517-GA

Os problemas abaixo foram resolvidos a partir da versão R450-20220502-GA. 

  • Problema 70493 resolvido: quando um cliente edita a configuração de um serviço VMware Secure Access e desativa/remove a associação a uma política do Cloud Web Security, não será possível guardar a configuração.

    Editar a configuração de um serviço Secure Access quando uma política do Cloud Web Security está a ser removida falha com um erro “Política do CWS inválida” (Invalid CWS Policy).

  • Problema 71078 resolvido: um cliente pode observar que a edição de uma implementação do Secure Access falha quando os bits de sub-rede do cliente são modificados, fazendo com que o serviço Secure Access seja inutilizável.

    Sem uma correção, o cliente pode eliminar o serviço SA existente e recriá-lo com as novas sub-redes do cliente, o que fará com que a implementação seja bem-sucedida.

  • Problema 70098 resolvido: a implementação de um serviço Secure Access VMware é concluída, mas não consegue obter a configuração a partir do tráfego de encaminhamento OU da UEM.

    O VMware Gateway recebe a configuração “ras” como parte da configuração do plano de controlo. No entanto, a configuração é vista como estando vazia para todos os serviços Secure Access associados a um Gateway.  Este problema é provocado por um erro de análise introduzido pelas recentes alterações no objeto da empresa Secure Access para verificação da integridade do serviço de túneis.

Problemas conhecidos

Problemas em aberto na versão 4.5.1

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 25595:

    Poderá ser necessário um reinício para que as alterações ao SLA estático num overlay WAN funcionem corretamente.  

    Solução alternativa: Reinicie o Edge após adicionar e remover o SLA estático do overlay WAN

  • 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. Reativar e, em seguida, desativar o caminho 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 34254:

    Quando o CSS Zscaler é criado e o segmento global tem definições de FQDN/PSK configuradas, estas definições são copiadas para segmentos não globais para formar túneis IPsec para um CSS Zscaler.

  • 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 39374:

    alterar a ordem dos Gateways de parceiro do VMware SD-WAN atribuídos a um VMware SD-WAN Edge pode não definir corretamente o Gateway 1 como o Gateway local a ser utilizado para o teste de largura de banda.

  • 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 39659:

    Num site configurado para alta disponibilidade melhorada, com uma ligação WAN em cada VMware SD-WAN Edge, quando o Edge em espera tem apenas o PPPoE ligado e o Edge ativo tem apenas não-PPPoE ligado e é possível um estado de brain state (ativo/ativo) se o cabo HA falhar.

  • 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 através da mesma fiquem parados.

  • 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 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, em seguida, reativar a interface no VMware SD-WAN Orchestrator.

  • Problema 42488:

    Num VMware SD-WAN Edge em que o VRRP está ativado para uma porta comutada ou encaminhada, se o cabo estiver desligado da porta e o Serviço do Edge for reiniciado, os caminhos ligados da LAN serão anunciados.

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

  • 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 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 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 46137:

    Um VMware SD-WAN Edge a executar o software 3.4.x não inicia um túnel com encriptação AES-GCM, mesmo que o Edge esteja configurado para GCM.

  • 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.

    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 46918:

    Um Spoke Edge do VMware SD-WAN que utiliza a versão 3.4.2 não atualiza corretamente o ID de rede privada de um nó do Hub de Cluster.

  • Problema 47084:

    Um VMware SD-WAN Hub Edge não pode estabelecer mais de 750 vizinhos PIM (Multicast Independente de Protocolo) quando tem 4000 Spoke Edges anexados.

  • Problema 47664:

    numa configuração de Hub e Spoke onde a VPN ramo a ramo através do Hub não está ativada, tentar inverter o sentido do tráfego ramo a ramo com um caminho resumido num switch/router L3 provocará ciclos de routing.

    Solução alternativa: configure a VPN de cloud para permitir a VPN ramo a ramo e selecione “Utilizar Hubs para VPN” (Use Hubs for VPN).

  • 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 47787:

    Um Spoke Edge do VMware SD-WAN configurado com uma política empresarial de backhaul enviará incorretamente tráfego através do caminho do VMware SD-WAN Gateway se o fluxo for iniciado a partir do Edge Hub para esse Spoke Edge.

  • Problema 48166:

    Um Edge Virtual do VMware SD-WAN em KVM não é suportado ao utilizar um SO de virtualização da Ciena e o Edge sofrerá falhas recorrentes do Serviço dataplane.

  • Problema 48175:

    Um VMware SD-WAN Edge a executar a versão 3.4.2 formará uma contiguidade OSPF num segmento não global, caso o segmento não global tenha uma interface configurada no mesmo intervalo de IP que a interface configurada no segmento global

  • Problema 48502:

    Em certos cenários, um VMware SD-WAN Hub Edge que está a ser utilizado para efetuar o backhaul do tráfego de Internet pode sofrer uma falha do Serviço dataplane devido a um processamento incorreto dos pacotes de retorno de backhaul.

  • 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 ficará 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 48666:

    O cálculo da MTU de Caminho do Gateway de IPsec de front-end não contabiliza o overhead de 61 bytes do IPsec, o que resulta num anúncio da MTU mais elevado para o cliente LAN e a subsequente fragmentação do pacote IPsec.

    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 51436: num local que utilize uma topologia de Alta Disponibilidade melhorada ao implementar um VMware SD-WAN Edge com um modem LTE, se o local entrar num estado duplo (split-brain), a recuperação automática de HA demorará cerca de 5 a 6 minutos.

    Como parte da recuperação de um estado duplo (split-brain), as portas LAN são inativadas no Edge ativo e isto tem impacto sobre o tráfego LAN durante o tempo em que as portas estão inativas e até que o local consiga recuperar.

    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 53359: a sessão BGP/BFD pode falhar durante alguns cenários de ataque DDoS.

    Se ocorrer um flood de tráfego no cliente ligado à interface encaminhada para o cliente LAN, a sessão BGP/BFD poderá falhar. Adicionalmente, quando ocorre um flood de tráfego de alta prioridade em tempo real para o destino de camada superior, a sessão BGP/BFD pode falhar.

    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 realizando uma opção de “Atualização” (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 vizinhanças BGP multihop no lado LAN, o cliente poderá sofrer situações de tráfego ignorado num Spoke Edge quando existir uma falha do lado LAN ou quando o BGP não for ativado 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 não está ativado para todos os segmentos e quando existem uma ou mais vizinhanças BGP multihop.

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

  • Problema 57210: mesmo quando um VMware SD-WAN Edge está a funcionar normalmente e é capaz de aceder à Internet, o LED na página Visão geral (Overview) da IU local é apresentado como “Vermelho” (Red).

    A IU local do Edge determina a conetividade do Edge com base na capacidade do mesmo para resolver um nome conhecido através da resolução de DNS do Google (8.8.8.8). Se não o conseguir por qualquer motivo, pensa que está offline e apresenta o LED como vermelho.

    Solução alternativa: não existe uma solução alternativa para este problema, exceto garantir que o tráfego DNS para 8.8.8.8 consegue alcançar o destino e ser resolvido com sucesso.

  • Problema 61543: se mais de uma regra NAT 1:1 for configurada em interfaces diferentes com o mesmo IP interno, o tráfego de entrada poderá ser recebido numa interface e os pacotes de saída do mesmo fluxo poderão ser encaminhados através de interfaces diferentes.

    Para os fluxos NAT de Fora para Dentro, as regras NAT 1:1 serão correspondidas com o IP externo e a interface onde os pacotes são recebidos. Para os pacotes de saída do mesmo fluxo, o VMware SD-WAN Edge tentará fazer corresponder novamente as regras NAT comparando o IP Interno e o tráfego de saída poderá ser encaminhado através da interface configurada na primeira regra de correspondência com “Tráfego de Saída” (Outbound Traffic) ativado.

    Solução alternativa: não existe uma solução alternativa para este problema, para além de garantir que não está configurada mais de uma regra NAT 1:1 com um endereço IP interno específico.

  • 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 não está ativado 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.

    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 63629: numa topologia de rede na qual o VMware SD-WAN Hub Edge e o Spoke Edge têm preferências diferentes de família de IPs (ou seja, pilha dupla IPv4/IPv6), o cliente pode ver mais largura de banda atribuída ao par do que o esperado.

    Se ambas as famílias IPv4 e IPv6 estiverem ativadas, o Edge criará internamente dois objetos de ligação diferentes. Os valores de largura de banda são adicionados para ambos quando deveriam ser adicionados apenas para um.

    Solução alternativa: a solução alternativa para este problema é não ter preferências diferentes de túneis se a topologia Hub/Spoke tiver a pilha dupla ativada.

  • Problema 64627: um VMware SD-WAN Gateway pode sofrer um reinício do Serviço dataplane, provocando 3 a 5 segundos de interrupção do tráfego.

    Quando existe um grande número de subcaminhos configurados nas ligações WAN de um VMware SD-WAN Edge ou existem flaps frequentes dos túneis do plano de gestão do VeloCloud (VCMP), isto pode levar à exaustão dos contadores e ao reinício do Serviço dataplane final do Gateway.

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

  • Problema 65560: o tráfego de um cliente para o dispositivo PE (Edge do Fornecedor) falha.

    A vizinhança BGP entre um Gateway de parceiro e o Edge do Fornecedor não é estabelecida quando o tipo de etiqueta é selecionado como “nenhum” na configuração de passagem de informação. Isto porque os valores ctag e stag são escolhidos em /etc/config/gateway e não na configuração da passagem de informação no Orchestrator quando o tipo de etiqueta é “nenhum”.

    Solução alternativa: atualize os valores ctag e stag para 0 cada em vrf_vlan->tag_info em /etc/config/gatewayd. Efetue um reinício vc_procmon.

  • Problema 67879: Um túnel do Serviço de Segurança na Cloud (CSS) é eliminado depois de um utilizador alterar uma definição de overlay WAN na deteção automática para definida pelo utilizador numa definição da interface WAN.

    Depois de guardar as alterações, os túneis CSS não voltam a ficar ativos sem que o cliente desative os túneis e volte a ativá-los. A alteração da configuração WAN desativará o túnel CSS e analisará novamente a configuração do CSS. Todavia, em alguns casos, nvs_config->num_gre_links é 0 e o túnel CSS não fica ativo.

    Solução alternativa: desativar e, em seguida, reativar a configuração do CSS ativará o túnel CSS.

  • Problema 68057: o pacote da versão DHCPv6 não é enviado do VMware SD-WAN Edge quando se altera o modo de endereço da interface WAN de DHCP com estado para endereço IPv6 estático e a concessão permanece ativa até atingir o tempo válido correspondente.

    O cliente DHCPv6 tem uma concessão que não é libertada quando a configuração é alterada. A concessão permanece válida até a sua vida útil expirar no servidor DHCPv6 e ser eliminada.

    Sem a correção, não há forma de remediar este problema, uma vez que a concessão permanece ativa até ao fim da sua vida útil.

  • Problema 68851: se um VMware SD-WAN Edge e VMware SD-WAN Gateway tiverem o mesmo servidor TCP syslog configurado, a ligação TCP não será estabelecida do Edge para o servidor syslog.

    Se o Edge e o Gateway tiverem cada um o mesmo servidor TCP e se os pacotes syslog do Edge forem encaminhados através do Gateway, o servidor syslog enviará uma redefinição do TCP para o Edge.

    Solução alternativa: envie os pacotes syslog diretamente do Edge em vez de os encaminhar através de um Gateway ou configure um servidor syslog diferente para o Edge e o Gateway.

  • Problema 69284: num site que utilize a topologia de elevada disponibilidade no qual os Edges implementem VNF numa configuração HA e com a versão 4.x, se estes Edges HA forem mudados para a versão inferior 3.4.x, que não suporta a VNFs HA e, em seguida, atualizados para 4.5.0, com a VNF HA ativada, o Standby Edge VNF não será ativado. 

     O estado VNF no Standby Edge é comunicado como inativo através do SNMP. Se o par VNF HA for mudado para uma versão anterior a partir de uma versão que suporte VNF-HA (versão 4.0+) para uma versão que não a suporte com a VNF ativada no Orchestrator. Este problema ocorre quando o Edge é atualizado para uma versão que suporta a VNF-HA e é ativado no Orchestrator novamente.

    Solução alternativa: a VNF deverá primeiro ser desativada no caso de HA se o Edge for mudado para uma versão anterior que não a suporta.

  • Problema 69562: ocorrer uma falha no tráfego num VMware SD-WAN Gateway quando tanto o Gateway-parceiro BGP como o Destino Não-SD-WAN-BGP têm o mesmo Número de Sistema Autónomo (ASN) local.

    Quando o PG-BGP e o NSD-BGP têm o mesmo ASN local e um caminho aprendido NSD-BGP é redistribuído num PG-BGP, o ASN será precedido duas vezes no caminho antes do anúncio. Isto pode fazer com que um outro caminho BGP seja preferido face a este por ter um caminho AS mais curto, levando potencialmente o tráfego a corresponder ao caminho errado.

    Solução alternativa: Sem esta correção, a solução alternativa para estes problemas é ter um ASN diferente para o PG-BGP e para o NSD-BGP.

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

    Durante o reinício do serviço Edge, o tráfego do cliente seria interrompido durante ~15-30 segundos. Este problema ocorre de forma inconsistente, mas quando ocorre o Edge separa uma associação de segurança IKE (SA). Normalmente, isto ocorre apenas quando: o temporizador SA (conforme configurado no VMware SD-WAN Orchestrator) expira; ou o utilizador altera a configuração IPSec no Orchestrator.

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

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

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

    Solução alternativa: não há solução alternativa para este problema, nem mesmo um reinício ou reinicialização do Edge.

  • Problema 72358: se o endereço IP de um nome DNS do VMware SD-WAN Orchestrator for alterado, o processo do plano de gestão do VMware SD-WAN Gateway não o resolverá corretamente e o Gateway não poderá ligar ao Orchestrator.

    O processo de gestão do Gateway verifica periodicamente a resolução DNS do nome DNS do Orchestrator, para ver se este foi alterado recentemente para que o Gateway possa ligar-se ao anfitrião certo. O código de resolução do DNS tem um problema, pelo que todas as verificações de resolução falham e o Gateway continua a utilizar um endereço antigo e, como tal, deixa de conseguir ligar-se ao Orchestrator.

    Solução alternativa: até que este problema seja resolvido, um utilizador operador não deve alterar o endereço IP do Orchestrator. Se o endereço IP do Orchestrator tiver de ser alterado, todos os Gateways ligados a esse Orchestrator terão de ser reativados.

  • Problema 81859: 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.

    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: 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 acionar um erro nesta configuração e impedir um utilizador de ativar a HA para os Edges, o Orchestrator permite-o e esta configuração ativa uma falha do plano de gestão nos Edges de HA que já não enviam um heartbeat ao Orchestrator e o Orchestrator marca o site como inativo.

    Solução alternativa: evite utilizar a configuração descrita acima.

  • Problema 82415: Um VMware SD-WAN Gateway implementou uma imagem KVM com o adaptador de servidor intel® Ethernet X710; SR-IOV; e Bond0 não responde se ativado para a Versão 4.5.1 ou 5.0.0.0

    Para um Gateway, os caminhos implementados desta forma não surgem e os comandos debug.py não funcionam.

    Solução alternativa: sem esta correção, os operadores devem evitar utilizar estas compilações para esta implementação específica do Gateway até que sejam lançadas novas compilações com este problema corrigido.

  • Problema 83083: um VMware SD-WAN Gateway atualizado para a versão 4.3.1 ou posterior pode registar uma fuga de memória lenta, que pode levar ao reinício do serviço do Gateway para limpar a memória.

    Os reinícios dos Gateways podem ser disruptivos para o tráfego do cliente durante os 30 a 45 segundos que o reinício do serviço do Gateway demora. Cada vez que um utilizador operador executa o comando debug.py --flow_dump all all all no Gateway, este esvazia parte da memória.  Executar este comando de depuração vezes suficientes fará com que a utilização da memória do Gateway atinja um nível crítico e desencadeie um reinício do serviço do Gateway para limpar a memória.

    Solução alternativa: evite executar o comando debug.py --flow_dump all all all no Gateway. Se a utilização deste comando de depuração for inevitável, monitorize a utilização da memória e agende as janelas de manutenção para reiniciar preventivamente o serviço para limpar a memória antes de um reinício não programado.

  • Problema 83212: ao consultar o VMware SASE Orchestrator em Monitorizar > Edge > Transporte (Monitor > Edge > Transport), existe uma discrepância entre a tabela de estatísticas da ligação e da aplicação.

    As estatísticas da ligação e da aplicação devem corresponder. No entanto, as estatísticas da aplicação mostram um valor superior em relação às estatísticas da ligação. Este problema ocorre mais frequentemente onde existe uma topologia de cluster de VMware SD-WAN Edge Hub em que o Spoke Edge utiliza uma única ligação WAN. Se esta ligação WAN única sofrer alguma perda, os pacotes são transmitidos novamente e são contabilizados duas vezes nas estatísticas da aplicação, o que resulta na discrepância observada.

    Solução alternativa: não há solução para este problema, mas, quando o mesmo for encontrado, as estatísticas da aplicação serão corretas comparativamente às estatísticas da ligação.

  • Problema 85154: 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 a versão 4.5.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.

    Solução alternativa: não existe uma solução alternativa para este problema para além de NÃO mudar para uma versão anterior à versão 4.5.1, uma vez que o AWS Edge está nesta versão.

  • Problema 85459: uma tentativa de acesso através de SSH a partir de um cliente do lado da LAN do Edge para um Edge ou de um cliente Edge numa sucursal remota para um Edge, poderá não funcionar após as regras NAT do lado da LAN serem configuradas.

    Os pacotes de resposta SSH provenientes do processo SSH do Edge passam pelo serviço dataplane do Edge e, uma vez que as regras NAT do lado da LAN estão configuradas, será possível que os pacotes de resposta SSH utilizem essas regras para acederem a destinos diferentes do cliente original que gerou o tráfego SSH, o que faz com que as tentativas de SSH a um Edge não funcionem.

    Solução alternativa: a única solução é remover a regra NAT.

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

    Quando um túnel Edge para NSD estiver inativo, é executada a libertaçã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.

    Solução alternativa: limitar um NSD via Edge a uma ligação WAN diminuirá a probabilidade de este problema ocorrer.

  • Problema 87982: 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.

    Solução alternativa: as soluções alternativas são não identificar o tráfego da VLAN para a ligação PPPoE ou tornar a ligação pública.

  • Problema 88604: 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.

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

  • Problema 88796: ao implementar um VMware SASE Orchestrator ou um VMware SD-WAN Gateway e utilizar um OVA no vSphere, as propriedades do OVF definidas como parte da implementação (palavra-passe, informações de rede, etc.) não serão aplicadas à imagem e não será possível aceder ao sistema após a implementação.

    Isto só afeta o novo sistema implementado a partir do OVA que utilize propriedades OVF/vApp (por oposição à utilização de ficheiros ISO). Este problema é causado por alterações a montante ao cloud-init em atualizações recentes.

    Solução alternativa: sem a correção, a solução é o operador implementar o sistema com um ficheiro ISO de dados de utilizador cloud-init.

  • 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, tanto o LED de estado frontal como 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.

    Nota: é 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 só pode ser resolvido através da atualização do Edge 6x0 para o firmware da plataforma 1.3.0 (R130-20220328-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 o Edge 6x0 também tem de utilizar uma compilação de versão 5.x. O utilizador atualizaria então o firmware da plataforma Edge 6x0 para a versão 1.3.0 (R130-20220328-GA) da mesma forma que uma versão de software do Edge é modificada.

    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: 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 pode atualizar temporariamente o Edge para uma compilação 5.x, atualizar o firmware da plataforma para a versão 1.3.0 (R130-20220328-GA), para que a versão de 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 continuaria a utilizar a versão de firmware da plataforma 1.3.0 (R130-20220328-GA). 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 91365: 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.

    Solução alternativa: para um cliente que utilize o Edge Network Intelligence, a ação recomendada é atualizar os respetivos Edges para a compilação de correção R451-20220720-GA-91365, que se baseia na primeira compilação rollup R451-20220701-GA do Edge e adiciona a correção de 91365. Qualquer cliente que precise de acesso a esta compilação de correção pode contactar o Suporte da VMware SD-WAN.

    Sem a correção, 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 91875: 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 é provocado por uma condição race num processo Edge que leva o Edge a considerar, erradamente, que a ligação WAN de backup é necessária e avança com a criação de um túnel para essa ligação, para a qual o Edge não tem uma contramedida para detetar e desmantelar este túnel errado.

    Solução alternativa: se estiver a utilizar ligações WAN como ligações de backup, recomenda-se que atualize os Edges onde seja o caso para a compilação de correção R451-20220714-GA-91875 que inclui uma correção específica para este problema.

  • Problema 92481: se uma interface WAN num VMware SD-WAN Edge estiver configurada como não ativada no VMware SASE Orchestrator, continuará a ser comunicada como “UP” (Ativa) 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 WAN do Edge (por exemplo, GE3 ou GE4 num modelo Edge 6x0 ou 3x00). Como resultado, quando o SNMP sonda essas interfaces, devolve sempre um resultado de UP, independentemente da configuração das interfaces.

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

  • 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 98136: 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 Edge Spoke que regista 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 Edge Spoke 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.

    Solução alternativa: aguarde que o túnel da VPN Ramo a Ramo Dinâmica fique inativo, após isso, o caminho de transmissão não será instalado no Edge Spoke quando um novo túnel da VPN Ramo a Ramo Dinâmica é formado em direção ao Edge Hub.

  • Problema 97321: 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.

    Solução alternativa: a única solução para este problema é desativar a Análise.

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 > A perda não representada em gráficos (Monitor > Transport > Loss not graphing) observou 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 33026:

    A página “Acordo de Serviços do Utilizador Final” (End User Service Agreement [EUSA]) não é atualizada corretamente após eliminar o acordo.

  • Problema 34828:

    O tráfego não consegue passar entre um Spoke Edge do VMware SD-WAN que utiliza a versão 2.x e um Edge Hub que utiliza a versão 3.3.1.

  • 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 de 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 40341:

    Embora a aplicação Skype esteja devidamente categorizada no back-end como tráfego em tempo real, ao editar a política empresarial do Skype no VMware SD-WAN Orchestrator, a Classe de Serviço pode exibir incorretamente “Transacional” (Transactional).

  • 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 47269:

    A interface VMware SD-WAN 510-LTE pode surgir em modelos Edge que não suportam uma interface LTE.

  • Problema 47713:

    Se uma Regra de política empresarial estiver configurada enquanto a VPN de cloud estiver desativada, a configuração NAT deverá ser reconfigurada ao ativar a VPN de cloud.

  • Problema 47820:

    Se uma VLAN estiver configurada com o DHCP não ativado ao nível do perfil, enquanto também tem uma Anulação de Edge para esta VLAN nesse Edge com o DHCP ativado e existir 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 48737:

    Num VMware SD-WAN Orchestrator que está a utilizar a nova interface de utilizador da versão 4.0.0, se um utilizador estiver ativo numa página de monitorização e alterar o intervalo de tempo de Início e Fim e posteriormente navegar entre separadores, o Orchestrator não atualizará o tempo de intervalo de Início e Fim para os novos valores.

  • Problema 49225:

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

  • Problema 49790:

    Quando um VMware SD-WAN Edge é ativado na versão 4.0.0, a ativação é publicada duas vezes em Eventos.

    Solução alternativa: ignore o evento duplicado.

  • Problema 50531:

    Quando dois operadores com privilégios diferentes utilizam a mesma janela do browser para aceder à nova IU na versão 4.0.0 do VMware SD-WAN Orchestrator e o Operador com menos privilégios tenta iniciar sessão depois do Operador com mais privilégios, esse Operador com menos privilégios observará vários erros a indicar, o “utilizador não tem privilégios” (user does not have privilege).

    Nota: não existe escalamento de privilégios para o Operador com privilégios mais reduzidos, apenas a apresentação de mensagens de erro.

    Solução alternativa: o próximo operador poderá atualizar essa página antes de iniciar sessão para evitar ver os erros ou cada Operador pode utilizar janelas diferentes do browser para evitar este problema de apresentação.

  • 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.

  • Problema 60039: a Reativação de RMA não funciona quando o modelo VMware SD-WAN Edge é alterado.

    Ao realizar uma Reativação de RMA para um local em que o modelo Edge também está a ser alterado, o VMware SD-WAN Orchestrator não guarda a alteração do modelo, o que torna a ligação de reativação ineficaz. Isto apenas afeta as Reativações de RMA em que o modelo Edge é alterado, uma Reativação de RMA em que o modelo Edge permanece o mesmo funcionará conforme esperado.

    Solução alternativa: se utilizar um modelo Edge diferente para um local, o utilizador terá de criar um novo Edge e aplicar manualmente todas as definições específicas ao Edge.

  • Problema 60522: na IU do VMware SASE Orchestrator, o utilizador observa um grande número de mensagens de erro quando tenta remover um segmento.

    O problema pode ser observado ao adicionar um segmento a um perfil e associar o segmento a vários VMware SD-WAN Edges. Quando o utilizador tenta remover o segmento adicionado a partir do perfil, vê um grande número de mensagens de erro.

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

  • Problema 88910: num VMware SASE Orchestrator com a versão 4.5.1, um utilizador não consegue executar um teste de velocidade de Ligação WAN para um VMware SD-WAN Edge através da utilização de Diagnóstico remoto > Teste de velocidade de ligação WAN (Remote Diagnostics > WAN Link Speed Test).

    Ao tentar utilizar o diagnóstico de Teste de velocidade de ligação WAN, o utilizador não poderá escolher uma interface para o teste de velocidade, uma vez que não existe um menu pendente para as interfaces presentes.

    Solução alternativa: se um utilizador quiser forçar um teste de largura de banda para uma ligação WAN, como solução alternativa, o utilizador poderá alterar o método de medição da largura de banda para essa ligação WAN, que aciona um novo teste automaticamente.  Isto pode ser feito da seguinte forma:

    1. Na IU do Orchestrator de um determinado Edge, aceda a Configurar > Dispositivo (Configure > Device) e desloque-se a página até Definições WAN (WAN Settings).
    2. Para que a ligação WAN seja testada de novo, selecione Editar (Edit) para a ligação a ser novamente medida e, em seguida, selecione Avançadas (Advanced) para serem apresentadas definições adicionais.
    3. No menu Medição da largura de banda (Bandwidth Measurement), altere o método de medição da largura de banda da corrente para um método diferente (por exemplo, se a ligação utilizar o Modo burst, altere para Início lento, ou vice-versa) e clique em Atualizar ligação (Update Link) e, em seguida, Guardar alterações (Save Changes) na parte superior da página do dispositivo.  
    4. Assim que tiver sido realizada uma medição na ligação WAN, altere o método de medição novamente para o método original de forma a garantir a medição mais precisa para a respetiva ligação WAN. Isto aciona um teste adicional da largura de banda.
Problemas conhecidos do Cloud Web Security
  • Problema 62934: para uma empresa que utiliza o VMware Cloud Web Security, se um utilizador cliente abrir um browser Chrome no modo de navegação anónima e tentar transferir um ficheiro, a transferência pode, ocasionalmente, não ser bem-sucedida.

    O modo de navegação anónima requer a ativação de cookies de terceiros. Ative os cookies de terceiros e volte a tentar a operação. Numa transferência sem êxito, o utilizador observaria um ecrã onde se lê “Ocorreu um erro. Contacte o administrador” (Error occurred contact your administrator) ou, para ficheiros de um servidor Web personalizado: “Esta página não está a funcionar” (This page is not working). Ocasionalmente, alguns servidores Web ou ficheiros podem ter uma variação na assinatura de ficheiro, que o Cloud Web Security Service pode não ser capaz de reconhecer, resultando neste problema.

    Solução alternativa: autorize os cookies de terceiros e tente novamente. Não há uma solução conhecida para este problema se utilizar uma janela de navegação anónima.

  • Problema 63149: quando uma implementação do cliente tem sub-redes sobrepostas num perfil e configura uma sub-rede para uma política do VMware Cloud Web Security e associa a política do Cloud Web Security ao perfil e segmento, os clientes Edge nessa sub-rede não serão capazes de se ligar à Internet.

    Se houver sub-redes sobrepostas configuradas para os segmentos LAN por trás dos VMware SD-WAN Edges dentro do mesmo segmento, os recursos por trás dos Edges não podem ter políticas do Cloud Web Security aplicadas para o tráfego ligado à Internet. Isto porque não há forma de identificar exclusivamente o Edge de destino para o tráfego de retorno da Internet para o Cloud Web Security.

    Solução alternativa: ative o NAT do lado LAN no Edge e tenha uma sub-rede única que represente o tráfego originado a partir de recursos por trás do Edge.

  • Problema 65001: para um cliente que utiliza o VMware Cloud Web Security, um utilizador não pode configurar o Motor de inspeção para ativar/desativar as Verificações de hash de ficheiro através do VMware Orchestrator.

    Quando um utilizador está a utilizar o Orchestrator para configurar o parâmetro de Verificação de hash de ficheiro do Motor de inspeção do Cloud Web Security para “Ação para transferência de ficheiro desconhecido” (Action for Unknown File Download) e “Ação para transferência de documento desconhecido” (Action for unknown document Download), estas alterações não são enviadas para o Motor de inspeção e não são aplicadas.

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

Problemas conhecidos do Secure Access
  • Problema 64541: para um cliente que utiliza o VMware Secure Access, ao utilizar a opção na configuração do Workspace ONE UEM para configurar o nome de anfitrião do túnel dentro do Grupo da organização, se um utilizador selecionar “Sim” (Yes), o nome de anfitrião será criado automaticamente na consola UEM em vez de ser configurado manualmente.

    O utilizador deve ter a opção de configurar manualmente o nome de anfitrião e não apenas criá-lo automaticamente. 

    Solução alternativa: a solução é defini-lo manualmente na consola UEM.

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