This site will be decommissioned on December 31st 2024. Please visit techdocs.broadcom.com for the latest content.

 

VMware SASE 5.1.0 | 18 de dezembro de 2023

  • VMware SASE™ Orchestrator versão R51010-20231215-GA

  • VMware SD-WAN™ Gateway versão R5103-20230621-GA

  • VMware SD-WAN™ Edge versão R5102-20230310-GA

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

O que está nas notas de versão

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

Utilização recomendada

Esta versão é recomendada para todos os clientes que necessitem das funcionalidades e características disponibilizadas pela primeira vez na Versão 5.1.0.

Compatibilidade

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

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

Orchestrator

Gateway

Edge

Hub

Ramo/Spoke

5.1.0 

5.1.0 

3.4.5 

3.4.5 

5.1.0 

5.1.0 

3.4.6 

3.4.6 

5.1.0 

5.1.0 

5.1.0 

3.4.5 

5.1.0 

5.1.0 

3.4.6 

5.1.0 

5.1.0 

4.2.2 

4.2.2 

4.2.2 

5.1.0 

5.1.0 

4.2.2 

4.2.2 

5.1.0 

5.1.0 

5.1.0 

4.2.2 

5.1.0 

5.1.0 

4.2.2 

5.1.0 

5.1.0 

4.3.0 

4.3.0 

4.3.0 

5.1.0 

5.1.0 

4.3.0 

4.3.0 

5.1.0 

5.1.0 

5.1.0 

4.3.0 

5.1.0 

5.1.0 

4.3.0 

5.1.0 

5.1.0 

4.3.1 

4.3.1 

4.3.1 

5.1.0 

5.1.0 

4.3.1 

4.3.1 

5.1.0 

5.1.0 

5.1.0 

4.3.1 

5.1.0 

5.1.0 

4.3.1 

5.1.0 

5.1.0 

4.5.0 

4.5.0 

4.5.0 

5.1.0 

5.1.0 

4.5.0 

4.5.0 

5.1.0 

5.1.0 

5.1.0 

4.5.0 

5.1.0 

5.1.0 

4.5.0 

5.1.0 

5.1.0 

4.5.1 

4.5.1 

4.5.1 

5.1.0 

5.1.0 

4.5.1 

4.5.1 

5.1.0 

5.1.0 

5.1.0 

4.5.1 

5.1.0 

5.1.0 

4.5.1 

5.1.0 

5.1.0 

5.0.1 

5.0.1 

5.0.1 

5.1.0 

5.1.0 

5.0.1 

5.0.1 

5.1.0 

5.1.0 

5.1.0 

5.0.1 

5.1.0 

5.1.0 

5.0.1 

5.1.0 

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

As versões 3.2.x, 3.3.x e 3.4.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.

  • 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 ao fim da orientação técnica (EOTG) a 30 de setembro de 2022.

  • As versões 3.4.x do Edge chegaram ao fim do suporte (EOGS) a 31 de dezembro de 2022 e ao fim da orientação técnica (EOTG) a 31 de março 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 3.x (84151) do VMware SD-WAN

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

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

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

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

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

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

  • A versão 4.5.x dos Orchestrators e dos Gateways chegou ao fim do suporte geral (EOGS) a 30 de setembro de 2023 e chegará ao fim da orientação técnica (EOTG) a 31 de dezembro 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.

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 ou 5.x. Uma vez que todos os Edges estão a executar a versão 4.x/5.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.1.0.

Orchestrator

Os Orchestrators que utilizam a versão 4.0.0 ou posterior podem ser atualizados para a versão 5.1.0. 

Gateway

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

ao implementar um novo Gateway com a versão 5.1.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.1.0 ou posterior.

antes de atualizar um Gateway para a versão 5.1.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.1.0 ou posterior.

Edge

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

Novas funcionalidades do SD-WAN

Hub ou Cluster Interconnect

Pela primeira vez, múltiplos Hub Edges ou Hub Clusters podem ser interligados através de overlay em vez de underlay, aumentando o número de Edges Spoke que podem comunicar entre si. Os hubs podem agora partilhar caminhos entre si, permitindo que os Spoke Edges ligados a um Hub Edge ou Hub Cluster comuniquem através de overlay com os Spoke Edges ligados a outro Hub Edge ou Hub Cluster. Os Spoke Edges numa implementação multi-hub podem agora aproveitar a Otimização dinâmica de vários caminhos (DMPO) para melhorar a qualidade do tráfego, proporcionando uma visibilidade completa de todo o tráfego da rede. O Hub ou Cluster Interconnect proporciona ao cliente maior escalabilidade, fiabilidade e disponibilidade na respetiva rede multi-Hub Edge ou Hub Cluster.

A ativação da funcionalidade Hub ou Cluster Interconnect introduz uma mudança fundamental no protocolo de routing VMware SD-WAN por permitir que os pacotes atravessem mais do que um hop na rede. Embora esta alteração tenha sido testada em topologias representativas, não é possível testar todos os cenários de routing que podem ser encontrados quando é efetuada a alteração para permitir a distribuição de caminhos distantes. Assim, a VMware está a lançar esta funcionalidade como acesso antecipado e monitorizará de perto as implementações onde será ativada quanto a um comportamento de routing inesperado.

Nova interface do utilizador do Orchestrator

O Orchestrator versão 5.1.0 inclui a implementação completa da nossa nova interface do utilizador, introduzida pela primeira vez na versão 4.0.0. A nova IU oferece melhor usabilidade e um visual consistente em todos os serviços VMware SASE. Adicionalmente, a nova IU adiciona a Ajuda integrada no produto para remeter os utilizadores para a documentação relevante e outros materiais que ajudam na utilização do serviço SD-WAN.

A nova IU é a interface predefinida na versão 5.1.0 do Orchestrator e o utilizador continua a ter a opção de mudar para a IU clássica do Orchestrator quando utiliza o SD-WAN.

A interface do utilizador clássica ainda será suportada na seguinte versão secundária do VMware SASE Orchestrator. Recomendamos vivamente que os clientes utilizem e se familiarizem com a nova IU do Orchestrator.

Visibilidade do fluxo

Nas versões anteriores, a IU do Orchestrator apenas apresenta informação de fluxo agregada e estatística individualmente a partir da lente Aplicação, Origem ou Destino e não combina todas estas informações num único ecrã para fornecer uma vista completa. Em resultado disto, a monitorização, a resolução de problemas e o relatório são prejudicados pela ausência de uma visibilidade detalhada de cada fluxo.

Com a versão 5.1.0, a nova IU do Orchestrator inclui um separador “Fluxos” (Flows) que apresenta os dados consolidados para cada fluxo de tráfego. A IU do Orchestrator apresenta cada parâmetro de chave de fluxo numa vista única. Além disso, a funcionalidade Visibilidade de fluxo (Flow Visibility) permite que os clientes vejam dados históricos de fluxo, filtrem dados com base em parâmetros correspondentes e transfiram estatísticas de fluxo completas.

Entradas de DNS locais

A versão 5.1.0 suporta entradas de DNS locais no Edge para remeter o tráfego para domínios específicos. Quando o DNS local é configurado, o Edge verifica primeiro o ficheiro anfitrião local antes de tentar resolver um domínio com um servidor DNS.

Autoteste de ligação (POST) para Orchestrator, Gateway e Edge

A versão 5.1.0 melhora a proteção e visibilidade dos dispositivos através de um autoteste de ligação (POST). O POST é um processo realizado por uma rotina de software invocada imediatamente após um dispositivo ser ligado ou reiniciado. O processo POST inclui:

  • Verificação da integridade do software.

  • Verificação do teste de resposta conhecida dos algoritmos de módulo criptográfico.

  • Teste de fonte de entropia (ruído).

  • Apresentação dos resultados do POST: Aprovação/Falha. O sistema continuará a apresentar o resto das aplicações apenas se o POST for aprovado. Se o POST falhar, as mensagens de erro serão apresentadas nos casos de falha do teste e a sequência de arranque do sistema será interrompida.

No caso de Orchestrators e Gateways, esta funcionalidade apenas está disponível numa implementação greenfield. Os Edges não têm esta funcionalidade ativada por predefinição. O utilizador terá de a ativar através da IU do Orchestrator.

Novas melhorias do SD-WAN

Sincronização de caminhos locais de alta disponibilidade (HA) e reinício otimizado do BGP

Para um site implementado numa topologia de alta disponibilidade em que o BGP ou o OSPF também é utilizado, uma recuperação automática HA pode ser lenta e prejudicial para o tráfego do cliente devido à elevada perda de pacotes à medida que o Edge em espera sincroniza os caminhos. Para garantir recuperações automáticas HA mais rápidas e menos prejudiciais, a VMware introduziu duas melhorias: Sincronização de caminhos locais de HA e Reinício otimizado do BGP.

A Sincronização de caminhos locais de HA sincroniza automaticamente os caminhos entre os Edges ativos e em espera e utiliza estes caminhos para encaminhar no Edge ativo, enquanto garante que a tabela de caminhos fica imediatamente disponível após uma recuperação automática HA.

O Reinício otimizado do BGP garante recuperações automáticas HA e reinícios do Edge mais rápidos ao fazer com que os dispositivos BGP vizinhos participem no reinício de forma a garantir que não ocorrem alterações de caminhos na rede durante o reinício. Sem o Reinício otimizado do BGP, o Edge par elimina todos os caminhos assim que a sessão de TCP termina entre os pares BGP e estes caminhos têm de ser reconstruídos após a recuperação automática HA ou o reinício do Edge. O Reinício otimizado do BGP altera este comportamento ao garantir que os Edges pares não eliminam os caminhos se for estabelecida uma nova sessão dentro de um limite de tempo de reinício configurável.

Para obter o melhor desempenho, o cálculo de custos dinâmico (DCC) também deve ser ativado na empresa do cliente. Com o DCC ativado, as decisões de preferência e anúncio são locais para o Edge e o Edge sincroniza de Ativo para Em espera assim que aprende os caminhos do processo de routing. Para obter mais informações sobre o DCC, veja Descrição geral do routing do VMware SD-WAN e Configurar o cálculo de custos distribuídos.

A Sincronização de caminhos locais de HA só está disponível para empresas que utilizam o BGP. A Sincronização de caminhos locais de HA quando é utilizado o OSPF estará disponível numa versão futura.

Autenticação RADIUS numa Interface switched

Os clientes podem utilizar a autenticação RADIUS utilizando o protocolo 802.1x em portas switched, quando, anteriormente, estavam limitados às portas routed. A autenticação RADIUS de porta switched é configurada através de uma VLAN associada a essa porta. Esta melhoria beneficia os sites do cliente, onde não existem outros routers disponíveis para expandir o acesso local, mas que requerem autenticação segura de dispositivo através de 802.1x.

Ignorar endereço MAC (MAB)

Em interfaces routed, os clientes podem agora verificar os endereços MAC de acordo com uma lista num servidor RADIUS para ignorar 802.1x em dispositivos LAN que não suportam a autenticação 802.1x. A opção MAB simplifica as operações de TI, poupa tempo e aumenta a escalabilidade e já não requer que os clientes configurem manualmente todos os endereços MAC que possam precisar de autenticação.

O MAB baseado em RADIUS não é suportado para VLANs e, por isso, não pode ser utilizado para portas switched. O MAB baseado em RADIUS é suportado apenas para interfaces routed.

Alterações de configuração que provocam um reinício do Edge

Várias alterações de configuração do Edge que anteriormente acionavam um reinício do Serviço Edge já não o fazem na versão 5.1.0. Em particular, as alterações de configuração da interface Edge frequentemente utilizada, como a modificação de um endereço IP LAN do Edge numa interface switched ou a modificação de um IP CIDR, um prefixo CIDR ou um IP fixo, já não provocam um reinício disruptivo do Edge. Para ver uma lista completa, veja o artigo da Base de Dados de Conhecimentos Alterações da configuração do VMware SD-WAN Edge que podem acionar um reinício do serviço do Edge (60247).

SNMP

A versão 5.1.0 adiciona as seguintes melhorias ao SNMP:

  • SNMPv2, suporte para cadeias de comunidade adicionais e contadores de 64 bits.

  • SNMPv3, suporte para SHA2, nome de utilizador e palavras-passe adicionais, autenticação separada e chaves privadas.

  • A opção MIB adiciona a seguinte telemetria:

    • Ligação UUID ao mapeamento de nome de interface.

    • Largura de banda/capacidade de ligação.

    • Débito de ligação.

Aumento da capacidade de fluxo do Edge 2000, 3800 e 3810

Os modelos Edge 2000, 3800 e 3810 aumentam cada um a respetiva capacidade de fluxo máxima de 1,9 M para 3,8 M fluxos quando é utilizado o software Edge versão 5.1.0.

O modelo Edge 3400 não é afetado por esta alteração e a capacidade máxima de fluxo deste modelo continua a ser de 1,9 M fluxos.

Captura de pacotes (PCAP) em Gateways

Um utilizador pode iniciar um PCAP num Gateway através da IU do Orchestrator. Até 120 segundos de tráfego de Gateway podem ser capturados com a opção de definir filtros simples ou complexos para garantir que o utilizador está apenas a capturar o que precisa. Esta funcionalidade está acessível aos utilizadores da seguinte forma:

  • Os Administradores de parceiro podem iniciar um PCAP apenas nos seus próprios Gateways de parceiro.

  • Os operadores podem iniciar um PCAP em Gateways de parceiro e Gateways alojados.

Autoridade de certificados (AC) externa

Foram adicionados dois novos modos preparados para API à funcionalidade AC externa:

  • O modo manual fornece suporte a qualquer autoridade de certificados e oferece flexibilidade e controlo, permitindo ao utilizador realizar manualmente cada passo do processo de certificado.

  • O modo assíncrono fornece suporte a qualquer autoridade de certificados com a possibilidade de controlar os passos manuais e automatizar as tarefas recorrentes.

Destino Não-SD-WAN (NSD) e Túneis de Serviço de Segurança na Cloud (CSS)

Nas versões SD-WAN anteriores, os túneis para um NSD ou CSS apenas eram formados quando tráfego passava pelo mesmo e persistiam enquanto existisse tráfego. Na ausência de tráfego durante um período, o túnel era eliminado e tinha de ser reconstruído da próxima vez que tráfego fosse enviado em qualquer direção, provocando latência para esse tráfego enquanto o túnel era restabelecido. A partir da Versão 5.1.0, todos os túneis NSD e CSS serão acionados e estabelecidos quando qualquer serviço for configurado inicialmente e persistirá quer exista tráfego ou não durante qualquer período, melhorando a experiência do utilizador em qualquer dos serviços.

Notas importantes

Cadeia de comunidade alargada do BGP anexada aos prefixos do BGP

Os caminhos BGP intracluster são automaticamente etiquetados com uma comunidade do BGP interna que é anexada às comunidades do BGP existentes por cada Edge. Esta cadeia de comunidade adicional combina 1 byte para a contagem de hops e 3 bytes derivados do ID lógico do Edge. Como resultado, os clientes que utilizam o peering BGP no lado da LAN Spoke/Hub não devem filtrar os prefixos do BGP anunciados pelos Edges com a nova cadeia de comunidades do BGP.

Dead Peer Timeout (DPD) para Destinos Não-SD-WAN

A versão 5.1.0 introduz grandes alterações no Dead Peer Timeout (DPD) para Destinos Não-SD-WAN. Em versões anteriores, o valor predefinido do DPD era de 20 segundos e um utilizador podia desativar o DPD configurando o temporizador de tempo excedido de DPD como 0 segundos. Com a mudança do VMware SD-WAN para o kit de ferramentas QuickSec IPsec, o DPD é alterado da seguinte forma:

  • Intervalo de sonda: Exponencial (0,5 segundos, 1 segundo, 2 segundos, 4 segundos, 8 segundos, 16 segundos).

  • Intervalo DPD mínimo predefinido: 47,5 segundos (o QuickSec espera 16 segundos após a última nova tentativa. Assim, 0,5+1+2+4+8+16+16 = 47,5).

  • Intervalo de DPD mínimo padrão + tempo excedido de DPD (segundos): 67,5 segundos.

Em resultado das alterações acima, um utilizador não pode desativar o DPD configurando o temporizador de tempo excedido de DPD como 0 segundos. O valor de tempo excedido de DPD em segundos será adicionado ao valor mínimo predefinido de 47,5 segundos. Por isso, mesmo que um utilizador configurasse o DPD como 0 segundos, na realidade, o DPD seria de 47,5.

Funcionalidades que têm de ser configuradas no Orchestrator clássico

Com a versão 5.1.0, o VMware torna a nova interface do utilizador na interface predefinida do Orchestrator, permitindo ao utilizador realizar todas as tarefas de monitorização e configuração na mesma. No entanto, algumas funcionalidades não estão totalmente integradas na nova IU:

  • Secure Access – Definições Edge e Perfil

  • Zscaler – Definições Edge e Perfil

  • TACACS – Definições Edge e página dos serviços de rede

  • Definições de parceiro (Partner Settings) – Página de parceiros

Para configurar as funcionalidades acima, o cliente pode selecionar a opção Abrir Orchestrator clássico (Open Classic Orchestrator) na parte superior do ecrã do Orchestrator, o que abrirá um novo separador do browser com a IU clássica.


Estas funcionalidades serão totalmente integradas na nova interface do utilizador numa versão de software posterior do Orchestrator.

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

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

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

Até à versão 3.x, a configuração de filtro BGPv4 para o AS-PATH precedente do VMware SD-WAN suportava delimitadores baseados em vírgula e espaço. No entanto, a partir da versão 4.0.0 e posterior, o VMware SD-WAN 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 demorarão mais do que o normal (3-5 minutos) nos modelos Edge 3x00 (ou seja, 3400, 3800 e 3810) se o Edge for atualizado diretamente da versão 4.0.0, 4.0.1 ou 4.2.0. Isto deve-se a uma atualização de firmware que resolve o problema 53676. Se um Edge 3400 ou 3800 for atualizado para a versão 5.1.0 utilizando qualquer outra versão do Edge, o Edge será 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 forçar um modo de velocidade e duplex nas portas GE1–GE4 num modelo VMware SD-WAN Edge 620, 640 ou 680; nas portas GE3 ou GE4 num Edge 3400, 3800 ou 3810; ou num Edge 520/540 quando um SFP com interface de cobre é utilizado nas portas SFP1 ou SFP2, o utilizador pode descobrir que, mesmo após um reinício, a ligação não aparece. 

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

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

Idiomas disponíveis

O VMware SASE Orchestrator com a versão 5.1.0 está localizado nos seguintes idiomas: alemão, checo, chinês simplificado, chinês tradicional, coreano, espanhol, francês, grego, inglês, italiano, japonês e português (Portugal).

Alterações à API do Orchestrator

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

Alterações à API do portal do VMware SASE Orchestrator (“API v1”)

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

Prevemos que as seguintes alterações poderão exigir ações por parte dos programadores:

  • Problema 66795: Esta correção introduz um mecanismo através do qual um Token de API só será válido e aceite pelo Orchestrator para utilizadores não nativos se estiverem no estado ativado (enabled) e se o utilizador SSO estiver ativo no respetivo Fornecedor de identidade. Se um utilizador não nativo se tornar inativo (por outras palavras, eliminado no IdP ou não tiver um token de atualização válido), todos os tokens de API deste utilizador serão revogados através de uma tarefa de back-end.

  • Os tokens emitidos em nome de um utilizador ativado por SSO antes desta correção estão sujeitos a um comportamento legado, segundo o qual, o Orchestrator continuará a honrá-los até expirarem.

  • Os utilizadores SSO dos fornecedores de identidade que não suportam tokens de atualização ou ponto final de introspeção não serão autorizados a utilizar a funcionalidade Autenticação baseada em tokens (Token Based Authentication). 

  • Problema 87878:vcoInventory/getPendingInventory alterou o payload de resposta. Campos removidos token, vcoInstanceLogicalId, vcoUrl, edgeMappingId, enterpriseId, enterpriseProxyId, uuid, mac, imei, owner. Não são utilizados no front-end e não afetam a IU porque estes campos não foram utilizados na IU. Esta API destina-se a ser utilizada para obter uma lista de Edges com disponibilidade ZTP e estes campos não são necessários para a atribuição de Edge (apenas é necessário o serialNumber). Assim, se um cliente utilizar esta API para ZTP e tiver uma validação de payload restrita que possa afetá-lo (depende da sua implementação). Em geral – a informação fornecida é suficiente para um fluxo ZTP bem sucedido.

  • Problema 84303: Foi adicionada uma validação para o atributo maxHop de vizinho BGP para não permitir a configuração de um valor maxHop inferior a 2 quando um localIP vizinho está presente. Anteriormente, a configuração de um valor maxHop como 1 era permitida, independentemente de o localIP vizinho estar ou não presente. Com esta alteração, sempre que um localIP vizinho está presente, o valor de max-hop mínimo permitido é 2 e, se um utilizador tentar configurar um valor maxHop inferior a 2, receberá o erro Invalid MaxHop for Neighbor. MaxHop value ranges from 2 to 255 when localIp is present. Está a ser criada uma correção para a configuração existente.

  • Problema 84114: A migração de dispositivos cliente do MySQL para ClickHouse eliminou o campo clientDeviceId. Como não identificámos um cliente externo utilizando o campo clientDeviceId, o impacto deverá ser insignificante. O único cliente que utiliza o ponto final dos dispositivos cliente com clientDeviceId parece ser a IU clássica do Orchestrator. A IU foi melhorada para atualizar ou obter registos no ClickHouse utilizando a combinação logicalId ou ipAddress e macAddress. Devem seguir-se os clientes externos quando for utilizado o ponto final do dispositivo cliente para atualizar o nome de anfitrião ou para obter dispositivos específicos por ID.

