Atualizado a 9 de novembro de 2022

VMware SASE™ Orchestrator versão R5002-20220517-GA
VMware SD-WAN™ Gateway versão R5002-20220506-GA
VMware SD-WAN™ Edge versão R5002-20220506-GA
VMware Cloud Web Security™ com a versão R5002-20220517-GA do Orchestrator
VMware Secure Access™ com a versão R5002-20220517-GA do Orchestrator
VMware Edge Network Intelligence™ com a versão R5002-20220517-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 5.0.0.

Compatibilidade

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

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

Orchestrator

Gateway

Edge

Hub

Ramo/Spoke

5.0.0

4.2.0

4.2.1 e 4.2.2

4.2.1 e 4.2.2

5.0.0

5.0.0

4.2.1 e 4.2.2

4.2.1 e 4.2.2

5.0.0

5.0.0

5.0.0

4.2.1 e 4.2.2

5.0.0

5.0.0

4.2.1 e 4.2.2

5.0.0

5.0.0

R3.4.5

3.4.5 e 3.4.6

3.4.5 e 3.4.6

5.0.0

5.0.0

3.4.5 e 3.4.6

3.4.5 e 3.4.6

5.0.0

5.0.0

5.0.0

3.4.5 e 3.4.6

5.0.0

5.0.0

3.4.5 e 3.4.6

5.0.0

5.0.0

4.3.0

4.3.0

4.3.0

5.0.0

5.0.0

4.3.0

4.3.0

5.0.0

5.0.0

5.0.0

4.3.0

5.0.0

5.0.0

4.3.0

5.0.0

5.0.0

4.5.0

4.5.0

4.5.0

5.0.0

5.0.0

4.5.0

4.5.0

5.0.0

5.0.0

5.0.0

4.5.0

5.0.0

5.0.0

4.5.0

5.0.0

5.0.0

4.5.0

5.0.0

4.5.0

5.0.0

3.2.2

3.2.2

3.2.2

5.0.0

5.0.0

3.2.2

3.2.2

5.0.0

5.0.0

5.0.0

3.2.2

5.0.0

3.3.2 P2

3.3.2 P2

3.3.2 P2

5.0.0

5.0.0

3.3.2 P2

3.3.2 P2

5.0.0

5.0.0

3.3.2 P2

5.0.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 ou posterior.

Aviso: as versões 3.2.x e 3.3.x do VMware SD-WAN chegaram ao fim do suporte.

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

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

  • A versão 3.4.x do Orchestrator e do Gateway chegou ao fim do suporte geral (EOGS) a 30 de março de 2022 e chegará ao fim da orientação técnica (EOTG) a 30 de setembro de 2022.
  • Nota: Diz apenas respeito ao Orchestrator e ao Gateway. A versão 3.4.x do Edge está agendada para chegar ao fim do suporte a partir de 31 de dezembro de 2022.
  • Para mais informações, consulte o artigo da Base de Dados de Conhecimentos: Anúncio: fim do período de suporte para a versão 3.x (84151) do VMware SD-WAN

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

  • A versão 4.0.x chegará ao fim do suporte geral (EOGS) a 30 de setembro de 2022 e ao fim da orientação técnica (EOTG) a 31 de dezembro de 2022. 
  • A versão 4.2.x dos Orchestrators e dos Gateways chegará ao fim do suporte geral (EOGS) a 30 de dezembro de 2022 e ao fim da orientação técnica (EOTG) a 30 de março de 2023.   
  • A versão 4.2.x dos Edges chegará ao fim do suporte geral (EOGS) a 30 de junho de 2023 e ao fim da orientação técnica (EOTG) a 30 de setembro de 2023.
  • Para mais informações, consulte o artigo da Base de Dados de Conhecimentos: Anúncio: fim do período de suporte para a versão 4.x (88319) do VMware SD-WAN

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

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

Seguem-se os caminhos para os clientes que pretendem atualizar o Orchestrator, o Gateway ou o Edge de uma versão mais antiga para a versão 5.0.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 5.0.0. Os Orchestrators que utilizam a versão 4.0.0 ou posterior podem ser atualizados para a versão 5.0.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 → 5.0.0.

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

Gateway

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

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

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

Edge

Um Edge pode ser atualizado diretamente para a versão 5.0.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.

Atualização do AWS Edge não suportada na versão 5.0.0

 Um VMware SD-WAN Virtual Edge que utiliza uma instância AWS C4 não pode ser atualizado para a versão 5.0.0 devido ao Problema pendente 82264 do Edge. Para este problema, quando um AWS C4 Virtual Edge é atualizado para a versão 5.0.0, o Edge não recupera e não existe uma forma de remediar o estado do Edge para além de reativar o Edge para uma versão que não seja a 5.0.0.  Nenhuma outra instância AWS (por exemplo, C5) é afetada por este problema.

No entanto, devido à natureza crítica deste defeito, não está disponível um pacote de software de Atualização AWS Edge para a versão 5.0.0. O problema 82264 foi resolvido em todas as compilações da versão 5.0.1 e inclui um pacote do AWS Edge Upgrade. 

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

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

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

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

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

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

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

  • d = Compilação rollup (por exemplo, 5.2.1.1) → Um rollup é um agregado cumulativo de correções de defeitos conhecidos encontrados pelos clientes ou defeitos críticos encontrados internamente.

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

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

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.

Aceder ao Cloud Web Security e ao Secure Access

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

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

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

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

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

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

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

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

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

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

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

Novas funcionalidades do SD-WAN

IPv6

A versão 5.0.0 fornece suporte para as seguintes funcionalidades IPv6:

  • Overlay IPv6
    • O cliente tem a opção de configurar o overlay definido pelo utilizador para Apenas IPv4, Apenas IPv6 ou IPv4 e IPv6 (Dual-Stack)
    • O modo Dual-Stack impede a sobresubscrição da ligação ao ter em conta o tráfego do IPv4 e do IPv6 através da mesma ligação.
  • E-mail de ativação do Edge IPv6
    • O E-mail de ativação do Edge pode agora ser enviado com uma ligação de ativação do IPv4 e/ou IPv6.
    • As hiperligações de ativação IPv6 são apenas para implementações de Greenfield.
  • Controlo de fluxo de overlay IPv6
    • O Edge mantém tabelas IPv4 e IPv6 separadas com pesquisas de caminho separadas.
    • O Cálculo dinâmico de custos (DCC) é ativado por predefinição com o IPv6
    • Inclui uma opção para Atualização de Caminhos Estáticos IPv6
  • Política empresarial do IPv6
    • As políticas empresariais têm agora um parâmetro de configuração de versão IP para IPv4, IPv6 ou IPv4 e IPv6
    • As opções IPv4 e IPv6 permitem correspondências por VLAN, Interface, Portas e Grupos de Objetos.
    • As políticas empresariais predefinidas são atualizadas automaticamente para IPv4 e IPv6 com a versão 5.0.0
    • Nota: algumas aplicações não têm suporte para IPv6, incluindo Skype, Zoom, GoToMeeting, Sharepoint e VMware Horizon, entre outras
  • Firewall com estado IPv6:
    • As Regras de Firewall com estado podem ser criadas para IPv4, IPv6 ou IPv4 e IPv6
    • A página de configuração inclui um campo de endereço IP melhorado que suporta endereços IPv6
  • IPv6 NAT
    • Tradução de prefixo de rede IPv6-para-IPv6 (NAT66) por predefinição em SD-WAN Gateways
    • 1:1 NAT IPv6 mapeia um endereço público IPv6 específico para um endereço LAN IPv6 específico
    • 1:1 IPv6 NAT pode traduzir endereços IPv6 externos em diferentes sub-redes da interface WAN se o ISP encaminhar o tráfego para a sub-rede em direção ao Edge SD-WAN
    • Encaminhamento de porta com endereço IPv6
  • Handoff de Gateway de Parceiro com BGPv6 e BFDv6
    • Suporta filtros BGPv6 de entrada e saída
    • O parceiro tem opções de configuração IPv4 e IPv6
    • Os caminhos IPv6 aprendidos através de BGP são sincronizados com o Controlo de Fluxo de Overlay
    • Esta funcionalidade só pode ser configurada na IU clássica com a versão 5.0.0

