Atualizado a 13 de julho de 2022

VMware SASE™ Orchestrator versão R450-20220502-GA
VMware SD-WAN™ Gateway versão R450-20211123-GA-74198-70416-74482-30022
VMware SD-WAN™ Edge versão R450-20220413-GA
VMware Cloud Web Security™ com a versão R450-20220502-GA do Orchestrator
Versão do VMware Secure Access™ com a versão R450-20220502-GA do Orchestrator
VMware Edge Network Intelligence™ com a versão R450-20220502-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 e características disponibilizadas pela primeira vez na Versão 4.5.0.

Compatibilidade

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

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

Orchestrator

Gateway

Edge

Hub

Ramo/Spoke

4.5.0 

4.2.1 

4.2.1 

4.2.1 

4.5.0 

4.5.0 

4.2.1 

4.2.1 

4.5.0 

4.5.0 

4.5.0 

4.2.1 

4.5.0 

4.5.0 

4.2.1 

4.5.0 

4.5.0 

3.4.5 

3.4.4 

3.4.3 

4.5.0 

4.5.0 

3.4.4 

3.4.3 

4.5.0 

4.5.0 

4.5.0 

3.4.3 

4.5.0 

4.5.0 

3.4.4 

4.5.0 

4.5.0 

 3.3.2 P2 *

 3.3.2 P2 *

 3.3.2 P2 *

4.5.0 

4.5.0 

  3.3.2 P2 * 

 3.3.2 P2 *

4.5.0 

4.5.0 

4.5.0 

 3.3.2 P2 *

4.5.0 

4.5.0 

 3.3.2 P2 *

4.5.0 

4.5.0 

4.3.0 

4.3.0 

4.3.0 

4.5.0 

4.5.0 

4.3.0 

4.3.0 

4.5.0 

4.5.0 

4.5.0 

4.3.0 

4.5.0 

4.5.0 

4.3.0 

4.5.0 

4.5.0 

4.5.0 

 3.2.2 *

 3.2.2 *

4.5.0 

4.5.0 

4.5.0 

 3.2.2 *

4.5.0 

4.5.0 

 3.2.2 *

4.5.0 

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

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 chegará ao fim do suporte geral (EOGS) a 30 de março de 2022 e 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 4.5.0

Orchestrator

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

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

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

Gateway

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

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

Edge

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

Notas importantes

Potencial problema com locais que utilizam uma topologia de alta disponibilidade

Um local onde um par de Edges são implementados numa topologia de alta disponibilidade pode deparar-se com um problema em que o Edge em standby reinicia uma ou mais vezes para resolver um estado Ativo-Ativo. Os reinícios do Edge em standby podem provocar a perturbação do tráfego do cliente, tendo um maior impacto em locais que utilizam uma topologia de HA melhorada, uma vez que o Edge em standby também transmite tráfego do cliente. O problema está a ser monitorizado pelo problema 85369 na secção Problemas conhecidos do Edge/Gateway destas Notas de versão.

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.  Estes serviços estão inacessíveis em Edges que utilizam uma versão anterior à 4.5.0.

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

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

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

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

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

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

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

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

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

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

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.

Novas funcionalidades do SD-WAN

Underlay IPv6 LAN para WAN

Esta funcionalidade proporciona suporte para o seguinte:

  • IPv6 na LAN:
    • Suporte de IPv6 na interface encaminhada (estática, DHCPv6 sem estado, DHCPv6 com estado)
  • Routing IPv6, o SD-WAN Edge suporta:
    • BGPv6 (multi-hop)
    • BFDv6 (multi-hop)
    • Caminhos estáticos IPv6
    • Reverse Path Forwarding IPv6 (rigoroso/livre/desativado)
  • Monitorização IPv6:
    • Contabilização de underlay IPv6
    • Monitorização BGPv6 e BFDv6
    • Diagnóstico remoto para IPv6

Rastreio NAT de Gateway

A funcionalidade de rastreio NAT proporciona um serviço para transmissão de detalhes de rastreio NAT de cada fluxo ao qual o NAT é aplicado pelo Gateway ou Gateway de parceiro para um servidor de registo externo onde os dados podem ser retidos e analisados. 

Migração do Gateway

Esta funcionalidade proporciona aos clientes uma capacidade de gestão personalizada para migrar Gateways. Os parceiros e clientes podem utilizar esta funcionalidade para migrar os túneis de Destino-Não SD-WAN via Gateway e reequilibrar os Gateways utilizando um fluxo de trabalho orientado.

Melhorias de funcionalidades do SD-WAN

Administração unificada

A versão 4.5.0 oferece suporte para novas funções prontas a utilizar para uma administração mais granular dos serviços SASE. Podem ser criadas funções personalizadas com o novo Criador de funções disponível na nova interface de utilizador angular do Orchestrator. Os serviços Cloud Web Security e Secure Access podem ter as suas próprias funções dedicadas para fornecer separação de funções e utilizadores entre o SD-WAN, o Edge Network Intelligence, o Cloud Web Security e o Secure Access.

Automatização GRE da integração do Zscaler no SD-WAN Edge

A criação do túnel GRE a partir do SD-WAN Edge para Zscaler é agora automatizada com APIs. O fluxo de trabalho automatizado seleciona os dois Edges de serviço mais próximos. A verificação do estado de funcionamento da camada 7 pode ser ativada como parte do fluxo de trabalho automatizado.

Novas funcionalidades do SASE

Prevenção de perda de dados (DLP)

A Prevenção de perda de dados (DLP) protege um cliente de Cloud Web Security contra a perda de partilhas acidentais ou intencionais de dados restritos. A funcionalidade DLP está disponível para clientes Cloud Web Security com um Pacote Avançado. O DLP do Cloud Web Security inclui as seguintes capacidades:

  • Evita a perda de dados para garantir o cumprimento das leis HIPAA, PCI, RGPD e outras leis de privacidade de dados.
  • Mais de 350 dicionários prontos a utilizar para inspecionar o tráfego.
  • Podem ser configurados dicionários personalizados com cadeias ou expressões regulares.
  • A atividade que não esteja em conformidade é reportada aos administradores designados.

Nota: Esta funcionalidade está acessível a partir da compilação R450-20220315-GA do VMware SASE Orchestrator. Uma compilação do Orchestrator 4.5.0 anterior à R450-20220315-GA está limitada às novas funcionalidades do SASE listadas abaixo.

Mediador de segurança de acesso à cloud (Cloud Access Security Broker – CASB)

O Mediador de segurança de acesso à cloud (Cloud Access Security Broker – CASB) proporciona visibilidade e controlo sobre as atividades dos utilizadores durante o acesso às aplicações SaaS. O CASB do Cloud Web Security inclui as seguintes capacidades:

Visibilidade da aplicação (parte da edição Standard e dos pacotes avançados do Cloud Web Security): o cliente pode visualizar as diferentes aplicações SaaS que estão a ser acedidas pelos utilizadores na respetiva rede. 

Em cada aplicação, o cliente que utilize a Visibilidade da aplicação (Application Visibility) do CASB pode observar:

  • A classificação de risco de cada aplicação. 
  • O número de vezes que os utilizadores acederam a uma aplicação.
  • A categoria da aplicação.

Controlo de aplicações (parte apenas do pacote avançado do Cloud Web Security): o cliente tem a capacidade de controlar ações específicas que podem ser realizadas em cada aplicação SaaS. Estão disponíveis controlos predefinidos prontos a utilizar para todas as aplicações SaaS, com controlos específicos da aplicação fornecidos ao nível da mesma. Estes controlos podem ser personalizados e configurados por aplicação e basear-se num utilizador ou grupo de utilizadores.

Em cada aplicação, o cliente que utilize o Controlo de aplicações (Application Control ) do CASB pode controlar:

  • O acesso inicial ao site da aplicação (Permitir ou Bloquear).
  • Ações adicionais, incluindo Iniciar sessão, Carregar/Transferir conteúdos, Pesquisar, Editar, Partilhar, Criar, Eliminar, Gostar ou Publicar.

Os clientes podem ver as ações atualmente disponíveis para as aplicações que desejam controlar.

Suporte Brownfield para implementações híbridas

Os clientes em implementações existentes com a versão 4.3.0 ou anterior que utilizam Gateways de parceiro em Orchestrators alojados pela VMware ou por parceiros podem agora aceder a serviços SASE, como o Cloud Web Security e o Secure Access, quando todos os componentes (Orchestrator, Gateway e Edge) forem atualizados para a versão 4.5.0. 

Assim que o cliente estiver totalmente atualizado para a versão 4.5.0, poderá aceder aos serviços Cloud Web Security e Secure Access através de PoPs SASE alojados pela VMware.

Novas funcionalidades do Edge Network Intelligence

Aplicação cliente do Edge Network Intelligence

A aplicação cliente do Edge Network Intelligence está agora disponível globalmente. A aplicação cliente pode ser utilizada para determinar se um utilizador final tem problemas em aceder a aplicações devido à conetividade de VPN, Internet ou Wi-Fi local. Está disponível no macOS X e Windows 10.

Acesso de parceiro ao Edge Network Intelligence   

Os parceiros podem aceder ao Edge Network Intelligence a partir do Orchestrator e poderão iniciar a análise de aplicação e ramo.

Anotação automática de eventos do Orchestrator    

O histórico de rede do Edge Network Intelligence irá anotar automaticamente eventos-chave do Orchestrator. Isto pode ser utilizado para identificar se os eventos no Orchestrator afetaram o desempenho de linha de base de um Edge.

Webhooks para alertas    

É possível configurar webhooks para a notificações de alertas. A notificação irá fornecer detalhes sobre a prioridade, o número de dispositivos afetados, a causa raiz e os passos seguintes sugeridos para o alerta.

Ativação de gestão personalizada da integração do Zoom

Os clientes podem agora aceder a A minha conta > Feeds (My Account > Feeds) e encontrar a ligação necessária para ativar a integração do Zoom.

Relatório de impacto de AP inativo

O relatório de impacto de AP irá fornecer um resumo dos APs com eventos de inatividades que afetaram os clientes.

Suporte para novas plataformas de hardware

Edge 510N, Edge 610N, Edge 620N, Edge 640N e Edge 680N

A VMware planeia introduzir vários modelos de hardware SD-WAN Edge novos que não incluem Wi-Fi integrado. Estes incluem o Edge 510N, 610N, 620N, 640N e 680N. Estes modelos Edge serão suportados nesta versão. As configurações Wi-Fi efetuadas nas definições do VMware SD-WAN/SASE Orchestrator não afetarão estes modelos Edge.

Alterações à API do Orchestrator desde a versão 4.3.x e 4.4.x

Nova página inicial para a documentação da API da VMware SASE Platform 

Está agora disponível documentação de referência abrangente da API para os serviços que compõem a VMware SASE Platform (incluindo o SD-WAN, o Cloud Web Security e o Secure Access) através do novo portal para programadores da VMware, developer.vmware.com

Alterações à API (“v1”) do portal do SD-WAN Orchestrator 

Está disponível um registo de alterações abrangente da API juntamente com a referência da API do portal do Orchestrator 4.5.0 em code.vmware.com

As seguintes alterações podem exigir uma ação por parte daqueles que mantêm clientes API, de modo a evitar perturbações nas aplicações cliente: 

  • 66011: o método da API linkQualityEvent/getLinkQualityEvents apresentava anteriormente um comportamento não determinístico relativamente à inclusão de informações de classificação ao nível da amostra em amostras de uma série temporal. Após esta alteração, o parâmetro de pedido “individualScores” tem de ser especificado para acionar os relatórios de classificação ao nível da amostra. 

  • 68447: a versão 4.3.0 estabeleceu um esquema de “sublocalizações” de segurança na cloud na secção de opções de segurança de cloud (“css”) no módulo de configuração deviceSettings (modelo “device_settings_cloud_security” na referência da API) com o objetivo de configurar sublocalizações Zscaler. Isto foi migrado para uma nova secção “zscaler” do esquema de configuração deviceSettings (ver modelo atualizado “segmentBasedDeviceSettingsData”). Após a atualização para a versão 4.5.0 do Orchestrator, é executado um patch de sistema que converte os módulos de configuração deviceSettings que seguem o esquema antigo no novo. O Orchestrator já não respeita o esquema antigo e os clientes que produzem opções de configuração de sublocalizações consistentes com o esquema antigo devem ser atualizados para garantir que produzem dados em conformidade com o novo esquema. 

  • 70202: como resultado de uma alteração na base de dados subjacente que é utilizada para registar os dados de QoE de ligação (e uma alteração anexa ao comportamento de processamento, que se destina à melhoria do desempenho de consulta e produz comportamentos mais alinhados com outras APIs de métricas), os utilizadores que consultam dados de QoE “ao minuto” com o método da API linkQualityEvent/getLinkQualityEvents podem ver informações de classificação com uma fidelidade mais reduzida no período de 15 minutos mais recente. Recomendamos a utilização de um intervalo de consulta não inferior a 20 minutos durante a consulta de dados ao minuto. 

  • Por motivos de segurança, foi adicionada uma validação de sintaxe mais rigorosa para os métodos da API que se seguem. Recomenda-se aos programadores que dependem destes métodos da API que revejam a utilização dos mesmos e garantam que a sintaxe dos parâmetros está em conformidade com a sintaxe documentada na referência da API. 

  • configuration/getConfiguration 

  • edge/deleteEdge 

Alterações à API v2 do SD-WAN Orchestrator 

Os problemas 66011 e 70202 aplicam-se também aos utilizadores dos métodos APIv2 que consultam eventos de qualidade de ligação. 

Histórico de revisões do documento

30 de setembro de 2021. Primeira edição

8 de outubro de 2021. Segunda edição

  • Foi adicionada uma nova compilação R450-20211006-GA do Orchestrator que inclui a funcionalidade CASB para os utilizadores do Cloud Web Security.
  • Foi adicionada uma descrição da função CASB na secção Novas funcionalidades do Cloud Web Security das notas de versão.
  • Foi adicionado o Problema resolvido 71278 ao problema resolvido do Orchestrator para a R450-20211006-GA.  
  • Foi adicionado o Problema resolvido 72485 na secção Problemas resolvidos do Cloud Web Security, uma vez que a disponibilização do CASB estava dependente deste problema estar resolvido. Esta correção está incluída na compilação R450-20211006-GA.
  • Foi adicionada uma nova compilação R450-20211007-GA-72423 do GA Edge.
  • Foi adicionado um novo Problema resolvido 72493 como parte da nova secção para a compilação R450-20211007-GA-72423 do Edge.
  • Foi removida a melhoria da funcionalidade “Reduzir o controlo do tráfego e a gestão do SD-WAN nas ligações sem fios”, dado que esta tinha sido incluída erradamente, pois esta funcionalidade não está incluída na versão 4.5.0 do GA.

13 de outubro de 2021. Terceira edição

  • Foi adicionada uma nova compilação R450-20211012-GA do Orchestrator.
  • Foram adicionados os Problemas resolvidos 72386 e 72424 aos problemas resolvidos do Orchestrator para a R450-20211012-GA.

25 de outubro de 2021. Quarta edição

  • Foi adicionada uma nova compilação R450-20211022-GA-74198 do Gateway à secção Problemas resolvidos do Edge/Gateway.  Esta compilação é a nova compilação GA do Gateway para a versão 4.5.0.
  • Esta compilação do Gateway adiciona o problema resolvido 74198, que se encontra documentado nesta secção.
  • Foi removido o Problema em aberto 52104, uma vez que foi resolvido na versão 4.2.x, e o Problema em aberto 52483, uma vez que foi fechado antes desta versão.

2 de novembro de 2021. Quinta edição

  • Foi adicionada uma nova compilação R450-20211101-GA do Orchestrator à secção Problemas resolvidos do Orchestrator.
  • Foram adicionados os Problemas resolvidos 63110, 64762, 69570, 69912, 72041, 73910, 74038, 74106, 74187, 74460 e 74491 aos problemas resolvidos do Orchestrator da R450-20211029-GA.
  • Foi adicionada uma nova compilação R450-20211029-GA-74198-70416 do Gateway à secção Problemas resolvidos do Edge/Gateway.  Esta compilação é a nova compilação GA do Gateway para a versão 4.5.0.
  • Esta compilação do Gateway adiciona o problema resolvido 70416, que se encontra documentado nesta secção.

8 de novembro de 2021. Sexta edição

  • Foi adicionada uma nova compilação R450-20211104-GA-74198-70416-74482 do Gateway à secção Problemas resolvidos do Edge/Gateway.  Esta compilação é a nova compilação GA do Gateway para a versão 4.5.0.
  • Esta compilação do Gateway adiciona o problema resolvido 74482, que se encontra documentado nesta secção.

10 de novembro de 2021. Sétima edição

  • Foi adicionada uma nova compilação R450-20211109-GA do Orchestrator à secção Problemas resolvidos do Orchestrator.
  • Foram adicionados os Problemas resolvidos 69196, 72018, 72020, 75311 e 75433 aos problemas resolvidos do Orchestrator para a R450-20211109-GA.
  • Foi adicionado o problema 75188 aos Problemas conhecidos do Orchestrator.

22 de novembro de 2021. Oitava edição

  • Foi adicionada uma nova compilação R450-20211120-GA do Orchestrator à secção Problemas resolvidos do Orchestrator.
  • Foram adicionados os Problemas resolvidos 71490, 75188, 75781 e 75859 aos problemas resolvidos do Orchestrator para a R450-20211120-GA.

30 de novembro de 2021. Nona edição

  • Foi adicionada uma nova compilação R450-20211123-GA-74198-70416-74482-30022 do Gateway à secção Problemas resolvidos do Edge/Gateway.  Esta compilação é a nova compilação GA do Gateway para a versão 4.5.0.
  • Esta compilação do Gateway não adiciona novos problemas resolvidos, mas contém alterações de resolução de problemas exigidas pela VMware Engineering. Especificamente, melhorias na formatação do registo de depuração do Gateway.

21 de dezembro de 2021. Décima edição

  • Foi adicionada uma nova compilação R450-20211218-GA do Orchestrator aos Problemas resolvidos do Orchestrator. Esta compilação do Orchestrator remedeia a CVE-2021-44228, a vulnerabilidade do Apache Log4j, ao atualizar para a versão Log4j 2.16.0. Para obter mais informações sobre a vulnerabilidade do Apache Log4j, consulte o VMware Security Advisory VMSA-2021-0028.5.
  • Foi adicionada às Notas importantes a seguinte nota: Limitação ao desativar a negociação automática nos modelos VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 e 3810. Esta nota aborda um problema que pode ser encontrado ao configurar uma velocidade forçada em algumas portas Ethernet dos modelos Edge indicados.

28 de janeiro de 2022, décima primeira edição

  • Foi adicionada uma nova compilação R450-20220120-GA do Edge à secção Problemas resolvidos do Edge. Esta compilação é a nova compilação GA do Edge para a versão 4.5.0.
  • Esta compilação do Edge inclui os problemas corrigidos 72413, 74313 e 76173, que se encontram documentados nesta secção.
  • O problema 58791 resolvido do Edge foi editado de forma a esclarecer as condições em que pode ocorrer e também foi simplificada a linguagem utilizada na descrição dos motivos pelos quais o problema acontece.

10 de fevereiro de 2022, décima segunda edição

  • Foi adicionada uma nova compilação R450-20220203-GA do Edge à secção Problemas resolvidos do Edge. Esta compilação é a nova compilação GA do Edge para a versão 4.5.0.
  • Esta compilação do Edge inclui os problemas corrigidos 34234, 53951, 76196, 72423, 77525 e 81672, que se encontram documentados nesta secção.
  • Foram alteradas as descrições do problema 72423, conforme presente nas compilações R450-20211007-GA-72423 e R450-20220120-GA, para observar o facto de existir potencial para um cenário de caso raro, mesmo com a correção totalmente resolvida na compilação R450-20220202-GA.

17 de fevereiro de 2022, décima terceira edição

  • Foi adicionada uma nova compilação R450-20220215-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta compilação é a nova compilação GA do Orchestrator para a versão 4.5.0.
  • Foram adicionados os Problemas resolvidos 64410, 64438, 68153, 74284 e 74491. Foram adicionados os Problemas resolvidos 74674, 74710, 74715, 74825, 77043, 77101, 80613, 81498 e 81599 aos problemas resolvidos do Orchestrator para a R450-20220215-GA.
  • Os problemas dos Orchestrators corrigidos afetam os serviços VMware SASE da seguinte forma:
    • VMware SD-WAN: 74491, 77043, 77101, 80613, 81498 e 81599.
    • VMware Cloud Web Security: 64410, 64438, 74284, 74674, 74710, 74715 e 74825
    • VMware Secure Access: 64410