Alterações à API v2 do VMware SASE Orchestrator

  • Problema 98750: O campo lastContact no registo Edge devolvido pelas APIs relacionadas com o Edge será depreciado e não deverá continuar a ser utilizado. Em vez disso, deverá ser utilizado o campo edgeState na resposta para determinar o estado real do Edge como única fonte fidedigna. Se algum código cliente alguma vez utilizar lastContact e não puder substituí-lo por edgeState, a API v1 ainda fornecerá um lastContact preciso na resposta, que poderá ser utilizado como um compromisso, mas não é recomendado.

  • Problema 30901: Com a funcionalidade Visibilidade de fluxo (Flow Visibility) incluída na versão 5.1.0, a cláusula obrigatória groupBy já não será necessária para flowstats. Se a cláusula groupBy não for mencionada, por predefinição, consideramos que o ponto final de API está a consultar ou a chamar o ponto final da API de visibilidade de fluxo que, por sua vez, efetua a resolução para todos os resolvedores, como aplicações, dispositivos cliente, etc. Contudo, isto apenas é aplicável para a chamada de API da métrica de estatística de fluxo e a API de série de estatística de fluxo é mantida inalterada.

  • Problema 95089: O módulo de limitação de taxa de APIv2 não tem imposto a mesma política predefinida que o limitador de taxa de API do Portal, o que sempre foi a nossa intenção. Uma mudança nesta versão afeta essa política para a APIv2. Recomendamos aos utilizadores que revejam as melhores práticas para evitar acionar o limitador de taxa e gerir as respostas em que a limitação da taxa é acionada.

Nota sobre a 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, algumas ligações permanentes para páginas específicas que estavam anteriormente presentes em code.vmware.com poderão deixar de funcionar como esperado.

Juntamente com a migração, a VMware continuará a utilizar o Portal de documentação do programador em https://developer.vmware.com/apis, onde reside agora toda a documentação da API ddo VMware SASE/SD-WAN.

Histórico de revisões do documento

18 de dezembro de 2023. Vigésima quarta edição.

  • Foi adicionada uma nova compilação rollup R51010-20231215-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a décima compilação rollup do Orchestrator e é a nova compilação GA predefinida do Orchestrator para a versão 5.1.0.

  • A compilação R51010-20231215-GA do Orchestrator inclui as correções para os problemas 117941, 125006, 128310, 129239 e 131789, sendo que cada uma delas está documentada nesta secção.

9 de outubro de 2023. Vigésima terceira edição.

  • Foi adicionada uma nova compilação rollup R5109-20231003-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a nona compilação rollup do Orchestrator e é a nova compilação GA predefinida do Orchestrator para a versão 5.1.0.

  • A compilação R5109-20231003-GA do Orchestrator inclui as correções para os problemas 128310 e 119938, sendo que cada uma delas está documentada nesta secção.

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

20 de setembro de 2023. Vigésima segunda edição.

  • Foi adicionada uma nova compilação rollup R5108-20230916-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a oitava compilação rollup do Orchestrator e é a nova compilação GA predefinida do Orchestrator para a versão 5.1.0.

  • A compilação R5108-20230916-GA do Orchestrator inclui as correções para os problemas 94610, 104775, 105580, 106191, 115981, 116531, 117822, 118728, 121085, 121441, 121469 e 124778, sendo que cada uma delas está documentada nesta secção.

  • O problema pendente 62701 foi movido dos Problemas conhecidos do Edge/Gateway para a secção Problemas resolvidos do Edge/Gateway na compilação GA original R5100-20221204-GA. Esta ação deveria ter sido realizada na 1.ª edição destas Notas de versão.

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

  • Para melhorar a experiência do utilizador, o Histórico de revisões do documento foi reorganizado de forma a ser lido das entradas mais recentes para as mais antigas.

22 de agosto de 2023. Vigésima primeira edição.

3 de agosto de 2023. Vigésima edição.

26 de julho de 2023. Décima nona edição.

  • Foi adicionado o Problema resolvido 103708 à secção Problemas resolvidos do Edge/Gateway da segunda compilação rollup do Edge R5102-20230310-GA. Este problema foi omitido da décima edição das Notas de versão 5.0.1.

23 de julho de 2023. Décima oitava edição.

  • Foi adicionada uma nova compilação rollup R5107-20230722-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a sétima compilação rollup do Orchestrator e é a nova compilação GA predefinida do Orchestrator para a versão 5.1.0.

  • A compilação R5107-20230722-GA do Orchestrator inclui a correção para o problema 122271, que se encontra documentado nesta secção.

  • O Problema pendente 53359 foi removido da secção Problemas conhecidos do Edge/Gateway, já que foi corrigido na versão 4.3.0.

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

15 de julho de 2023. Décima sétima edição.

6 de julho de 2023. Décima sexta edição.

  • Foi adicionada uma nova compilação rollup R5106-20230705-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a sexta compilação rollup do Orchestrator e é a nova compilação GA predefinida do Orchestrator para a versão 5.1.0.

  • A compilação R5106-20230705-GA do Orchestrator inclui as correções para os problemas 84772, 115411, 115433, 116633, 117772, 117988, 117993, 118074, 118544, 118733, 119733 e 120606, sendo que cada uma é documentada nesta secção.

  • Foi adicionado o Problema resolvido 95565 à secção Problemas resolvidos do Edge/Gateway da compilação original R5100-20221204-GA. Este problema foi omitido por engano nas Notas de lançamento originais da versão 5.1.0.

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

  • Foi adicionado o Problema pendente 112826 à secção Problemas conhecidos do Orchestrator.

23 de junho de 2023. Décima quinta edição.

  • Foi adicionada uma nova compilação rollup R5103-20230621-GA do Gateway à secção Problemas resolvidos do Edge/Gateway. Esta é a terceira compilação rollup do Gateway e é a nova compilação GA do Gateway para a versão 5.1.0.

  • A compilação R5103-20230621-GA do Gateway inclui as correções para os problemas 82808, 100172, 101536, 104619, 107309, 108473, 111646, 111888, 111924, 112016, 112017, 112019, 112020, 112800, 114052, 114084, 114282, 114932, 115604, 115692 e 116182, sendo que cada uma delas está documentada nesta secção.

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

13 de junho de 2023. Décima quarta edição.

  • Foi adicionada uma nova compilação rollup R5105-20230611-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a quinta compilação rollup do Orchestrator e é a nova compilação GA do Orchestrator para a versão 5.1.0.

  • A compilação R5105-20230611-GA do Orchestrator inclui as correções para os problemas 87089, 105861, 106295, 107180, 107766, 110826, 111957, 112044, 112333, 112451, 112500, 112605, 112809, 112906, 112912, 112992, 113209, 113254, 113366, 113375, 113963, 114240, 114291, 114564, 114602, 114912, 115307, 115439, 115624, 115653, 115719, 116141, 116523, 116770, 116790, 116976, 117527, 117800 e 118071.

  • Foram adicionados os seguintes Problemas em aberto à secção Problemas conhecidos do Edge/Gateway: 82808, 107309, 111924, 112016, 112017, 112019, 114084, 114282, 115692 e 116182. Todos estes problemas afetam o VMware SD-WAN Gateway.

11 de maio de 2023. Décima terceira edição.

  • Foram adicionados os seguintes Problemas em aberto à secção Problemas conhecidos do Edge/Gateway: 108473, 111646, 111888, 112020, 112800, 114052 e 114932. Todos estes problemas afetam o VMware SD-WAN Gateway.

27 de abril de 2023. Décima segunda edição.

  • Foi adicionada uma nova compilação rollup R5104-20230426-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a quarta compilação rollup do Orchestrator para a versão 5.1.0.

  • A compilação R5104-20230426-GA do Orchestrator inclui as correções para os problemas 95631, 104785, 106327, 106929, 107071, 107349, 107980, 108072, 108363, 109284, 109300, 109532, 109533, 109715, 109788, 109836, 109911, 110094, 110330, 110946, 111104, 111407, 111444, 111665, 111934, 111944, 111946, 112094, 112201, 112224, 112437, 112458, 112885 e 114475. Cada edição está documentada nesta secção.

  • Dois dos pedidos corrigidos, 106907 e 106929, foram originalmente marcados como corrigidos na versão 5.1.0.2 do Orchestrator. No entanto, as correções estavam incompletas na versão 5.1.0.2 e os problemas só ficaram totalmente resolvidos na versão 5.1.0.4 do Orchestrator. Como resultado, estes pedidos foram removidos da secção Problemas resolvidos da versão 5.1.0.2 do Orchestrator e movidos para a 5.1.0.4.

  • Foi adicionado o problema 94612 à secção Problemas resolvidos do Edge/Gateway da compilação original R5100-20221204-GA. Este problema foi omitido por engano nas Notas de lançamento originais da versão 5.1.0.

  • Foi atualizada a secção Compatibilidade para marcar todas as versões 3.x como tendo chegado ao fim da vida útil (EOSL). Também foi atualizada a secção 4.x para marcar os Orchestrators e os Gateways 4.2.x como tendo chegado ao fim da vida útil (EOSL).

  • Foi adicionada uma nota às Notas importantes com o título Cadeia de comunidade alargada do BGP anexada aos prefixos do BGP. Consulte-a para obter mais detalhes.

15 de março de 2023. Décima primeira edição.

  • Foi adicionada uma nova compilação rollup R5103-20230315-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a terceira compilação rollup do Orchestrator para a versão 5.1.0.

  • A compilação R5103-20230315-GA do Orchestrator inclui as correções para os problemas 107587, 107725, 108533, 108833 e 109064. Cada edição está documentada nesta secção. R5104-202304xx-GA

14 de março de 2023. Décima edição.

  • Foi adicionada uma nova compilação rollup R5102-20230310-GA do Edge/Gateway à secção Problemas resolvidos do Edge/Gateway. Esta é a segunda compilação rollup do Edge/Gateway e é a nova compilação GA do Edge e do Gateway para a versão 5.1.0.

  • A compilação R5102-20230310-GA do Edge/Gateway inclui as correções para os problemas 98782, 104141, 105744 e 106587, sendo que cada uma delas está documentada nesta secção.

6 de março de 2023. Nona edição.

  • Na secção Novas melhorias do SD-WAN, foi feita a revisão da entrada Aumento da capacidade de fluxo do Edge 3x00. A entrada original excluiu o 2000 e incluiu erradamente o Edge 3400. A entrada revista passa a ter a seguinte redação:

    • Aumento da capacidade de fluxo do Edge 2000, 3800 e 3810

    • Os modelos Edge 2000, 3800 e 3810 aumentam cada um a respetiva capacidade de fluxo máxima de 1,9 M para 3,8 M fluxos quando é utilizado o software Edge versão 5.1.0.

    • Foi adicionada um nota para deixar claro que o modelo Edge 3400 não é afetado por esta alteração e que a capacidade máxima de fluxo deste modelo continua a ser de 1,9 M fluxos.

28 de fevereiro de 2023. Oitava edição.

  • Substituiu a compilação rollup R5102-20230216-GA do Orchestrator pela R5102-20230222-GA. A nova compilação do Orchestrator corrige um problema de atualização visto pela equipa de operações do VMware ao atualizar um Orchestrator para a compilação R5102-20230216-GA. O problema de atualização foi causado por uma incompatibilidade de versão no manifesto do pacote de atualização.

  • A nova compilação também inclui correções para: 106907, 108074 e 108309.

17 de fevereiro de 2023. Sétima edição.

  • Foi adicionada uma nova compilação rollup R5102-20230216-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a segunda compilação rollup do Orchestrator para a versão 5.1.0.

  • A compilação do Orchestrator R5102-20230216-GA inclui as correções dos problemas 40584, 105610, 106159, 106242, 106592, 106806, 106929, 107410, 107637 e 107885. Cada edição está documentada nesta secção.

  • Foi adicionado o problema 89725 à secção Problemas resolvidos do Edge/Gateway da compilação original R5100-20221204-GA. Este problema foi omitido por engano nas Notas de lançamento originais da versão 5.1.0.

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

29 de janeiro de 2023. Sexta edição.

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

  • Na secção Novas melhorias do SD-WAN, foi adicionada a melhoria Túneis de Destino Não-SD-WAN (NSD) e Serviço de Segurança na Cloud (CSS). Isto foi omitido na primeira edição das Notas de lançamento por erro.

  • Na secção Notas importantes, foi adicionada uma nota em Dead Peer Timeout (DPD) para Destinos Não-SD-WAN. Esta nota abrange as alterações de comportamento para o DPD em resultado da mudança do software VMware SD-WAN para o kit de ferramentas Quicksec IPsec. Este material foi omitido na primeira edição das Notas de lançamento por erro.

20 de janeiro de 2023. Quinta edição.

  • Foi adicionada uma nova compilação rollup R5101-20230112-GA do Gateway à secção Problemas resolvidos do Edge/Gateway. Esta é a primeira compilação rollup do Gateway e é a nova compilação GA do Gateway para a versão 5.1.0.

  • A compilação R5101-20230112-GA do Gateway inclui as correções para os problemas 97272 e 104487, sendo que cada uma delas está documentada nesta secção.

  • Foi alterado o idioma para a Função melhorada MAC Address Bypass (MAB) para esclarecer que esta função não é suportada para VLANs e, assim, não pode ser utilizada para portas switched que dependem de uma VLAN para a autenticação 802.1x. Assim, o MAB apenas é suportado em interfaces routed a partir desta versão 5.1.0.

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

  • Foi adicionado texto sobre duas melhorias da versão 5.1.0: Sincronização de caminhos locais de HA e Reinício otimizado do BGP.

5 de janeiro de 2023. Terceira edição.

  • Foi adicionada uma nova compilação rollup R5101-20221220-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a primeira compilação rollup do Orchestrator para a versão 5.1.0.

  • A compilação R5101-20221220-GA do Orchestrator inclui as correções para os problemas 100133, 101835, 102806 e 103622, sendo que cada uma delas está documentada nesta secção.

15 de dezembro de 2022. Segunda edição.

  • Problema em aberto 39134 removido dos Problemas conhecidos do Edge/Gateway, uma vez que a engenharia concluiu que foi corrigido e este pedido já tinha sido adicionado por engano aos Problemas resolvidos do Edge/Gateway na primeira edição das notas de versão 5.1.0.

8 de dezembro de 2022. Primeira edição.

Problemas resolvidos do Edge e do Gateway

Resolvido na versão R5103-20230621-GA do Gateway

A compilação R5103-20230621-GA do Gateway foi lançada a 23/06/2023 e é o terceiro rollup do Gateway para a versão 5.1.0.

Esta compilação rollup do Gateway aborda os problemas críticos abaixo desde a segunda compilação rollup R5102-20230310-GA do Gateway.

  • Problema 82808 resolvido: no caso de um VMware SD-WAN Edge que esteja a utilizar um Serviço de Segurança na Cloud (CSS) e tenha ativado a Verificação de estado de funcionamento de L7 (L7 Health Check), o cliente poderá observar falhas de tráfego ao utilizar estes túneis do CSS, mesmo que o VMware SASE Orchestrator continue a marcar os túneis como UP.

    Embora a pesquisa L7 falhe com um erro 4XX HTTP, o VMware SD-WAN Gateway não reconhece a falha e não informa o Orchestrator para marcar os túneis do CSS como INATIVOS.

  • Problema 100172 resolvido: se um utilizador tentar um SSH para um Edge através do VMware SD-WAN Gateway, o Gateway poderá registar uma falha no Serviço dataplane, gerar um núcleo, seguido de um reinício para recuperar.

    O Gateway pode encontrar esse problema quando um utilizador está a tentar um SSH para um Edge através do Gateway e essa sessão SSH gera uma mensagem de erro FRAG_NEEDED ICMP.

  • Problema 101536 resolvido: um VMware SD-WAN Gateway pode sofrer uma falha do Serviço dataplane, gerar um núcleo e reiniciar para recuperar.

    Ao procurar no ficheiro principal, o utilizador observa um registo relacionado com o monitor mutex do Gateway, o que pode ocorrer quando o Hub e Cluster Interconnect estão a ser utilizados pela empresa do cliente ligada a esse Gateway.

  • Problema 104619 resolvido: quando duas ou mais empresas partilham o mesmo Gateway de parceiro e todas têm uma configuração de handoff de parceiro em que as empresas estão a utilizar o IPv4, se um handoff de parceiro numa empresa for removido, o estabelecimento da associação de segurança (SA) falha para as outras empresas ligadas a esse Gateway de parceiro.

    Por exemplo, se existirem duas empresas chamadas Empresa-1 e Empresa-2 a utilizar um Gateway de parceiro, e estiver configurado um handoff de parceiro em ambas as empresas, o serviço SD-WAN define um único endereço IP na interface de rede virtual do Gateway. Se um utilizador desativar o handoff de parceiro na Empresa-2, o serviço SD-WAN passa ao fluxo seguinte e elimina este endereço IP da interface de rede virtual, mesmo que o mesmo endereço IP esteja a ser utilizado para o handoff da Empresa-1. Como tal, a Empresa-1 não poderá estabelecer túneis IPsec com os respetivos Edges.

    Se este problema ocorrer num Gateway sem uma correção, a reinicialização do Gateway corrigirá o problema.

  • Problema 107309 resolvido: Quando um cliente configura a verificação do estado de funcionamento L7 para um Destino Não-SD-WAN através do Edge num Orchestrator 4.x e o Orchestrator é atualizado para a versão 5.x, se o cliente tentar modificar o valor de repetição da pesquisa L7, o Edge não aplicará o novo valor.

    Por exemplo, se o valor de repetição da pesquisa da verificação do estado de funcionamento L7 for 3 (o túnel está marcado como inativo em 3 pesquisas com falha) e o cliente alterar esse valor para 1, a verificação do estado de funcionamento L7 continuará a utilizar o valor original de 3 repetições antes de o túnel ser marcado como inativo.

  • Problema 108473 resolvido: um VMware SD-WAN Gateway pode sofrer uma falha do Serviço dataplane, gerar um núcleo e reiniciar para recuperar o serviço.

    O Gateway pode entrar numa situação em que existe um excesso de números de sequência, o que aciona uma eliminação de todas as SAs (associações de segurança IPsec). Ao tentar eliminar todas as SAs, o processo do Gateway tenta localizar um túnel com base num ID de túnel, mas o túnel não existe, o que causa uma falha de serviço do Gateway.

  • Problema 111646 resolvido: um VMware SD-WAN Gateway com uma carga de CPU elevada pode sofrer uma falha do Serviço dataplane e reiniciar para recuperar.

    Ao observar o núcleo gerado pelo Gateway, o utilizador veria a exceção do monitor mutex e a mensagem Program terminated with signal SIGXCPU, CPU time limit exceeded message. O problema está relacionado com um processo do Gateway que liberta um bloqueio de thread de prioridade mais baixa.

  • Problema 111888 resolvido: um VMware SD-WAN Gateway implementado com 4 núcleos e mais de 2000 túneis ligados pode ter uma elevada utilização da CPU e os túneis ligados ao Gateway podem ser instáveis.

    Um dos threads do Gateway está a utilizar muita capacidade de CPU num Gateway de 4 núcleos, o que está a prejudicar a capacidade do Gateway de manter túneis estáveis.

  • Problema 111924 resolvido: um cliente pode observar que, em todos os seus sites, o tráfego multicaminho (por outras palavras, o tráfego que atravessa o VMware SD-WAN Gateway) está a ser descartado, mesmo que os túneis do VMware SD-WAN Edge para o Gateway estejam ativos e estáveis.

    Não há limite para o número máximo de vezes que um Gateway pode retransmitir um pacote VCMP (protocolo de gestão do SD-WAN), e essas retransmissões podem sobrecarregar as ligações de baixa largura de banda. Essas retransmissões também causarão uma acumulação de pacotes no programador quando o Edge tem uma ligação de baixa largura de banda, uma vez que as retransmissões não podem ser drenadas suficientemente rápido. Eventualmente, as filas do programador ficam cheias e levam o programador a descartar pacotes de todos os Edges. O tráfego direto que não utiliza o Gateway não será afetado por este problema.

    Quando é encontrado este problema e está a ser emitido um Gateway sem uma solução para o mesmo, a única forma de o corrigir será o utilizador operador identificar os Edges que estão a provocar a acumulação de pacotes no programador utilizando o comando debug.py --qos_dump_net e bloqueá-los no Gateway afetado.

  • Problema 112016 resolvido: um VMware SD-WAN Gateway pode sofrer várias falhas do serviço dataplane com núcleos gerados após iniciada a reinicialização de um gateway.

    Ao examinar os núcleos, um operador observaria que cada falha é desencadeada por um problema com o monitor mutex. Ocorre um aumento de tempo percetível no processamento do VCMP (protocolo de gestão do SD-WAN) realizado para o thread que o gere. Durante um arranque do Gateway, isso faz com que o thread do VCMP seja executado continuamente a 100% por longos períodos (mais de 60 segundos), provocando múltiplas falhas do serviço de Gateway relacionadas com o monitor mutex.

  • Problema 112017 resolvido: um operador pode observar que um VMware SD-WAN Gateway implementado com 4 núcleos sofre uma carga elevada, o que leva a uma ou mais falhas do serviço dataplane.

    Os logs de núcleo do Gateway apontariam para uma falha do serviço desencadeada pelo monitor mutex. Existem vários pedidos que abordam o sintoma acima e, neste caso, a causa deve-se ao facto de os threads de VCMP (protocolo de gestão) maximizarem os processos da CPU de um Gateway de 4 núcleos, o que aciona o monitor mutex. Este pedido adiciona a possibilidade de permitir que um utilizador Operador configure um limite de 20 ligações semiabertas VCMP. Isso pode ser efetuado através da interface de linhas de comando (CLI) do Gateway utilizando debug.py ou através de um ficheiro de configuração estática.

  • Problema 112019 resolvido: um VMware SD-WAN Gateway pode encontrar uma falha do Serviço dataplane e reiniciar para recuperar quando a carga da CPU é elevada.

    Como acontece com outros pedidos de falha do serviço Gateway na compilação rollup 5.1.0.3, o Operador ou Parceiro veria um acionamento de monitor mutex no ficheiro de núcleo. Com este pedido, a correção consiste em mover os logs de depuração NAT para fora do âmbito do bloqueio da tabela NAT para evitar uma das causas desse problema.

  • Problema 112020 resolvido: um VMware SD-WAN Gateway implementado com 4 núcleos com uma carga de CPU elevada pode sofrer uma falha do Serviço dataplane e reiniciar como resultado.

    Ao observar o ficheiro dos núcleos do Gateway, um utilizador veria uma falha no monitor mutex provocada pelo facto de não ser possível executar um processo do Gateway porque a CPU está a ser executada na capacidade máxima devido a uma contagem de túneis elevada.

  • Problema 112800 resolvido: os clientes que utilizam um VMware SD-WAN Gateway podem deparar-se com um desempenho fraco, incluindo túneis e caminhos que demoram muito mais tempo a convergir.

    Ao consultar a monitorização de um Gateway, um utilizador verá os núcleos do plano de dados (dp-cores) a funcionar a 100%, em resultado de o Gateway não limpar os fluxos do distribuidor de fluxos obsoletos.

  • Problema 114052 resolvido: um VMware SD-WAN Gateway pode sofrer uma falha do Serviço dataplane, gerar um núcleo e, como resultado, reiniciar.

    O problema é causado por um thread no processo IPsec do Gateway que excede o tempo limite e aciona uma falha de serviço do Gateway.

  • Problema 114084 resolvido: no caso de um cliente que tenha configurado um Serviço de Segurança na Cloud (CSS) do tipo Zscaler com Verificação de estado de funcionamento de L7 (L7 Health Check) para um VMware SD-WAN Edge, ao atualizar o Servidor de Cloud Zscaler no VMware SASE Orchestrator, os detalhes atualizados não são aplicados ao Edge.

    Apesar de o Orchestrator mostrar a nova configuração do Servidor de Cloud Zscaler, o Edge e o Gateway não enviam tráfego nem as pesquisas L7 através deste novo servidor, mas sim através do antigo servidor Zscaler.

  • Problema 114282 resolvido: quando um VMware SD-WAN Gateway implementado com 4 núcleos é reiniciado, podem ser necessários até 20 minutos para convergir ~3000 túneis para as empresas de cliente ligadas.

    A expetativa é que um Gateway convirja ~3000 túneis em ~5 minutos em comparação com os 20 minutos observados nesta versão. A velocidade mais lenta causaria uma perturbação do tráfego do cliente até os túneis serem totalmente restaurados. A causa da convergência mais lenta é atribuída a uma configuração no processo IPsec do Gateway que gere as associações e chaves de segurança e que é corrigida com este pedido.

  • Problema 114932 resolvido: os utilizadores cliente do VMware SD-WAN Edge podem registar uma degradação do desempenho do tráfego que atravessa o VMware SD-WAN Gateway principal do Edge.

    Os utilizadores operadores podem observar uma utilização elevada da CPU no Gateway, mesmo que a contagem de túneis esteja dentro dos limites suportados. A utilização elevada da CPU resulta de uma SA (associação de segurança) IKE obsoleta que permanece durante mais tempo na tabela IKE e faz com que os túneis que demorem mais tempo a convergir, o que causa maiores quedas de tráfego e instabilidade do caminho para o tráfego do cliente que atravessa o Gateway.

  • Problema 115604 resolvido: um VMware SD-WAN Edge ou Gateway pode registar uma falha no Serviço dataplane e gerar um núcleo com uma afirmação no início de sessão.

    Quando um Edge ou Gateway processa um pacote corrompido, o software pode atingir uma afirmação onde o comprimento do pacote do utilizador atual é superior à memória intermédia do pacote interno. Espera-se que o Gateway descarte esse tipo de pacote e impeça que o mesmo seja enviado para o Edge, mas em vez disso processa-o e isso resulta numa falha do serviço e reinicialização.

  • Problema 115692 resolvido: um operador pode observar uma escalada da utilização da memória num VMware SD-WAN Gateway, o que pode levar ao esgotamento da memória e à reinicialização do serviço defensivo para limpar a memória.

    Nesse caso, o gateway regista uma fuga de memória IKE no Gateway que renova certificados com sites de pares.

    Sem uma correção para esse problema, o Operador apenas pode monitorizar a utilização da memória no Gateway e reiniciar proativamente o Gateway numa janela de manutenção que garanta o mínimo de perturbação nos sites do cliente que utilizam o Gateway.

  • Problema 116182 resolvido: um VMware SD-WAN Gateway pode sofrer uma falha do Serviço dataplane, gerar um núcleo e, como resultado, reiniciar.

    Este problema é observado em gateways em que os SD-WAN Edges ligados são configurados com uma política de backhaul de Internet que utiliza IPv6 ou o modo misto IPv4/IPv6 para um destino não-SD-WAN (NSD) via gateway. Neste cenário, quando o gateway recebe pacotes IPv6 destinados a um NSD que utiliza IPv4, isso aciona a falha do serviço de gateway.