Edge Factory Software e Atualizações de firmware no VMware SD-WAN Edge

A partir da versão 5.0.0, os componentes da plataforma SD-WAN Edge podem ser atualizados fora do software de imagem do Edge. Um Edge 5.0.0 ligado a um Orchestrator 5.0.0 permite ao parceiro ou administrador de clientes gerir o firmware da plataforma e atualizar a imagem predefinida de fábrica do Edge.

Acesso seguro ao edge + CLI

O Acesso seguro ao edge + CLI fornece um método seguro para suportar o acesso CLI a Edges com pares de chaves gerados pelo utilizador e envia um utilizador com sessão registada numa shell Edge CLI que apenas expõe comandos de resolução de problemas SD-WAN e cumpre os requisitos de CSO.

Tanto o Edge como o Orchestrator devem estar a utilizar a versão 5.0.0 ou posterior para que esta funcionalidade esteja disponível.

Melhorias de funcionalidades do SD-WAN

Correspondência de origem da firewall

Na Versão 4.x e anterior, ao configurar uma regra de firewall, o utilizador tinha de selecionar entre uma interface ou um endereço IP nos critérios de correspondência de Origem, mas não ambos. Na versão 5.0.0, um utilizador pode agora configurar uma regra tanto para a interface como para o endereço IP, de modo que possa fazer corresponder um endereço IP específico na interface de entrada.

Localização para grego

A versão 5.0.0 adiciona a localização para o idioma grego do Orchestrator e da documentação do SD-WAN e SASE.

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 usar para inspecionar o tráfego
  • Dicionários personalizados podem ser configurados com cadeias ou expressões regulares
  • A atividade que não esteja em conformidade é reportada aos administradores designados

Nota: a funcionalidade DLP também está disponível na versão 4.5.0/4.5.1, começando com a compilação do VMware SASE Orchestrator R450-20220315-GA

Novas funcionalidades do Edge Network Intelligence

Redes de autorrecuperação

As Redes de autorrecuperação tiram partido do Edge Network Intelligence e do SD-WAN para remediar problemas de rede em tempo real. A funcionalidade Redes de autorrecuperação analisa as condições globais, deteta a degradação em tempo real e proporciona ao cliente uma ação corretiva recomendada que o cliente tem a opção de seguir.

Incidentes de rede em que o desempenho da aplicação se degrada são automaticamente detetados quando se utiliza a autorrecuperação. A funcionalidade fornece então um relatório sobre o Incidente que fornece informações fundamentais, incluindo: Edges afetados, causas de raiz e outras aplicações impactadas. O Relatório de incidentes também fornece uma recomendação de reparação. Na implementação inicial da Autorrecuperação, o utilizador optaria manualmente por agir de acordo com a recomendação de remediação.

Quaisquer ações de reparação realizadas através do Edge Network Intelligence são automaticamente anotadas na página Histórico de Rede e incluem o número de Edges atualizados e a(s) aplicação(ões) impactada(s).

Ativar a Análise e autorrecuperação

Anteriormente, a Análise do Edge Network Intelligence tinha de ser ativada um Edge de cada vez. Na nova IU, um utilizador pode selecionar vários Edges e configurar as definições de análise para ativar apenas a análise ou a análise + autorrecuperação.

Alterações à API do Orchestrator desde a versão 4.5.0

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

O Registo de alterações da API completo está disponível para transferência em developer.vmware.com (ver: “API do VMware SD-WAN Orchestrator v1”).

