| VMware SASE 5.1.0 | 17 de fevereiro de 2023
Verifique se existem adições e atualizações a estas notas de versão. |
| VMware SASE 5.1.0 | 17 de fevereiro de 2023
Verifique se existem adições e atualizações a estas notas de versão. |
As notas de versão abrangem os seguintes tópicos:
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.
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 e 3.3.x do VMware SD-WAN para todos os componentes e a versão 3.4.x para o Orchestrator e o Gateway 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 chegará ao fim da orientação técnica (EOTG) a 30 de setembro de 2022.
Nota: Diz apenas respeito ao Orchestrator e ao Gateway. A versão 3.4.x do Edge está agendada para chegar ao fim do suporte a partir de 31 de dezembro de 2022.
Para mais informações, consulte o artigo da Base de Dados de Conhecimentos: Anúncio: fim do período de suporte para a versão 3.x (84151) do VMware SD-WAN
A versão 4.0.x do VMware SD-WAN chegou ao fim do suporte para Gateways e Orchestrators. As versões 4.2.x e 4.3.x estão a aproximar-se do fim de suporte.
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 chegará ao fim da orientação técnica (EOTG) a 30 de março de 2023.
A versão 4.2.x dos Edges chegará ao fim do suporte geral (EOGS) a 30 de junho de 2023 e ao fim da orientação técnica (EOTG) a 30 de setembro de 2025.
A versão 4.3.x dos Orchestrators e dos Gateways chegará ao fim do suporte geral (EOGS) a 30 de junho de 2023 e ao fim da orientação técnica (EOTG) a 30 de setembro de 2023.
A versão 4.3.x dos Edges chegará ao fim do suporte geral (EOGS) a 30 de junho de 2023 e ao fim da orientação técnica (EOTG) a 30 de setembro de 2025.
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.
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.
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.
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 comutada
Os clientes podem utilizar a autenticação RADIUS utilizando o protocolo 802.1x em portas comutadas, quando, anteriormente, estavam limitados às portas encaminhadas. A autenticação RADIUS de porta comutada é 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 encaminhadas, 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 comutadas. O MAB baseado em RADIUS é suportado apenas para interfaces encaminhadas.
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 comutada 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 3x00
Os modelos Edge 3400, 3800 e 3810 aumentam 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.
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.
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 codificar a velocidade e o duplex nas portas GE1–GE4 num modelo VMware SD-WAN Edge 620, 640 ou 680; nas portas GE3 ou GE4 num Edge 3400, 3800 ou 3810; ou num Edge 520/540 quando um SFP com interface de cobre é utilizado nas portas SFP1 ou SFP2, pode descobrir que, mesmo após um reinício, a ligação não aparece.
Tal deve-se ao facto de cada um dos modelos Edge indicados utilizar o Intel Ethernet Controller i350, que tem a seguinte limitação: quando a negociação automática não é utilizada em ambos os lados da ligação, não consegue detetar dinamicamente os fios adequados para transmitir e receber (MDIX automático). Se ambos os lados da ligação estiverem a transmitir e a receber nos mesmos fios, a ligação não será detetada. Se o lado do par também não suportar o MDIX automático sem a negociação automática e a ligação não aparecer com um cabo reto, será necessário um cabo Ethernet cruzado para estabelecer a ligação.
Para obter mais informações, consulte o artigo da BDC Limitação ao desativar a negociação automática nos modelos VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 e 3810 (87208).
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.
8 de dezembro de 2022. Primeira ediçã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.
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.
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.
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 comutadas que dependem de uma VLAN para a autenticação 802.1x. Assim, o MAB apenas é suportado em interfaces encaminhadas a partir desta versão 5.1.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.
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.
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 VMware SD-WAN Edges 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: Os sites de clientes cujos VMware SD-WAN Edges utilizam um VMware SD-WAN Gateway específico como Gateway principal podem ter problemas com o tráfego de utilizadores destinado ao Gateway, porque o Gateway não pode ligar-se à Internet mesmo que apareça como ativo na monitorização do Orchestrator.
Quando este problema ocorre, o Gateway não consegue transmitir pacotes para o serviço de acesso remoto (RAS) pelo facto de estes pacotes ficarem encravados na fila de transmissão do Gateway e, por esse motivo, os Edges ligados a este Gateway não podem criar túneis para o mesmo. Este problema ocorre apenas para pacotes de dados que contêm tráfego de clientes e não para pacotes keepalive entre o Gateway e o RAS, razão pela qual o Gateway continuará a aparecer como ativo na monitorização do Orchestrator, apesar do problema ocorrido. O tráfego de clientes sinalizado como Direto para a Internet não será afetado por este problema, uma vez que não utiliza um Gateway para aceder à Internet.
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 do Edge e Gateway que estão listadas nas notas de versão 5.0.0 ou 5.0.1.
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 ver a página Monitorizar (Monitor) > Edge > System (Sistema), 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: Para uma empresa 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 é removido no VMware SD-WAN Gateway e o mapa de caminho é aplicado com o mesmo.
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 64526 resolvido: Quando um utilizador muda a interface GE2 num VMware SD-WAN Edge de comutada para encaminhada 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 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 encaminhado/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 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 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: uma empresa de cliente com uma topologia Hub/Spoke que utiliza um Gateway de parceiro como um 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: para um VMware SD-WAN Edge a executar a versão 5.0.0 que está configurado com 128 segmentos, o processo dnsmasq do Edge irá parar e encerrar.
Quando o IPv6 estiver ativado em 128 segmentos e os servidores DCPv6 estiverem configurados na LAN de cada segmento, o processo dnsmasq irá parar ao ser excedido o total de descritores de ficheiros abertos. O processo dnsmasq continuará durante ~30 minutos antes de encerrar, altura em que a atribuição DHCP de endereços IP do Edge irá falhar.
Solução alternativa: Reiniciar o Edge restaura o processo dnsmasq durante ~30 minutos, mas voltará a falhar. A única solução alternativa real é reduzir o número de segmentos para menos de 128.
Problema 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 é 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.
Este erro pode induzir um cliente a pensar que algo está errado com o Wi-Fi do Edge quando o processo está a funcionar corretamente. Os modelos Edge em que isto não ocorre são as linhas de modelo Edge 510 e Edge 6x0. Todos os outros modelos com um módulo Wi-Fi (500, 520, 540) estão sujeitos a este problema.
Problema 85156 resolvido: Problema 85156: 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 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 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 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 encontrar uma falha do 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 de corrida 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 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 comutada 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 encaminhadas.
A mensagem de erro que pode ser visualizada é “erro ao ler os dados para o teste” (error reading data for test). Se o teste for concluído, os resultados das interfaces encaminhadas estão vazios sem quaisquer informações sobre velocidade ou duplex. De qualquer forma, o estado da interface é inválido. O problema está relacionado com o comando de depuração subjacente ao estado da interface omitir as portas DPKD ativadas.
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 encaminhadas.
Problema 93853 resolvido: um VMware SD-WAN Gateway sobrecarregado pode encontrar uma falha do 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 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 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 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 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 encontrar uma falha do 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.
A compilação R5102-20230216-GA do Orchestrator foi lançada a 17-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 compilação 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 para o Edge quando utiliza o modo de Endereço IP 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 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:
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 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.
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: [user@domain.com.167566721.441107] [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.
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.
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 ver a página Monitorizar (Monitor) > Edge > Visão geral (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 comutado 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 encaminhadas.
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 encaminhada 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:
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).
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.
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.
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 pendentes na versão 5.1.0.
Problema 14655:
Ligar ou desligar um adaptador SFP pode fazer com que o dispositivo pare de responder no Edge 540, Edge 840 e Edge 1000 e exija um reinício físico.
Solução alternativa: o Edge deve ser reiniciado fisicamente. Este procedimento pode ser realizado no Orchestrator utilizando Ações Remotas > Reiniciar Edge (Remote Actions > Reboot Edge) ou através do ciclo de ativação do Edge.
Problema 25504:
Custos do caminho estático superiores a 255 podem resultar numa ordenação de caminho imprevisível.
Solução alternativa: utilize um custo de caminho entre 0 e 255.
Problema 25595:
Poderá ser necessário um reinício para que as alterações ao SLA estático num overlay WAN funcionem corretamente.
Solução alternativa: reinicie o Edge após adicionar e remover o SLA estático do overlay WAN.
Problema 25742:
O tráfego contabilizado de underlay está limitado à capacidade máxima do VMware SD-WAN Gateway, mesmo que seja inferior à capacidade da ligação WAN privada que não está ligada ao Gateway.
Problema 25758:
As ligações WAN USB podem não ser corretamente atualizadas quando são trocadas de uma porta USB para outra, até que o VMware SD-WAN Edge seja reiniciado.
Solução alternativa: reinicie o Edge após mover as ligações WAN USB de uma porta para outra.
Problema 25885:
Uma grande atualização de configuração no Gateway de parceiro (por exemplo, 200 VRFs configurados por BGP) pode provocar um aumento da latência durante cerca de 2 a 3 segundos para algum tráfego através do VMware SD-WAN Gateway.
Solução alternativa: nenhuma solução alternativa disponível.
Problema 25921:
A recuperação automática do VMware SD-WAN Hub de alta disponibilidade demora mais do que o esperado (até 15 segundos) quando existem três mil Edges de ramo ligados ao Hub.
Solução alternativa: nenhuma solução alternativa disponível.
Problema 25997:
O VMware SD-WAN Edge pode precisar de um reinício para passar corretamente tráfego numa interface encaminhada que foi convertida para uma porta comutada.
Solução alternativa: reinicie o Edge após fazer a alteração de configuração.
Problema 26421:
O Gateway de parceiro primário para qualquer site do ramo também deve ser atribuído a um cluster do VMware SD-WAN Hub para túneis ao cluster a ser estabelecido.
Solução alternativa: nenhuma solução alternativa disponível.
Problema 28175:
O NAT de Política Empresarial falha quando o IP do NAT se sobrepõe ao IP de interface do VMware SD-WAN Gateway.
Solução alternativa: nenhuma solução alternativa disponível.
Problema 31210:
VRRP: o ARP não é resolvido no cliente LAN para o endereço IP virtual VRRP quando o VMware SD-WAN Edge é primário com um segmento CDE não global em execução na interface LAN.
Solução alternativa: nenhuma solução alternativa disponível.
Problema 32731:
os caminhos predefinidos condicionais anunciados através de OSPF podem não ser retirados corretamente quando o caminho é desativado.
Solução alternativa: a reativação do caminho, seguida de uma nova desativação, permitirá retirá-los com sucesso.
Problema 32960:
O estado da interface de “Negociação automática” (Autonegotiation) e “Velocidade” (Speed) pode ser apresentado incorretamente na IU de Web Local para os VMware SD-WAN Edges ativados.
Solução alternativa: consulte a IU do Orchestrator em Diagnóstico remoto > Estado da interface (Remote Diagnostics > Interface Status).
Problema 32981:
A codificação da velocidade e do duplex numa porta configurada por DPDK pode exigir o reinício do VMware SD-WAN Edge para que as configurações entrem em vigor, uma vez que exige a desativação do DPDK.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 34254:
Quando o CSS Zscaler é criado e o segmento global tem definições de FQDN/PSK configuradas, estas definições são copiadas para segmentos não globais para formar túneis IPsec para um CSS Zscaler.
Problema 35778:
Quando existem múltiplas ligações WAN definidas pelo utilizador numa única interface, apenas uma dessas ligações WAN pode ter um túnel GRE para o Zscaler.
Solução alternativa: utilize uma interface diferente para cada ligação WAN que precisa de criar túneis GRE para o Zscaler.
Problema 36923:
O nome do cluster não pode ser atualizado corretamente na descrição da interface de NetFlow para um VMware SD-WAN Edge que está ligado a esse Cluster como o seu Hub.
Problema 38682:
Um VMware SD-WAN Edge que atua como um servidor DHCP numa interface configurada por DPDK pode não gerar corretamente eventos de “Novo dispositivo de cliente” para todos os clientes ligados.
Problema 38767:
Quando um overlay WAN que tenha túneis GRE configurados para o Zscaler é alterado da deteção automática para definido pelo utilizador, os túneis obsoletos podem permanecer até ao próximo reinício.
Solução alternativa: reinicie o Edge para limpar o túnel obsoleto.
Problema 39374:
alterar a ordem dos Gateways de parceiro do VMware SD-WAN atribuídos a um VMware SD-WAN Edge pode não definir corretamente o Gateway 1 como o Gateway local a ser utilizado para o teste de largura de banda.
Problema 39608:
A saída do “Teste de Ping” (Ping Test) de Diagnóstico Remoto pode apresentar brevemente conteúdos inválidos, antes de apresentar os resultados corretos.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 39624:
O ping através de uma subinterface pode falhar quando a interface principal estiver configurada com PPPoE.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 39753:
a desativação da VPN ramo a ramo dinâmica pode fazer com que os fluxos existentes que estão atualmente a ser enviados através da mesma fiquem parados.
Solução alternativa: basta desativar a VPN Ramo a Ramo Dinâmica numa janela de manutenção.
Problema 40421:
O Traceroute não está a apresentar o caminho quando passa através de um VMware SD-WAN Edge com uma interface configurada como uma porta comutada.
Problema 40096:
Se um VMware SD-WAN Edge 840 ativado for reiniciado, existirá possibilidade de um módulo SFP ligado ao Edge parar de passar o tráfego, mesmo que as luzes de ligação e o VMware SD-WAN Orchestrator indiquem a porta como “ATIVA” (UP).
Solução alternativa: desligue o módulo SFP e, em seguida, volte a ligá-lo na porta.
Problema 42278:
Para um tipo específico de configuração de par, o VMware SD-WAN Gateway pode enviar continuamente mensagens IKE init a um par Não-SD-WAN. Este problema não perturba o tráfego do utilizador para o Gateway; no entanto, os registos do Gateway serão preenchidos com erros IKE e isso poderá ocultar entradas de registo úteis.
Problema 42388:
Num VMware SD-WAN Edge 540, uma porta SFP não é detetada após desativar e, em seguida, reativar a interface no VMware SD-WAN Orchestrator.
Problema 42872:
Ativar o isolamento de perfil num perfil de Hub em que um Cluster de Hub está associado não revoga os caminhos do Hub na base de informações de encaminhamento (RIB).
Problema 43373:
Quando o mesmo caminho BGP é aprendido a partir de vários VMware SD-WAN Edges, se este caminho for movido da saída preferencial para a saída elegível no Controlo de fluxo de overlay, o Edge não será removido da lista de anúncios e continuará a ser anunciado.
Solução alternativa: ative o cálculo de custos distribuídos (DCC) no VMware SD-WAN Orchestrator.
Problema 44995:
Os caminhos OSPF não são revogados a partir do VMware SD-WAN Gateway e dos Spoke Edges do VMware SD-WAN quando os caminhos são retirados do Cluster de Hub.
Problema 45189:
Com o NAT do lado LAN de origem configurado, o tráfego de um Edge Spoke do VMware SD-WAN para o Edge Hub é permitido mesmo sem a configuração de caminho estático para a sub-rede NAT.
Problema 45302:
Num cluster do VMware SD-WAN Hub, se um Hub perder durante mais de 5 minutos a conetividade a todos os VMware SD-WAN Gateways comuns entre si e os seus Spoke Edges atribuídos, os Spokes poderão, em condições raras, ser incapazes de manter os caminhos do hub após 5 minutos. A questão resolve-se sozinha quando o Hub recupera o contacto com os Gateways.
Problema 46053:
A preferência do BGP não é corrigida automaticamente para caminhos de overlay quando o seu vizinho é alterado para um vizinho de vínculo superior.
Solução alternativa: um reinício do serviço Edge corrigirá este problema.
Problema 46137:
Um VMware SD-WAN Edge a executar o software 3.4.x não inicia um túnel com encriptação AES-GCM, mesmo que o Edge esteja configurado para GCM.
Solução alternativa: Se um cliente estiver a utilizar o AES-256, deverá desativar explicitamente o GCM do Orchestrator antes de atualizar os Edges para a versão 4.x. Uma vez que todos os Edges estão a executar a versão 4.x, o cliente pode escolher entre o AES-256-GCM e o AES-256-CBC.
Problema 46216:
Em Destinos Não-SD-WAN via Gateway ou Edge, em que o par é uma instância AWS, quando o par inicia a Fase-2 de recodificação, a Fase-1 do IKE também é eliminada e força uma recodificação. Isto significa que o túnel é desmontado e reconstruído, provocando a perda de pacotes durante a reconstrução do túnel.
Solução alternativa: para evitar a destruição do túnel, configure os Destinos Não-SD-WAN via Gateway/Edge ou o temporizador de recodificação IPsec CSS para menos de 60 minutos. Isto impede que o AWS inicie a recodificação.
Problema 46391:
Para um VMware SD-WAN Edge 3800, as interfaces SFP1 e SFP2 têm problemas com os SFPs multitaxa (isto é, 1/10G) e não devem ser utilizadas nessas portas.
Solução alternativa: Utilize SFPs de taxa única de acordo com o artigo BDC Lista de módulos SFP suportadospor VMware SD-WAN (79270). Os SFPs multitaxa podem ser utilizados com SFP3 e SFP4.
Problema 47664:
numa configuração de Hub e Spoke onde a VPN ramo a ramo através do Hub está desativada, tentar inverter o sentido do tráfego ramo a ramo com um caminho resumido num switch/router L3 provocará ciclos de routing.
Solução alternativa: configure a VPN de cloud para ativar a VPN ramo a ramo e selecione “Utilizar Hubs para VPN” (Use Hubs for VPN).
Problema 47681:
Quando um anfitrião no lado LAN de um VMware SD-WAN Edge utiliza o mesmo IP que a interface WAN do Edge, a ligação do anfitrião LAN para a WAN não funciona.
Problema 48530:
Os modelos do VMware SD-WAN Edge 6x0 não realizam a negociação automática para a velocidade tripla (10/100/1000 Mbps) dos SFPs de cobre.
Solução alternativa: o Edge 520/540 suporta SFPs de cobre de velocidade tripla, mas este modelo foi assinalado para Fim de Venda até ao 1.º trimestre de 2021.
Problema 48597: A vizinhança BGP multihop não ficará ativa se um dos dois caminhos para o par ficar inativo.
Se existir uma vizinhança BGP multihop com um par para o qual existem vários caminhos e um deles ficar inativo, o utilizador notará que a vizinhança BGP fica inativa e não será ativada com outros caminhos disponíveis. Isto inclui também o caso de vizinhança de retorno de IP local.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 50518:
Num VMware SD-WAN Gateway onde o PKI está configurado, se mais de 6000 túneis PKI tentarem ligar-se ao Gateway, os túneis poderão não surgir todos devido aos SAs de entrada não serem eliminados.
Os túneis que utilizam a autenticação de chave pré-partilhada (PSK) não têm este problema.
Problema 51436: num local que utilize uma topologia de Alta Disponibilidade melhorada ao implementar um VMware SD-WAN Edge com um modem LTE, se o local entrar num estado duplo (split-brain), a recuperação automática de HA demorará cerca de 5 a 6 minutos.
Como parte da recuperação de um estado duplo (split-brain), as portas LAN são inativadas no Edge ativo e isto tem impacto sobre o tráfego LAN durante o tempo em que as portas estão inativas e até que o local consiga recuperar.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 52955: A recusa DHCP não é enviada a partir do Edge e o reenlace do DHCP não é reiniciado após a falha do DAD no DHCP Dinâmico.
Se o servidor DHCPv6 atribuir um endereço que é detetado como duplicado pelo kernel durante uma verificação DAD, o cliente DHCPv6 não enviará nenhuma recusa. Isto levará a tráfego ignorado, uma vez que o endereço de interface será assinalado como verificação DAD falhada e não será utilizado. Esta ação não levará a nenhum ciclo de tráfego na rede, mas será observado um bloqueio de tráfego.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 53219: Após um reequilíbrio do cluster do VMware SD-WAN Hub, alguns Spoke Edges podem não ter a interface RPF/IIF com a definição correta.
Nos Spoke Edges afetados, o tráfego multicast será afetado. O que acontece é que depois de um reequilíbrio do cluster, alguns dos Spoke Edge não enviam uma junção PIM.
Solução alternativa: este problema persistirá até que o Edge Spoke afetado reinicie o Serviço Edge.
Problema 53359: A sessão BGP/BFD pode falhar durante alguns cenários de ataque DDoS.
Se ocorrer um flood de tráfego no cliente ligado à interface encaminhada para o cliente LAN, a sessão BGP/BFD poderá falhar. Adicionalmente, quando ocorre um flood de tráfego de alta prioridade em tempo real para o destino de camada superior, a sessão BGP/BFD pode falhar.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 53830: Num VMware SD-WAN Edge, alguns dos caminhos na vista BGP podem não ter os valores de preferência e anúncio corretos quando a flag DCC está configurada, provocando uma sequência de ordenação incorreta no FIB do Edge.
Quando o Cálculo de custos distribuídos (DCC) é configurado num cenário à escala com um grande número de caminhos num Edge, ao analisar o pacote de diagnóstico do Edge para o registo bgp_view alguns dos caminhos podem não ser corretamente atualizados com os valores de preferência e anúncio. Este problema, caso seja encontrado, pode potencialmente ser encontrado em alguns Edges que fazem parte de uma grande empresa (mais de 100 Spoke Edges ligados a Edges Hub ou Clusters de Hub).
Solução alternativa: Este problema pode ser corrigido reaprendendo os caminhos BGP de underlay ou executando a opção “Atualizar” (Refresh) na página OFC do VMware SD-WAN Orchestrator para os caminhos afetados. Tenha em atenção que ao realizar a “Atualização” (Refresh) de um caminho vai reaprender os caminhos de todos os Edges na empresa.
Problema 53934: numa empresa onde está configurado um cluster do VMware SD-WAN Hub, se o Hub principal tiver vizinhanças BGP multihop no lado LAN, o cliente poderá sofrer situações de tráfego ignorado num Spoke Edge quando existir uma falha do lado LAN ou quando o BGP não for configurado em todos os segmentos.
Num cluster de Hub, o Hub principal tem a vizinhança BGP multihop com um dispositivo de par para aprender caminhos. Se a interface física no Hub, através da qual a vizinhança do BGP é estabelecida, ficar inativa, os caminhos da BGP LAN não poderão ser zero, apesar da vista BGP estar vazia. Isto pode fazer com que o reequilíbrio do Cluster de Hub não ocorra. O problema também pode ser observado quando o BGP não está configurado para todos os segmentos e quando existem uma ou mais vizinhanças BGP multihop.
Solução alternativa: reinicie o Hub que teve a falha do lado da LAN (ou o BGP não ativado).
Problema 57210: mesmo quando um VMware SD-WAN Edge está a funcionar normalmente e é capaz de aceder à Internet, o LED na página Visão geral (Overview) da IU local é apresentado como “Vermelho” (Red).
A IU local do Edge determina a conetividade do Edge com base na capacidade do mesmo para resolver um nome conhecido através da resolução de DNS do Google (8.8.8.8). Se não o conseguir por qualquer motivo, pensa que está offline e apresenta o LED como vermelho.
Solução alternativa: não existe uma solução alternativa para este problema, exceto garantir que o tráfego DNS para 8.8.8.8 consegue alcançar o destino e ser resolvido com sucesso.
Problema 61543: se mais de uma regra NAT 1:1 for configurada em interfaces diferentes com o mesmo IP interno, o tráfego de entrada poderá ser recebido numa interface e os pacotes de saída do mesmo fluxo poderão ser encaminhados através de interfaces diferentes.
Para os fluxos NAT de Fora para Dentro, as regras NAT 1:1 serão correspondidas com o IP externo e a interface onde os pacotes são recebidos. Para os pacotes de saída do mesmo fluxo, o VMware SD-WAN Edge tentará fazer corresponder novamente as regras NAT comparando o IP interno e o tráfego de saída poderá ser encaminhado através da interface configurada na primeira regra de correspondência com “Tráfego de saída” (Outbound Traffic) configurado.
Solução alternativa: não existe uma solução alternativa para este problema, para além de garantir que não está configurada mais de uma regra NAT 1:1 com um endereço IP interno específico.
Problema 62701: para um VMware SD-WAN Edge implementado como parte de um cluster de Hub Edge, se a VPN de cloud não estiver ativada no segmento global, mas estiver ativada num segmento não global, uma atualização do plano de controlo enviada pelo Orchestrator pode fazer com que todas as ligações WAN fiquem instáveis no Hub Edge.
As ligações WAN do Edge Hub que fiquem inativas e, em seguida, ativas numa sucessão rápida (instabilidade) afetam o tráfego em tempo real, como chamadas de voz. Este problema foi observado numa implementação de clientes em que a VPN de cloud não estava ativada no segmento global do Hub Edge, mas a configuração do cluster estava ativada, o que significa que este Hub Edge fazia parte de um cluster (e a configuração de um cluster é aplicável a todos os segmentos). Quando uma alteração da configuração é emitida para o Hub Edge, o dataplane do Hub Edge inicia a análise dos dados e começa com o segmento global, onde verá que a VPN de cloud não está ativada, e o Hub Edge assume erradamente que o clustering foi desativado neste segmento global. Como resultado, o Edge Hub derruba todos os túneis das ligações WAN do Hub, o que provoca instabilidades de ligação em todas as ligações WAN desse Edge. Para qualquer incidente deste tipo, as ligações WAN só ficam inativas e recuperam uma vez por atualização do plano de controlo.
Solução alternativa: A solução alternativa é ativar a VPN de cloud em todos os segmentos, o que implica o segmento global e todos os segmentos não globais.
Problema 65560: o tráfego de um cliente para o dispositivo PE (Edge do Fornecedor) falha.
A vizinhança BGP entre um Gateway de parceiro e o Edge do Fornecedor não é estabelecida quando o tipo de etiqueta é selecionado como “nenhum” na configuração de handoff de informação. Isto porque os valores ctag e stag são escolhidos em /etc/config/gateway e não na configuração da handoff de informação no Orchestrator quando o tipo de etiqueta é “nenhum”.
Solução alternativa: atualize os valores ctag e stag para 0 cada em vrf_vlan->tag_info em /etc/config/gatewayd. Efetue um reinício vc_procmon.
Problema 67879: Um túnel do Serviço de Segurança na Cloud (CSS) é eliminado depois de um utilizador alterar uma definição de overlay WAN na deteção automática para definida pelo utilizador numa definição da interface WAN.
Depois de guardar as alterações, os túneis CSS não voltam a ficar ativos sem que o cliente desative os túneis e volte a ativá-los. A alteração da configuração WAN desativará o túnel CSS e analisará novamente a configuração do CSS. Todavia, em alguns casos, o nvs_config>num_gre_links é 0 e o túnel CSS não fica ativo.
Solução alternativa: desativar a configuração de CSS e, em seguida, reativá-la, ativará o túnel CSS.
Problema 68057: O pacote da versão DHCPv6 não é enviado do VMware SD-WAN Edge quando se altera o modo de endereço da interface WAN de DHCP com estado para endereço IPv6 estático e a concessão permanece ativa até atingir o tempo válido correspondente.
O cliente DHCPv6 tem uma concessão que não é libertada quando a configuração é alterada. A concessão permanece válida até a sua vida útil expirar no servidor DHCPv6 e ser eliminada.
Solução alternativa: não há forma de remediar este problema, uma vez que a concessão permanece ativa até ao fim da sua vida útil.
Problema 68851: se um VMware SD-WAN Edge e VMware SD-WAN Gateway tiverem o mesmo servidor TCP syslog configurado, a ligação TCP não será estabelecida do Edge para o servidor syslog.
Se o Edge e o Gateway tiverem cada um o mesmo servidor TCP e se os pacotes syslog do Edge forem encaminhados através do Gateway, o servidor syslog enviará uma redefinição do TCP para o Edge.
Solução alternativa: envie os pacotes syslog diretamente do Edge em vez de os encaminhar através de um Gateway ou configure um servidor syslog diferente para o Edge e o Gateway.
Problema 69284: num site que utilize uma topologia de alta disponibilidade na qual os Edges implementem VNFs numa configuração HA e estejam a utilizar a versão 4.x, se estes Edges HA forem mudados para a versão inferior 3.4.x, que não suporta VNFs HA, e, em seguida, atualizados para 4.5.0, quando os VNFs HA forem reativados, a VNF no Standby Edge não será ativada.
O estado VNF no Edge em standby é comunicado como inativo através do SNMP. Se o par VNF HA for mudado para uma versão anterior, de uma versão que suporte VNF-HA (versão 4.0+) para uma versão que não a suporte com a VNF configurada no Orchestrator. Este problema ocorre quando o Edge é atualizado para uma versão que suporta a VNF-HA e é configurado no Orchestrator novamente.
Solução alternativa: a VNF deverá primeiro ser desativada no caso de uma configuração HA se o Edge for mudado para uma versão anterior que não a suporta.
Problema 70311: um VMware SD-WAN Edge pode encontrar uma falha do Serviço dataplane e, como resultado, ser reiniciado.
Durante o reinício do serviço Edge, o tráfego do cliente seria interrompido durante ~15-30 segundos. Este problema ocorre de forma inconsistente, mas quando ocorre o Edge separa uma associação de segurança IKE (SA). Normalmente, isto ocorre apenas quando: o temporizador SA (conforme configurado no VMware SD-WAN Orchestrator) expira; ou o utilizador altera a configuração IPSec no Orchestrator.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 72358: se o endereço IP de um nome DNS do VMware SD-WAN Orchestrator for alterado, o processo do plano de gestão do VMware SD-WAN Gateway não o resolverá corretamente e o Gateway não poderá ligar ao Orchestrator.
O processo de gestão do Gateway verifica periodicamente a resolução de DNS do
nome DNS do Orchestrator, para ver se mudou recentemente, de forma a que o Gateway se possa ligar ao anfitrião correto. O código de resolução do DNS tem um problema, pelo que todas as verificações de resolução falham e o Gateway continua a utilizar um endereço antigo e, como tal, deixa de conseguir ligar-se ao Orchestrator.
Solução alternativa: até que este problema seja resolvido, um utilizador operador não deve alterar o endereço IP do Orchestrator. Se o endereço IP do Orchestrator tiver de ser alterado, todos os Gateways ligados a esse Orchestrator terão de ser reativados.
Problema 77541: Quando um modem USB que suporta o IPv6 é desligado e, em seguida, ligado novamente a uma interface USB do VMware SD-WAN Edge, pode não ser aprovisionado um endereço IPv6 na interface USB.
Isto afeta modems USB baseados em IP, versus geridos pela aplicação ModemManager. A maioria dos modems Inseego são baseados em IP e isso é importante porque o Inseego é o fabricante de modem que o VMware SASE recomenda. Os modems USB que suportam o IPv6 e utilizam o ModemManager versus baseados em IP serão bons num cenário de desligar e ligar novamente.
Solução alternativa: O Edge tem de ser reiniciado (ou desligado e ligado) depois de o modem USB ser ligado novamente na porta USB do Edge. Após o reinício, o Edge irá recuperar o endereço IPv6 para o modem.
Problema 81852: para um VMware SD-WAN Edge que está a utilizar um Serviço de Segurança na Cloud (CSS) do tipo Zscaler que utiliza túneis GRE e ativou a Verificação de estado de funcionamento de L7 (L7 Health Check), quando esse Edge é atualizado para a versão 5.0.0, em alguns casos, o cliente pode observar erros de verificação de estado de funcionamento de L7.
Isto é normalmente visto durante a atualização do software ou durante o tempo de arranque. Quando a Verificação de estado de funcionamento de L7 (L7 Health Check) verifica se existe um CSS com túneis GRE, podem ser observadas mensagens de erro getaddress relacionadas com o socket. O erro observado é visto de forma intermitente e não consistente. Por causa disso, as mensagens de sonda da Verificação de estado de funcionamento de L7 (L7 Health Check) não são enviadas.
Solução alternativa: Sem a correção, para remediar o problema, um utilizador tem de desligar e depois voltar a ligar a configuração da Verificação de estado de funcionamento de L7 (L7 Health Check) e esta funcionalidade funciona então como esperado.
Problema 82184: num VMware SD-WAN Edge a executar a versão 5.0.0 do Edge, quando um traceroute ou traceroute6 é executado para o endereço IPv4/IPv6 de br-network do Edge, o traceroute não vai terminar corretamente quando é utilizada uma sonda UDP.
O traceroute ou traceroute6 para o endereço IPv4/IPv6 de br-network do Edge não será corretamente utilizado quando for utilizado o modo predefinido (por outras palavras, a sonda UDP).
Solução alternativa: Utilize a opção -I em traceroute e traceroute6 para utilizar a pesquisa ICMP e depois o traceroute para o endereço IPv4/IPv6 de br-network funcionará como esperado.
Problema 83166: Quando um VMware SD-WAN Gateway é recentemente implementado com um tipo de instância AWS c5.4xlarge do Portal do AWS com a opção IPv6 selecionada, nem o IPv6 nem os caminhos predefinidos estão configurados.
Como resultado do IPv6 e dos caminhos predefinidos não configurados, os túneis de gestão do Gateway IPv6 do AWS não estão a formar-se e o Gateway não irá funcionar.
Solução alternativa: não existe uma solução para este problema, evite a implementação de um Gateway com as propriedades acima mencionadas.
Problema 92481: Se uma interface WAN num VMware SD-WAN Edge estiver desativada no VMware SASE Orchestrator, continuará a ser comunicada como “Ativa” (UP) pelo SNMP.
O processo de depuração principal para a saída das interfaces não inclui os detalhes da porta física para interfaces WAN do Edge (por exemplo, GE3 ou GE4 num modelo Edge 6x0 ou 3x00). Como resultado, quando o SNMP sonda essas interfaces, devolve sempre um resultado de UP, independentemente da configuração das interfaces.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 92676: numa implementação de cliente na qual um Destino Não VMware SD-WAN (NSD) via Gateway esteja configurado para utilizar túneis e Gateways redundantes e também esteja a utilizar BGP através de IPsec, caso os Gateways principais e secundários anunciem um prefixo com um caminho AS igual ao dos túneis NSD principais e secundários, o túnel NSD principal irá preferir um caminho do Gateway redundante em vez do Gateway principal.
O impacto de o túnel NSD principal via Gateway preferir o caminho do Gateway redundante em vez do Gateway principal só é sentido para o tráfego de retorno do NSD para o Gateway.
Solução alternativa: configure uma métrica mais alta (3 ou mais) no Gateway redundante para o prefixo interessado, pois tal ajudará o túnel principal do NSD a escolher o Gateway principal para o tráfego de retorno.
Problema 93141: num site implementado com uma topologia de alta disponibilidade, um cliente que utiliza um interruptor L2 a montante do par Edge HA pode observar evidências de um ciclo de tráfego L2 nos registos do interruptor, embora não exista realmente um ciclo.
O problema é provocado pelo Edge HA enviar o heartbeat da interface HA com o endereço MAC virtual para o Orchestrator em vez do endereço MAC real da interface, o que é causado pelo Edge HA armazenar o endereço MAC virtual no ficheiro MAC. Como resultado, o interruptor L2 ligado deteta tráfego do mesmo MAC de origem proveniente de duas interfaces Edge diferentes e regista-o como um ciclo L2. Este problema é cosmético ao nível do registo, dado que não existe realmente um ciclo L2 e não existe nenhuma interrupção do tráfego do cliente nem perda de contacto com o Orchestrator decorrente do mesmo.
Solução alternativa: o cliente pode ignorar os eventos de deteção de ciclo L2 dos interruptores a montante provenientes da interface de HA do Edge (normalmente GE1).
Problema 95399: Quando uma ligação Ethernet é fisicamente desligada ou ligada a uma interface VMware SD-WAN Edge, o VMware SASE Orchestrator não recebe uma notificação deste evento do Edge e não o mostra em Eventos de cliente.
Os clientes confiam no Orchestrator para reportar estes eventos na página Eventos e quando estes não são registados, isso torna a monitorização dos seus vários sites menos fiável.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 95565: 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.
Solução alternativa: num par Edge HA que regista este problema e não tem a correção, a solução alternativa é desativar o SNMP, uma vez que se trata de um problema de temporização e isto reduz o risco.
Problema 97321: Quando a Análise do Edge Network Intelligence é ativada num VMware SD-WAN Edge, o Edge pode acionar um reinício do Serviço do Edge, o que provoca uma interrupção de 10-15 segundos do tráfego do cliente.
Quando a Análise estiver ativada no Edge, o Edge pode experienciar uma condição de falta de memória seguido de um estado de memória “dupla memória livre”. O Edge reinicia o serviço para restaurar a memória.
Os sintomas para este problema podem ocorrer várias vezes enquanto a Análise está ativada.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 98136: Para as empresas de clientes que usam uma topologia Hub/Spoke onde a VPN Ramo a Ramo Dinâmica está configurada, os utilizadores cliente atrás de um SD-WAN Edge Spoke podem observar que algum tráfego tem latência inesperada, resultante do tráfego utilizar um caminho que não o ideal.
O tráfego do Edge Spoke que regista este problema utiliza um caminho que era inicialmente um caminho de não transmissão para um Hub Edge não incluído no perfil que o Edge Spoke estava a utilizar. Um túnel de VPN Ramo a Ramo Dinâmica pode ser formado do Edge Spoke para o Edge Hub devido ao tráfego ser enviado em direção a outro prefixo não relacionado e, nesta instância, um caminho não de transmissão é instalado no Edge Spoke.
Em resultado deste caminho não-transmissão, todo o tráfego para este prefixo começa a passar pelo
O Hub Edge e o caminho não-transmissão torna-se num caminho de transmissão (alteração para comunidade de transmissão), mas o caminho não-transmissão instalado previamente não é revogado e o tráfego assume o caminho de Hub Edge enquanto o túnel de VPN ramo a ramo Dinâmica permanecer ativa.
Solução alternativa: aguarde que o túnel da VPN Ramo a Ramo Dinâmica fique inativo, após isso, o caminho de transmissão não será instalado no Edge Spoke quando um novo túnel da VPN Ramo a Ramo Dinâmica é formado em direção ao Edge Hub.
Problema 19566:
Após a recuperação automática da alta disponibilidade, o número de série do VMware SD-WAN Edge em espera pode ser apresentado como o número de série ativo no Orchestrator.
Problema 21342:
Ao atribuir Gateways de parceiro por segmento, a lista correta de Atribuições de Gateway pode não aparecer na opção “Ver” (View) Gateways do Operador na lista de monitorização do VMware SD-WAN Edge.
Problema 24269:
Monitorizar > Transportar > Perda não representada em gráficos (Monitor > Transport > Loss not graphing) – foi observada uma perda da ligação WAN enquanto os gráficos QoE refletiram esta perda.
Problema 25932:
O VMware SD-WAN Orchestrator permite que os VMware SD-WAN Gateways sejam removidos do Conjunto de Gateways mesmo quando estão a ser utilizados.
Problema 32335:
A página “Acordo de Serviços do Utilizador Final” (EUSA) (End User Service Agreement (EUSA)) apresenta um erro quando um utilizador está a tentar aceitar o acordo.
Solução alternativa: certifique-se de que não existem espaços iniciais ou finais no nome da empresa.
Problema 32435:
É permitida uma sobreposição de VMware SD-WAN Edge para uma configuração NAT baseada em políticas para cadeias de identificação que já estão configuradas ao nível do perfil e vice-versa.
Problema 32856:
Embora a política empresarial esteja configurada para utilizar um cluster de Hub para realizar o backhaul do tráfego de Internet, o utilizador pode desmarcar o cluster de Hub de um perfil num VMware SD-WAN Orchestrator que foi atualizado da versão 3.2.1 para a versão 3.3.x.
Problema 35658:
Quando um VMware SD-WAN Edge é movido de um perfil para outro que tem uma definição CSS diferente (por exemplo, IPsec no perfil1 para GRE no perfil2), as definições CSS ao nível do Edge continuarão a utilizar as definições CSS anteriores (por exemplo, IPsec em comparação com GRE).
Solução alternativa: ao nível do Edge, desative a GRE e, em seguida, ative-a novamente para resolver o problema.
Problema 35667:
Quando um VMware SD-WAN Edge é movido de um perfil para outro perfil que tem a mesma definição de CSS, mas um nome GRE CSS diferente (os mesmos pontos finais), alguns túneis GRE não vão aparecer na monitorização.
Solução alternativa: ao nível do Edge, desative a GRE e, em seguida, ative-a novamente para resolver o problema.
Problema 36665:
Se o VMware SD-WAN Orchestrator não conseguir ligar-se à Internet, as páginas de interface do utilizador que requerem acesso à API do Google Maps poderão não conseguir carregar completamente.
Problema 32913:
Após ativar a alta disponibilidade, os detalhes de multicast do VMware SD-WAN Edge não são apresentados na página de monitorização. Uma recuperação automática resolve o problema.
Problema 33026:
A página “Acordo de Serviços do Utilizador Final” (End User Service Agreement [EUSA]) não é atualizada corretamente após eliminar o acordo.
Problema 38056:
O ficheiro export.csv de licenciamento de Edge não mostra os dados da região.
Problema 38843:
Ao fazer push a um mapa de aplicação, não existe nenhum Evento do operador e o Evento do Edge é de utilidade limitada.
Problema 39633:
A hiperligação Supergateway (Super Gateway) não funciona após um utilizador atribuir o Gateway alternativo (Alternate Gateway) como o Supergateway (Super Gateway).
Problema 39790:
O VMware SD-WAN Orchestrator permite a um utilizador configurar uma interface encaminhada do VMware SD-WAN Edge para que tenha mais do que as 32 subinterfaces suportadas, criando o risco de um utilizador configurar 33 ou mais subinterfaces numa interface, o que pode provocar uma falha do Serviço dataplane Edge.
Problema 41691:
O utilizador não pode alterar o campo “Número de endereços” (Number of addresses), embora o conjunto DHCP não esteja esgotado na página Configurar > Edge > Dispositivo (Configure > Edge > Device).
Problema 43276:
O utilizador não consegue alterar o tipo de segmento quando um VMware SD-WAN Edge ou Perfil tem um Gateway de parceiro configurado.
Solução alternativa: remova temporariamente a configuração do Gateway de parceiro no Perfil ou no Edge para que o segmento possa ser alterado entre privado e normal. Em alternativa, o utilizador pode remover o segmento do perfil e fazer a alteração a partir daí.
Problema 47713:
se uma regra de política empresarial for configurada enquanto a VPN de cloud estiver desativada, a configuração NAT deverá ser reconfigurada ao ativar a VPN de cloud.
Problema 47820:
Se uma VLAN estiver configurada com o DHCP desativado ao nível do perfil, enquanto também tem uma Anulação de Edge para esta VLAN nesse Edge com o DHCP ativado e existe uma entrada para o campo de servidor DNS definido como nenhum (nenhum IP configurado), o utilizador não poderá fazer qualquer alteração na página Configurar > Edge > Dispositivo (Configure > Edge > Device) e receberá uma mensagem de erro de “endereço IP inválido []” (invalid IP address []) que não explica nem indica o verdadeiro problema.
Problema 48085: O VMware SD-WAN Orchestrator permite que um utilizador elimine uma VLAN que esteja associada a uma interface.
Ao encontrar este problema, o utilizador deveria ver uma mensagem de erro semelhante a “ID de VLAN [xx] não pode ser removida, em utilização pelo Edge [b1-edge1 (GEx-desativado)]” (VLAN ID [xx] cannot be removed, in use by edge [b1-edge1 (GEx-disabled]).
Problema 51722: No VMware SASE Orchestrator, o seletor do intervalo de tempo não é superior a duas semanas para qualquer estatística nos separadores Monitorizar > Edge (Monitor > Edge).
O seletor de intervalo de tempo não apresenta opções superiores a “Últimas 2 semanas” (Past 2 Weeks) nos separadores Monitorizar > Edge (Monitor > Edge), mesmo que o período de retenção para um conjunto de estatísticas seja largamente superior a 2 semanas. Por exemplo, as estatísticas de fluxo e ligação são mantidas durante 365 dias por predefinição (isto é configurável), enquanto as estatísticas de caminho são mantidas apenas durante 2 semanas por predefinição (também configurável). Este problema está a fazer com que todos os separadores de monitorização estejam em conformidade com o tipo de estatística retida mais baixa versus permitir que um utilizador selecione um período de tempo consistente com o período de retenção para essa estatística.
Solução alternativa: um utilizador pode utilizar a opção “Personalizado” (Custom) no seletor de intervalo de tempo para ver dados durante mais de 2 semanas.
Problema 60522: Na IU do VMware SD-WAN Orchestrator, o utilizador observa um grande número de mensagens de erro quando tenta remover um segmento.
O problema pode ser observado ao adicionar um segmento a um perfil e associar o segmento a vários VMware SD-WAN Edges. Quando o utilizador tenta remover o segmento adicionado a partir do perfil, vê um grande número de mensagens de erro.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 82680: Para o cliente a utilizar a Automação de Túnel MT-GRE, quando um utilizador desliga a flag Interligação cloud a cloud (CCI) num VMware SD-WAN Gateway que está configurado para utilizar o CCI, as entradas Zscaler MT-GRE podem não ser eliminadas do portal Zscaler de forma consistente.
Depois de um site CCI ter sido eliminado do Gateway, as entradas para este site também devem ser removidas. Este problema só foi visto durante a automação de teste e não foi reproduzido manualmente, mas continua a ser um risco.
Solução alternativa: Elimine manualmente o recurso do Zscaler antes de voltar a tentar.
Problema 82681: Para o cliente utilizar a automação do túnel MT-GRE, quando um utilizador desliga a flag Interligação cloud a cloud (CCI) num VMware SD-WAN Gateway que está configurado para utilizar o CCI, e o utilizador desativa a flag CCI de um VMware SD-WAN Edge com CCI configurado que está a utilizar um Serviço de Segurança na Cloud Zscaler, as entradas Zscaler MT-GRE podem não ser eliminadas do Edge ou do portal Zscaler.
Depois de um site CCI ter sido eliminado do Gateway, as entradas para este site também devem ser removidas. Este problema só foi visto durante a automação de teste e não foi reproduzido manualmente, mas continua a ser um risco.
Solução alternativa: Elimine manualmente o recurso do Zscaler antes de voltar a tentar.
Problema 103769: Um operador pode verificar que um VMware SASE Orchestrator numa implementação de grande escala está a ter problemas de desempenho, como uma utilização do disco de 100% e o facto de o Orchestrator já não acumular registos.
Este problema provoca uma alteração no comportamento de registo do Orchestrator 5.1.0 que pode ter como resultado o facto de as pastas que guardam os registos ficarem cheias, levando a CPU do Orchestrator a atingir uma utilização de 100%.
Solução alternativa: um superutilizador operador tem de iniciar sessão no Orchestrator e limpar os registos pendentes.