Resolvido na versão R5102-20230310-GA do Edge/Gateway

A compilação R5102-20230310-GA do Edge/Gateway foi lançada em 14-03-2023 e é a segunda compilação rollup do Edge/Gateway para a versão 5.1.1.

Esta compilação rollup do Gateway aborda os problemas críticos abaixo desde a primeira compilação rollup, R5101-20230112-GA, do Edge/Gateway.

  • Problema 98782 resolvido: Um VMware SD-WAN Gateway pode sofrer uma falha no Serviço dataplane durante o estabelecimento do túnel IPsec, o que gera um núcleo e resulta no reinício.

    Quando um Gateway regista este problema, o reinício pode resultar numa breve interrupção do tráfego do cliente para os Edges ligados a esse Gateway e a Destinos Não-SD-WAN através do Gateway para túneis IPsec. O problema é causado por uma condição race quando o Gateway que está a estabelecer um túnel IPsec aciona a falha no Serviço dataplane.

  • Problema 103708 resolvido: quando novas regras são adicionadas numa configuração de filtro BGP, pode haver caminhos BGP inesperados recebidos e enviados pelo VMware SD-WAN Edge.

    Quando novas regras são adicionadas aos filtros BGP a partir do Orchestrator, as listas de prefixos são adicionadas na configuração de routing do Edge sem que sejam removidas as entradas antigas. Este comportamento resulta em listas de prefixos de caminho obsoletos e num comportamento de filtragem inesperado.

  • Problema 104141 resolvido: Os utilizadores por trás de um VMware SD-WAN Edge ou os clientes ligados a um VMware SD-WAN Gateway podem enfrentar problemas significativos relacionados com tráfego que esteja a utilizar esse Edge ou a atravessar esse Gateway ao ponto de não ser encaminhado qualquer tráfego.

    Quando o problema ocorre, o Edge ou o Gateway tem um número ilimitado de memórias intermédias (mbufs) a serem consumidas pela fila de memória intermédia de distorção devido ao aumento dos carimbos de data/hora do túnel de gestão recebidos de um par, o que aciona a capacidade reduzida dos números inteiros no cálculo da distorção, fazendo com que os pacotes sejam colocados na memória intermédia efetivamente de forma indefinida. Inicialmente, afeta apenas os fluxos colocados na memória intermédia, mas, durante um período longo o suficiente, o número de mbufs consumidos na fila de memória intermédia de distorção aproxima-se do total de mbufs disponíveis e o dispositivo SD-WAN (Edge ou Gateway) pode tornar-se incapaz de encaminhar todo o tráfego. Se isso afetar um Gateway, afetará apenas o tráfego multicaminho que atravessa o Gateway e o tráfego do cliente que vai direto não será afetado.

    Há outro pedido de suporte, 105744, que também aborda os sintomas encontrados aqui, mas corrige uma causa separada. Diferença entre os dois pedidos de suporte: a correção incluída no 104141 aborda as memórias intermédias que estão a ser consumidas pela fila de memória intermédia de distorção devido ao aumento dos carimbos de data/hora de gestão recebidos pelo par. A correção incluída no 105744 restringe a contagem da memória intermédia de distorção a 25% do total de memórias intermédias, independentemente do que possa acontecer, para garantir que este problema não volta a ocorrer.

    Sem uma correção para este problema para o Edge ou o Gateway, um utilizador pode monitorizar a utilização da memória intermédia (mbuf) no Orchestrator e procurar uma maior utilização da mbuf devido ao facto de os pacotes estarem a ser colocados em fila na memória intermédia de distorção. Se o utilizador observar o problema, poderá remover os fluxos para o Edge (através do Diagnóstico remoto) ou o Gateway para atenuar temporariamente o problema, mas o problema acabará por voltar a ocorrer até que a correção seja aplicada.

  • Problema 105744 resolvido: Os utilizadores por trás de um VMware SD-WAN Edge ou os clientes ligados a um VMware SD-WAN Gateway podem enfrentar problemas significativos relacionados com tráfego que esteja a utilizar esse Edge ou a atravessar esse Gateway ao ponto de não ser encaminhado qualquer tráfego.

    Este pedido de suporte e o Problema 104141 estão diretamente relacionados e têm os mesmos sintomas e causa, que serão repetidos aqui: quando o problema ocorre, o Edge ou o Gateway tem um número ilimitado de memórias intermédias (mbufs) a serem consumidas pela fila de memória intermédia de distorção devido ao aumento dos carimbos de data/hora do túnel de gestão recebidos de um par, o que aciona a capacidade reduzida dos números inteiros no cálculo da distorção, fazendo com que os pacotes sejam colocados na memória intermédia efetivamente de forma indefinida. Inicialmente, afeta apenas os fluxos colocados na memória intermédia, mas, durante um período longo o suficiente, o número de mbufs consumidos na fila de memória intermédia de distorção aproxima-se do total de mbufs disponíveis e o dispositivo SD-WAN (Edge ou Gateway) pode tornar-se incapaz de encaminhar todo o tráfego. Se isso afetar um Gateway, afetará apenas o tráfego multicaminho que atravessa o Gateway e o tráfego do cliente que vai direto não será afetado.

    Diferença entre os dois pedidos de suporte: a correção incluída no 104141 aborda as memórias intermédias que estão a ser consumidas pela fila de memória intermédia de distorção devido ao aumento dos carimbos de data/hora de gestão recebidos pelo par. A correção incluída no 105744 restringe a contagem da memória intermédia de distorção a 25% do total de memórias intermédias para garantir que esse problema não volta a ocorrer.

    Sem uma correção para este problema para o Edge ou Gateway, é possível proceder à sua monitorização no Orchestrator, onde um utilizador iria procurar uma maior utilização da mbuf devido ao facto de os pacotes estarem a ser colocados em fila na memória intermédia de distorção e o utilizador pode esvaziar fluxos para o Edge ou Gateway para atenuar temporariamente o problema, mas o problema acabará por se repetir até que a correção seja aplicada.

  • Problema 106587 resolvido: Um cliente pode observar que todo o tráfego está a ser removido aleatoriamente e que o estado se mantém.

    O problema está relacionado com a instalação da Associação de segurança (SA) do IPsec no lado do dispositivo de resposta. Quando o Edge inicia uma nova SA ou faz uma recodificação, o pacote do Índice de parâmetros de segurança (SPI) da SA antiga pode chegar antes da nova SA (SPI). Nesse caso, o VMware SD-WAN Gateway elimina a SA (SPI) recém-criada. A correção adicionada impedirá a eliminação da nova SA (SPI) criada.

    Sem uma correção para este problema, um utilizador parceiro ou operador teria de reinicializar o Gateway para reiniciar todos os túneis IPsec afetados.

Resolvido na versão R5101-20230112-GA do Gateway

A compilação R5101-20230112-GA do Gateway foi lançada a 19-01-2023 e é o primeiro rollup do Gateway para a versão 5.1.0.

Esta compilação rollup do Gateway aborda os problemas críticos abaixo desde a compilação de Gateway original R5100-20221204-GA.

  • Problema 97272 resolvido: num site com topologia de Alta Disponibilidade em que o OSPF é utilizado, quando o site tem uma condição “split brain” (ambos os SD-WAN Ed ges estão Ativos), o caminho predefinido para o router central é removido e o site HA não consegue alcançar os sites de pares na rede.

    A idade do anúncio do estado de ligação (LSA) do router central é sincronizada com o Edge ativo. Quando existe uma condição “split brain” de um HA, o Edge em modo de espera muda para ativo e envia uma nova idade do LSA para o router central. Uma vez que tanto o Edge ativo como o Edge em espera têm o mesmo ID de router, uma idade do LSA diferente é enviada pelo novo Edge ativo. Esta falta de correspondência faz com que a idade do LSA seja definida para um valor máximo de 3600 no router central, que também remove o caminho principal para o site HA, resultando numa paragem completa no site.

  • Problema 104487 resolvido: devido à lentidão do serviço de base de dados, os utilizadores do VMware SASE Orchestrator podem deparar-se com uma lentidão geral e algumas falhas de API. Outros efeitos colaterais incluem SD-WAN Gateways/Edges que aparecem offline na interface do utilizador, alterações de configuração efetuadas através da IU do Orchestrator que não são enviadas para os SD-WAN Edges de destino e perda de capacidades de relatório.

    Os problemas são todos provocados pela falha do serviço de base de dados do Orchestrator com o erro: demasiados ficheiros abertos (too many open files). Este erro é observado pelo operador do VMware SASE Orchestrator através de registos. Um utilizador final que aceda ao VMware SASE Orchestrator através da IU depara-se com lentidão e falhas intermitentes de API, o que provoca mensagens de erro na IU.

Resolvido na versão R5100-20221204-GA do Edge e do Gateway

A compilação R5100-20221204-GA de Edge e Gateway foi lançada a 08-12-2022 e resolve os seguintes problemas desde a compilação R5012-20221107-GA do Edge e a compilação R5011-20221007-GA do Gateway.