As seguintes alterações podem exigir ações dos programadores:

  • Os módulos de configuração de dispositivos, QOS e firewall foram aumentados com novas opções de configuração para suportar o IPv6. 
  • Algumas destas definições são introduzidas através de um patch de sistema na atualização do Orchestrator para a versão 5.0.0 e são tratadas conforme exigido pelo servidor após a atualização. Os utilizadores que dependem de perfis de “modelo” terão de atualizar esses perfis para incluir as novas definições necessárias.
  • O esquema revisto para cada um destes módulos está documentado na referência da API (ver “segmentBasedDeviceSettings”, “firewall” e “QOS” na secção de módulos da referência na parte inferior da página).
  • Com a introdução do suporte para a configuração do firmware dos componentes da plataforma Edge de forma independente do software (ver “Edge Factory Software e Atualizações de firmware no VMware SD-WAN Edge”), a API exige agora que as seguintes propriedades estejam presentes no módulo de configuração “data” de imageUpdate: “devicefamily”, “modemFirmware”, “platformFirmware” e “factoryFirmware”. Este módulo é exclusivo dos Perfis do operador, e a alteração não deve ter impacto nas aplicações do cliente em causa com Perfis do cliente ou definições específicas do Edge.
  • 76036: Adiciona lógica de validação a todos os métodos /métricas/* que fazem com que a API responda com um erro nos casos em que o intervalo de consulta precede o início da janela de retenção global do sistema (2 semanas para “estatísticas de estado de funcionamento” do Edge, 40 semanas para todos os outros tipos de métricas, por predefinição). Anteriormente, o servidor cumpriu estas consultas, mas devolveu dados incompletos.
  • 74050: Remove uma propriedade “vlanId” redundante (que não foi utilizada pelo Edge) de opções de endereçamento específicas do IPv6 (o objeto “v6detail”) para interfaces encaminhadas contidas nos módulos de configuração deviceSettings de Perfil e Edge.
  • 69028: Introduz validação que impede os Administradores de clientes de invocarem enterprise/reassignDataCenterGateway (que altera o Gateway designado para túnel para um site de destino que não é SD-WAN) a menos que o portal de destino esteja no modo “desligado” (quiesced).
  • 64145: Causa uma pequena alteração no comportamento da API ao manusear atualizações para módulos de configuração de definições de dispositivos nos casos em que os gateways de handoff de parceiros são configurados, nos quais o servidor irá cumprir sempre as atribuições de gateway especificadas em “segmentos[] > gatewaysHandoff > listaGateways” (segments[] > handOffGateways > gatewaysList”) em relação às especificadas em “segmentos[] > GatewaysHandoff > listaGateways” (“segments[] > handOffGateways > gateways”), sempre que a propriedade anterior estiver presente. Anteriormente emitimos orientações para alguns utilizadores de que os “segmentos[] > gatewaysHandoff > gateways” (“segments[] > handOffGateways > gateways”) tinham de ser eliminados em alguns casos para acionar este comportamento, mas isso já não é necessário.

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

Esta versão adiciona suporte para configuração de definições de perfil e dispositivo Edge, tais como HA, Wi-Fi, segurança na cloud, protocolos de routing e muito mais. Introduz as seguintes novas operações da API:

  • Para configuração de Perfis de cliente:
    • GET /enterprises/{enterpriseLogicalId}/perfis/{profileLogicalId}/deviceSettings
    • PATCH /enterprises/{enterpriseLogicalId}/perfis/{profileLogicalId}/deviceSettings
    • PUT /enterprises/{enterpriseLogicalId}/perfis/{profileLogicalId}/deviceSettings
  • Para a configuração de Edges específicos:
    • GET /enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/profiles/{profileLogicalId}/deviceSettings
    • PATCH /enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/profiles/{profileLogicalId}/deviceSettings
    • PUT /enterprises/{enterpriseLogicalId}/edges/{edgeLogicalId}/profiles/{profileLogicalId}/deviceSettings

Com estas operações da API, o VMware SASE introduziu algumas capacidades e padrões de design da API (por exemplo, suporte para atualizações parciais de recursos através de patch HTTP, manuseamento e relato consistente de erros de sintaxe e execução assíncrona por predefinição) que irá orientar a forma como os utilizadores executam muitas tarefas de gestão de configuração, com a funcionalidade adicional a ser introduzida em futuras versões.

Existem outras duas alterações que podem exigir ações por parte dos utilizadores da API:

  • Para normalizar as estruturas de URL em todo o conjunto mais amplo de serviços API da VMware SASE Platform (incluindo Cloud Web Security e Secure Access), o caminho de base canónica para SD-WAN “APIv2” é alterado nesta versão de “/sdwan” para “/api/sdwan/v2”. Para garantir a retrocompatibilidade com versões anteriores do software Orchestrator, o Orchestrator continua a honrar os pedidos para o caminho base “/sdwan”, desde que os clientes estejam configurados para seguir os redirecionamentos HTTP 308. Com base numa análise do tráfego da API, a maioria dos utilizadores não deve observar qualquer perturbação como resultado desta alteração. No entanto, recomendamos que todos os utilizadores da APIv2 comecem a utilizar o novo caminho básico de URL (/api/sdwan/v2) após a atualização para a versão 5.0.0 do Orchestrator (ou os utilizadores devem garantir que as aplicações e os scripts do cliente são configurados para seguir redirecionamentos HTTP). Não se esperam mudanças adicionais deste tipo.
  • Devido a um erro operacional, o módulo de limitação de taxas APIv2 não tem imposto a mesma política de incumprimento que o limitador de taxa de API do Portal, o que sempre foi a intenção. Uma mudança nesta versão afeta essa política para a APIv2. Os utilizadores devem rever as melhores práticas para evitar acionar o limitador de taxa e lidar com as respostas em que a limitação da taxa é acionada.

Alterações à documentação do programador

Historicamente, a documentação do VMware SASE/SD-WAN API encontrava-se em VMware {code} em code.vmware.com. O VMware {code} foi recentemente migrado para um novo domínio, developer.vmware.com. Como resultado da migração, alguns permalinks para páginas específicas que estavam anteriormente presentes em code.vmware.com podem deixar de funcionar como esperado.

Em conjunto com a migração, a VMware também lançou recentemente um novo Portal de Documentação do Programa em https://developer.vmware.com/apis, onde residem agora todas as documentações da API VMware SASE/SD-WAN.

Histórico de revisões do documento

28 de fevereiro de 2022. Primeira edição.

4 de março de 2022. Segunda edição.

  • Em Alterações da API do Orchestrator desde a versão 4.5.0, foi adicionado conteúdo à secção Alterações à API do Portal do VMware SD-WAN Orchestrator (“API v1”) sobre a capacidade de atualizar o firmware do Edge. O texto adicionado começa da seguinte forma: “Com a introdução do suporte para a configuração do firmware dos componentes da plataforma Edge de forma independente do software...”

17 de março de 2022. Terceira edição.

  • Foi adicionado o Problema resolvido 71745 aos Problemas resolvidos do Edge/Gateway da compilação GA R5000-20220225-GA. Foi anteriormente omitido, dado que não se encontrava anteriormente no campo.
  • 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”.

21 de março de 2022. Quarta edição.

  • Foi adicionada a Localização para grego da documentação do SASE à secção Melhoria de funcionalidades. Esta melhoria adiciona versões em PDF transferíveis da documentação principal do SASE (Notas de versão, SD-WAN, Cloud Web Security e Secure Access) que podem ser acedidas neste site.  

23 de março de 2022. Quinta edição.

  • Foi adicionada uma nova compilação R5001-20220317-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta compilação é a nova compilação GA do Orchestrator para a versão 5.0.0. Como lembrete, o quarto dígito representa uma compilação rollup e esta é a primeira compilação rollup do Orchestrator para a versão 5.0.0.
  • Foram adicionados os Problemas resolvidos 69573, 76994, 78688, 83538, 83550, 83582, 83902, 83940, 84083, 84286, 84297, 84299 e 84300 aos problemas resolvidos do Orchestrator da R5001-20220317-GA.
  • Os problemas dos Orchestrators corrigidos afetam os serviços VMware SASE da seguinte forma:
    • VMware SD-WAN: 78688, 83582, 83902 e 84083.
    • VMware Cloud Web Security: 76994, 83550, 83940, 84286, 84297, 84299 e 84300.
    • VMware Secure Access: 69573, 83538.
  • Foi adicionado o Problema 84825 à secção Problemas resolvidos do Edge/Gateway.

3 de maio de 2022. Sexta edição.

  • Foi adicionado um novo aviso na secção Compatibilidade relativamente à versão 4.0.x, que se aproxima do fim do suporte.
  • 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 5.0.0.

24 de maio de 2022. Sétima edição.

  • Foi adicionada uma nova compilação rollup R5002-20220506-GA do Edge/Gateway à secção Problemas resolvidos do Edge/Gateway. Esta é a nova compilação GA do Edge/Orchestrator para a versão 5.0.0.
  • A compilação R5002-20220506-GA do Edge/Gateway inclui as correções para os problemas 74316, 83209 e 87956, que se encontram documentados nesta secção.
  • Foi adicionada uma nova compilação R5002-20220517-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta compilação é a nova compilação GA do Orchestrator para a versão 5.0.0.
  • Foram adicionados os Problemas resolvidos 81960, 84600, 84969, 85291, 85338, 85412, 86083, 86573, 88796 e 89005 aos problemas resolvidos do Orchestrator da R5002-20220517-GA.
  • Os problemas dos Orchestrators corrigidos afetam os serviços VMware SASE da seguinte forma:
    • VMware SD-WAN: 84969, 85291, 85338, 86573 e 88796.
    • VMware Cloud Web Security: 81960, 84600, 85412, 86083 e 89005.
  • 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.
  • Foi adicionado o Problema pendente 88796 à secção Problemas conhecidos do Edge/Gateway. Este problema afeta os Orchestrators e os OVAs do Gateway, mas a correção para o Orchestrator está incluída na compilação R5002-20220517-GA.  A partir desta revisão, não existe qualquer OVA do Gateway com a correção do 88796.
  • Foi alterada a secção Problemas resolvidos do Edge/Gateway para adicionar o Problema resolvido 77525 para a R5000-20220225-GA, uma vez que o mesmo tinha sido omitido por engano.

1 de junho de 2022, oitava edição

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

16 de junho de 2022, nona 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.
  • Foi adicionado o Problema resolvido 53951 à secção Problemas resolvidos do Edge/Gateway. Este pedido foi omitido por engano das Notas de lançamento originais da versão 5.0.0.
  • Foi adicionado o Problema pendente 75348 à secção Problemas conhecidos do Orchestrator.

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

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

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

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

28 de julho de 2022. Vigésima primeira edição

  • As notas de versão foram revistas para eliminar todas as referências a 5.0.0.0 que não estão estritamente relacionadas com uma compilação do Orchestrator, Gateway ou Edge. As notas de versão são corretamente intituladas Notas de versão 5.0.0 do VMware SASE, uma vez que essa é a versão do software abrangida e o quarto dígito está reservado para compilações específicas desse software.

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

  • Foi adicionado o Problema resolvido 89217 à secção Problemas resolvidos do Edge/Gateway. Este registo foi adicionado à secção da compilação 5.0.0.0, pois é uma correção do firmware da plataforma que pode ser aplicada a um Edge que utilize qualquer compilação 5.0.0.

9 de novembro de 2022. Vigésima terceira edição.

  • Na secção Melhorias de funcionalidades do SD-WAN, a secção Localização para grego foi atualizada. A indicação: “Apesar de o Orchestrator efetuar a localização para grego automaticamente, existe uma limitação para a documentação, uma vez que o idioma grego não é atualmente suportado pela plataforma VMware Docs. Como solução provisória, a documentação em grego do VMware SD-WAN, do Cloud Web Security e do Secure Access está publicada aqui em formato PDF.” foi removida. A partir desta edição, o idioma grego é suportado na plataforma VMware Docs e um utilizador pode ver as versões em grego da documentação do SD-WAN e SASE em docs.vmware.com.

Problemas resolvidos

Os problemas resolvidos são agrupados da seguinte forma.

Problemas resolvidos do Edge/Gateway

Resolvido na versão R5002-20220506-GA do Edge/Gateway

A versão rollup R5002-20220506-GA do Edge/Gateway foi lançada a 12-05-2022.

Esta compilação rollup do Edge/Gateway aborda os problemas críticos abaixo desde a versão R5000-20220225-GA do Edge/Gateway.

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

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

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

  • Problema 83209 resolvido: Para os clientes que utilizam o OSPF na respetiva empresa, o routing OSPF pode não funcionar conforme esperado.

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

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

  • Problema 87956 resolvido: para um VMware SD-WAN Edge que utiliza uma única interface WAN onde estão configurados dois ou mais overlays WAN definidos pelo utilizador com o mesmo próximo hop, se uma ligação WAN ligada à interface única ficar inativa e ativa, apenas um dos túneis overlay definidos pelo utilizador é restabelecido.

    Por exemplo, se existirem overlays definidos pelo utilizador com diferentes endereços IP de origem, mas o mesmo próximo hop que direciona o tráfego para um Hub Edge e um Gateway respetivamente, num flap de ligação WAN, apenas o túnel para o Gateway é restabelecido e o túnel para o Hub Edge não é, o que resulta num impacto no tráfego do cliente destinado ao Hub Edge.

    Por definição, o Edge não suporta ter vários overlays WAN definidos pelo utilizador com o mesmo próximo hop, mas o Edge não realiza uma verificação da configuração e, em vez disso, trata-a como válida. O Edge apenas realiza uma verificação e impõe um único overlay WAN definido pelo utilizador, excluindo outros overlays WAN, perante um flap de ligação WAN. É por isso que a configuração "funciona"para o Edge quando é aplicada ou quando o Edge é reiniciado e a configuração é reaplicada. A correção deste problema permite vários overlays WAN definidos pelo utilizador para a mesma interface e, assim, todos os túneis serão restabelecidos após um flap de ligação WAN ou qualquer outra circunstância que possa fazer com que os túneis overlay fiquem inativos.

    Sem a correção, a única forma de restaurar todos os túneis é reiniciar o serviço Edge, o que pode ser feito no Orchestrator com Teste e Resolução de problemas > Ações remotas > Reiniciar serviço (Test & Troubleshoot > Remote Actions > Restart Service).

Problemas resolvidos do Edge/Gateway

Resolvido na versão R5000-20220225-GA do Edge/Gateway

Os problemas abaixo foram resolvidos desde a versão R450-20220203-GA do Edge e a versão R450-20220203-GA do Gateway .

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

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

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

    Desativar uma interface encaminhada desassocia esse dispositivo de rede do hardware controlado por DPDK, volta a associá-lo ao driver Linux e reinicia o serviço Edge. O ficheiro /opt/vc/etc/dpdk.json é atualizado para remover esta interface, pelo que, na reativação, o ficheiro não é atualizado para ser desassociado do Linux de volta para o driver controlado por DPDK.

    Sem a correção, a única maneira de remediar o problema é reiniciar o Edge para limpar o estado e voltar a um estado de arranque padrão para voltar a adicionar dispositivos à camada DPDK do edge

  • Problema 42488 resolvido: 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 Edge for reiniciado, os caminhos ligados da LAN são anunciados.

    Se a ligação numa porta for removida e a interface não for desativada, o Edge não revoga o caminho do Gateway, fazendo com que outros Edges encaminhem o tráfego para o Edge sem ligação. O impacto do cliente é que o tráfego pode ser um buraco negro para o caminho ligado para interfaces que não têm uma ligação ativa.

    Sem a correção, a única solução alternativa é desativar a interface se não estiver ativa nenhuma ligação.

  • Problema 53378 resolvido: Num VMware SD-WAN Edge, em que uma largura de banda de ligação WAN é configurada manualmente nas definições WAN, as definições de largura de banda são honradas no tráfego com o Segmento Global, mas não são honradas no tráfego com um Segmento Não Global.

    Numa ligação WAN com uma capacidade superior à capacidade configurada manualmente nas Definições WAN, o Segmento Global imporia o valor configurado mais baixo, mas um Segmento não Global utilizaria a capacidade real da ligação.  Isto ocorre apesar da Contabilização de Underlay estar configurada na interface do Edge que a ligação WAN está a usar.

  • 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 no 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 na ligação WAN pública afetada ou reiniciar o Edge (onde são utilizadas ligações PPPoE), o que recupera o caminho para o Orchestrator.

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

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

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

  • Problema 64627 resolvido: Um VMware SD-WAN Gateway pode ter um reinício do Serviço dataplane com uma breve interrupção no 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 de gestão do Edge com o seu Gateway conectado, isto pode levar à exaustão dos contadores de memória do Gateway que aciona um reinício do Gateway para recuperar.

  • Problema 65964 resolvido: Ao analisar os detalhes de um Alerta, a secção de tempo está incorreta no VMware SASE Orchestrator.

    Os detalhes dos Alertas não são enviados dentro do atraso de notificação e são semelhantes aos detalhes de um Alerta que é enviado. A hora de notificação é qualquer que seja a hora atual quando os detalhes são vistos. Na nova IU, a hora de notificação é listada como “Pendente” ( “Pending”).

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

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

  • Problema 68482 resolvido: O VMware SD-WAN Hardware Edge a executar a Versão 4.5.0 pode não atualizar com sucesso os valores de largura de banda de ligação WAN após o reinício do serviço.

    Quando um serviço VMware SD-WAN Edge reinicia o Edge deve testar a largura de banda e comparar com os valores em cache. Com este problema, os resultados dos testes não são aplicados e o valor em cache continua a ser utilizado.

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

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

  • Problema 70118 resolvido: Ao olhar para o registo route_events_msg_dump de um pacote de diagnóstico, os registos do utilizador não incluem a máscara de rede. 

    Para alguns problemas com o cliente é útil incluir a máscara de rede ao examinar eventos de routing, mas está em falta neste caso.

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

    Tanto os Edges como os Gateways têm uma biblioteca interna para gerir UUIDs (identificadores exclusivos universais). Uma condição race muito rara nesta biblioteca pode causar um problema “use-after-free” que desencadeia uma falha de segmentação e uma falha de serviço para o respetivo Edge ou Gateway. Um fator que aumenta o risco de um Edge ou Gateway registar este problema são os frequentes flaps de túneis (túneis que são desativados e recriados).

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

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

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

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

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

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

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

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

  • Problema 73933 resolvido: Um modelo VMware SD-WAN Edge 500 com uma imagem de fábrica versão 1.8.x não pode ser ativado para a versão 4.5.0 ou posterior.

    Um Edge 500 cuja reposição da imagem de fábrica tenha sido total (em que essa imagem é a Versão 1.8.x) não pode ser ativado num cenário em que lhe seja atribuída uma versão 4.5.x. As compilações 4.5.0+ alteraram o formato do pacote de atualização para utilizar sha256sums em vez de sha1sums. Como as compilações mais antigas não têm estas bibliotecas, a atualização para 4.5.x falha.

    Sem a correção, a solução é ativar o Edge 500 para uma versão mais recente como 4.2.x ou 4.3.x e, em seguida, proceder com um passo extra para atualizar o Edge para a compilação 4.5.x uma vez que o Edge está a utilizar a compilação mais recente.  O Edge 500 também é EOL, pelo que a outra solução é realizar o RMA do Edge para o mais recente modelo Edge equivalente.

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

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

    Sem a correção, a única forma de fazer com que o Edge retome o envio de sondas L7 é desativar e reativar a verificação de estado de funcionamento de L7.

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

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

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

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

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

    Sem esta correção, a solução é personalizar o mapa de aplicação para que o Skype e o MS Teams sejam classificados como Colaboração empresarial.

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

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

  • Problema 75772 resolvido: Para um cliente que utilize o Edge Network Intelligence em que um Edge tem a Análise (Analytics) ativa, o Edge pode ter uma fuga de memória que resulta no reinício do Edge para limpar a fuga de memória.

    Quando a Análise (Analytics) está configurada e o DHCP também está configurado numa interface do Edge, os eventos de conectividade do cliente fazem com que a utilização da memória aumente. Durante um período de tempo suficiente, a utilização da memória pode chegar a um limiar crítico e o Edge reiniciaria defensivamente o serviço Edge para restaurar os níveis normais de memória.  Como em qualquer problema de fuga de memória, quanto menor for a pegada de memória inicial (por exemplo, um Edge 510, 520 ou 610) mais vulnerável é o reinício do Edge.

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

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

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

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

  • Problema 77224 resolvido: Se um caminho estático inválido (por exemplo, 2.2.2.2/0) estiver configurado num VMware SASE Orchestrator para um VMware SD-WAN Edge, vários Edges ligados podem ter um caminho inválido ou obsoleto.

    Quando existe um caminho genuíno predefinido (0.0.0.0/0) e também um caminho inválido com comprimento de prefixo 0 (por exemplo, 2.2.2.2/0). O caminho inválido faz com que o caminho predefinido não seja eliminado dos Edges remotos, embora tenha sido eliminado do Edge original.

    Isto está ligado ao pedido do Orchestrator 77159 que permite configurar caminhos inválidos com prefixos de comprimento 0.

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

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

    Nota: Este é um seguimento do problema de Edge 51291 que, embora a correção tenha sido bem sucedida na resolução do problema, não foi duradoura porque os limiares de tensão definidos manualmente estavam a ser limpos por uma atualização CPLD.  Caso contrário, o sintoma e a descrição são os mesmos, mas a correção aqui garante que os limiares de tensão persistem sobre qualquer atualização subsequente do Edge.

  • Problema 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 de software do Edge em standby, poderá ser apresentada uma exceção que não é processada pelo código HA do Edge, o que faz com que um thread de trabalho 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 ocorrer uma recuperação automática HA e o Edge em standby for promovido a ativo, o Edge ficará com um conjunto de configurações e software incompatíveis. O Orchestrator detetará a incompatibilidade da configuração e emitirá a configuração atualizada para este Edge, ao mesmo tempo que também completará a atualização do software que anteriormente falhou no Edge em standby. 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 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 aos threads HA sem fornecimento durante o processamento do pacote de heartbeat HA. 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 de espera 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. 

    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 77629 resolvido: Num site implementado com uma topologia de alta disponibilidade, se o utilizador desligar a HA, o Edge em standby e o ativo podem ficar desativados.

    Este problema pode ter um impacto sério num site de cliente uma vez que ambos os Edges estão desativados e nenhum tráfego do cliente poderia passar até que um dos Edges fosse reativado. O comportamento esperado quando a HA é desligada para um site é o Edge em standby ser desativado e o Edge ativo tornar-se o Edge autónomo para esse site. Em alguns casos, quando a HA é desligada, enquanto o Edge em standby está a aplicar a configuração “HA off” e antes de ser desativado, continua a enviar heartbeats para o Orchestrator e o Orchestrator atualiza erroneamente o número de série do Edge HA. Durante o ciclo seguinte, o Ativo envia ao Orchestrator o seu heartbeat que o Orchestrator compara com o número de série recém-atualizado e deteta um número de série desajustado e inicia também uma desativação do Edge ativo.

    Isto é um problema de tempo e não é consistente, mas sem a correção, a melhor prática é desativar a HA apenas numa janela de manutenção para ser seguro.

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

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

  • Problema 77755 resolvido: Num VMware SD-WAN Edge a executar a Versão 4.0.0 e posterior, se um cliente implementar uma imagem VNF (Funções de Rede Virtual) em que o checksum é configurado com letras maiúsculas, a implementação VNF falha devido a uma incompatibilidade de dados e a imagem será removida do Edge.

    Este problema é causado pelo software 4.0.0 e posterior do Edge a executar uma comparação com distinção de maiúsculas do checksum configurado pelo Operador com o checksum calculado pelo Edge. Um checksum configurado que contém letras maiúsculas causa uma não correspondência de checksum, mesmo que os valores de checksum calculados sejam correspondentes.

    A versão 5.0.0 e as versões posteriores utilizam uma comparação sem distinção de maiúsculas para verificar se um checksum configurado pelo Operador corresponde ao checksum calculado no Edge.

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

    Normalmente, se existirem vários túneis Dinâmicos Edge-to-Edge já estabelecidos no Spoke Edge, a verificação máxima do número de túneis é atingida no Spoke para o túnel estático. Esta verificação impede a formação de túneis estáticos do Spoke para o Hub.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    O problema resolve-se através da atualização do Edge 6x0 para o firmware de plataforma 1.3.0 (R130-20220328-GA), que inclui a versão de PIC v20N. Para isso, o Edge 6x0 tem de ser ligado a um VMware SASE Orchestrator com a versão 5.x (5.0.0 ou posterior) e o Edge 6x0 também tem de utilizar uma compilação de versão 5.x. O utilizador atualizaria então o firmware da plataforma Edge 6x0 para a versão 1.3.0 (R130-20220328-GA) da mesma forma que uma versão de software do Edge é modificada.

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

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

    Nota: se o utilizador preferir manter o Edge numa versão de software mais baixa (por exemplo, versão 4.3.1 ou 4.5.1), o cliente poderá atualizar temporariamente o Edge para uma compilação 5.x, atualizar o firmware da plataforma para a versão 1.3.0 (R130-20220328-GA), para que a versão de PIC seja v20N, e mudar para uma versão anterior preferida do software do Edge. A mudança do software do Edge 6x0 para uma versão anterior não muda a versão do firmware da plataforma do Edge para uma versão anterior e o Edge continuaria a utilizar a versão de firmware da plataforma 1.3.0 (R130-20220328-GA). Neste caso de utilização, os Edges do cliente teriam de estar num Orchestrator que utilizasse a versão 5.x.

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

Problemas resolvidos do Orchestrator

Resolvido na versão R5002-20220517-GA do Orchestrator

A versão rollup R5002-20220517-GA do Orchestrator foi lançada a 17-05-2022.

Esta compilação rollup do Orchestrator aborda os problemas críticos abaixo desde a versão rollup R5001-20220317-GA do Orchestrator.

  • Problema 81960 resolvido: para um cliente que utiliza o serviço VMware Cloud Web Security, ao configurar as Regras DLP ou as Regras da Web, a IU do VMware SASE Orchestrator mostra o número de itens selecionados, mas não mostra de imediato se todos os itens de uma categoria foram selecionados.

    A UI deve apresentar não só o número total de regras selecionadas, mas também “Todos os tipos selecionados” (All Types Selected), onde todos os tipos podem ser Aplicações de regras DLP, Tipos de documentos de regras DLP, Tipos de ficheiros de regras DLP, Categorias de regras DLP, Dicionários DLP, Categorias de regras da Web e Ameaças de regras da Web. Desta forma, o utilizador consegue saber de imediato se todas as regras de um tipo especificado foram selecionadas.

  • Problema 84600 resolvido: quando um VMware SASE Orchestrator que utiliza uma topologia de Recuperação após desastre (DR) é atualizado para a versão 4.5.0 ou 5.0.0.1, o operador pode observar que os serviços Cloud Web Security e Secure Access do Orchestrator em standby estão constantemente a reiniciar.

    Isto não afeta o cliente, uma vez que ocorre apenas no Orchestrator em standby, nem afeta quaisquer serviços, mas um operador observaria registos do Orchestrator em standby relativamente ao reinício em intervalos de poucos segundos dos serviços Cloud Web Security e Secure Access (listados como “ztnad”). O problema é provocado por cada serviço que faz uma chamada da API para o Orchestrator em standby que falha porque esse Orchestrator não pode servir os pedidos.

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

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

  • Problema 85291 resolvido: quando um VMware SASE Orchestrator que utiliza uma topologia de Recuperação após desastre (DR) é atualizado para a compilação da versão 5.0.0.0 ou 5.0.0.1 do Orchestrator, a DR pode falhar.

    Nos Eventos do operador, o operador observaria eventos com o nome “Falha de configuração da DR” (DR Configuration Failure) e uma mensagem “Aviso: o ativo não consegue obter o estado da DR do standby... o acesso ao ficheiro do certificado falhou ao iniciar uma chamada da API segura...” (Warning: active unable to get standby DR status...accessing the cert file is failed to initiate a secure API call...). A falha da DR é provocada por um problema de direitos de acesso durante a leitura da raiz de confiança de um certificado autoassinado.

  • Problema 85338 resolvido: quando um VMware SASE Orchestrator que utiliza uma topologia de Recuperação após desastre (DR) é atualizado para a compilação da versão 5.0.0.0 ou 5.0.0.1 do Orchestrator, as Definições de gestão (Management Settings) são removidas dos Perfis do operador.

    As Definições de gestão removidas incluem o endereço do Orchestrator em todas as três formas: Endereço FQDN, Endereço IPv4 do Orchestrator e/ou Endereço IPv6 do Orchestrator, quando aplicável. Sem a correção, um operador necessita de voltar a preencher os campos de endereço do Orchestrator adequados. Caso contrário, o Perfil do operador não será válido.

  • Problema 85412 resolvido: quando um VMware SASE Orchestrator que utiliza uma topologia de Recuperação após desastre (DR) é atualizado para a compilação da versão 5.0.0.0 ou 5.0.0.1 do Orchestrator, a DR pode falhar com um erro na fase Copiar DB (Copy DB).

    Como parte do processo de replicação, a base de dados do Orchestrator em standby está a ser reutilizada e, devido a uma declaração incorreta do MySQL, certas tabelas não são criadas na base de dados do standby, o que impede que o processo de DR prossiga.

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

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

    • Para alterações de configuração, o nome de utilizador é incluído no evento, mas não é incluída a alteração que foi feita.
    • Quando uma regra do Cloud Web Security é eliminada, o Orchestrator não inclui os dados eliminados com o evento.
    • Ativar ou desativar a autenticação não inclui um carimbo de data e hora para o evento.
    • Para eventos CASB, apenas é incluído o ID da aplicação e não o nome da aplicação.
  • Problema 86573 resolvido: quando um utilizador executa um Diagnóstico remoto para um VMware SD-WAN Edge com uma versão 3.4.x num VMware SASE Orchestrator com a versão 5.0.0.1, o diagnóstico excede o tempo limite e a IU do Orchestrator não apresenta um resultado.

    Quando o Edge 3.4.x utiliza o modo de comunicação em direto e não suporta o RealtimeConnection (que é introduzido nas versões 4.x do Edge) e a versão do Orchestrator é 5.x, a página da IU do Diagnóstico remoto para e não devolve um resultado.

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

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

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

    Nota: embora este problema afete as compilações do Gateway e do Orchestrator, a presente correção aplica-se apenas à compilação do Orchestrator. O problema que afeta as compilações do Gateway é rastreado como um pedido de Problema conhecido com o mesmo número (88796).

  • Problema 89005 resolvido: para os clientes que utilizam o serviço VMware Cloud Web Security, um utilizador não consegue ativar ou desativar uma autenticação SAML existente no VMware SASE Orchestrator.

    Quando um utilizador navega para Cloud Web Security > Configurar > Autenticação > Ativar autenticação SAML (Cloud Web Security > Configure > Authentication > Enable SAML Authentication) e introduz informações válidas, depois de clicar em Guardar alterações (Save Changes), a configuração falha e a mensagem de erro indica O "adminSaml" não é permitido ("adminSaml" is not allowed)

___________________________________________________________________

Resolvido na versão R5001-20220317-GA do Orchestrator

A versão R5001-20220317-GA do Orchestrator foi lançada em 18/03/2022. Esta compilação do Orquestrador aborda vários problemas críticos desde a versão R5000-20220225-GA do Orchestrator.

  • Problema 69573 resolvido: para os 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 76994 resolvido: Para um cliente que utiliza o serviço VMware Cloud Web Security, quando um cliente que utiliza o Cloud Web Security tem esse serviço removido no VMware SASE Orchestrator por um operador e, em seguida, restaura o serviço ao cliente, os utilizadores observarão que a IU do Cloud Web Security não é utilizável e verão vários erros.

    Um utilizador que inicia sessão na secção Cloud Web Security do Orchestrator verá vários erros ao tentar configurar uma política de segurança e, apesar do próprio serviço funcionar, o cliente não será capaz de modificar as políticas existentes.

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

  • 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 83550 resolvido: Para os clientes que utilizam o serviço Cloud Web Security que configuraram políticas de segurança com a funcionalidade de Prevenção de perda de dados (DLP), ao monitorizar a atividade DLP na IU do VMware SASE Orchestrator, o utilizador não poderá ver o ecrã “Contagem de blocos por data” (Block Count by Date).

    O ecrã Cloud Web Security > Monitorizar > DLP (Cloud Web Security > Monitor > DLP) também irá apresentar um banner de mensagem “erro ao receber a contagem de blocos de topo dlp por data - Erro de Backend” (error while getting dlp top block count by date - Backend Error). Os ecrãs Origens de ameaças (Threat Origins) e Contagem de blocos por utilizador (Block Count by User) serão apresentados corretamente nesta página.

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

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

  • Problema 83902 resolvido: para um VMware SASE Orchestrator implementado com uma topologia de Recuperação após desastre (DR), quando o Orchestrator é atualizado para a versão 5.0.0, a sincronização DR entre os Orchestrators ativos e em standby pode falhar.

    Um utilizador operador verá uma mensagem de erro “Falha na cópia de DB” (Failure Copying DB) durante a fase Copiar DB da sincronização DR na IU do Orchestrator.  Nos registos do Orchestrator, um operador verá esta entrada “Erro ao executar a cópia do esquema mysql: ERRO 1049 (42000) na linha 4116: Base de dados “velocloud_ztnad” desconhecida”. (Error running mysql schema copy: ERROR 1049 (42000) at line 4116: Unknown database ´velocloud_ztnad´).

  • 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 R5000-20220225-GA

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

  • Problema 52301 resolvido: O filtro para a coluna “Tipo de Gateway” (Gateway Type) na grelha de utilização do cliente para um Gateway ativado não funciona corretamente no VMware SASE Orchestrator.

    Localizado na página Visão geral (Overview) de um Gateway ativado, o utilizador não consegue filtrar eficazmente pelo Tipo de Gateway (Gateway Type).

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

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

  • Problema 61182 resolvido: Na nova IU do VMware SASE Orchestrator, quando o estado de BGP é alterado para “Removido” para o Edge ou Gateway, o Orchestrator não está a apresentar o estado de vizinho.

    Este é apenas um problema de exibição, mas é confuso para os utilizadores que não estão a obter um estado correto para uma alteração do estado BGP para “Removido” (Removed).

  • Problema 62456 resolvido: Na nova IU do VMware SASE Orchestrator, um utilizador pode ativar um Serviço de Segurança na Cloud (CSS) sem selecionar um serviço.

    O utilizador pode configurar um CSS sem um serviço e guardar sem um erro na nova IU.  A IU Clássica funciona como esperado e lança um erro. O problema pode ocorrer para um VMware SD-WAN Edge em que a configuração CSS está ativada, mas nenhum serviço é selecionado, e, em seguida, o Edge desativa automaticamente a configuração CSS sem nenhuma notificação do utilizador ou evento.

  • Problema 62459 resolvido: Na nova IU do VMware SASE Orchestrator, ao configurar um Serviço de Segurança na Cloud (CSS) com o tipo Zscaler, a opção da Verificação do estado de funcionamento L7 (L7 Health Check) está em falta.

    A opção da Verificação do estado de funcionamento L7 (L7 Health Check) é apresentada na IU Clássica, mas está em falta se utilizar a nova IU. Esta é uma omissão significativa, uma vez que esta funcionalidade é muito importante para muitos clientes que usam um CSS Zscaler.

  • Problema 63605 resolvido: Na nova IU do VMware SASE Orchestrator, um utilizador pode configurar uma opção de hash MD5 para um Serviço de Segurança na Cloud.

    MD5 é uma opção descontinuada a partir da versão 4.5.0 e não deve ser apresentada num Orchestrator 4.5.0 posterior como opção para um CSS.

  • Problema 66226 resolvido: Na nova IU do VMware SASE Orchestrator, quando um utilizador configura alguns campos inválidos dentro de uma secção colapsada de “acordeão” da IU do navegador, o utilizador não tem qualquer indicador de validade nesse acordeão e não consegue saber a razão pela qual não está autorizado a guardar alterações.

    Quando um utilizador introduz dados inválidos num campo e, em seguida, colapsa essa secção para ver outras secções nessa página da IU, o utilizador não pode guardar alterações, mas a secção de acordeão colapsada não é marcada como inválida. A única ação que um utilizador pode realizar é expandir a secção de acordeão para verificar que campos são inválidos.

  • Problema 67179 resolvido: Para um cliente que tenha configurado um Serviço de Segurança na Cloud, se o Protocolo de Túnel do fornecedor de CSS for alterado de GRE para IPsec, quando o utilizador olhar para a secção Configurar > Dispositivo > Serviço de Segurança na Cloud para um Edge com esse CSS, o utilizador observa linhas FQDN vazias na secção Credenciais.

    Se o fornecedor de CSS for alterado de GRE para IPsec, as linhas FQDN anteriormente preenchidas para credenciais CSS estão agora vazias. Trata-se de um problema de exibição, mas, no entanto, é um obstáculo para o utilizador cliente que tenta confirmar credenciais.

  • Problema 67784 resolvido: Na IU Clássica do VMware SASE Orchestrator, para um Edge com seis ou mais ligações WAN, ao consultar o separador Monitorizar > QoE (Monitor > QoE), o utilizador observaria que as etiquetas de texto de cada ligação estão desalinhadas em relação ao respetivo gráfico QoE com o qual devem coincidir.

    Problema de exibição que impede a capacidade de um utilizador de ver o estado QoE de cada uma das seis ou mais ligações WAN.

  • Problema 69240 resolvido: Quando um Administrador de parceiro com uma função de Especialista empresarial se regista num VMware SASE Orchestrator a executar a Versão 4.5.0, o administrador pode observar os detalhes do cliente.

    Um Administrador de parceiro com uma função de Especialista empresarial foi concebido para criar e modificar contas de clientes que o Parceiro está a suportar. Esta função não deve conseguir ver as configurações do cliente.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Problema 77136 resolvido: Quando uma empresa de cliente é migrada de um VMware SASE Orchestrator para outro, a configuração do Início de Sessão Único (SSO) não é migrada com sucesso.

    Este é um grande problema para um cliente que precise de reconfigurar manualmente os seus dados SSO após a sua empresa ser migrada para um Orchestrator diferente.

  • Problema 77159 resolvido: Um utilizador consegue configurar um caminho estático com um prefixo de rede com uma especificação de 0 netmask, que resulta numa perturbação potencialmente significativa do tráfego do cliente.

    O Orchestrator não realiza uma validação para um prefixo de rede mau com um 0 netmask (por exemplo, 2.2.2.2/0) e, em vez disso, instala este caminho no FIB. Como o prefixo do caminho estático é 0, é provável que apanhe muito tráfego destinado à cloud e que possa ser eliminado tráfego. 

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

    Para um utilizador parceiro durante o registo do evento “Modificou a lista de imagens de software atribuída” (Modified the assigned software image list) para atualizar “Imagens de software/firmware atribuídas” (Assigned Software/Firmware Images), se nenhuma Imagem de software/firmware foi removida para esse evento em “removedSoftwareImages”, estava a processar e a listar imagens de todos os módulos imageUpdate presentes em VELOCLOUD_CONFIGURATION_MODULE para o operador em particular. Com efeito, a lógica é quebrada para este processo quando um utilizador parceiro executa a ação e isto causa o erro e a falha ao alterar a imagem de software padrão do cliente.

  • Problema 78684 resolvido: Para um Destino VMware Não-SD-WAN via Gateway com um tipo de Hub Virtual Microsoft Azure, quando um utilizador executa uma Configuração de ressincronização para este Azure NSD, o VMware SASE Orchestrator não propaga os caminhos estáticos NSD.

    Os caminhos não são propagados para o Controlo de fluxo de overlay (tabela) ou para as Definições do dispositivo Edge devido a um problema com a API responsável por estas ações sempre que a Configuração de ressincronização for selecionada para o Azure NSD.

  • Problema 80593 resolvido: A permissão de negação de privilégios de um utilizador na página “Diagnóstico remoto” (“Remote Diagnostics”) não tem qualquer efeito se a localização do VMware SASE Orchestrator mudar para outro idioma que não seja inglês.

    As permissões do Pacote de personalização de função para os privilégios utilizados na página “Diagnóstico remoto” (“Remote Diagnostics”) não são aplicadas quando o local do Orchestrator muda para um idioma que não seja inglês. A razão para este problema é que a verificação de permissões de função do Orchestrator é realizada num valor traduzido, mas é comparada com um valor não traduzido que está a falhar a condição de correspondência de cadeias.

  • Problema 80930 resolvido: Para um cliente que esteja a utilizar um Destino Não-SD-WAN via Edge, quando uma regra de Política empresarial é criada para esse Edge, o VMware SASE Orchestrator também pode criar uma configuração duplicada do túnel IPsec para cada túnel IPsec que o NSD via Edge tenha configurado e, assim que estes duplicados são criados, o utilizador do cliente não consegue fazer mais alterações de configuração no Edge sem obter vários erros.

    O erro que o utilizador veria na IU do Orchestrator indica: O ramo de segmento “Nome do segmento” do Edge para Destino Não-SD-WAN através do serviço “Nome do serviço” do Edge não pode adicionar túneis duplicados com a mesma ligação WAN. Este problema já foi observado no campo e não foi recriado com sucesso pela Engenharia, o que sugere que este problema é raro.  É causado por uma chamada extra à API realizada pelo Orchestrator quando uma política empresarial é criada que também adiciona duplicados em cada túnel IPsec que o Edge já tenha. 

    A única forma de resolver o problema é eliminar as entradas duplicadas e, em seguida, introduzir novamente os detalhes da configuração.

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

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

  • Problema 81396 resolvido: Na nova IU do VMware SASE Orchestrator, um utilizador não consegue atualizar uma configuração VNF de segurança para um VMware SD-WAN Edge.

    O problema específico é o UUID do VNF de segurança. Ao alterar valores como VM-1 IP, VM-1 Nome de anfitrião, o Orchestrator não fornece um novo UUID para o VNF de segurança. A atualização de um VNF de segurança funciona como esperado na IU clássica do Orchestrator.

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

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

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

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

Problemas resolvidos do Secure Access

Resolvido na versão R5000-20220227-GA

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

  • Problema 70493: quando um cliente edita a configuração de um serviço VMware Secure Access e remove a associação a uma política do Cloud Web Security, não é 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).

Problemas resolvidos do Cloud Web Security

Resolvido na versão R5000-20220227-GA

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

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

Problemas conhecidos

Problemas pendentes na versão 5.0.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 configurados por BGP) pode provocar um aumento da latência durante cerca de 2 a 3 segundos para algum tráfego através do VMware SD-WAN Gateway.

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

  • Problema 25921:

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

  • Problema 25997:

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

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

  • Problema 26421:

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

  • Problema 28175:

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

  • Problema 31210:

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

  • Problema 32731:

    os caminhos predefinidos condicionais anunciados através de OSPF podem não ser retirados corretamente quando o caminho é desativado. A reativação do caminho, seguida de uma nova desativação, irá retirá-los com sucesso. 

  • Problema 32960:

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

  • Problema 32981:

    a codificação da velocidade e do duplex numa porta configurada por DPDK pode exigir o reinício do VMware SD-WAN Edge para que as configurações entrem em vigor, uma vez que exige a desativação do DPDK.

  • Problema 34254:

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

  • Problema 35778:

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

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

  • Problema 36923:

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

  • Problema 38682:

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

  • Problema 38767:

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

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

  • Problema 39134:

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

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

  • Problema 39374:

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

  • Problema 39608:

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

  • Problema 39624:

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

  • Problema 39659:

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

  • Problema 39753:

    a desativação da VPN ramo a ramo dinâmica pode fazer com que os fluxos existentes que estão atualmente a ser enviados através da mesma fiquem parados.

  • Problema 40096:

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

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

  • Problema 40421:

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

  • Problema 42278:

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

  • Problema 42388:

    num VMware SD-WAN Edge 540, uma porta SFP não é detetada após desativar e, em seguida, reativar a interface no VMware SD-WAN Orchestrator.

  • Problema 42872:

    ativar o isolamento de perfil num perfil de Hub em que um cluster de Hub está associado não revoga os caminhos do Hub na base de informações de routing (RIB).

  • Problema 43373:

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

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

  • Problema 44995:

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

  • Problema 45189:

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

  • Problema 45302:

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

  • Problema 46053:

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

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

  • Problema 46137:

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

  • Problema 46216:

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

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

  • Problema 46391:

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

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

  • Problema 46918:

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

  • Problema 47084:

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

  • Problema 47664:

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

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

  • Problema 47681:

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

  • Problema 47787:

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

  • Problema 48166:

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

  • Problema 48175:

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

  • Problema 48502:

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

  • Problema 48530:

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

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

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

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

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

  • Problema 48666:

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

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

  • Problema 49738:

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

  • Problema 50518:

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

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

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

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

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

  • Problema 52955: a recusa DHCP não é enviada a partir do Edge e o reenlace do DHCP não é reiniciado após a falha do DAD no DHCP Dinâmico.

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

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

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

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

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

  • Problema 53337: os pacotes ignorados podem ser observados numa instância do AWS de um VMware SD-WAN Gateway quando o débito é superior a 3200 Mbps.

    Quando o tráfego excede um débito superior a 3200 Mbps e um tamanho de pacote de 1300 bytes, são observados pacotes ignorados no handoff do IPv4 BH e RX.

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

  • Problema 53359: a sessão BGP/BFD pode falhar durante alguns cenários de ataque DDoS.

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

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

  • Problema 53830: num VMware SD-WAN Edge, alguns dos caminhos na vista BGP podem não ter os valores de preferência e anúncio corretos quando a flag DCC está marcada, provocando uma sequência de ordenação incorreta no FIB do Edge.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Problema 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 a configuração de CSS e, em seguida, reativá-la, vai ativar o túnel CSS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Problema 82182: para um modelo VMware SD-WAN Edge 510 ou 510-LTE que esteja a executar a versão 5.0.0 do Edge, quando um utilizador tenta reiniciar o serviço do Edge, o Edge pode também reiniciar.

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

    Solução alternativa: Não existe uma solução alternativa, mas os reinícios do serviço do Edge para estes modelos apenas devem ser feitos numa janela de manutenção ou com a compreensão de que este problema pode surgir.

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

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

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

  • Problema 82264: um VMware SD-WAN Virtual Edge que utiliza uma instância AWS C4 não pode ser atualizado para a versão 5.0.0.

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

    Solução alternativa: o cliente pode atualizar as instâncias do AWS C4 Edge para a versão 5.0.1, que inclui uma correção para este problema.

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

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

    Solução alternativa: não existe uma solução alternativa. Evite utilizar estas compilações para esta implementação específica do Gateway até que sejam lançadas novas compilações com este problema corrigido.

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

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

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

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

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

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

  • Problema 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 correspondência/definição, o cliente poderá observar o par Edge HA a falhar continuamente sem nunca recuperar.

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

    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 85461: se um VMware SD-WAN Edge for utilizado para encaminhar o DNS e os dispositivos LAN ligados ao Edge estiverem a utilizar o Edge para o encaminhamento do DNS, todo o tráfego do DNS pode falhar.

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

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

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

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

    Solução alternativa: a solução para este problema é não utilizar o Edge para encaminhar o DNS, ou...

    • Quando utilizar a versão 4.2.2 do Edge: utilize portas LAN comutadas ou portas LAN encaminhadas que incluam um endereço IP do Gateway.
    • Quando utilizar a versão 4.3.x ou 4.5.x: utilize apenas portas LAN encaminhadas com um endereço IP do Gateway especificado. 
  • Problema 88604: num site que utiliza uma topologia de Alta Disponibilidade, caso uma interface WAN fique inativa e, depois, fique operacional num VMware SD-WAN Edge em espera, o evento não é registado no VMware SASE Orchestrator.

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

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

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

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

    Nota: este pedido aberto aplica-se apenas às compilações do Gateway.  As compilações do Orchestrator foram corrigidas com a versão R5002-20220517-GA.

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

  • Problema 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 (Analytics) está ativada num Edge, o Serviço 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 (Analytics) no Edge até que seja disponibilizada uma compilação do Edge corrigida; ou b) monitorizar a memória do Edge. Quando a utilização da memória atingir os 40% e o Orchestrator registar um Evento de aviso de memória, agende um reinício manual do Serviço Edge numa janela de manutenção para limpar a memória e garantir um impacto mínimo no cliente.

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

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

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

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

    O processo de depuração principal para a saída das interfaces não inclui os detalhes da porta física para interfaces WAN do Edge (por exemplo, GE3 ou GE4 num modelo Edge 6x0 ou 3x00). Como resultado, quando o SNMP sonda essas interfaces, devolve sempre um resultado de UP, independentemente da configuração das interfaces.

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

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

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

    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 do VMware SD-WAN Edge não são apresentados na página de monitorização. Uma recuperação automática resolve o problema.

  • Problema 33026:

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

  • Problema 34828:

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

  • Problema 35658:

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

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

  • Problema 35667:

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

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

  • Problema 36665:

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

  • Problema 38056:

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

  • Problema 38843:

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

  • Problema 39633:

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

  • Problema 39790:

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

  • Problema 40341:

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

  • Problema 41691:

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

  • Problema 43276:

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

  • Problema 47269:

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

  • Problema 47713:

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

  • Problema 47820:

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

  • Problema 48085:

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

  • Problema 48737:

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

  • Problema 49225:

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

  • Problema 49790:

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

    Solução alternativa: ignore o evento duplicado.

  • Problema 50531:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Problema 75348: Um cliente que tenha configurado um Destino Não-SD-WAN (NSD) via Gateway no qual a opção “Desativar sub-redes do site” (Deactivate Site Subnets) está selecionada poderá observar um caminho 0.0.0.0/32 em Configurar > Edge > Dispositivo > Definições de caminho estático > Caminhos NSD (Configure > Edge > Device > Static Route Settings > NSD Routes), apesar de esse caminho não ter sido configurado pelo cliente.

    Quando a caixa Desativar sub-redes do site (Deactivate Site Subnets) está selecionada na IU de configuração do NSD, é criada uma sub-rede 0.0.0.0/32 predefinida a partir da própria IU e, embora não apareça no ecrã de configuração do NSD, este caminho aparece no ecrã da IU Configurar > Edge > Dispositivo (Configure > Edge > Device). O problema é puramente estético e este caminho não cria perturbações ao tráfego do cliente. 

    Solução alternativa: o caminho pode ser limpo na IU do Orchestrator quando um utilizador seleciona a caixa VPN de cloud VeloCloud redundante (Redundant VeloCloud Cloud VPN) e, em seguida, anula a seleção da mesma no ecrã onde o NSD está configurado. Uma vez removido o caminho 0.0.0.0/32, o mesmo não voltará a aparecer na secção Caminhos NSD (NSD Routes).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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