21 de fevereiro de 2022. Décima quarta edição

  • Foi adicionado o Problema resolvido 65466 à secção Problemas resolvidos do Edge/Gateway. Esta correção foi incluída na versão GA original dos Edges e Gateways e foi omitida, por engano, da 1.ª edição das Notas de lançamento da versão 4.5.0.

3 de março de 2022. Décima quinta edição

  • Nota importante adicionada: Misturar Edges capazes de Wi-Fi e não capazes de Wi-Fi em alta disponibilidade não é suportado. 

17 de março de 2022, décima sexta edição

  • Foi adicionada uma nova compilação R450-20220315-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta compilação é a nova compilação GA do Orchestrator para a versão 4.5.0.
  • A compilação R450-20220315-GA do Orchestrator inclui acesso à funcionalidade de Prevenção de perda de dados (DLP) para os clientes do Cloud Web Security com um pacote avançado.
  • Foi adicionada uma descrição da função DLP na secção Novas funcionalidades do SASE das notas de versão.
  • Esta compilação do Orchestrator remedeia a CVE-2021-45046, a vulnerabilidade do Apache Log4j, ao atualizar para a versão Log4j 2.17.0. Para obter mais informações sobre a vulnerabilidade do Apache Log4j, consulte o VMware Security Advisory VMSA-2021-0028.13.
  • Foram adicionados os Problemas resolvidos 69573, 76036, 79324, 83534, 83538, 83822, 83940, 84286, 84297, 84299 e 84300 aos problemas resolvidos do Orchestrator da R450-20220315-GA.
  • Os problemas dos Orchestrators corrigidos afetam os serviços VMware SASE da seguinte forma:
    • VMware SD-WAN: 76036
    • VMware Cloud Web Security: 79324, 83534, 83822, 83940, 84286, 84297, 84299 e 84300.
    • VMware Secure Access: 69573 e 83538.
  • Foi adicionado o Problema resolvido 64713 à secção Problemas resolvidos do Edge/Gateway. A correção deste problema foi incluída na compilação R450-20210922-GA do Edge GA original, mas foi omitida por lapso antes desta edição.
  • Na secção Compatibilidade, foi adicionado um novo Aviso a indicar que a versão 3.4.x do software está a chegar ao fim do suporte para o Orchestrator e o Gateway com o fim do suporte geral (EOGS) a 30 de março de 2022 e o fim da orientação técnica (EOTG) a 30 de junho de 2022. Diz apenas respeito ao Orchestrator e ao Gateway. O software 3.4.x do Edge está agendado para chegar ao fim do suporte a partir de 31 de dezembro de 2022.
  • Foi adicionada uma nova Nota importante, relativa à Limitação do BGP através de IPsec no Edge e no Gateway e automatização da WAN Virtual do Azure. A nota indica: “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”.

23 de março de 2022, décima sétima edição

  • Foi adicionado o Problema 84825 à secção Problemas resolvidos do Edge/Gateway.
  • Edição adicional do Problema corrigido 58791 para remover as partes que indicam que este pedido corrige o site HA configurado com um número elevado de filtros de correspondência e definição BGP. Esta parte do problema não é corrigida neste pedido, é registada com o problema 84825.

9 de abril de 2022. Décima oitava edição

  • Foi adicionada uma nova compilação rollup R450-20220404-GA do Edge à secção Problemas resolvidos do Edge. Esta é a terceira compilação rollup do Edge e é a nova compilação GA do Edge para a versão 4.5.0.
  • A compilação R450-20220404-GA do Edge inclui os problemas resolvidos 67201, 67336, 72245, 72718, 77625, 78003, 80551, 80654, 83432 e 84106, que se encontram documentados nesta secção.
  • Foi adicionado um novo Problema pendente 83212 à secção Problemas conhecidos do Edge/Gateway.
  • Foi adicionado o Problema pendente 62701 à secção Problemas conhecidos do Edge/Gateway, uma vez que, neste momento, este problema continua por resolver em todas as versões.

25 de abril de 2022. Décima nona edição

  • Foi adicionada uma nova compilação rollup R450-20220413-GA do Edge à secção Problemas resolvidos do Edge. Esta é a quarta compilação rollup do Edge e é a nova compilação GA do Edge para a versão 4.5.0.
  • A compilação R450-20220413-GA do Edge inclui os problemas resolvidos 78300 e 85375, que se encontram documentados nesta secção.

4 de maio de 2022, vigésima edição

  • Foi adicionada uma nova compilação R450-20220502-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a oitava compilação rollup do Orchestrator e é a nova compilação GA do Orchestrator para a versão 4.5.0.
  • A compilação R450-20220502-GA do Orchestrator inclui os problemas resolvidos 78688, 84214 e 84969, que se encontram documentados nesta secção.
  • Foram removidos os problemas 46254 e 49738 da secção Problemas conhecidos do Edge/Gateway, uma vez que foram resolvidos com a versão 4.3.0 e, portanto, também estão resolvidos na 4.5.0.

27 de maio de 2022, vigésima primeira edição

  • Foi adicionado o Problema 85369 à secção Problemas resolvidos do Edge/Gateway.

8 de junho de 2022, vigésima segunda edição

  • Foi adicionada uma nova Nota importante: “Potencial problema com locais que utilizam uma topologia de alta disponibilidade” relativamente a problemas em curso com locais de clientes que utilizam uma topologia de alta disponibilidade para um par de Edges. Este problema continua a ser monitorizado pelo problema 85369 localizado nos Problemas conhecidos do Edge/Gateway.
  • Em Compatibilidade, foram corrigidas as datas de fim de vida para o software do Edge da versão 4.2.x. O software do Edge é discriminado como um item à parte e agora indica o seguinte: “A versão 4.2.x do Edges chegará ao fim do suporte geral (EOGS) a 30 de junho de 2023 e ao fim da orientação técnica (EOTG) a 30 de setembro de 2023”.  A entrada separada do Orchestrator e do Gateway mantém as mesmas datas de fim de vida como anteriormente.
  • O problema 53951 resolvido foi revisto na secção Problemas resolvidos do Edge/Gateway de forma a incluir outro cenário que pode afetar um cliente que encontre este problema no campo.

13 de julho de 2022. Vigésima terceira edição

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

Problemas resolvidos

Os problemas resolvidos são agrupados da seguinte forma.

Problemas resolvidos do Edge

Resolvido na versão R450-20220413-GA do Edge

A versão R450-20220413-GA do Edge foi lançada a 25-04-2022 e é o quarto rollup do Edge para a versão 4.5.0.

Esta compilação rollup do Edge aborda os problemas críticos abaixo desde o terceiro rollup do Edge, versão R450-20220404-GA.

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

___________________________________________________________________

Resolvido na versão R450-20220404-GA do Edge

A versão R450-20220404-GA do Edge foi lançada a 05-04-2022 e é o terceiro rollup do Edge para a versão 4.5.0.

Esta compilação rollup do Edge aborda os problemas críticos abaixo desde o segundo rollup do Edge, versão R450-20220203-GA.

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

    Quando o Edge em standby é detetado, o Edge Ativo sincroniza todas as informações de caminho para o Edge em standby.  No entanto, quando existe um número elevado de mensagens de sincronização de caminho, a forma como o Edge processa estas mensagens de sincronização de caminho pode levar a uma falha do Serviço dataplane no Edge em standby ou a uma inversão da prioridade do thread, o que causará um atraso no processamento do heartbeat, enquanto o processamento pode levar a um estado Ativo/Ativo. Em qualquer situação, numa topologia HA convencional, o impacto do cliente deverá ser mínimo, dado que o Edge em standby não está a passar o tráfego do cliente. No entanto, 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. Um Edge HA que inclui esta correção melhorou o caminho do código de processamento de informações para evitar que o problema ocorra.

  • Problema 67336 resolvido: quando um utilizador consulta a página Monitorização (Monitoring) do Orchestrator para um VMware SD-WAN Edge, as estatísticas de transporte mostram valores muito mais baixos quando comparados com as estatísticas de aplicação para esse Edge.

    O problema impede que um utilizador consiga obter uma imagem precisa do débito de um determinado Edge, uma vez que não sabe qual é o conjunto de dados correto. O problema é o resultado de as estatísticas de transporte não incluírem as estatísticas de contabilização de underlay, ao contrário das estatísticas de aplicação, que o fazem.

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

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

  • Problema 72718 resolvido: num local de clientes que utilize um Destino Não-SD-WAN (NSD) via Edge, em que o backhaul da Internet está configurado para encaminhar o tráfego através do NSD via Edge, o tráfego falha para destinos com a regra de backhaul.

    O backhaul para um NSD via Edge falha devido a um problema decorrente do facto de o ID de destino não ter sido substituído. O tráfego anterior que não estava a ser interligado ao NSD corresponde a um caminho da cloud predefinido cujo destino é o Gateway. O serviço SD-WAN não substitui o destino do caminho da cloud mais antigo com o ID lógico do NSD mais recente e, portanto, o tráfego falha durante a correspondência de regra de backhaul.

  • Problema 77625 resolvido: num site de cliente implementado com uma topologia de alta disponibilidade, o utilizador pode observar que o Edge em standby do VMware SD-WAN reinicia várias vezes.

    O site entra num estado Ativo/Ativo (Split-Brain) devido à prioridade do thread HA estar invertida, um thread de prioridade inferior tem prioridade e impede um thread de prioridade superior de funcionar, o que provoca um atraso no processamento do heartbeat e leva a que o Edge em standby seja incorretamente promovido para Ativo. Num estado ativo-ativo, o tie-break vai para o Edge ativo e o Edge em standby é reiniciado para o despromover de volta ao seu estado rm standby adequado. No entanto, neste caso, o evento Ativo/Ativo é detetado várias vezes com reinícios do Edge em standby todas as vezes para recuperar o site. 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. 

    Os problemas de campo envolveram os modelos Edge 6x0 (610, 620, 640, 680) mas o problema é agnóstico da plataforma e pode ocorrer em outros modelos Edge.

  • Problema 78003 resolvido: para um cliente que utiliza uma topologia Hub/Spoke, os túneis estáticos do Edge Spoke VMware SD-WAN para um Edge Hub podem não ser formados.

    Normalmente, se houver um grande número de túneis Edge a Edge dinâmicos já estabelecidos no Spoke Edge, a verificação do número máximo de túneis é atingida no Spoke para o túnel estático, e esta verificação impede a formação de túneis estáticos do Spoke para o Hub.

  • Problema 80551 resolvido: Nos modelos VMware SD-WAN Edge que incluem um modem LTE interno (Edge 510-LTE e Edge 610-LTE), os túneis LTE através de uma ligação IPV6 tornam-se INSTÁVEIS quando o endereço IPv6 na interface CELL muda.

    Sempre que o endereço IPv6 numa interface CELL muda (por exemplo, devido à expiração da concessão DHCP), os túneis IPv6 tornam-se INSTÁVEIS. Isto porque os túneis continuam a utilizar o antigo endereço IPv6 em vez do novo.

    Sem a correção, a única forma de remediar o problema é reiniciar o serviço do Edge.

  • Problema 80654 resolvido: num site configurado com uma topologia de Alta disponibilidade melhorada, um utilizador pode verificar quedas de tráfego intermitentes nas ligações WAN do VMware SD-WAN Edge em standby.

    Quando há flaps de caminho frequentes (caminhos adicionados e eliminados frequentemente), a ligação TCP entre os Edges ativo e em standby é reposta em determinados cenários de tempo, provocando quedas de pacotes relativas ao tráfego que atravessa uma ligação WAN no Edge em standby.

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

___________________________________________________________________

Resolvido na versão R450-20220203-GA do Edge

A versão R450-20220203-GA do Edge foi lançada a 10-02-2022 e resolve os problemas críticos abaixo desde a versão R450-20220120-GA do Edge.

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

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

  • Problema 53951 resolvido: um VMware SD-WAN Edge pode deparar-se com uma falha de tráfego enviada diretamente para a Internet ou uma perda de conetividade ao VMware SD-WAN Orchestrator e o Edge é marcado como inativo.

    Este problema pode afetar um Edge num de dois cenários:

    1. Para um Edge que utiliza ligações WAN públicas, quando ocorre um flap (a ligação fica inativa e, em seguida, ativa) numa ligação WAN, o impacto para o cliente neste cenário é que o tráfego que é direcionado para a ligação afetada e também é classificado como Direto é ignorado. Este problema afeta especialmente um local onde as regras da política empresarial são configuradas para forçar determinado tráfego a utilizar uma ligação WAN apenas enquanto também for enviado como Direto.
    2. Ao ativar a HA num Edge com ligações WAN PPPoE, ocorre uma alteração na mudança do IP da interface PPPoE: o caminho próprio antigo é eliminado, mas, com o novo endereço IP PPPoE, o novo caminho próprio não é adicionado. Como resultado, a comunicação entre o Orchestrator e o Edge deixa de funcionar.

    Sem a correção, a forma de corrigir temporariamente o problema é reiniciar o serviço do Edge para garantir que o tráfego direto é enviado ou reiniciar o Edge (onde são utilizadas ligações PPPoE), o que recupera o caminho para o Orchestrator.

  • Problema 72423 resolvido: o VMware SD-WAN Edge fica offline no VMware SD-WAN Orchestrator e não está acessível se o servidor DNS público do Edge não for o DNS da Google.

    Neste caso, o servidor DNS configurado para um Edge no Orchestrator não é o DNS da Google, mas os pacotes DNS para domínios específicos (como *.nyansa.com e *.velocloud.net) continuarão a ser enviados para o servidor DNS da Google (8.8.8.8/8.8.4.4). (Este é um comportamento esperado.) 

    Quando um pacote DNS é recebido do kernel, só é reencaminhado se o IP de destino for o mesmo que o configurado no Orchestrator. Se o IP de destino não corresponder ao configurado no Orchestrator, o Edge ignora esse pacote. No entanto, o Edge não liberta esse pacote, o que provoca uma fuga da memória intermédia. É a fuga da memória intermédia que, em última análise, faz com que o Edge não responda.

    Sem a correção, como uma solução alternativa, os clientes poderiam garantir que o DNS da Google está configurado como o servidor DNS público para todos os seus Edges.  No caso de um Edge num estado inacessível, o cliente necessita de reiniciar o Edge para o recuperar.

    Nota: esta correção foi incluída em duas compilações anteriores da versão 4.5.0: R450-20211007-GA-72423 e R450-20220120-GA. Embora a correção nessas compilações resolva o problema principal, existe um cenário extremamente raro em que, se um cliente enviar tráfego destinado a um servidor DNS completamente diferente do que o cliente configurou (independentemente do serviço DNS configurado e de ser um serviço que não o DNS da Google), o problema pode ocorrer mesmo com a correção encontrada nestas compilações. A correção nesta compilação R450-20220203-GA também resolve este caso e deve ser considerada como a correção completa do problema 72423.

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

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

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

  • Problema 77525 resolvido: para um local que utilize uma topologia de Alta Disponibilidade, quando os VMware SD-WAN HA Edges são atualizados para uma nova imagem de software, o Edge em standby pode não conseguir atualizar e a IU do VMware SD-WAN Orchestrator lista incorretamente o estado do Edge em standby como “Ativo”, mesmo que não esteja.

    Quando o Edge ativo deteta o Edge em standby, tenta obter a versão do software do Edge em standby e, se a versão for superior a 3.4.x, o Edge ativo copia o ficheiro de configuração da rede para o Edge em standby. Durante a obtenção da versão do software do Edge em standby, pode haver uma exceção que não é processada pelo código de HA do Edge, o que faz com que um thread de trabalho de HA seja afetado e a comunicação com o Edge em standby falhe. Neste momento, o processo de gestão entre o Edge ativo e em standby foi interrompido e o que quer que se relacione com o plano de gestão, incluindo a gestão de software, o estado do Edge em standby e as alterações da configuração, não será sincronizado entre o Edge ativo e em standby. Isto resulta no facto de o Edge em standby ser falsamente detetado como ativo e aparecer como um estado de “split brain” ativo/ativo no Orchestrator, o que não acontece, já que o Edge em standby continua a desempenhar a função adequada.

    Se ocorresse uma recuperação automática HA e o Edge em standby fosse promovido para ativo, o Edge estaria com um conjunto de configurações e software incompatíveis. O Orchestrator detetaria a incompatibilidade da configuração e emitiria a configuração atualizada para este Edge, ao mesmo tempo que também completaria a atualização do software que o Edge em standby falhou anteriormente. Como uma atualização do software do Edge requer um reinício, o cliente observaria outra falha enquanto o novo Edge ativo fosse reiniciado e, em seguida, despromovido de volta para o estado em standby. 

    Este problema não é encontrado de forma consistente quando um local HA atualiza o software dos Edges. Além disso, este problema também pode ocorrer quando se cria um novo site HA, ou quando um site autónomo é colocado em Alta Disponibilidade, sempre que o Edge em standby tem de atualizar o respetivo software. Contudo, estes cenários secundários são mais raros quando comparados com Edges HA submetidos a uma atualização do software.

    Sem a correção, um cliente que observasse este problema teria de reiniciar o serviço Edge ou acionar uma recuperação automática HA para resolver o problema.

  • Problema 81672 resolvido: um VMware SD-WAN Edge 510-LTE pode experienciar uma falha do Serviço dataplane após um reinício, um ciclo de energia ou uma atualização do software (que requer um reinício para ser concluída).

    Quando a interface CELL num Edge 510-LTE surge após um reinício ou uma atualização do software, pode ocorrer um problema de tempo e o Serviço dataplane do Edge falha e exige um reinício para recuperar. Após o reinício, o serviço funciona corretamente. 

___________________________________________________________________

Resolvido na versão R450-20220120-GA do Edge

A versão R450-20220120-GA do Edge foi lançada a 27-01-2022 e resolve os problemas críticos abaixo desde a versão R450-20211007-GA-72423 do Edge.

  • Problema 72423 resolvido: o VMware SD-WAN Edge fica offline no VMware SD-WAN Orchestrator e não está acessível se o servidor DNS público do Edge não for o DNS da Google.

    Neste caso, o servidor DNS configurado para um Edge no Orchestrator não é o DNS da Google, mas os pacotes DNS para domínios específicos (como *.nyansa.com e *.velocloud.net) continuarão a ser enviados para o servidor DNS da Google (8.8.8.8/8.8.4.4). (Este é um comportamento esperado.) 

    Quando um pacote DNS é recebido do kernel, só é reencaminhado se o IP de destino for o mesmo que o configurado no Orchestrator. Se o IP de destino não corresponder ao configurado no Orchestrator, o Edge ignora esse pacote. No entanto, o Edge não liberta esse pacote, o que provoca uma fuga da memória intermédia. É a fuga da memória intermédia que, em última análise, faz com que o Edge não responda.

    Sem a correção, como uma solução alternativa, os clientes poderiam garantir que o DNS da Google está configurado como o servidor DNS público para todos os seus Edges.  No caso de um Edge num estado inacessível, o cliente necessita de reiniciar o Edge para o recuperar.

    Nota: embora a correção nesta compilação resolva o problema principal, existe um cenário extremamente raro em que, se um cliente enviar tráfego destinado a um servidor DNS completamente diferente do que o cliente configurou (independentemente do serviço DNS configurado e de ser um serviço que não o DNS da Google), o problema pode ocorrer mesmo com a correção encontrada nesta compilação. A compilação R450-20220203-GA também resolve este caso e deve ser considerada como a correção completa do problema 72423.

  • Problema 74313 resolvido: para o site de um cliente que utiliza um modelo LTE de um VMware SD-WAN Edge (por outras palavras, o Edge 510-LTE ou o Edge 610-LTE), o Edge perderá a comunicação com o VMware SD-WAN Orchestrator após o reinício do Edge se tiver apenas uma ligação WAN LTE.

    A conectividade entre o Orchestrator e o Edge será perdida, uma vez que a acessibilidade do caminho predefinido através da interface LTE torna-se falsa após o reinício do Edge.  Como resultado, o Edge será marcado como inativo pelo Orchestrator, embora o tráfego do cliente ainda esteja a passar na ligação WAN LTE.

    Sem a correção, a única forma de recuperar a acessibilidade do Edge é efetuar um reinício do serviço Edge.

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

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