A versão 5.1.0 contém todas as correções de Edges e Gateways indicadas nas Notas de versão 5.0.0 e todas as correções de Edges e Gateways nas Notas de versão 5.0.1 até às compilações indicadas acima.

  • Problema 26085 resolvido: Um cliente que utilize uma topologia Hub/Spoke e Gateways de parceiro pode observar uma queda do tráfego num VMware SD-WAN Spoke Edge se um dos Gateways não for configurado a partir de um Hub Edge.

    O tráfego abandonado está a utilizar um caminho obsoleto para um Gateway que já não está atribuído. Quando um Gateway não é configurado a partir de um Hub Edge, o Gateway propriamente dito não sabe que isso ocorreu e trata o evento como um simples evento de túnel inativo. Em resultado disso, o Gateway continua a providenciar ao Spoke Edge o seu caminho e o Spoke Edge não remove o caminho remoto (acessível através do Hub Edge) porque o Hub Edge continua a estar acessível ao Spoke Edge.

    Quando este problema ocorre na ausência de uma compilação fixa, a única forma de o solucionar consiste em inserir a ligação Spoke Edge para Gateway.

  • Problema 29929 resolvido: No caso de um site implementado com uma topologia de alta disponibilidade, quando existe uma recuperação automática HA, um utilizador pode não conseguir iniciar sessão na IU Local para os Edges HA.

    Quando as credenciais locais são modificadas para os Edges HA no Orchestrator, o Edge ativo correto aplica a alteração, mas as novas credenciais não são sincronizadas com o Edge em standby. Em resultado disso, quando ocorre uma recuperação automática HA e o Edge em standby é promovido a Ativo, o Edge utiliza as credenciais predefinidas de utilizador/palavra-passe e um utilizador que tente iniciar sessão na IU Local não conseguirá fazê-lo com sucesso com as credenciais mais recentes.

  • Problema 32413 resolvido: A temperatura não está incluída nas estatísticas do estado de funcionamento ou no MIB.

    A correção adiciona a temperatura da CPU ao MIB utilizado para SNMP e a métrica medida em Monitorizar (Monitor) > Edge > Sistema (System), também conhecida como “Estatísticas do estado de funcionamento do Edge”.

  • Problema 32654 resolvido: Os utilizadores num site VMware SD-WAN Edge em que uma interface WAN está inativa podem observar uma queda do tráfego.

    As quedas de tráfego em resultado de caminhos ligados continuam a ser anunciadas a um VMware SD-WAN Gateway, embora a capacidade de alcance seja Falso (False) no VMware SD-WAN Edge quando a interface ligada está inativa.

  • Problema 39134 resolvido: ao consultar a página Monitorizar > Edge > Sistema (Monitor > Edge > System), a percentagem da CPU não é exata.

    Também conhecidas como “Estatísticas do estado de funcionamento do Edge”, o VMware SASE Orchestrator não recebe informações exatas sobre a utilização da CPU do Edge e envia estas informações para gráficos na página Sistema (System) que são imprecisos e induzem em erro os clientes que tentam resolver um problema com o Edge.

  • Problema 45453 resolvido: Um cliente não pode configurar um VMware SD-WAN Edge para ter 2 interfaces WAN que utilizem a mesma VLAN.

    O problema surge num cenário em que um site liga várias portas WAN do Edge ao mesmo interruptor L2 na mesma VLAN. O problema com esta configuração é que o Edge pode, por vezes, utilizar o endereço MAC de origem errado quando envia tráfego de gestão.

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

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

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

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

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

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

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

  • Problema 56153 resolvido: no cado da empresa de um cliente em que é implementado um Destino Não-SD-WAN via Gateway e em que é utilizado o BGP através de IPsec, se um filtro BGP de entrada não for atribuído pelo cliente, o filtro não será removido no VMware SD-WAN Gateway e o mapa de caminho será aplicado juntamente.

    Este problema pode provocar um routing inesperado para o cliente, uma vez que este espera que o filtro BGP de entrada esteja inativo quando ainda está a ser utilizado pelo Gateway e Edge.

  • Problema 60844 resolvido: Uma política empresarial que foi concebida para abandonar todo o tráfego que corresponde aos critérios da política configurando um limite de taxa de 0% não funciona.

    Embora seja permitida a configuração para um limite de taxa de 0%, o Edge não o observa como 0% mas 100%, anulando totalmente a finalidade da política empresarial.

    Num Edge sem correção, a solução é utilizar uma regra de Firewall para fazer corresponder e abandonar tráfego vs. uma Política empresarial.

  • Problema 61804 resolvido: Uma empresa cliente que utilize BGP pode observar que, quando um VMware SD-WAN Edge aprende caminhos de um par, estes caminhos são anunciados de volta ao par.

    O Edge não deve anunciar caminhos aprendidos pelos pares ao par propriamente dito, já que isso provoca um comportamento de routing adverso e uma queda do tráfego.

  • Problema 62701 resolvido: 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 Hub Edge inativa 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.

    Numa empresa em que os Edges não utilizam uma versão com uma correção para este problema, a solução alternativa é ativar a VPN de cloud em todos os segmentos, ou seja, no segmento global e em todos os segmentos não globais.

  • Problema 64526 resolvido: Quando um utilizador muda a interface GE2 num VMware SD-WAN Edge de switched para routed e, em seguida, configura uma subinterface nesta interface e tenta guardar as alterações, o Orchestrator emite um erro.

    Apenas é acionado quando a configuração da interface do Edge é alterada ao nível do Perfil (vs. ao nível do Edge). O utilizador veria o erro “Tipo de endereçamento desconhecido DHCP_STATELESS para subinterface GE2 – ignorado” (Unknown addressing type DHCP_STATELESS for subinterface GE2 - ignored) e isso é visto na página Eventos (Events) do Orchestrator desse cliente.

  • Problema 65530 resolvido: Um cliente que implemente Metanoia SFPs num VMware SD-WAN Edge pode registar problemas com o módulo.

    Os problemas podem ocorrer pelo facto de não ter um nível de firmware mais recente, atualizado com a versão 5.1.0. As alterações à versão do CSP e à versão do firmware SFP UPG são apresentadas na tabela abaixo:

    Versão do Edge

    Versão do CSP

    Versão do firmware SFP UPG

    5.1.0

    3.2.9.13

    1_62_8559

    4.0.0 – 5.0.x

    3.2.8.11

    1_62_8431

    Estas atualizações garantem uma maior estabilidade para os Metanoia SFPs no Edge.

  • Problema 65919 resolvido: No caso de um cliente que tenha configurado um Serviço de Segurança na Cloud (CSS) Zscaler, se o serviço Edge for reiniciado ou o DNS for eliminado, o túnel Zscaler pode falhar.

    Apesar de as consultas de DNS serem bem sucedidas, o DNS não mostra o Zscaler FQDN e, consequentemente, o túnel não aparece. Ao verificar os registos do Edge para DNS, não haverá entradas Zscaler na cache DNS.

    Para remediar o problema, um utilizador teria de realizar um nslookup ou um ping, para criar uma entrada de DNS e aparecer o túnel Zscaler. 

  • Problema 67900 resolvido: Se uma ligação WAN for configurada como autodetetada no VMware SASE Orchestrator, o Orchestrator poderá marcá-la como uma ligação privada, mesmo que deva ser definida como ligação pública.

    O Orchestrator requer que a ligação seja definida como privada, mesmo que o cliente tenha definido a configuração para essa ligação como pública. Isto pode causar problemas significativos de conetividade com um Gateway, uma vez que a ligação estará a tentar ligar-se a um IP privado e falhará no processo.

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

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

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

  • Problema 70248 resolvido: Quando uma CRL é emitida do lado do Edge, o túnel fica inativo e é novamente restabelecido.

    Quando o Orchestrator revoga qualquer certificado, por exemplo, um certificado do Gateway, o Edge inativa o túnel e restabelece-o.

    O problema está relacionado com o tempo de validade da CRL. Se a CRL tiver um tempo de atualização anterior ao tempo do Edge, o túnel será restabelecido.

    Na ausência de uma correção, a única solução é garantir que o Edge e o Orchestrator têm uma correspondência de data e hora.

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

  • Problema 71302 resolvido: Para empresas clientes que utilizam Destinos Não-SD-WAN via Edge, a porta utilizada é 500 em vez de 4500.

    Este não é o comportamento esperado e pode provocar problemas com o tráfego que utiliza esse NSD via Edge se houver outro dispositivo a bloquear a porta 500.

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

  • Problema 75553 resolvido: Um cliente que implemente um Destino Não-SD-WAN (NSD) via Gateway que utilize um tipo baseado em política não poderá configurar VMware SD-WAN Gateways redundantes.

    Em compilações anteriores, o VMware marcava sempre um caminho NSD baseado em política como “Acessível” (Reachable), independentemente do estado, com o resultado de que o caminho do Gateway principal do NSD nunca seria marcado como inacessível e acionaria uma recuperação automática para um Gateway redundante.

    Na versão 5.1.0 e posteriores, o caminho do Gateway é marcado como acessível, exceto se falhar a negociação IKE/IPsec, nesse caso, será marcado como “Inacessível” (Unreachable) e o tráfego NSD passará através do gateway redundante como acontece com um NSD baseado em caminho.

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

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

  • Problema 76881 resolvido: Um VMware SD-WAN Edge pode registar níveis críticos de utilização da memória quando mais de 10 000 concessões de DHCPv6 são utilizadas e, possivelmente, acionar um reinício do serviço Edge.

    Quando um grande número de clientes DHCPv6 é ligado ao servidor DHCPv6, cada cliente recebe uma concessão e a memória do servidor DHCPv6 continua a aumentar. O Edge não limita o número de concessões de DHCPv6 que podem ser atribuídas, em contraste com o limite rígido de endereços IPv4 5K. Consequentemente, existe o potencial de o Edge atribuir concessões suficientes para ser atingido um nível crítico do estado da memória do Edge e acionar, assim, um reinício do serviço.

    A correção do problema restringe o número máximo de clientes a 10 000.

  • Problema 77066 resolvido: Um VMware SD-WAN Gateway pode encontrar uma falha do Serviço dataplane, acionar um core e reiniciar o serviço para recuperar.

    O problema é acionado por danos na memória do Gateway causados por dois processos do Gateway que gerem, respetivamente, os pacotes de transmissão e receção, tentando simultaneamente aceder ao mesmo nó numa árvore de pesquisa.

  • Problema 77457 resolvido: Se um utilizador tentar gerar uma captura de pacotes (PCAP) para uma interface num VMware SD-WAN Edge em standby, o VMware SASE Orchestrator informa que o PCAP falhou.

    Quando um utilizador tenta gerar um PCAP para o Edge em standby numa implementação de alta disponibilidade melhorada, a IU do Orchestrator registará o Estado do pedido (Request Status) como Falhado (Failed) e a explicação “Falha ao carregar o pacote de diagnóstico: ‘“unicode” não tem a interface de memória intermédia” (Failed to upload diagnostic bundle: 'unicode' does not have the buffer interface).


  • Problema 77611 resolvido: No caso de um site de cliente que utilize uma topologia de alta disponibilidade, quando o Edge HA é migrado para uma configuração de Perfil diferente, ambos os Edges podem entrar no estado Ativo-Ativo (cérebro dividido) e reiniciar ao mesmo tempo para recuperarem.

    Durante este estado Ativo-Ativo, os utilizadores cliente registam problemas significativos de qualidade de tráfego devido a perda de pacotes.

    O problema é provocado pela falha dos Edges HA em seguir um processo de mudança para um novo perfil em que o Edge em standby deve reiniciar primeiro para aplicar as alterações e permanecer como Standby. Em seguida, o Ativo aplicaria as alterações de configuração e seria reiniciado e, só então, promoveria o Standby a Ativo, despromovendo-se a Standby. Em vez disso, o Edge em standby promove-se imediatamente a Ativo após o reinício, conduzindo ao estado Ativo-Ativo.

  • Problema 78037 resolvido: um VMware SD-WAN Edge pode encontrar um pico de utilização de memória, seguido de uma falha do Serviço dataplane, onde um servidor DHCPv6 está configurado com mais de 1000 endereços.

    O problema ocorre para interfaces routed e switched . O problema pode ocorrer quando mais de 1000 endereços são configurados para clientes num servidor DHCPv6. Quando mais de 1000 clientes estão a obter endereços, a quantidade de pacotes de solicitação DHCPv6 gerados levam ao esgotamento da memória do Edge e à falha do serviço do Edge.

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

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

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

  • Problema 78435 resolvido: Um VMware SD-WAN Edge que é ativado com um URL através da IU local pode emitir o erro de que a ativação do Edge falhou, quando, na realidade, foi bem sucedida.

    A ativação do URL do Edge com a IU local emite o erro “A ativação do Edge não foi concluída” (Edge activation could not be completed)


    Este problema ocorre porque o Edge refere-se a um pedido de ativação mais antigo com parâmetros incorretos ao responder ao pedido de estado de ativação. Entretanto, o atual pedido de ativação com os parâmetros corretos está a ser processado. Como resultado, a IU local emite um erro mesmo que a ativação do Edge esteja a ser processada corretamente.

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

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

  • Problema 79338 resolvido: Quando um grande número de clientes DHCPv6 tenta obter um novo endereço IPv6, alguns clientes podem não conseguir obter um.

    Quando há mais de 1024 clientes a tentar adquirir um endereço IPv6 ao mesmo tempo, alguns dos clientes podem não obter um endereço IPv6 válido. Este problema ocorre porque a cache vizinha é fixa e as entradas vizinhas de alguns clientes não são criadas. Como não existem entradas vizinhas, as mensagens de renovação falham.

    Um cliente que não utilize uma compilação com a correção pode tentar novamente adquirir o endereço IPv6 a partir dos clientes após alguns minutos.

  • Problema 79550 resolvido: um VMware SD-WAN Gateway ou SD-WAN Edge pode registar uma falha do Serviço dataplane e reiniciar.

    Este problema poderá ocorrer se um fragmento de tráfego de gestão (VCMP) repetido for recebido, fazendo com que o processo escreva para lá da memória intermédia alocada para esse pacote, o que ativa a falha.

  • Problema 81881 resolvido: Uma alteração da definição de Configurar (Configure) > Dispositivo (Device) efetuada no VMware SASE Orchestrator não pode ser aplicada ao VMware SD-WAN Edge pretendido, mesmo que o Edge esteja ligado ao Orchestrator.

    Adicionalmente, o Edge pode ter este problema em caso de sobrecarga e de alterações de configuração frequentes e rápidas. Nesse cenário, o thread de gestão do Edge responsável pela aplicação de configuração bloqueia e não aplica alterações adicionais.

  • Problema 81353 resolvido: Um VMware SD-WAN Gateway implementado utilizando uma plataforma Azure provoca uma queda de pacotes na receção das interfaces.

    A queda dos pacotes deve-se a uma memória intermédia baixa. A definição de memória intermédia em anel não fazia parte das interfaces geridas Não-DPDK utilizadas pelas plataformas Azure e as filas de memória intermédia em anel de receção NIC são definidas como números baixos.

  • Problema 81355 resolvido: Os VMware SD-WAN Gateways implementados utilizando a plataforma Azure podem ter problemas com pacotes de tamanho superior a 1500.

    Os pacotes com mais de 1500 bytes são abandonados com a mensagem de erro: pkt_too_big_drop. Os pacotes com tamanho muito superior a 1500 bytes são abandonados com a mensagem de erro: sock_too_big_dropp.

    Este problema deve-se ao facto de a plataforma Azure não utilizar interfaces agregadas DPDK, o que mantém a lista DPDK.json do gateway vazia e não permite que as configurações de rede DPDK inicializem as definições TSO/GSO da interface Linux.

  • Problema 81377 resolvido: Quando as sub-redes do Secure Access são atualizadas, as sub-redes antigas não são revogadas do BGP.

    Quando uma configuração de sub-rede do Secure Access é modificada, o SD-WAN elimina apenas as sub-redes antigas da FIB (Forwarding Information Base) e de outras tabelas de caminho locais. O problema é que o SD-WAN não revoga o caminho da tabela BGP utilizado para a redistribuição, fazendo com que estes caminhos obsoletos permaneçam no BGP.

  • Problema 81483 resolvido: No caso de um cliente com uma topologia Hub-Spoke, se um utilizador aumentar os ciclos de vida IKE e/ou IPsec através do VMware SASE Orchestrator, o cliente poderá verificar que alguns túneis mantêm os ciclos de vida antigos. Por esse motivo, alguns túneis realizarão reintroduções de chave mais frequentemente do que o esperado por manterem os ciclos de vida anteriores.

    Se o cliente diminuir os ciclos de vida, solucionará, tecnicamente, este erro (uma parte da tecnologia Hub-Spoke pode manter o ciclo de vida antigo e mais longo), mas não observará qualquer diferença de funcionalidade porque o Edge que tiver recebido corretamente o ciclo de vida mais reduzido realizará a reintrodução de chave primeiro, mascarando assim o problema.

    A única solução para este problema é alterar os valores de ciclo de vida até que todos os túneis reflitam o estado correto e, em seguida, reiniciar o Edge.

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

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

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

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

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

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

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

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

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

    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 83821 resolvido: Para os clientes que utilizam NetFlow, os pacotes/bytes de transmissão (Tx) e receção (Rx) para tráfego de controlo SD-WAN não são atualizados corretamente nos registos NetFlow.

    Os dados de controlo SDWAN (pacotes/bytes Tx/Rx) que são exportados para um coletor NetFlow são sempre zero. Uma vez que as entradas não são preenchidas nas chat_stats do contentor de fluxo, o NetFlow também não exporta os dados.

  • Problema 84000 resolvido: Um VMware SD-WAN Gateway ligado a Edges implementados numa configuração de pilha dupla (IPv4/IPv6) em que existe uma elevada frequência de remoção e criação de túneis com os Edges pode registar uma fuga de memória que, se suficientemente elevada, acionará um reinício do serviço.

    Quando um túnel VCMP (Gestão Encriptada) é criado e eliminado várias vezes num Edge com uma configuração de pilha dupla, no Gateway desse Edge poderá ocorrer fuga pi se o Gateway estiver a funcionar a uma escala elevada. Não ocorrerá uma fuga pi real, mas a eliminação pi ocorrerá lentamente, e esta velocidade lenta de eliminação pode provocar problemas de memória partilhada que se podem tornar críticos.

    Num Gateway sem a correção, um reinício de serviço limpará temporariamente a memória.

  • Problema 84136 resolvido: O cliente pode observar uma elevada utilização de CPU e um fraco desempenho do tráfego num VMware SD-WAN Edge atualizado para algumas versões do Edge.

    Este problema ocorre em Edges que tenham configuradas mais de 400 regras de IP na secção Configurar > Firewall > Acesso Edge (Configure > Firewall > Edge Access) (endereços IP permitidos de acesso de suporte ou acesso SNMP). Quando o Edge tenta enviar a configuração de firewall nesse cenário, o processo de gestão esgota a CPU, excede o tempo limite e este processo repete-se.

    Nas localizações dos clientes que também utilizem uma topologia de alta disponibilidade, os sintomas incluem “Eventos desconhecidos de alta disponibilidade”, porque o Edge ativo não está a enviar heartbeats dentro do período de tempo esperado.

  • Problema 84225 resolvido: Quando uma interface VMware SD-WAN Edge ligada fica inativa, a sub-rede configurada continua a ser redistribuída para o OSPF ou BGP.

    O Edge atrai o tráfego do par para a sub-rede quando está inativo e pode provocar interrupções de tráfego pelo facto de o par preferir este caminho em detrimento de outras alternativas à sub-rede.

    Num Edge sem uma correção para este problema, o utilizador terá de reiniciar o Edge numa janela de serviço planeada para eliminar o problema.

  • Problema 84313 resolvido: Na empresa de um cliente com uma topologia Hub/Spoke, uma ligação overlay IPv6 pode ser anunciada aos pares de underlay dos VMware SD-WAN Spoke Edges.

    Ao configurar um endereço IPv6 no overlay e permitir o anúncio, o mesmo endereço também será anunciado através do underlay.

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

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

  • Problema 84790 resolvido: quando um VMware SD-WAN Edge com qualquer outro tipo de modelo que não o 510/510-LTE é reiniciado, o Edge pode comunicar erradamente o evento crítico “Não é possível lançar o serviço wifihang” (Unable to launch service wifihang) ao VMware SASE Orchestrator.

    A mensagem do evento wifihang foi concebida para ser utilizada apenas com os modelos Edge 510/510-LTE e alerta um cliente sobre um problema com o processo Wi-Fi desse modelo Edge. Quando esta mensagem de evento é observada em qualquer outro modelo Edge, quer esse modelo utilize Wi-Fi ou não (por exemplo: o Edge 3400), a mensagem de evento é falsa e o evento pode ser ignorado com segurança.

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

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

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

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

    A lógica de processamento de sincronização de dados de controlo HA no Edge em standby para os dados recebidos através de TCP pode levar a que os dados só sejam lidos parcialmente. Isto pode fazer com que estas mensagens curtas sejam processadas no modo em standby, o que tornar mais lento o nó em standby. Nas plataformas Edge no limite inferior (por exemplo, modelos Edge 510, 520, 610 e 620), esta lentidão pode ter um impacto significativo no processamento heartbeat entre Ativo e Em standby, o que leva ao Edge em standby a ser incorretamente promovido a Ativo. Num estado ativo-ativo, o tie-break vai para o Edge ativo e o Edge em standby é reiniciado para o despromover de volta ao seu estado rm standby adequado.

    Quando este problema é encontrado numa topologia HA convencional, o impacto no cliente deverá ser mínimo, dado que o Edge em standby não está a passar o tráfego do cliente. Numa implementação HA melhorada, onde o Edge em standby também está a passar tráfego, os reinícios perturbarão algum tráfego do cliente. 

    A correção para este problema acrescenta melhorias na lógica de processamento da mensagem TCP do Edge, para melhorar o desempenho no Edge em standby e evitar a lentidão do sistema.

  • Problema 85269 resolvido: Para as empresas cliente que utilizam uma topologia Hub/Spoke em que o Multicast está configurado, um recetor multicast pode não receber a fonte de tráfego por trás de um Hub Edge em que o endereço IP de origem é definido manualmente no Hub Edge ou num spoke Edge, mas não em ambos.

    Os registos Pimd e os comandos de depuração forneceriam aos utilizadores a confirmação se o envio de junção PIM falhar devido a uma falta de correspondência entre um endereço IP do PIM vizinho e um endereço IP de próximo hop, impedindo o LHR de chegar ao RP e de se registar (*,G).

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

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

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

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

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

    Este problema só pode ser eliminado realizando um reinício de serviço do Edge.

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

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

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

  • Problema 87552 resolvido: quando um VMware SD-WAN Edge é configurado para utilizar um NSD (Destino Não-SD-WAN) via Edge ou um Serviço de Segurança na Cloud (CSS), o VMware SD-WAN Edge pode ter periodicamente uma falha do Serviço dataplane e reiniciar quando os túneis do NSD ou CSS estiverem instáveis.

    Quando a Edge desativa um túnel para um NSD ou um CSS (IPsec ou GRE), é executada a libertação incorreta de um túnel escolhido anteriormente que aciona uma exceção no Serviço dataplane do Edge e uma reinicialização do Serviço do Edge para restaurar o serviço. Reiniciar o serviço do Edge resultará numa interrupção de 10-15 segundos do tráfego do cliente.

    Num Edge sem uma correção para este problema, a associação de um NSD via Edge ou CSS a uma ligação WAN pode diminuir a probabilidade de este problema ocorrer. Por outras palavras, em vez de configurar um NSD ou CSS em várias ligações WAN, escolha apenas uma ligação WAN. Isto provocará a perda de redundância, mas atenuará o impacto deste problema.

  • Problema 88055 resolvido: Nos modelos VMware SD-WAN Edge 3x00, um cliente pode verificar que, quando o débito é mantido em 10 Gbps ou mais, a latência do caminho WAN pode ficar bloqueada e degradar a estabilidade e o débito do Edge.

    Em ambientes 10G com rápida deriva do relógio entre pontos finais VCMP, as medições de latência do caminho WAN podem bloquear, o que afeta a eficácia da Otimização Dinâmica Multicaminho (DMPO) e resulta numa seleção incorreta do caminho e na degradação do débito.

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

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

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

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

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

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

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

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

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

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

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

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

  • Problema 89725 resolvido: Nos VMware SD-WAN Edges que utilizem versões anteriores à 5.1.0, os utilitários de Diagnóstico remoto Teste de largura de banda da ligação WAN (WAN Link Bandwidth Test) e Traceroute podem não funcionar.

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

  • Problema 90044 resolvido: Quando um VMware SD-WAN Gateway é configurado com uma sonda ICMP e o Gateway é reiniciado, a sonda ICMP não recupera e permanece inativa.

    O estado da sonda ICMP em debug.py --icmp indica INATIVO (DOWN) após o reinício do Gateway.

    Num Gateway sem uma correção para este problema, a solução é desativar a sonda ICMP e, em seguida, reativá-la.

  • Problema 90098 resolvido: No caso da empresa de um cliente em que está configurada uma VPN ramo a ramo, em determinados cenários, um túnel pode ser experimentado infinitamente, apesar de não funcionar devido a uma alteração da configuração.

    O cenário envolve um Edge a tentar criar um túnel com um Edge par que esteja offline ou cujo endereço IP tenha sido alterado. O Edge não percebe que o par está inacessível e tenta infinitamente criar um túnel para o destino inexistente, o que afeta o desempenho global e não pode ser interrompido pelo cliente.

    Este problema é provocado pela ausência de um limite de tempo de expiração para túneis Ramo a Ramo que não funcionam. Adicionalmente, este problema é difícil de resolver porque não é gerada uma mensagem acerca do local em que o Edge está a receber mensagem Ramo a ramo e porque não existe um comando de depuração no Gateway ligado para exibir a informação Ramo a Ramo válida para um par.

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

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

  • Problema 90884 resolvido: no caso da empresa de um cliente que utiliza uma topologia de Cluster de Hub/Spoke, quando um Hub Edge no Cluster é reatribuído a um ou mais Spoke Edges, os utilizadores nessas localizações Spoke Edge podem registar uma falha de tráfego.

    Os Hub Edges num Cluster podem ser reatribuídos como parte de um reequilíbrio do cluster quando uma empresa atualiza o respetivo software Edge, pelo que este problema pode ser observado após a atualização. Quando este problema é encontrado, o VMware SD-WAN Gateway não envia os novos caminhos do Spoke Edge para o Hub Edge dado que o Gateway espera que todos os Hub Edges tenham todos os caminhos do Spoke Edge e, assim, estes caminhos não estão na tabela de routing do Hub Edge. Como resultado de tal, o tráfego entre os Spoke Edges e o Hub Edge no cluster é afetado, dado que o caminho de encaminhamento está inativo.

    se o problema for encontrado numa empresa que não utiliza Gateways com uma correção para este problema, ele pode ser temporariamente resolvido, executando uma reinicialização de caminho no Hub Edge. No entanto, o problema pode ocorrer novamente numa nova reatribuição do Hub Edge.

  • Problema 91164 resolvido: Na empresa de um cliente implementada com uma topologia Hub/Spoke em que o VMware SD-WAN Hub Edge está configurado para alta disponibilidade, o Hub Edge HA pode não encaminhar o tráfego de backhaul de Internet após uma recuperação automática HA.

    O problema limita-se a um cenário em que o Edge em standby não define o caminho de destino para fluxos de backhaul de Internet quando o fluxo de backhaul é configurado para encaminhar através de um caminho estático utilizando uma interface de overlay não-WAN. Quando o Edge em standby é promovido a Ativo numa recuperação automática HA, estes fatores provocam a falha do tráfego de backhaul de Internet.

  • Problema 91188 resolvido: Um ping IPv6 para um anfitrião ligado a uma VLAN numa interface switched falha se for efetuado utilizando Diagnóstico remoto (Remote Diagnostics) > Ping e selecionando a interface VLAN como interface de origem.

    O nome de interface de origem 'VLAN-x' é conhecido apenas pelo VMware SD-WAN Edge e o SO Edge precisa da interface de origem na forma 'br-networkx' uma vez que a interface VLAN é criada com esse nome no SO Edge.

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

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

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

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

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

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

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

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

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

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

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

    Num Edge sem esta correção, o utilizador teria de gerar um pacote de diagnóstico para o Edge para ver o estado das interfaces routed.

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

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

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

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

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

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

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

  • Problema 94612 resolvido: o tráfego para o prefixo de rede BGP pode não estar acessível.

    Quando este problema ocorre, o prefixo de rede BGP não é configurado no BGP e não é anunciado aos nós de pares.

    Num Edge sem uma correção para este problema, a única solução é eliminar as redes do BGP e reconfigurá-las.

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

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

  • Problema 94980 resolvido: para um site implementado com uma topologia de alta disponibilidade, o VMware SD-WAN Edge em espera pode enfrentar um erro do Serviço dataplane e reiniciar após a configuração de uma ligação WAN PPPoE para os Edges de HA.

    Ao examinar o núcleo gerado pelo Edge em espera, um utilizador verá a mensagem vc_is_use_cloud_gateway_set após a configuração da ligação PPPoE.

    Num site HA sem uma correção para este problema, o cliente terá de garantir que é configurada uma ligação PPPoE apenas numa janela de manutenção para gerir o risco deste problema.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Quando uma regra da política empresarial tem um grupo de serviço explícito de ligações WAN com fios com um modo de ligação Disponível e existem ligações sem fios disponíveis no site, a expectativa é de que o tráfego que utiliza essa regra seja recuperado automaticamente para as ligações WAN com fios se as ligações com fios no grupo de serviço ficarem inativas (por outras palavras, caso se tornem indisponíveis) para garantir um fluxo ininterrupto do tráfego que corresponde a essa regra. Neste problema, não está a ocorrer o direcionamento do tráfego para as ligações sem fios.

  • Problema 97321 resolvido: a partir do momento em que um utilizador ativa a Análise do Edge Network Intelligence num VMware SD-WAN Edge, o Edge pode, potencialmente, acionar um reinício do Serviço do Edge, cada instância do qual causa de 10 a 15 segundos de interrupção do tráfego do cliente.

    Quando a Análise estiver ativada no Edge, o Edge pode experienciar uma condição de falta de memória seguido de um estado de memória “dupla memória livre”. O Edge reinicia o serviço para restaurar a memória.

    Os sintomas para este problema podem ocorrer várias vezes enquanto a Análise está ativada.

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

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

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

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

