Atualizado a 18 de agosto de 2022

VMware SASE™ Orchestrator versão R5010-20220817-GA
VMware SD-WAN™ Gateway versão R5010-20220729-GA
VMware SD-WAN™ Edge versão R5010-20220729-GA
VMware Cloud Web Security™ com a versão R5010-20220803-GA do Orchestrator
VMware Secure Access™ com a versão R5010-20220803-GA do Orchestrator
VMware Edge Network Intelligence™ com a versão R5010-20220803-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 5.0.0, bem como para os clientes afetados pelos problemas indicados abaixo que foram resolvidos desde a versão 5.0.0.

Compatibilidade

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

Nota: A versão 5.0.1 é classificada como versão de manutenção, e as versões de manutenção estão sujeitas a um subconjunto de testes de interoperabilidade porque o protocolo é idêntico à versão principal/secundária de que fazem parte. Consulte as Notas de versão do VMware SASE 5.0.0 para obter uma lista das outras versões de software relativamente às quais esta versão do protocolo foi testada.

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

Orchestrator

Gateway

Edge

Hub

Ramo/Spoke

5.0.1

5.0.1

4.3.1

4.3.1

5.0.1

5.0.1

4.5.0

4.5.0

5.0.1

5.0.1

5.0.0

5.0.0

5.0.1

4.3.1

4.3.1

4.3.1

5.0.1

4.5.0

4.5.0

4.5.0

5.0.1

5.0.0

5.0.0

5.0.0

5.0.0

5.0.1

5.0.1

5.0.1

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

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 respeito apenas 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 5.0.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 5.0.1. Os Orchestrators que utilizam a versão 4.0.0 ou posterior podem ser atualizados para a versão 5.0.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 → 5.0.1.

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

Gateway

As atualizações do Gateway da versão 3.x para a versão 5.0.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.

Nota: ao implementar um novo Gateway com a versão 5.0.1, a instância ESXi do VMware tem de ser, pelo menos, da versão 6.7, Atualização 3, até à versão 7.0. A utilização de uma instância ESXi anterior irá resultar na falha do Serviço dataplane do Gateway ao tentar executar a versão 5.0.0 ou posterior.

Nota: antes de atualizar um Gateway para a versão 5.0.1, a instância ESXi tem de ser atualizada para, pelo menos, a versão 6.7, Atualização 3, até à versão 7.0. A utilização de uma instância ESXi anterior irá resultar na falha do Serviço dataplane do Gateway ao tentar executar a versão 5.0.1 ou posterior.

Edge

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

Notas importantes

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

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

A Grafana já não está disponível no Orchestrator

A versão 5.0.0 e as versões posteriores dos Orchestrators não incluem a aplicação Grafana devido a restrições de licença. A Grafana é utilizada principalmente por clientes e parceiros que executam o Orchestrator no local para monitorizar o desempenho do Orchestrator. A partir de agora, para estas necessidades, um cliente ou parceiro teria de alojar a sua própria aplicação Grafana fora do Orchestrator e configurar o Telegraf no Orchestrator para apontar para ela.

As compilações do VMware SASE incluem um quarto dígito

Começando com a versão 5.0.0 e a partir de agora, a compilação da versão passará a incluir um quarto dígito.

Para versões de software, o VMware SASE segue um esquema de numeração a.b.c, em que:  

  • a = Principal (por exemplo, 5.0.0) → Uma versão com várias grandes funcionalidades e alterações arquitetónicas potencialmente significativas.
  • b = Menor (por exemplo, 5.2.0) → Uma versão com várias pequenas funcionalidades ou algumas grandes funcionalidades e sem alterações arquitetónicas significativas
  • c = Manutenção (por exemplo, 5.2.1) → Uma versão com um número potencialmente grande de correções para problemas encontrados em campo e correções de problemas encontrados internamente sem funcionalidades, exceto o potencialmente novo suporte da plataforma de hardware.

Com a versão 5.0.0, é adicionado um quarto dígito às compilações do Edge, Gateway e Orchestrator, pelo que a numeração passa a ser a.b.c.d, em que

  • d = Compilação rollup (por exemplo, 5.2.1.1) → Uma versão com um pequeno número de correções para problemas encontrados em campo, sem correções de problemas encontrados internamente e sem funcionalidades.

As compilações Rollup para 4.x e anteriores distinguem-se pela data de GA do nome de imagem, o que não é uma forma ideal de comunicar a versão da compilação a um cliente. Adicionar um quarto dígito às compilações 5.0.0 e posteriores permite que os clientes vejam mais claramente que versão de software está a ser utilizada num determinado componente.

Esta convenção de numeração da compilação aplica-se apenas à versão 5.0.0 e às versões posteriores. As versões 4.x e anteriores continuarão a utilizar três dígitos, sendo que as compilações rollup serão identificadas da forma existente por data.

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 ou 5.x devem editar as configurações de AS-PATH precedentes 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, 4.3.0, 4.5.0 ou 5.0.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).

Histórico de revisões do documento

5 de agosto de 2022. Primeira edição.

11 de agosto de 2022. Segunda edição.

  • Foram adicionados os problemas corrigidos 89346, 90067, 90128, 90540, 91054, 91720 e 92082 à secção Problemas resolvidos do Orchestrator. Estes pedidos foram omitidos por engano da Primeira edição das Notas de lançamento da versão 5.0.1.

15 de agosto de 2022. Terceira edição.

  • Foi adicionado o Problema resolvido 89217 à secção Problemas resolvidos do Edge/Gateway. Este pedido foi omitido por engano da Primeira edição das Notas de lançamento da versão 5.0.1.

18 de agosto de 2022. Quarta edição.

  • Foi adicionada uma compilação R5010-20220817-GA atualizada do Orchestrator à secção Problemas resolvidos do Orchestrator. A compilação R5010-20220817-GA substitui a compilação original R5010-20220803-GA do Orchestrator e é a nova compilação GA do Orchestrator para a versão 5.0.1.
  • Esta compilação atualizada do Orchestrator inclui a correção para o problema 95613, que é adicionada à secção Problemas resolvidos do Orchestrator.

