| VMware SASE 5.0.1 | Atualizado a 17 de fevereiro de 2023 |
Verifique se existem adições e atualizações a estas notas de versão. |
| VMware SASE 5.0.1 | Atualizado a 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 disponibilizadas pela primeira vez na versão 5.0.0, bem como para os clientes afetados pelos problemas indicados abaixo que foram resolvidos desde a versão 5.0.0.
A versão 5.0.1 dos Orchestrators, Gateways e Edges Hub suporta todas as versões anteriores do VMware SD-WAN Edge iguais ou superiores à versão 3.2.2.
A versão 5.0.1 é classificada como versão de manutenção, e as versões de manutenção estão sujeitas a um subconjunto de testes de interoperabilidade porque o protocolo é idêntico à versão principal/secundária de que fazem parte. Consulte as Notas de versão do VMware SASE 5.0.0 para obter uma lista das outras versões de software relativamente às quais esta versão do protocolo foi testada.
Foram explicitamente testadas as seguintes combinações de interoperabilidade do SD-WAN:
| Orchestrator |
Gateway |
Edge |
|
| Hub |
Ramo/Spoke |
||
| 5.0.1 |
5.0.1 |
4.3.1 |
4.3.1 |
| 5.0.1 |
5.0.1 |
4.5.0 |
4.5.0 |
| 5.0.1 |
5.0.1 |
5.0.0 |
5.0.0 |
| 5.0.1 |
4.3.1 |
4.3.1 |
4.3.1 |
| 5.0.1 |
4.5.0 |
4.5.0 |
4.5.0 |
| 5.0.1 |
5.0.0 |
5.0.0 |
5.0.0 |
| 5.0.0 |
5.0.1 |
5.0.1 |
5.0.1 |
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 da VMware SD-WAN 3.2.x e 3.3.x para todos os componentes e 3.4.x para o Orchestrator e 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. 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.
Seguem-se os caminhos para os clientes que pretendem atualizar o Orchestrator, o Gateway ou o Edge de uma versão mais antiga para a versão 5.0.1.
Orchestrator
Devido às alterações à infraestrutura no Orchestrator a partir da versão 4.0.0, qualquer Orchestrator que utilize uma versão 3.x deve ser atualizado primeiro para a versão 4.0.0 e, depois, para a versão 5.0.1. Os Orchestrators que utilizam a versão 4.0.0 ou posterior podem ser atualizados para a versão 5.0.1. Assim, os caminhos de atualização do Orchestrator são os que se seguem:
Orchestrator com a versão 3.x → 4.0.0 → 5.0.1.
Orchestrator com a versão 4.x → 5.0.1.
Gateway
As atualizações do Gateway da versão 3.x para a versão 5.0.1 não são suportadas. Em vez de ser atualizado, um Gateway com a versão 3.x deve ser novamente implementado com os mesmos atributos de VM, sendo, em seguida, preterida a instância antiga.
A atualização de um Gateway com a versão 4.0.0 ou posterior é completamente suportada para todos os tipos de Gateway.
Nota: ao implementar um novo Gateway com a versão 5.0.1, a instância ESXi do VMware tem de ser, pelo menos, da versão 6.7, Atualização 3, até à versão 7.0. A utilização de uma instância ESXi anterior irá resultar na falha do Serviço dataplane do Gateway ao tentar executar a versão 5.0.0 ou posterior.
Nota: antes de atualizar um Gateway para a versão 5.0.1, a instância ESXi tem de ser atualizada para, pelo menos, a versão 6.7, Atualização 3, até à versão 7.0. A utilização de uma instância ESXi anterior irá resultar na falha do Serviço dataplane do Gateway ao tentar executar a versão 5.0.1 ou posterior.
Edge
Um Edge pode ser atualizado diretamente para a versão 5.0.1 a partir de qualquer versão 3.x ou posterior.
Misturar Edges capazes de Wi-Fi e não capazes de Wi-Fi em alta disponibilidade não é suportado
A partir de 2021, o VMware SD-WAN introduziu modelos Edge que não incluem um módulo de Wi-Fi: os modelos Edge 510N, 610N, 620N, 640N e 680N. Embora estes modelos pareçam idênticos aos seus congéneres com Wi-Fi, com exceção do Wi-Fi, a implementação de um Edge com capacidade de Wi-Fi e um Edge sem capacidade de Wi-Fi do mesmo modelo (por exemplo, um Edge 640 e um Edge 640N) como um par de alta disponibilidade não é suportada. Os clientes devem verificar se os Edges implementados como um par de alta disponibilidade são do mesmo tipo: ambos com capacidade de Wi-Fi, ou ambos sem capacidade de Wi-Fi.
A Grafana já não está disponível no Orchestrator
A versão 5.0.0 e as versões posteriores dos Orchestrators não incluem a aplicação Grafana devido a restrições de licença. A Grafana é utilizada principalmente por clientes e parceiros que executam o Orchestrator no local para monitorizar o desempenho do Orchestrator. A partir de agora, para estas necessidades, um cliente ou parceiro teria de alojar a sua própria aplicação Grafana fora do Orchestrator e configurar o Telegraf no Orchestrator para apontar para ela.
As compilações do VMware SASE incluem um quarto dígito
Começando com a versão 5.0.0 e a partir de agora, a compilação da versão passará a incluir um quarto dígito.
Para versões de software, o VMware SASE segue um esquema de numeração a.b.c, em que:
a = Principal (por exemplo, 5.0.0) → Uma versão com várias grandes funcionalidades e alterações arquitetónicas potencialmente significativas.
b = Menor (por exemplo, 5.2.0) → Uma versão com várias pequenas funcionalidades ou algumas grandes funcionalidades e sem alterações arquitetónicas significativas
c = Manutenção (por exemplo, 5.2.1) → Uma versão com um número potencialmente grande de correções para problemas encontrados em campo e correções de problemas encontrados internamente sem funcionalidades, exceto o potencialmente novo suporte da plataforma de hardware.
Com a versão 5.0.0, é adicionado um quarto dígito às compilações do Edge, Gateway e Orchestrator, pelo que a numeração passa a ser a.b.c.d, em que
d = Compilação rollup (por exemplo, 5.2.1.1) → Um rollup é um agregado cumulativo de correções de defeitos conhecidos encontrados pelos clientes ou defeitos críticos encontrados internamente.
As compilações Rollup para 4.x e anteriores distinguem-se pela data de GA do nome de imagem, o que não é uma forma ideal de comunicar a versão da compilação a um cliente. Adicionar um quarto dígito às compilações 5.0.0 e posteriores permite que os clientes vejam mais claramente que versão de software está a ser utilizada num determinado componente.
Esta convenção de numeração da compilação aplica-se apenas à versão 5.0.0 e às versões posteriores. As versões 4.x e anteriores continuarão a utilizar três dígitos, sendo que as compilações rollup serão identificadas da forma existente por data.
Aceder ao Cloud Web Security e ao Secure Access
Os clientes que pretendam aceder ao VMware Cloud Web Security ou ao VMware Secure Access devem atualizar os Edges para a versão 4.5.0 ou posterior. Estes serviços estão inacessíveis em Edges que utilizam uma versão anterior à 4.5.0.
Alteração ao delimitador da configuração de filtro BGPv4 para o AS-PATH precedente
Até à versão 3.x, a configuração de filtro BGPv4 para o AS-PATH precedente do VMware SD-WAN suportava delimitadores baseados em vírgula e espaço. No entanto, a partir da Versão 4.0.0 e posterior, o VMware SD-WAN apenas suporta um delimitador baseado em espaços numa configuração AS-PATH precedente. Os clientes que atualizam de 3.x para 4.x ou 5.x devem editar as suas configurações AS-PATH precedentes para “substituir vírgulas por espaços” (replace commas with spaces) antes de fazerem a atualização para evitar uma seleção incorreta do melhor caminho do BGP.
Tempo de atualização alargado para os modelos Edge 3x00
As atualizações para esta versão podem demorar mais do que o normal (3 a 5 minutos) nos modelos Edge 3x00 (ou seja, 3400, 3800 e 3810). Isto deve-se a uma atualização de firmware que resolve o problema 53676. Se um Edge 3400 ou 3800 tivesse atualizado previamente o seu firmware na versão 3.4.5/3.4.6, 4.0.2, 4.2.1, 4.3.0, 4.5.0 ou 5.0.0, o Edge seria atualizado conforme esperado. Para obter mais informações, consulte Problema 53676 resolvido nas respetivas notas de versão.
Limitação do BGP através de IPsec no Edge e no Gateway e automatização da WAN Virtual do Azure
A funcionalidade do BGP através de IPsec no Edge e no Gateway não é compatível com a automatização da WAN Virtual do Azure no Edge ou no Gateway. Apenas os caminhos estáticos são suportados ao automatizar a conetividade de um Edge ou Gateway para uma vWAN do Azure.
Limitação ao desativar a negociação automática nos modelos VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 e 3810
Quando um utilizador desativa a negociação automática para codificar a velocidade e o duplex nas portas GE1–GE4 num modelo VMware SD-WAN Edge 620, 640 ou 680; nas portas GE3 ou GE4 num Edge 3400, 3800 ou 3810; ou num Edge 520/540 quando um SFP com interface de cobre é utilizado nas portas SFP1 ou SFP2, pode descobrir que, mesmo após um reinício, a ligação não aparece.
Tal deve-se ao facto de cada um dos modelos Edge indicados utilizar o Intel Ethernet Controller i350, que tem a seguinte limitação: quando a negociação automática não é utilizada em ambos os lados da ligação, não consegue detetar dinamicamente os fios adequados para transmitir e receber (MDIX automático). Se ambos os lados da ligação estiverem a transmitir e a receber nos mesmos fios, a ligação não será detetada. Se o lado do par também não suportar o MDIX automático sem a negociação automática e a ligação não aparecer com um cabo reto, será necessário um cabo Ethernet cruzado para estabelecer a ligação.
Para obter mais informações, consulte o artigo da BDC Limitação ao desativar a negociação automática nos modelos VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 e 3810 (87208).
5 de agosto de 2022. Primeira edição.
11 de agosto de 2022. Segunda edição.
Foram adicionados os problemas corrigidos 89346, 90067, 90128, 90540, 91054, 91720 e 92082 à secção Problemas resolvidos do Orchestrator. Estes pedidos foram omitidos por engano da Primeira edição das Notas de lançamento da versão 5.0.1.
15 de agosto de 2022. Terceira edição.
Foi adicionado o Problema resolvido 89217 à secção Problemas resolvidos do Edge/Gateway. Este pedido foi omitido por engano da Primeira edição das Notas de lançamento da versão 5.0.1.
18 de agosto de 2022. Quarta edição.
Foi adicionada uma compilação R5010-20220817-GA atualizada do Orchestrator à secção Problemas resolvidos do Orchestrator. A compilação R5010-20220817-GA substitui a compilação original R5010-20220803-GA do Orchestrator e é a nova compilação GA do Orchestrator para a versão 5.0.1.
Esta compilação atualizada do Orchestrator inclui a correção para o problema 95613, que é adicionada à secção Problemas resolvidos do Orchestrator.
9 de setembro de 2022. Quinta edição.
Foram adicionados os Problemas resolvidos 87552, 90151 e 93383 à secção Problemas resolvidos do Edge/Gateway. Estes pedidos foram omitidos por engano da Primeira edição das Notas de lançamento da versão 5.0.1.
O Problema pendente 49712 foi removido dos Problemas conhecidos do Edge/Gateway, uma vez que a Engenharia concluiu que foi provocado por um erro de configuração e não por um defeito no código.
O Problema pendente 90065 foi removido dos Problemas conhecidos do Edge/Gateway, uma vez que a Engenharia não conseguiu replicar o problema e a sincronização DR funciona conforme esperado com a compilação 5.0.1 do Orchestrator.
16 de setembro de 2022. Sexta edição.
Foi adicionada uma compilação R5010-20220912-GA atualizada do Orchestrator à secção Problemas resolvidos do Orchestrator. A compilação R5010-20220912-GA substitui a compilação original R5010-20220817-GA do Orchestrator e é a nova compilação GA do Orchestrator para a versão 5.0.1.
Esta compilação atualizada do Orchestrator inclui a correção para o problema 90749, 95847 e 96095, que é adicionada à secção Problemas resolvidos do Orchestrator.
Foi adicionado o Problema resolvido 91875 à secção Problemas resolvidos do Edge/Gateway. Estes pedidos foram omitidos por engano da Primeira edição das Notas de lançamento da versão 5.0.1.
Foram adicionados os problemas 96055 e 96231 à secção Problemas conhecidos do Edge/Gateway.
23 de setembro de 2022. Sétima edição.
Foi adicionado o problema resolvido 96108 à compilação R5010-20220912-GA do Orchestrator na secção Problemas resolvidos do Orchestrator, este problema foi omitido por erro a partir da sexta edição destas notas de versão.
O problema resolvido 90749 foi movido da compilação R5010-20220912-GA do Orchestrator para a compilação original R5010-20220803-GA do Orchestrator na secção de Problemas resolvidos do Orchestrator, dado que foi aqui que a correção do problema foi realmente adicionada na versão 5.0.1.
Foi adicionado o Problema resolvido 87982 à secção Problemas resolvidos do Edge/Gateway. Este pedido foi omitido por engano da Primeira edição das Notas de lançamento da versão 5.0.1.
Foram adicionados os Problemas pendentes 86098, 94204, 95565, 96441 e 96888 à secção de Problemas conhecidos do Edge/Gateway.
28 de setembro de 2022. Oitava edição.
Foi adicionado 98136 à secção Problemas conhecidos do Edge/Gateway.
12 de outubro de 2022. Nona edição.
Foi adicionada uma nova compilação rollup R5011-20221007-GA do Edge/Gateway à secção Problemas resolvidos do Edge/Gateway. Esta é a primeira compilação rollup do Edge/Gateway e é a nova compilação GA do Edge/Gateway para a versão 5.0.1.
A compilação R5011-20221007-GA do Edge/Gateway inclui as correções para os problemas 89235, 94430, 95503, 96055, 96231, 98157 e 99188 que são documentadas nesta secção.
18 de outubro de 2022. Décima edição.
Foi adicionado o Problema resolvido 90876 à secção Problemas resolvidos do Edge/Gateway para a versão 5.0.1 GA da compilação original R5010-20220729-GA. Este problema foi omitido por engano da Primeira edição das Notas de lançamento da versão 5.0.1.
31 de outubro de 2022. Décima primeira edição.
Foi adicionado o Problema resolvido 72491 à secção Problemas resolvidos do Edge/Gateway para a versão 5.0.1 GA da compilação original R5010-20220729-GA. Este problema foi omitido por engano da Primeira edição das Notas de lançamento da versão 5.0.1.
14 de novembro de 2022. Décima segunda edição.
Foi adicionada uma nova compilação rollup R5012-20221107-GA do Edge à secção Problemas resolvidos do Edge/Gateway. Esta é a segunda compilação rollup do Edge e é a nova compilação GA do Edge para a versão 5.0.1. e é recomendada para todos os clientes que executam a versão 5.0.x.x do Edge.
A compilação R5012-20221107-GA do Edge inclui as correções para os problemas 96411, 96441, 96888, 97483, 98514, 100377 e 101049 que são documentadas nesta secção.
Aqueles que utilizam as compilações anteriores do Edge 5.0.x.x, devem atualizar os Edges para 5.0.1.2.
22 de novembro de 2022. Décima terceira edição.
Foi adicionada uma nova compilação rollup R5011-20221117-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a primeira compilação rollup do Orchestrator e é a nova compilação GA do Orchestrator para a versão 5.0.1.
A compilação do Orchestrator R5011-20221117-GA inclui as correções para os problemas 80735, 88957, 97713, 98086, 98357, 98518, 98654, 99109, 99247, 99250, 100656 e 101449, todos eles documentados nesta secção.
Foi adicionado o Problema resolvido 89873 à secção Problemas resolvidos do Edge/Gateway. Este problema foi omitido por engano da Primeira edição das Notas de lançamento da versão 5.0.1.
Foi adicionado o Problema pendente 97559 aos Problemas conhecidos do Edge/Gateway.
30 de novembro de 2022. Décima quarta edição.
Foi substituída a compilação rollup do Orchestrator R5011-20221117-GA pela compilação revista R5011-20221129-GA que corrige um problema de atualização detetado pela equipa de Operações de VMware ao atualizar um Orchestrator para a compilação R5011-20221117-GA. O problema de atualização foi provocado por uma incompatibilidade de versão no pacote de atualização Manifest, e esta nova compilação não adiciona qualquer funcionalidade nova.
16 de dezembro de 2022. Décima quinta edição.
Foi adicionada uma nova compilação rollup R5012-20221214-GA do Gateway às secções Problemas resolvidos do Edge/Gateway. Esta é a segunda compilação rollup do Gateway e é a nova compilação GA do Gateway para a versão 5.0.1.
A compilação R5012-20221214-GA do Gateway inclui as correções para os problemas 96863, 97272 e 99650, sendo que cada uma delas está documentada nesta secção.
Devido a um problema de compilação com a compilação de Gateway 5.0.1.1 original (R5011-20221007-GA), não é possível efetuar a atualização dos Gateways para qualquer compilação de Gateway além da 5.0.1.1 e a atualização tem de ser efetuada diretamente da 5.0.1.1 para a 5.0.1.2.
Foi adicionada uma nova compilação rollup R5012-20221214-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a segunda compilação rollup do Orchestrator e é a nova compilação GA do Orchestrator para a versão 5.0.1.
A compilação R5012-20221214-GA do Orchestrator inclui as correções para os problemas 96538, 100133, 101835 e 102806, sendo que cada uma delas está documentada nesta secção.
30 de janeiro de 2023. Décima sexta edição.
O pedido 89217 corrigido foi revisto para refletir uma versão (R5012-20230123-GA-103475) revista do Edge e a versão (R131-20221216-GA) do firmware da plataforma necessárias para resolver o problema. O pedido também adiciona uma ligação para o artigo da BDC que aborda o problema 89217 e inclui instruções passo a passo para atualizar um Edge 6x0.
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.
17 de fevereiro de 2023. Décima sétima edição.
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 R5012-20221214-GA do Gateway foi lançada em 14-12-2022 e é o segundo rollup do Gateway para a versão 5.0.1.
Esta compilação rollup do Gateway aborda os problemas críticos abaixo desde a compilação R5011-20221007-GA do Gateway.
Devido a um problema de compilação com a compilação de Gateway 5.0.1.1 original (R5011-20221007-GA), não é possível efetuar a atualização dos Gateways para qualquer compilação de Gateway além da 5.0.1.1 e a atualização tem de ser efetuada diretamente da 5.0.1.1 para a 5.0.1.2.
Problema 96863 resolvido: Um VMware SD-WAN Edge em que as ligações WAN preferem IPv6 pode sofrer uma falha do Serviço dataplane, o que pode provocar uma breve perturbação do tráfego do cliente.
O problema pode ocorrer num Edge ou num VMware SD-WAN Gateway quando o IPv6 é ativado, resultando numa falha de serviço que exige uma reinicialização de recuperação.
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 99650 resolvido: Num site de cliente em que um Destino Não-SD-WAN seja configurado com IKEv1, pode não ser formado o túnel entre um VMware SD-WAN Edge e o par NSD e o tráfego do cliente não chega ao site do par.
Durante uma classificação inicial de pacote, os pacotes ESP fragmentados no túnel NSD são incorretamente classificados como pacotes de utilizador comuns e, em seguida, enviados para uma fila não monitorizada. Isto faz com que os pacotes se acumulem nessa fila e nunca sejam processados e libertados.
A compilação R5012-20221107-GA do Edge foi lançada em 14-11-2022 e é o 2.º rollup do Edge para a versão 5.0.1.
Esta compilação rollup do Edge aborda os problemas críticos abaixo desde o 1.º rollup do Edge, versão R5011-20221007-GA.
Aqueles que utilizam as compilações anteriores do Edge 5.0.x.x, devem atualizar os Edges para 5.0.1.2. As compilações anteriores do Edge 5.0.x.x foram marcadas como depreciadas nos Orchestrators alojados em VMware SASE.
Para obter mais informações, consulte o artigo da Base de conhecimentos https://kb.vmware.com/s/article/90042.
Problema 96411 resolvido: Um VMware SD-WAN Edge pode encontrar uma falha do serviço dataplane e, em resultado de tal, reiniciar, o que resulta numa interrupção de 10 a 15 segundos do tráfego do cliente.
O problema pode ocorrer num Edge onde existe instabilidade da ligação (onde uma ligação WAN fica inativa e é reativada em rápida sucessão). O problema é provocado por uma corrupção da memória, que resulta num estado de dupla memória livre e numa falha do serviço do Edge.
Problema 96441 resolvido: Num site que utilize uma topologia de alta disponibilidade, o cliente pode observar recuperações automáticas de HA frequentes.
O problema é acionado pela interface de HA ser marcada pelo Edge como inativa e, em seguida, regressar em 500 a 1000 ms, o que pode acionar um recuperação automática da HA. No entanto, estes eventos de interface inativa são falsos e provocados por uma interface ativada por DPDK com consultas em intervalos de 500 ms para determinar o estado da interface. Utilizando este método, o controlador do dispositivo subjacente pode, por vezes, comunicar falsamente um evento de interface inativa e cada evento faz com que o Edge marque a interface como inativa até que a próxima consulta do estado da interface (em 500 ms) comunicar que a interface está ativa.
Problema 96888 resolvido: Em certas condições de carga, os protocolos de routing para o BGP ou OSPF podem reiniciar aleatoriamente, levando a uma nova convergência do caminho e à interrupção do tráfego.
Em condições de carga mais elevadas, os processos de protocolo de routing do BGP e do OSPF são forçados a esperar mais tempo do que o esperado pela CPU do Edge para serem agendados, o que leva a um atraso e ao reinício do protocolo de routing. O atraso no protocolo de routing é provocado por uma alocação insuficiente de largura de banda na CPU e pode ocorrer em qualquer modelo Edge.
Problema 97483 resolvido: Para um site que utiliza um VMware SD-WAN Virtual Edge com 2 núcleos de CPU, o débito não excede os 500 Mpbs na direção de transmissão (Tx).
O débito de um Edge Virtual de 2 núcleos é limitado por software (por outras palavras, limitado através do software do Edge) para 500 Mbps para impedir que a CPU seja sobrecarregada. No entanto, as melhorias ao software do Edge permitiram que um Edge Virtual de 2 núcleos controlasse muito mais tráfego sem que a CPU ficasse sobrecarregada e o limite de 500 Mbps existente é agora demasiado limitador. Com esta compilação do Edge, o limite de débito de 2 núcleos é aumentado para 1000 Mbps.
Problema 98514 resolvido: Numa empresa do cliente implementada com uma topologia de alta disponibilidade, sempre que uma alteração à configuração é aplicada nos Edges do VMware SD-WAN, o utilizador deveria observar um evento que indica “O serviço de gestão falhou” (Management service failed) no Edge em standby e que em resultado de tal o serviço de gestão está a reiniciar.
Uma vez que este é um serviço de gestão (que não envolve o tráfego do cliente) e no Edge em standby, não existe nenhum impacto negativo para os utilizadores de clientes no local de HA quando o serviço de gestão do Edge em standby reinicia. Ainda assim, trata-se de um evento crítico registado nos Eventos do Edge que será de grande preocupação para os administradores de cliente.
Problema 100377 resolvido: Quando um VMware SD-WAN Edge é atualizado para a Versão 5.0.x, os utilizadores do cliente do lado da LAN podem observar que todo o tráfego do cliente é removido e não conseguem ligar-se a outros sites nem à Internet.
Descrição: este problema ocorre aleatoriamente e afeta o tráfego do lado da LAN. O Edge permanece ligado ao Gateway e ao Orchestrator. No Orchestrator, quando observa Monitorizar > Edge > Estado de funcionamento (Monitor > Edge > Health) um utilizador deveria observar um nível crescente de handoff queue drops. O problema é provocado por uma mudança de comportamento introduzida na compilação 5.x do Edge, o que pode levar a uma fuga de pacotes, um pacote em particular relacionado com a mudança já não é lançado e ao longo do tempo a memória intermédia do pacote fica sobrecarregada e começa a ignorar todos os pacotes.
Num Edge sem uma correção para este problema, reiniciar o serviço do Edge vai limpar a memória intermédia, mas apenas temporariamente.
Problema 101049 resolvido: Se uma empresa do cliente utilizar caminhos seguros e não seguros, poderá registar perdas de caminho elevadas.
Um exemplo da utilização tanto de caminhos seguros como caminhos não seguros seria uma empresa onde um Gateway de parceiro é usado e o Edge aprende sub-redes de um vizinho BGP (não seguro) e, em seguida, o Edge aprende essas mesmas sub-redes de outra Edge na rede (seguro). Neste cenário o caminho seguro é o preferencial, mas se o caminho seguro for revogado, o tráfego não é comutado para o caminho não seguro. O problema é provocado pelo serviço do Edge não sequenciar os túneis de gestão responsáveis por um encaminhamento correto.
A compilação R5011-20221007-GA do Edge/Gateway foi lançada em 11-10-2022 e é o 1.º rollup do Edge/Gateway para a versão 5.0.1.
Esta compilação rollup do Edge/Gateway aborda os problemas críticos abaixo desde a compilação GA original, R5010-20220729-GA.
Problema 89235 resolvido: Na empresa de um cliente que utiliza uma topologia Hub/Spoke e empregue políticas de backhaul da Internet, o tráfego de backhaul a partir de um Edge Spoke do VMware SD-WAN que se destina à Internet pode ser ignorado pelo Edge Hub.
Quando este problema é encontrado, os utilizadores clientes notarão problemas no tráfego destinado à Internet. O problema ocorre após um dos seguintes: um ciclo de energia do Edge (por exemplo, após uma falha de energia), um reinício do serviço do Edge ou uma alteração da configuração e o problema é provocado por um problema de temporização entre o tráfego de backhaul com origem num Edge Spoke e o caminho anunciado a partir do Edge Spoke.
Ao encontrar este problema num Edge Spoke sem a correção, um utilizador deve esvaziar os fluxos no Edge Spoke afetado para restaurar o encaminhamento normal do tráfego de backhaul. Isto pode ser realizado no Orchestrator através de Diagnóstico remoto > Esvaziar fluxos (Remote Diagnostics > Flush Flows).
Problema 94430 resolvido: Na empresa de um cliente que utilize uma topologia Hub/Spoke onde vários Hubs são implementados, um utilizador que utiliza um Edge Spoke do VMware SD-WAN pode observar problemas com o tráfego destinado a um Edge Hub.
Os problemas de tráfego do cliente ocorrem quando o Spoke Edge encaminha o tráfego para um Hub diferente daquele que se espera receber o tráfego. O problema é provocado pelo comprimento do caminho AS devido aos caminhos BGP remotos não serem devidamente calculados em determinadas situações. Devido a este motivo, os caminhos a partir dos Hubs que deveriam ter uma preferência de encaminhamento inferior acabam por ter um comprimento de AS_PATH superior e podem ser preferidos.
Se encontrar este problema sem uma correção, um cliente poderá retirar e anunciar novamente o caminho que se espera que seja o preferido.
Problema 95503 resolvido: Em situações raras, um cliente pode ver um modelo 610, 610N ou 610-LTE do VMware SD-WAN Edge apresentar o mesmo endereço MAC para todas as interfaces da Ethernet.
Um Edge 610 (qualquer tipo) pode mostrar um endereço MAC eth0 que termina em 0xF*. Nestes casos, as portas GE1 a GE6 recebem o mesmo endereço MAC devido a um problema com o script que calcula e atribui endereços MAC.
A correção corrige este comportamento do script e um modelo Edge 610 afetado deveria calcular e alocar corretamente endereços MAC únicos quando o Edge é atualizado para uma compilação que o inclui.
Problema 96055 resolvido: Um VMware SD-WAN Gateway pode encontrar uma falha no serviço dataplane com o sinal 6 (SIGABRT) e gerar um núcleo.
Este problema poderá ocorrer se um VMware SD-WAN Edge enviar um pacote que faz referência a um segmento inválido para o Gateway Principal do Edge. Quando o Gateway recebe este pacote, o processo do Gateway falha em vez de lidar da melhor forma possível com a situação, eliminando tais pacotes.
Problema 96231 resolvido: Quando um cliente implementa um Destino Não-SD-WAN (NSD) via Gateway com um tipo Palo Alto Networks e também configura a “Funcionalidade de monitorização do túnel Prisma” (Prisma tunnel monitoring feature) da Palo Alto para utilização neste NSD, o utilizador pode observar que enquanto os túneis IPsec são estabelecidos para este NSD, estes são continuamente desmontados e reconstruídos a cada 5 a 15 segundos, o que provoca interrupções do tráfego que utiliza o NSD.
Quando a monitorização do túnel Prisma está ativada, a aplicação Prisma envia pacotes ICMP encriptados para o SD-WAN Gateway e quando o Gateway responde de volta ao pacote ICMP, o Prisma confirma que o túnel está estabelecido. Na verdade, o Prisma é uma espécie de verificação do funcionamento do túnel IPsec. No entanto, o problema neste caso é que o Gateway está a ignorar o pacote ICMP de Prisma e, assim, o Prisma marca o túnel como inativo, o que aciona a desmontagem e reconstrução do túnel.
Os problemas são provocados pelo Gateway receber o pacote ICMP e verificar se se trata de um pacote de pedido de eco, mas em vez de verificar o campo de tipo, o Gateway verifica incorretamente o campo de código no cabeçalho ICMP e isto resulta no Gateway eliminar o pacote ICMP, o que aciona o desmantelamento do túnel pelo Prisma.
Num Gateway que não tem uma correção para este problema, o cliente não deve utilizar o Prisma para o NSD do tipo Palo Alto.
Problema 98157 resolvido: Um VMware SD-WAN Gateway pode encontrar uma falha do Serviço dataplane e, como resultado, reiniciar.
Em instância raras quando a porta de origem de um túnel SD-WAN é alterada (por exemplo, devido a um reinício do dispositivo NAT intermédio), o processo do dataplane do Gateway pode falhar, em seguida, reinicia e gera um núcleo.
Problema 99188 resolvido: Em algumas situações, uma sessão BGP pode não surgir para uma empresa do cliente.
Este problema ocorre quando um valor ASN superior a 2147483648 é configurado. Neste caso, a configuração não é aplicada e, desta forma, as sessões de BGP não surgem.
A versão R5010-20220729-GA do Edge e Gateway foi lançada em 05-08-2022 e resolve os seguintes problemas desde a versão R5002-20220506-GA do Edge/Gateway. Isto significa que uma correção para qualquer problema do Edge ou Gateway listada nas notas de versão 5.0.0 está incluída em todas as compilações da versão 5.0.1.
Problema 58791 resolvido: Um site implementado com uma topologia de alta disponibilidade onde o BGP é utilizado pode encontrar um problema em que o VMware SD-WAN Edge falha repetidamente.
Este problema afeta os sites HA configurados com uma topologia hub/spoke onde o site HA tem mais de 512 prefixos de filtro BGPv4 configurados.
Quando o BGP é utilizado com vários comandos de rede configurados e enquanto o Edge em standby é ativado, analisa todas as configurações simetricamente e para cada comando de rede é gerado um vtysh. Consequentemente, o thread verp não é executado. O atraso no thread verp resulta num atraso no processamento do heartbeat, o que faz com que o Edge em standby acredite que o Edge ativo está inativo e se torne ativo, causando um estado ativo-ativo. Para recuperar do estado split-brain, o Edge em standby reinicia, o que apenas vai repetir o ciclo.
Sem a correção, a solução alternativa é reduzir o número de configurações de prefixo de filtro BGP agregando-as e mantendo o número total abaixo de 512 (256 filtros de entrada e 256 filtros de saída).
existe um problema semelhante em que um site de HA sofre perturbações ao utilizar as operações de “corresponder e definir” (match and set) do BGP e este é acompanhado em separado em Problema 84825 resolvido, que também é resolvido nesta compilação do Edge.
Problema 67458 resolvido: quando um VMware SD-WAN Hub Edge com um grande número de Edges Spoke é atualizado para a versão 4.2.1 ou posterior, alguns túneis para outros Edges Spoke não aparecerão para o Edge Hub.
Entende-se por um grande número de Edges Spoke ~1000 ou mais. Este problema não é consistente, mas, geralmente, ~1/3 dos túneis do Protocolo de gestão do VeloCloud (VCMP) não são estabelecidos entre o Edge Hub e os Edges Spoke ligados. Isto é causado pelo Hub Edge ignorar o MP_INITs dado que o número de TDs meio abertos excede o limite superior do Edge Hub.
Ao encontrar este problema sem a correção, o reinício do Serviço Edge restabelecerá a conectividade total do túnel.
Problema 70129 resolvido: Quando o Syslog está ativado num VMware SD-WAN Gateway de grande escala, a pasta /var/log pode ficar cheia de ficheiros de syslog num curto período de tempo.
A grande escala é considerada como um Gateway com cerca de 4 mil pares e cerca de 6 mil túneis, em que existem, geralmente, perto de 100 a 150 mil fluxos e perto de 50 a 100 mil entradas NAT. O curto período de tempo pode ser de apenas 24 horas com um ficheiro syslog.log de tamanho >3,2 Gb. Isto é causado pelo facto de alguns registos NAT serem redirecionados para /var/log, mas que deveriam ser direcionados para outra pasta.
Problema 70586 resolvido: Quando uma interface encaminhada num VMware SD-WAN Edge for configurada para 802.1x (utiliza autenticação RADIUS), a autenticação dos clientes ligados nessa interface será silenciosamente desativada sempre que qualquer interface sofrer um flap (isto é, quando qualquer interface não 802.1x ficar inativa e ativa rápida e sucessivamente) e todo o seu tráfego falhará até que o cliente se desligue e se volte a ligar ao Edge.
O Edge não está a verificar se a interface onde ocorreu um flap é realmente a que teve clientes 802.1x autenticados e, portanto, trata qualquer ocorrência de flap numa interface como se fosse um flap de interface de 802.1x e atua em conformidade.
Sem a correção, a única solução alternativa é forçar o cliente a desligar-se fisicamente e ligar novamente para ser novamente autenticado.
Problema 74291 resolvido: Um VMware SD-WAN Edge numa topologia de alta disponibilidade pode aparecer como offline após uma recuperação automática, apesar de ter acesso à Internet e um DNS funcional.
Este problema pode ocorrer após uma recuperação automática de alta disponibilidade e é provocado por um token de erro no recentemente promovido Edge Ativo, o que resulta numa falha do heartbeat para o Orchestrator. Sem o heartbeat, o Orchestrator assinala o Edge como inativo.
Sem uma compilação Edge com a correção, a forma de corrigir o problema é forçar localmente outra recuperação automática através de uma IU local ou realizando o ciclo de energia do Edge Ativo.
Problema 72925 resolvido: para um cliente que utiliza consultas SNMP para monitorizar a sua empresa e implementa modelos inferiores de VMware SD-WAN Edges (por exemplo, os modelos Edge 510, 520 ou 610) que estão a executar uma versão de software 4.x, as consultas SNMP demoram bastante tempo a processar e podem, inclusivamente, exceder o limite de tempo.
Este problema reduz significativamente a eficácia das consultas SNMP para monitorização de redes ao utilizar Edges das séries 510, 5x0 e 6x0. Este problema é causado pelo SNMPagent da versão 4.x, que demora bastante tempo a percorrer a lista de comandos de depuração, o que não é efetivamente necessário para o processo SNMP.
Problema 73830 resolvido: o tráfego de aplicações do System Center Configuration Manager (SCCM) é incorretamente classificado pelo VMware SD-WAN Edge como tráfego do Business Intelligence Service (BITS) e os clientes que utilizem Políticas empresariais ou Regras de firewall concebidas para o tráfego do SCCM observarão um impacto no tráfego.
O motor de Inspeção profunda de pacotes (DPI) do Edge classifica incorretamente os pacotes de aplicações do SCCM como tráfego do BITS e, caso haja Políticas empresariais ou Regras de firewall concebidas para direcionar esse tráfego ou garantir que o mesmo é permitido pelas regras de firewall, as classificações incorretas poderão fazer com que o tráfego do SCCM seja bloqueado, levando a uma interrupção para o cliente. A remediação deste problema envolveu corrigir os mapas de aplicação 4.5.1/5.0.1 e posteriores predefinidos, para assegurar que esta classificação incorreta é evitada.
Problema 74316 resolvido: Um Edge Spoke do VMware SD-WAN pode não se ligar a um ou a nenhum Cluster Edge do Hub atribuído, mesmo que o Edge tenha um reinício de serviço ou um reinício completo.
Existe um problema com a lógica de reatribuição de clusters, que cria o mapeamento de atribuição de clusters sem a informação de ponto final do membro do cluster num cenário específico de flap de sobreposição Membro de cluster para Supergateway. Como resultado, os Edges do Spoke atribuídos ao membro do Cluster de hub não recebem, subsequentemente, a informação de ponto final do membro do Cluster de hub, fazendo com que não haja overlays entre os Edges do Spoke e os Clusters de hub.
Sem a correção, a única forma de remediar temporariamente esta condição é uma pessoa com acesso ao Gateway acionar uma reatribuição de cluster manualmente nos Supergateways.
Problema 76690 resolvido: um utilizador pode constatar que faltam registos importantes ao tentar resolver problemas de um VMware SD-WAN Edge porque o espaço foi ocupado por entradas repetidas de um evento de menor importância.
Num pacote de diagnóstico, velocloud/log pode ter registos repetidos do evento vc_peer_qos_update_cos_qlimits. O nível de registo deste evento é o plano de gestão e o mesmo pode ser registado repetidamente até ao ponto de o registo ser excedido e substituir outras entradas. Num cenário de resolução de problemas, isto pode resultar em mensagens de registo importantes em falta, dado que foram substituídas e eliminadas.
Problema 78276 resolvido: Num VMware SD-WAN Gateway, executar o comando debug.py -qos_net falhará se o nome do VMware SD-WAN Edge incluir carateres não ASCII.
Um exemplo prático deste problema foi a utilização de carateres chineses, mas aplica-se a todos os carateres não ASCII, e pode ser observado da seguinte forma: altere o nome de um Edge para incluir carateres não ASCII e reinicie o Edge. Em seguida, um Gateway ligado ao Edge executará o comando da CLI: debug.py --list 3, para obter o ID lógico do Edge. Em seguida, execute o comando da CLI do Gateway: debug.py -qos_net [logical ID] all stats e o utilizador observará o comando a falhar.
Problema 78300 resolvido: Se um VMware SD-WAN Edge estiver a utilizar uma ligação WAN configurada como de backup, um utilizador pode observar registos ou Eventos do Orchestrator que sugerem que os túneis estão a ficar ativos ou inativos para esta ligação.
Propositadamente, os túneis não são estabelecidos para ligações de backup. Mas qualquer pedido de túnel a partir de uma extremidade remota (normalmente um túnel dinâmico Edge-to-Edge) pode alterar o estado da ligação à medida que passa pela pilha. Nesta correção, foram tomados cuidados para que nenhum registo indique que qualquer formação de túnel ou remoção está a acontecer para a ligação de backup.
Problema 78391 resolvido: o tráfego com a classificação da aplicação Speedtest não está a funcionar corretamente.
Tanto speedtest.net como fast.com têm novos endereços IP de servidor de speedtest que estão em falta no mapa de aplicação predefinido e, consequentemente, a Política empresarial que lida com essas aplicações não é aplicada.
Se não for atualizado para a versão 4.5.1 ou 5.0.1, o operador poderá adicionar os IPs de speedtest necessários a um mapa de aplicação existente com o Editor de mapa de aplicação do VMware SASE Orchestrator (VMware SASE Orchestrator's Application Map Editor).
Problema 79261 resolvido: o tráfego de aplicações do Office 365/Microsoft 365 é incorretamente classificado como tráfego de aplicações Tencent Meeting (VooV Meeting) no VMware SD-WAN Edge.
Este problema pode ser disruptivo para os clientes que dependem de políticas empresariais ou de firewall para o routing e a definição de prioridades do tráfego do Office 365/Microsoft 365, pois esse tráfego é classificado como sendo do Tencent Meeting, sendo regido por uma regra completamente diferente. O problema tem origem em sub-redes de mapa de aplicação incorretas para o Tencent e que estão corrigidas no mapa de aplicação predefinido da versão 4.3.2. É possível corrigir este problema para um cliente que não utilize a versão 4.3.2 através de um operador que edite o mapa de aplicação através do Editor de mapa de aplicação do Orchestrator para corrigir as sub-redes do Tencent.
Problema 80010 resolvido: Para a empresa de um cliente que utilize uma topologia Hub/Spoke em que o SD-WAN alcançável também está configurado, o caminho do Spoke para o Gateway (ao utilizar uma ligação WAN pública) através do caminho do Hub não é apresentado se o caminho do Spoke para o Hub for ponto a ponto.
A funcionalidade SD-WAN alcançável, que é uma passagem para um Edge do Spoke se ligar a um Gateway através de um Hub ligado, não é suportada se o Edge do Spoke e o Edge do Hub estiverem ligados ponto a ponto (por outras palavras, o endereço IP do Spoke corresponde ao caminho ligado no Hub). A correção para este problema adiciona esta funcionalidade.
Problema 80196 resolvido: Um VMware SD-WAN Gateway pode registar uma falha no Serviço dataplane com uma mensagem SIGXCPU e o Gateway reinicia o serviço para recuperar, com um impacto de cerca de 15 a 30 segundos no respetivo tráfego.
Este problema é verificado quando existe débito elevado nesse Gateway relativamente à capacidade de débito do mesmo, pelo que é mais provável que ocorra em implementações de grande escala (por exemplo, 4 mil Edges e 6 mil túneis). Quando o tráfego a uma taxa elevada chega ao Gateway, em alguns casos, este registará um bloqueio de thread e gerará um núcleo durante o reinício. No núcleo, o utilizador verá: Program terminated with signal SIGXCPU, CPU time limit exceeded.
Problema 80479 resolvido: um VMware SD-WAN Gateway pode registar uma falha no Serviço dataplane e o Gateway reinicia o serviço para recuperar, o que tem um impacto de cerca de 15 a 30 segundos no tráfego do Gateway.
Este problema poderá ocorrer se um VMware SD-WAN Edge estiver ligado ao Gateway com Edge-a-Edge (E2E) configurado e um caminho de interface de retorno anunciado. Quando um utilizador desativa o E2E nesse Edge, é acionado um início de caminho, mas o caminho de retorno não é eliminado e o caminho atualiza a respetiva flag de perfil. Em seguida, se o utilizador remover o anúncio do caminho de retorno, o caminho do FIB será eliminado, mas permanecerá inativo na tabela E2E no Gateway. Se o caminho de retorno for de novo anunciado e adicionado ao FIB e, posteriormente, o utilizador ativar novamente o Edge-a-Edge, o que, mais uma vez, apenas atualizará a flag, apesar de o caminho estar presente na tabela E2E do Gateway (que está inativa), a ref_count do caminho real não será correta. Finalmente, se o túnel for removido, ocorrerá uma falha do Serviço de dataplane no Gateway.
Sem a correção, um operador terá de se certificar de que os caminhos são removidos antes de um perfil ser alterado para o Edge.
Problema 80496 resolvido: o envio de um ping de um VMware SD-WAN Edge para um endereço IP de retorno de ramo do Edge remoto através de um túnel do SD-WAN pode não funcionar.
O problema ocorre em pings com tamanhos de pacotes suficientemente grandes para provocar fragmentações. Quando o ping é iniciado com um tamanho de pacote grande de um Edge para o endereço IP de retorno de um ramo remoto do Edge, a resposta fragmentada do ICMP consegue aceder ao Edge que inicia o ping, mas não consegue aceder à aplicação de ping, pois o fragmento seguinte é removido.
Problema 80721 resolvido: os parceiros e operadores que monitorizam um VMware SD-WAN Gateway com o Telegraf podem observar que as métricas não são retomadas caso o Telegraf sofra um tempo limite de rede excedido.
Os Gateways que registam este problema estão a utilizar a versão 1.17.3 do Telegraf, o que é diferente da versão do Telegraf que o VMware SASE Orchestrator está a utilizar: 1.21.1. Esta incompatibilidade de versões causa o problema em que o Telegraf fica bloqueado caso ocorra um tempo limite excedido da rede. Os Gateways com uma correção deste problema incluem a versão 1.21.1 do Telegraf, assim como qualquer compilação futura do Gateway nessa série de versões (por outras palavras: 4.5.1 ou 5.0.1).
Num Gateway que registe este problema, a única remediação consiste em reiniciar o Telegraf para retomar o envio de métricas.
Problema 80814 resolvido: num VMware SD-WAN Edge em que a regra de permissão da firewall padrão está configurada, que possui um endereço IP de origem de cliente Edge local e um cliente remoto como endereço IP de destino e que também possui a regra “Recusar tudo” (Deny All) para outro tráfego, o tráfego do cliente remoto para o cliente local é ignorado.
Este problema é encontrado quando existe uma incompatibilidade do endereço IP da VLAN entre os anfitriões de origem e de destino. Quando os anfitriões de origem e de destino fazem parte de VLANs diferentes, o serviço SD-WAN prefere o endereço IP de origem/destino do primeiro pacote, dado que está na chave de pesquisa da firewall. Como resultado, existe uma incompatibilidade dos fluxos de entrada de overlay e o tráfego atinge a regra da firewall Recusar tudo (Deny All).
Sem a correção, a solução alternativa para este problema consiste em reverter a regra na direção do primeiro pacote IP do fluxo, para que o pacote consiga corresponder à regra da firewall.
Problema 80897 resolvido: Para uma empresa do cliente onde os VMware SD-WAN Edges estão ligados a Gateways de parceiro do VMware SD-WAN, os utilizadores podem observar um mau desempenho do tráfego do cliente.
O mau desempenho é o resultado de problemas de routing decorrentes dos caminhos de distribuição do Gateway de parceiro para os Edges onde estão disponíveis caminhos estáticos seguros preferenciais, mas o Edge não identifica corretamente estes caminhos como seguros. O resultado é que o Edge pode anunciar caminhos não seguros não preferenciais em vez de caminhos seguros, uma vez que todos os caminhos são tratados da mesma forma quando o comportamento esperado é preferir sempre caminhos seguros em vez de caminhos não seguros.
Tanto o Gateway de parceiro como os Edges do cliente devem ser atualizados para uma compilação que inclua esta correção para resolver o problema.
Problema 81221 resolvido: se um cliente configurar uma regra NAT 1:1 para um VMware SD-WAN Edge e esse Edge for reiniciado, a regra deixará de funcionar.
Após o reinício, o Edge atribui o endereço NAT como o endereço da interface do Edge em que a regra NAT está a ser aplicada, pelo que não são criados túneis para o tráfego que corresponde a essa regra.
Sem a correção, a única remediação é executar Diagnóstico remoto (Remote Diagnostic) > Esvaziar NAT (Flush NAT), que esvazia toda a tabela NAT e restabelece o correto funcionamento da regra NAT.
Problema 81809 resolvido: Quando um utilizador tenta aceder através de SSH a um IP VLAN num VMware SD-WAN Edge a partir de um cliente remoto por trás de outro Edge ou até mesmo por trás de um VMware SD-WAN Gateway, a tentativa de SSH falhará.
Uma tentativa de SSH a partir de um cliente LAN para um IP Edge VLAN funcionará corretamente. Originalmente, foi utilizado o IP de Gestão do Edge para aceder através de SSH ao Edge. No entanto, após a descontinuação do IP de gestão do Edge, não havia opção para o utilizador aceder através de SSH ao Edge (através de overlay a partir de um cliente Edge), pois o IP de retorno continua sem suporte para SSH.
Problema 81859 resolvido: quando um VMware SD-WAN Edge 610-LTE é ativado para a versão 5.0.0 do Edge, a interface CELL pode não aparecer depois de o Edge ser atualizado para essa versão.
Este problema não é consistente, mas quando ocorre pode ter um grande impacto se a única ligação pública do Edge 610-LTE for a ligação CELL móvel, uma vez que o Edge estará efetivamente inativo e a intervenção para este Edge terá de ser local.
Se encontrar este problema num Edge sem a correção, o utilizador terá de reiniciar o serviço Edge (ou desligar e ligar/reiniciar, se o Edge estiver inacessível através do Orchestrator) ou reiniciar o modem do Edge para restaurar a interface CELL.
Problema 82182 resolvido: para um modelo VMware SD-WAN Edge 510 ou 510-LTE que esteja a executar a versão 5.0.0 do Edge, quando um utilizador tenta reiniciar o serviço do Edge, o Edge pode também reiniciar.
Um reinício do Edge interromperia o tráfego do cliente durante 2-3 minutos durante o processo o processo de reinicialização. Num Edge 510/510-LTE, existe um script de monitorização de paragem de dispositivo Wi-Fi cuja paragem pode falhar durante o reinício do serviço do Edge, o que desencadeia a reinicialização.
Sem a correção, um utilizador precisaria de reiniciar o serviço Edge, mas os reinícios do serviço Edge para estes modelos só deve ser efetuado numa janela de manutenção ou tendo a noção de que este problema pode ocorrer.
Problema 82264 resolvido: um VMware SD-WAN Virtual Edge que utiliza uma instância AWS C4 não pode ser atualizado para a versão 5.0.0.
Um AWS C4 Virtual Edge atualizado para a versão 5.0.0 não recupera e a única correção é o utilizador reativar o Edge para uma versão que não seja a 5.0.0. Nenhuma outra instância AWS (por exemplo, C5) é afetada por este problema, mas, devido à natureza crítica deste defeito, não está disponível um pacote de Atualização de software AWS Edge para a versão 5.0.0.
A versão 5.0.1 e as versões posteriores do Edge corrigem este problema e a instância AWS C4 pode ser atualizada com sucesso para a versão 5.0.1 e versões posteriores.
Problema 82463 resolvido: Num site configurado com um Serviço de Segurança na Cloud (CSS), o VMware SD-WAN Edge pode perder tráfego destinado ao CSS.
Se o site estiver a encaminhar todo o tráfego de Internet através de um CSS, o impacto deste problema pode ser significativo. Quando o problema ocorre, os pacotes CSS são enviados na interface incorreta, com o endereço IP da interface real como a fonte que origina uma falha no acesso à aplicação. O problema é causado por uma potencial corrida entre o thread de pesquisa de contexto do CSS e o thread de seleção de interface de saída, que provoca a associação incorreta da interface de saída ao fluxo e a falha de alguns fluxos nos caminhos do CSS.
Sem a correção, quando ocorre o problema, o utilizador pode solucioná-lo ao iniciar um novo fluxo ou esvaziar todos os fluxos no Edge através de Diagnóstico remoto > Esvaziar fluxos (Remote Diagnostics > Flush Flows).
Problema 82485 resolvido: num modelo VMware SD-WAN Edge de nível básico (por exemplo, Edge 510, 510-LTE ou 610), se um utilizador executar o diagnóstico remoto “Esvaziar tabela de caminhos” (Route Table Dump), a página da IU do Orchestrator pode exceder o tempo limite e não devolver um resultado.
O problema é encontrado se existirem mais de 16 000 caminhos, dado que o Edge demora mais de 30 segundos a devolver os resultados. 30 segundos é o tempo limite do WebSocket da página e, portanto, nenhum resultado é devolvido. A correção deste problema otimiza o percurso da tabela de caminhos, para garantir que os tempos limites não são excedidos.
Problema 82522 resolvido: quando o tráfego de elevado débito chega a um VMware SD-WAN Edge, pode verificar-se uma queda no débito real observado no Edge.
Com débito elevado, o thread do protocolo NDP (Neighbor Discovery Protocol) do Edge adquire um bloqueio duas vezes, mesmo para entradas do protocolo NDP que tenham sido marcadas como acessíveis, pelo que não é necessário mais processamento. Estes bloqueios duplicados fazem com que o débito diminua devido ao processamento adicional.
Problema 82652 resolvido: Para um cliente que utilize um Serviço de Segurança na Cloud (CSS) em que está configurada a Verificação de estado de funcionamento de L7, o VMware SD-WAN Edge não tenta recuperar um túnel CSS IPsec que foi marcado como inativo há mais de cinco minutos.
Na implementação atual da Verificação de estado de funcionamento de L7, o Edge envia sondas L7 em todos os túneis CSS e, se essas sondas falharem um número definido de vezes, o Edge marca o túnel como inativo, continua a enviar sondas L7 e aguarda que o túnel fique ativo por si mesmo. O problema prende-se com o facto de não existir qualquer tentativa de recuperar um túnel após este se encontrar num estado inativo por mais de cinco minutos, sendo que o IKE permanece ativo (se o IKE também estiver inativo, o túnel IPsec é automaticamente reposto após 20 segundos).
A correção neste caso melhora a Verificação de estado de funcionamento de L7, incluindo um passo adicional para os túneis CSS baseados em IPsec: se um túnel CSS baseado em IPsec permanecer inativo por mais de cinco minutos (sem sondas L7 bem-sucedidas), enquanto o IKE do túnel permanece ativo durante o mesmo período, o Edge derruba o túnel IPsec e repõe o IKE numa tentativa de recuperar o túnel CSS. As sondas L7 continuariam a ser enviadas enquanto isto ocorre e marcariam o túnel como ativo se fossem bem-sucedidas. Se o túnel permanecesse inativo, seria aplicado o mesmo passo após cinco minutos adicionais.
Este comportamento adicionado aplica-se apenas a um CSS com túneis IPsec, e não aos que utilizam túneis GRE.
Problema 82790 resolvido: nos VMware SD-WAN Gateways implementados em ambientes do Azure, os contadores da interface do Gateway não são exportados para o serviço de monitorização Wavefront.
O Azure é um ambiente onde o DPDK não está configurado para utilização e apenas os contadores de interface do DPDK (taxa de débito, PPS e contadores de queda) são exportados para o serviço Wavefront. Este facto resulta em capacidades de monitorização reduzidas em plataformas como o Azure, em que o DPDK não é utilizado.
Problema 82839 resolvido: se um utilizador realizar uma ação de eliminação de automatização de IPsec para um túnel do Serviço de Segurança na Cloud Zscaler num VMware SASE Orchestrator, essa ação também eliminará todas as credenciais de VPN associadas à respetiva localização do Zscaler, resultando na eliminação da própria localização.
A ação de eliminação da automatização de IPsec só deve eliminar a credencial de VPN que lhe está associada a partir da localização do Zscaler. Todas as outras credenciais de VPN associadas à respetiva localização do Zscaler devem permanecer intactas.
Problema 83029 resolvido: Para um VMware SD-WAN Edge autónomo ou um site implementado com uma topologia de alta disponibilidade onde são utilizadas uma ou mais ligações PPPoE, se o IP do ponto final PPPoE for alterado após ocorrer um flap na interface do Edge para essa ligação PPPoE ou quando um site HA tiver uma falha, o tráfego não passará nas ligações PPPoE afetadas.
Num site que utiliza ligações PPPoE, em conjunto com uma alteração no IP do ponto final do PPPoE, o impacto significaria nenhum tráfego de clientes a passar. O problema é causado pela presença de um caminho predefinido, que é um caminho que utiliza o antigo endereço IP do ponto final PPPoE no Edge, que não é eliminado após recebido um novo endereço IP do ponto final do PPPoE.
Sem a correção, um utilizador no local teria de desligar cada cabo PPPoE e voltar a ligá-lo para forçar uma renegociação ou reiniciar o Edge, o que também forçaria uma renegociação.
Problema 83083 resolvido: Um VMware SD-WAN Gateway atualizado para a versão 4.3.1 ou posterior pode registar uma fuga de memória lenta, que pode levar ao reinício do serviço do Gateway para limpar a memória.
Os reinícios dos Gateways podem ser disruptivos para o tráfego do cliente durante os 30 a 45 segundos que o reinício do serviço do Gateway demora. Cada vez que um utilizador operador executa o comando debug.py --flow_dump all all all no Gateway, este esvazia parte da memória. Executar este comando de depuração vezes suficientes fará com que a utilização da memória do Gateway atinja um nível crítico e desencadeie um reinício do serviço do Gateway para limpar a memória.
Num Gateway sem a correção, o operador tem de evitar executar o comando debug.py --flow_dump all all all no Gateway. Se a utilização deste comando de depuração for inevitável, monitorize a utilização da memória e agende as janelas de manutenção para reiniciar preventivamente o serviço para limpar a memória antes de um reinício não programado.
Problema 83209 resolvido: Para os clientes que utilizam o OSPF na respetiva empresa, o routing OSPF pode não funcionar conforme esperado.
O problema ocorre quando há uma alteração no router-id do OSPF e o serviço Edge é reiniciado. Apenas as interfaces de retorno e as interfaces com a flag “Anunciar” (Advertise) definida são consideradas para a seleção de router-id. Quando existe uma nova interface de retorno configurada com um endereço IP superior, após o reinício do serviço Edge, o novo endereço IP de retorno é selecionado como o router-id e, se o Edge for escolhido como o RD (Router designado), o problema ocorrerá.
Sem a correção, a única solução é forçar a utilização do ID de router antigo. Para voltar a utilizar o ID de router antigo, defina a flag Anunciar (Advertise) na respetiva interface (será necessário reiniciar o serviço Edge).
Problema 83402 resolvido: Num VMware SD-WAN Edge com várias ligações WAN, uma ou mais ligações WAN podem deixar de passar tráfego.
Nas ligações WAN que deixam de passar tráfego, o endereço adquirido DHCP não é renovado e o endereço da interface WAN é perdido. O problema ocorre quando existem várias interfaces que adquirem endereços IP utilizando o DHCP e o servidor DHCP está numa rede diferente do cliente. A interface de saída de um pacote unicast de renovação DHCP é determinada através da procura de caminhos. Uma vez que existem vários caminhos predefinidos com diferentes valores de métricas aprendidos através de diferentes interfaces, os pacotes de pedidos DHCP podem ser enviados de uma interface diferente.
Sem a correção, um utilizador no local teria de a desligar e, em seguida, voltar a ligá-la na ligação WAN afetada a partir do Edge para a forçar a obter novamente o respetivo endereço IP.
Problema 83411 resolvido: quando a alta disponibilidade é ativada com um VMware SD-WAN Edge recentemente ativado, o par Edge HA pode ficar offline.
Quando a HA é ativada, todos os endereços MAC da interface Edge são alterados para endereços MAC virtuais e, durante o estado de emissão, a configuração DPDK não é atualizada com estes endereços VMAC. Como resultado, os pacotes de heartbeat destinados ao Orchestrator são ignorados devido a uma incompatibilidade do MAC de destino e o Orchestrator assinala o par Edge HA como inativo.
Problema 83424 resolvido: um percurso SNMP pode não funcionar corretamente para OIDs relacionados com caminhos e interfaces.
Quando é executado um comando snmpbulkwalk para algumas implementações do Edge, o percurso SNMP pode demorar demasiado tempo e exceder o tempo limite. A correção deste problema otimiza o SNMP e garante respostas mais rápidas aos pedidos de percurso SNMP. No entanto, é de notar que existem situações raras em que o problema continua a ocorrer, uma vez que o processo SNMP continua a ser um processo de menor prioridade no Edge.
Problema 83428 resolvido: numa empresa de cliente que utiliza uma topologia Hub/Spoke, os túneis estáticos entre um VMware Hub Edge e um Spoke Edge podem deixar de passar tráfego ao tentarem medir a largura de banda no túnel.
No Hub Edge, não existe nenhum mecanismo para lidar com um cenário em que a preferência de túnel é atualizada a meio do processo de estabelecimento do túnel. O processo de medição da largura de banda coloca o túnel num estado parado e o tráfego não consegue passar no mesmo. O tráfego do cliente pode ser redirecionado através do Gateway, mas isso pode introduzir latência no tráfego Hub/Spoke.
Problema 83432 resolvido: num site implementado com uma topologia de alta disponibilidade, quando são adicionados outros túneis ao site, o Edge em standby do VMware SD-WAN pode sofrer uma falha do Serviço dataplane e gerar um núcleo.
Uma forma comum de adicionar túneis consiste em adicionar ligações WAN aos Edges HA. Quando o número de túneis que o Edge em standby precisa de sincronizar com o Edge ativo ultrapassa os 80, isto aciona uma exceção e uma falha do Serviço dataplane no Edge em standby. Quando este problema é encontrado numa topologia HA convencional, o impacto no cliente deverá ser mínimo, dado que o Edge em standby não está a passar o tráfego do cliente. Numa implementação HA melhorada, onde o Edge em standby também está a passar tráfego, os reinícios perturbarão algum tráfego do cliente.
Problema 83611 resolvido: o cliente pode observar um número invulgarmente elevado de eventos EDGE_NEW_DEVICE a partir de um VMware SD-WAN Hub Edge na IU do VMware SASE Orchestrator.
Este problema pode ser encontrado com a seguinte topologia: Dispositivo cliente – Edge Spoke – Hub Edge – Servidor DHCP. Com esta topologia, sempre que um utilizador cliente que utiliza um Edge Spoke envia um pacote DHCP, o Edge Spoke aciona corretamente um evento Edge_New_Device para este dispositivo do cliente. No entanto, quando o Hub Edge recebe o pacote de reencaminhamento DHCP, o Hub Edge aciona novamente um evento Edge_New_Device para o Orchestrator e este evento está incorreto.
Problema 83699 resolvido: quando um VMware SD-WAN Gateway está definido para o modo desligado na nova IU do VMware SASE Orchestrator, quando o utilizador seleciona um novo Gateway de substituição, o Orchestrator não permite alterações de configuração no mesmo.
Este problema ocorre depois de ativar o processo de migração do Destino Não-SD-WAN através da nova IU do Orchestrator, sendo que parte desse processo é selecionar um novo Gateway, que é aquele que substituirá o Gateway desligado. Quando o novo Gateway for designado como o Gateway de substituição, ao tentar efetuar qualquer alteração de configuração no Gateway de substituição, o Operador observará uma mensagem de erro semelhante a: GATEWAY_SERVICE_STATE_INVALID: Cannot change the state of the gateway to null, as it is already used as a replacement gateway.
Problema 83928 resolvido: Um VMware SD-WAN Edge pode sofrer uma elevada utilização da CPU e um fraco desempenho de tráfego do cliente.
Os utilizadores também poderiam observar pontuações QoE fracas ao consultar o ecrã Monitorizar > Edge > QoE (Monitor > Edge > QoE) do Orchestrator desse Edge. O problema é causado por uma regra da lista de controlo de acesso (ACL) que é instanciada várias vezes no Edge e está a forçar a capacidade da CPU do Edge a processar muitas regras ACL de uma só vez, o que faz com que o Edge não consiga processar o tráfego do cliente corretamente.
Problema 83946 resolvido: Os clientes do lado da LAN do VMware SD-WAN Edge podem observar perturbações no tráfego e, para um site que utilize a autenticação RADIUS, os utilizadores do cliente podem observar falhas de autenticação.
Os pacotes grandes serão fragmentados e estes pacotes fragmentados podem ser removidos pelo Edge Os pacotes podem ser removidos devido a uma fuga de memória durante a tradução da identificação do IP do fragmento durante alguns cenários de erro e, se o limite do Edge para os pacotes fragmentados for excedido, este poderá remover ainda mais pacotes fragmentados.
Para os clientes que utilizam o RADIUS em situações em que estão envolvidos pacotes grandes de um cliente sem fios para um Edge que utiliza a autenticação RADIUS, isto pode causar falhas de autenticação. Por exemplo, os pacotes grandes de um controlador LAN sem fios (WLC) para um servidor RADIUS podem ser removidos.
Problema 84106 resolvido: um VMware SD-WAN Edge pode exportar estatísticas do NetFlow no intervalo de tempo incorreto, o que faz com que os sistemas recetores fiquem dessincronizados.
Os pacotes do NetFlow podem ter um atraso adicional de 5 segundos em relação ao intervalo configurado. Isto acontece porque o exportador do NetFlow verifica o tempo de exportação apenas uma vez a cada 5 segundos e, como resultado, os pacotes do NetFlow podem ter um atraso de 5 segundos entre o intervalo configurado e o intervalo de exportação real.
Problema 84359 resolvido: Quando uma interface do VMware SD-WAN Edge é ativada e desativada repetidamente, é possível que vários endereços IPv4 possam ser atribuídos à mesma.
Quando uma interface, configurada com um cliente DHCP, é desativada e ativada repetidamente, todo o processo do cliente DHCP é executado novamente e poderá haver cenários em que um endereço IP diferente é adquirido de cada vez. Neste caso, o endereço IP mais antigo não é limpo nem ficará obsoleto.
Sem esta correção, a única forma de remediar o problema é o utilizador eliminar manualmente os endereços IP da interface através da shell do Linux com o comando ip address del.
Problema 84501 resolvido: para uma empresa de cliente que utiliza a autenticação 802.1x (por exemplo, RADIUS, Cisco ISE), quando os VMware SD-WAN Edges são atualizados para a versão 4.3.1 ou posterior, os dispositivos do cliente ligados ao Edge podem falhar a autenticação no servidor de acesso à rede (NAS) que está alojado na WAN.
O endereço IP do NAS é definido, por predefinição, como um endereço IP de retorno nos pacotes RADIUS ou ISE enviados do Edge (autenticador) para o servidor ISE ou RADIUS e isto pode fazer com que os pacotes de autenticação não cheguem ao NAS, causando a falha de autenticação. Para remediar o problema, as compilações com esta correção definem o endereço IP do NAS como o endereço IP da interface de origem selecionado e configurado com as definições de autenticação 802.1x. Se “Automático” (Auto) for selecionado como a interface de origem, o IP de retorno será definido como o endereço IP do NAS por predefinição.
Problema 84825 resolvido: quando é aplicada uma grande configuração de encaminhamento em massa num VMware SD-WAN Edge num só passo, o Edge poderá experienciar falhas repetidas no Serviço dataplane, resultando em repetidos reinícios do serviço do Edge para recuperar de cada falha.
Quando um Edge autónomo (não HA) se depara com este problema, há um impacto significativo no tráfego do cliente, porque embora um único reinício do serviço do Edge interrompa o tráfego durante cerca de 15 segundos, os reinícios repetidos resultam em interrupções de cerca de 60 segundos ou mais. Num site com topologia de Elevada disponibilidade, o cliente notaria uma recuperação automática repetida resultante dos reinícios do serviço do Edge, que também afetaria o tráfego.
Este problema ocorre quando é aplicada uma configuração de encaminhamento em massa que envolve um grande número de vizinhos e mapas de caminhos a um Edge num único passo. O sistema do Edge enfrenta uma grande pressão ao converter estas configurações em especificações de comando e aplicá-las em protocolos de encaminhamento num curto espaço de tempo, o que provoca as repetidas falhas e reinícios do serviço do Edge.
Numa compilação do Edge sem a correção, para mitigar o risco deste problema, o cliente teria de fazer o seguinte:
Em vez de aplicar uma configuração grande num único passo, a mesma deve ser dividida em várias secções menores com cada secção aplicada separadamente.
O número de filtros de encaminhamento deve ser minimizado.
O Edge só deve ser reiniciado deliberadamente numa janela de manutenção e o serviço do Edge deve ser, por norma, evitado se houver uma série de filtros de encaminhamento configurados, uma vez que toda a configuração do Edge é aplicada de uma só vez durante o reinício, o que aumentaria de forma considerável o risco de este problema ocorrer.
Problema 84847 resolvido: os clientes que implementam um modem LTE baseado em USB num VMware SD-WAN Edge ou implementam um modelo LTE VMware SD-WAN Edge (510-LTE ou 610-LTE) podem ter problemas intermitentes com a criação de túneis na interface CELL após a reposição do modem.
Quando o modem LTE é reiniciado num dos seguintes cenários:
Num Edge a utilizar um modem USB, ao remover e voltar a ligar ao modem na porta USB.
Num Edge-LTE, após um reinício do Edge ou ao reiniciar a interface CELL1 através de Teste e Resolução de problemas > Diagnóstico remoto > Repor modem USB > CELL1 (Test & Troubleshoot > Remote Diagnostics > Reset USB Modem > CELL1).
Em qualquer dos cenários, o dispositivo de rede subjacente muda de wwan0 para wwan1 e o Edge não respeita este novo nome porque parece ser uma interface duplicada.
Sem a correção, a solução para restaurar a interface LTE é reiniciar o Serviço Edge através de Ações remotas > Reiniciar o serviço (Remote Actions > Restart Service).
Problema 85369 resolvido: Num site implementado com uma topologia de alta disponibilidade, o cliente pode observar disrupções ao tráfego do cliente e, possivelmente, observar vários reinícios do VMware SD-WAN do Edge em standby.
Vários threads nos Edges HA estão a ficar suspensos, o que leva a vários problemas na HA, incluindo, entre outros, um estado Ativo-Ativo de HA. Se o site se tornar Ativo-Ativo, uma configuração HA convencional sofrerá uma disrupção mínima no tráfego, dado que o Edge em standby não passa tráfego nesta topologia, mas numa implementação HA melhorada, onde o Edge em standby também está a passar tráfego, os reinícios perturbarão algum tráfego do cliente. A outra forma através da qual a suspensão de múltiplos threads pode ter impacto num cliente é através da disrupção do caminho, que também pode ser observada como uma disrupção do tráfego do cliente. Desta forma, um site HA de cliente pode encontrar este problema sem, necessariamente, ver os sinais de um cenário Ativo-Ativo onde o Edge em standby reinicia.
A causa para vários threads do Edge HA serem suspensos permanece em investigação.
Problema 85375 resolvido: os clientes que utilizem modems LTE baseados em USB num VMware SD-WAN Edge ou modelos LTE do VMware SD-WAN Edge (510-LTE ou 610-LTE) podem sofrer perturbações no tráfego LTE.
O utilizador observaria nos registos do Edge erros RX que são incrementados sem que o tráfego passe pela interface LTE. Um aspeto do problema é que só ocorre se o MTU da ligação LTE for inferior a 1500.
Problema 85459 resolvido: Uma tentativa de acesso através de SSH a partir de um cliente do lado da LAN do Edge para um Edge ou de um cliente Edge numa sucursal remota para um Edge, poderá não funcionar após as regras NAT do lado da LAN serem configuradas.
Os pacotes de resposta SSH provenientes do processo SSH do Edge passam pelo serviço dataplane do Edge e, uma vez que as regras NAT do lado da LAN estão configuradas, será possível que os pacotes de resposta SSH utilizem essas regras para acederem a destinos diferentes do cliente original que gerou o tráfego SSH, o que faz com que as tentativas de SSH a um Edge não funcionem.
Num Edge sem a correção, a única solução alternativa é remover a regra NAT.
Problema 86032 resolvido: ao atualizar um VMware SD-WAN Gateway da versão 4.3.x para a 4.5.1 ou 5.0.0, o Gateway ignora a comunicação com o VMware SASE Orchestrator e as interfaces eth0 e eth1 são removidas.
O problema principal é o processo de dataplane do Gateway parar após a atualização. Isto é provocado pela falha ao iniciar do serviço Telegraf. Uma vez que o serviço Telegraf é ativado como parte do script de arranque do Gateway, se o início do Telegraf falhar, o serviço do Gateway também não inicia.
Se um Gateway for atualizado para uma compilação sem esta correção, a única forma de remediar o problema será executar vc_procmon restart no Gateway juntamente com um reinício do serviço Telegraf.
Problema 86103 resolvido: Na empresa de um cliente que utilize a autenticação RADIUS, os utilizadores clientes em determinados sites podem não conseguir ligar-se aos VMware SD-WAN Edges e passar o tráfego.
Os problemas são causados pelo Edge que categoriza incorretamente os pacotes RADIUS fragmentados com o bit DF (Don't Fragment) definido no cabeçalho do IP como não fragmentado. Um ou mais destes pacotes não conseguem aceder a vários Edges com o resultado de que o tráfego que depende da autenticação RADIUS não passará por esses Edges. Este problema pode ocorrer em qualquer topologia, incluindo Hub/Spoke e ramo a ramo simples.
Sem a correção, a única solução alternativa é configurar o servidor RADIUS para não definir o bit DF no cabeçalho do IP enquanto envia pacotes fragmentados.
Problema 86314 resolvido: um VMware SD-WAN Edge pode efetuar uma pesquisa incorreta de regras de firewall com estado quando o fluxo NAT do lado da LAN é iniciado por um par remoto.
Quando um utilizador configura uma NAT de origem do lado da LAN (por exemplo, para ocultar uma sub-rede IP interna por trás do Edge) num Edge no qual a Firewall com estado é utilizada, e um par remoto iniciar um fluxo, é efetuada uma pesquisa de firewall errada para o primeiro pacote de retorno.
Por exemplo, suponha que um Edge tem a seguinte configuração:
LAN-side NAT: [source] inside address: 10.0.2.25/32 outside address: 7.0.2.25/32 Static route: 7.0.2.25/32 [advertise] next hop: 10.0.2.1Um cliente remoto a enviar um ping para 7.0.2.25 a partir de 10.0.1.25 resultará em duas pesquisas de regras de firewall no Edge. O primeiro pacote de entrada resultará numa pesquisa de firewall para 10.0.1.25 > 7.0.2.25 e, depois, o primeiro pacote de retorno resultará numa pesquisa de regras de firewall ao utilizar o IP não NAT para 10.0.2.25 > 10.0.1.25. Esta segunda pesquisa de regras de firewall é feita por engano.
Sem esta correção, o utilizador teria de criar uma regra de firewall adicional para permitir o primeiro pacote de retorno do fluxo.
Problema 86617 resolvido: uma empresa de cliente que utiliza um endereço IP de retorno com Gateways de parceiro em que o BGP está configurado pode observar que o tráfego que deveria utilizar os caminhos de IP de retorno está a ser ignorado, o que resulta numa interrupção do tráfego de cliente.
Os caminhos do endereço IP de retorno estão em falta no VMware SD-WAN Edge, o que se deve a um cenário em que o BGP está configurado para o Edge e o Gateway de parceiro e um endereço IP de retorno é enviado para o Edge através do BGP, mas o Edge não aprende o caminho do IP de retorno.
Problema 86740 resolvido: ao executar o diagnóstico remoto “Estado da interface” (Interface Status), um módulo SFP do tipo GPON não aparece quando é implementado na interface SFP2 de um VMware SD-WAN Edge.
O problema é provocado por uma falha no script de back-end de diagnóstico remoto que é executado no Edge e não tem corretamente em consideração a interface SFP2 do Edge.
Problema 86808 resolvido: Alguns caminhos BGP são anunciados quando não o devem ser, de acordo com os filtros do BGP (ou não são anunciados quando deveriam ser).
Para uma determinada regra do mapa de caminhos, o Edge pode ter uma configuração de lista de prefixos ou de lista da comunidade para o encaminhamento do Edge com base no tipo de correspondência da regra. No entanto, para funções de anulação de aplicação do mapa de caminhos, o Edge está a tentar eliminar tanto a lista de prefixos como a lista da comunidade para cada regra, uma das quais tem de ser inexistente.
Anteriormente, esta situação não causava problemas, uma vez que os comandos para as listas de prefixos e/ou listas da comunidade inexistentes costumavam ser enviados para o processo de encaminhamento do Edge como um comando vtysh separado, que acabaria simplesmente por não ter operações e não afetaria os outros comandos. Nessa altura, esta foi uma decisão deliberada, uma vez que mantinha as coisas simples nas funções de anulação de aplicação do mapa de caminhos.
No entanto, como parte da correção do problema 84825, o Edge começou a criar lotes de vários comandos vtysh de remoção de listas de prefixos/listas da comunidade para serem enviados para o processo de encaminhamento do Edge. Agora, ao tentar eliminar a lista de prefixos/lista da comunidade inexistente faz com que todo o lote de comandos falhe e encha o Edge com configurações obsoletas de listas de prefixos/listas da comunidade no processo de encaminhamento do Edge.
Num Edge sem uma correção para este problema, um utilizador precisa de reiniciar o serviço Edge para garantir que todos os caminhos BGP são corretamente anunciados.
Problema 87304 resolvido: Se um utilizador desativar uma interface LAN num VMware SD-WAN Edge com a IU do VMware SASE Orchestrator, a interface 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 LAN do Edge (por exemplo, GE1 ou GE2). Como resultado, quando o SNMP sonda essas interfaces, devolve sempre um resultado de UP, independentemente da configuração das interfaces.
Problema 87552 resolvido: num site que utilize um Destino Não-SD-WAN (NSD) via Edge, o VMware SD-WAN Edge pode sofrer periodicamente uma falha do Serviço dataplane e reiniciar quando os túneis Edge para NSD estiverem instáveis.
Quando um túnel Edge para NSD estiver inativo, é executada a libertação incorreta de um túnel anteriormente escolhido, o que desencadeia uma exceção no Serviço dataplane do Edge e é necessário um reinício para restaurar o serviço. Reiniciar o serviço do Edge resultará numa interrupção de 10-15 segundos do tráfego do cliente.
Se o Edge utilizar uma compilação sem a correção, limitar um NSD via Edge a uma ligação WAN vai diminuir a probabilidade de este problema ocorrer.
Problema 87612 resolvido: para um VMware SD-WAN Edge com inserção VNF em uma ou mais VLANs, os utilizadores cliente nessas VLANs não conseguem obter endereços IP a partir de um servidor de reencaminhamento DHCP.
O Edge não está a encaminhar os pacotes de reencaminhamento DHCP e, portanto, os utilizadores clientes não estão a receber endereços IP.
Sem a correção, a única solução alternativa é desativar a inserção VNF na VLAN.
Problema 87982 resolvido: Um VMware SD-WAN Edge que utiliza um módulo SFP do tipo Metanoia com uma ligação PPPoE WAN privada pode não conseguir estabelecer um peering BGP e ligar-se a outros sites.
Os pacotes marcados da VLAN que utilizam uma ligação PPPoE privada são corrompidos pelo Edge e como resultado nunca chegam ao seu destino. Este problema não afeta as ligações públicas PPPoE.
Problema 88757 resolvido: Um utilizador que executa Diagnóstico remoto (Remote Diagnostic) > Esvaziar tabela de caminhos (Route Table Dump) na IU do Orchestrator pode constatar que a tentativa excede o tempo limite e a página não devolve resultados.
O diagnóstico Esvaziar tabela de caminhos (Route Table Dump) excede o tempo limite porque o tempo limite do WebSocket é de 30 segundos e, para um site com um número elevado de caminhos, o tempo que o comando de depuração demora a entregar todos os caminhos ao Orchestrator pode exceder esse limite. A correção consiste em reduzir o tempo limite do processo de esvaziamento de caminho para menos de 30 segundos e impedir que o WebSocket exceda o tempo limite antes disso, o que garante que o diagnóstico Esvaziar tabela de caminhos (Route Table Dump) irá devolver um resultado.
Problema 88796 resolvido: Ao implementar um VMware SASE Orchestrator ou um VMware SD-WAN Gateway e utilizar um OVA no vSphere, as propriedades do OVF definidas como parte da implementação (palavra-passe, informações de rede, etc.) não serão aplicadas à imagem e não será possível aceder ao sistema após a implementação.
Isto só afeta o novo sistema implementado a partir do OVA que utilize propriedades OVF/vApp (por oposição à utilização de ficheiros ISO). Este problema é causado por alterações a montante ao cloud-init em atualizações recentes.
Num Gateway sem a correção, a solução é o operador implementar o sistema com um ficheiro ISO de dados de utilizador cloud-init.
este pedido aberto aplica-se apenas às compilações do Gateway. O problema do Orchestrator é corrigido com a compilação da versão R5002-20220517-GA e posterior.
Problema 89217 resolvido: Um VMware SD-WAN Edge na linha de modelo 6x0 (610, 610N, 610-LTE, 620, 620N, 640, 640N, 680, 680N) pode desligar-se subitamente sem motivo.
O 6x0 Edge teria todas as luzes apagadas, tanto o LED de estado frontal como as luzes traseiras da porta Ethernet, e só pode ser recuperado através de um arranque manual do Edge.
A causa do problema tem origem num microcontrolador PIC, exclusivo da linha Edge 6x0, que utiliza a versão de firmware de PIC de v20M ou anterior (v20L, v20K, v20J). Este problema só pode ocorrer quando o Edge 6x0 utiliza uma versão de PIC de v20M ou anterior. Contudo, mesmo com esta versão, as probabilidades de se deparar com o problema de desligamento são raras (aproximadamente 1/1000). O problema não pode ocorrer num Edge 6x0 com uma versão de firmware de PIC de v20N ou posterior.
É possível determinar um firmware Edge 6x0 que inclua a versão de PIC num Orchestrator que utilize 5.x ao aceder à página Monitor > Edge > Visão geral (Monitor > Edge > Overview) desse Edge e clicar na caixa de informações pendente ao lado do nome do Edge que inclui as Informações do Edge, a versão do dispositivo e o firmware do dispositivo.
O problema resolve-se através da atualização do Edge 6x0 para o firmware de plataforma 1.3.1 (R131-20221216-GA), que inclui a versão de PIC v20N. Para isso, o Edge 6x0 tem de ser ligado a um VMware SASE Orchestrator com a versão 5.x (5.0.0 ou posterior) e tem primeiro de atualizar o Edge 6x0 para a compilação de correção do Edge R5012-20230123-GA-103475. Quando atualizar o Edge 6x0 para R5012-20230123-GA-103475, o utilizador deverá atualizar o firmware de plataforma do Edge 6x0 para a versão R131-20221216-GA da mesma forma que uma versão de software do Edge é modificada.
Para obter mais informações e um guia passo a passo para atualizar um Edge 6x0 para o firmware da plataforma 1.3.1, consulte o artigo da BDC: Os VMware SD-WAN Edges do modelo 6X0 podem desligar-se sem LEDs e exigir um ciclo de energia para voltarem a um estado funcional (88970). Este artigo da BDC foi atualizado a 27 de janeiro de 2023 para refletir o novo software do Edge e da plataforma necessário para resolver o problema.
Para obter informações sobre como carregar um pacote de firmware de plataforma para um Orchestrator, consulte a secção Imagens de firmware da plataforma e de fábrica com a nova IU do Orchestrator do Guia do Operador do VMware SD-WAN.
Para obter informações sobre como atualizar o firmware de plataforma de um Edge 6x0, consulte a secção Ver ou modificar as informações do Edge do Guia de Administração do VMware SD-WAN.
Se o utilizador preferir manter o Edge numa versão de software mais baixa (por exemplo, versão 4.3.1 ou 4.5.1), o cliente poderá atualizar temporariamente o Edge para R5012-20230123-GA-103475, atualizar o firmware da plataforma para a versão 1.3.1 (R131-20221216-GA), para que a versão do PIC seja v20N, e mudar para uma versão anterior preferida do software do Edge. A mudança do software do Edge 6x0 para uma versão anterior não muda a versão do firmware da plataforma do Edge para uma versão anterior e o Edge continuará a utilizar a versão de firmware da plataforma 1.3.1. Neste caso de utilização, os Edges do cliente teriam de estar num Orchestrator que utilizasse a versão 5.x.
Se o Edge 6x0 estiver num Orchestrator que não suporte a utilização da versão 5.x e tenha sofrido este problema e o respetivo firmware de PIC tiver de ser atualizado, o cliente poderá contactar o Suporte VMware SD-WAN, que atualizará manualmente a versão de PIC do Edge.
Problema 89873 resolvido: um utilizador pode observar um aumento da utilização da memória num VMware SD-WAN Edge, resultando num Evento de aviso de utilização de memória no Orchestrator e, potencialmente, num reinício não programado do Serviço Edge para recuperar a memória do Edge.
Este problema ocorre quando o UDP flui com um endereço IP único e as portas são processadas a uma taxa elevada no Edge. A criação do fluxo é processada de forma assíncrona no Edge e, quando vários pacotes de um mesmo fluxo são colocados na fila do serviço de criação do fluxo, os objetos de fluxo são vazados e resultam numa fuga de memória do Edge. O impacto é geralmente mais observado nos modelos Edge de nível de entrada (por exemplo, 510, 610 ou 620), que têm quantidades menores de memória do Edge. Contudo, durante um período suficiente, cada modelo Edge pode atingir um nível crítico de memória (utilização de memória de 60% por mais de 90 segundos) e ser reiniciado. Um reinício não planeado do Serviço Edge para limpar a memória pode provocar uma breve perturbação no tráfego do cliente.
Sem uma correção para este problema, a única forma de evitar que o mesmo afete os sites dos clientes é monitorizar a memória. Quando a utilização da memória atingir os 40% e o Orchestrator registar um Evento de aviso de memória, agende um reinício do Serviço Edge numa janela de manutenção para limpar a memória e garantir um impacto mínimo no cliente.
Problema 90151 resolvido: para o BGP através de IPsec no Gateway, aplicar diferentes filtros BGP aos vizinhos principais e secundários pode não funcionar como esperado.
Quando são aplicados filtros diferentes a um Destino Não-SD-WAN (NSD)-BGP nos vizinhos principais e secundários do VMware SD-WAN Gateway, apenas um é aplicado a ambos os vizinhos BGP.
O motivo deste problema é que, relativamente ao Gateway de parceiro (PG)-BGP, o serviço SD-WAN identifica os filtros BGP com uma combinação de enterprise_logical_id e segment_id e a utilização de enterprise_logical_id era suficiente para o Gateway de parceiro-BGP, porque, para uma determinada combinação de segmento/empresa, só poderíamos ter 1 vizinho PG-BGP.
No entanto, este método foi herdado para o NSD-BGP no Gateway, onde pode haver até 2 vizinhos BGP (principal e secundário) para a mesma combinação de segmento-empresa. Como resultado, a combinação enterprise_logical_id e segment_id não é suficiente para diferenciar entre filtros de 2 vizinhos NSD-BGP diferentes.
Problema 90283 resolvido: um cliente pode ter má qualidade de áudio e/ou vídeo em chamadas VoIP e de videotelefonia se a contabilização de underlay for ativada para a ligação WAN que está a ser utilizada no VMware SD-WAN Edge.
Ao verificar os registos, o utilizador pode observar pacotes para tráfego bidirecional em que o tráfego é assimetricamente encaminhado e um dos caminhos é pelo underlay. Por outras palavras, quando os caminhos de um fluxo são assimétricos de uma forma em que o tráfego segue por um caminho de underlay numa direção e utiliza um caminho de overlay na direção oposta e onde a contabilização de underlay está ativada para essa ligação WAN, poderá ocorrer perda de pacotes em fluxo bidirecionais, que são típicos de chamadas VoIP e de videotelefonia, mas não se limitam às mesmas.
Problema 90876 resolvido: O DNS falha num Segmento não global para um cliente à distância de um hop que esteja ligado a um VMware SD-WAN Edge por uma interface LAN ou por uma subinterface encaminhada sem um IP do Gateway.
A causa do problema difere dependendo do tipo de interface do Edge que o cliente à distância de um hop está a utilizar:
Se o cliente a um hop de distância estiver ligado a um Edge através de uma porta LAN, a resolução DNS falhará para o Segmento não global, dado que o Edge que encaminha o pacote de resposta para o cliente é a interface VCE1 e o processo do Edge trata-o como um segmento Global. Como resultado, o pacote de resposta é ignorado à medida que um caminho estático fica disponível na tabela de encaminhamento do Segmento global.
Se o cliente a um hop de distância estiver ligado a um Edge via uma porta de subinterface encaminhada que não tem um endereço IP de Gateway e um caminho estático para o cliente no Orchestrator, a resolução DNS falhará para o cliente, dado que o Edge não tem um caminho para o cliente. Este corresponde ao caminho ligado e envia um ARP para o próprio IP de destino, o ARP falha e a resposta não é enviada.
Para um Edge que não tem uma correção para este problema, a solução alternativa para um cliente que utiliza uma LAN do Edge é utilizar apenas o Segmento global. Para um cliente que utiliza uma subinterface encaminhada, a solução alternativa é indicar um endereço IP de Gateway e, se tal não for possível, utilizar apenas o Segmento global.
Problema 91875 resolvido: Para um cliente que tenha configurado uma ligação WAN como backup num VMware SD-WAN Edge, este pode observar que a ligação WAN de backup se torna ativa de forma intermitente, mesmo que as condições que exijam que a ligação se torne ativa não estejam presentes.
O problema é provocado por uma condição race num processo Edge que leva o Edge a considerar, erradamente, que a ligação WAN de backup é necessária e avança com a criação de um túnel para essa ligação, para a qual o Edge não tem uma contramedida para detetar e desmantelar este túnel errado.
Problema 93383 resolvido: Um VMware SD-WAN Edge pode sofrer uma ou mais falhas do serviço do dataplane com uma interrupção no tráfego do cliente.
O problema é provocado por uma rara instância de incompatibilidade no número de interfaces armazenadas no Edge em duas estruturas de dados diferentes, o que desencadeia uma exceção e resulta na falha do serviço do Edge uma ou mais vezes. O serviço Edge precisa de reiniciar para recuperar o que, numa implementação não HA, provocaria uma interrupção de 10 a 15 segundos do tráfego do cliente para cada reinício. No entanto, se o serviço do Edge falhar três vezes consecutivas, o Edge precisará de um reinício ou ciclo de energia para recuperar.
A compilação R5012-20221214-GA do Orchestrator foi lançada a 14-12-2022 e é o segundo rollup do Orchestrator para a versão 5.0.1.
Esta compilação rollup do Orchestrator aborda os problemas críticos abaixo desde a compilação R5011-20221129-GA do Orchestrator.
Problema 96538 resolvido: O Diagnóstico remoto “Mostrar caminhos aprendidos de vizinhos BGP” (Show BGP Neighbor Learned Routes) falha.
Um problema de interoperabilidade na chamada de API subjacente provoca erros de validação ao executar o Diagnóstico remoto “Mostrar caminhos aprendidos de vizinhos BGP” (Show BGP Neighbor Learned Routes).
Problema 100133 resolvido: O Orchestrator tem problemas de desempenho em cada configuração de Envio para Edge.
Quando um cliente configura um grande número de regras de política empresarial associando um cluster Edge, o Orchestrator tem problemas de desempenho em cada configuração de Envio para Edge.
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.
A compilação R5011-20221129-GA do Orchestrator foi lançada a 29-11-2022 e é o primeiro rollup do Orchestrator para a versão 5.0.1.
A compilação do Orchestrator R5011-20221129-GA substitui a compilação R5011-20221117-GA e corrige um problema de atualização detetado pela equipa de Operações de VMware ao efetuar a atualização de um Orchestrator para a compilação R5011-20221117-GA. O problema de atualização foi provocado por uma incompatibilidade de versão no pacote de atualização Manifest, e esta nova compilação não adiciona qualquer funcionalidade nova.
Esta compilação rollup do Orchestrator aborda os problemas críticos abaixo desde a compilação R5010-20220912-GA do Orchestrator.
Problema 80735 resolvido: quando um utilizador altera a configuração de um perfil que também está atribuído a um ou mais VMware SD-WAN Edges, os filtros do BGP ao nível do perfil são removidos.
O utilizador veria “ERRO: ref. de filtro inválida” (ERR: invalid filter ref) na IU do VMware SASE Orchestrator nos locais onde o utilizador anteriormente podia ver os detalhes do filtro BGP. O impacto para a rede de um cliente que depende do BGP seria significativo e a única forma de restaurar os filtros BGP seria restaurá-los manualmente.
Problema 88957 resolvido: A configuração de uma VLAN com uma sub-rede /30 não é implementada.
Depois de o utilizador configurar e aplicar uma sub-rede /30 para uma VLAN, o Orchestrator define automaticamente o intervalo de início do DHCP para x.x.x.1, em vez do correto x.x.x.2. Mesmo quando um utilizador substitui manualmente esta configuração ao alterar manualmente o intervalo de início do DHCP para .2, sempre que a configuração é carregada, o Orchestrator muda-a novamente para .1.
Problema 97713 resolvido: Quando um cliente analisa a tabela Monitorizar (Monitor) > Serviço de rede (Network Service) > Cluster Edge (Edge Cluster), não observa métricas estatísticas do estado de funcionamento do cluster Edge na IU do VMware SASE Orchestrator.
O problema resulta do facto de o cluster Edge estar a carregar as estatísticas para o Orchestrator e, ao fazê-lo, envia números que o Orchestrator não espera. O Orchestrator ignora todas as estatísticas do estado de funcionamento em vez de as armazenar na respetiva base de dados.
Problema 98086 resolvido: Um administrador parceiro com uma função de Especialista em TI, Apoio ao cliente ou Empresa não consegue ver estatísticas de caminhos na IU do VMware SASE Orchestrator.
O Orchestrator não disponibiliza privilégios para estas funções de Administrador parceiro e estes utilizadores não estão autorizados a ver quaisquer gráficos ou métricas no separador Estatística de caminho (Path Stats).
Problema 98357 resolvido: Quando um utilizador tenta adicionar um privilégio ALLOW incremental a uma função existente, falha com um erro.
Quando um utilizador está a tentar editar um pacote de personalização num Orchestrator 5.x para adicionar privilégios ALLOW para ações como Ver estatísticas de caminhos (View Path Stats), o pacote de personalização é rejeitado pelo Orchestrator.
O problema é provocado por um validador da API que apenas processa privilégios deny e não processa quaisquer privilégios allow.
Problema 98518 resolvido: Se um utilizador remover um VMware SD-WAN Gateway de um conjunto de gateways onde não existem clientes atribuídos, os clientes que utilizam os gateways de parceiros poderão observar que as configurações de handoff de parceiro também são removidas para vários gateways.
Quando um gateway é removido de um conjunto de gateways, o Orchestrator verifica a existência de handoffs e considera, erradamente, que alguns handoffs não estão a ser utilizados, quando estão. Isto resulta na anulação da definição do Orchestrator e, em seguida, na substituição das configurações de handoffs para esse gateway devido à constatação errada de que não existem configurações de handoffs em utilização.
Problema 98654 resolvido: Num VMware SASE Orchestrator atualizado para a versão 5.0.0.0 ou posterior, quando um VMware SD-WAN Edge é configurado para o modo CERTIFICADO NECESSÁRIO (CERTIFICATE REQUIRED), o Edge pode perder a comunicação com o Orchestrator e ser marcado como inativo após uma renovação de certificado.
A versão 5.0.0.0 do Orchestrator introduziu uma nova funcionalidade para verificar a Utilização alargada da chave dos certificados do cliente para Edges configurados como CERTIFICADO NECESSÁRIO (CERTIFICATE REQUIRED). Foi introduzido um defeito neste processo de verificação que, erroneamente, tratou os certificados válidos como inválidos e fez com que os heartbeats falhassem.
Problema 99109 resolvido: Quando um VMware SASE Orchestrator é atualizado para 5.0.0 ou posterior, os utilizadores numa empresa do cliente com uma implementação Zscaler existente não conseguem fazer alterações nas respetivas definições do Zscaler e obtêm o erro “A subscrição da cloud não pode ser nula e deve corresponder ao nome da cloud” (Cloud Subscription cannot be null and should match Cloud Name).
A versão 5.0.0 do Orchestrator apresenta um novo processo para Configurar subscrições da cloud para os clientes configurarem um novo serviço cloud, como o Zscaler. Como parte deste mecanismo adicional, quando o Orchestrator era atualizado para a versão 5.0.0/5.0.1, esperava-se que as implementações existentes fossem detetadas pelo Orchestrator e migradas automaticamente para a subscrição da cloud. No entanto, neste problema, isso não está a acontecer e um utilizador cliente é obrigado a configurar manualmente cada Edge do Zscaler com o novo método para Configurar subscrições da cloud para fazer quaisquer alterações à configuração do Zscaler existente.
Problema 99247 resolvido: Na empresa de um cliente que utilize um Serviço de segurança na cloud (CSS) onde o utilizador configura uma política empresarial para fazer backhaul do tráfego com a CSS, quando o VMware SASE Orchestrator é atualizado para a versão 5.0.0/5.0.1, o cliente observará que já não pode fazer alterações na configuração da CSS nos VMware SD-WAN Edges.
Ao analisar Configurar > Edge > Definições do dispositivo (Configure > Edge > Device Settings), o utilizador observará que a “Subscrição da cloud” (Cloud Subscription) está agora bloqueada e que a opção “Nenhuma” (None) está selecionada. Quaisquer tentativas de fazer uma alteração de configuração são devolvidas com um erro a indicar que “A subscrição da cloud não pode ser NENHUMA” (Cloud Subscription cannot be NONE). O utilizador também não conseguirá selecionar uma subscrição da cloud sem primeiro detetar a política empresarial de backhaul.
Problema 99250 resolvido: A temperatura do núcleo da CPU do VMware SD-WAN Edge não está representada corretamente no gráfico no VMware SASE Orchestrator.
Quando um utilizador analisa o separador Monitorizar (Monitor) > Edge > Sistema (System), observa que a temperatura do núcleo da CPU aparece sempre como 0°.
O Edge está a comunicar a temperatura do núcleo da CPU correta ao Orchestrator, mas o número está a ser ignorado devido a um problema de formatação e, na ausência de dados, o Orchestrator apresenta um valor predefinido de 0.
Problema 100656 resolvido: Quando um utilizador acede a Monitorizar (Monitor) > Edge > QoE na IU do VMware SASE Orchestrator, pode observar grandes lacunas no gráfico QoE do Edge.
O problema resulta do erro do VMware SASE Orchestrator numa função de repreenchimento quando não deteta dados de QoE no período de tempo de consulta de 15 minutos.
Problema 101449 resolvido: Se um utilizador configurar mais de 32 subinterfaces num VMware SD-WAN Edge com a versão 4.3.x ou posterior, o Orchestrator gerará um erro e impedirá a aplicação da configuração.
A restrição destina-se a proteger uma empresa de cliente com Edges a executar uma versão inferior a 4.3.x (por exemplo, 4.2.2 ou 3.4.6) e mais de 32 subinterfaces não são suportadas. Com esta alteração, o Orchestrator permitirá a configuração de mais de 32 subinterfaces e o cliente será alertado para fazer isto apenas se o Edge estiver a utilizar a versão 4.3.0 ou posterior.
A versão R5010-20220912-GA do Orchestrator foi lançada a 13-09-2022 e é a compilação GA do Orchestrator atualizada para a versão 5.0.1.
A compilação R5010-20220912-GA do Orchestrator atualizada resolve os problemas abaixo desde a compilação R5010-20220817 do Orchestrator.
Problema 96108 resolvido: Quando um VMware SASE Orchestrator é atualizado para uma compilação 5.x, um cliente pode observar estatísticas de utilização da memória em falta nos VMware SD-WAN Edges ao observar as páginas da IU Monitorizar > Edge (Monitor > Edge).
O problema é provocado durante a migração para um Orchestrator 5.x a partir de Edges mais antigos que enviam um nome diferente para o campo de memória das estatísticas de estado de funcionamento (memPct) quando o Orchestrator está à espera de receber o campo de memória das estatísticas de estado de funcionamento do Edge que utiliza o nome atual (memoryPct). Como resultado, o Orchestrator ignora o valor do campo de memória de estatísticas do estado de funcionamento do Edge enviado com o nome inesperado memPct e o Orchestrator predefine o valor do campo de memória de estatísticas do estado de funcionamento para zero.
A correção para este problema resolve as outras causas das estatísticas de estado de funcionamento do Edge em falta na IU do Orchestrator, sendo a primeira causa corrigida no 90749 na compilação 5.0.1 GA original.
Problema 96095 resolvido: Quando um VMware SASE Orchestrator está configurado para recuperação após desastre (DR), o endereço IP do Orchestrator IPv6 é eliminado de todos os perfis do operador e os SD-WAN Edges apenas de IPv6 são marcados como inativos pelo Orchestrator.
Se um Perfil do operador estiver configurado com um endereço IP do Orchestrator para o tipo IPv4 e IPv6, mas configura a DR utilizando apenas o endereço IPv4, o endereço IPv6 será removido do perfil do operador no Orchestrator. Isto faz com que os Edges apenas IPv6 deixem de comunicar com o Orchestrator, o que marcará esses Edges como inativos e deixará de enviar alterações de configuração para os mesmos.
Se este problema for encontrado num Orchestrator sem a correção, após a atualização a DR precisará de ser anulada e configurada novamente para que os endereços IP de gestão sejam restaurados.
Problema 95847 resolvido: Quando um VMware SASE Orchestrator é atualizado para a versão 5.0.1, o Operador que realiza a atualização pode observar que a atualização do esquema não foi bem-sucedida e deve ser novamente executada de forma manual.
Quando um Orchestrator é atualizado para uma versão com um novo esquema ClickHouse, existe o potencial de ocorrer uma condição race no back-end e a versão do esquema antigo não está ativa e pronta antes de ser atualizada. Como resultado, o Operador precisa de executar novamente e manualmente a atualização do esquema.
A versão R5010-20220817-GA do Orchestrator foi lançada a 17-08-2022 e é a compilação GA do Orchestrator atualizada para a versão 5.0.1.
Esta compilação substitui a compilação GA original R5010-20220803-GA, que incluiu o problema 95613. Este problema foi detetado durante uma atualização do Orchestrator depois de esta compilação ter sido lançada em 05-08-2022. Os clientes só devem utilizar a compilação R5010-20220817-GA e não utilizar a R5010-20220803-GA.
Problema 95613 resolvido: Quando um VMware SASE Orchestrator é atualizado para a compilação R5010-20220803-GA, um cliente ligado a esse Orchestrator pode ter dificuldade em monitorizar os respetivos Edges e, se utilizar chamadas à API, observa que essas chamadas falham. O utilizador operador observaria que o processo da API falha e exigiria um reinício juntamente com uma elevada utilização da CPU no Orchestrator.
Este problema é desencadeado por um utilizador que configura a respetiva empresa para fazer chamadas à API sem qualquer intervalo de tempo (por outras palavras, cada chamada à API é imediatamente seguida por outra). Esta atividade faz com que o processo da API v2 que trata da chamada à API se depare com uma exceção e falhe quando recebe o pedido da API. A falha do processo da API v2 significa que a monitorização do Edge para dados como estatísticas de ligações (que se baseia em chamadas à API) não apresentará dados precisos e as empresas dos clientes que utilizam as chamadas à API também teriam falhas nas mesmas. Além disso, se a mesma empresa continuar a fazer chamadas à API sem intervalo de tempo, o processo da API v2 ficará efetivamente bloqueado num ciclo de falha e reinício até que essas chamadas à API possam ser interrompidas ou modificadas para incluir um intervalo de tempo.
A falha e o reinício do processo da API v2 também causa elevado consumo de CPU do Orchestrator, o que afetará o desempenho global do Orchestrator, para além de lidar com as chamadas à API.
A versão R5010-20220803-GA do Orchestrator foi lançada em 05-08-2022 e resolve os seguintes problemas desde a versão do Orchestrator 5002-20220517-GA. Isto significa que uma correção para qualquer problema do Edge ou Gateway listada nas notas de versão 5.0.0 está incluída em todas as compilações da versão 5.0.1.
Problema 49535 resolvido: na página Monitorizar > Serviços de rede (Monitor > Network Services), o VMware SASE Orchestrator não atualiza imediatamente o estado do vizinho BGP de um VMware SD-WAN Edge que ficou offline.
A tabela Estado de vizinho Edge BGP (BGP Edge Neighbor State) continua a apresentar o Edge offline como “Estabelecido” (Established) e permanece assim durante horas após o Edge ficar offline. Isto tem impacto em qualquer utilizador que dependa da IU do Orchestrator para verificar estes detalhes.
Problema 68463 resolvido: Ao observar o gráfico Monitorizar > QoE (Monitor > QoE) no VMware SASE Orchestrator em que a secção do gráfico é apresentada como amarelo/aceitável quanto a qualidade, pode existir uma discrepância entre o motivo pelo qual a secção do gráfico é apresentada como amarelo/aceitável ao verificar a IU clássica em comparação com a nova IU.
Perante este problema, na IU clássica, se a caixa de pop-up indicar Latência (Latency) como o motivo da classificação QoE aceitável, a nova IU terá uma caixa de pop-up a indicar Distorção (Jitter) como o motivo da classificação QoE aceitável. O problema é provocado por um mapeamento incorreto dos valores de Latência (Latency) e Distorção (Jitter) na nova IU.
Problema 70005 resolvido: ao utilizar o VMware Cloud Web Security, um utilizador pode editar uma Política de segurança existente e mudar o nome da mesma para um nome em branco ou vazio e guardá-la na VMware SASE Orchestrator.
Um utilizador não pode criar uma Política de segurança com um nome vazio/em branco, mas pode editar uma política existente para configurar o nome de modo a que fique em branco e o Orchestrator permite a mudança e não emite nenhum erro.
Problema 76036 resolvido: Tentar aceder à página “Visão geral do parceiro” (Partner Overview) e/ou a uma página “Configurar > Cliente” (Configure > Customer) para esse Parceiro num VMware SASE Orchestrator não consegue carregar e apresenta a mensagem “Ocorreu um erro inesperado” (An unexpected error has occurred).
O carregamento da página Visão geral do Parceiro(Partner Overview) e/ou de uma página Configurar > Cliente (Configure > Customer) para um cliente suportado por esse parceiro pode falhar porque a API enterpriseProxy /getEnterpriseProxyGatewayPools excede o limite de tempo. O que origina o não carregamento destas páginas é a inclusão de um elevado número de Gateways e conjuntos de Gateways, o que pode levar ao excedimento do limite de tempo da API enterpriseProxy /getEnterpriseProxyGatewayPools utilizada na página, causando o problema de carregamento de página para cada página da IU.
Problema 76036 resolvido: Tentar aceder à página “Visão geral do parceiro” (Partner Overview) e/ou a uma página “Configurar > Cliente” (Configure > Customer) para esse Parceiro num VMware SASE Orchestrator não consegue carregar e apresenta a mensagem “Ocorreu um erro inesperado” (An unexpected error has occurred).
O carregamento da página Visão geral do Parceiro(Partner Overview) e/ou de uma página Configurar > Cliente (Configure > Customer) para um cliente suportado por esse parceiro pode falhar porque a API enterpriseProxy /getEnterpriseProxyGatewayPools excede o limite de tempo. O que origina o não carregamento destas páginas é a inclusão de um elevado número de Gateways e conjuntos de Gateways, o que pode levar ao excedimento do limite de tempo da enterpriseProxy /getEnterpriseProxyGatewayPools API utilizada na página, causando o problema de carregamento de página para cada página da IU.
Problema 81835 resolvido: a página Monitorizar > Edge > QoE (Monitor > Edge > QoE) da IU do VMware SASE Orchestrator pode não representar com precisão o estado de uma ligação WAN (seja online, offline ou degradada) ou representar com precisão as métricas da ligação para o período selecionado.
Intervalos de tempo diferentes podem fazer com que o gráfico QoE apresente resultados diferentes para o estado de uma ligação WAN. E, para as métricas de uma ligação, o gráfico QoE pode apresentar um valor QoE específico (latência, perda ou distorção) que não reflete o valor da métrica real nessa hora exata.
Este problema é provocado pelo facto de estar a ser atribuído o mesmo ID lógico de ligação a várias ligações WAN pertencentes a diferentes empresas, o que causa uma falha no processo de pós-aprovisionamento dos dados da ligação do Orchestrator. O Orchestrator assume erradamente que o ID lógico de ligação WAN é exclusivo porque não está ligado ao ID da empresa de um cliente. Isto permite duplicar os IDs lógicos de ligação e a possibilidade de métricas e estados de ligação incorretos.
A correção para este problema armazena as chaves da ligação na base de dados do Orchestrator como uma combinação do ID lógico da empresa do cliente e do ID lógico da ligação WAN, o que garante que cada ligação WAN é exclusiva.
Problema 82725 resolvido: Um VMware SASE Orchestrator pode não gerar corretamente a ligação de reposição da palavra-passe.
Este problema ocorre quando o URL para o Orchestrator não é exatamente https://domain/ ou https://domain/operator/. No entanto, se, por exemplo, o URL for https://domain/test/ a hiperligação de redefinição da palavra-passe não funciona e direciona-o de volta para a página de início de sessão.
Ao encontrar este problema num Orchestrator sem a correção, se o URL do Orchestrator não puder ser corrigido para um URL conforme apresentado acima, a única opção é que um Superutilizador ou Operador introduza manualmente uma nova palavra-passe para o utilizador e, em seguida, partilhe-a com o utilizador afetado para que possa, por sua vez, reconfigurar uma palavra-passe diferente para si mesmo uma vez que tenha iniciado a sessão com sucesso.
Problema 82775 resolvido: num VMware SASE Orchestrator que utiliza a versão 5.0.0, quando um Serviço de Segurança na Cloud (CSS) do tipo Zscaler é configurado para um cliente e associado a um VMware SD-WAN Edge e, em seguida, uma política empresarial é configurada com uma regra de backhaul CSS, um utilizador não consegue alterar os parâmetros de hash ou encriptação CSS para esse CSS.
O Orchestrator impede o utilizador de modificar a configuração Zscaler CSS após a associação a uma Política empresarial de Backhaul CSS.
Num Orchestrator sem uma correção para este problema, o utilizador tem de eliminar a Política empresarial de Backhaul CSS para modificar a configuração Zscaler CSS e, em seguida, recriar a mesma Política empresarial.
Problema 82864 resolvido: Num VMware SASE Orchestrator que utilize a versão 5.0.0, quando um utilizador está na página Configurar > Perfis (Configure > Profiles) e selecionar “Modificar” (Modify), será redirecionado para a página Perfil > Visão geral (Profile > Overview) em vez da página Perfil > Definições do dispositivo (Profile > Device Settings).
O botão Configurar > Perfis (Configure > Profiles) “Modificar” (Modify) não está a mapear para a página correta.
Problema 83165 resolvido: um utilizador operador não consegue transferir um Cliente para um Parceiro no VMware SASE Orchestrator com a indicação de não terem o mesmo Conjunto de Gateways, apesar de terem.
Este problema é causado por uma chamada da API network/getNetworkEnterpriseProxies que não devolve os detalhes do Conjunto de Gateways e que faz com que o Orchestrator pense que o Parceiro e o Cliente não têm o mesmo Conjunto de Gateways e rejeite a atribuição.
Problema 83538 resolvido: para clientes que utilizam o serviço Secure Access, quando criam um serviço de Acesso remoto, o ecrã Definições da rede e da empresa (Enterprise & Network Settings) mostra chaves de mensagem de erro interno no VMware SASE Orchestrator.
Ao criar um serviço de acesso remoto, se o utilizador introduzir dados inválidos nos campos Sub-rede de cliente (Customer Subnet) ou Bits de sub-rede (Subnet bits) será apresentada uma mensagem de erro não traduzida abaixo destes campos. Esta mensagem de erro não é útil para o utilizador e não encaminha para a solução do problema real relativamente a dados inválidos em qualquer um dos campos.
Problema 83539 resolvido: num VMware SASE Orchestrator implementado com uma configuração de Recuperação após desastre (DR), quando o Orchestrator é atualizado para a nova versão de software, a sincronização da DR falha.
A DR funciona corretamente antes da atualização, mas quando um utilizador operador atualiza os Orchestrators ativos e em standby, o estado da DR é apresentado como falhado.
Problema 83582 resolvido: ao atualizar um VMware SASE Orchestrator da versão 4.5.0 para a versão 5.0.0, o processo demora muito mais do que o esperado e todos os serviços do Orchestrator estão indisponíveis até o processo ser concluído.
A atualização do esquema pode demorar mais de 15 minutos para que a tabela de estatísticas do Edge seja atualizada durante a atualização, quando deveria ser atualizado o esquema LRQ. Esta situação causa um grande atraso na conclusão da atualização do Orchestrator.
Problema 83822 resolvido: para os clientes que utilizam o VMware Cloud Web Security, ao consultar Monitorizar > Registos > Registos Web (Monitor > Logs > Web Logs) no VMware SASE Orchestrator, o utilizador só conseguirá ver um máximo de 100 registos e não conseguirá carregar mais páginas para ver registos adicionais.
Com este problema, o utilizador fica limitado a utilizar um máximo de 100 registos numa única página sem conseguir visualizar registos adicionais, dado que a paginação é interrompida nos Registos Web na IU do Orchestrator. Este é um grande obstáculo para os utilizadores, dado que ignifica que se quiserem carregar um grande período de tempo (por exemplo, 30 dias), não conseguirão ver todos os registos para esse período. A única solução alternativa é carregar curtos períodos de tempo que devolvam 100 ou menos registos.
Problema 84152 resolvido: Quando um cliente gera um relatório Talkers principais para a respetiva empresa, os nomes dos Talkers principais podem ser listados como “Desconhecidos”.
Os “Talkers principais” são as principais origens de todos os fluxos num determinado intervalo de tempo. O nome do Talker principal poderá não aparecer se o dispositivo cliente não estiver presente para o par exclusivo (IP de origem + Endereço MAC). Isto acontece porque os dispositivos clientes são guardados com base no Modo de visibilidade (Endereço IP ou Endereço MAC) configurado para o VMware SD-WAN Edge. Por exemplo, um Orchestrator pode guardar um dispositivo para (Endereço IP 1, Endereço MAC 1). Assim, o registo (Endereço IP 2, Endereço MAC 2) não será guardado se o Modo de visibilidade (Visibility Mode) estiver definido como Endereço IP (IP Address). Isto faria com que o Talker principal correspondente ao Endereço IP 2/Endereço MAC 2 fosse marcado como “Desconhecido”.
Problema 84214 resolvido: Quando um utilizador operador estiver na página Gateways da IU de um VMware SASE Orchestrator, poderá não conseguir atribuir um Gateway em particular para a função Super Gateway.
Quando um Gateway já está atribuído à função Super e à função Super Gateway alternativo, se o operador tentar editar a atribuição do Super Gateway de uma empresa na lista Utilização do cliente (Customer Usage) no ecrã Gateways > Configurar Gateways (Configure Gateways), a IU não encontrará corretamente os dados associados ao Super Gateway e a caixa de diálogo Atribuir Super Gateway (Assign Super Gateway) não será apresentada e apresentará um erro na consola.
Problema 84969 resolvido: Quando um VMware SD-WAN Edge que execute a versão 4.2.x e que também esteja configurado com um IP de gestão não predefinido substituído é atualizado para a versão 4.3.x ou superior num VMware SD-WAN Orchestrator com a versão 4.3.x ou superior, o Edge pode perder o IP de gestão substituído configurado.
Um Orchestrator com a versão 4.3.x ou superior não está automaticamente a criar a interface de retorno, enquanto mantém também o IP de gestão não predefinido substituído para um Edge quando esse Edge é atualizado da versão 4.2.x para uma versão 4.3.x ou uma compilação posterior.
Problema 86546 resolvido: para clientes que utilizam o VMware Secure Access, um utilizador pode não conseguir utilizar o Secure Access em alguns PoPs SASE e outros podem até ser apresentados como offline no VMware SASE Orchestrator.
Os Gateways VMware que não estão configurados para utilização com o Secure Access (por outras palavras, Gateways que não possuem um túnel Geneve com o servidor de túnel no PoP) também recebem informações sobre o serviço Secure Access pelo Orchestrator. Isto leva à escolha de um caminho inválido em alguns casos para encaminhar o tráfego de cliente. Este problema apenas pode ser encontrado quando mais de um Gateway é atribuído por PoP por Conjunto de Gateways num Orchestrator específico.
Num Orchestrator que não possui a correção para este problema, a solução alternativa é adicionar e manter apenas um Gateway por PoP em cada Conjunto de Gateways, para que esse Gateway seja sempre escolhido pelo Secure Access e para o estabelecimento do caminho correto.
Problema 86848 resolvido: quando um administrador do cliente faz uma tentativa de início de sessão falhada através do método Nativo (nome de utilizador/palavra-passe) na empresa do cliente no VMware SASE Orchestrator, o Orchestrator não regista a tentativa falhada na página Monitorizar > Eventos (Monitor > Events) da IU.
O Orchestrator deve registar todas as tentativas de início de sessão, quer sejam bem-sucedidas ou não, de modo a garantir a devida responsabilização de todas as contas de utilizador e para que todos os administradores possam detetar atividades de início de sessão invulgares. O problema é causado pelo facto de o Orchestrator não incluir os metadados enterpriseId numa tentativa falhada de autorização de nome de utilizador/palavra-passe. Isto afeta apenas os utilizadores de clientes que utilizam a autorização Nativa (nome de utilizador/palavra-passe). As empresas de clientes que utilizam o início de sessão único (SSO) não são afetadas por este problema.
Problema 87111 resolvido: quando um VMware SASE Orchestrator é atualizado para a versão 4.3.x ou posterior, os VMware SD-WAN Edges ligados ao Orchestrator que estão configurados para utilizar o BGP não têm a flag de uplink configurada.
A flag de uplink BGP é adicionada como uma configuração na versão 4.3.0 do SD-WAN e as versões 4.3.0 e posteriores do Edge estão à espera que esteja presente uma flag de uplink. No entanto, o Orchestrator não está a enviar a atualização da configuração para todos os Edges que não possuem esta flag após ser atualizado.
Problema 88621 resolvido: Não é possível modificar nem guardar a configuração de um VMware SD-WAN Gateway em migração no VMware SASE Orchestrator.
Um utilizador operador não consegue atualizar a localização de um Gateway de produção, uma vez que, quando tenta guardar a configuração, o Orchestrator devolve o erro: GATEWAY_SERVICE_STATE_INVALID: Cannot change the state of the gateway to null, as it is already used as a replacement gateway.
Problema 89346 resolvido: Num VMware SASE Orchestrator que utilize a compilação 5.0.0.2, ao gerar um novo relatório no ecrã Monitorizar clientes (Monitor Customers), o relatório recém-gerado é sempre entregue em inglês, mesmo que o idioma do relatório tenha sido especificado como uma língua não inglesa.
O relatório transferido deve ser apresentado no idioma especificado em Idioma do relatório (Report Language), mas o idioma utilizado é sempre o inglês.
Problema 89800 resolvido: quando um utilizador atualiza a Propriedade do segmento (Segment Property) no VMware SASE Orchestrator, os túneis Edge para o Serviço de Segurança na Cloud Zscaler (CSS) ficam inativos e o tráfego encaminhado para o Zscaler é descartado.
Se um utilizador tiver um CSS configurado em Configurar > Serviço de rede (Configure > Network Service) (qualquer tipo de CSS) e, em seguida, configurar os detalhes de autenticação FQDN e PSK em Configurar > Edge > Dispositivo (Configure > Edge > Device) > Cloud Security Service com a Anulação de Edge (Edge Override), quando o utilizador atualizar qualquer segmento na secção Configurar > Segmento (Configure > Segment) do Orchestrator, a configuração de autenticação CSS do Edge será eliminada e o Edge já não conseguirá estabelecer ligação ao par Zscaler.
Problema 90128 resolvido: na empresa de um cliente que tenha um Cloud Security Services (CSS) configurado, quando o utilizador altera a configuração do CSS, o evento CSS inclui a chave PSK do CSS.
Embora este comportamento não crie uma vulnerabilidade direta, o valor PSK do CSS é uma informação confidencial que não deve ser incluída num ficheiro de registo.
Problema 90540 resolvido: num VMware SASE Orchestrator que utilize a versão 5.0.0, quando um VMware SD-WAN Edge com a versão do Edge 4.5.1 é atualizado para a versão 5.0.0, o Edge perde a funcionalidade DNS e sofre uma perda de conectividade à Internet.
Como parte da atualização do Edge para 5.0.0, a função do Orchestrator é enviar uma configuração do Edge atualizada e a parte do DNS dessa configuração não era compatível com uma compilação 4.5.x do Edge, levando à perda da definições de DNS e impedindo a conectividade à Internet. O Edge continuaria a passar o tráfego para outros locais (por exemplo, o Orchestrator, outros Edges, Hub Edges e Destinos Não-SD-WAN), onde o DNS não é um fator.
Problema 90067 resolvido: quando um VMware SASE Orchestrator é atualizado para 4.5.1 ou 5.0.0, o Operador pode observar problemas de utilização e carga de CPU elevada.
Durante a atualização, o Orchestrator perde uma propriedade crítica do sistema: edge.learnedRoute.maxRoutePerCall.. Esta propriedade limita o número de eventos do protocolo de encaminhamento que podem ser recebidos pelo Orchestrator num dado momento. Na ausência desta propriedade, um Orchestrator poderia ser inundado com eventos do protocolo de encaminhamento que o colocam sob carga elevada podendo afetar o desempenho do Orchestrator. A correção garante que a propriedade do sistema edge.learnedRoute.maxRoutePerCall persiste após as atualizações do Orchestrator.
Problema 90749 resolvido: Quando um VMware SASE Orchestrator é atualizado para uma compilação 5.x, um cliente pode observar uma perda das estatísticas do histórico para um ou mais dos seus Edges do VMware SD-WAN ao observar as páginas da IU Monitorizar > Edge (Monitor > Edge).
Nos registos do Orchestrator, um Operador deveria observar as mensagens de registo “Erro ao migrar estatísticas de estado de funcionamento” (Error while migrating health stats) e “Erro ao escrever o ficheiro de dados para clickhouse” (Error while writing data file to clickhouse) com carimbos de data/hora imediatamente após o Orchestrator ser atualizado para uma compilação 5.x. O problema é acionado durante a atualização do Orchestrator por um Edge que envia quaisquer dados inválidos (por exemplo, uma contagem de túnel inválida com um número negativo) para o Orchestrator, o que resulta no Orchestrator rejeitar não só os dados inválidos, mas todo o lote de dados do histórico para esse Edge em particular. Como resultado, o utilizador observa grandes lacunas nos históricos de tempo nos gráficos para esse Edge ao observar as páginas Monitorizar > Edge (Monitor > Edge) após a atualização do Orchestrator. O problema não afeta de forma uniforme todos os Edges ligados ao Orchestrator, apenas o número reduzido que envia dados inválidos.
Existe um problema 96108 relacionado que também provoca estatísticas de estado de funcionamento do Edge em falta e que é corrigido na compilação do Orchestrator R5010-20220912-GA.
Problema 90835 resolvido: num cliente que utiliza o serviço VMware Cloud Web Security, o utilizador não pode configurar as regras de domínio do Office 365 para o proxy Web no Cloud Web Security com o VMware SASE Orchestrator.
O utilizador não pode configurar as regras de domínio do Office 365 (cujo nome foi recentemente alterado para Microsoft 365) para o proxy Web no Cloud Web Security com o assistente de ficheiro PAC.
Problema 91054 resolvido: Para um cliente que utilize o VMware Cloud Web Security, um utilizador pode encontrar múltiplos problemas de usabilidade na IU do VMware SASE Orchestrator ao tentar configurar a autenticação de início de sessão único.
Os problemas que um utilizador pode encontrar ao configurar o início de sessão único no serviço Cloud Web Security incluem:
• Erros de certificado que aparecem na página principal Autenticação (Authentication) em vez de na página Certificado (Certificate).• Por vezes, um utilizador pode guardar um certificado inválido.• A alteração de um certificado pode, por vezes, repor os outros valores no formulário de autenticação.• Os campos individuais não mostram mensagens de validação em linha com o campo.• Ao guardar a página Autenticação (Authentication), a IU do Orchestrator não mostra a roda giratória de progresso.• A descrição de depuração verbosa mostra “t+2h” em vez de uma hora real.• Em certos idiomas, a etiqueta do botão Início de sessão único (Single Sign-On) ocupa mais de uma linha.• O esquema do rodapé Guardar alterações (Save Changes) não é apresentado corretamente em ecrãs pequenos.
Todos os problemas listados estão resolvidos nos Orchestrators que incluam uma correção para o problema 91054.
Problema 91179 resolvido: para um VMware SD-WAN Edge que tem uma ligação WAN configurada como reserva dinâmica, se o estado da ligação da reserva dinâmica for Standby, a nova IU do VMware SASE Orchestrator apresenta o estado incorreto para a ligação da reserva dinâmica (Ativa).
A IU clássica do Orchestrator apresenta o estado correto da ligação (Inativa), pelo que este problema está limitado apenas à nova IU. O problema é provocado pela nova IU não obter a atualização correta sobre a alteração de estado de uma ligação WAN de reserva dinâmica.
Problema 91720 resolvido: nas empresas de clientes que utilizem uma topologia Hub/Spoke, os utilizadores podem remover um VMware SD-WAN Hub Edge da configuração do Hub de backhaul, mesmo que esse Hub esteja a ser utilizado com uma política empresarial configurada para utilizar o backhaul da Internet.
Uma vez configurada uma política empresarial para efetuar o backhaul do tráfego do Edge Spoke através de um Edge Hub, o comportamento esperado é que o VMware SASE Orchestrator “bloqueie” esse Edge Hub e impeça um utilizador de o remover da configuração do Hub de Backhaul na secção Configurações > Definições do dispositivo (Configure > Device Settings). No entanto, com este problema, o utilizador pode remover o Edge Hub e provocar uma perturbação significativa no tráfego do cliente.
Problema 92082 resolvido: um cliente que utilize o VMware Cloud Web Security pode observar que as regras de filtragem de conteúdos não honram o domínio configurado.
As regras de filtragem de conteúdos substituem o domínio configurado fornecido se o utilizador tiver também selecionado TODAS em Categorias. Ou se o utilizador selecionar NENHUMA em Categorias, o assistente predefiniu esta escolha para significar TODAS as Categorias, daí que os domínios não foram honrados aqui também. Isto é provocado por um problema no assistente de filtragem de conteúdos e na API. Se o utilizador configurar, pelo menos, uma Categoria, o Domínio é honrado.
Num Orchestrator sem esta correção, o utilizador teria de configurar categorias específicas juntamente com domínios e, então, o Orchestrator honraria os domínios na filtragem de conteúdos.
Problemas pendentes na versão 5.0.1.
Problema 14655:
Ligar ou desligar um adaptador SFP pode fazer com que o dispositivo pare de responder no Edge 540, Edge 840 e Edge 1000 e exija um reinício físico.
Solução alternativa: o Edge deve ser reiniciado fisicamente. Este procedimento pode ser realizado no Orchestrator utilizando Ações Remotas > Reiniciar Edge (Remote Actions > Reboot Edge) ou através do ciclo de ativação do Edge.
Problema 25504:
Custos do caminho estático superiores a 255 podem resultar numa ordenação de caminho imprevisível.
Solução alternativa: Utilize um custo de caminho entre 0 e 255.
Problema 25595:
Poderá ser necessário um reinício para que as alterações ao SLA estático num overlay WAN funcionem corretamente.
Solução alternativa: reinicie o Edge após adicionar e remover o SLA estático do overlay WAN.
Problema 25742:
O tráfego contabilizado de underlay está limitado à capacidade máxima do VMware SD-WAN Gateway, mesmo que seja inferior à capacidade da ligação WAN privada que não está ligada ao Gateway.
Problema 25758:
As ligações WAN USB podem não ser corretamente atualizadas quando são trocadas de uma porta USB para outra, até que o VMware SD-WAN Edge seja reiniciado.
Solução alternativa: reinicie o Edge após mover as ligações WAN USB de uma porta para outra.
Problema 25855:
uma grande atualização de configuração no Gateway de parceiro (por exemplo, 200 VRFs configurados por BGP) pode provocar um aumento da latência durante cerca de 2 a 3 segundos para algum tráfego através do VMware SD-WAN Gateway.
Solução alternativa: nenhuma solução alternativa disponível.
Problema 25921:
A recuperação automática do VMware SD-WAN Hub de alta disponibilidade demora mais do que o esperado (até 15 segundos) quando existem três mil Edges de ramo ligados ao Hub.
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, irá retirá-los com sucesso.
Problema 32960:
O estado da interface de “Negociação automática” (Autonegotiation) e “Velocidade” (Speed) pode ser apresentado incorretamente na IU de Web Local para os VMware SD-WAN Edges ativados.
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.
Problema 34254:
Quando o CSS Zscaler é criado e o segmento global tem definições de FQDN/PSK configuradas, estas definições são copiadas para segmentos não globais para formar túneis IPsec para um CSS Zscaler.
Problema 35778:
Quando existem múltiplas ligações WAN definidas pelo utilizador numa única interface, apenas uma dessas ligações WAN pode ter um túnel GRE para o Zscaler.
Solução alternativa: utilize uma interface diferente para cada ligação WAN que precisa de criar túneis GRE para o Zscaler.
Problema 36923:
O nome do cluster não pode ser atualizado corretamente na descrição da interface de NetFlow para um VMware SD-WAN Edge que está ligado a esse Cluster como o seu Hub.
Problema 38682:
Um VMware SD-WAN Edge que atua como um servidor DHCP numa interface configurada por DPDK pode não gerar corretamente eventos de “Novo dispositivo de cliente” para todos os clientes ligados.
Problema 38767:
Quando um overlay WAN que tenha túneis GRE configurados para o Zscaler é alterado da deteção automática para definido pelo utilizador, os túneis obsoletos podem permanecer até ao próximo reinício.
Solução alternativa: reinicie o Edge para limpar o túnel obsoleto.
Problema 39134:
A estatística de estado de funcionamento do Sistema “Percentagem de CPU” (CPU Percentage) pode não ser comunicada corretamente em Monitorizar > Edge > Sistema (Monitor > Edge > System) para o VMware SD-WAN Edge e em Monitorizar > Gateways (Monitor > Gateways) para o VMware SD-WAN Gateway.
Solução alternativa: os utilizadores devem utilizar as Handoff Queue Drops para monitorizar a capacidade do Edge e não a percentagem de CPU.
Problema 39374:
alterar a ordem dos Gateways de parceiro do VMware SD-WAN atribuídos a um VMware SD-WAN Edge pode não definir corretamente o Gateway 1 como o Gateway local a ser utilizado para o teste de largura de banda.
Problema 39608:
A saída do “Teste de Ping” (Ping Test) de Diagnóstico Remoto pode apresentar brevemente conteúdos inválidos, antes de apresentar os resultados corretos.
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.
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 de iniciação de IKE a um par Não-SD-WAN. Este problema não perturba o tráfego do utilizador para o Gateway; no entanto, os registos do Gateway 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 suportados por 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.
Nota: os túneis que utilizam a autenticação de chave pré-partilhada (PSK) não têm este problema.
Problema 51436: num local que utilize uma topologia de Alta Disponibilidade melhorada ao implementar um VMware SD-WAN Edge com um modem LTE, se o local entrar num estado duplo (split-brain), a recuperação automática de HA demorará cerca de 5 a 6 minutos.
Como parte da recuperação de um estado duplo (split-brain), as portas LAN são inativadas no Edge ativo e isto tem impacto sobre o tráfego LAN durante o tempo em que as portas estão inativas e até que o local consiga recuperar.
Solução alternativa: Não existe uma solução alternativa para este problema.
Problema 52955: A recusa DHCP não é enviada a partir do Edge e o reenlace do DHCP não é reiniciado após a falha do DAD no DHCP Dinâmico.
Se o servidor DHCPv6 atribuir um endereço que é detetado como duplicado pelo kernel durante uma verificação DAD, o cliente DHCPv6 não enviará nenhuma recusa. Isto levará a tráfego ignorado, uma vez que o endereço de interface será assinalado como verificação DAD falhada e não será utilizado. Esta ação não levará a nenhum ciclo de tráfego na rede, mas será observado um bloqueio de tráfego.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 53219: Após um reequilíbrio do cluster do VMware SD-WAN Hub, alguns Spoke Edges podem não ter a interface RPF/IIF com a definição correta.
Nos Spoke Edges afetados, o tráfego multicast será afetado. O que acontece é que depois de um reequilíbrio do cluster, alguns dos Spoke Edge não enviam uma junção PIM.
Solução alternativa: este problema persistirá até que o Edge Spoke afetado reinicie o Serviço Edge.
Problema 53337: os pacotes ignorados podem ser observados numa instância do AWS de um VMware SD-WAN Gateway quando o débito é superior a 3200 Mbps.
Quando o tráfego excede um débito superior a 3200 Mbps e um tamanho de pacote de 1300 bytes, são observados pacotes ignorados no handoff do IPv4 BH e RX.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 53359: A sessão BGP/BFD pode falhar durante alguns cenários de ataque DDoS.
Se ocorrer um flood de tráfego no cliente ligado à interface encaminhada para o cliente LAN, a sessão BGP/BFD poderá falhar. Adicionalmente, quando ocorre um flood de tráfego de alta prioridade em tempo real para o destino de camada superior, a sessão BGP/BFD pode falhar.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 53830: Num VMware SD-WAN Edge, alguns dos caminhos na vista BGP podem não ter os valores de preferência e anúncio corretos quando a flag DCC está configurada, provocando uma sequência de ordenação incorreta no FIB do Edge.
Quando o cálculo de custos distribuídos (DCC) é configurado num cenário dimensionado com um grande número de caminhos num Edge, ao analisar o pacote de diagnóstico do Edge para o registo bgp_view, alguns dos caminhos podem não ser corretamente atualizados com os valores de preferência e anúncio. Este problema, caso seja encontrado, pode potencialmente ser encontrado em alguns Edges que fazem parte de uma grande empresa (mais de 100 Spoke Edges ligados a Edges Hub ou Clusters de Hub).
Solução alternativa: este problema pode ser corrigido reaprendendo os caminhos BGP de underlay ou realizando uma opção de “Atualização” (Refresh) na página OFC do VMware SD-WAN Orchestrator para os caminhos afetados. Tenha em atenção que ao realizar a “Atualização” (Refresh) de um caminho vai reaprender os caminhos de todos os Edges na empresa.
Problema 53934: numa empresa onde está configurado um cluster do VMware SD-WAN Hub, se o Hub principal tiver vizinhanças BGP multihop no lado LAN, o cliente poderá sofrer situações de tráfego ignorado num Spoke Edge quando existir uma falha do lado LAN ou quando o BGP não for configurado em todos os segmentos.
Num cluster de Hub, o Hub principal tem a vizinhança BGP multihop com um dispositivo de par para aprender caminhos. Se a interface física no Hub, através da qual a vizinhança do BGP é estabelecida, ficar inativa, os caminhos da BGP LAN não poderão ser zero, apesar da vista BGP estar vazia. Isto pode fazer com que o reequilíbrio do Cluster de Hub não ocorra. O problema também pode ser observado quando o BGP não está configurado para todos os segmentos e quando existem uma ou mais vizinhanças BGP multihop.
Solução alternativa: reinicie o Hub que teve a falha do lado da LAN (ou o BGP não ativado).
Problema 57210: mesmo quando um VMware SD-WAN Edge está a funcionar normalmente e é capaz de aceder à Internet, o LED na página Visão geral (Overview) da IU local é apresentado como “Vermelho” (Red).
A IU local do Edge determina a conetividade do Edge com base na capacidade do mesmo para resolver um nome conhecido através da resolução de DNS do Google (8.8.8.8). Se não o conseguir por qualquer motivo, pensa que está offline e apresenta o LED como vermelho.
Solução alternativa: não existe uma solução alternativa para este problema, exceto garantir que o tráfego DNS para 8.8.8.8 consegue alcançar o destino e ser resolvido com sucesso.
Problema 61543: se mais de uma regra NAT 1:1 for configurada em interfaces diferentes com o mesmo IP interno, o tráfego de entrada poderá ser recebido numa interface e os pacotes de saída do mesmo fluxo poderão ser encaminhados através de interfaces diferentes.
Para os fluxos NAT de Fora para Dentro, as regras NAT 1:1 serão correspondidas com o IP externo e a interface onde os pacotes são recebidos. Para os pacotes de saída do mesmo fluxo, o VMware SD-WAN Edge tentará fazer corresponder novamente as regras NAT comparando o IP interno e o tráfego de saída poderá ser encaminhado através da interface configurada na primeira regra de correspondência com “Tráfego de saída” (Outbound Traffic) configurado.
Solução alternativa: não existe uma solução alternativa para este problema, para além de garantir que não está configurada mais de uma regra NAT 1:1 com um endereço IP interno específico.
Problema 62701: para um VMware SD-WAN Edge implementado como parte de um cluster de Hub Edge, se a VPN de cloud não estiver ativada no segmento global, mas estiver ativada num segmento não global, uma atualização do plano de controlo enviada pelo Orchestrator pode fazer com que todas as ligações WAN fiquem instáveis no Hub Edge.
As ligações WAN do Edge Hub que fiquem inativas e, em seguida, ativas numa sucessão rápida (instabilidade) afetam o tráfego em tempo real, como chamadas de voz. Este problema foi observado numa implementação de clientes em que a VPN de cloud não estava ativada no segmento global do Hub Edge, mas a configuração do cluster estava ativada, o que significa que este Hub Edge fazia parte de um cluster (e a configuração de um cluster é aplicável a todos os segmentos). Quando uma alteração da configuração é emitida para o Hub Edge, o dataplane do Hub Edge inicia a análise dos dados e começa com o segmento global, onde verá que a VPN de cloud não está ativada, e o Hub Edge assume erradamente que o clustering foi desativado neste segmento global. Como resultado, o Edge Hub derruba todos os túneis das ligações WAN do Hub, o que provoca instabilidades de ligação em todas as ligações WAN desse Edge. Para qualquer incidente deste tipo, as ligações WAN só ficam inativas e recuperam uma vez por atualização do plano de controlo.
Solução alternativa: A solução alternativa é 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 passagem de informação. Isto porque os valores ctag e stag são escolhidos em /etc/config/gateway e não na configuração da 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, vai ativar o túnel CSS.
Problema 68057: O pacote da versão DHCPv6 não é enviado do VMware SD-WAN Edge quando se altera o modo de endereço da interface WAN de DHCP com estado para endereço IPv6 estático e a concessão permanece ativa até atingir o tempo válido correspondente.
O cliente DHCPv6 tem uma concessão que não é libertada quando a configuração é alterada. A concessão permanece válida até a sua vida útil expirar no servidor DHCPv6 e ser eliminada.
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 Standby Edge é comunicado como inativo através do SNMP. Se o par VNF HA for mudado para uma versão anterior, de uma versão que suporte VNF-HA (versão 4.0+) para uma versão que não a suporte com a VNF configurada no Orchestrator. Este problema ocorre quando o Edge é atualizado para uma versão que suporta a VNF-HA e é configurado no Orchestrator novamente.
Solução alternativa: a VNF deverá primeiro ser desativada no caso de uma configuração HA se o Edge for mudado para uma versão anterior que não a suporta.
Problema 70311: um VMware SD-WAN Edge pode encontrar uma falha do Serviço dataplane e, como resultado, ser reiniciado.
Durante o reinício do serviço Edge, o tráfego do cliente seria interrompido durante ~15-30 segundos. Este problema ocorre de forma inconsistente, mas quando ocorre o Edge separa uma associação de segurança IKE (SA). Normalmente, isto ocorre apenas quando: o temporizador SA (conforme configurado no VMware SD-WAN Orchestrator) expira; ou o utilizador altera a configuração IPSec no Orchestrator.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 71719: A ligação PPTP não é estabelecida ao longo do caminho Edge to Cloud.
A ligação ao servidor PPTP por trás do VMware SD-WAN Edge não é estabelecida.
Solução alternativa: não há solução alternativa para este problema, nem mesmo um reinício ou reinicialização do Edge.
Problema 72358: se o endereço IP de um nome DNS do VMware SD-WAN Orchestrator for alterado, o processo do plano de gestão do VMware SD-WAN Gateway não o resolverá corretamente e o Gateway não poderá ligar ao Orchestrator.
O processo de gestão do Gateway verifica periodicamente a resolução DNS do nome DNS do Orchestrator, para ver se este foi alterado recentemente para que o Gateway possa ligar-se ao anfitrião certo. O código de resolução do DNS tem um problema, pelo que todas as verificações de resolução falham e o Gateway continua a utilizar um endereço antigo e, como tal, deixa de conseguir ligar-se ao Orchestrator.
Solução alternativa: até que este problema seja resolvido, um utilizador operador não deve alterar o endereço IP do Orchestrator. Se o endereço IP do Orchestrator tiver de ser alterado, todos os Gateways ligados a esse Orchestrator terão de ser reativados.
Problema 77541: Quando um modem USB que suporta o IPv6 é desligado e, em seguida, ligado novamente a uma interface USB do VMware SD-WAN Edge, pode não ser aprovisionado um endereço IPv6 na interface USB.
Isto afeta modems USB baseados em IP, versus geridos pela aplicação ModemManager. A maioria dos modems Inseego são baseados em IP e isso é importante porque o Inseego é o fabricante de modem que o VMware SASE recomenda. Os modems USB que suportam o IPv6 e utilizam o ModemManager versus baseados em IP serão bons num cenário de desligar e ligar novamente.
Solução alternativa: O Edge tem de ser reiniciado (ou desligado e ligado) depois de o modem USB ser ligado novamente na porta USB do Edge. Após o reinício, o Edge irá recuperar o endereço IPv6 para o modem.
Problema 81852: para um VMware SD-WAN Edge que está a utilizar um Serviço de Segurança na Cloud (CSS) do tipo Zscaler que utiliza túneis GRE e ativou a Verificação de estado de funcionamento de L7 (L7 Health Check), quando esse Edge é atualizado para a versão 5.0.0, em alguns casos, o cliente pode observar erros de verificação de estado de funcionamento de L7.
Isto é normalmente visto durante a atualização do software ou durante o tempo de arranque. Quando a Verificação de estado de funcionamento de L7 (L7 Health Check) verifica se existe um CSS com túneis GRE, podem ser observadas mensagens de erro getaddress relacionadas com o socket. O erro observado é visto de forma intermitente e não consistente. Por causa disso, as mensagens de sonda da Verificação de estado de funcionamento de L7 (L7 Health Check) não são enviadas.
Solução alternativa: Sem a correção, para remediar o problema, um utilizador tem de desligar e depois voltar a ligar a configuração da Verificação de estado de funcionamento de L7 (L7 Health Check) e esta funcionalidade funciona então como esperado.
Problema 82184: num VMware SD-WAN Edge a executar a versão 5.0.0 do Edge, quando um traceroute ou traceroute6 é executado para o endereço IPv4/IPv6 de br-network do Edge, o traceroute não vai terminar corretamente quando é utilizada uma sonda UDP.
O traceroute ou traceroute6 para o endereço IPv4/IPv6 de br-network do Edge não será corretamente utilizado quando for utilizado o modo predefinido (por outras palavras, a sonda UDP).
Solução alternativa: Utilize a opção -I em traceroute e traceroute6 para utilizar a pesquisa ICMP e depois o traceroute para o endereço IPv4/IPv6 de br-network funcionará como esperado.
Problema 83166: Quando um VMware SD-WAN Gateway é recentemente implementado com um tipo de instância AWS c5.4xlarge do Portal do AWS com a opção IPv6 selecionada, nem o IPv6 nem os caminhos predefinidos estão configurados.
Como resultado do IPv6 e dos caminhos predefinidos não configurados, os túneis de gestão do Gateway IPv6 do AWS não estão a formar-se e o Gateway não irá funcionar.
Solução alternativa: não existe uma solução para este problema, evite a implementação de um Gateway com as propriedades acima mencionadas.
Problema 83227: para um VMware SD-WAN Edge a executar a versão 5.0.0 que está configurado com 128 segmentos, o processo dnsmasq do Edge irá parar e encerrar.
Quando o IPv6 estiver ativado em 128 segmentos e os servidores DCPv6 estiverem configurados na LAN de cada segmento, o processo dnsmasq irá parar ao ser excedido o total de descritores de ficheiros abertos. O processo dnsmasq continuará durante ~30 minutos antes de encerrar, altura em que a atribuição DHCP de endereços IP do Edge irá falhar.
Solução alternativa: Reiniciar o Edge restaura o processo dnsmasq durante ~30 minutos, mas voltará a falhar. A única solução alternativa real é reduzir o número de segmentos para menos de 128.
Problema 86098: 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.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 92481: Se uma interface WAN num VMware SD-WAN Edge estiver desativada no VMware SASE Orchestrator, continuará a ser comunicada como “Ativa” (UP) pelo SNMP.
O processo de depuração principal para a saída das interfaces não inclui os detalhes da porta física para interfaces WAN do Edge (por exemplo, GE3 ou GE4 num modelo Edge 6x0 ou 3x00). Como resultado, quando o SNMP sonda essas interfaces, devolve sempre um resultado de UP, independentemente da configuração das interfaces.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 92676: Numa implementação de cliente na qual um Destino Não VMware SD-WAN (NSD) via Gateway esteja configurado para utilizar túneis e Gateways redundantes e também esteja a utilizar BGP através de IPsec, caso os Gateways principais e secundários anunciem um prefixo com um caminho AS igual ao dos túneis NSD principais e secundários, o túnel NSD principal irá preferir um caminho do Gateway redundante em vez do Gateway principal.
O impacto de o túnel NSD principal via Gateway preferir o caminho do Gateway redundante em vez do Gateway principal só é sentido para o tráfego de retorno do NSD para o Gateway.
Sem uma correção para este problema, um utilizador precisa de configurar uma métrica mais alta (3 ou mais) no Gateway redundante para o prefixo interessado, pois tal ajudará o túnel principal do NSD a escolher o Gateway principal para o tráfego de retorno.
Solução alternativa: configure uma métrica mais alta (3 ou mais) no Gateway redundante para o prefixo interessado, pois tal ajudará o túnel principal do NSD a escolher o Gateway principal para o tráfego de retorno.
Problema 93062: quando um utilizador executa o diagnóstico remoto “Estado da interface” (Interface Status) no VMware Orchestrator, o Orchestrator devolve um erro para esse teste e não é concluído ou o teste não devolve resultados para as interfaces encaminhadas.
A mensagem de erro que pode ser visualizada é “erro ao ler os dados para o teste” (error reading data for test). Se o teste for concluído, os resultados das interfaces encaminhadas estão vazios sem quaisquer informações sobre velocidade ou duplex. De qualquer forma, o estado da interface é inválido. O problema está relacionado com o comando de depuração subjacente ao estado da interface omitir as portas DPKD ativadas.
Solução alternativa: o utilizador teria de gerar um pacote de diagnóstico para o Edge para ver o estado das interfaces encaminhadas.
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 94204: 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.
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 97559: No site de um cliente implementado com uma topologia de alta disponibilidade melhorada, uma ligação WAN ligada ao VMware SD-WAN Edge numa função Em espera pode aparecer como inativa no VMware SASE Orchestrator e não transmitir o tráfego do cliente, mesmo que a interface WAN do Edge onde a ligação WAN está ligada esteja ativa.
Um utilizador que analisasse um tcpdump ou o registo de um pacote de diagnóstico observaria pedidos de ARP a chegar e o Edge em espera a não responder, como resultado do bloqueio da respetiva porta.
Na HA melhorada, quando um Edge assume a função Em espera, devem ocorrer os seguintes eventos nesta sequência:
O Edge em espera bloqueia todas as portas.
O Edge em espera deteta que está implementado numa topologia de HA melhorada e desbloqueia as respetivas portas WAN para transmitir o tráfego.
Quando este problema ocorre, Evento 1, o bloqueio inicial das portas demora inesperadamente muito tempo a ser concluído e o Evento 2 seguinte, o desbloqueamento de todas as portas WAN, é concluído antes da conclusão do Evento 1. Em seguida, o Evento 1 é concluído e, assim, o estado final é que todas as portas WAN estão bloqueadas no Edge em espera.
Solução alternativa: Uma recuperação pós-falha de HA que promove o Edge em espera para ativo ativará as ligações WAN do Edge de HA.
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.
Como resultado deste caminho de não transmissão, todo o tráfego direcionado para este prefixo começa a passar pelo Edge Hub e o caminho de não transmissão torna-se de transmissão (mudança de comunidade para comunidade de transmissão), mas o caminho de não transmissão instalado anteriormente não é revogado e o tráfego utiliza o caminho do Edge Hub enquanto o túnel da VPN Ramo a Ramo Dinâmica permanece ativo.
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 65001: para um cliente que utiliza o VMware Cloud Web Security, um utilizador não pode configurar o Motor de inspeção para ativar/desativar as Verificações de hash de ficheiro através do VMware Orchestrator.
Quando um utilizador está a utilizar o Orchestrator para configurar o parâmetro de Verificação de hash de ficheiro do Motor de inspeção do Cloud Web Security para “Ação para transferência de ficheiro desconhecido” (Action for Unknown File Download) e “Ação para transferência de documento desconhecido” (Action for unknown document Download), estas alterações não são enviadas para o Motor de inspeção e não são aplicadas.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 63149: quando uma implementação do cliente tem sub-redes sobrepostas num perfil e configura uma sub-rede para uma política do VMware Cloud Web Security e associa a política do Cloud Web Security ao perfil e segmento, os clientes Edge nessa sub-rede não serão capazes de se ligar à Internet.
Se houver sub-redes sobrepostas configuradas para os segmentos LAN por trás dos VMware SD-WAN Edges dentro do mesmo segmento, os recursos por trás dos Edges não podem ter políticas do Cloud Web Security aplicadas para o tráfego ligado à Internet. Isto porque não há forma de identificar exclusivamente o Edge de destino para o tráfego de retorno da Internet para o Cloud Web Security.
Solução alternativa: ative o NAT do lado LAN no Edge e tenha uma sub-rede única que represente o tráfego originado a partir de recursos por trás do Edge.
Problema 62934: para uma empresa que utiliza o VMware Cloud Web Security, se um utilizador cliente abrir um browser Chrome no modo de navegação anónima e tentar transferir um ficheiro, a transferência pode, ocasionalmente, não ser bem-sucedida.
O modo de navegação anónima requer a ativação de cookies de terceiros. Ative os cookies de terceiros e volte a tentar a operação. Numa transferência sem êxito, o utilizador observaria um ecrã onde se lê “Ocorreu um erro. Contacte o administrador” (Error occurred contact your administrator) ou, para ficheiros de um servidor Web personalizado: “Esta página não está a funcionar” (This page is not working). Ocasionalmente, alguns servidores Web ou ficheiros podem ter uma variação na assinatura de ficheiro, que o Cloud Web Security Service pode não ser capaz de reconhecer, resultando neste problema.
Solução alternativa: autorize os cookies de terceiros e tente novamente. Não há uma solução conhecida para este problema se utilizar uma janela de navegação anónima.
Problema 64541: Para um cliente que utiliza o VMware Secure Access, ao utilizar a opção na configuração do Workspace ONE UEM para configurar o nome de anfitrião do túnel dentro do Grupo da organização, se um utilizador selecionar “Sim” (Yes), o nome de anfitrião será criado automaticamente na consola UEM em vez de ser configurado manualmente.
O utilizador deve ter a opção de configurar manualmente o nome de anfitrião e não apenas criá-lo automaticamente.
Solução alternativa: Sem a correção, a solução alternativa é defini-lo manualmente na consola UEM.