Problemas resolvidos do Orchestrator

Resolvido na versão R51010-20231215-GA do Orchestrator

A compilação R51010-20231215-GA do Orchestrator foi lançada a 18/12/2023 e é a 10.ª compilação rollup do Orchestrator para a versão 5.1.0.

Esta compilação rollup do Orchestrator aborda o problema importante abaixo desde a 9.ª compilação rollup R5109-20231003-GA do Orchestrator.

  • Problema 117941 resolvido: a caixa de verificação Anúncio da VLAN (VLAN Advertise) é sempre apresentada como desmarcada na IU do Orchestrator.

    Mesmo quando um utilizador marca a caixa de verificação Anúncio da VLAN (VLAN Advertise) e seleciona Guardar alterações (Save Changes), a caixa de verificação Anúncio da VLAN (VLAN Advertise) na IU do Orchestrator volta a ser apresentada desmarcada.

  • Problema 125006 resolvido: num VMware SASE Orchestrator configurado com uma topologia de recuperação após desastre (DR), a base de dados do Orchestrator pode falhar e isso leva o Orchestrator em standby a entrar num estado de erro e, em casos raros, pode fazer com que os Edges e os Gateways apareçam como offline na IU do Orchestrator e acionem eventos e alertas.

    Espera-se que o estado da base de dados seja recuperado automaticamente dentro de alguns minutos e os Orchestrators DR sejam ressincronizados. No entanto, às vezes, este estado pode exceder o período de tolerância e tanto os Edges como os Gateways começam a enviar os respetivos heartbeats para o Orchestrator em standby em vez do Orchestrator ativo. Como tal, o Orchestrator ativo marca os Edges e os Gateways que não enviam heartbeats como inativos e aciona eventos e alertas. Este problema é puramente do lado da gestão e não afeta o tráfego de rede.

    Num Orchestrator sem uma correção, a forma de evitar este problema é aumentar a Propriedade do sistema do Orchestrator que controla a tolerância para uma sincronização com falha: vco.disasterRecovery.transientErrorToleranceSecs numa quantidade adequada para fornecer uma janela de recuperação automática mais longa.

  • Problema 128310 resolvido: os utilizadores do VMware SASE Orchestrator podem deparar-se com lentidão geral e algumas falhas de API devido a problemas com o serviço de base de dados do Orchestrator. Outros efeitos colaterais incluem SD-WAN Gateways/Edges que aparecem offline na IU, alterações de configuração efetuadas através da IU do Orchestrator que não estão a ser enviadas para os SD-WAN Edges de destino e perda de capacidades de relatório.

    Estes problemas são todos causados pela falha do serviço de base de dados do Orchestrator com o erro: demasiados ficheiros abertos (too many open files). Este erro pode ser observado por um utilizador operador no VMware SASE Orchestrator nos registos. Um utilizador empresarial ou parceiro que aceda ao VMware SASE Orchestrator através da IU depara-se com lentidão e falhas intermitentes da API, o que causa mensagens de erro na IU.

  • Problema 129239 resolvido: na página Configurar > Perfil (Configure > Profile) da IU do Orchestrator, quando um utilizador edita qualquer definição ao nível do perfil e tenta guardar, pode observar que a chamada à API ultrapassa o tempo limite e não é bem-sucedida.

    Quando este problema é encontrado, a IU do Orchestrator apresenta uma faixa de erro vermelha na página do navegador que indica “tempo limite ultrapassado para configuration/updateConfigurationModule” (configuration/updateConfigurationModule time out). O problema ocorre porque outras consultas da base de dados do Orchestrator demoram demasiado tempo a serem concluídas e fazem com que a tentativa de guardar as novas definições do perfil ultrapasse o tempo limite.

  • Problema 131789 resolvido: ao configurar o Início de sessão único (SSO) para uma organização, mesmo que as informações de função estejam presentes na resposta do Fornecedor de identidade (IdP), os utilizadores não conseguem iniciar sessão no Orchestrator.

    O Orchestrator não conseguirá fazer a correspondência da função de um utilizador que inicia sessão através do Início de sessão único (SSO) se o IdP enviar informações de função numa estrutura JSON aninhada. A partir da versão 5.0.1.7, o Orchestrator pode fazer referência e fazer a correspondência à função de um utilizador do SSO mesmo que esteja presente numa estrutura JSON aninhada. Se este problema ocorrer num Orchestrator sem uma correção, a solução alternativa passa por configurar o IdP para enviar o detalhe da função no nível imediato e não na estrutura aninhada.

Resolvido na versão R5109-20231003-GA do Orchestrator

A compilação R5109-20231003-GA do Orchestrator foi lançada a 05/10/2023 e é a nona compilação rollup do Orchestrator para a versão 5.1.0.

Esta compilação rollup do Orchestrator aborda o problema importante abaixo desde a oitava compilação rollup R5108-20230916-GA do Orchestrator.

  • Problema 119938 resolvido: para um cliente que utiliza a automatização para túneis do Zscaler, a criação de um túnel IPsec automatizado a partir de um VMware SD-WAN Edge para o Zscaler pode demorar muito tempo.

    Quando os clientes configuram sublocalizações do Zscaler em Edge > Definições do dispositivo (Edge Device Settings), a sincronização dessas configurações com a cloud do Zscaler pode demorar muito tempo. Isto ocorre porque a cloud do Zscaler precisa de atualizar os respetivos registos para cada sublocalização, o que pode ser um processo demorado.

    Este problema é provocado pela estrutura de automatização no Orchestrator, que adiciona as ações de criação de túneis IPsec e de criação de sublocalizações à fila de automatização. Também adiciona as ações de atualização à fila de automatização quando o IP da WAN do Edge é alterado. No entanto, o tempo de espera para os itens na fila aumenta devido ao grande número de ações de atualização. Em alguns ambientes de implementação do cliente, o IP da WAN do Edge pode ser alterado até 4000 vezes num dia (por exemplo, ligações de WAN móvel).

  • Problema 128310 resolvido: os utilizadores do VMware SASE Orchestrator podem deparar-se com uma lentidão geral e algumas falhas de API devido a problemas com o serviço de base de dados do Orchestrator. Outros efeitos colaterais incluem SD-WAN Gateways/Edges que aparecem offline na interface do utilizador, alterações de configuração efetuadas através da IU do Orchestrator que não são enviadas para os SD-WAN Edges de destino e perda de capacidades de relatório.

    Os problemas são todos provocados pela falha do serviço de base de dados do Orchestrator com o erro: demasiados ficheiros abertos (too many open files). Este erro pode ser observado por um utilizador operador no VMware SASE Orchestrator através de registos. Um utilizador empresarial ou de parceiro que aceda ao VMware SASE Orchestrator através da IU depara-se com lentidão e falhas intermitentes de API, o que provoca mensagens de erro na IU.

Resolvido na versão R5108-20230916-GA do Orchestrator

A compilação R5108-20230916-GA do Orchestrator foi lançada a 20/09/2023 e é a oitava compilação rollup do Orchestrator para a versão 5.1.0.

Esta compilação rollup do Orchestrator aborda o problema importante abaixo desde a sétima compilação rollup R5107-20230722-GA do Orchestrator.

  • Problema 94610 resolvido: quando um utilizador inicia uma recuperação automática HA forçada através de Ações remotas > Forçar recuperação automática HA (Remote Actions > Force HA Failover), o VMware SASE Orchestrator pode não gerar nem enviar um alerta para a recuperação automática HA.

    Como a recuperação automática HA é forçada pelo Orchestrator, tanto o Edge ativo como Em standby antecipam a recuperação automática e isto pode fazer com que as mensagens HA_GOING_ACTIVE e HA_READY sejam enviadas no mesmo heartbeat pelo Edge de HA. Se o “Estado HA” (HA State) enviado no heartbeat for apresentado como “Pronto” (Ready), o Orchestrator será induzido em erro para não gerar um alerta para a recuperação automática, uma vez que só verá a mensagem “Pronto” (Ready) e não a mensagem “A ficar ativo” (Going Active).

  • Problema 104775 resolvido: quando um utilizador configura uma ligação WAN anteriormente ativa num VMware SD-WAN Edge para funcionar como backup, a IU do VMware SASE Orchestrator não apresenta o estado corretamente em Monitorizar > Edges > Vista geral (Monitor > Edges > Overview).

    O estado deve ser apresentado como Standby inativo (Standby Idle) com um ponto de estado com a cor cinza, mas, em vez disso, não apresenta o tipo de ligação nem o estado da alternativa. Este é um defeito de aspeto, uma vez que a ligação WAN está a desempenhar a sua função de backup.

  • Problema 105580 resolvido: no caso de um VMware SASE Orchestrator em que o modo FIPS está configurado, uma tentativa de configurar a Recuperação após desastre (DR) para o Orchestrator pode falhar.

    Falha SSL_CTX_new ao tentar estabelecer ligação. A configuração da DR com o FIPS configurado inclui uma compilação do Orchestrator com o MySQL versão 8.0.28 ou superior e falhará durante a fase DR COPYING_DP com a mensagem de erro: SSL_CTX_new failed when trying to connect.

  • Problema 106191 resolvido: um utilizador não poderá efetuar alterações à configuração de um VMware SD-WAN Edge se o Edge estiver a utilizar um perfil em que qualquer interface está configurada com um endereço IP estático.

    Se ocorrer uma tentativa de alteração da configuração do Edge, a IU do VMware SASE Orchestrator apresentará a mensagem de erro: “intervalo da pesquisa inválido para a interface” (invalid probe interval for interface) e vai impedir que as alterações sejam guardadas.

    Num Orchestrator sem uma correção para este problema, a única solução alternativa é criar um novo perfil sem atribuições de interface estática e aplicá-lo ao Edge.

  • Problema 115981 resolvido: para uma empresa de cliente que utiliza a APIv2 do VMware SASE Orchestrator, ao executar a API para obter eventos empresariais, o Orchestrator devolve apenas um conjunto limitado.

    A chamada específica é https://\{api_host}//api/sdwan/v2/enterprises/{enterpriseLogicalId}/events. Após a invocação, devolve apenas a hierarquia de nível superior e inclui detalhes como enterpriseName, EdgeName, segmentName ou edgeID. Além disso, a APIv2 não suporta a travessia de gráficos.

    Num Orchestrator sem uma correção para este problema, a única solução alternativa é utilizar a APIv1, que força um cliente a manter dois conjuntos de famílias de APIs. Além disso, a APIv1 não suporta o Cloud Web Security.

  • Problema 116531 resolvido: se um utilizador tentar gerar um relatório no VMware SASE Orchestrator em que, pelo menos, uma descrição de Edge inclui uma vírgula (,), o relatório pode não ser formatado corretamente.

    Quando uma descrição de Edge inclui uma vírgula (conforme mostrado na captura de ecrã abaixo), o serviço de relatório do Orchestrator confunde isto e divide o texto após cada vírgula na coluna seguinte do relatório, em vez de conter toda a cadeia de texto na coluna Descrição de Edge (Edge Description), conforme esperado.

    Assim, em vez de os Bytes transmitidos (Bytes Transmitted) apresentarem os respetivos valores associados, é apresentado o texto após a primeira vírgula, e os Bytes recebidos (Bytes Received) apresentam o texto após a segunda vírgula (caso exista), e assim sucessivamente. O relatório continua a incluir os dados dos Bytes transmitidos e dos Bytes recebidos; estes são simplesmente apresentados mais à direita e não são apresentados nas colunas corretas.

    Num Orchestrator sem uma correção para este problema, o utilizador tem de garantir que a descrição do Edge não utiliza vírgulas.

  • Problema 117822 resolvido: quando um cliente consulta Monitorizar > Edges > QoE (Monitor > Edges > QoE), pode observar lacunas nos gráficos de QoE que não são explicadas por nenhum problema nas ligações WAN do Edge.

    As lacunas são o resultado de um problema na base de dados do Orchestrator no qual a fila de tarefas interna para os dados da ligação é perdida e os dados da ligação não são preenchidos.

  • Problema 118728 resolvido: num portal de parceiro ou numa empresa de cliente, alguns utilizadores podem não ter permissão para iniciar sessão no VMware SASE Orchestrator.

    O utilizador pode ver o erro “o utilizador não tem o privilégio [READ:PROXY] necessário para aceder a [enterpriseProxy/getEnterpriseProxy]” (user does not have privilege [READ:PROXY] required to access [enterpriseProxy/getEnterpriseProxy]), mesmo que tenha os privilégios corretos para iniciar sessão. Isto é válido para a autenticação nativa e para a autenticação de dois fatores. Na verdade, este erro reflete uma palavra-passe expirada. Além de o Orchestrator não estar a informar o utilizador acerca do verdadeiro motivo pelo qual não pode iniciar sessão, o utilizador não pode repor a respetiva palavra-passe, uma vez que não consegue iniciar sessão.

    Num Orchestrator sem uma correção para este problema, um administrador de cliente ou parceiro com uma função adequada pode enviar o e-mail de reposição de palavra-passe a um utilizador afetado para repor a respetiva palavra-passe.

  • Problema 121085 resolvido: se um administrador de parceiro estiver na página Definições globais > Gestão de utilizadores > Permissões de serviço (Global Settings > User Management > Service Permissions), a opção “Repor predefinição do sistema” (Reset to System Default) não funciona conforme o esperado.

    O comportamento esperado quando a opção Repor predefinição do sistema (Reset to System Default) é selecionada é que todos os pacotes de permissões de funções personalizados revertam para um estado Não publicado (Unpublished), uma vez que as predefinições das permissões de funções dos utilizadores foram repostas. No entanto, o utilizador de parceiro observará que um ou mais pacotes personalizados permanecem num estado Publicado (Published) e os que permanecem Publicados (Published) não podem ser modificados nem eliminados.

  • Problema 121441 resolvido: quando um cliente ativa a inserção VNF numa VLAN do VMware SD-WAN Edge, o Edge elimina e reimplementa a VNF, o que a torna inutilizável para esse Edge.

    Depois da inserção VNF ser ativada na VLAN, o cliente observa os eventos de eliminação e reimplementação da VNF na página Monitorizar > Eventos (Monitor > Events) e recebe um e-mail com a mensagem “(VNF_VM_DELETED)/A VNF do fornecedor desconhecido foi eliminada no Edge <Nome de Edge>” [(VNF_VM_DELETED) / Unknown vendor VNF was deleted on the edge <Edge Name>]. O problema é atribuído ao Orchestrator que envia um novo identificador exclusivo universal (UUID) depois da inserção VNF ser ativada numa VLAN. O Edge interpreta esta alteração do UUID como um acionador para eliminar a VNF e reimplementá-la, o que a torna inutilizável para esse Edge.

    Este problema ocorre apenas na IU nova. Se tiver este problema num Orchestrator 5.1.x sem uma correção para o mesmo, mude para a IU clássica para configurar a VNF.

  • Problema 121469 resolvido: quando um utilizador navega para a página Definições globais > Gestão de utilizadores (Global Settings > User Management), pode observar que todas as contas de utilizador são apresentadas como bloqueadas de acordo com uma faixa na IU, mesmo que a maioria das contas, ou possivelmente todas as contas, não estejam realmente bloqueadas.

    A faixa da mensagem de erro para qualquer conta de utilizador indica “Esta conta foi bloqueada devido a várias tentativas de início de sessão falhadas” (This account has been locked due to too many failed login attempts), mesmo que, ao observar a página da lista de utilizadores, o estado seja apresentado como Desbloqueado (Unlocked) e continue a ser possível iniciar sessão na IU local.

  • Problema 124778 resolvido: ao utilizar a nova IU no VMware SASE Orchestrator, se um cliente navegar até Definições globais > Configuração do cliente (Global Settings > Customer Configuration), não verá a opção para configurar a respetiva política de segurança.

    A secção Política de segurança (Security Policy) é onde um cliente pode configurar a respetiva Proposta IPsec Edge (Edge IPsec Proposal), incluindo a encriptação, o grupo DH, entre outros. Esta opção está presente na IU clássica, mas não na IU nova.

Resolvido na versão R5107-20230722-GA do Orchestrator

A compilação R5107-20230722-GA do Orchestrator foi lançada a 22/07/2023 e é a sétima compilação rollup do Orchestrator para a versão 5.1.0.

Esta compilação rollup do Orchestrator aborda o problema importante abaixo desde a sexta compilação rollup R5106-20230705-GA do Orchestrator.

  • Problema 122271 resolvido: quando um cliente adiciona regras NAT do lado de LAN adicionais a um perfil utilizando a nova IU do VMware SASE Orchestrator, pode verificar que todo o tráfego correspondente a essas regras falha.

    A nova IU calcula incorretamente a máscara externa NAT do lado da LAN a partir do prefixo de endereço interno. Quando as regras não são escritas de modo a que o prefixo interno e externo sejam os mesmos (por outras palavras: 1:1), o comportamento das regras mudará e poderá deixar de ser funcional se um utilizador modificar qualquer regra NAT do lado da LAN na nova IU.

    Num Orchestrator sem uma correção para este problema, o cliente só deve utilizar a IU clássica do Orchestrator para configurar regras NAT do lado de LAN.

Resolvido na versão R5106-20230705-GA do Orchestrator

A compilação R5106-20230705-GA do Orchestrator foi lançada a 06/07/2023 e é a sexta compilação rollup do Orchestrator para a versão 5.1.0.

Esta compilação rollup do Orchestrator aborda os problemas importantes abaixo desde a quinta compilação R5105-20230611-GA do Orchestrator.

  • Problema 84772 resolvido: quando o tipo do servidor DHCP IPv6 de uma VLAN é configurado como Reencaminhamento (Relay) ao nível do perfil, se um utilizador alterar o tipo para Ativado (Activated) ao nível do Edge utilizando Sobrepor configuração do Edge (Edge Override) e, posteriormente, desativar essa opção, o Edge continuará a utilizar o tipo Ativado (Activated) em vez de reverter para o tipo Reencaminhamento (Relay) fornecido pelo perfil.

    O VMware SASE Orchestrator não está a conseguir impor a configuração do perfil após a desativação de Sobrepor configuração do Edge ( Edge Override), o que resulta em configurações incorretas do servidor IPv6 para o Edge afetado.

  • Problema 115411 resolvido: no caso de um VMware SASE Orchestrator que utiliza a versão 5.1.0 ou posterior e é implementado com uma topologia de recuperação após desastre, a sincronização pode falhar devido a um problema com a base de dados.

    O processo específico que falha é dr_utils.js e deve-se ao facto de este processo ter sido preterido na versão mais recente do software de base de dados do Orchestrator presente na versão 5.1.0 e posterior.

  • Problema 115433 resolvido: um utilizador com a função “Suporte de empresa” (Enterprise Support) não consegue ver os dados de configuração DHCP quando consulta a nova IU do VMware SASE Orchestrator.

    Esse utilizador do Suporte de empresa poderá ver os dados de configuração DHCP se utilizar a IU clássica.

  • Problema 116633 resolvido: ao iniciar sessão no VMware SASE Orchestrator com o Safari ou o Firefox, se um utilizador configurar uma VLAN inválida ao nível do perfil (por exemplo, “”) e, em seguida, configurar um valor de VLAN válido no VMware SD-WAN Edge, a chamada será realizada, mas apresentará um erro.

    O valor da interface em que nenhum valor é definido deveria ser zero, mas é vlanID = “”. Se um utilizador iniciar sessão no Orchestrator com um browser baseado no Chromium, este problema não ocorrerá.

  • Problema 117772 resolvido: quando consulta o ecrã Monitorizar > Visão geral da rede (Monitor > Network Overview) relativamente a um VMware SASE Orchestrator de um cliente empresarial, as ligações WAN que apresentam o estado Degradado (Degraded) ou Inativo (Down) poderão não ser incluídas no ecrã Estado da ligação (Link status) se estiverem a ser monitorizadas mais de 10 ligações WAN.

    Este problema é exclusivo da nova IU do Orchestrator devido a um problema de front-end que não prevê ligações WAN degradadas ou inativas. A monitorização funciona conforme esperado na IU clássica.

  • Problema 117988 resolvido: a opção “Aprendizagem de caminho de entrada” (Inbound Route Learning) com a caixa de verificação “Correspondência exata” (Exact Match) configurada para OSPF numa VMware SD-WAN Interface não corresponde à que está configurada no Edge quando são comparados os valores da IU clássica com os da nova IU do VMware SASE Orchestrator.

    A opção Correspondência exata (Exact Match) não apresenta o valor correto, mesmo que esteja armazenada corretamente na base de dados do Edge quando é visualizada a nova IU. Os valores corretos são representados na IU clássica.

  • Problema 117993 resolvido: quando um utilizador parceiro que gere as empresas do cliente que utilizam autenticação nativa (por outras palavras, nome de utilizador/palavra-passe) ou um utilizador empresarial tenta repor uma palavra-passe para um utilizador empresarial, a tentativa falhará.

    O utilizador verá o erro: o utilizador não tem privilégios para aceder a [enterpriseUser/sendEnterpriseUserPasswordResetEMail] (user does not have privileges required to access [enterpriseUser/sendEnterpriseUserPasswordResetEMail]). Este problema só ocorre na nova IU e deve-se ao facto de existirem parâmetros de pedido em falta. Se este problema ocorrer, o utilizador poderá mudar para a IU clássica para a reposição de palavra-passe funcionar como esperado.

  • Problema 118074 resolvido: um utilizador pode não conseguir abrir determinadas definições do dispositivo na página Configurar > Edge > Dispositivo (Configure > Edge > Device) da nova IU do VMware SASE Orchestrator.

    As definições que podem não estar acessíveis incluem Interfaces, IPv6, VPN de cloud, Destino Não-SD-WAN (NSD) e Serviço de Segurança na Cloud (CSS). Este problema é atribuído às definições WAN que requerem um endereço IP público e se este endereço não estiver presente, será apresentado um erro na nova IU e bloqueado o acesso a essas definições. As definições do dispositivo funcionam como esperado na IU clássica.

  • Problema 118544 resolvido: o utilizador pode observar que um perfil do operador não é carregado e que está inacessível, por isso, não pode ser atribuído a uma empresa do cliente.

    Existe um problema com a base de dados do Orchestrator em que o perfil do operador está presente, mas um ID lógico incorreto será adicionado a um módulo de configuração se uma empresa do cliente for eliminada, o que impedirá o seu carregamento.

  • Problema 118733 resolvido: quando é utilizada a nova IU do VMware SASE Orchestrator e, se uma política empresarial ou regra de firewall estiver configurada ao nível do perfil e, em seguida, for substituída ao nível do Edge, ao consultar o ecrã Configurar > Edges > Listar Edges (Configure > Edges > List Edges), os ícones do Edge substituído não serão representados corretamente para Dispositivo (Device), Empresa (Business) e Firewall.

    Os ícones com a opção Sobrepor configuração do Edge (Edge Override) marcada devem ser apresentados com cor sólida e, em vez disso, são apresentados vazios. O Orchestrator clássico apresentará corretamente os ícones com cor sólida quando a opção Sobrepor configuração do Edge (Edge Override) tiver sido configurada para uma categoria específica.

  • Problema 119733 resolvido: a base de dados do VMware SASE Orchestrator pode registar uma falha e deixar de funcionar.

    Esse problema deve-se ao facto de a base de dados não ter a versão estável mais recente do MySQL. A versão 5.1.0.6 do Orchestrator corrige essa deficiência com uma versão atualizada do MySQL.

  • Problema 120606 resolvido: ao tentar criar uma nova função em Cliente > Definições globais > Gestão de utilizadores > Nova função (Customer > Global Settings > User Management > New Role), será apresentado um erro e os privilégios não serão carregados.

    Quando ocorrer este problema, o utilizador verá “erro de método” (method error) na página da IU ao criar uma nova função e que também impedirá que os privilégios sejam carregados.

     