Problemas resolvidos

Os problemas resolvidos são agrupados da seguinte forma.

Problemas resolvidos do Edge/Gateway

Resolvido na compilação R5010-20220729-GA do Edge/Gateway

Os problemas abaixo foram resolvidos a partir da compilação R5002-20220506-GA do Edge/Gateway.

  • Problema 58791 resolvido: um local implementado com uma topologia de Alta Disponibilidade onde o BGP é utilizado pode encontrar um problema em que o VMware SD-WAN Edge falha repetidamente.

    Este problema afeta os sites HA configurados com uma topologia hub/spoke onde o site HA tem mais de 512 prefixos de filtro BGPv4 configurados.

    Quando o BGP é utilizado com vários comandos de rede configurados e enquanto o Edge em standby é ativado, analisa todas as configurações simetricamente e para cada comando de rede é gerado um vtysh. Consequentemente, o thread verp não é executado. O atraso no thread verp resulta num atraso no processamento do heartbeat, o que faz com que o Edge em standby acredite que o Edge ativo está inativo e se torne ativo, causando um estado ativo-ativo. Para recuperar do estado split-brain, o Edge em standby reinicia, o que apenas vai repetir o ciclo.

    Sem a correção, a solução alternativa é reduzir o número de configurações de prefixo de filtro BGP agregando-as e mantendo o número total abaixo de 512 (256 filtros de entrada e 256 filtros de saída).

    Nota: existe um problema semelhante em que um site de HA sofre perturbações ao utilizar as operações de “corresponder e definir” (match and set) do BGP e este é acompanhado em separado em Problema 84825 resolvido, que também é resolvido nesta compilação do Edge.

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

    Ao encontrar este problema sem a correção, o reinício do Serviço Edge restabelecerá a conectividade total do túnel.

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

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

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

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

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

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

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

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

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

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

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

  • 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 que estão corrigidas no mapa de aplicação predefinido da versão 4.5.1 e 5.0.1.  É possível corrigir este problema para um cliente que não utilize a versão 4.5.1/5.0.1 com 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 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, o que tem um impacto de cerca de 15 a 30 segundos no tráfego do Gateway.

    Este problema poderá ocorrer se um VMware SD-WAN Edge estiver ligado ao Gateway com Edge-a-Edge (E2E) configurado 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 utilizador ativar novamente o Edge-a-Edge, o que, mais uma vez, apenas atualizará a flag, 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 80721 resolvido: os parceiros e operadores que monitorizam um VMware SD-WAN Gateway com o Telegraf podem observar que as métricas não são retomadas caso o Telegraf sofra um tempo limite de rede excedido. 

    Os Gateways que registam este problema estão a utilizar a versão 1.17.3 do Telegraf, o que é diferente da versão do Telegraf que o VMware SASE Orchestrator está a utilizar: 1.21.1. Esta incompatibilidade de versões causa o problema em que o Telegraf fica bloqueado caso ocorra um tempo limite excedido da rede. Os Gateways com uma correção deste problema incluem a versão 1.21.1 do Telegraf, assim como qualquer compilação futura do Gateway nessa série de versões (por outras palavras: 4.5.1 ou 5.0.1).

    Num Gateway que registe este problema, a única remediação consiste em reiniciar o Telegraf para retomar o envio de métricas.

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

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

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

  • Problema 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 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 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 81859 resolvido: quando um VMware SD-WAN Edge 610-LTE é ativado para a versão 5.0.0 do Edge, a interface CELL pode não aparecer depois de o Edge ser atualizado para essa versã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 este Edge terá de ser local.

    Se encontrar este problema num Edge sem a correção, o utilizador terá de reiniciar o serviço Edge (ou desligar e ligar/reiniciar, se o Edge estiver inacessível através do Orchestrator) ou reiniciar o modem do Edge para restaurar a interface CELL.

  • Problema 82182 resolvido: para um modelo VMware SD-WAN Edge 510 ou 510-LTE que esteja a executar a versão 5.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 82264 resolvido: um VMware SD-WAN Virtual Edge que utiliza uma instância AWS C4 não pode ser atualizado para a versão 5.0.0.

    Um AWS C4 Virtual Edge atualizado para a versão 5.0.0 não recupera e a única correção é o utilizador reativar o Edge para uma versão que não seja a 5.0.0.  Nenhuma outra instância AWS (por exemplo, C5) é afetada por este problema, mas, devido à natureza crítica deste defeito, não está disponível um pacote de Atualização de software AWS Edge para a versão 5.0.0.

    A versão 5.0.1 e as versões posteriores do Edge corrigem este problema e a instância AWS C4 pode ser atualizada com sucesso para a versão 5.0.1 e versões posteriores.

  • Problema 82463 resolvido: num site configurado com um Serviço de Segurança na Cloud (CSS), o VMware SD-WAN Edge pode perder tráfego destinado ao CSS. 

    Se o site estiver a encaminhar todo o tráfego de Internet através de um CSS, o impacto deste problema pode ser significativo. Quando o problema ocorre, os pacotes CSS são enviados na interface incorreta, com o endereço IP da interface real como a fonte que origina uma falha no acesso à aplicação. O problema é causado por uma potencial corrida entre o thread de pesquisa de contexto do CSS e o thread de seleção de interface de saída, que provoca a associação incorreta da interface de saída ao fluxo e a falha de alguns fluxos nos caminhos do CSS.

    Sem a correção, quando ocorre o problema, o utilizador pode solucioná-lo ao iniciar um novo fluxo ou esvaziar todos os fluxos no Edge através de Diagnóstico remoto > Esvaziar fluxos (Remote Diagnostics > Flush Flows).

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

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

  • Problema 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 82652 resolvido: para um cliente que utilize um Serviço de Segurança na Cloud (CSS) em que está configurada a Verificação de estado de funcionamento de L7, o VMware SD-WAN Edge não tenta recuperar um túnel CSS IPsec que foi marcado como inativo há mais de cinco minutos.

    Na implementação atual da Verificação de estado de funcionamento de L7, o Edge envia sondas L7 em todos os túneis CSS e, se essas sondas falharem um número definido de vezes, o Edge marca o túnel como inativo, continua a enviar sondas L7 e aguarda que o túnel fique ativo por si mesmo. O problema prende-se com o facto de não existir qualquer tentativa de recuperar um túnel após este se encontrar num estado inativo por mais de cinco minutos, sendo que o IKE permanece ativo (se o IKE também estiver inativo, o túnel IPsec é automaticamente reposto após 20 segundos).

    A correção neste caso melhora a Verificação de estado de funcionamento de L7, incluindo um passo adicional para os túneis CSS baseados em IPsec: se um túnel CSS baseado em IPsec permanecer inativo por mais de cinco minutos (sem sondas L7 bem-sucedidas), enquanto o IKE do túnel permanece ativo durante o mesmo período, o Edge derruba o túnel IPsec e repõe o IKE numa tentativa de recuperar o túnel CSS. As sondas L7 continuariam a ser enviadas enquanto isto ocorre e marcariam o túnel como ativo se fossem bem-sucedidas. Se o túnel permanecesse inativo, seria aplicado o mesmo passo após cinco minutos adicionais.

    Este comportamento adicionado aplica-se apenas a um CSS com túneis IPsec, e não aos que utilizam túneis GRE.

  • 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 não está configurado para utilização 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 não é utilizado.

  • 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 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 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 83209 resolvido: Para os clientes que utilizam o OSPF na respetiva empresa, o routing OSPF pode não funcionar conforme esperado.

    O problema ocorre quando há uma alteração no router-id do OSPF e o serviço Edge é reiniciado. Apenas as interfaces de retorno e as interfaces com a flag “Anunciar” (Advertise) definida são consideradas para a seleção de router-id. Quando existe uma nova interface de retorno configurada com um endereço IP superior, após o reinício do serviço Edge, o novo endereço IP de retorno é selecionado como o router-id e, se o Edge for escolhido como o RD (Router designado), o problema ocorrerá.

    Sem a correção, a única solução é forçar a utilização do ID de router antigo. Para voltar a utilizar o ID de router antigo, defina a flag Anunciar (Advertise) na respetiva interface (será necessário reiniciar o serviço Edge).

  • 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 83411 resolvido: quando a alta disponibilidade é ativada com um VMware SD-WAN Edge recentemente ativado, o par Edge HA pode ficar offline.

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

  • Problema 83424 resolvido: um percurso SNMP pode não funcionar corretamente para OIDs relacionados com caminhos e interfaces.

    Quando é executado um comando snmpbulkwalk para algumas implementações do Edge, o percurso SNMP pode demorar demasiado tempo e exceder o tempo limite. A correção deste problema otimiza o SNMP e garante respostas mais rápidas aos pedidos de percurso SNMP. No entanto, é de notar que existem situações raras em que o problema continua a ocorrer, uma vez que o processo SNMP continua a ser um processo de menor prioridade no Edge.

  • Problema 83428 resolvido: numa empresa de cliente que utiliza uma topologia Hub/Spoke, os túneis estáticos entre um VMware Hub Edge e um Spoke Edge podem deixar de passar tráfego ao tentarem medir a largura de banda no túnel.

    No Hub Edge, não existe nenhum mecanismo para lidar com um cenário em que a preferência de túnel é atualizada a meio do processo de estabelecimento do túnel. O processo de medição da largura de banda coloca o túnel num estado parado e o tráfego não consegue passar no mesmo. O tráfego do cliente pode ser redirecionado através do Gateway, mas isso pode introduzir latência no tráfego Hub/Spoke.

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

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

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

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

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

  • 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 84106 resolvido: um VMware SD-WAN Edge pode exportar estatísticas do NetFlow no intervalo de tempo incorreto, o que faz com que os sistemas recetores fiquem dessincronizados.

    Os pacotes do NetFlow podem ter um atraso adicional de 5 segundos em relação ao intervalo configurado. Isto acontece porque o exportador do NetFlow verifica o tempo de exportação apenas uma vez a cada 5 segundos e, como resultado, os pacotes do NetFlow podem ter um atraso de 5 segundos entre o intervalo configurado e o intervalo de exportação real.

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

    O endereço IP do NAS é definido, por predefinição, como um endereço IP de retorno nos pacotes RADIUS ou ISE enviados do Edge (autenticador) para o servidor ISE ou RADIUS e isto pode fazer com que os pacotes de autenticação não cheguem ao NAS, causando a falha de autenticação. Para remediar o problema, as compilações com esta correção definem o endereço IP do NAS como o endereço IP da interface de origem selecionado e configurado com as definições de autenticação 802.1x. Se “Automático” (Auto) for selecionado como a interface de origem, o IP de retorno será definido como o endereço IP do NAS por predefinição.

  • Problema 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 implementam um modem LTE baseado em USB num VMware SD-WAN Edge ou implementam um modelo LTE VMware SD-WAN Edge (510-LTE ou 610-LTE) podem ter problemas intermitentes com a criação de túneis na interface CELL após a reposição 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 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.

    Vários threads nos Edges HA estão a ficar suspensos, o que leva a vários problemas na HA, incluindo, entre outros, um estado Ativo-Ativo de HA. 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. A outra forma através da qual a suspensão de múltiplos threads pode ter impacto num cliente é através da disrupção do caminho, que também pode ser observada como uma disrupção do tráfego do cliente. Desta forma, um site HA de cliente pode encontrar este problema sem, necessariamente, ver os sinais de um cenário Ativo-Ativo onde o Edge em standby reinicia.

    A causa para vários threads do Edge HA serem suspensos permanece em investigação.

  • Problema 85375 resolvido: os clientes que utilizem modems LTE baseados em USB num VMware SD-WAN Edge ou modelos LTE do VMware SD-WAN Edge (510-LTE ou 610-LTE) podem sofrer perturbações no tráfego LTE.

    O utilizador observaria nos registos do Edge erros RX que são incrementados sem que o tráfego passe pela interface LTE. Um aspeto do problema é que só ocorre se o MTU da ligação LTE for inferior a 1500.

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

    Num Edge sem a correção, a única solução alternativa é remover a regra NAT.

  • Problema 86032 resolvido: ao atualizar um VMware SD-WAN Gateway da versão 4.3.x para a 4.5.1 ou 5.0.0, o Gateway ignora a comunicação com o VMware SASE Orchestrator e as interfaces eth0 e eth1 são removidas.

    O problema principal é o processo de dataplane do Gateway parar após a atualização. Isto é provocado pela falha ao iniciar do serviço Telegraf. Uma vez que o serviço Telegraf é ativado como parte do script de arranque do Gateway, se o início do Telegraf falhar, o serviço do Gateway também não inicia.

    Se um Gateway for atualizado para uma compilação sem esta correção, a única forma de remediar o problema é executar “vc_procmon restart” para o Gateway juntamente com um reinício do serviço Telegraf.

  • 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 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 86617 resolvido: uma empresa de cliente que utiliza um endereço IP de retorno com Gateways de parceiro em que o BGP está configurado pode observar que o tráfego que deveria utilizar os caminhos de IP de retorno está a ser ignorado, o que resulta numa interrupção do tráfego de cliente.

    Os caminhos do endereço IP de retorno estão em falta no VMware SD-WAN Edge, o que se deve a um cenário em que o BGP está configurado para o Edge e o Gateway de parceiro e um endereço IP de retorno é enviado para o Edge através do BGP, mas o Edge não aprende o caminho do IP de retorno.

  • Problema 86740 resolvido: ao executar o diagnóstico remoto “Estado da interface” (Interface Status), um módulo SFP do tipo GPON não aparece quando é implementado na interface SFP2 de um VMware SD-WAN Edge.

    O problema é provocado por uma falha no script de back-end de diagnóstico remoto que é executado no Edge e não tem corretamente em consideração a interface SFP2 do Edge.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Nota: este pedido aberto aplica-se apenas às compilações do Gateway.  O problema do Orchestrator é corrigido com a compilação da versão R5002-20220517-GA e posterior.

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

    O problema resolve-se através da atualização do Edge 6x0 para o firmware de 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.

    Nota: se o utilizador preferir manter o Edge numa versão de software mais baixa (por exemplo, versão 4.3.1 ou 4.5.1), o cliente poderá atualizar temporariamente o Edge para 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.

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

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