Problemas resolvidos do Gateway

Versão R450-20211123-GA-74198-70416-74482-30022 do Gateway

A versão R450-20211123-GA-74198-70416-74482-30022 do Gateway foi lançada a 29/11/2021. Esta compilação do Gateway não adiciona novos problemas resolvidos desde a versão R450-20211104-GA-74198-70416-74482 do Gateway, mas contém alterações de resolução de problemas exigidas pela VMware Engineering.

    ___________________________________________________________________

    Resolvido na versão R450-20211104-GA-74198-70416-74482 do Gateway

    A versão R450-20211104-GA-74198-70416-74482 do Gateway foi lançada a 08/11/2021 e resolve o problema crítico abaixo desde a versão R450-20211029-GA-74198-70416 do Gateway.

    • Problema 74482 resolvido: para um cliente que utiliza uma topologia de rede Hub-Spoke, o caminho de um VMware SD-WAN Spoke Edge não é aprendido num Hub Edge se esse Hub Edge também for um Spoke para um Hub Edge diferente.

      Para que este problema ocorresse, o cliente também teria o Edge a Edge via Hub configurado. Quando as implementações do cliente têm um Edge implementado como um Hub para determinados Spokes e um Spoke para determinados Hubs, esse Edge não recebe os caminhos do Spoke do VMware SD-WAN Gateway. Este problema tem um grande impacto numa rede com esta topologia devido aos caminhos em falta.

      Sem esta correção, a única forma de evitar este problema é desativar o Edge a Edge via Hub nos Spoke Edges.

    __________________________________________

    Resolvido na versão R450-20211029-GA-74198-70416 do Gateway

    A versão R450-20211029-GA-74198-70416 do Gateway foi lançada a 30/10/2021 e resolve o problema crítico abaixo desde a versão R450-20211022-GA-74198 do Gateway.

    • Problema 70416 resolvido: os clientes ligados a um determinado VMware SD-WAN Gateway podem subitamente observar altos níveis de perda de pacotes e latência para todos os utilizadores. Um utilizador operador observa que o Gateway que causa estes problemas mostra um pico na carga da CPU seguido de um pico nas Handoff Queue Drops.

      Quando este problema é observado num Gateway, a equipa de engenharia observou um problema com os threads de caminho rápido identificados (IKE, dados VCMP e similares) que gastam entre 15 a 20% dos seus ciclos a realizar operações inet_ntop que provocaram o pico na carga da CPU e nas Handoff Queue Drops. Para evitar que este problema se repita, as chamadas de API que causam este problema foram substituídas por uma formatação de dados melhorada para os comandos de registo.

    __________________________________________

    Resolvido na versão R450-20211022-GA-74198 do Gateway

    A versão R450-20211022-GA-74198 do Gateway foi lançada a 23/10/2021 e resolve o problema crítico abaixo desde a versão R450-20210922-GA do Gateway.

    • Problema 74198 resolvido: se um cliente tiver implementado um Destino Não-SD-WAN (NSD) via Gateway com vários túneis para o mesmo endereço IP de destino num único segmento, os túneis aparecerão todos como “ativos” no VMware SD-WAN Orchestrator, mas apenas um dos túneis passará tráfego.

      Existe uma verificação de singularidade inadequada aplicada aos caminhos anunciados para Destinos Não-SD-WAN (NSD) VMware através do Gateway. Um exemplo comum de um estado de erro é um cliente que tem, por exemplo, dois túneis desde o mesmo VMware SD-WAN Gateway até ao mesmo endereço IP do Zscaler para efeitos de equilíbrio de carga. Com este problema, ambos os túneis parecerão estáveis no Orchestrator, mas apenas um passará tráfego e o outro simplesmente colocará todo o tráfego numa condição de buraco negro (ou seja, descarta todo o tráfego sem informar a origem de que o tráfego não chegou ao destinatário pretendido). Isto só afeta os NSDs que utilizem um Gateway com a versão 4.4.0 ou 4.5.0.

      Se utilizar Gateways com uma compilação anterior, a solução alternativa para este problema é utilizar IPs de destino diferentes (por exemplo, endereços IP do Zscaler diferentes) para facilitar o equilíbrio de carga.

    Problema resolvido do Edge

    Resolvido na versão R450-20211007-GA-72423 do Edge

    A versão R450-20211007-GA-72423 do Edge foi publicada em 10-08-2021 e responde aos problemas críticos abaixo a partir da versão Edge R450-20210922-GA do Edge.

    • Problema 72423 resolvido: o VMware SD-WAN Edge fica offline no VMware SD-WAN Orchestrator e não está acessível se o servidor DNS público do Edge não for o DNS da Google.

      Neste caso, o servidor DNS configurado para um Edge no Orchestrator não é o DNS da Google, mas os pacotes DNS para domínios específicos (como *.nyansa.com e *.velocloud.net) continuarão a ser enviados para o servidor DNS da Google (8.8.8.8/8.8.4.4). (Este é um comportamento esperado.) 

      Quando um pacote DNS é recebido do kernel, só é reencaminhado se o IP de destino for o mesmo que o configurado no Orchestrator. Se o IP de destino não corresponder ao configurado no Orchestrator, o Edge ignora esse pacote. No entanto, o Edge não liberta esse pacote, o que provoca uma fuga da memória intermédia. É a fuga da memória intermédia que, em última análise, faz com que o Edge não responda.

      Sem a correção, como uma solução alternativa, os clientes poderiam garantir que o DNS da Google está configurado como o servidor DNS público para todos os seus Edges.  No caso de um Edge num estado inacessível, o cliente necessita de reiniciar o Edge para o recuperar.

      Nota: embora a correção nesta compilação resolva o problema principal, existe um cenário extremamente raro em que, se um cliente enviar tráfego destinado a um servidor DNS completamente diferente do que o cliente configurou (independentemente do serviço DNS configurado e de ser um serviço que não o DNS da Google), o problema pode ocorrer mesmo com a correção encontrada nesta compilação. A compilação R450-20220203-GA também resolve este caso e deve ser considerada como a correção completa do problema 72423.

    Problemas resolvidos do Edge/Gateway

    Resolvido na versão R450-20210922-GA do Edge/Gateway

    Os problemas abaixo foram resolvidos desde as versões R430-20210702-GA-61583 e R440-20210702-GA-61583 do Edge e a versão R430-20210727-GA-65293-67191 do Gateway.

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

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

    • Problema 43005 resolvido: um VMware SD-WAN Edge pode não transmitir pacotes Tx e/ou receber pacotes Rx, mas o estado da interface continua a mostrar a ligação como ativa e ligada, embora o tráfego não esteja a passar.

      No chip NIC do Edge, o módulo de hardware Tx/Rx pode ficar num estado suspenso, o que faz com que os pacotes Tx/Rx deixem de enviar/receber e que o tráfego do cliente deixe de passar. Um Edge neste estado teria, por exemplo, o dispcnt a mostrar o contador sfp2_l2_dropped a aumentar e o contador Tx inalterado:

      dpdk_sfp2_l2_dropped = 199042 71/s
      dpdk_sfp2_l2_tx = 36801627105 71/s

      A solução para este problema é a implementação da deteção e recuperação de suspensão Tx entre todos os modelos Edge. Esta funcionalidade monitoriza as paragens de hardware e tenta uma recuperação. A VMware introduziu inicialmente a deteção e recuperação de suspensão Tx para a NIC Intel 82599, que é utilizada em algumas implementações de Edge virtual.

      Numa interface que utiliza a monitorização de paragens Tx, deverá observar-se a linha de registo que se segue na inicialização:

      2021-05-24T23:45:14.287 MSG [NET] dpdk_parse_interface:773 DPDK intf sfp2, driver ixgbe,
       mac ac:1f:6b:2d:d2:0a, pci 0000:02:00.0, tx_stall_monitor 1

      Quando é detetada uma paragem Tx e a interface é recuperada, um utilizador deverá observar uma linha de registo semelhante à que se encontra abaixo:

      2021-05-20T20:09:05.644 ERR [NET] dpdk_tx_stall_check_and_recovery:1545 TX stall count : 1, on dpdk intf:sfp2 ,port: 0
      2021-05-20T20:09:06.644 ERR [NET] dpdk_tx_stall_check_and_recovery:1545 TX stall count : 2, on dpdk intf:sfp2 ,port: 0
      ...
      2021-05-20T20:09:23.647 ERR [NET] dpdk_tx_stall_check_and_recovery:1545 TX stall count : 19, on dpdk intf:sfp2 ,port: 0
      2021-05-20T20:09:24.647 ERR [NET] dpdk_tx_stall_check_and_recovery:1545 TX stall count : 20, on dpdk intf:sfp2 ,port: 0
      2021-05-20T20:09:24.647 ERR [NET] dpdk_tx_stall_recover:1499 Starting TX stall recovery on dpdk intf:sfp2 ,port: 0
      2021-05-20T20:09:37.027 ERR [NET] dpdk_tx_stall_recover:1528 Completed TX stall recovery on dpdk intf:sfp2 ,port: 0
    • Problema 43278 resolvido: se um utilizador configurar um filtro BGP de saída para corresponder ao prefixo ou caminho predefinido e, em seguida, definir um Caminho AS precedente, o prefixo ou caminho predefinido será anunciado para o BGP vizinho, mas não existirá nenhum Caminho AS precedente.

      Um filtro vizinho BGP de saída definido para corresponder a um prefixo e um Caminho AS precedente definido não funciona em nenhum prefixo originado através da declaração de “Redes” de configuração Avançada BGP. Também não funciona para um caminho predefinido com origem num vizinho através do vizinho “Origem DR” (DR Originate), através da caixa de verificação Anunciar caminho predefinido “condicional” avançado BGP (BGP Advanced “Conditional” Default Route Advertise).

      Além disso, quando utiliza uma configuração de caminho estático no VMware SD-WAN Edge, nenhum caminho predefinido nem caminho estático não DR definido para “Anunciar” (Advertise) será anunciado para um vizinho BGP com o Caminho AS precedente; o único AS no prefixo é o próprio AS do Edge.

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

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

      Sem esta correção, a única forma de evitar que este problema ocorra é utilizar uma solução alternativa onde o cliente configura apenas um dos dois sites do Hub de HA para utilizar o outro site do Hub como um Hub para si mesmo. Por exemplo, se existirem dois sites do Hub de HA, o Hub1 e o Hub2, o Hub1 pode ter o Hub2 como Hub para si no seu perfil, mas o Hub2 não deve utilizar o Hub1 como Hub no seu perfil.

    • Problema 46489 resolvido: Se diferentes perfis com Gateways de parceiro ativados forem atribuídos a vários VMware SD-WAN Edges, os Edges vão reter entradas de routing obsoletas para os Gateways de parceiro do VMware SD-WAN não atribuídas nos seus perfis.

      Se diferentes perfis com Gateways de parceiro ativados forem atribuídos a vários Edges, o Edge reterá as entradas de routing aprendidas de outros Gateways e estes caminhos serão considerados entradas obsoletas.  O impacto para o cliente consiste em tráfego que não é encaminhado corretamente porque o Edge está a tentar enviar tráfego para caminhos inválidos para esse perfil.

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

      O erro refere-se a uma ordem de caminhos não determinística quando o mesmo prefixo é recebido como caminho PG não seguro, caminho de underlay e caminho de overlay. Não existe uma comparação de preferência direta entre o overlay/underlay dinâmico e os caminhos estáticos PG. Isto resulta no armazenamento do mesmo caminho numa ordem diferente no FIB, dependendo da ordem na qual a adição do caminho é recebida no Edge.
      Aceda a /etc/config/edged e /etc/config/gatewayd, ative legacy_sort_pg_static_pref para 1 e, em seguida, o caminho estático PG não seguro será sempre preferido face ao caminho de underlay/overlay dinâmico. Desta forma, torna a ordem de caminhos FIB determinística.

    • Problema 48105 resolvido: um VMware SD-WAN Gateway pode ficar num estado suspenso e não concluir um reinício ao encontrar certos pânicos do núcleo.

      O impacto é significativo, dado que um utilizador terá de intervir para reiniciar o Gateway caso este fique suspenso.  Por predefinição, um pânico do núcleo deve provocar um reinício imediato, mas alguns pânicos do núcleo não acionavam o reinício por predefinição.

    • Problema 48209 resolvido: um VMware SD-WAN com uma versão 3.x não consegue estabelecer um túnel com um VMware SD-WAN Gateway ou Edge Hub que está a utilizar uma versão 4.x no modo de certificado quando a cadeia de certificados da Autoridade de Certificado (AC) é maior do que dois.

      O utilizador deve observar túneis falhados a partir do Edge com um erro ERR_CERT_INVALID_PARENT_CERTIFICATE. O problema está relacionado com o processamento da cadeia de certificados. A biblioteca Mocana assume que, quando uma cadeia de certificados é recebida, os certificados de cada emissor devem seguir-se uns aos outros, mas, em alguns casos, o VMware SD-WAN Orchestrator emite uma cadeia de certificados da AC que não corresponde a esta regra.

      Sem a correção, a solução alternativa é limitar a cadeia de certificados da AC a dois certificados, que vão sempre corresponder à regra.

    • Problema 48958 resolvido: um VMware SD-WAN Gateway pode perder conetividade numa interface ligada.

      Quando o Protocolo de Gestão VeloCloud (VCMP) e a porta WAN estiverem definidos para utilizar a mesma porta, a configuração de handoff da VLAN do Gateway de parceiro pode fazer com que o Gateway fique offline devido à falha das resoluções ARP. Com esta correção, quando o VCMP e a porta WAN forem idênticos, a configuração de handoff da VLAN do VMware SD-WAN Orchestrator será rejeitada no Gateway.  Sem esta correção, a solução alternativa é não atribuir a mesma porta ao VCMP e à WAN.

    • Problema 48593 resolvido: os pacotes de um Destino Não-SD-WAN (NSD) VMware ou de um Serviço de Segurança na Cloud (CSS) podem ser enviados sem encriptação.

      Durante a seleção da ligação, caso o socket seguro não esteja disponível, os pacotes são enviados através de qualquer ligação disponível. A correção garante que, se não estiver disponível um socket seguro, os pacotes NSD e CSS devem ser eliminados.

    • Problema 50422 resolvido: o endereço MAC do par pode ser aprendido incorretamente via ARP ao utilizar interfaces encaminhadas e etiquetadas como VLAN.

      Se tiver uma etiqueta VLAN atribuída a uma interface encaminhada e o hop seguinte enviar pedidos ARP não etiquetados, isto vai provocar a aprendizagem do MAC não etiquetado e pode fazer com que o tráfego seja colocado numa condição de buraco negro dependendo da entrada que é aprendida primeiro.

      Sem esta correção, a única alternativa será filtrar os pedidos ARP não etiquetados do próximo hop se tiver uma etiqueta VLAN na interface encaminhada.

    • Problema 51428 resolvido: podem ser observadas perdas de tráfego multicast num local onde o VMware SD-WAN Edge tem uma subinterface configurada com PIM.

      Quando uma subinterface configurada com PIM é rapidamente movida de um segmento para outro, o pimd (o processo que gere o PIM) pode reiniciar e o local pode sofrer uma perda de tráfego multicast intermitente.

      Sem a correção, a solução alternativa para este problema é desativar primeiro a subinterface e, em seguida, mover a subinterface para outro segmento. Uma vez movida, reative-a.

    • Problema 52031 resolvido: a mensagem de pedido de informações DHCPv6 não é enviada no modo DHCPv6 sem estado quando a mensagem de anúncio do router é recebida com outra sinalização de configuração definida.

      Se a interface num VMware SD-WAN Edge estiver configurada com o modo DHCPv6 sem estado, quando estiver a receber uma mensagem de anúncio do router com outra sinalização de configuração definida nessa interface, é esperado que envie uma mensagem de pedido de informações DHCPv6 para obter informações adicionais, por exemplo, o servidor DNS. No entanto, a mensagem de pedido de informações DHCPv6 não é enviada para o servidor DHCP.

    • Problema 52419 resolvido: o tempo válido do endereço IPv6 é atualizado quando um anúncio de router (RA) é recebido com um temporizador que não é zero.

      Este comportamento não está em conformidade com o RFC 4862 para a atualização de um temporizador de tempo de vida válido. De acordo com o RFC:

      1. Se o tempo de vida válido recebido for superior a 2 horas ou superior a RemainingLifetime, defina o tempo de vida válido do endereço correspondente como o tempo de vida válido anunciado.
      2. Se RemainingLifetime for inferior ou igual a 2 horas, ignore a opção de informações de prefixo no que diz respeito ao tempo de vida válido, exceto se o anúncio de router a partir do qual esta opção foi obtida tiver sido autenticado (por exemplo, através do Secure Neighbor Discovery [RFC3971]).  Se o anúncio de router tiver sido autenticado, o tempo de vida válido do endereço correspondente deve ser definido para o tempo de vida válido na opção recebida.
      3. Caso contrário, reponha o tempo de vida válido do endereço correspondente para 2 horas.

      O problema resultava de o processamento de RA ser realizado pelo núcleo do VMware SD-WAN Edge e esta tarefa foi agora transferida para o processo Dataplane do Edge, garantindo conformidade total.

    • Problema 54022 resolvido: os registos de erro relacionados com a firewall entram continuamente nos registos de um VMware SD-WAN Edge quando um modem USB está ligado.

      Ao ligar o modem USB a um Edge, os registos de erro relacionados com a firewall entram continuamente nos registos do Edge, o que prejudica a capacidade do utilizador de ver incidentes da firewall genuínos.

    • Problema 54157 resolvido: o utilizador pode observar redução de tráfego num VMware SD-WAN Gateway para o tráfego a partir de um servidor de centro de dados para um cliente legado anunciado através do BGP sobre IPsec a partir do Gateway.

      Na versão 4.4.x e anteriores, não é possível distribuir caminhos legados associados ao Edge do fornecedor (PE) para um Destino Não-SD-WAN (NDS) através dos caminhos NSD e Gateway para o PE. A versão 4.5.0 proporciona suporte ao pipeline de dados entre destinos associados ao PE e um NSD via Gateway. Isto também inclui a função de redistribuição de caminhos entre PG-BGP e NSD-BGP.

    • Problema 54378 resolvido: a verificação de deteção de endereços duplicados (DAD) da interface ativada de endereço estático IPv6 falha devido a um NA (Anúncio de vizinho) ignorado.

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

    • Problema 54536 resolvido: a deteção de endereços duplicados (DAD) não ocorre após um reinício do VMware SD-WAN Edge.

      A verificação DAD não é acionada após o reinício do Edge. Se existir um endereço duplicado na rede, este não será detetado.

    • Problema 54687 resolvido: a mensagem de solicitação DHCPv6 não é enviada por um VMware SD-WAN Edge após o servidor proporcionar uma configuração com um valor T1 superior a T2.

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

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

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

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

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

    • Problema 56218 resolvido: para um local de cliente implementado com uma topologia de Alta Disponibilidade ou onde a HA acaba de ser ativada, quando os Edges são atualizados de 3.2.x para 3.4.x, o Edge em espera pode ficar inativo.

      Quando a HA (alta disponibilidade) está ativada ou os Edges HA são atualizados de 3.2.2 para 3.4.x após a configuração de uma definição WAN com a IU local, a interface HA (por exemplo, LAN1 ou GE1 dependendo do modelo Edge) será removida do Edge em espera e o estado HA vai ser definido para HA_FAILED no VMware SD-WAN Orchestrator.

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

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

    • Problema 58259 resolvido: Em alguns casos, um cliente pode observar um túnel VMware de Destino Não-SD-WAN inativo no lado do Gateway com um par Zscaler.

      Existem alguns casos em que a extremidade do par Zscaler elimina a associação de segurança (SA) de Fase 2, mas o VMware SD-WAN Gateway ainda retém a SA. Nestes casos, o túnel é eliminado e o cliente não consegue passar tráfego.

      Sem a correção, a solução alternativa é utilizar um script phase2_sa_check.py que passa sobre a tabela SA de fase 2 e verifica se existe uma SA de fase 2 para a qual a SA de fase 1 está em falta. Se encontrar uma, o Gateway restabelece o túnel.

    • Problema 58453 resolvido: alguns pacotes do Office365 são classificados incorretamente como pacotes SSL pelo VMware SD-WAN Edge.

      O motor de Inspeção Profunda de Pacote (DPI) do VMware SD-WAN está por vezes a classificar erradamente os pacotes que devem ser classificados como Office365 em vez de SSL.  O impacto é que estes fluxos vão ser tratados como fluxos SSL em vez de fluxos Office365 e isso pode significar que são tratados com uma prioridade menor, impactando a experiência do utilizador.

    • 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 split-brain (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: Uma versão anterior da descrição deste pedido indicou que esta era também uma correção para sites HA com operações BGP de correspondência e definição. Esta parte do problema não é corrigida neste pedido, é registada com o problema 84825.

    • Problema 59236 resolvido: para locais que utilizam uma topologia de Alta Disponibilidade (HA) melhorada, os túneis não são formados se a ligação WAN associada ao Edge em standby for um Metanoia SFP e este comportamento persiste mesmo após uma recuperação automática HA.

      Para HA melhorada, as portas WAN estão bloqueadas no Edge em standby (por outras palavras, o Edge não permite TX nas suas interfaces WAN). Para apresentar uma interface Metanoia SFP, tem de ocorrer uma troca de pacotes entre o hardware. Dado que o Edge não permite TX, a inicialização da interface não é bem-sucedida.

    • Problema 59629 resolvido: num local de cliente implementado com uma topologia de Alta Disponibilidade, o utilizador pode observar que o Edge em standby do VMware SD-WAN reinicia várias vezes.

      Tanto o Edge ativo como o Edge em standby perdem o heartbeat HA e ambos os Edges se tornam Ativo/Ativo (também conhecido como “Split-Brain”). Para desfazer o impasse, o recém-promovido Edge ativo (o anterior Edge em standby) será submetido a um reinício com um evento de registo: “Pânico Ativo/Ativo” (Active/Active Panic).  A correção para este problema envolve a promoção da prioridade do thread de heartbeat Edge HA de modo a minimizar o atraso no processamento dos heartbeats que podem ser observados como heartbeats em falta e que provocam o estado Ativo/Ativo.

    • Problema 60010 resolvido: para um local que utiliza VMware SD-WAN Edges com VNF implementado numa topologia de Alta Disponibilidade, o VNF no Edge em standby não é acessível através de SSH após um flap da porta do lado da LAN.

      A interface do lado da LAN no VNF em standby encontra-se, normalmente, num estado desativado. Devido ao flap da porta do lado da LAN, este move-se para um estado de encaminhamento, o que resulta num mapeamento da porta do endereço MAC errado na interface de ponte, o que resulta na inacessibilidade do VNF.

    • Problema 60073 resolvido: os pacotes DNS através de uma interface PPPoE do VMware SD-WAN Edge não são processados.

      Os pacotes DNS passados através da interface PPPoE do Edge não são processados e são eliminados. Devido a isto, a funcionalidade de DNS através de PPPoE é afetada e o cliente observa, por exemplo, problemas como os túneis CSS não surgirem após uma atualização para a versão 4.2.0 ou posterior.

    • Problema 60097 resolvido: um modelo 510 do VMware SD-WAN Edge tem um desempenho de produção máxima mais baixo devido a não ter suporte DPDK.

      O desempenho inferior do Edge 510 resulta de interfaces vinculadas ao núcleo e sockets em bruto abertos para entrada/saída de pacotes do Edge. Isto é resolvido ao incluir o Edge 510 no conjunto de plataformas suportadas do DPDK.  Alterações de débito testadas e observadas da seguinte forma:

      Antes do suporte DPDK: IMIX 400 = 130 Mbps; pacotes de 1300 bytes = 360 Mbps.  
      Depois do suporte DPDK: IMIX 400 = 250 Mbps; pacotes de 1300 bytes = 600 Mbps.

    • Problema 60184 resolvido: um VMware SD-WAN Edge de ramo instala caminhos marcados como comunidade de transmissão a partir de um Edge Hub sem perfil (ramo a ramo dinâmico) e dá preferência a estes caminhos em comparação com qualquer outro.

      O Edge Hub sem perfil é tratado como um Edge de ramo quando o ramo a ramo dinâmico é utilizado.  Desta forma, quando existe uma criação dinâmica de um túnel, o problema ocorre conforme descrito. A única solução alternativa é adicionar Hubs a todos os perfis, mas não é possível dimensionar isto em redes de maior dimensão onde existem mais de 20 Edges Hub devido ao enorme número de caminhos que seriam criados.

    • Problema 60367 resolvido: as regras de firewall com estado não eliminam o primeiro pacote num fluxo que vai para o IP do VMware SD-WAN Edge mesmo com uma regra de eliminação específica da VLAN em vigor.

      O envio de um ping para um IP VLAN do Edge é bem-sucedido mesmo com regras de eliminação da firewall com estado específicas da VLAN. Com regras de eliminação da firewall com estado específicas da VLAN, o comportamento não é consistente entre o ping para um anfitrião VLAN e o IP VLAN do Edge. O ping para um IP VLAN do Edge é bem-sucedido. A correção não permite o ping para o anfitrião VLAN ou o IP VLAN do Edge.

    • Problema 60570 resolvido: o estado do caminho pode apresentar o estado incorreto ao utilizar a nova IU no VMware SD-WAN Orchestrator. 

      Este é apenas um problema de visualização e não afeta o tráfego real do cliente. Um exemplo deste problema é a nova IU mostrar um caminho como morto quando um registo do pacote de diagnóstico do Edge apresenta o caminho como estável.

    • Problema 61344 resolvido: quando um VMware SD-WAN Edge tem tráfego > 180 Mbps a fluir através do mesmo, ocorre lentidão no novo tráfego seguinte iniciado através do Edge.

      Quando tráfego > 180 Mbps está a fluir através de um Edge, o novo tráfego é colocado em memória intermédia no VMware SD-WAN Gateway e não é processado pelo Gateway no tempo esperado. Desta forma, o tráfego sofre latência.

    • Problema 61361 resolvido: ao aplicar uma atualização de software para atualizar um VMware SD-WAN Edge 3400, 3800 e 3810 para a versão 3.4.5, 4.0.2 ou 4.2.1 do Edge, existe a possibilidade de os modelos Edge não arrancarem imediatamente após a atualização.

      As versões 3.4.5, 4.0.2 e 4.2.1 incluem uma atualização de firmware específica para o dispositivo lógico programável complexo (CPLD) e a atualização aciona um reinício que, por vezes, pode ficar “preso”, exigindo um ciclo de energia manual para reiniciar o sistema.

      Sem a correção, um utilizador local deve passar manualmente um ciclo de energia ao Edge para concluir a atualização.

    • Problema 61502 resolvido: durante a ativação de um VMware SD-WAN Edge, a transferência da nova imagem de software a ser aplicada é adiada indefinidamente.

      Num ambiente com conetividade de rede pouco fiável ou certos tipos de estrangulamento de tráfego, a transferência HTTPS da nova imagem de software pode ficar presa. Sem esta correção, caso este cenário ocorra, passe um ciclo de energia ao Edge e aguarde alguns minutos. A transferência deve reiniciar automaticamente, no entanto, começa do zero.

    • Problema 61583 resolvido: se um cliente ativar a Alta Disponibilidade para um local, o VMware SD-WAN Edge ficará offline, o local ficará inativo e todo o tráfego do cliente será interrompido.

      Quando a AD é ativada, o Edge ficará, no mínimo, offline durante cerca de 5 minutos, com o tráfego do cliente interrompido durante esse período. O Edge poderá conseguir voltar à configuração anterior e retomar o funcionamento após esse período de cerca de 5 minutos, embora esse Edge continuar a funcionar como independente com a AD não seja possível.  No entanto, se o Edge não voltar com êxito à última configuração, permanecerá inativo até que um utilizador local efetue uma reposição de fábrica seguida de uma reativação de RMA (com a AD não ativada) para restaurar a conetividade naquele local.

      Para obter mais informações, consulte o artigo BDC Ativar a Alta Disponibilidade num VMware SD-WAN Edge com a versão 4.3.0 GA ou 4.4.0 GA pode fazer com que o Edge fique offline. (84396)

    • Problema 61596 resolvido: existe uma degradação do desempenho quando o BGP de parceiro é ativado com a opção segura e um caminho estático é configurado como não seguro ou vice-versa.

      A degradação do desempenho é provocada por um erro de cálculo do comprimento máximo do endereço IP quando um caminho estático não seguro recolhe o sinalizador seguro a partir de uma configuração BGP. Inicialmente, o VMware SD-WAN Gateway faz uma pesquisa de caminho e, se encontrar um caminho estático inseguro, o Gateway verificará se o BGP está ativado ou não.  Se o BGP estiver ativado, o Gateway verificará a encriptação definida e, em seguida, recolherá a encriptação definida para o BGP, que é seguro, e a fragmentação ocorrerá porque a opção segura é mais conservadora do que insegura.

    • Problema 61622 resolvido: O tráfego do Google Drive é incorretamente identificado como “Outro TCP/UDP” (Other TCP/UDP) ou como “APP_UNKNOWN”.

      Este tráfego deve ser identificado como “Documentos Google (também conhecido como Google Drive)” (Google Documents [aka Google Drive]). O problema é provocado pelo motor de Inspeção profunda de pacotes (DPI) não ter as sub-redes/portas mais atualizadas para o Google Drive.

    • Problema 61625 resolvido: um VMware SD-WAN Hub Edge não anuncia todos os caminhos se existirem mais de ~250 caminhos a ser anunciados no OSPF.

      Independentemente do número de caminhos, sejam eles 300, 2000 ou mais, apenas ~250 caminhos irão aparecer conforme anunciado e os restantes terão o seu sinalizador de anúncio definido para FALSO. Isto deve-se a um atraso no processamento de caminhos superiores a ~250 e é resolvido através do processamento de um lote muito menor de caminhos por pedido.

    • Problema 61725 resolvido: para um local que utiliza uma topologia de Alta Disponibilidade onde são utilizadas ligações USB WAN, a execução do diagnóstico remoto “Informações de HA” (HA Info) irá resultar em erros.

      Quando um modem USB/LTE está presente ou esteve anteriormente presente apenas no Edge ativo do VMware SD-WAN e não no Edge standby, o Edge ativo tenta obter detalhes da interface USB/LTE no Edge standby e o resultado é que o Edge lança um erro, dado que a interface USB/LTE não está presente no Edge em standby.

    • Problema 61759 resolvido: o nome ISP e a largura de banda são apresentados como vazios na IU local do VMware SD-WAN Edge (página Visão geral [Overview] e página Propriedades de interface encaminhada [Routed Interface Properties]).

      Se uma interface encaminhada tiver mais do que uma sobreposição, espera-se que a IU local apresente os detalhes da interface que tem o valor “última ativação” (last active) mais recente (dado que foi concebida para apresentar os detalhes de apenas um). Quando o utilizador abre a página Visão geral/Detalhes (Overview/Details) da IU local, os valores de largura de banda e ISP para interfaces encaminhadas com várias sobreposições são apresentados como vazios.

    • Problema 61797 resolvido: o retrocesso de caminho não é suportado no VMware SD-WAN Edge, o que resulta em caminhos de acessibilidade falsa.

      A partir desta versão, o retrocesso de caminho é suportado. O retrocesso de caminho significa que se a correspondência do prefixo mais longo (LPM) estiver inalcançável e existir outro caminho super-net disponível, a procura de caminhos deve optar por este caminho super-net para encaminhar o pacote. Quando a procura de caminho obtém um caminho inalcançável como LPM, o Edge não consegue obter o melhor caminho seguinte presente na tabela de routing e isso resultou em muitos clientes com um problema de caminhos de acessibilidade falsa.

    • Problema 62197 resolvido: um VMware SD-WAN Gateway pode reiniciar o seu Serviço dataplane.

      O Gateway encontra uma fuga de memória que ocorre enquanto sincroniza caminhos de si próprio para o VMware SD-WAN Orchestrator.  Quando o consumo de memória atinge níveis críticos, o Serviço dataplane do Gateway reinicia para limpar a memória, provocando uma breve perturbação no tráfego do cliente que utiliza o Gateway.

    • Problema 62280 resolvido: a subinterface LAN do VMware SD-WAN Edge não é apresentada num traceroute a partir de um anfitrião encaminhado para um cliente ligado através de Edge a Edge.

      Quando o traceroute é realizado a partir de um anfitrião (não diretamente ligado ao Edge) para um cliente numa topologia Edge a Edge, o IP da interface do Edge não é apresentado em o/p. Isto só acontece quando uma configuração do VMware SD-WAN Gateway não é realizada na interface Edge no caminho para o anfitrião.

      Sem a correção, a única solução alternativa é ativar a configuração do Gateway na interface do Edge que liga a esse anfitrião traceroute.

    • Problema 62373 resolvido: ao chamar um local de Alta Disponibilidade configurado para um endereço MAC único, o vMAC é programado a partir de uma interface encaminhada para uma interface comutada.

      O endereço MAC exclusivo não vai ser programado para o Edge HA quando o tipo de interface é alterado de uma interface WAN para uma interface comutada e isto leva à perda de tráfego. 

      Sem a correção, a solução alternativa para resolver este problema é reiniciar os Edges HA, o que irá programar o MAC correto na interface agora comutada.
       

    • Problema 62552 resolvido: um local pode experimentar períodos intermitentes de perdas elevadas de pacotes e problemas de conetividade.

      Este erro é causado pela API que verifica a resolução ARP, indicando ao Edge que existe uma resolução ARP bem-sucedida para um dispositivo enquanto entrega um endereço MAC de 00:00:00:00.  Este endereço é mantido na cache ARP e quaisquer pacotes destinados ao dispositivo com o MAC listado como zero são ignorados.  Neste problema, muitas destas instâncias de ARPs bem-sucedidos com endereços MAC zero são entregues, o que provoca problemas de conetividade e perda elevada de pacotes.

      Nota: existe um problema anterior (60130) com o mesmo comportamento e causa subjacentes, mas que inclui uma resolução diferente do 62552.  Com o 60130, a resolução foi uma solução alternativa defensiva, enquanto o 62552 inclui uma correção completa que impede qualquer recorrência deste problema.

    • Problema 62620 resolvido: num local implementado com uma topologia de Alta Disponibilidade, o tráfego direto para alguns dos destinos pode parar de funcionar após a recuperação automática de HA.

      Os fluxos do VMware SD-WAN Edge ativo são sincronizados para o Edge em espera, juntamente com a porta alocada para a entrada NAT para que, quando ocorra uma recuperação automática, não exista nenhuma perturbação no tráfego após a recuperação automática. A porta alocada no Edge em espera nunca é libertada mesmo depois de o fluxo expirar. Assim, quando existe uma recuperação automática, existe a possibilidade de exaustão de porta NAT e de falha de NAT. Como resultado, podem ser ignorados pacotes no Edge.

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

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

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

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

      Sem a correção, a única forma de remediar o problema é reiniciar o Edge para eliminar as entradas NHT com fuga de memória. 

    • Problema 62736 resolvido: num VMware SD-WAN Edge baseado em hardware, quando o utilizador está a aceder à interface de utilizador local, na página Propriedades de interface encaminhada (Routed Interface Properties) da IU local, para interfaces PPPoE, o campo Endereço MAC (MAC address) é apresentado como vazio e o campo Endereço IP (IP address) apresentado está errado.

      A partir da versão 4.3.x, os detalhes de interface na IU local são obtidos a partir de eventos NETLINK em vez de consultar constantemente quanto a atualizações. Dado que as próprias interfaces PPPoE não têm endereços MAC (as interfaces de base têm), o endereço MAC é apresentado como vazio. Adicionalmente, estava a ser utilizado um parâmetro errado do NETLINK para comunicar o endereço IP (IFA_ADDRESS em vez de IFA_LOCAL). As interfaces DHCP/estáticas não têm este problema, dado que o valor de ambos os campos é idêntico.

    • Problema 62890 resolvido: os IDs da aplicação são diferentes ao visualizar as estatísticas no Edge Network Intelligence e no VMware SD-WAN Orchestrator.

      Há duas formas diferentes de aprender as aplicações:
      1. No primeiro pacote, através de uma base de dados de portas e endereços IP de aplicações SaaS bem conhecidas (por exemplo, Office 365) ou através da aprendizagem do IP de uma aplicação que o Orchestrator tinha aprendido anteriormente.
      2. Após uma série de pacotes serem analisados com a inspeção de pacotes profunda (DPI).

      Os IDs de Aplicação do Edge Network Intelligence não estavam a ser atualizados por #2. Isto significa que as aplicações do primeiro pacote, como Office365, são visíveis, mas as aplicações que exigem DPI (por exemplo, AnyDesk) são vistas no Orchestrator, mas não no Edge Network Intelligence.

    • Problema 62897 resolvido: se um utilizador operador iniciar sessão num VMware SD-WAN Gateway e executar o comando tcpdump em eth0 ou eth1, os resultados não são fornecidos corretamente. 

      tcpdump é um comando de depuração de Gateway crítico para os operadores e a falta de saída correta prejudica significativamente os seus esforços. Existe uma forma de obter a saída correta sem a correção, que consiste em utilizar um comando que canaliza a saída de tcdump para cat, por exemplo: tcpdump -nnplei eth0 | cat

    • Problema 63056 resolvido: um VMware SD-WAN Edge pode encontrar um pânico do núcleo que resulta num reinício do núcleo.

      O processo mutex mon falha com SIGXCPU e um núcleo é acionado. A correção para este problema é permitir que todos os threads utilizem ambos os núcleos, juntamente com deslocar a comunicação do Serviço de dataplane do Edge < > frr para sockets de domínio Unix, o que proporciona todos os benefícios dos sockets TCP sem a sobrecarga do núcleo e com um melhor desempenho.

    • Problema 63141 resolvido: num local que utiliza uma topologia de Alta Disponibilidade melhorada onde os módulos Metonia ADSL2+ SFP estão a ser utilizados, no caso de uma recuperação automática, os módulos ADSL2+ SFP não surgem.

      Quando um Edge HA melhorado falha ou se a rede for reiniciada, um Edge com uma configuração ADSL2+ não surge. 

    • Problema 63359 resolvido: num local configurado com uma topologia de Alta Disponibilidade e OSPF e onde os VMware SD-WAN Edges estão a utilizar uma compilação IP MGMT do Edge, quando estes Edges são atualizados de uma compilação IP MGMT 3.4.x para 4.2.x, a conetividade OSPF pode ser interrompida após a atualização. 

      Quando os Edges HA são atualizados para uma compilação IP MGMT 4.2.x, os sistemas HA podem definir o ID de router como 169.254.2.2. Este não é o comportamento esperado, dado que a seleção do Edge do ID de router não deve ter em conta o endereço IP da interface HA. Este ID de router interrompe a conetividade OSPF e ocorre uma desconexão completa, dado que a troca de caminhos já não acontece.

      Sem a correção, a única solução alternativa é reiniciar o serviço Edge (acionando uma recuperação automática de HA), pois isto irá forçar uma nova seleção do ID de router, que deve ser o correto após o reinício.

    • Problema 63362 resolvido: num local que utiliza uma topologia de Alta Disponibilidade melhorada, uma interface ativada por DHCP/PPPoE para de enviar tráfego após o Edge em standby ser reiniciado ou passar o ciclo de energia.

      Numa topologia de HA melhorada, se o DHCP/PPPoE estiver ativado numa interface de proxy (isto é, o estado da ligação de HA está definido como USE_PEER), não obtém um endereço do servidor após o Edge em standby ser reiniciado ou passar o ciclo de energia.

      Sem a correção, a única solução alternativa é alterar o endereço dinâmico para um tipo de endereço estático ou realizar uma recuperação automática de HA forçada para obter um endereço IP do servidor.

    • Problema 63513 resolvido: para um cliente que utiliza o Edge Network Intelligence, a versão de software apresentada para o VMware SD-WAN Edge não é atualizada após uma atualização do software do Edge.

      O Edge foi efetivamente atualizado para a versão mais recente do Edge Network Intelligence, mas comunica o número de versão mais antigo ao VMware SD-WAN Orchestrator e é isso que o cliente observa. O cliente encontra o problema após atualizar um Edge. Depois de o Edge ser atualizado de uma versão mais antiga para a mais recente, o cliente continua a ver a versão mais antiga do Edge Network Intelligence.

    • Problema 63640 resolvido: para um cliente que utiliza a pilha dupla IPv4/IPv6 numa sobreposição WAN, a ligação WAN mostrará um valor MTU incorreto.

      No caso da pilha dupla da sobreposição WAN, se o MTU for alterado para uma ligação IPv4 e, em seguida, a preferência for alterada para IPv6, o mesmo MTU IPv4 será aplicado na ligação IPv6 e isto causará a discrepância do valor MTU.

    • Problema 64184 resolvido: quando um utilizador ativa a Alta Disponibilidade num local que utiliza dois Edges de hardware VMware SD-WAN, o utilizador pode observar que, quando o ponto de atualização do software do Edge em standby é atingido, a atualização do Edge não ocorre e o Edge em standby permanece num estado inativo.

      Este problema ocorre raramente nas condições acima referidas, mas, quando ocorre, a causa é o encerramento de um thread de trabalhador de HA no Edge ativo durante a ação de invocação da atualização da imagem do Edge em standby após a ativação da HA. O encerramento deste thread de trabalhador HA leva a que o Edge em standby fique num estado inativo.

    • Problema 64205 resolvido: o utilizador observa um elevado número de Handoff Queue Drops de dados VCMP para um VMware SD-WAN Gateway, o que causa uma má experiência do utilizador.

      Quando existem eventos contínuos de criação de fluxos, o processamento de pacotes no thread de dados do VCMP (Protocolo de gestão do VeloCloud) torna-se mais lento. Esta correção reduz a carga do thread de dados VCMP, redirecionando as mensagens de controlo VCMP para um thread diferente e eliminando algumas das mensagens de registo contínuas.

    • Problema 64713 resolvido: no site de um cliente que utiliza uma topologia de Alta Disponibilidade melhorada, se um utilizador reiniciar o serviço Edge ou efetuar uma alteração de configuração que resulte no reinício do serviço Edge, o cliente poderá observar que o reinício demora muito mais tempo do que o esperado antes da recuperação do Edge.

      Quando este problema ocorre, existe uma condição race entre o processo Edge e outros processos concorrentes que resulta no atraso do arranque.  Nos registos do pacote de diagnóstico, o utilizador veria uma linha com a frase “FATAL: não é possível obter informações hugepage” (FATAL: Cannot get hugepage information).

    • Problema 64736 resolvido: os endereços IP do DHCPv6 podem não ser removidos de uma interface VMware SD-WAN Edge depois de configurar a interface de encaminhada para comutada.

      Quando uma interface é convertida de encaminhada para comutada, os endereços IP IPv6 devem ser removidos da interface porque o IPv6 não é suportado na LAN. Contudo, em alguns casos, os endereços IP IPv6 não são removidos após a conversão para comutado. Estes endereços IP persistem mesmo se a interface for devolvida. O problema não ocorre sempre que uma interface é convertida.

      Sem a correção, a única solução é reiniciar o Edge para eliminar os endereços IP IPv6 da interface comutada recentemente convertida.

    • Problema 64961 resolvido: um VMware SD-WAN Edge pode encontrar uma falha do Serviço dataplane e reiniciar esse serviço se estiver a processar pacotes IP que incluem opções.

      O processamento de pacotes IP com opções poderá resultar numa falha do Serviço dataplane devido a uma análise incorreta dos campos de opções (a análise continua para além do fim da lista de opções). A falha do Serviço dataplane é acionada por mon mutex. Sem esta correção, a única forma de minimizar o risco deste problema é evitar definir opções que não o Caminho de registo (Record Route) (RR) e Sem opção (No Option) (NOP) nos pacotes IP de tráfego de utilizador.

    • Problema 65037 resolvido: o estabelecimento de uma ligação HTTPS/SSL pode falhar devido a um certificado corrompido caso o certificado tenha caracteres especiais ou espaços no campo de nome comum SSL (SSL common name).

      O VMware SD-WAN Edge inspeciona todo o tráfego do utilizador que passa por ele, para que possa identificar a aplicação à qual o tráfego pertence. É necessário para a aplicação correta das políticas empresariais e também para que o VMware SD-WAN Orchestrator apresente as estatísticas por aplicação na página Monitorização (Monitoring) do Edge. No entanto, um problema no código de identificação da aplicação faz com que um byte no nome comum SSL seja substituído caso o nome comum SSL contenha caracteres especiais ou espaços, sendo, desta forma, corrompido.

    • Problema 65219 resolvido: um VMware SD-WAN Gateway do tipo KVM SR-IOV com um controlador i40evf eliminar pacotes de clientes com 1500 bytes ou mais. 

      Os dados com um tamanho inferior a 1496 B não serão ignorados. Se um utilizador tentar um protocolo SSH no anfitrião do Gateway, irá observar uma suspensão com base na condição descrita.

    • Problema 65293 resolvido: o desempenho do débito de um VMware SD-WAN Gateway implementado no AWS e que está a ser executado com o controlador do Elastic Network Adapter (ENA) da Amazon fica degradado ao utilizar a versão 4.x.

      Este problema ocorrerá se o Gateway for atualizado para uma compilação 4.x (a partir de 3.x) ou numa nova implementação através de uma compilação 4.x. Os Gateways que utilizem a versão 4.0.0 ou posterior têm o DPDK v19.11 e, a partir do DPDK v19.02, o controlador do ENA da Amazon utiliza uma fila de baixa latência (LLQ). No entanto, para que a LLQ funcione de forma eficiente, a combinação de gravação para a definição de memória tem de estar ativada de acordo com o guia de referência do ENA.  Se o mapeamento de memória não tiver a combinação de gravação, o Gateway implementado no AWS apresentará uma elevada utilização da CPU, o que afeta significativamente o débito. A correção deste problema ativa a combinação de gravação no adaptador ENA para Gateways implementados no AWS.

    • Problema 65432 resolvido: um traceroute a partir de um cliente que está ligado do lado da LAN a um VMware SD-WAN Edge para um servidor DC através do VMware SD-WAN Gateway não apresenta o IP do Gateway na saída do traceroute.

      Ao iniciar um traceroute a partir do cliente LAN para o DC que é alcançável através do Gateway, o traceroute mostra todos os hops, exceto o IP do Gateway.

    • Problema 65466 resolvido: um VMware SD-WAN Gateway ou VMware SD-WAN Edge que processe uma grande troca de caminhos BGP pode experienciar uma falha no Serviço dataplane e reiniciar ao executar determinados comandos de depuração ou ao gerar um pacote de diagnóstico.

      Um Edge ou um Gateway que processe um grande número de caminhos (por exemplo, um Edge que anuncie 50 000 caminhos BGP ou um Gateway que aprenda mais de 100 000 caminhos BGP de Edges) pode deparar-se com este problema se o comando de depuração dispcnt (com parâmetros) também for executado.  O comando de depuração dispcnt é utilizado para monitorizar as quedas de capacidade e pode ser executado por um operador parceiro na CLI do respetivo dispositivo ou por um utilizador durante a criação de um pacote de diagnóstico. Quando este comando é executado num Edge ou Gateway com um grande número de caminhos e outro evento (por exemplo, eliminação de caminhos) ocorre de uma forma em que a variável original aponta para uma localização de memória que está agora obsoleta, o resultado será uma falha do Serviço dataplane devido ao acesso ilegal à memória.

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

      Um reinício do serviço Edge irá perturbar o tráfego do cliente durante ~5 a 10 segundos. O Serviço dataplane do Edge falha ao processar uma mensagem de controlo inesperada durante um handshake de criação de túnel de protocolo de gestão VeloCloud (VCMP). Este problema não depende da topologia de rede, do número de fluxos ou do débito. É uma situação rara e aleatória, mas tem o potencial de ocorrer em qualquer tipo de cliente empresarial.

    • Problema 65539 resolvido: uma sessão BGP estabelecida entre dois dispositivos entre dois ramos diferentes não surge quando o cliente atualiza os seus VMware SD-WAN Edges para a versão 4.2.x.

      Quando um cliente atualiza os seus Edges de uma versão inferior para a versão 4.2.x, as sessões BGP entre 2 dispositivos LAN de ramos diferentes estabelecidas sobre túneis VCMP não irão surgir.

    • Problema 65673 resolvido: um utilizador operador com sessão iniciada num VMware SD-WAN Gateway que execute o comando de depuração dpdk_xtstats_dump verá uma mensagem de erro de Chamada de Procedimento Remoto (RPC).

      Ao executar o comando debug.py --dpdk_xstats_dump no Gateway, este último emite um erro RPC devido à indisponibilidade do registo de chamada de retorno.

    • Problema 65839 resolvido: para os fluxos iniciados a partir de clientes atrás de um VMware SD-WAN Hub Edge para a LAN atrás de um Edge Spoke, o tráfego de retorno do spoke é encaminhado através do Gateway de parceiro se o caminho predefinido for o anunciado a partir do Gateway de parceiro.

      O comportamento esperado é que um fluxo com origem num Edge Hub também regresse através do Edge Hub. Se não existir um caminho predefinido ou um caminho Edge a Edge anunciado do Edge Hub para o Edge Spoke, a procura do caminho no Edge Spoke para o tráfego de retorno corresponde ao caminho predefinido do Gateway de parceiro e o tráfego de retorno é encaminhado para o Gateway de parceiro em vez do Edge Hub.

      Sem esta correção, a única forma de evitar este problema é anunciar um caminho predefinido ou um caminho Edge a Edge a partir do Edge Hub para o Edge Spoke.

    • Problema 65910 resolvido: a atualização do endereço IP de origem do BGP multi-hop não é atualizada quando o endereço de loopback é alterado, o que resulta na desativação da sessão BGP-MH.

      Quando uma interface de retorno é utilizada como interface de origem para o BGP-MH e o endereço de loopback é alterado, a interface de origem não será atualizada o que resulta na desativação da sessão BGP-MH.

      Sem a correção, a única solução alternativa é a seguinte: depois de modificar o endereço de loopback, reconfigure a interface de origem para o BGP multi-hop.

    • Problema 65985 resolvido: para um cliente que utiliza o Edge a Edge dinâmico, um VMware SD-WAN Edge na sua rede pode eliminar abruptamente todos os túneis e, em seguida, não ser capaz de construir túneis para quaisquer outros locais da rede.

      Assim que o site elimina todos os seus túneis, o valor máximo do túnel do Edge fica corrompido e apresenta um valor negativo para o número máximo de túneis. Este valor corrompido impede que o Edge forme novos túneis Edge a Edge dinâmicos para outros Edges. O impacto é grave, dado que o Edge não consegue comunicar com qualquer outro site na rede.

      Sem a correção, a única forma de resolver este problema é realizar um reinício do serviço Edge ou uma recuperação automática HA para locais HA.

    • Problema 66086 resolvido: a configuração do filtro baseado no mapa do caminho antigo é apresentada numa lista de configurações BGP depois de esse filtro ter sido removido.

      Com uma configuração BGP de vários vizinhos na qual também está associado um filtro de mapa de vários caminhos, se esse filtro for removido mais tarde, a configuração obsoleta persistirá em alguns vizinhos, o que poderá causar perturbações no routing esperado da rede de clientes.

    • Problema 66119 resolvido: quando um Edge Virtual do VMware SD-WAN é implementado numa localização remota, o Edge falha a ativação automática através do cloud-init.

      As localizações remotas têm frequentemente uma elevada latência de rede (superior a um segundo) entre o Edge e o VMware SD-WAN Orchestrator. Este nível de latência faz com que a ativação automática através do cloud-init de um Edge Virtual falhe.

    • Problema 66139 resolvido: um VMware SD-WAN Edge pode sofrer uma Falha do Serviço Dataplane e reiniciar quando um utilizador ativar ou desativar os vizinhos BGP.

      Como parte de todos os eventos de ligação recebidos do BGP, o VMware SD-WAN reaplica a configuração do processo Edge para o BGP e há mais um thread no qual as configurações são removidas, o que resulta em informações de BGP obsoletas e que, em casos raros, pode provocar um cenário de condição race que resulta na Falha do Serviço Dataplane.

    • Problema 66355 resolvido: para um cliente em que a firewall com estado está ativada e pelo menos uma regra NAT (Muitos:1) do lado da LAN está configurada, os fluxos entre VLANs não funcionam.

      Com regras NAT do lado da LAN Muitos:1, o estado TCP não é mantido corretamente para o tráfego entre VLANs e, com a firewall com estado também ativada, os pacotes serão eliminados.

    • Problema 66366 resolvido: para um cliente que utiliza multicast com um número elevado de vizinhos, um VMware SD-WAN Edge pode encontrar uma falha no Serviço dataplane e reiniciar, provocando uma breve perturbação no tráfego do cliente.

      Um “número elevado de vizinhos” é definido como ~1600 vizinhos PIM. No caso de este problema ocorrer enquanto o tráfego está em execução para um grupo de 1600 Edges Spoke para um recetor atrás de um Edge Hub, o serviço PIM falha e isso, por sua vez, faz com que o serviço Edge também falhe, causando o reinício.

    • Problema 66676 resolvido: quando um NAT de política empresarial estiver configurado, pode não ocorrer NAT do tráfego de retorno do VMware SD-WAN Gateway para o IP de origem original.

      Durante a inserção da entrada NAT no código, espera-se que elimine as entradas mais antigas. No entanto, devido à não utilização de todas as chaves para a procura da tabela hash, as entradas mais antigas não eram eliminadas em algumas situações e isso estava a provocar o erro de inserção de entrada NAT.

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

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

    • Problema 66801 resolvido: para um local de cliente que utiliza uma topologia de Alta Disponibilidade e um VNF, o cliente pode não ser capaz de se ligar a um VNF para efetuar o estabelecimento de confiança a partir de um servidor de gestão.

      O problema é observado em locais HA quando as interfaces encaminhadas têm o DHCP ativado e não existe um caminho predefinido presente na tabela de caminhos do núcleo. Neste caso, o núcleo responde com “Destino ICMP inalcançável” (ICMP destination unreachable).

      Sem a correção, a solução alternativa para evitar este problema é adicionar um caminho predefinido no Edge em standby para que o Edge não envie “ICMP inalcançável” (ICMP Unreachable) de volta para a VM VNF, fazendo com que a ligação SSH seja reposta.

    • Problema 67060 resolvido: o VMware SD-WAN Edge pode apresentar uma grande utilização da memória, o que pode potencialmente provocar um reinício do serviço Edge caso seja suficientemente elevada.

      O problema é uma fuga de memória que se manifesta como um aumento lento e contínuo da utilização da memória. O problema ocorre quando vários pacotes de pedido HTTP são enviados para um único fluxo; a fuga de memória ocorre especificamente enquanto o Edge está a analisar os pacotes de pedido HTTP.

    • Problema 67173 resolvido: quando o mesmo caminho é aprendido a partir de vários vizinhos IBGP, o segundo melhor caminho selecionado a partir do processo BGP está a ser utilizado pelo VMware SD-WAN Edge, o que resulta na colocação de determinado tráfego do cliente numa condição de buraco negro.

      Devido a um problema no conjunto de Routing de intervalo livre (Free Range Routing – FRR), o IBGP estava a enviar vários hops seguintes para o Edge e a escolher o segundo melhor (último na ordem de hop seguinte) para atualizar a base de informações de encaminhamento (FIB). A correção inclui um comando no processo BGP para enviar apenas o melhor hop seguinte para o Edge.

    • Problema 67191 resolvido: para um cliente que utiliza um Serviço de Segurança na Cloud (CSS), a verificação do estado de funcionamento da camada 7 devolve uma falha errada e os túneis CSS são eliminados.

      Quando existe um grande número de túneis do Destino Não-SD-WAN (NSD) num VMware SD-WAN Gateway, o IP da Interface do Túnel Virtual (VTI) pode sair do intervalo da máscara de sub-rede /24, cuja definição permite que as sondas sejam processadas pelo Serviço dataplane do Gateway. Isto é o que provoca uma falha errada da verificação do estado de funcionamento da L7. A correção atualiza a máscara para /16 para aceitar a L7 para o processamento no serviço dataplane do Gateway.

      Sem a correção, a única solução é que um operador com acesso ao Gateway altere manualmente o ficheiro /opt/vc/bin/gwd_ip_setup.sh para refletir a alteração da máscara (169.254.0.0/24 para 169.254.0.0/16), seguindo-se um reinício do serviço de Gateway.

    • Problema 67197 resolvido: uma rede de cliente pode sofrer perturbações periódicas do serviço multicast em implementações com mais de 1500 origens associadas a um grupo multicast.

      Um problema de software na lógica de processamento de mensagens de unir/eliminar conjuntos PIM falha com uma exceção ao processar atualizações de unir/eliminar em implementações com mais de 1500 origens associadas a um grupo multicast.

      Sem a correção, a única forma de evitar este problema é limitar o número total de origens multicast a 1000.

    • Problema 67259 resolvido: o fluxo de tráfego multicast é perturbado quando o processo PIM reinicia várias vezes e o vizinho PIM não surge.

      Numa configuração à escala com 1600 vizinhos PIM, ao reiniciar o processo PIM várias vezes enquanto o tráfego está em execução de 700 Edges Spoke para um recetor atrás de um Edge Hub, após um dos reinícios, apenas 570+ vizinhos PIM surgiam dos 1600 vizinhos PIM. A única forma de resolver este problema é reiniciar o serviço Edge.

    • Problema 67485 resolvido: o VMware SD-WAN Gateway pode ter interfaces em falta durante uma atualização. 

      Existe um intervalo de tempo muito estreito para terminar o processo de dataplane do Gateway antes de este processo ter inicializado todas as interfaces DPDK KNI (baseadas em software). Ao regressar ao núcleo, não é possível encontrar a interface KNI. Ao regressar ao DPDK, esse mesmo estado é mantido com uma interface em falta.

    • Problema 67694 resolvido: um cliente pode encontrar uma falha no túnel do Serviço de Segurança na Cloud (CSS) porque as sondas de Verificação de estado de funcionamento de L7 do estado de funcionamento são interligadas condicionalmente.

      As sondas de Verificação de estado de funcionamento de L7 do estado de funcionamento nunca devem ser sistematicamente interligadas e falham quando isto acontece, o que faz com que os túneis CSS sejam erradamente marcados como desativados.

    • Problema 67790 resolvido: para uma empresa cliente que utiliza o BGP ou o OSPF e configurou os filtros de entrada para ignorar certos caminhos, quando o Cálculo dinâmico de custos (DCC) estiver ativado nesta empresa, os filtros de entrada deixarão de estar em vigor e o tráfego tentará utilizar esses caminhos.

      Antes de o DCC ser ativado, a base de informações de encaminhamento (FIB) não incluirá os caminhos que foram definidos para IGNORAR (IGNORE) no filtro de entrada BGP/OSPF.  Depois de o DCC ser ativado, a FIB inclui agora estes caminhos e o tráfego tentará utilizá-los com o potencial para uma perturbação significativa do tráfego para a empresa do cliente.

      Sem a correção, a única solução alternativa é reiniciar o OSPF/BGP para que o filtro de entrada seja corretamente aplicado.

    • Problema 67869 resolvido: quando um VMware SD-WAN Hub Edge tiver sido configurado previamente como pilha única IPv4 e, mais tarde, é alterado para pilha dupla IPv6 preferencial, o túnel IPv4 mais antigo não será desligado.

      Quando este problema se manifesta, o cliente observa uma contagem incorreta de túneis porque os túneis IPv4 não estão a ser desativados. Com efeito, o número de túneis duplica.

    • Problema 68994 resolvido: os clientes que implementem um túnel de Destino Não-SD-WAN (NSD) a partir de um VMware SD-WAN Edge com um VMware SD-WAN Gateway podem observar instabilidade no túnel.

      Este problema é observado no estabelecimento do túnel ou na recodificação da IKE. O Edge ou o Gateway elimina as associações de segurança (SAs) com base em IKESAID=0, o que provoca a instabilidade no túnel. O túnel estabiliza automaticamente, mas o tempo necessário para o fazer não é consistente e tal pode aumentar o impacto no tráfego do cliente para o NSD.

    • Problema 69704 resolvido: ativar a Alta Disponibilidade num site com uma plataforma VMware SD-WAN Edge 6x0 (610, 620, 640, 680) pode interromper a comunicação do Edge com o VMware SD-WAN Orchestrator.

      Isto foi verificado nas versões 4.3.0 e 4.4.0. Depois de permitir a HA, devido a determinadas condições de tempo, a comunicação do Orchestrator é interrompida. Deste modo, a HA não ocorre e o Edge perde a conetividade total com o Orchestrator, o que significa que o Orchestrator irá marcar o Edge como inativo, não sendo possível efetuar mais alterações de configuração.

    • Problema 70310 resolvido: Para um cliente que utiliza vários segmentos, quando um ou mais segmentos são eliminados ou desativados, um VMware SD-WAN Edge pode sofrer uma falha no Serviço dataplane e reiniciar esse serviço, provocando uma breve perturbação no tráfego do cliente. 

      Quando um segmento é eliminado, o Edge não limpa completamente a memória associada ao mesmo. Existem cenários em que o Edge ativo sincroniza eventos para o Edge em standby, fazendo referência a tais segmentos, o que resulta numa falha de serviço no Edge em standby, uma vez que estes segmentos não estão presentes.

    • Problema 70416 resolvido: o VMware SD-WAN Gateway pode apresentar uma carga elevada da CPU, o que resulta em perda de pacotes e latência para os Edges que o utilizam como o seu Gateway principal.

      Este problema é provocado pelos threads de caminho rápido do Gateway (IKE, dados VCMP, etc.), que gastam entre 15 e 20% dos seus ciclos a realizar operações inetNtop. A correção para este problema remove as operações InetNtop e substitui-as por um processo de formatação de dados mais eficiente.

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

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

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

    • Problema 70789 resolvido: o cliente pode sofrer situações em que o tráfego é aleatoriamente eliminado devido à deteção antirreprodução do IPSec.

      Se um VMware SD-WAN Edge ou VMware SD-WAN Gateway receber dois pacotes em que cada um deles atualiza o número de sequência de entrada em cache, é possível que o primeiro pacote atualize incorretamente a janela de reprodução, o que pode acionar a deteção antirreprodução do IPsec e fazer com que o pacote IPsec seja eliminado.

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

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

    • Problema 71513 resolvido: um utilizador que consultasse o separador Gateways > Monitor na IU de um VMware SD-WAN Orchestrator observaria que as Handoff Queue Drops mostram sempre um valor de 0 para um VMware SD-WAN Gateway com a versão 4.3.0.

      Os Gateways com a versão 4.3.0 ou superior não comunicam Handoff Queue Drops ao Orchestrator devido a formatação incorreta e isto impede que o operador obtenha uma imagem clara deste ponto de dados específico de resolução de problemas.

    Problemas resolvidos do Orchestrator

    Resolvido na versão R450-20220502-GA do Orchestrator

    A versão R450-20220502-GA do Orchestrator foi lançada a 04-05-2022 e é o oitavo rollup do Orchestrator para a versão 4.5.0.

    Esta compilação rollup do Orchestrator aborda os problemas críticos abaixo desde o sétimo rollup do Orchestrator, versão R450-20220315-GA.

    • Problema 78688: Um VMware SASE Orchestrator que aloja clientes que utilizam um Serviço de Segurança na cloud (CSS) Zscaler pode sofrer um pico de utilização da CPU, o que leva a uma latência elevada nos pedidos de processamento e o Orchestrator não atualiza as estatísticas de estado de funcionamento do Edge. 

      O processamento das Estatísticas de estado de funcionamento do Orchestrator Edge tem uma procura de base de dados que não está otimizada e isto aumenta a utilização da CPU pelo Orchestrator.

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

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

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

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

    • Problema 84969: 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 que execute a versão 4.3.x ou superior (incluindo a 4.5.0) 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 o Edge é atualizado da versão 4.2.x para uma versão 4.3.x ou uma compilação posterior.

      Solução alternativa: um utilizador teria de reconfigurar o IP de gestão substituído.

    Problemas resolvidos do Orchestrator e funcionalidade adicionada

    Resolvido na versão R450-20220315-GA do Orchestrator

    A versão R450-20220315-GA do Orchestrator foi lançada em 16/03/2022

    Esta compilação do Orchestrator remedeia a CVE-2021-45046, uma vulnerabilidade do Apache Log4j, ao atualizar para a versão Log4j 2.17.0. A compilação também remedeia a CVE-2021-44228, que foi abordada pela primeira vez na compilação R450-20211218-GA do Orchestrator com a versão 2.16.0 do Log4j. Para obter mais informações sobre a vulnerabilidade do Apache Log4j, consulte o VMware Security Advisory VMSA-2021-0028.13.

    Adicionalmente, esta compilação do Orchestrator aborda vários problemas críticos desde a versão R450-20220215-GA do Orchestrator.

    Esta compilação também adiciona uma nova funcionalidade ao Cloud Web Security: Prevenção de perda de dados (DLP).  Esta nova funcionalidade é analisada com maior detalhe no início das notas de versão na secção Novas funcionalidades do SASE.

    • Problema 69573 resolvido: Para clientes que utilizam o VMware Secure Access, quando criam um serviço de acesso remoto, caso a validação falhe no ecrã Definições da empresa e da rede (Enterprise & Network Settings), o botão Seguinte (Next) é desativado conforme esperado, mas as mensagens de erro não são apresentadas.

      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), não será apresentada nenhuma mensagem de erro abaixo destes campos para ajudar o utilizador a compreender o motivo da falha da configuração.

    • 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 79324 resolvido: No serviço Cloud Web Security para aplicações específicas, alguns Controlos de aplicação CASB estão efetivamente ligados (por outras palavras, definir uma aplicação para bloquear pode bloquear também outra aplicação), enquanto o Assistente de regras de exceção CASB os apresenta individualmente.

      O Assistente de regras de exceção CASB agora alerta os utilizadores quando os Controlos de aplicação CASB para a aplicação selecionada estão ligados e a alteração do Controlo afetado também irá alterar os outros. Além disso, apenas as aplicações sem controlos ligados podem ser agrupadas numa Regra de exceção, enquanto que uma aplicação com controlos ligados precisa da sua própria Regra de exceção.

    • Problema 83534 resolvido: Para clientes que utilizam o VMware Cloud Web Security, um cliente com uma licença Padrão conseguirá aceder às funcionalidades reservadas de um cliente com uma licença Avançada.

      A API que valida a licença do Cloud Web Security do cliente e certifica que o cliente acede às funcionalidades corretas da licença não funcionou corretamente e permitiu que todos os clientes acedessem a todas as funcionalidades do Cloud Web Security (por exemplo, Controlo de aplicações do CASB, independentemente do tipo de licença). 

    • Problema 83538 resolvido: Para clientes que utilizam o serviço Secure Access, quando criam um serviço de Acesso Remoto, o ecrã de Definições da Rede e da Empresa mostra chaves de mensagem de erro interno.

      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 83822 resolvido: Para os clientes que utilizam o VMware Cloud Web Security, ao consultar Monitorizar > Registos > Registos Web (Monitor > Logs > Web Logs), 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. 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 83940 resolvido: Para clientes que utilizam o VMware Cloud Web Security, um cliente com uma Licença Padrão conseguirá ver páginas tanto para a Prevenção de perda de dados (DLP) como para as páginas de Controlo de aplicações do CASB na IU do VMware SASE Orchestrator.

      Um cliente com uma licença Padrão do Cloud Web Security não terá acesso às funcionalidades DLP e de Controlo de aplicações do CASB e a IU não deverá apresentar páginas para essas funcionalidades. Este problema é causado por uma configuração de caminho em falta na IU do Cloud Web Security.

    • Problema 84286 resolvido: Para os clientes que utilizam o serviço VMware Cloud Web Security, um utilizador com privilégios só de leitura não verá registos na página Cloud Web Security > Eventos (Events) até selecionar um intervalo de tempo.

      A página Cloud Web Security > Eventos (Events) de um utilizador só de leitura será apresentada em branco, o que significa que não há registos para apresentar. Mas se o utilizador selecionar um novo intervalo de tempo, os registos corretos para esse intervalo de tempo serão apresentados.

    • Problema 84297 resolvido: Para o cliente que utiliza o VMware Cloud Web Security, os utilizadores só de leitura serão capazes de editar as configurações do Cloud Web Security para as páginas Motor de inspeção de conteúdos (Content Inspection Engine) e Autenticação (Authentication).

      O VMware SASE Orchestrator não está a impor corretamente a função de utilizador só de leitura para as páginas de configuração do Cloud Web Security selecionadas. 

    • Problema 84299 resolvido: Para os clientes que utilizam o VMware Cloud Web Security, os administradores de clientes com a função de Administrador de segurança ou de Leitura de segurança não conseguirão abrir a página Cloud Web Security > Monitorizar (Monitor) na IU do VMware SASE Orchestrator.

      Os administradores de clientes com funções de Segurança (Administrador e Leitura) não terão os privilégios necessários para ver a página Monitorizar (Monitor) do Cloud Web Security no Orchestrator.

    • Problema 84300 resolvido: Para os clientes que utilizam o serviço VMware Cloud Web Security, um administrador de cliente com qualquer função só de leitura poderá remover endereços de e-mail de auditor da página Configurar > DLP (Configure > DLP).

      Funções de administrador de cliente com estado só de leitura no Cloud Web Security: Apoio ao cliente, Leitura de segurança e Administrador de rede. Qualquer um destes administradores pode aceder a Cloud Web Security > Configurar > Definições DLP (Cloud Web Security > Configure > DLP Settings) e, no separador Auditores (Auditors), pode eliminar os endereços de e-mail configurados dos auditores que supostamente receberão os e-mails de alerta da DLP.

    ___________________________________________________________________

    Resolvido na versão R450-20220215-GA do Orchestrator

    A versão R450-20220215-GA do Orchestrator foi lançada a 17/02/2022 e resolve vários problemas críticos desde a versão R450-20211218-GA do Orchestrator.

    • Problema 64410 resolvido: para clientes que utilizam o VMware Cloud Web Security, um utilizador pode adicionar endereços IP inválidos como parte da regra de inspeção SSL na nova IU do VMware SD-WAN Orchestrator.

      Isto pode ser feito através de uma política de segurança existente ou de uma nova política de segurança para a origem ou o destino. Quando o utilizador termina a configuração da regra com um IP inválido, não é apresentada qualquer mensagem de erro. Em seguida, quando o utilizador tenta publicar a regra, ocorre um erro que é inútil para o utilizador e que indica “erro ao publicar a política de segurança: o pedido falhou com o código de estado 400”.

    • Problema 64438 resolvido: para clientes que utilizam o VMware Cloud Web Security, um utilizador pode adicionar caracteres inválidos ao nome de uma política de segurança ao atualizar a regra na nova IU do VMware SD-WAN Orchestrator.

      Por exemplo, ao criar uma política de segurança, se um utilizador introduzir caracteres inválidos como “<>” no nome, a IU do Orchestrator apresenta um erro, mas, se o utilizador editar uma política de segurança existente, atualizar o respetivo nome para “<>” e guardar, o nome da política de segurança é atualizado.

    • Problema 68153 resolvido: para os clientes que utilizam o VMware Secure Access, um utilizador pode não conseguir eliminar um serviço Secure Access da nova IU do VMware SD-WAN Orchestrator.

      Quando a criação de um serviço Secure Access falhar e o utilizador tentar eliminar o Secure Access da IU do Orchestrator, a eliminação pode falhar. Isto acontece quando alguns recursos não são criados aquando da falha do Secure Access e, portanto, não é possível concluir a eliminação adequadamente, uma vez que o serviço de back-end tenta encontrar estes recursos para eliminar, mas falha. O resultado seria uma chamada de eliminação falhada.

    • Problema 74284 resolvido: para os clientes que utilizam o VMware Cloud Web Security, ao criar uma nova regra Cloud Access Security Broker (CASB) e selecionar uma aplicação de destino, o botão está definido para “Todas as aplicações” (All Applications) na nova IU do VMware SD-WAN Orchestrator.

      Ao criar uma nova regra CASB, o botão deve ser definido como “Personalizado” (Custom), o que permite ao utilizador escolher as aplicações às quais a regra CASB é aplicada. No entanto, por vezes, o botão está definido e “bloqueado” em “Todas as aplicações” (All Applications), o que engloba todas as mais de 1000 aplicações às quais a regra CASB pode ser aplicada.

    • Problema 74491 resolvido: num VMware SD-WAN Orchestrator configurado para a recuperação após desastre, onde também estão a funcionar os serviços VMware Cloud Web Security e VMware Secure Access, a replicação pode falhar entre os Orchestrators ativos e em standby, com o utilizador a observar erros na IU do Orchestrator.

      Quando o problema ocorre, o MySQL no Orchestrator em standby não reproduz os eventos do Orchestrator ativo. O motivo para isto é que os serviços Cloud Web Security/Secure Access estão a funcionar no Orchestrator em standby, o que também está a modificar o estado da base de dados.

    • Problema 74674 resolvido: para os clientes que utilizam o VMware Cloud Web Security, quando o utilizador está na página Cloud Web Security da nova IU do VMware SD-WAN Orchestrator, não existe qualquer secção que apresente eventos específicos do Cloud Web Security.

      Com este problema, o único problema que é apresentado é CWS_EVENT, que não disponibiliza quaisquer detalhes para o utilizador. Um Orchestrator que inclua esta correção observaria agora uma ligação de Eventos no painel de navegação à esquerda que direciona para uma página de Eventos dedicada apenas para o Cloud Web Security.

    • Problema 74710 resolvido: para os clientes que utilizam o VMware Cloud Web Security, o formato da data da Emissão do certificado e da Expiração do certificado está sempre em inglês dos EUA na nova IU do VMware SD-WAN Orchestrator.

      Ao configurar uma regra CASB, selecione qualquer aplicação, na caixa de diálogo apresentada, o formato da data para a Emissão do certificado (Cert. Issue) e Expiração do certificado (Cert. Expiration) estará sempre em inglês dos EUA, independentemente da localização real do navegador do utilizador (por exemplo, espanhol).

    • Problema 74715 resolvido: para os clientes que utilizam o VMware Cloud Web Security, quando um utilizador com um navegador que tenha uma localização de idioma que não o inglês está a configurar uma Política de segurança > Regra CASB (Security Policy > CASB Rule), as cadeias de texto da caixa de diálogo apresentada são truncadas na nova IU do VMware SD-WAN Orchestrator.

      O utilizador não consegue ver o texto completo para um passo específico na configuração de uma regra CASB quando essas cadeias de texto não estão em inglês.  Em vez disso, a frase é simplesmente cortada no limite da caixa de texto.

    • Problema 74825 resolvido:  para os clientes que utilizam o VMware Cloud Web Security, quando um utilizador com um navegador que tenha um idioma que não o inglês tenta realizar uma pesquisa na página Política de segurança > CASB (Security Policy > CASB) através de cadeias de texto que não estão em inglês, não são devolvidos quaisquer resultados na nova IU do VMware SD-WAN Orchestrator.

      Embora uma parte do texto estivesse a ser apresentada como traduzida na grelha de regras do Cloud Web Security, a caixa de pesquisa estava a pesquisar texto não traduzido. A única solução alternativa para um utilizador não inglês é utilizar o filtro para a coluna da classificação do risco para filtrar diferentes níveis, como Baixo, Médio e Alto.

    • Problema 77043 resolvido: para um local que utilize uma topologia de Alta Disponibilidade, em que os VMware SD-WAN Edges utilizam a versão 4.3.x ou posterior, numa recuperação automática HA, o VMware SD-WAN Orchestrator não regista um evento de recuperação automática HA.

      O Orchestrator filtra eventos HA_GOING_ATIVE em Edges com a versão 4.3.x ou posterior para evitar uma condição race e, como resultado, o evento não é apresentado em Eventos (Events).

    • Problema 77101 resolvido: quando um VMware SD-WAN Orchestrator é atualizado, os clientes que utilizam o BGP podem encontrar os seus caminhos alterados de “Transmissão” (Uplink) para “Não transmissão” (Non-Uplink).

      Existe um potencial impacto na ordem dos caminhos para os prefixos recebidos deste vizinho, o que pode levar a saídas de routing não preferenciais.

      Sem esta correção, um utilizador teria de voltar a configurar o flag de transmissão para os vizinhos BGP afetados após a atualização.

    • Problema 80613 resolvido: num VMware SD-WAN Orchestrator configurado para a recuperação após desastre (DR), a replicação pode falhar entre os Orchestrators ativos e em standby, com o utilizador a observar o estado A copiar DB (Copying DB) como “Falhado” (Failed) na IU do Orchestrator.

      Desde a versão 8.0.26 do MySQL, a opção de dados principais foi descontinuada no comando mysqldump. Esta foi substituída por uma opção de dados de origem.
      Este problema é encontrado porque o processo de DR do Orchestrator utiliza o comando mysqldump com a opção de dados principais. No entanto, com a atualização do MySQL para a versão mais recente, esta opção já não funciona e, por isso, interrompe a DR. Para resolver este problema, o Orchestrator com esta correção utiliza a opção de dados de origem em vez da opção de dados principais para o comando mysqldump durante o processo de DR.

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

      O Orchestrator que execute 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 o Edge é atualizado da versão 4.2.x para uma versão 4.3.x ou uma compilação posterior.

    • Problema 81599 resolvido: para clientes que utilizam o VMware Cloud Web Security, a inspeção SSL está incorporada no separador Segurança Web (Web Security) na nova IU do VMware SD-WAN Orchestrator.

      O problema aqui é que as regras de inspeção SSL não são específicas das políticas de segurança Web, mas são igualmente aplicáveis ao CASB e ao DLP. Como resultado, com esta compilação do Orchestrator e posteriores, o utilizador observa a inspeção SSL com o seu próprio separador juntamente com a Segurança Web, o CASB e o DLP para que o utilizador possa facilmente aceder e configurar essas regras conforme necessário.

    ___________________________________________________________________

    Resolvido na versão R450-20211218-GA do Orchestrator

    A versão R450-20211218-GA do Orchestrator foi lançada a 20-12-2021. Esta compilação do Orchestrator remedeia a CVE-2021-44228, a vulnerabilidade do Apache Log4j, ao atualizar para a versão Log4j 2.16.0. Para obter mais informações sobre a vulnerabilidade do Apache Log4j, consulte o VMware Security Advisory VMSA-2021-0028.5.

      ___________________________________________________________________

      Resolvido na versão R450-20211120-GA do Orchestrator

      A versão R450-20211120-GA do Orchestrator foi lançada a 22/11/2021 e resolve vários problemas críticos desde a versão R450-20211109-GA do Orchestrator.

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

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

      • Problema 75188 resolvido: quando um cliente utiliza a Automatização GRE na versão 4.5.0, os túneis primário e secundário não podem estar na mesma localização.

        Quando os clientes utilizam a Automatização GRE, é apresentada uma lista de túneis recomendados e são utilizados os dois primeiros como primário e secundário. No entanto, o design não permite que os túneis primário e de backup sejam para o mesmo centro de dados. Por exemplo, se o túnel primário fosse configurado para o centro de dados de São Francisco e o secundário fosse configurado para o centro de dados de Los Angeles, surgiriam ambos os túneis.

      • Problema 75781 resolvido: quando um VMware SD-WAN Orchestrator é atualizado da versão 3.x para a 4.5.0, os utilizadores observarão longas lacunas sem dados na IU do Orchestrator para o separador de monitorização de QoE. Estas lacunas serão observadas para intervalos de tempo abrangidos antes da atualização.

        Após a atualização para a versão 4.5.0, espera-se que todos os dados de QoE sejam migrados do MySQL para o ClickHouse, tendo o utilizador a capacidade de ver todos os dados históricos de QoE servidos do ClickHouse após a atualização. No entanto, devido a um problema com a lógica empresarial da migração, os dados não eram transferidos com sucesso.

      • Problema 75859 resolvido: para um VMware SD-WAN Orchestrator a funcionar no modo FIPS e que é atualizado para a versão 4.5.0, um operador pode observar uma taxa elevada de eventos de auditoria e carga de disco.

        O problema de um Orchestrator a funcionar no modo FIPS é que são criados perfis duplicados do apparmor (um serviço de segurança) para o MySQL durante a atualização para a versão 4.5.0, o que impede o início do serviço apparmor.

      ___________________________________________________________________

      Resolvido na versão R450-20211109-GA do Orchestrator

      A versão R450-20211109-GA do Orchestrator foi lançada a 10/11/2021 e resolve vários problemas críticos desde a versão R450-20211101-GA do Orchestrator.

      • Problema 69196 resolvido: quando um cliente tem um site com uma ligação WAN configurada como backup e também utiliza um Serviço de Segurança na Cloud (CSS), é possível que um utilizador observe eventos de túnel CSS para a ligação de backup.

        Se o utilizador tiver ligações WAN de backup onde estão configurados túneis CSS, verá eventos relacionados com essas ligações, juntamente com ligações ativas e de reserva dinâmica. Uma vez que a ligação de backup é, por definição, inativa, estes eventos são falsos e desagradáveis para o cliente.

      • Problema 72018 resolvido: se um parceiro ativar os serviços SASE como o Cloud Web Security e o Secure Access, esses serviços não funcionarão porque os Gateways SASE não serão atribuídos.

        Antes desta compilação do VMware Orchestrator, a ativação dos serviços SASE para parceiros não era suportada. Como resultado, se um parceiro ativasse um serviço SASE, o Orchestrator não reagiaria ao atribuir Gateways SASE aos clientes do parceiro.

      • Problema 72020 resolvido: um parceiro não poderá usufruir dos serviços SASE nos respetivos Gateways SASE atribuídos estaticamente nos PoPs SASE alojados do VMware e não serão atribuídos Gateways SASE aos Edges do cliente do parceiro.

        Este problema está associado ao 72018 e é igualmente provocado pela falta de suporte para ativar serviços SASE para parceiros antes desta versão do Orchestrator.

      • Problema 75311 resolvido: quando um cliente carrega um mapa de aplicação personalizado que inclui sub-redes duplicadas de VMware SD-WAN Edges mais antigos para um VMware SD-WAN Orchestrator que utiliza a versão 4.5.0, o cliente observará um erro de validação por ter sub-redes duplicadas.

        A correção remove a validação para sub-redes duplicadas de modo a permitir que os clientes carreguem um mapa de aplicação de Edges mais antigos com valores duplicados.

      • Problema 75433 resolvido: se um utilizador navegar até Monitorizar > Serviços de rede (Monitor > Network Services) e verificar os detalhes de um Destino Não-SD-WAN no VMware SD-WAN Orchestrator, observará que o campo VPN de cloud redundante (Redundant Cloud VPN) não é só de leitura, mas tem uma caixa de verificação que o utilizador pode selecionar.


        Espera-se que todos os ecrãs de Monitorização sejam puramente só de leitura, pelo que ter qualquer item configurável no ecrã de Monitorização não é correto. Não deve existir qualquer funcionalidade de atualização para os Serviços de rede ou em qualquer outro local.

      ___________________________________________________________________

      Resolvido na versão R450-20211101-GA do Orchestrator

      A versão R450-20211101-GA do Orchestrator foi lançada a 01/11/2021 e resolve vários problemas críticos desde a versão  R450-20211012-GA do Orchestrator.

      • Problema 63110 resolvido: para um cliente que utiliza o serviço VMware Cloud Web Security, ao configurar uma política do Cloud Web Security, um utilizador não pode eliminar um nome de domínio anterior numa lista sem a truncar.

        O utilizador não pode ver os domínios anteriores àquele que está a ser visto e não há forma de os mostrar com a IU existente. A capacidade de editar corretamente uma política do Cloud Web Security não foi devidamente implementada nas compilações anteriores do Orchestrator 4.5.0.

        Sem esta funcionalidade, a única opção do utilizador é eliminar todos os itens listados após o item e, em seguida, reintroduzi-los.

      • Problema 64762 resolvido: para um cliente que utiliza o serviço VMware Cloud Web Security, ao tentar configurar a inspeção de conteúdos com o assistente de inspeção de conteúdos, o utilizador observa uma falta de ajuda contextual.

        O utilizador depara-se com este problema ao abrir o assistente de inspeção de conteúdos, uma vez que o utilizador deve esperar que haja ajuda contextual para garantir que o utilizador pode configurar esta funcionalidade com sucesso.

      • Problema 69570 resolvido: ao utilizar a nova IU no VMware SD-WAN Orchestrator, um administrador de clientes observa que o comutador de aplicações não está visível.

        Um administrador de clientes deverá poder ver um separador da interface que permita ao utilizador alternar entre o SD-WAN, Cloud Web Security e o Secure Access, mas esse separador não está presente.

      • Problema 69912 resolvido: um utilizador operador que utilize a nova IU no VMware SD-WAN Orchestrator, se abrir a consola no browser, poderá observar erros relacionados com privilégios em falta.

        A janela da consola mostra uma série de erros que indicam “ERRO TypeError: Não é possível ler a propriedade “authType” de indefinido”. Este problema é provocado por um componente do cabeçalho que não tem o privilégio necessário.

      • Problema 72041 resolvido: para um cliente que utiliza o serviço VMware Cloud Web Security, um utilizador não consegue criar uma regra de filtragem de URL com domínios que tenham caminhos, como “google.com/flights”.

        Um utilizador deverá conseguir impor um conjunto de regras de filtragem de URL que permita um domínio como www.facebook.com, enquanto bloqueia este mesmo domínio com um caminho, como www. facebook.com/gaming. Quando o utilizador tenta criar uma regra de filtragem de URL na IU do Cloud Web Security para um nome de domínio com um caminho, o Orchestrator apresenta um erro. 

      • Problema 73910 resolvido: para um cliente que utiliza o serviço VMware Cloud Web Security, o utilizador não pode atualizar nenhuma das definições do motor de inspeção de conteúdos.

        Um utilizador não pode atualizar as definições de nenhum parâmetro do motor de inspeção de conteúdos porque a IU do VMware SD-WAN Orchestrator descarta qualquer alteração do utilizador quando a secção Detalhes está fechada.

      • Problema 74038 resolvido: para um cliente que utiliza o serviço VMware Cloud Web Security, uma tentativa de publicar uma política de segurança com uma regra de inspeção de conteúdos que selecione uma opção ISO em “Arquivos e pacotes comprimidos” (Archives and Compressed Packages) não é bem sucedida.

        Quando a opção ISO é selecionada, os dados transmitidos para o serviço Cloud Web Security não são compatíveis com a nossa API atual, especialmente a opção ISO Tipo v1 que precisa de ser modificada.

      • Problema 74106 resolvido: os clientes que não tenham ativado o Cálculo dinâmico de custos (DCC) e estejam localizados nos VMware SD-WAN Orchestrators, que acolhe um grande número de clientes, podem observar atrasos no tempo necessário para a sincronização das rotas das respetivas empresas.  Um utilizador operador desse Orchestrator observa um elevado número de rejeições de eventos de routing no Orchestrator.

        Nos Orchestrators de produção com uma escala de routing elevada, este problema provocará um atraso significativo na sincronização das rotas para um cliente Não-DCC e, por isso, atrasará a convergência da rota do dataplane. A resolução deste problema melhora a limitação da taxa do Orchestrator de routing de chamadas de API nos VMware SD-WAN Edges, o que melhora o tempo de convergência de rotas do lado do dataplane em ambientes de clientes que não estão a utilizar o Cálculo de custos distribuídos.

      • Problema 74187 resolvido: para um cliente que utiliza o serviço VMware Cloud Web Security, um utilizador não consegue configurar corretamente uma regra de filtragem de conteúdos para transferir um ficheiro para o tipo de ficheiro “Outros documentos”.

        Quando um utilizador tenta criar uma regra de filtragem de conteúdos para transferir um ficheiro para o tipo de ficheiro “Outros Documentos”, as opções de tipo de ficheiro apresentadas ao utilizador são do tipo de ficheiro “Ferramentas de apresentação”.

      • Problema 74460 resolvido: os utilizadores parceiros não conseguem remover os handoffs do Gateway de parceiro por segmento.

        Os utilizadores parceiros não têm permissão para modificar VMware SD-WAN Gateways alojados na cloud, mas quando um parceiro invoca a API para modificar a configuração de handoff para um Gateway de parceiro, o back-end do Orchestrator tratava um Gateway de parceiro como um Gateway alojado na cloud. O problema surgiu devido a correções anteriores em torno das configurações de handoff de conjuntos de Gateways mistos (conjuntos que incluem Gateways alojados na cloud e alojados em parceiros).

      • Problema 74491 resolvido: para um VMware SD-WAN Orchestrator configurado numa topologia de recuperação de desastres, um utilizador operador pode observar que a replicação falhou entre os Orchestrators ativos e em standby.

        O MySQL no Orchestrator em standby falha ao reproduzir os eventos do Orchestrator ativo. O motivo é que os serviços VMware Cloud Web Security e Secure Access estão a funcionar no Orchestrator em standby e cada serviço está a modificar o estado da base de dados.

      ___________________________________________________________________

      Resolvido na versão R450-20211012-GA do Orchestrator

      A versão R450-20211012-GA do Orchestrator foi lançada a 12-10-2021 e resolve dois problemas críticos desde a versão  R450-20211006-GA do Orchestrator.

      • Problema 72386 resolvido: na secção Monitorizar > Edge (Monitor > Edge) de um VMware SD-WAN Orchestrator, quando olhar para o separador QoE em monitorização, o utilizador observará amostras que indicam que não existem dados para a extremidade direita da série temporal.

        O problema é observado se um utilizador aceder a uma página Monitorizar > Edge (Monitor > Edge) para qualquer VMware SD-WAN Edge e selecionar o separador QoE com um intervalo de tempo de 12 horas ou mais.

        Sem a correção, o utilizador terá de consultar o intervalo de tempo pretendido em incrementos de 1 hora. Quando tal é efetuado desta forma, o utilizador não observa quaisquer lacunas.

      • Problema 72424 resolvido: os clientes que utilizam o Secure Access não conseguem utilizar a funcionalidade “Editar” (Edit) para editar o servidor DNS, os bits da sub-rede ou a sub-rede. Adicionar ou remover o serviço Cloud Web Security também não funciona.

        A implementação do Secure Access falhará quando qualquer um dos elementos da lista acima for editado, exceto o Cloud Web Security. Uma implementação do Secure Access será concluída com sucesso para uma alteração do Cloud Web Security, mas não atualiza de facto o campo do Cloud Web Security com o novo valor.

        Sem esta correção, como uma solução alternativa, o utilizador, em vez de editar o Secure Access, iria eliminar e criar um novo Secure Access com as atualizações pretendidas.

      Problema resolvido e funcionalidade adicionada

      Resolvido na versão R450-20211006-GA

      A versão R450-20211006-GA do Orchestrator foi lançada a 08-10-2021 e resolve um novo problema crítico desde a versão R450-20210924-GA do Orchestrator. 

      Esta compilação também adiciona uma nova funcionalidade ao Cloud Web Security: Mediador de segurança de acesso à cloud (Cloud Access Security Broker – CASB).  Esta nova funcionalidade é analisada com maior detalhe no início das notas de versão na secção Novas funcionalidades do Cloud Web Security.

      • Problema 71278 resolvido: as chamadas de API iniciadas por um administrador de parceiros ao método linkQualityEvent/getLinkQualityEvents falham com o erro “Nenhum ID de empresa na consulta” (No enterprise id in query) quando o parâmetro enterpriseId não é especificado.

        O VMware SD-WAN começou a tratar o enterpriseId como obrigatório para esta chamada de API a partir da versão 4.5.0 GA, apesar de muitos parceiros nunca terem utilizado um enterpriseId na respetiva chamada de API. Como resultado, a correção aqui é não exigir o enterpriseId para esta chamada de API.

        Sem esta correção, tanto os utilizadores operadores como os administradores de parceiros são aconselhados a garantir que o parâmetro “enterpriseId” é sempre especificado nas chamadas para este método de API, bem como todos os outros métodos de API que operam em dados geridos pelo cliente.

      Problemas resolvidos do Orchestrator

      Resolvido na versão R450-20210924-GA

      Os problemas abaixo foram resolvidos a partir da versão R430-20210810-GA do Orchestrator. 

      • Problema 48706 resolvido: os utilizadores podem não conseguir guardar as alterações no separador Configurar > Edge > Dispositivo (Configure > Edge > Device) com a interface de origem selecionada sob a configuração Syslog.

        O erro que o utilizador veria no VMware SD-WAN Orchestrator é “A interface de origem fornecida não está presente no segmento: <Nome do segmento>” (Provided source interface is not present in the segment on segment: <Segment Name>). Isto é provocado pelo utilizador criar e eliminar um determinado número de segmentos de forma que a sequência de segmentos já não seja sequencial.

      • Problema 48791 resolvido: o utilizador não consegue comutar um VMware SD-WAN Edge entre perfis quando o Edge tem uma interface configurada com a anulação do Edge.

        Por exemplo, se um cliente tiver dois perfis de configuração: o Perfil 1 e o Perfil 2 e associa um Edge ao Perfil 1.  Se o utilizador utilizar então a anulação do Edge para configurar o GE2 como encaminhado e adicionar um caminho estático para o GE2, quando o utilizador tentar, posteriormente, atribuir este mesmo Edge ao Perfil 2, vai observar um erro onde o GE2 não existe no Perfil 2 como encaminhado. Este problema ocorre porque, quando um utilizador configura uma interface do Edge com a anulação do Edge que pertence a um perfil, o VMware SD-WAN Orchestrator não consegue mudar, dado que o Orchestrator não valida a presença da anulação do Edge.

      • Problema 51210 resolvido: a vista de “gestão” (management) da API da IU do VMware SD-WAN Orchestrator foi inadvertidamente disponibilizada aos utilizadores que não tinham os privilégios para modificar (ou seja, revogar) tokens da API.

        Os administradores padrão conseguiam ver os tokens da API alocados a outros utilizadores nas páginas “Autenticação” (Authentication) do inquilino; isto não é considerado um problema de segurança, mas não é suposto acontecer, dado que estes utilizadores não têm a capacidade de modificar tokens da API alocados a outros utilizadores.

      • Problema 52315 resolvido: ao utilizar a nova IU no VMWare SD-WAN Orchestrator, um utilizador pode observar inconsistências no que diz respeito ao certificado Edge.

        Se um utilizador navegar para a lista de Edges e selecionar um Edge que tem vários certificados, abre uma caixa pop-up.  O problema é que, por vezes, o utilizador irá ver o design da IU antiga em vez da nova IU.

      • Problema 52863 resolvido: a IU do VMware SD-WAN Orchestrator permite configurações do temporizador BGP não padrão e não apresenta nenhum erro.

        Ao ativar a configuração de handoff de Parceiro na página de configuração do cliente, quando um utilizador configura temporizadores de retenção/suspensão de BGP no Orchestrator que não cumprem com a norma BGP em RFC 4271, o Orchestrator permite que a configuração seja guardada. No entanto, no próprio VMware SD-WAN Edge, o FRR altera os valores de retenção/suspensão para cumprir com as normas. Por exemplo, se um utilizador configurar um valor de retenção de 2 segundos/suspensão de 5 segundos no Orchestrator, o Edge FRR alterará o valor de retenção para 1 segundo, ou seja, 3 x o valor de retenção = (menor ou igual a suspensão).

      • Problema 55819 resolvido: quando um VMware SD-WAN Edge tem o COS ativado com policiamento e precedência rigorosas, a largura de banda da ligação permanece inutilizada quando a percentagem da largura de banda total é inferior a 100.

        A largura de banda é composta como uma percentagem direta (em comparação a um rácio), que resulta em largura de banda não utilizada na ligação. Na versão 4.5.0, o VMware SD-WAN Orchestrator apresenta uma mensagem pop-up que alerta os utilizadores de que a ligação pode não ser totalmente utilizada quando estão ativados policiamento e precedência rigorosos.

      • Problema 59106 resolvido: o comprimento do nome de utilizador não pode afetar a visualização da página na IU do VMware SD-WAN Orchestrator.

        Se um utilizador criar um novo administrador com um nome de utilizador excecionalmente longo (por exemplo, configureconfigureconfigureconfigureconfigure@vmware.com), a página do utilizador não se irá ajustar ao comprimento do nome de utilizador e será apresentada incorretamente, o que resulta na impossibilidade de ver o nome do utilizador corretamente.

      • Problema 59606 resolvido: os utilizadores veem ícones de diferentes tamanhos quando estes deveriam ser uniformes ao utilizar a nova IU do VMware SD-WAN Orchestrator.

        Se um utilizador navegar para qualquer página que contenha ícones, por exemplo, a lista de Edges, vê ícones com o tamanho errado.  Os ícones permanecem utilizáveis, apenas têm um tamanho incorreto.

      • Problema 59611 resolvido: na nova IU do VMware SD-WAN Orchestrator, o utilizador tem dificuldade em utilizar a tabela Alterar segmentos de perfil (Change Profile Segments) se a tabela tiver muitas linhas.

        Navegue para Configurar > Lista de perfis (Configure > Profiles List) e selecione qualquer perfil que tenha muitos segmentos.  Em seguida, abra o menu pendente do segmento e clique em “Alterar segmentos de perfil” (Change Profile Segments).  O utilizador irá verificar que a tabela é difícil de utilizar.

      • Problema 60428 resolvido: na IU do VMware SD-WAN Orchestrator, a monitorização ativa apresenta o dobro dos valores reais caso a caixa de verificação Mostrar detalhes TCP/UDP (Show TCP/UDP Details) não for selecionada.

        Este problema é observado quando o utilizador abre o separador Monitorizar Edge > Ligações (Monitor Edge > Links) e ativa o Modo ativo (Live Mode), mas opta por não mostrar TCP/UDP.  Neste caso, o utilizador irá ver valores de métricas em duplicado.

      • Problema 61529 resolvido: ao utilizar a nova IU no VMware SD-WAN Orchestrator, a eliminação dos modelos do VMware SD-WAN Edge de uma lista de perfis não funciona corretamente.

        Ao editar que modelos Edge se aplicam a um perfil, a remoção de um modelo Edge da lista deve remover o mesmo bloco da interface do Edge das definições do dispositivo. No entanto, caso sejam eliminados todos os Edges da lista de perfis, o bloco de interface irá permanecer para o último Edge eliminado na lista.

      • Problema 61852 resolvido: a página Monitorizar > Registos de Firewall (Monitor > Firewall Logs) na nova IU não apresenta informações corretas de paginação.

        A contagem de linhas de página está incorreta para esta secção.

      • Problema 62145 resolvido: quando um VMware SD-WAN Orchestrator é atualizado para a versão 4.2.1 a partir de versões anteriores, a migração falha, indicando um erro de interrupção de restrição único. Isto está no campo “logicalId” na tabela do dispositivo cliente.

        A versão 4.2.1 tem uma operação de longa duração que é executada durante a migração e que adiciona “logicalId” à tabela do dispositivo cliente. Esta operação só é realizada com base numa consulta de pré-condição. Esta consulta de pré-condição estava incorreta, o que fez com que o campo logicalId estivesse vazio. A adição de uma restrição no campo logicalId provocou um erro de duplicação, dado que mais de 1 linha era composta por logicalId como uma cadeia vazia.

        Sem a correção, a única solução alternativa para isso é, na migração, executar manualmente a consulta pendente de longa duração que irá adicionar um logicalId único a todas as linhas da tabela de dispositivo cliente e, em seguida, executar a consulta de restrição única.

      • Problema 62575 resolvido: o VMware SD-WAN Edge não cumpre a configuração do local de Destino Não-SD-WAN ou de Serviço de Segurança na Cloud (CSS) para segmentos não globais quando essas capacidades estão ativadas através de uma anulação específica ao Edge.

        Em alguns cenários de configuração incomuns (por exemplo, um caso em que o Serviço de Segurança na Cloud foi ativado exclusivamente num segmento não global através de uma anulação específica ao Edge), o Orchestrator computou incorretamente a configuração do plano de controlo do Edge para segmentos não globais.

      • Problema 63556 resolvido: o utilizador tem a opção de adicionar mais de um servidor TACACS na IU do VMware SD-WAN Orchestrator.

        Embora o utilizador possa adicionar mais de um servidor TACACS, esta não é uma configuração válida.  O motivo para tal é que, se o primeiro servidor TACACS falhar, o segundo servidor TACACS não vai assumir o controlo em qualquer situação.  A correção remove a opção para adicionar mais de um servidor TACACS.

      • Problema 64039 resolvido: em alguns casos, um cliente pode observar o seu servidor DHCP como inativo.

        O problema pode ser observado no seguinte cenário: após fornecer valores ao tipo de endereçamento, ative o servidor DHCP, atribua valores e clique no botão Atualizar (Update). Se o utilizador abrir o pop-up de subinterface, irá ver que o servidor DHCP aparece como inativo com todos os campos sob o servidor DHCP ocultos.

      • Problema 64930 resolvido: as mensagens de erro da API não são específicas para criar/atualizar/eliminar funções no VMware SD-WAN Orchestrator.

        As mensagens de erro nos registos de back-end do Orchestrator não são suficientes para a funcionalidade de função composta, o que impede um utilizador operador de identificar questões relacionadas com a gestão de funções. A correção melhora as mensagens de erro, especialmente nos problemas relativos às funções compostas do utilizador.

      • Problema 65069 resolvido: ao utilizar a nova IU no VMware SD-WAN Orchestrator, o utilizador não consegue dizer em que separador está porque o separador ativo não é realçado.

        Este é um problema cosmético sem impacto na funcionalidade. Mas o utilizador não consegue olhar simplesmente para a faixa superior e confirmar a sua localização na IU.

      • Problema 65199 resolvido: ao percorrer a página Monitorizar > Eventos (Monitor > Events) na nova IU do VMware SD-WAN Orchestrator, a última página apresenta uma faixa “Os dados de grelha foram alterados” (Grid Data has changed).

        A nova IU utiliza a paginação da página Monitorizar > Eventos (Monitor > Events).  É apresentada uma faixa “Os dados de grelha foram alterados” (Grid Data has changed) na última página porque há um erro de correspondência de eventos quando estes são ordenados com base num atributo de carimbo de data/hora em alguns casos.

      • Problema 65253 resolvido: ao configurar uma regra de firewall, a lista pendente Grupos de objetos (Object Groups) fica inutilizável na IU do VMware SD-WAN Orchestrator quando são configurados mais de 20 grupos.

        Mesmo com mais de 5 grupos de objetos (Grupo de endereços, Grupo de portas) configurados, a lista pendente Grupos de objetos (Object Groups) é apresentada perto da parte inferior do ecrã do browser.  Com mais de 20 regras, a lista Grupos de objetos (Object Groups) fica completamente fora do ecrã e é impossível vê-la a menos que o utilizador faça bastante zoom no browser, mas, aí, o texto é tão pequeno que também é inutilizável.

      • Problema 65266 resolvido: ao visualizar a página Segmentos (Segments) na nova IU do VMware Orchestrator, o esquema não está alinhado.

        Trata-se de um problema cosmético sem impacto funcional para o utilizador, mas o esquema está quebrado e os itens da IU não estão alinhados como seria suposto.

      • Problema 65526 resolvido: o VMware SD-WAN Orchestrator gera Alertas e Eventos para um VMware SD-WAN Edge num estado “Degradado” que nunca atinge um estado “Offline/Inativo”.

        Quando um VMware SD-WAN Edge perde inicialmente a conetividade ao Orchestrator (numa verificação de heartbeat), estado é designado “Degradado”.  Se a perda de conetividade do Edge ao Orchestrator continuasse, o Edge seria, em seguida, marcado como Offline/Inativo e este segundo estado ocorreria quando um Evento “Edge inativo” (Edge Down) fosse publicado na página Monitorizar > Eventos (Monitor > Events) do Orchestrator e um Alerta correspondente fosse enviado conforme adequado para a configuração de Alertas de um cliente.  No entanto, o Orchestrator está a gerar um Evento e a enviar um Alerta para um Edge num estado Degradado, o que resulta num número possivelmente grande de Eventos de Edge inativo e notificações de Alertas indevidos para o cliente.

      • Problema 65381 resolvido: o utilizador é capaz de criar funções personalizadas de utilizador composto, apesar do RADIUS ter sido ligado.

        As funções compostas ao nível do cliente só devem ser criadas para modos de autenticação que não o RADIUS, uma vez que a autenticação RADIUS está ao nível do Orchestrator e não pode haver funções específicas em cada empresa. A correção adiciona uma validação para prevenir estes casos.

      • Problema 65558 resolvido: a tentativa de configurar e guardar as definições Syslog falha com um erro no VMware SD-WAN Orchestrator. 

        O problema ocorre quando a interface de origem VLAN está configurada. O problema não é apresentado ao escolher uma porta encaminhada como interface de origem.

      • Problema 65748 resolvido: o BGP é validado ao nível do perfil mesmo quando está desligado.

        Agora as interfaces de origem podem ser ligadas ao BGP. Quando está ligado, mas o perfil BGP está desligado e, se a interface de origem for alterada, será atualmente emitido um erro, mas idealmente não deveria fazê-lo.

      • Problema 65760 resolvido: quando um utilizador operador observa a página Diagnóstico de Orchestrator (Orchestrator Diagnostics) na IU do VMware SD-WAN Orchestrator, o utilizador nota que a secção Informação de armazenamento da base de dados (Database Storage Info) tem vários grupos de dados em falta.

        Faltam as seguintes secções em Armazenamento de base de dados (Database Storage): Lista de Processos de base de dados (Database Process List); Variável de estado da base de dados (Database Status Variable); Variável do sistema da base de dados (Database System Variable); Estado do motor da base de dados (Database Engine Status).

      • Problema 65794 resolvido: para um cliente com um número excecionalmente grande de Edges que também utilizam Destinos Não VMware SD-WAN, a página Monitorizar > Serviços (Monitoring > Services) no VMware SD-WAN Orchestrator pode exceder o limite de tempo devido ao número de registos que têm de ser recuperados.

        Por exemplo, se um cliente tiver perto de 200 000 ou mais registos Edge com a etiqueta EDGE_NVS_TUNNEL, ao carregar a página /monitorizar/serviços (/monitor/services), esta devolve mais de 200 000 linhas. Em seguida, a IU recupera apenas o registo Edge mais recente para cada túnel, agrupa-o por fornecedor e apresenta o estado do túnel em Sites de Serviços de Segurança na Cloud (Cloud Security Service Sites). Os dados de resposta também são utilizados depois de clicar no evento quando o cliente quer ver o histórico do estado do túnel ser alterado.

      • Problema 66011 resolvido: o método linkQualityEvent/getLinkQualityEvents da API do portal do VMWare SD-WAN Orchestrator opera de forma não determinante no modo “verboso”.

        O método linkQualityEvent/getLinkQualityEvents da API do Orchestrator suporta uma opção “individualScores” que permite aos clientes pedir opcionalmente informações mais detalhadas sobre a ligação QoE na resposta da API. Este método opcional produz informações detalhadas por amostra de série de tempo (que é lenta e tem um desempenho de produção intensivo) no resultado. O valor predefinido deste parâmetro é falso, para evitar que este desempenho seja atingido. No entanto, o problema aqui é que o servidor reporta esta informação de forma não determinante, mesmo nos casos em que o cliente não a solicitou especificamente e o desempenho do assistente é afetado.

      • Problema 66038 resolvido: o utilizador vê gráficos ligados entre os pontos onde não houve tráfego na IU do VMware SD-WAN Orchestrator.

        Isto é verdade para qualquer uma das versões da IU, nova ou original. Ao monitorizar os dados de tráfego do cliente, o gráfico não capturará quando não há tráfego, em vez disso liga os pontos de dados nulos. Assim, ao ver um gráfico, o utilizador veria dados errados sobre o tráfego.

      • Problema 66203 resolvido: quando um conjunto de Gateways é atribuído a um cliente que contém Gateways de parceiro e Gateways alojados na cloud, o parceiro não consegue modificar a configuração de handoff do Gateway para os seus Gateways geridos.

        O problema ocorre quando o utilizador administrador de um Parceiro tenta modificar a configuração de handoff de Gateway no separador Cliente (Customer) presente na página dos clientes.

      • Problema 66236 resolvido: A resposta da API para o “WAN module” /edge/getEdgeConfigurationModules não está em conformidade com o esquema JSON documentado.

        Se o utilizador comparar a resposta da API para “/edge/getEdgeConfigurationModules” com o esquema documentado, a propriedade PrivateNetwork estará em falta para os dados WAN.

      • Problema 66276 resolvido: quando a Elevada Disponibilidade é configurada num VMware SD-WAN Edge substituindo uma interface no nível Edge, o VMware SD-WAN Orchestrator não permite que um utilizador faça quaisquer novas alterações nas definições do dispositivo de perfil, emitindo o erro “Edge b2-edge1: a interface GE1 é exigida para ser o tipo para mudar para o modo autónomo pela HA do par” (Edge b2-edge1: Interface GE1 is required to be type of switched for the stand by pair HA).

        Este problema tem um impacto importante num utilizador que necessite de alterar uma configuração de perfil, uma vez que bloqueia todas as alterações. A correção deste problema permite que os utilizadores modifiquem as definições do dispositivo de perfil quando o Edge tiver substituído a configuração do perfil para configurar HA.

      • Problema 66597 resolvido: num VMWare SD-WAN Orchestrator onde existe um cliente com um número muito elevado de Edges implementados, ao serem adicionados vários VMware SD-WAN Gateways a um conjunto de Gateways que o cliente está a utilizar, um grande número de Edges pode ser apresentado como inativo no Orchestrator.

        Este problema foi observado no terreno com um cliente que tinha ~7000 Edges ligados ao Orchestrator. Quando existe uma alteração no conjunto de Gateways desse cliente, o Orchestrator tem de emitir as alterações de configuração para todos os Edges e os novos cálculos do plano de controlo para mais de 700 Edges numa janela de 30 segundos faz com que as emissões de heartbeats/estatísticas falhem com o erro “POOL_ENQUEUELIMIT”. Devido a falhas de heartbeat, os Edges são apresentados como inativos no Orchestrator.

      • Problema 66631 resolvido: a Ferramenta de migração não funciona ao tentar migrar grandes clientes empresariais.

        Um grande cliente empresarial é definido como um com 100 ou mais Edges. A ferramenta de migração irá falhar no passo onde é suposto encadear todo o blob de dados e escrever para um ficheiro. Ao realizar a exportação da configuração, a ferramenta de migração estava a utilizar JSON.stringify para encadear os dados de saída e escrevê-los para o ficheiro, o que irá falhar quando a configuração tem dimensões muito elevadas.

      • Problema 66636 resolvido: o VMware SD-WAN Edge não cumpre a configuração da interface de origem para o tráfego de autenticação RADIUS quando a origem é uma interface de retorno.

        Quando um utilizador configura o RADIUS num Perfil ou Edge e especifica uma interface de retorno como a interface de origem pretendida para o tráfego de autenticação de saída, o Edge não cria uma regra NAT como esperado devido a um erro de análise decorrente de uma inconsistência no tipo esperado em comparação com o tipo real do parâmetro “porta” para o serviço de autenticação que é distribuído a partir do VMware SD-WAN Orchestrator. Este valor deve ser um número inteiro e a lógica de validação da API do Orchestrator foi alterada em conformidade.

      • Problema 67153 resolvido: os e-mails de alerta estão a ser enviados mesmo quando o VMware SD-WAN Edge reagiu dentro do intervalo de atraso configurado.

        O VMware SD-WAN Orchestrator envia notificações de Edge inativo/ativo, mesmo que os eventos tenham ocorrido dentro do intervalo de atraso configurado.

      • Problema 67701 resolvido:  ao configurar uma regra de política empresarial, a lista pendente Grupos de objetos (Object Groups) não é visível na IU do VMware SD-WAN Orchestrator quando são configurados mais de 20 grupos.

        Mesmo com mais de 5 grupos de objetos (Grupo de endereços, Grupo de portas) configurados, a lista pendente Grupo de objetos (Object Group) é apresentada perto da parte inferior do ecrã do browser.  Com mais de 20 regras, a lista Grupos de objetos (Object Groups) fica completamente fora do ecrã e é impossível vê-la a menos que o utilizador faça bastante zoom no browser, mas, aí, o texto é tão pequeno que também é inutilizável.

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

        A causa impede o Orchestrator de obter o espaço livre no disco necessário para a recuperação de desastres e, por conseguinte, a recuperação de desastres pode falhar.

      • Problema 71399 resolvido: num VMware SD-WAN Orchestrator implementado numa configuração de recuperação após desastre (DR), o utilizador operador pode observar que o Orchestrator em standby não conseguiu sincronizar com o Orchestrator ativo.

        Na IU do Orchestrator na página Replicação (Replication), um utilizador iria observar todas as atividades de sincronização como falhadas no Monitor de atividade (Activity Monitor). A falha de sincronização DR ocorre no handshake inicial em que o Orchestrator ativo não consegue copiar a base de dados de configuração para o Orchestrator em standby.

      Problemas resolvidos do Cloud Web Security

      Resolvidos na versão R450-20210922-GA

      Os problemas abaixo foram resolvidos desde a versão R440-20210702-GA-61583 do Edge.

      • Problema 62978 resolvido: 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 falhar e, caso isso aconteça, o utilizador poderá ver um ecrã de erro que não tem a marca VMware.

        No cenário acima em que uma transferência de ficheiros falha (que é abordado no problema n.º 62934), o ecrã de erro “Ocorreu um erro. Contacte o administrador” (Error occurred contact your administrator) deveria mostrar a marca VMware, mas, em vez disso, não mostra nenhuma marca. Se um utilizador se deparar com este erro, deverá perceber que este não é um resultado esperado.

        Sem a correção, a solução alternativa é permitir cookies de terceiros no browser.

      • Problema 64429 resolvido: numa empresa de clientes que utiliza o VMware Cloud Web Security, onde uma política do Cloud Web Security está configurada e é aplicada através do backhaul de Internet, uma transferência UDP para um servidor na Internet, iniciada por um cliente por trás do Edge, com um bit DF definido, irá falhar.

        O Cloud Web Security receberá pacotes de tamanho MTU, mas terá de enviar uma mensagem inalcançável ICMP de volta ao remetente, uma vez que a fragmentação não é permitida devido ao bit Não fragmentar (DF) definido. O Cloud Web Security está a executar o DNAT (tradução de endereços de rede de destino) para o endereço IP de origem errado e está a enviar uma mensagem “ICMP inalcançável, fragmentação necessária” (ICMP unreachable fragmentation needed) ao cliente, em vez de a enviar de volta para o servidor.

      • Problema 65115 resolvido: para um cliente que utilize o VMware Cloud Web Security, se a autenticação SAML estiver configurada, o utilizador poderá não ter acesso a nenhum site.

        Com a autenticação SAML (Security Assertion Markup Language) ativada, se um utilizador aceder a qualquer site, tal resultará num ciclo de autenticação onde o acesso ao IdP (Fornecedor de identificação) requer autenticação e falha.

        Sem a correção, a solução alternativa é adicionar uma Exceção SSL na política de segurança para permitir o acesso ao URL de início de sessão do IdP sem autenticação.

      • Problema 72485 resolvido: para um cliente que utiliza o Cloud Web Security, sempre que o cliente edita a Regra de exceção do CASB existente e altera a aplicação selecionada no Assistente, todos os controlos de aplicações foram definidos como “permitidos”.

        O assistente da Regra de exceção do CASB no VMware Orchestrator não mantém os valores de controlo existentes após a alteração de uma aplicação selecionada.

      Problemas resolvidos do Secure Access

      Resolvidos na versão R450-20210922-GA

      Os problemas abaixo foram resolvidos desde a versão R440-20210702-GA-61583 do Edge.

      • Problema 62421 resolvido: ao utilizar o Secure Access, o tráfego para os recursos pode falhar se uma sub-rede estiver em conflito com um caminho existente trocado por/associado a uma sub-rede em conflito.

        O tráfego do Secure Access para os recursos irá falhar se a sub-rede escolhida para o Secure Access estiver em conflito com uma sub-rede de cliente interna existente. Isto deve-se à falta de verificação de intervalos de IP em conflito no serviço Secure Access.

      Problemas conhecidos

      Problemas em aberto na versão 4.5.0

      Os problemas conhecidos são agrupados da seguinte forma.

      Problemas conhecidos do Edge/Gateway
      • Problema 14655:

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

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

      • Problema 25504:

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

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

      • Problema 25595:

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

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

      • Problema 25742:

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

      • Problema 25758:

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

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

      • Problema 25855:

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

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

      • Problema 25921:

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

      • Problema 25997:

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

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

      • Problema 26421:

        O Gateway de parceiro primário para qualquer 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 não podem ser retirados corretamente quando o caminho está desligado. Ativar e desativar novamente o caminho vai retraí-lo com sucesso. 

      • Problema 32960:

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

      • Problema 32981:

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

      • Problema 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 35807:

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

      • Problema 36923:

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

      • Problema 38682:

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

      • Problema 38767:

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

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

      • Problema 39134:

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

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

      • Problema 39374:

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

      • Problema 39608:

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

      • Problema 39624:

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

      • Problema 39659:

        Num 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 utilizando Ramo-a-Ramo Dinâmica sejam atrasados.

      • Problema 40096:

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

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

      • Problema 40421:

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

      • Problema 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 ativar novamente a interface no VMware SD-WAN Orchestrator.

      • Problema 42488:

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

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

      • Problema 42872:

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

      • Problema 43373:

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

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

      • Problema 44995:

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

      • Problema 45189:

        Com o NAT do lado LAN de origem configurado, o tráfego de um 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 Ramo a Ramo através da VPN do Hub está desativado, tentar inverter o sentido do tráfego de ramo-a-ramo com um caminho resumido num switch/router L3 provocará ciclos de routing.

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

      • Problema 47681:

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

      • Problema 47787:

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

      • Problema 48166:

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

      • Problema 48175:

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

      • Problema 48502:

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

      • Problema 48530:

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

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

      • Problema 48597: a vizinhança BGP multihop não ficará ativa se um dos dois caminhos para o par ficar inativo

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

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

      • Problema 48666:

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

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

      • Problema 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 50518:

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

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

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

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

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

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

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

        Solução alternativa: este problema persistirá até que o 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 a preferência correta e anunciar valores quando o sinalizador DCC está ativado provocando uma sequência de ordenação incorreta no FIB do Edge.

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

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

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

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

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

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

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

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

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

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

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

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

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

        Solução alternativa: a solução 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 ativadas, o Edge criará internamente dois objetos de ligação diferentes. Os valores de largura de banda são adicionados para ambos quando deveriam ser adicionados apenas para um.

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

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

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

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

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

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

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

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

        Entende-se por um grande número de Edges Spoke ~1000 ou mais. Este problema não é consistente, mas, geralmente, ~1/3 dos túneis do Protocolo de gestão do VeloCloud (VCMP) não são estabelecidos entre o Edge Hub e os Edges Spoke ligados. Isto é causado pelo 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        Se o site se tornar Ativo-Ativo, uma configuração HA convencional sofrerá uma disrupção mínima no tráfego, dado que o Edge em standby não passa tráfego nesta topologia, mas numa implementação HA melhorada, onde o Edge em standby também está a passar tráfego, os reinícios perturbarão algum tráfego do cliente.

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

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

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

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

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

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

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

      Problemas conhecidos do Orchestrator
      • Problema 19566:

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

      • Problema 21342:

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

      • Problema 24269:

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

      • Problema 25932:

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

      • Problema 32335:

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

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

      • Problema 32435:

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

      • Problema 32856:

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

      • Problema 32913:

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

      • Problema 33026:

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

      • Problema 34828:

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

      • Problema 35658:

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

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

      • Problema 35667:

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

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

      • Problema 36665:

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

      • Problema 38056:

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

      • Problema 38843:

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

      • Problema 39633:

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

      • Problema 39790:

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

      • Problema 40341:

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

      • Problema 41691:

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

      • Problema 43276:

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

      • Problema 47269:

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

      • Problema 47713:

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

      • Problema 47820:

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

      • Problema 48085:

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

      • Problema 48737:

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

      • Problema 49225:

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

      • Problema 49790:

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

        Solução alternativa: ignore o evento duplicado.

      • Problema 50531:

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

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

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

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

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

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

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

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

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

      • Problema 60522: na IU do VMware 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 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.

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

      Problemas conhecidos do Cloud Web Security
      • Problema 62934: para uma empresa que utiliza o VMware Cloud Web Security, se um utilizador cliente abrir um browser Chrome no modo de navegação anónima e tentar transferir um ficheiro, a transferência pode, ocasionalmente, não ser bem-sucedida.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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