Resolvido na versão R5105-20230611-GA do Orchestrator

A compilação R5105-20230611-GA do Orchestrator foi lançada a 13/06/2023 e é a 5.ª compilação rollup do Orchestrator para a versão 5.1.0.

Esta compilação rollup do Orchestrator aborda os problemas importantes abaixo desde a quarta compilação rollup R5104-20230426-GA do Orchestrator.

  • Problemas que ocorrem apenas na nova IU do Orchestrator e não na IU clássica do Orchestrator

    A versão 5.1.0.5 do Orchestrator inclui um grande número de correções relacionadas com problemas com que um cliente se pode deparar apenas ao utilizar a nova IU e que não ocorrem ao utilizar a IU clássica. A tabela abaixo apresenta todas essas correções com descrições dos sintomas de cada problema.

    Problemas apenas da nova IU resolvidos

    Pedido

    Sintoma/Descrição

    Problema 87089 corrigido

    O utilizador não tem a opção de editar o endereço do cliente na página Monitorizar > Edges > Origens (Monitor > Edges > Sources). A correção adiciona um ícone de lápis azul no qual é possível clicar para editar uma entrada.

    Problema 112044 corrigido

    Para um site onde está implementado um destino Não-SD-WAN via Edge do tipo Zscaler, ao analisar Monitorizar > Serviços de rede (Monitor > Network Services), a nova IU não apresenta a coluna Subscrições IaaS (IaaS Subscriptions) na página Estado da implementação (Deployment Status).

    Problema 112451 corrigido

    Quando um utilizador está a editar um perfil de configuração e, em Dispositivo > Interfaces > Os seus modelos Edge (Device > Interfaces > Your Edge Models), seleciona o Edge 3810, a página do browser deixa de responder e não é possível guardar, e o utilizador tem de atualizar a página para recuperar. O cliente não consegue utilizar o Edge 3810 para esse perfil.

    Problema 112500 corrigido

    Para um site onde está implementado um Serviço de Segurança na Cloud (CSS) com o tipo Zscaler, ao analisar Monitorizar > Edges (Monitor > Edges) e ao passar o rato sobre os túneis Edge para um Edge, a IU não mostra a Cidade e o Estado do CSS Zscaler.

    Problema 112809 corrigido

    Um Administrador de cliente com uma função Só de leitura de empresa pode ver a página Monitorização > Routing (Monitoring > Routing) na IU.

    Problema 112906 corrigido

    Um utilizador pode observar que as páginas da IU são carregadas com uma formatação estranha, em que a página tem grandes secções de espaços em branco.

    Problema 112912 corrigido

    Um Administrador de cliente com uma função de Suporte de empresa não tem a opção de selecionar Ações remotas > Reiniciar (Remote Actions > Reboot) para um Edge.

    Problema 113254 corrigido

    Um Administrador de parceiro com uma função Superutilizador ou Padrão não consegue alterar o perfil de operador predefinido de um cliente sob a respetiva gestão.

    Problema 113366 corrigido

    Um utilizador não consegue configurar um caminho estático onde um IP secundário de VLAN seja o próximo hop.

    Problema 113963 corrigido

    Se um utilizador criar uma Regra de firewall e definir uma Aplicação para essa regra e, posteriormente, editar a mesma regra e alterar a Aplicação, a alteração não é aplicada e a regra mantém a Aplicação anterior.

    Problema 114291 corrigido

    Se um Serviço de Segurança na Cloud (CSS) estiver configurado num perfil, o utilizador não consegue alternar entre segmentos e não tem a oportunidade de guardar as Definições do dispositivo (Device Settings) depois de um CSS ter sido alterado em vários segmentos diferentes.

    Problema 114564 corrigido

    O utilizador não pode configurar a Definição 802.1P (802.1P Setting) na configuração opcional para uma interface do Edge.

    Problema 114602 corrigido

    O utilizador não tem nenhuma opção para configurar Alertas do operador ou Alertas da empresa em Definições do serviço > Alertas e notificações (Service Settings > Alerts & Notifications).

    Problema 114912 corrigido

    A página Visão geral do Parceiro (Partner Overview) não inclui definições para o Acordo do utilizador (User Agreement).

    Problema 115307 corrigido

    Quando a sessão de um utilizador permanece inativa durante tempo suficiente para acionar um limite de tempo, a IU não apresenta uma mensagem de fim de sessão. Em vez disso, entra em modo de suspensão e, quando o utilizador acede à IU, o Orchestrator ativa e permite que o utilizador aceda ao Orchestrator em vez de o redirecionar para a página de início de sessão.

    Problema 115439 corrigido

    Quando um utilizador navega para Configurar > Perfil > Definições do dispositivo > BGP (Configure > Profile > Device Settings > BGP), observa o BGP como presente, mas, se ordenar por Segmento com deteção (Segment Aware), a opção para configurar o BGP fica em falta.

    Problema 115653 corrigido

    Quando um Administrador de parceiro está a ver a respetiva página Gerir clientes (Manage Customers), a IU não comunica se o cliente está a utilizar Gateways que estão num estado de serviço desligado. Isso impede que o parceiro tome medidas oportunas para garantir que o cliente está a utilizar apenas Gateways ativos.

    Problema 115719 corrigido

    Uma regra de backhaul desaparece da página Configurar > Política empresarial (Configure > Business Policy) se for feita alguma alteração nas Definições do dispositivo (Device Settings) ao nível do perfil.

    Problema 116523 corrigido

    Quando um utilizador está a definir uma configuração de inserção de VNF e está a tentar configurar a Alta disponibilidade de VNF no Edge, o Orchestrator não guarda a alteração de VNF depois de a HA ter sido configurada.

    Problema 117527 corrigido

    Quando um utilizador está a configurar o BGP ao nível do perfil, o browser pode deixar de responder se estiver configurado um grande número de regras.

  • Problema 105861 resolvido: quando uma ligação WAN fica inativa por vários minutos e recupera, Monitorizar > Gráfico de QoE (Monitor > QoE graph) não reflete o estado real da ligação.

     A QoE deve estar a vermelho enquanto a ligação estiver inativa e, em seguida, retomar a cor (verde se for de boa qualidade) quando a ligação for restaurada. Isso não está a acontecer e causa confusão para os utilizadores. O problema é causado pelo facto de a base de dados do VMware SASE Orchestrator não registar o evento de ligação inativa corretamente.

  • Problema 106295 resolvido: no caso de um Destino Não-SD-WAN com um tipo AWS, quando os gateways principais e secundários são configurados com o BGP configurado em cada um, o VMware SASE Orchestrator poderá mostrar os túneis secundários redundantes como inativos, apesar de estarem ativos.

    O lado do AWS vai comunicar os túneis principais e secundários como ativos, mas na página Monitorizar > Serviços de rede (Monitor > Network Services) do Orchestrator, o secundário aparece como inativo. Trata-se de um problema estritamente cosmético.

  • Problema 107180 resolvido: quando um utilizador está a configurar uma VNF com um tipo Fortinet, não consegue ver a versão da imagem do Fortinet 6.49 ou 7.2.0 no menu pendente.

    Estas imagens são suportadas na versão 5.1.0, mas não podem ser acedidas por um cliente.

  • Problema 107766 resolvido: quando um cliente configura um Destino Não-SD-WAN via Edge ou um CSS (Serviço de Segurança na Cloud) e também configura a opção Verificação de estado de funcionamento de nível 7 (L7), o cliente pode observar que os túneis são marcados inesperadamente como inativos ou ativos comparativamente com o que deve ocorrer com base no respetivo valor de configuração da Verificação de estado de funcionamento de L7.

    O problema é que o Orchestrator envia para o VMware SD-WAN Edge os parâmetros predefinidos da Verificação de estado de funcionamento L7, independentemente da configuração efetuada pelo cliente. Como resultado, mesmo que as condições do túnel correspondam à configuração do cliente, o estado do túnel pode permanecer inalterado porque está a aderir ao valor predefinido da Verificação de estado de funcionamento L7.

  • Problema 110826 resolvido: quando um VMware SD-WAN Edge é atribuído a uma empresa cliente, o VMware SASE Orchestrator não move automaticamente o Edge para o separador “Inventário atribuído” (Assigned Inventory) na aplicação de gestão de inventário Maestro.

    Quando os Edges não atribuídos são solicitados ao Maestro e o Orchestrator procura números de série já atribuídos, o número do modelo Edge não é comparado, o que causa problemas em que os Edges são atribuídos duas vezes.

  • Problema 111957 resolvido: depois de um operador atualizar um VMware SASE Orchestrator, os utilizadores podem observar erros relacionados com falhas em atualizações de esquema de execução prolongada. Por exemplo, os caminhos aprendidos recentemente (BGP ou OSPF) podem estar em falta na página OFC. Também serão observados erros nos registos de carregamento num Orchestrator relacionados com os caminhos aprendidos.

    Uma chave externa no VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC é ignorada e novamente adicionada a uma atualização do Orchestrator da versão 4.2.x para a versão 4.3.x ou posterior como atualização de esquema de execução prolongada. Esta chave externa ainda não existe em Orchestrators cujo caminho de atualização foi realizado através de algumas compilações 2.1.x com um defeito de atualização E um Gateway que estava a aprender os caminhos BGP que foi eliminado do Orchestrator. Em tais Orchestrators, a adição de chaves externas na atualização 4.2.x > 4.3.x ou posterior irá falhar se existir uma chave externa que viole os registos já presentes na tabela.

    A correção para este problema corrige a causa raiz ao eliminar a chave externa que está a violar os registos e, em seguida, ao adicionar novamente a chave externa.

    Se estiver a atualizar para um Orchestrator sem uma correção para este problema, a solução alternativa é executar a seguinte consulta no esquema do VeloCloud de MySQL: DELETE FROM VELOCLOUD_LEARNED_PARTNER_ROUTE_ASSOC WHERE gatewayId not in (selecione o ID de VELOCLOUD_GATEWAY) e, em seguida, acionar novamente as atualizações de esquema de longa execução.

  • Problema 112333 resolvido: um VMware SASE Orchestrator que processa cerca de 4000 VMware SD-WAN Edges com cerca de 6000 túneis e fluxo de tráfego contínuo pode tornar-se instável durante um período de cerca de 4 dias e começar a terminar a sessão dos utilizadores aleatoriamente.

    A tensão faz com que a base de dados do Orchestrator falhe e acione o erro “connect ECONNREFUSED” seguido pelo endereço IP do Orchestrator. Este problema só foi observado num ambiente de teste de escala e não numa implementação de campo.

  • Problema 112605 resolvido: um cliente pode observar que, ao tentar atribuir um Cluster de hub em Configurar > Dispositivo > VPN de cloud > Edge para sites SD-WAN (Configure > Device > Cloud VPN > Edge to SD-WAN Sites), o perfil não responde e a configuração não pode ser guardada.

    O Orchestrator cria associações de configuração duplicadas onde existem várias Políticas empresariais de backhaul e as referências duplicadas acionam a falha na configuração e atribuição de Clusters de hub.

  • Problema 112992 resolvido: quando a empresa de um cliente é migrada de um VMware SASE Orchestrator para outro, o Orchestrator adiciona um registo UUID.

    O registo UUID é adicionado aos registos VELOCLOUD_ENTERPRISE_OBJECT, quando não deveria ser.

  • Problema 113209 resolvido: um utilizador não poderá eliminar um VMware SD-WAN Edge do SASE Orchestrator se o Edge estiver num estado “Degradado” (Degraded).

    O Orchestrator gera a mensagem de erro “Não é possível eliminar Edges degradados e ligados” (Degraded edges and connected edges cannot be deleted). Embora um utilizador não deva poder eliminar um Edge ligado, deverá conseguir eliminar um Edge degradado. 

  • Problema 113375 resolvido: para um VMware SASE Orchestrator implementado com uma topologia de Recuperação após desastre (DR), quando o Orchestrator é atualizado da versão 4.5.x para a 5.1.x, a atualização pode falhar.

    O script de atualização e os iptables falham com o código de devolução 1. O problema pode ser acionado durante o período em que os Orchestrators ativos e em Standby estão a executar versões de software diferentes e os iptables não são carregados corretamente quando o Orchestrator em Standby tenta atualizar (o que é esperado e temporário) e o erro faz falhar toda a atualização. A correção simplesmente transforma o erro iptables num aviso e permite que a atualização continue.

  • Problema 114240 resolvido: em Proposta IPsec Edge (Edge IPsec Proposal), quando um utilizador altera a encriptação para AES-128-GCM ou AES-256-GCM e guarda a configuração, a IU do Orchestrator gera um erro.

    O erro indica: “A encriptação instance.ipsec.não é um dos valores enum: AES_128_CBC, AES_256_CBC, DES_CBC” (instance.ipsec.encryption is not one of enum values: AES_128_CBC, AES_256_CBC, DES_CBC). O problema é o resultado das duas encriptações do tipo GCM serem adicionadas por engano ao menu Encriptação (Encryption) quando não são opções válidas. Estas opções são removidas no Orchestrator atualizado.

  • Problema 115624 resolvido: um VMware SASE Orchestrator pode enfrentar uma elevada utilização da CPU e instabilidade, juntamente com o carregamento lento das páginas da IU Definições do dispositivo (Device Settings) e Definições de rede (Network Settings) quando o serviço do portal é reiniciado.

    O problema foi encontrado num Orchestrator com cerca de 2000 Edges ligados ao utilizar Serviços de Segurança na Cloud (CSS) e pode ocorrer com este número de Edges ligados ou mais. O problema é causado por vários processos do Orchestrator relacionados com as configurações do Edge, do Perfil e da Rede serem carregados a partir dos Edges para o Orchestrator e demorarem muito mais tempo a concluir do que o esperado (cerca de 60 segundos ou mais).

  • Problema 116141 resolvido: quando um utilizador altera as Definições do dispositivo (Device Settings) num perfil de configuração, o VMware SASE Orchestrator demora um tempo excessivo a validar as alterações.

    Cada alteração pode demorar até um minuto a ser validada e aplicada, quando deveria demorar apenas alguns segundos. O problema está associado a um processo do Orchestrator que não só está a obter uma contagem de todos os registos de configuração do Edge associados a esse perfil, mas também está a descodificar e a analisar cada registo, o que é desnecessário e desgastante para a CPU do Orchestrator. A correção garante que o processo obtém apenas a contagem dos registos.

  • Problema 116770 resolvido: quando um utilizador operador cria uma autoridade de certificação (CA) externa com um comprimento de cadeia de 2 ou mais na raiz de confiança, o VMware SASE Orchestrator não permite um valor pathLengthConstraint de 0 num subordinado.

    Um subordinado que não tem permissão para assinar um subordinado abaixo dele é uma configuração válida e deve ser permitida pelo Orchestrator, mas um processo impede que a configuração seja guardada.

  • Problema 116790 resolvido: quando um VMware SASE Orchestrator é atualizado para a versão 5.1.x ou posterior, a versão dos VMware SD-WAN Edges do cliente pode ser inadvertidamente reduzida para uma versão do Edge mais antiga do que aquela que o Edge está configurado para utilizar.

    O problema é acionado quando uma empresa do cliente é eliminada do Orchestrator e estava associada a um Perfil de operador através do respetivo ID lógico na base de dados do Orchestrator. Quando a empresa é eliminada, o Perfil de operador também é eliminado. Os clientes com a Gestão de imagem Edge (Edge Image Management) configurada e vários Perfis de operador disponíveis e que tinham este Perfil de operador eliminado atribuído como predefinição recebem um Perfil de operador que permanece disponível no menu Gestão de imagem Edge (Edge Image Management). Como resultado, pode ser atribuído ao cliente um perfil do operador com uma versão do Edge muito mais antiga e os Edges atribuídos a esse perfil do operador podem ter o seu software alterado e a respetiva versão pode ser reduzida levando a uma possível interrupção, incluindo falha de rede, se o Edge estiver a executar uma versão mais antiga que não suporte funcionalidades que o cliente esteja a utilizar.

  • Problema 116976 resolvido: quando um administrador de parceiro inicia sessão num VMware SASE Orchestrator, pode observar que o Orchestrator não está a apresentar o estado correto das ligações WAN que estão inativas há mais de 24 horas nos VMware SD-WAN Edges que gerem.

    A API do Orchestrator devolve apenas ligações recentes para Parceiros/MSPs, enquanto os utilizadores empresarias do cliente normais obtêm as informações corretas sobre o estado da ligação, o que afeta a capacidade de um Parceiro oferecer suporte adequado aos seus clientes em caso de problemas com ligações.

  • Problema 117800 resolvido: quando um VMware SASE Orchestrator é atualizado da versão 4.x para a 5.1.x ou posterior, o operador pode observar que, após a reinicialização do processo de back-end, é criado o mesmo ficheiro upgradeSchema.sql, mesmo que tenha sido executado com êxito.

    Este problema ocorre com a atualização de esquema pós-atualização e, assim que o script pós-esquema é executado, o ficheiro upgradeSchema.sql não deve ser gerado novamente.

  • Problema 118071 resolvido: a tentativa do utilizador de alterar as definições de VPN em Configurar > Perfil > Dispositivo (Configure > Profile > Device) pode falhar com um erro se existirem vários VMware SD-WAN Gateways atribuídos ao cliente, todos com cerca de 2000 Edges ou mais atribuídos.

    O erro do Orchestrator indica “Erro ao validar as alterações” (Error validating changes). O VMware SASE Orchestrator não está a atualizar as definições de VPN porque a API está a aguardar uma consulta da base de dados que devolve um excesso de 10 000 linhas, algo que pode acontecer com um Orchestrator a operar em grande escala. O problema é causado pelo facto de o Orchestrator obter todos os Gateways, independentemente do tipo (principal e secundário), quando deveria ter apenas o relatório do Edge do respetivo Gateway principal. Isto aumenta muito o número de registos devolvidos e pode sobrecarregar uma consulta em escala.

Resolvido na versão R5104-20230426-GA do Orchestrator

A compilação R5104-20230426-GA do Orchestrator foi lançada a 27/04/2023 e é a 4.ª compilação rollup do Orchestrator para a versão 5.1.0.