Problemas resolvidos do Orchestrator

Resolvido na versão R5010-20220817-GA do Orchestrator

A versão R5010-20220817-GA do Orchestrator foi lançada a 17-08-2022 e é a compilação GA do Orchestrator atualizada para a versão 5.0.1.

Esta compilação substitui a compilação GA original R5010-20220803-GA, que incluiu o problema 95613. Este problema foi detetado durante uma atualização do Orchestrator depois de esta compilação ter sido lançada em 05-08-2022.  Os clientes só devem utilizar a compilação R5010-20220817-GA e não utilizar a R5010-20220803-GA.

Além do problema 95613, a compilação R5010-20220817-GA do Orchestrator aborda os problemas críticos abaixo (que foram incluídos no R5010-20220803-GA) desde a compilação GA original 5.0.1 Orchestrator, versão 5002-20220517-GA.

  • Problema 49535 resolvido: na página Monitorizar > Serviços de rede (Monitor > Network Services), o VMware SASE Orchestrator não atualiza imediatamente o estado do vizinho BGP de um VMware SD-WAN Edge que ficou offline.

    A tabela Estado de vizinho Edge BGP (BGP Edge Neighbor State) continua a apresentar o Edge offline como “Estabelecido” (Established) e permanece assim durante horas após o Edge ficar offline. Isto tem impacto em qualquer utilizador que dependa da IU do Orchestrator para verificar estes detalhes.

  • Problema 68463 resolvido: ao observar o gráfico Monitorizar > QoE (Monitor > QoE) no VMware SASE Orchestrator em que a secção do gráfico é apresentada como amarelo/aceitável quanto a qualidade, pode existir uma discrepância entre o motivo pelo qual a secção do gráfico é apresentada como amarelo/aceitável ao verificar a IU clássica em comparação com a nova IU.  

    Perante este problema, na IU clássica, se a caixa de pop-up indicar a latência como o motivo da classificação aceitável, a nova IU terá uma caixa de pop-up a indicar a distorção como o motivo da classificação aceitável. O problema é provocado por um mapeamento incorreto dos valores de latência e distorção na nova IU.

  • 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á-la na VMware SASE Orchestrator.

    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 76036 resolvido: Tentar aceder à página “Visão geral do Parceiro” (Partner Overview) e/ou a uma página “Configurar > Cliente” (Configure > Customer) para esse Parceiro num VMware SASE Orchestrator não consegue carregar e apresenta a mensagem “Ocorreu um erro inesperado” (An unexpected error has occurred).

    O carregamento da página Visão geral do Parceiro (Partner Overview) e/ou de uma página Configurar > Cliente (Configure > Customer) para um cliente suportado por esse parceiro pode falhar porque a API “enterpriseProxy/getEnterpriseProxyGatewayPools” excede o limite de tempo.  O que origina o não carregamento destas páginas é a inclusão de um elevado número de Gateways e conjuntos de Gateways, o que pode levar ao excedimento do limite de tempo da API enterpriseProxy /getEnterpriseProxyGatewayPools utilizada na página, causando o problema de carregamento de página para cada página da IU.

  • 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 hiperligação de redefinição da palavra-passe não funciona e direciona-o de volta para a página de início de sessão.

    Ao encontrar este problema num Orchestrator 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 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 83538 resolvido: para clientes que utilizam o serviço Secure Access, quando criam um serviço de Acesso remoto, o ecrã Definições da rede e da empresa (Enterprise & Network Settings) mostra chaves de mensagem de erro interno no VMware SASE Orchestrator.

    Ao criar um serviço de acesso remoto, se o utilizador introduzir dados inválidos nos campos Sub-rede de cliente (Customer Subnet) ou Bits de sub-rede (Subnet bits) será apresentada uma mensagem de erro não traduzida abaixo destes campos. Esta mensagem de erro não é útil para o utilizador e não encaminha para a solução do problema real relativamente a dados inválidos em qualquer um dos campos.

  • Problema 83539 resolvido: num VMware SASE Orchestrator implementado com uma configuração de Recuperação após desastre (DR), quando o Orchestrator é atualizado para a nova versão de software, a sincronização da DR falha.

    A DR funciona corretamente antes da atualização, mas quando um utilizador operador atualiza os Orchestrators ativos e em standby, o estado da DR é apresentado como falhado.

  • Problema 83582 resolvido: ao atualizar um VMware SASE Orchestrator da versão 4.5.0 para a versão 5.0.0, o processo demora muito mais do que o esperado e todos os serviços do Orchestrator estão indisponíveis até o processo ser concluído.

    A atualização do esquema pode demorar mais de 15 minutos para que a tabela de estatísticas do Edge seja atualizada durante a atualização, quando deveria ser atualizado o esquema LRQ. Esta situação causa um grande atraso na conclusão da atualização do Orchestrator.

  • Problema 83822 resolvido: para os clientes que utilizam o VMware Cloud Web Security, ao consultar Monitorizar > Registos > Registos Web (Monitor > Logs > Web Logs) no VMware SASE Orchestrator, o utilizador só conseguirá ver um máximo de 100 registos e não conseguirá carregar mais páginas para ver registos adicionais.

    Com este problema, o utilizador fica limitado a utilizar um máximo de 100 registos numa única página sem conseguir visualizar registos adicionais, dado que a paginação é interrompida nos Registos Web na IU do Orchestrator. Este é um grande obstáculo para os utilizadores, dado que ignifica que se quiserem carregar um grande período de tempo (por exemplo, 30 dias), não conseguirão ver todos os registos para esse período.  A única solução alternativa é carregar curtos períodos de tempo que devolvam 100 ou menos registos. 

  • Problema 84152 resolvido: Quando um cliente gera um relatório Talkers principais para a respetiva empresa, os nomes dos Talkers principais podem ser listados como “Desconhecidos”.

    Os “Talkers principais” são as principais origens de todos os fluxos num determinado intervalo de tempo. O nome do Talker principal poderá não aparecer se o dispositivo cliente não estiver presente para o par exclusivo (IP de origem + Endereço MAC).  Isto acontece porque os dispositivos clientes são guardados com base no Modo de visibilidade (Endereço IP ou Endereço MAC) configurado para o VMware SD-WAN Edge.  Por exemplo, um Orchestrator pode guardar um dispositivo para (Endereço IP 1, Endereço MAC 1). Assim, o registo (Endereço IP 2, Endereço MAC 2) não será guardado se o Modo de visibilidade (Visibility Mode) estiver definido como Endereço IP (IP Address). Isto faria com que o Talker principal correspondente ao Endereço IP 2/Endereço MAC 2 fosse marcado como “Desconhecido”.

  • Problema 84214 resolvido: 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 84969 resolvido: quando um VMware SD-WAN Edge que execute a versão 4.2.x e que também esteja configurado com um IP de gestão não predefinido substituído é atualizado para a versão 4.3.x ou superior num VMware SD-WAN Orchestrator com a versão 4.3.x ou superior, o Edge pode perder o IP de gestão substituído configurado.

    Um Orchestrator com a versão 4.3.x ou superior não está automaticamente a criar a interface de retorno, enquanto mantém também o IP de gestão não predefinido substituído para um Edge quando esse Edge é atualizado da versão 4.2.x para uma versão 4.3.x ou uma compilação posterior.

  • 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 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 87111 resolvido: quando um VMware SASE Orchestrator é atualizado para a versão 4.3.x ou posterior, os VMware SD-WAN Edges ligados ao Orchestrator que estão configurados para utilizar o BGP não têm a flag de uplink configurada.

    A flag de uplink BGP é adicionada como uma configuração na versão 4.3.0 do SD-WAN e as versões 4.3.0 e posteriores do Edge estão à espera que esteja presente uma flag de uplink.  No entanto, o Orchestrator não está a enviar a atualização da configuração para todos os Edges que não possuem esta flag após ser atualizado.

  • Problema 88621 resolvido: não é possível modificar nem guardar a configuração de um VMware SD-WAN Gateway em migração no VMware SASE Orchestrator.

    Um utilizador operador não consegue atualizar a localização de um Gateway de produção, uma vez que, quando tenta guardar a configuração, o Orchestrator devolve o erro “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" (Cannot change the state of the gateway to null, as it is already used as a replacement gateway).

  • Problema 89346 resolvido: num VMware SASE Orchestrator que utilize a compilação 5.0.0.2, ao gerar um novo relatório no ecrã Monitorizar clientes (Monitor Customers), o relatório recém-gerado é sempre entregue em inglês, mesmo que o idioma do relatório tenha sido especificado como uma língua não inglesa.

    O relatório transferido deve ser apresentado no idioma especificado em Idioma do relatório (Report Language), mas o idioma utilizado é sempre o inglês.

  • 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 (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 será eliminada e o Edge já não conseguirá estabelecer ligação ao par Zscaler.

  • Problema 90128 resolvido: na empresa de um cliente que tenha um Cloud Security Services (CSS) configurado, quando o utilizador altera a configuração do CSS, o evento CSS inclui a chave PSK do CSS. 

    Embora este comportamento não crie uma vulnerabilidade direta, o valor PSK do CSS é uma informação confidencial que não deve ser incluída num ficheiro de registo.

  • Problema 90540 resolvido: num VMware SASE Orchestrator que utilize a versão 5.0.0, quando um VMware SD-WAN Edge com a versão do Edge 4.5.1 é atualizado para a versão 5.0.0, o Edge perde a funcionalidade DNS e sofre uma perda de conectividade à Internet.

    Como parte da atualização do Edge para 5.0.0, a função do Orchestrator é enviar uma configuração do Edge atualizada e a parte do DNS dessa configuração não era compatível com uma compilação 4.5.x do Edge, levando à perda da definições de DNS e impedindo a conectividade à Internet. O Edge continuaria a passar o tráfego para outros locais (por exemplo, o Orchestrator, outros Edges, Hub Edges e Destinos Não-SD-WAN), onde o DNS não é um fator.

  • 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 90835 resolvido: num cliente que utiliza o serviço VMware Cloud Web Security, o utilizador não pode configurar as regras de domínio do Office 365 para o proxy Web no Cloud Web Security com o VMware SASE Orchestrator. 

    O utilizador não pode configurar as regras de domínio do Office 365 (cujo nome foi recentemente alterado para Microsoft 365) para o proxy Web no Cloud Web Security com o assistente de ficheiro PAC.

  • Problema 91054 resolvido: para um cliente que utilize o VMware Cloud Web Security, um utilizador pode encontrar múltiplos problemas de usabilidade na IU do VMware SASE Orchestrator ao tentar configurar a autenticação de início de sessão único.

    Os problemas que um utilizador pode encontrar ao configurar o início de sessão único no serviço Cloud Web Security incluem:

    • Erros de certificado que aparecem na página principal Autenticação (Authentication) em vez de na página Certificado (Certificate).
    • Por vezes, um utilizador pode guardar um certificado inválido.
    • A alteração de um certificado pode, por vezes, repor os outros valores no formulário de autenticação.
    • Os campos individuais não mostram mensagens de validação em linha com o campo.
    • Ao guardar a página Autenticação (Authentication), a IU do Orchestrator não mostra a roda giratória de progresso.
    • A descrição Depuração verbosa mostra “t+2h” em vez de uma hora real.
    • Em certos idiomas, a etiqueta do botão Início de sessão único ocupa mais de uma linha.
    • O esquema do rodapé Guardar alterações não é apresentado corretamente em ecrãs pequenos.

    Todos os problemas listados estão resolvidos nos Orchestrators que incluam uma correção para o problema 91054.

  • 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 91720 resolvido: nas empresas de clientes que utilizem uma topologia Hub/Spoke, os utilizadores podem remover um VMware SD-WAN Hub Edge da configuração do Hub de backhaul, mesmo que esse Hub esteja a ser utilizado com uma política empresarial configurada para utilizar o backhaul da Internet.

    Uma vez configurada uma política empresarial para efetuar o backhaul do tráfego do Edge Spoke através de um Edge Hub, o comportamento esperado é que o VMware SASE Orchestrator “bloqueie” esse Edge Hub e impeça um utilizador de o remover da configuração do Hub de Backhaul na secção Configurações > Definições do dispositivo (Configure > Device Settings). No entanto, com este problema, o utilizador pode remover o Edge Hub e provocar uma perturbação significativa no tráfego do cliente. 

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

  • Problema 95613 resolvido: quando um VMware SASE Orchestrator é atualizado para a compilação R5010-20220803-GA, um cliente ligado a esse Orchestrator pode ter dificuldade em monitorizar os respetivos Edges e, se utilizar chamadas à API, observa que essas chamadas falham. O utilizador operador observaria que o processo da API falha e exigiria um reinício juntamente com uma elevada utilização da CPU no Orchestrator.

    Este problema é desencadeado por um utilizador que configura a respetiva empresa para fazer chamadas à API sem qualquer intervalo de tempo (por outras palavras, cada chamada à API é imediatamente seguida por outra). Esta atividade faz com que o processo da API v2 que trata da chamada à API se depare com uma exceção e falhe quando recebe o pedido da API. A falha do processo da API v2 significa que a monitorização do Edge para dados como estatísticas de ligações (que se baseia em chamadas à API) não apresentará dados precisos e as empresas dos clientes que utilizam as chamadas à API também teriam falhas nas mesmas. Além disso, se a mesma empresa continuar a fazer chamadas à API sem intervalo de tempo, o processo da API v2 ficará efetivamente bloqueado num ciclo de falha e reinício até que essas chamadas à API possam ser interrompidas ou modificadas para incluir um intervalo de tempo. 

    A falha e o reinício do processo da API v2 também causa elevado consumo de CPU do Orchestrator, o que afetará o desempenho global do Orchestrator, para além de lidar com as chamadas à API.

    Nota: este problema está resolvido na compilação R5010-20220817-GA do Orchestrator.

Problemas conhecidos

Problemas pendentes na versão 5.0.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 configurados 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 local 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 podem não ser retirados corretamente quando o caminho é desativado. A reativação do caminho, seguida de uma nova desativação, irá retirá-los 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 codificação da velocidade e do duplex numa porta configurada por DPDK pode exigir o reinício do VMware SD-WAN Edge para que as configurações entrem em vigor, uma vez que exige 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 configurada 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 local 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 vão ser preenchidos com erros IKE e isso pode 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 42872:

    ativar o isolamento de perfil num perfil de Hub em que 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 (DCC) 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 Spoke Edge 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 está desativada, 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 ativar 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 49172:

    Uma regra NAT Baseada em Política configurada com a mesma sub-rede NAT para dois VMware SD-WAN Edges não funciona.

  • Problema 49738:

    Em certos casos, quando o Spoke Edge do VMware SD-WAN é configurado para utilizar vários Edges Hub, o Spoke Edge não consegue formar túneis para um dos Hubs configurados na lista de Hubs.

  • Problema 50518:

    num VMware SD-WAN Gateway onde o PKI está configurado, 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 52955: a recusa DHCP não é enviada a partir do Edge e o reenlace do DHCP não é reiniciado após a falha do DAD no DHCP Dinâmico.

    Se o servidor DHCPv6 atribuir um endereço que é detetado como duplicado pelo kernel durante uma verificação DAD, o cliente DHCPv6 não enviará nenhuma recusa. Isto levará a tráfego ignorado, uma vez que o endereço de interface será assinalado como verificação DAD falhada e não será utilizado. Esta ação não levará a nenhum ciclo de tráfego na rede, mas será observado um bloqueio de tráfego.

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

  • Problema 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 Spoke Edge 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 os valores de preferência e anúncio corretos quando a flag DCC está configurada, provocando uma sequência de ordenação incorreta no FIB do Edge.

    Quando o cálculo de custos distribuídos (DCC) é configurado num cenário dimensionado 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 configurado 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á configurado 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 o BGP não 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) configurado.

    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 Hub Edge, 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 Hub Edge.

    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 Hub Edge, mas a configuração do cluster estava ativada, o que significa que este Hub Edge 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 Hub Edge, o dataplane do Hub Edge 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 Hub Edge assume erradamente que o clustering foi desativado neste segmento global. Como resultado, o Edge Hub derruba todos os túneis das ligações WAN do Hub, o que provoca instabilidades de ligação em todas as ligações WAN desse Edge. Para qualquer incidente deste tipo, as ligações WAN só ficam inativas e recuperam uma vez por atualização do plano de controlo.

    Solução alternativa: a solução alternativa consiste em ativar a VPN de cloud no segmento global.

  • 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 configuradas, 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 configurada.

  • 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 a configuração de CSS e, em seguida, reativá-la, vai 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 uma topologia de alta disponibilidade na qual os Edges implementem VNFs numa configuração HA e estejam a utilizar a versão 4.x, se estes Edges HA forem mudados para a versão inferior 3.4.x, que não suporta VNFs HA, e, em seguida, atualizados para 4.5.0, quando os VNFs HA forem reativados, a VNF no Standby Edge não será ativada. 

    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, de uma versão que suporte VNF-HA (versão 4.0+) para uma versão que não a suporte com a VNF configurada no Orchestrator. Este problema ocorre quando o Edge é atualizado para uma versão que suporta a VNF-HA e é configurado no Orchestrator novamente.

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

  • 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 77541: Quando um modem USB que suporta o IPv6 é desligado e, em seguida, ligado novamente a uma interface USB do VMware SD-WAN Edge, pode não ser aprovisionado um endereço IPv6 na interface USB.

    Isto afeta modems USB baseados em IP, versus geridos pela aplicação ModemManager. A maioria dos modems Inseego são baseados em IP e isso é importante porque o Inseego é o fabricante de modem que o VMware SASE recomenda. Os modems USB que suportam o IPv6 e utilizam o ModemManager versus baseados em IP serão bons num cenário de desligar e ligar novamente.

    Solução alternativa: O Edge tem de ser reiniciado (ou desligado e ligado) depois de o modem USB ser ligado novamente na porta USB do Edge. Após o reinício, o Edge irá recuperar o endereço IPv6 para o modem.

  • Problema 81852: para um VMware SD-WAN Edge que está a utilizar um Serviço de Segurança na Cloud (CSS) do tipo Zscaler que utiliza túneis GRE e ativou a Verificação de estado de funcionamento de L7 (L7 Health Check), quando esse Edge é atualizado para a versão 5.0.0, em alguns casos, o cliente pode observar erros de verificação de estado de funcionamento de L7.

    Isto é normalmente visto durante a atualização do software ou durante o tempo de arranque. Quando a Verificação de estado de funcionamento de L7 (L7 Health Check) verifica se existe um CSS com túneis GRE, podem ser observadas mensagens de erro getaddress relacionadas com o socket. O erro observado é visto de forma intermitente e não consistente. Por causa disso, as mensagens de sonda da Verificação de estado de funcionamento de L7 (L7 Health Check) não são enviadas.

    Solução alternativa: Sem a correção, para remediar o problema, um utilizador tem de desligar e depois voltar a ligar a configuração da Verificação de estado de funcionamento de L7 (L7 Health Check) e esta funcionalidade funciona então como esperado.

  • Problema 82184: num VMware SD-WAN Edge a executar a versão 5.0.0 do Edge, quando um traceroute ou traceroute6 é executado para o endereço IPv4/IPv6 de br-network do Edge, o traceroute não vai terminar corretamente quando é utilizada uma sonda UDP.

    O traceroute ou traceroute6 para o endereço IPv4/IPv6 de br-network do Edge não será corretamente utilizado quando for utilizado o modo predefinido (por outras palavras, a sonda UDP).

    Solução alternativa: Utilize a opção -I em traceroute e traceroute6 para utilizar a pesquisa ICMP e depois o traceroute para o endereço IPv4/IPv6 de br-network funcionará como esperado.

  • Problema 82415: um VMware SD-WAN Gateway que implementou uma imagem KVM com o adaptador de servidor Intel® Ethernet X710, SR-IOV e Bond0 não responde se for ativado para a versão 4.5.0 ou 5.0.0

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

    Solução alternativa: não existe uma solução alternativa. Evite 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 93141: num site implementado com uma topologia de alta disponibilidade, um cliente que utiliza um interruptor L2 a montante do par Edge HA pode observar evidências de um ciclo de tráfego L2 nos registos do interruptor, embora não exista realmente um ciclo.

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

    Solução alternativa: o cliente pode ignorar os eventos de deteção de ciclo L2 dos interruptores a montante provenientes da interface de HA do Edge (normalmente GE1). 

  • Problema 83166: Quando um VMware SD-WAN Gateway é recentemente implementado com um tipo de instância AWS c5.4xlarge do Portal do AWS com a opção IPv6 selecionada, nem o IPv6 nem os caminhos predefinidos estão configurados.

    Como resultado do IPv6 e dos caminhos predefinidos não configurados, os túneis de gestão do Gateway IPv6 do AWS não estão a formar-se e o Gateway não irá funcionar.

    Solução alternativa: Não existe uma solução para este problema, evite a implementação de um Gateway com as propriedades acima mencionadas.

  • Problema 83227: para um VMware SD-WAN Edge a executar a versão 5.0.0 que está configurado com 128 segmentos, o processo dnsmasq do Edge irá parar e encerrar.

    Quando o IPv6 estiver ativado em 128 segmentos e os servidores DCPv6 estiverem configurados na LAN de cada segmento, o processo dnsmasq irá parar ao ser excedido o total de descritores de ficheiros abertos. O processo dnsmasq continuará durante ~30 minutos antes de encerrar, altura em que a atribuição DHCP de endereços IP do Edge irá falhar. 

    Solução alternativa: Reiniciar o Edge restaura o processo dnsmasq durante ~30 minutos, mas voltará a falhar. A única solução alternativa real é reduzir o número de segmentos para menos de 128.

  • Problema 92481: se uma interface WAN num VMware SD-WAN Edge estiver desativada no VMware SASE Orchestrator, continuará a ser comunicada como “Ativa” (UP) pelo SNMP.

    O processo de depuração principal para a saída das interfaces não inclui os detalhes da porta física para interfaces 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.

    Sem uma correção para este problema, um utilizador precisa de configurar 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.

    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 93062: quando um utilizador executa o diagnóstico remoto “Estado da interface” (Interface Status) no VMware Orchestrator, o Orchestrator devolve um erro para esse teste e não é concluído ou o teste não devolve resultados para as interfaces encaminhadas.

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

    Solução alternativa: o utilizador teria de gerar um pacote de diagnóstico para o Edge para ver o estado das interfaces encaminhadas.

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 do 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: ao nível do Edge, desative a GRE e, em seguida, ative-a novamente 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: ao nível do Edge, desative a GRE e, em seguida, ative-a novamente 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 for 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 desativado ao nível do perfil, enquanto também tem uma Anulação de Edge para esta VLAN nesse Edge com o DHCP ativado e existe uma entrada para o campo de servidor DNS definido como 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 60522: na IU do VMware SD-WAN 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 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 62624: 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.

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

  • Problema 68463: ao utilizar a nova IU no VMware SD-WAN 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.

    Solução alternativa: não existe solução alternativa para este problema, além de utilizar a IU antiga para confirmar os valores QoE corretos.

  • Problema 82680: Para o cliente a utilizar a Automação de Túnel MT-GRE, quando um utilizador desliga a flag Interligação cloud a cloud (CCI) num VMware SD-WAN Gateway que está configurado para utilizar o CCI, as entradas Zscaler MT-GRE podem não ser eliminadas do portal Zscaler de forma consistente.

    Depois de um site CCI ter sido eliminado do Gateway, as entradas para este site também devem ser removidas. Este problema só foi visto durante a automação de teste e não foi reproduzido manualmente, mas continua a ser um risco. 

    Solução alternativa: Elimine manualmente o recurso do Zscaler antes de voltar a tentar.

  • Problema 82681: Para o cliente utilizar a automação do túnel MT-GRE, quando um utilizador desliga a flag Interligação cloud a cloud (CCI) num VMware SD-WAN Gateway que está configurado para utilizar o CCI, e o utilizador desativa a flag CCI de um VMware SD-WAN Edge com CCI configurado que está a utilizar um Serviço de Segurança na Cloud Zscaler, as entradas Zscaler MT-GRE podem não ser eliminadas do Edge ou do portal Zscaler.

    Depois de um site CCI ter sido eliminado do Gateway, as entradas para este site também devem ser removidas. Este problema só foi visto durante a automação de teste e não foi reproduzido manualmente, mas continua a ser um risco.

    Solução alternativa: Elimine manualmente o recurso do Zscaler antes de voltar a tentar.

  • Problema 82775: num VMware SASE Orchestrator que utiliza a versão 5.0.0, quando um Serviço de Segurança na Cloud (CSS) do tipo Zscaler é configurado para um cliente e associado a um VMware SD-WAN Edge e, em seguida, uma política empresarial é configurada com uma regra de backhaul CSS, um utilizador não consegue alterar os parâmetros de hash ou encriptação CSS para esse CSS.

    O Orchestrator impede o utilizador de modificar a configuração Zscaler CSS após a associação a uma Política empresarial de Backhaul CSS.

    Solução alternativa: O utilizador tem de eliminar a Política empresarial de Backhaul CSS para modificar a configuração Zscaler CSS e, em seguida, recriar a mesma Política empresarial.

  • Problema 82864: num VMware SASE Orchestrator que utiliza a versão 5.0.0, quando um utilizador está na página Configurar > Perfis (Configure > Profiles) e seleciona “Modificar” (Modify), é redirecionado para a página Perfil > Visão geral (Profile > Overview) em vez da página Perfil > Definições do dispositivo (Profile > Device Settings).

    O botão Configurar > Perfis (Configure > Profiles) “Modificar” (Modify) não está a mapear para a página correta.

    Solução alternativa: não existe uma solução alternativa.

  • Problema 90065: num VMware SASE Orchestrator implementado com ESXi e configurado para Recuperação após desastre (DR), quando o Orchestrator é atualizado para a versão 5.0.1, a replicação de DR falha.

    O problema é provocado por serviços que não são reiniciados no Orchestrator baseado em ESXi após a atualização para a versão 5.0.1, o que impede os utilizadores de replicação de receberem as concessões necessárias e, por conseguinte, bloqueia a replicação de DR. Este problema não é observado num Orchestrator implementado com AWS.

    Solução alternativa: para restaurar a replicação de DR após a atualização num Orchestrator baseado em ESXi, o Operador precisa de reiniciar manualmente os serviços e, em seguida, a replicação será concluída com sucesso.

  • Problema 94668: ao configurar uma regra de política empresarial em que a opção NAT está selecionada, um utilizador pode configurar símbolos inválidos para o endereço IPv6 NAT de origem ou de destino que são aceites pelo VMware SASE Orchestrator.

    Um símbolo inválido é algo que não deve ser utilizado para configurar um endereço IPv6 (por exemplo, %, * ou +). Como resultado, o Orchestrator aceita uma configuração inválida e a regra não funciona para NAT, pois o endereço IPv6 é inválido.

    Solução alternativa: não existe uma solução alternativa para além de o utilizador garantir que os endereços IPv6 são válidos quando configurados para o IPv6 NAT de destino ou de origem.

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 resolvido: 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. 

    Sem a correção, a solução alternativa é defini-lo manualmente na consola UEM.

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