Esta compilação rollup do Orchestrator aborda os problemas importantes abaixo desde a terceira compilação rollup R5103-20230315-GA do Orchestrator.

  • Problemas que ocorrem apenas na nova IU do Orchestrator e não na IU clássica do Orchestrator

    A versão 5.1.0.4 do Orchestrator inclui um grande número de correções relacionadas com problemas com que um cliente se pode deparar apenas ao utilizar a nova IU e que não ocorrem ao utilizar a IU clássica. A tabela abaixo apresenta todas essas correções com descrições dos sintomas de cada problema.

    Problemas apenas da nova IU resolvidos

    Pedido

    Sintoma/Descrição

    Problema 104785 resolvido

    Quando um utilizador está na página Monitorizar > Eventos (Monitor > Events) e clica no botão de atualização dos eventos, o carimbo de data/hora da tabela Eventos (Events) não é atualizado e os eventos mais recentes não aparecem na tabela, a menos que a página do browser seja recarregada.

    Problema 106327 resolvido

    Quando um utilizador está na página Monitorizar > Eventos (Monitor > Events) e está a configurar um filtro para eventos, algumas opções de filtro estão ausentes e limitam a forma como os eventos do Edge podem ser filtrados.

    Problema 107071 resolvido

    Quando um utilizador está na página Monitorizar > Eventos (Monitor > Events) e seleciona uma janela de tempo grande o suficiente para que sejam devolvidos mais de cinco milhões de eventos, a página expira e falha ao carregar.

    Problema 107980 resolvido

    Quando um utilizador está na página Configurar > Edge > Visão geral (Configure > Edge > Overview), não pode alterar o nome de um Edge, a menos que também preencha os dados de Contacto e Localização (Contact & Location), se os dados de contacto local estiverem em branco.

    Problema 108072 resolvido

    Quando um utilizador tenta configurar uma interface de retorno com o mesmo endereço IP em vários segmentos, o Orchestrator impede-o e mostra a mensagem de aviso “Deve ser único” (Must be unique).

    Problema 109284 resolvido

    Quando um utilizador adiciona um túnel para um destino Não-SD-WAN (NSD) via Edge do tipo Azure ou Zscaler, os campos Tipo de identificação de local (Local Identification Type), Identificação de local (Local Identification) e PSK podem ser editados.

    Problema 109300 resolvido

    Quando um utilizador observa qualquer área do Orchestrator onde deve ser configurada uma licença, só pode ver a licença selecionada e nenhuma outra. O Orchestrator filtra e exclui todas as outras opções de licença quando é selecionada uma licença e a correção para este problema inclui um novo botão Limpar (Clear) à direita do menu pendente de licenças para permitir a seleção de outra opção de licença.

    Problema 109532 resolvido

    Ao examinar a página Configurar > Serviços de rede (Configure > Network Services), os endereços IP DNS diferem na nova IU face à IU clássica porque a nova IU mostra campos diferentes.

    Problema 109533 resolvido

    Na página Configurar > Edge > Dispositivo > Conectividade > VLAN (Configure > Edge > Device > Connectivity > VLAN), o servidor DHCP aparece como Ativado (Enabled) quando devia ser apresentado o estado Reencaminhamento (Relay), que é mais preciso.

    Problema 109715 resolvido

    Uma ligação WAN inativa desaparece da página Monitorizar > Visão geral da rede (Monitor > Network Overview) após 24 horas, mesmo que o Limite de ligação inativa do Edge (Edge Down Link Limit) esteja definido como um valor superior a 24 horas.

    Problema 109788 resolvido

    Ao configurar qualquer destino Não-SD-WAN, um utilizador não pode configurar uma Sub-rede do site (Site Subnet) com um valor de 0.0.0.0/0 e o Orchestrator declara-o um “Prefixo CIDR inválido” (Invalid CIDR Prefix).

    Problema 109836 resolvido

    Os caminhos estáticos do Gateway de parceiro não são distribuídos para os Edges ao configurar estes caminhos na nova IU. Estes caminhos devem ser distribuídos para os Edges ligados como Caminhos de cloud (Tipo = cloud ) e mostrados numa captura da tabela de caminhos, mas não são.

    Problema 109911 resolvido

    Ao configurar uma política empresarial, na secção Direção de ligação > Interfaces (Link Steering > Interfaces), se o tipo de overlay WAN for “Desativado” (Disabled), essa interface não poderá ser selecionada. A nova IU permite apenas interfaces relacionadas com o overlay WAN que sejam descobertas automaticamente ou definidas pelo utilizador.

    Problema 110094 resolvido

    Ao editar uma interface Edge e adicionar muitos filtros de uma só vez ao OSPF, a grelha de filtros desaparece. Quando forem adicionados filtros OSPF suficientes para que a paginação apareça na grelha de filtros OSPF, a altura da grelha é definida como 0 e o utilizador deixa de a poder editar ou ver.

    Problema 110330 resolvido

    Os administradores de parceiros e clientes podem não conseguir ver o separador Definições globais > Permissões de serviço (Global Settings > Service Permissions) mesmo que a respetiva função permita que o façam. A personalização da função do utilizador está documentada em Permissões de serviço (Service Permissions).

    Problema 111104 resolvido

    Ao observar a página Definições do serviço > Gestão do Edge > Imagens de software e firmware (Service Settings > Edge Management > Software & Firmware Images), se um utilizador expandir uma linha na parte inferior da tabela, não poderá ver todos os detalhes.

    Problema 111407 resolvido

    Quando um utilizador está na página Configurar > Edge > Dispositivo > Conectividade > Interfaces (Configure > Edge > Device > Connectivity > Interfaces), não tem permissão para configurar uma interface definida pelo utilizador sem também adicionar uma ligação WAN.

    Problema 111444 resolvido

    Ao configurar um Serviço de Segurança na Cloud (CSS) com um tipo Zscaler, o utilizador não tem permissão para configurar o URL de início de sessão do Zscaler (Zscaler Login URL) com um URL, recebe a mensagem O FQDN é inválido (FQDN is invalid) e o valor do URL de início de sessão não é enviado para um servidor nem guardado.

    Problema 111934 resolvido

    Ao atualizar qualquer campo de um destino Não-SD-WAN via Edge com o tipo Zscaler, o Orchestrator remove o campo Grupo DH (DH Group).

    Problema 111944 resolvido

    Um Superutilizador operador não pode modificar nem eliminar uma Propriedade do sistema (System Property).

    Problema 112094 resolvido

    Quando um utilizador altera as credenciais de um Serviço de Segurança na Cloud (CSS) num segmento não global e, na mesma sessão, muda para um segmento global, as credenciais do CSS são removidas.

    Problema 112201 resolvido

    Se um utilizador configurar um Serviço de Segurança na Cloud (CSS) através de uma API e definir o CSS como Nenhum (em branco), na configuração do CSS do VMware Edge, o Orchestrator não apresentará uma configuração, mas as respostas da API e a base de dados do Edge terão o CSS ativo e a funcionar. Um CSS neste estado não pode ser utilizado como parte de uma política empresarial.

    Problema 112224 resolvido

    Quando um administrador de cliente com uma função de Superutilizador, Padrão ou Suporte navega para Diagnóstico (Diagnostics), a ligação da página Pacotes de diagnóstico (Diagnostic Bundles) não está presente, mesmo que a função do mesmo permita o acesso a esta secção. Como resultado, o administrador de cliente não pode gerar (mas não transferir) um pacote de diagnóstico e não pode gerar e transferir uma captura de pacotes.

    Problema 112437 resolvido

    Se um utilizador abrir várias sessões de Diagnóstico remoto (Remote Diagnostics) para o mesmo Edge, o carregamento da página poderá falhar se tiverem sido abertas sessões suficientes.

  • Problema 95631 resolvido: quando um utilizador navega para Monitorizar > Serviços de rede > Sites de Serviços de Segurança na Cloud (Monitor > Network Services > Cloud Security Service Sites) e tenta ordenar os eventos pela Hora de alteração de estado (State Change Time), a sequência de ordenação está incorreta.

    Quando um utilizador tenta ordenar pela coluna Hora de alteração de estado (State Change Time) da tabela CSS, a ordenação está incorreta porque as datas não são ordenadas pelo carimbo de data/hora, mas sim pela data da análise. Este problema ocorre tanto na IU clássica como na nova.

  • Problema 106907 resolvido: Quando um cliente tiver configurado um Destino Não-SD-WAN (NSD) via Edge associado a uma política empresarial, se um utilizador posteriormente utilizar a sobreposição de configuração do Edge para desativar o NSD via Edge, a política empresarial não será removida num VMware SASE Orchestrator com a versão 5.1.0.

    O Orchestrator deve remover a política empresarial assim que o NSD via Edge for desativado porque, se a regra persistir, o tráfego correspondente a essa política empresarial será direcionado para um destino inexistente, resultando na remoção desse tráfego.

  • Problema 106929 resolvido: Um operador pode não conseguir atribuir uma versão de software a um perfil de operador no VMware SASE Orchestrator utilizando a versão 5.1.0.

    O Orchestrator apresenta um erro semelhante ao seguinte:

    Mensagem de erro.

    O problema é provocado pelo facto de o Orchestrator fazer com que a tentativa de adicionar a imagem de software exceda o tempo limite devido a consultas de API de base de dados concorrentes. Este problema pode ocorrer com mais probabilidade num Orchestrator que aloje um grande número de Edges, como é o caso de Orchestrators alojados em VMware e pode ocorrer com a Nova IU ou a IU Clássica.

    Num Orchestrator sem uma correção para este problema, a única solução é aumentar o valor do tempo limite para ligações de base de dados.

  • Problema 107349 resolvido: ao observar Monitorizar > Edge > Origens (Monitor > Edge > Sources) no VMware SASE Orchestrator, algumas ou até mesmo todas as origens podem não ser resolvidas e mostrar “Não é possível resolver” (Unable to resolve).

    Este problema é inconsistente e alguns sites numa empresa de cliente podem mostrar os IPs e os endereços MAC das origens conforme esperado. O problema é provocado por uma tabela de base de dados do Orchestrator para nomes de Edges que não está a ser atualizada.

    Se um cliente se deparar com este problema num Orchestrator sem uma correção para o mesmo, poderá desativar a VPN de cloud numa janela de manutenção e, em seguida, ativá-la novamente para forçar o Orchestrator a obter os nomes de Edges corretos.

  • Problema 108363 resolvido: depois de um VMware SASE Orchestrator ter sido atualizado para uma versão 5.x, os VMware SD-WAN Edges que implementam o CSS (Serviço de Segurança na Cloud), como o Zscaler, e que têm uma Verificação de estado de funcionamento de nível 7 (L7) também configurada podem sofrer uma perda de tráfego com esse CSS durante cerca de 30 segundos.

    Após a atualização do Orchestrator, é acionada uma atualização de configuração para todos os Edges, o que pode fazer com que alguns sites CSS com a Verificação de estado de funcionamento de L7 configurada fiquem inativos até que a configuração seja corrigida. O problema está ligado ao Problema 107302 resolvido, que aborda o problema no Edge. A correção aqui presente impede que o Orchestrator acione atualizações de configuração para Edges numa atualização e, portanto, protege os Edges que não têm a correção para o problema 107302.

  • Problema 110946 resolvido: um VMware SD-WAN Orchestrator com a versão 4.2.x ou anterior pode falhar quando atualizado para se tornar um SASE Orchestrator com a versão 4.3.x ou posterior.

    Um Orchestrator 4.2.x ou anterior não limpa a cache apt antes de executar a rotina do serviço de atualização apt quando o Orchestrator é atualizado para a versão 4.3.x ou posterior e, como resultado, a base de dados MySQL é reiniciada durante a atualização e a atualização falha.

    Se atualizar para uma versão do Orchestrator sem uma correção para este problema, o operador pode executar o comando rm -rf /var/lib/apt/lists/ antes da atualização.

  • Problema 111665 resolvido: ao atualizar um VMware SASE Orchestrator de uma versão anterior do Orchestrator para a versão 5.1.0, a migração do dispositivo de cliente pode não ser concluída.

    O problema afeta a migração de dados do dispositivo de cliente de um Orchestrator que utilize o MySQL para outro que utilize o ClickHouse. Após a migração de um determinado número de registos, o processo de migração termina prematuramente.

  • Problema 111946 resolvido: um utilizador não consegue ver os caminhos no separador Edge > Monitorizar > Caminhos (Edge > Monitor > Paths) num VMware SASE Orchestrator quando a lista de pares é superior a 100.

    Quando um utilizador navega para o separador Edge > Monitorizar > Caminhos (Edge > Monitor > Paths), o back-end do Orchestrator devolve todos os registos, mesmo que existam mais de 100. Isto ocorre porque o back-end omite a restrição do limite, que é o número máximo de registos que devem ser devolvidos. Os registos devolvidos após a contagem do limite não são normalizados, o que significa que não são formatados de forma compatível com a IU. Isto causa um erro na IU. O Orchestrator só deve devolver os registos que estejam no limite enviado.

  • Problema 112458 resolvido: quando é adicionado um novo VMware SD-WAN Gateway a um conjunto de Gateways e é iniciado um reequilíbrio de Gateway, o novo Gateway não é redistribuído para os VMware SD-WAN Edges, mesmo que os Gateways existentes estejam sobrecarregados.

    O VMware SASE Orchestrator deve reatribuir vários Edges ao Gateway com menos carga na mesma região geográfica quando é efetuado um reequilíbrio de Gateway. Com este problema, os Edges mantêm a atribuição de Gateway existente, apesar de o Gateway atribuído estar sobrecarregado.

  • Problema 112885 resolvido: pode ser acionado um reequilíbrio de Gateway para fluxos de trabalho não diretamente relacionados com o fluxo de trabalho acionador através da IU do VMware SASE Orchestrator.

    Esta correção aborda o problema em que podem ocorrer reequilíbrios de Gateway para fluxos de trabalho fora do que é pretendido para uma empresa dedicada. Um reequilíbrio de Gateway só deve ser acionado através da IU do Orchestrator ao nível do Operador e por nenhum outro meio.

  • Problema 114475 resolvido: quando um Operador tenta atualizar um VMware SASE Orchestrator da versão 4.2.0 para 5.1.0, o Orchestrator pode comunicar que a atualização falhou.

    Nos registos, o Operador veria esta entrada: Error while initializing CWS Server service Error: Too many connections. Este problema é causado pela reinicialização do MySQL antes da instalação de vco-db-schema, o que se deve ao facto de o MySQL não definir o número máximo de ligações. Além disso, apesar de o Orchestrator comunicar que a instalação falhou, na realidade, a instalação foi concluída e o utilizador pode reiniciar o Orchestrator e todos os serviços funcionarão conforme o esperado.

Resolvido na versão R5103-20230315-GA do Orchestrator

A compilação R5103-20230315-GA do Orchestrator foi lançada a 15/03/2023 e é a terceira compilação rollup do Orchestrator para a versão 5.1.0.

Esta compilação rollup do Orchestrator aborda os problemas críticos abaixo desde a segunda compilação rollup R5102-20230222-GA do Orchestrator.

  • Problema 107587 resolvido: Um operador não consegue editar os detalhes do utilizador de outros operadores ou de administradores do cliente no VMware SASE Orchestrator.

    Espera-se que os operadores tenham o privilégio de editar os detalhes do utilizador em Administração > Gestão de utilizadores (Administration > User Management) de outro operador, se a sua função o permitir, e de editar um administrador do cliente se a delegação da gestão estiver ativada. Com este problema, o operador observaria os detalhes do utilizador como “só de leitura”, sem os poder editar.

  • Problema 107725 resolvido: Quando um utilizador a utilizar a nova IU do VMware SASE Orchestrator navega para Monitorizar > Edges > Distribuição no mapa (Monitor > Edges > Map Distribution), o mapa mostra apenas um máximo de 20 VMware SD-WAN Edges de cada vez e não todos os Edges implementados por um cliente.

    Este problema afeta os clientes que implementam > 20 Edges, pois a Distribuição no mapa (Map Distribution) na nova IU mostrará apenas 20 Edges de cada vez na lista de Edges do cliente. Quando o utilizador clica na página seguinte da lista, o mapa mostrará apenas os Edges dessa página. Não existe uma opção para apresentar todos os Edges de uma empresa do cliente.

  • Problema 108533 resolvido: Quando um utilizador navega para Definições do serviço > Gestão do Edge > Configurar atualizações (Service Settings > Edge Management > Configure Updates), o texto explicativo das definições não está claro na nova IU do VMware SASE Orchestrator.

    O nome da definição Desativar atualizações de configuração do Edge (Disable Edge Configuration Updates) contradiz a função real da definição e, com esta correção, é alterado para Ativar atualizações de configuração do Edge (Enable Edge Configuration Updates) para se alinhar com a função e o texto explicativo.

  • Problema 108833 resolvido: Se um utilizador alterar um filtro BGP num segmento não global na nova IU do VMware SASE Orchestrator, o Orchestrator substituirá essa alteração de filtro BGP no segmento global por esta nova definição.

     Para um cliente que utiliza o BGP em vários segmentos com definições exclusivas em cada um, este problema pode provocar uma falha na rede para os utilizadores que utilizam o segmento global onde as definições do BGP são substituídas. O problema não é observado ao utilizar a IU clássica.

  • Problema 109064 resolvido: Um utilizador poderá configurar o mesmo SSID (Service Set Identifier) em duas interfaces de Wi-Fi diferentes para um VMware SD-WAN Edge se configurar o filtro MAC numa e não na outra interface de Wi-Fi.

    A configuração do mesmo SSID para WLAN1 e WLAN2, um com filtro MAC ligado e outro com filtro MAC desligado, ou com uma lista de permissões MAC diferente em cada interface não deve ser permitida pelo VMware SASE Orchestrator, pois permite que endereços MAC não aprovados sejam ligados.

Resolvido na versão R5102-20230222-GA do Orchestrator

A compilação R5102-20230222-GA do Orchestrator foi lançada a 24/02/2023 e é o segundo rollup do Orchestrator para a versão 5.1.0.

Esta compilação rollup do Orchestrator aborda os problemas críticos abaixo desde a primeira compilação rollup R5101-20221220-GA do Orchestrator.

  • Problema 40584 resolvido: Quando um utilizador observa Monitor > Edge > Fontes (Sources) no VMware SASE Orchestrator, poderá verificar que, apesar de terem sido adicionados novos dispositivos cliente ao VMware SD-WAN Edge, o Orchestrator não exibe o mais recente dispositivo cliente quando é utilizado o modo de Visibilidade de IP.

    Este problema pode ocorrer quando o Modo de visibilidade (Visibility Mode) do Edge é configurado como Visibilidade por endereço IP (Visibility by IP Address). Este problema é provocado pelo facto de o Orchestrator não processar a informação do cliente mais recente do Edge quando utiliza o modo Endereço IP (IP Address) corretamente, apresentando assim apenas o cliente mais antigo e o respetivo endereço IP.

  • Problema 105610 resolvido: Quando um utilizador tenta criar um novo grupo de objetos IPv4 ou tenta atualizar um grupo de objetos IPv4 existente que inclui uma máscara de carácter universal que começa com “255” e termina com “0” (por exemplo, 255.0.1.0), o VMware SASE Orchestrator não permite esta máscara de carácter universal e emite um erro mesmo que esta seja uma expressão de carácter universal válida e devesse ser permitida.

    Começando pela versão 5.0.x e posteriores, os Orchestrators não têm validação para máscaras de carácter universal em grupos de objetos e, como resultado, emitem um erro quando um utilizador configura uma máscara de carácter universal para um.

  • Problema 106159 resolvido: Um VMware SASE Orchestrator que executa a versão 5.1.0.0 e 5.1.0.1 não permite que os utilizadores nativos criem tokens de API quando a autenticação é configurada como Início de sessão único (SSO) e o Fornecedor de identidade (IdP) correspondente não suporta o ponto final de introspeção.

    A versão 5.1.0.0 introduz uma verificação de ponto final de introspeção IdP durante a validação de criação de token de API. Esta verificação não distingue os utilizadores nativos de utilizadores não nativos e desde que o SSO esteja configurado para a autenticação, o Orchestrator verificará se o IdP suporta o ponto final de introspeção. Assim, se o IdP não suportar o ponto final de introspeção, a validação impedirá que os utilizadores nativos e não nativos criem tokens de API. Esta condição é verdadeira tanto para os Utilizadores operadores como para os Administradores de parceiro.

  • Problema 106242 resolvido: Um utilizador que aceda à página Diagnóstico (Diagnostics) > Diagnóstico remoto (Remote Diagnostics) no VMware SASE Orchestrator pode ver a sessão inesperadamente terminada na página Diagnóstico remoto (Remote Diagnostics) enquanto realiza o diagnóstico de qualquer Edge.

    Quando um utilizador encontra este problema, é porque o Orchestrator atingiu um limite para o número de ligações possíveis, e o Orchestrator termina a sessão dos utilizadores de Diagnóstico remoto para garantir um funcionamento normal. Este problema é provocado pelo facto de o Orchestrator não libertar, erroneamente, ligações de base de dados quando estas já não são necessárias, levando o Orchestrator a acionar comportamentos de limitação de ligações.

  • Problema 106592 resolvido: Num VMware SASE Orchestrator que executa a versão 5.1.0.0 e 5.1.0.1, um cliente que utilize APIs pode observar os seguintes sintomas: a) Os tokens de API ativos são revogados pelo Orchestrator e b) Serviços como o APIv2 deixam de funcionar.

    A versão 5.1.0.0 introduz uma nova tarefa de back-end denominada batchRevokeApiTokenForInactiveSsoUsers que será executada de 6 em 6 horas para revogar os tokens de API emitidos anteriormente para utilizadores de Início de sessão único (SSO) inativos. Defeitos na tarefa de back-end provocam uma revogação errónea de todos os tokens de API no Orchestrator independentemente dos destinatários dos tokens.

    Com a correção, um administrador de cliente com um superutilizador ou um administrador de parceiro deve eliminar manualmente os utilizadores inativos do Fornecedor de identidade (IdP) do Orchestrator para impedir o acesso não autorizado através de tokens de API.

  • Problema 106806 resolvido: Quando atualizar um VMware SASE Orchestrator para a versão 5.1.0, os clientes ligados ao Orchestrator podem encontrar perturbações no tráfego de cliente.

    O Orchestrator cria uma nova versão de módulo de definições de dispositivo como parte da sua atualização para a versão 5.1.0. Em seguida, o Orchestrator envia esta nova versão de definições de dispositivo para todos os Edges ligados e isto pode provocar perturbações porque certas alterações de definições de dispositivo podem acionar um reinício do serviço Edge, o que resulta numa perturbação do tráfego do cliente de 10-15 segundos. A correção para este problema garante que o Orchestrator não envia uma versão atualizada de definições de dispositivo para todos os Edges ligados quando é atualizado para a versão 5.1.0.

  • Problema 107410 resolvido: No caso de um administrador de parceiro que utiliza a nova IU no VMware SASE Orchestrator, quando este tenta atribuir uma imagem de software a um dos clientes de parceiro, o utilizador verifica que não pode deslocar-se no menu pendente que apresenta as imagens de software.

    O resultado é que, exceto se o parceiro vir a imagem de software que pretende na apresentação inicial de imagens quando o menu pendente é aberto, não será capaz de deslocar-se para baixo para encontrar a imagem que pretende se estiver mais abaixo. Os utilizadores operadores não têm qualquer problema em fazê-lo e o administrador de parceiro continua a poder deslocar-se com a IU Clássica quando atribui uma imagem de software a um Cliente.

  • Problema 107637 resolvido: Um cliente com um grande número de VMware Edges pode descobrir, ao navegar para Configurar (Configure) > Edges na IU Clássica do VMware SASE Orchestrator, que a página não carrega.

    Este problema ocorre na IU Clássica e a página excederá o tempo limite com a mensagem “Ocorreu um erro inesperado” (An unexpected error has occurred). Os utilizadores não terão este problema ao utilizar a Nova IU.

    Ecrã de erro.

    Ao resolver o problema, um operador descobrirá nos registos do Orchestrator que o método enterprise/getEnterpriseEdgeList está a falhar com o seguinte erro:

    2023-02-06T17:21:05.412Z - error: [[email protected]] [24775] API Invocation error for enterprise/getEnterpriseEdgeList: { code: undefined, message: 'Internal error' }

    Este problema é provocado por uma API de Orchestrator que obtém a lista de Edges para um cliente em cenários como Configurar (Configure) > Edges. Na IU Clássica, esta API é utilizada de uma forma que pode exceder o tempo limite, especialmente quando é necessário obter um grande número de Edges (por exemplo, quinhentos ou mais Edges).

  • Problema 107885 resolvido: No caso de qualquer utilizador com a nova IU do VMware SASE Orchestrator, a página Configurar (Configure) > Visão geral (Overview) pode não ser carregada para alguns VMware SD-WAN Edges.

    Este problema é inconsistente e a página Configurar (Configure) > Visão geral (Overview) pode ser carregada para alguns Edges. Este problema é desencadeado quando o módulo QoS do Edge não é preenchido com informação de segmento.

    Num Orchestrator sem uma correção para este problema, um utilizador pode configurar uma política empresarial de teste que não tenha impacto no tráfego do utilizador e guardá-la e, em seguida, a página “Visão geral” (Overview) será carregada com sucesso.

  • Problema 108074 resolvido: Quando um utilizador navega na caixa de informações do Edge no ecrã Monitor > Edge, a Descrição (Description) está ausente ao analisar estas informações na nova IU do VMware SASE Orchestrator.

    No ecrã da IU clássica de Monitorizar > Edge, o ecrã pendente Informações do Edge (Edge information) mostra a Descrição (Description) configurada:


    No ecrã da nova IU de Monitorizar > Edge, o ecrã pendente Informações do Edge (Edge information) não mostra a Descrição (Description) configurada:


    Um utilizador pode configurar a Descrição (Description) do Edge na página Configurar > Edge > Visão geral (Configure > Edge > Overview).

  • Problema 108309 resolvido: Na nova IU do VMware SASE Orchestrator com a versão 5.1.0, quando um utilizador tenta associar um VMware SD-WAN Edge a um Destino Não-SD-WAN (NSD) através da sobreposição de configuração do Edge, a opção de configuração do túnel não é apresentada.

    A opção de configuração do túnel deve ser apresentada como última coluna no ecrã como Ação (Action) com um símbolo + neste problema em que o símbolo + está em falta.


    Este problema é limitado a ações específicas do Edge e, se um cliente adicionar um NSD através de um perfil que o Edge está a utilizar (em vez de utilizar a sobreposição de configuração do Edge), a opção Ação + (Action +) será apresentada corretamente.


Resolvido na versão R5101-20221220-GA do Orchestrator

A compilação R5101-20221220-GA do Orchestrator foi lançada a 20/12/2022 e é o primeiro rollup do Orchestrator para a versão 5.1.0.

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

  • Problema 100133 resolvido: um VMware SASE Orchestrator pode ter problemas de desempenho.

    Quando um cliente configura um grande número de regras de política empresarial ao associá-las a um Cluster de Hub Edge, o Orchestrator depara-se com problemas de desempenho sempre que precisa de enviar estas configurações para os Edges nessa empresa.

  • Problema 101835 resolvido: a secção VPN de cloud (Cloud VPN) não está disponível na nova IU do Orchestrator se o utilizador selecionar um segmento não global em que a VPN de cloud esteja configurada.

    Na nova IU do Orchestrator, na página de definições Configurar (Configure) > Edge > Dispositivo (Device), a secção VPN de cloud (Cloud VPN) não está disponível se o utilizador selecionar um segmento não global em que a VPN de cloud esteja configurada.

  • Problema 102806 resolvido: o cliente não consegue editar a configuração do handoff do Gateway de parceiro a um nível por Gateway.

    Este problema ocorre quando um cliente configura o handoff do Gateway de parceiro durante uma atualização.

  • Problema 103622 resolvido: o utilizador operador pode observar a mensagem de erro: “Não tem permissão para aceder a estes dados” (You don’t have permission to access this data) ao tentar aceder a algumas páginas no VMware SASE Orchestrator.

    Este problema é observado na nova IU do Orchestrator quando um utilizador operador tenta aceder à página Gestão de utilizadores operadores ou parceiros (Operator or Partner User Management) após visitar as páginas Definições globais (Global Settings), Cloud Web Security ou Secure Access num cliente.

Resolvido na versão R5100-20221202-GA do Orchestrator

A versão R5100-20221202-GA do Orchestrator foi lançada em 12-08-2022 e resolve os seguintes problemas desde a versão do Orchestrator R5011-20221129-GA.

A versão 5.1.0 contém todas as correções do Orchestrator que estão listadas nas notas de versão 5.0.0 ou 5.0.1.

  • Problema 91407 resolvido: Quando um overlay WAN definido pelo utilizador é configurado como ligação de backup, o VMware SASE Orchestrator a executar a versão 5.0.x apresenta a ligação como ativa em Monitorizar (Monitor) > Edge, mas a ligação está, efetivamente, no modo Backup.

    Este é apenas um problema de visualização e a função de ligação WAN de backup está a funcionar corretamente. Este problema é provocado porque o Orchestrator não guarda corretamente os valores do Modo de ligação para o Edge, sendo apresentado um estado incorreto.

  • Problema 91393 resolvido: No caso de um cliente que recolha dados do Edge utilizando syslong ou telnet, o utilizador pode observar dois nomes para a mesma aplicação nos dados NetFlow a partir do VMware SD-WAN Edge.

    Este problema surge quando existem aplicações em que o displayName no ficheiro de idioma (appids_en_us.json) difere do displayName no ficheiro de aplicações (applications.json). Como o displayName do ficheiro applications.json é utilizado do lado do Edge, não deve sofrer alterações.

    Este problema ocorre porque o displayName do ficheiro applications.json estava a ser alterado para o displayName do ficheiro appids_en_us.json como parte de uma resposta API e sempre que os dados de mapa de aplicação são atualizados, cada displayName do mapa de aplicação é atualizado, mesmo que o utilizador não o tenha alterado e o mesmo seja enviado para o Edge.

  • Problema 12132 resolvido: Quando configura um caminho estático no VMware SASE Orchestrator, a IU alerta para um Reinício do Serviço Edge que não ocorre realmente.

    Quando altera a configuração em qualquer caminho estático e guarda as alterações, a IU do Orchestrator avisa que ocorrerá um reinício do Edge e uma perturbação do serviço. Esta mensagem é inválida e não existe um reinício do serviço Edge associado à alteração de uma configuração de caminho estático. A correção remove o aviso falso.

  • Problema 36058 resolvido: Uma ligação WAN configurada como ligação de backup pode ser apresentada a cinzento na página Monitorizar (Monitor) > Visão geral (Overview) da IU do VMware SASE Orchestrator quando a ligação está efetivamente inativa.

    O ecrã teria o seguinte aspeto:


    Ao consultar a página Monitorizar > Edge > Visão geral (Monitor > Edge > Overview), o estado da ligação de backup apresenta o estado correto.

  • Problema 52952 resolvido: A IU do VMware SASE Orchestrator permite que um utilizador configure entradas inválidas para o AS Path Prepend.

    A IU do Orchestrator não inspeciona um valor de AS Path Prepend inválido. Um utilizador pode introduzir o AS PATH Prepend com valores que incluam uma vírgula, e a IU aceita-o mesmo que esta seja uma configuração inválida para o processo de routing do Edge. A configuração inválida não é aplicada e o utilizador não recebe feedback, por exemplo, um aviso, uma mensagem de erro ou uma dica sobre a configuração inválida.

  • Problema 53740 resolvido: Quando configura uma regra de firewall na IU do VMware SASE Orchestrator, o utilizador não pode configurar um valor de protocolo para um protocolo que pretende fazer corresponder.

    O Orchestrator apenas permite TCP/UDP/ICMP/GRE nos critérios de correspondência de protocolo e não permite valores de protocolo entre 0 e 255. A alteração permite ao utilizador configurar uma regra de firewall correspondente e, em Destino (Destination), o utilizador seleciona Outro (Other) no menu Protocolo (Protocol) e, em seguida, introduz um valor entre 0 e 255.

    Embora um utilizador possa introduzir um valor entre 0 e 255, os valores de protocolo entre 144 e 255 são considerados reservados ou não atribuídos de acordo com a documentação Números do Protocolo de Internet Atribuídos IANA.

  • Problema 68347 resolvido: O VMware SASE Orchestrator apresenta erradamente um Zscaler IPsec para o evento de túnel GRE como um evento de túnel Edge IPsec na página Alertas.

    Não é suposto serem gerados alertas para eventos de túnel GRE.

  • Problema 70987 resolvido: Um utilizador pode não conseguir eliminar um VMware SD-WAN Edge do VMware SASE Orchestrator.

    Os Edges estão offline, mas não são atualizados para o estado “desligado”, permanecendo num estado degradado e, assim, não são elegíveis para eliminação.

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

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

  • Problema 73481 resolvido: Quando dois ou mais VMware SD-WAN Gateways são implementados no mesmo local, um operador pode verificar que um Gateway está a ser utilizado pela maior parte dos VMware SD-WAN Edges, enquanto outros Gateways são subutilizados, o que pode provocar problemas de desempenho no Gateway utilizado a toda a sua capacidade.

    Com este problema, um Gateway será utilizado a 90%, enquanto outro, no mesmo local, será utilizado a 10%, com recursos de sobra. As atribuições de Gateway principal e secundário para Edges têm de levar em consideração a carga existente nos Gateways. Caso contrário, um único Gateway é sobrecarregado enquanto Gateway principal, sobrando muita capacidade não utilizada num Gateway secundário.

  • Problema 75175 resolvido: Quando um administrador de cliente tenta aceder à página Informações do gateway (Gateway Information) no VMware SASE Orchestrator, ocorre um erro na página.

    Após ser concluída uma migração do gateway, Monitorizar (Monitor) > Edge > Ver (View), recebe a mensagem de erro: Erro ao carregar as informações do gateway


    Os Administradores de cliente não devem poder aceder à página Informações do gateway (Gateway Information). No entanto, ao tentarem aceder a essa página, devido ao respetivo nível de privilégio, ocorrerá um erro na secção.

  • Problema 76091 resolvido: Um utilizador pode verificar que, ao editar uma sub-rede no ecrã Configurar (Configure) > Dispositivo (Device), o ecrã fica bloqueado.

    Se clicar no botão Repor (Reset) ou mover o Edge para “Saídas VPN elegíveis” (Eligible VPN Exits) e, em seguida, o utilizador clicar em Guardar (Save) para uma sub-rede que não tenha aprendido caminhos, a IU ficará bloqueada e o ícone de carregamento girará sem parar.


     

    O problema é provocado pela falta da matriz learnedRoute nessas sub-redes, o que aciona uma falha da IU.

  • Problema 76182 resolvido: Ao selecionar determinados intervalos de tempo na página Monitorizar (Monitor) > Edge da IU do VMware SASE Orchestrator, o Orchestrator poderá apresentar dados incompletos.

    No caso de uma consulta do utilizador com intervalos múltiplos de 5, ou seja, 12:00:00 – 13:00:00, o back-end envia apenas 11 amostras de 5 minutos, em vez das 12 amostras corretas, devido a um problema com a API de estatísticas de ligação do Edge.

  • Problema 77538 resolvido: Quando a empresa de um cliente é migrada de um VMware SASE Orchestrator para um Orchestrator diferente, o cliente poderá ver perfis de operador duplicados e imagens de software Edge duplicadas.

    Não só os perfis do operador duplicados são confusos para o cliente, como apontam para o Orchestrator antigo e, assim, um Edge que utilize um destes perfis emitiria um heartbeat para o Orchestrator errado, fazendo com que o Edge fosse marcado como inativo e não recebesse atualizações de configuração.

  • Problema 79383 resolvido: Ao efetuar uma alteração de configuração em Configurar (Configure) > Dispositivo (Device), o utilizador poderá ver uma mensagem de erro, mas não o nome do segmento em que ocorreu o erro.

    Um exemplo disto acontece quando, enquanto comuta uma interface Edge de caminho para switched ao nível do perfil, um utilizador vê a cadeia “object.segment.name”, em vez do nome do segmento quando existe um erro nas definições do dispositivo.


    Se a empresa cliente estiver a utilizar múltiplos segmentos, a resolução de problemas torna-se muito difícil quando não se sabe ao certo qual é o segmento com o erro.

  • Problema 80445 resolvido: Ao configurar o OSPF no VMware SASE Orchestrator, um utilizador pode verificar que o ID de área OSPF permite a existência de entradas duplicadas entre IP e Número e que o valor de ID de área OSPF “0” é permitido como ID válido.

    O Orchestrator não verifica se existem entradas duplicadas comparando com IPs e Número de tipo de formato para IDs de área. Além disso, permite o valor “0” como um ID de área OSPF válido. Em resultado disto, o utilizador pode configurar e publicar por engano uma configuração de OSPF inválida com efeitos negativos consequentes.

  • Problema 81364 resolvido: Quando utiliza a nova interface do utilizador do Orchestrator para configurar interfaces do VMware SD-WAN Edge, as definições de velocidade e duplex não são atualizadas para interfaces routed.

    Num Orchestrator sem uma correção para este problema, o utilizador teria de utilizar o Orchestrator clássico para configurar as definições de velocidade e duplex para uma interface routed de um Edge.

  • Problema 81366 resolvido: Quando utiliza a nova Interface do Utilizador do Orchestrator para configurar um site do cliente utilizando Alta Disponibilidade, as alterações não são guardadas para o intervalo de sonda APR sob os valores LOS.

    O intervalo de sonda APR revisto em Deteção LOS não apresenta os valores configurados para o Edge HA. Num Orchestrator sem uma correção para este problema, os valores de sonda APR têm de ser configurados no Orchestrator clássico.

  • Problema 83342 resolvido: Ao tentar criar um relatório com demasiados Edges, o VMware SASE Orchestrator apresenta uma mensagem de erro vaga, que não explica o motivo da falha do relatório.

    A geração de um relatório com um erro não permite ver os detalhes do erro na IU e impede o utilizador de corrigir o motivo da falha.


    Os dados de registo do serviço terão os detalhes em falta, se necessário, num Orchestrator sem a correção.

    N/D

  • Problema 83345 resolvido: Se a tentativa de criar um relatório falhar no VMware SASE Orchestrator devido a tempo limite excedido, a IU não apresenta um erro de validação.

    Este pedido está relacionado com o 83342 e, em ambos os casos, os registos não fornecem detalhes suficientes para corrigir o problema. A diferença aqui é que a causa do problema pode gerar um relatório sem Edges e exceder o tempo limite de relatório sem uma explicação do erro.

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

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

  • Problema 84064 resolvido: Um cliente que implemente o Hub Virtual do Microsoft Azure tem a opção de configurar o BGP no VMware SASE Orchestrator.

    O BGP não é oficialmente suportado no “Hub Virtual do Microsoft Azure”, que é automatizado. No entanto, os utilizadores podem configurar o BGP no Orchestrator e se um utilizador configurar a automatização do Azure com o BGP, os túneis para o Gateway ficam inativos e o site Azure não passará tráfego.


  • Problema 88811 resolvido: Num VMware SASE Orchestrator que utilize a versão 5.0.x, um superutilizador operador não pode criar tokens API para utilizadores cliente mesmo que estes tenham privilégios delegados.

    Este problema é provocado pelo facto de o superutilizador operador não ter o privilégio CREATE ENTERPRISE_API_TOKEN. Em resultado disso, o operador não pode criar, ler ou revogar tokens API para outros utilizadores.

  • Problema 88845 resolvido: Quando um utilizador tenta remover interfaces de uma lista de VLANs empresariais e guarda as alterações num VMware SASE Orchestrator utilizando a IU clássica, o Orchestrator não remove as interfaces.

    Ao guardar as alterações desta ação, o Orchestrator ignora a alteração de configuração porque o formato de dados json não corresponde ao formato de dados da IU clássica.

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

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

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

    1. Na IU do Orchestrator de um determinado Edge, aceda a Configurar > Dispositivo (Configure > Device) e desloque-se a página até Definições WAN (WAN Settings).

    2. Para que a ligação WAN seja testada de novo, selecione Editar (Edit) para a ligação a ser novamente medida e, em seguida, selecione Avançadas (Advanced) para serem apresentadas definições adicionais.

    3. No menu Medição da largura de banda (Bandwidth Measurement), altere o método de medição da largura de banda da corrente para um método diferente (por exemplo, se a ligação utilizar o Modo burst, altere para Início lento, ou vice-versa) e clique em Atualizar ligação (Update Link) e, em seguida, Guardar alterações (Save Changes) na parte superior da página do dispositivo.

    4. Assim que tiver sido realizada uma medição na ligação WAN, altere o método de medição novamente para o método original de forma a garantir a medição mais precisa para a respetiva ligação WAN. Isto aciona um teste adicional da largura de banda.

  • Problema 88998 resolvido: Um utilizador não pode clonar uma regra de política empresarial ou de firewall num VMware SASE Orchestrator a executar a versão 5.0.x utilizando a IU clássica.

    Na versão 5.0.x da IU clássica do Orchestrator, as opções IPv6 e Mistas (IPv4 e IPv6) foram desativadas para a regra de Política empresarial do Edge. No entanto, os utilizadores podem utilizá-las se forem clonadas regras já existentes, mas o resultado é uma mensagem de erro.

    Este problema não ocorre com a nova IU do Orchestrator e um utilizador pode solucionar este problema utilizando a nova IU.

  • Problema 91231 resolvido: No caso de um VMware SASE Orchestrator implementado com uma topologia de recuperação após desastre, a configuração inicial da replicação DR poderá falhar se uma tarefa de truncagem de tabela grande for acionada durante a fase de importação de tabela grande do processo DR.

    Se a importação de fundo de estatística demorar mais de 24 horas, colidirá com as tarefas de truncagem automática executadas diariamente. A tarefa trunca as partições antigas das tabelas grandes que são replicadas também no servidor MySQL em standby.

    Contudo, entre o processo, o MySQL pode ter uma importação de dados em curso para a mesma tabela e isso provoca a falha da replicação, resultando na falha do processo DR global.

    Se este problema surgir num Orchestrator sem a correção, o processo DR poderá ser iniciado após a hora de alteração diária UTC. Contudo, isso não garante uma prevenção quando o Orchestrator é grande e o DR pode demorar mais de 24 horas até terminar.

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

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

Problemas conhecidos

Problemas conhecidos do Edge/Gateway

Problemas pendentes na versão 5.1.0.

  • Problema 105933: o utilizador não consegue efetuar SSH no VMware SD-WAN Edge dos modelos 610/610-LTE ou 520/540 através de uma interface encaminhada.

    Não existe nenhuma regra de remoção de pacotes SSH duplicados originados através de um driver af-pkt utilizado pelo SO do Edge afetado. Por isso, o kernel do Edge recebe 2 pacotes SSH: um através da interface vce1 e outro direto devido à natureza do driver. Isto faz com que o kernel do Edge responda a 2 pedidos de SSH, o que confunde o cliente do SSH e causa a falha do SSH.

    Solução alternativa: no caso de um Edge sem uma correção para este problema, o utilizador pode adicionar uma regra da tabela IP para remover os pacotes SSH recebidos de interfaces diferentes de vce1.

  • Problema 115136: um cliente pode observar um aumento gradual da utilização da memória num VMware SD-WAN Edge numa empresa de cliente que utiliza BGP para routing.

    O daemon BGP do Edge está a provocar uma fuga de memória gradual no Edge ao longo de vários dias e pode fazê-lo mesmo quando o BGP não está configurado para esse Edge. Se a fuga de memória continuar durante um período suficiente para levar a utilização da memória do Edge para lá do limiar crítico de 60% da RAM disponível durante mais de 90 segundos, o Edge realizará um reinício defensivo do serviço para eliminar a fuga, o que pode resultar numa interrupção do tráfego do cliente durante 10 a 15 segundos.

    Solução alternativa: A única remediação sem uma correção do Edge é reiniciar o processo BGP encerrando-o ou executando preventivamente uma reinicialização do serviço do Edge/recuperação automática de HA numa janela de serviço adequada.

  • Problema 117037: no cas de um cliente que utiliza uma topologia Hub/Spoke na qual sejam utilizadas várias ligações WAN para enviar e receber tráfego do Spoke Edge para o Hub Edge, os clientes podem observar um desempenho inferior ao esperado para o tráfego que é direcionado pelas Políticas empresariais, porque as ligações WAN não agregam a largura de banda da ligação WAN.

    O SD-WAN utiliza um contador para contabilizar o número de pacotes armazenados em buffer numa fila de nova sequenciação. Este contador é gerido por par e utilizado para garantir que só os pacotes 4K são armazenados em buffer por par. Sob algumas condições, este contador pode tornar-se negativo. Antes da versão 4.2.x, quando este contador ficava negativo, o respetivo contador era imediatamente reposto a 0 depois de esvaziar os pacotes na fila de nova sequenciação. No entanto, a partir da versão 4.3.x, este contador é atualizado automaticamente para garantir que permanece dentro dos limites esperados.

    O resultado desta alteração no comportamento pode causar casos em que a contagem do contador está incorreta e a fila de nova sequenciação pode permanecer num número muito alto ao qual a SD-WAN reage esvaziando cada pacote. Esta ação não só impede a agregação de largura de banda, como também pode reduzir a eficácia dos fluxos que, de outra forma, ficariam numa única ligação.

    Solução alternativa: Nos Edges sem uma correção para o problema, a solução será configurar políticas empresariais que direcionem o tráfego correspondente para uma única ligação obrigatória.

Problemas conhecidos do Orchestrator

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