| VMware SD-WAN Versão 4.3.1 | 17 de fevereiro de 2023
Verifique se existem adições e atualizações a estas notas de versão. |
| VMware SD-WAN Versão 4.3.1 | 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 4.3.0, bem como para os clientes afetados pelos problemas indicados abaixo que foram resolvidos desde a versão 4.3.0.
A versão 4.3.1 dos Orchestrators, Gateways e Edges Hub suporta todas as versões anteriores do VMware SD-WAN Edge igual ou superior à versão 3.2.0
Isto significa que as versões anteriores à 3.2.0 não são suportadas.
Foram explicitamente testadas as seguintes combinações de interoperabilidade:
| Orchestrator |
Gateway |
Edge |
|
| Hub |
Ramo/Spoke |
||
| 4.3.1 |
3.4.6 |
3.4.6 |
3.4.6 |
| 4.3.1 |
4.3.1 |
3.4.6 |
3.4.6 |
| 4.3.1 |
4.3.1 |
4.3.1 |
3.4.6 |
| 4.3.1 |
4.3.1 |
3.4.6 |
4.3.1 |
| 4.3.1 |
4.2.2 |
4.2.2 |
4.2.2 |
| 4.3.1 |
4.3.1 |
4.2.2 |
4.2.2 |
| 4.3.1 |
4.3.1 |
4.3.1 |
4.2.2 |
| 4.3.1 |
4.3.1 |
4.2.2 |
4.3.1 |
| 4.3.1 |
4.3.0 |
4.3.0 |
4.3.0 |
| 4.3.1 |
4.3.1 |
4.3.0 |
4.3.0 |
| 4.3.1 |
4.3.1 |
4.3.1 |
4.3.0 |
| 4.3.1 |
4.3.1 |
4.3.0 |
4.3.1 |
| 4.5.0 |
4.3.1 |
4.3.0 |
4.3.1 |
| 4.5.0 |
4.5.0 |
4.3.0 |
4.3.1 |
| 4.3.1 |
4.3.1 |
3.2.2 |
3.2.2 |
| 4.3.1 |
4.3.1 |
3.3.2 P2 |
3.3.2 P2 |
Nota: a versão 3.x não suportava adequadamente o AES-256-GCM, o que significava que os clientes que utilizavam o AES-256 estavam sempre a utilizar os Edges com o GCM desativado (AES-256-CBC). Se um cliente estiver a utilizar o AES-256, deverá desativar explicitamente o GCM do Orchestrator antes de atualizar os Edges para a versão 4.x. Uma vez que todos os Edges estão a executar a versão 4.x, o cliente pode escolher entre o AES-256-GCM e o AES-256-CBC.
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
Potencial problema com locais que utilizam uma topologia de alta disponibilidade
Um site onde um par de Edges são implementados numa topologia de alta disponibilidade pode deparar-se com um problema em que o Edge em standby reinicia uma ou mais vezes para resolver um estado Ativo-Ativo. Os reinícios do Edge em standby podem provocar a perturbação do tráfego do cliente, tendo um maior impacto em locais que utilizam uma topologia de HA melhorada, uma vez que o Edge em standby também transmite tráfego do cliente. O problema está a ser registado no problema 85369 na secção Problemas resolvidos do Edge/Gateway destas Notas de versão e está resolvido na compilação do Edge R431-20220608-GA.
Misturar Edges capazes de Wi-Fi e não capazes de Wi-Fi em alta disponibilidade não é suportado
A partir de 2021, o VMware SD-WAN introduziu modelos Edge que não incluem um módulo de Wi-Fi: os modelos Edge 510N, 610N, 620N, 640N e 680N. Embora estes modelos pareçam idênticos aos seus congéneres com Wi-Fi, com exceção do Wi-Fi, a implementação de um Edge com capacidade de Wi-Fi e um Edge sem capacidade de Wi-Fi do mesmo modelo (por exemplo, um Edge 640 e um Edge 640N) como um par de alta disponibilidade não é suportada. Os clientes devem verificar se os Edges implementados como um par de alta disponibilidade são do mesmo tipo: ambos com capacidade de Wi-Fi, ou ambos sem capacidade de Wi-Fi.
Alteração ao delimitador da configuração de filtro BGPv4 para o AS-PATH precedente
Até à versão 3.x, a configuração de filtro BGPv4 para o AS-PATH precedente do VMware SD-WAN suportava delimitadores baseados em vírgula e espaço. No entanto, a partir da versão 4.0.0 e posteriores, o VMware SD-WAN apenas suportará um delimitador baseado em espaços numa configuração AS-PATH precedente. Os clientes que atualizam da 3.x para a 4.x devem editar as 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.
Reverse Path Forwarding (RPF) ativado por predefinição
Em versões anteriores, os pacotes com origem desconhecida eram permitidos na interface LAN de um VMware SD-WAN Edge. Este comportamento prendia-se com o facto de as interfaces LAN do Edge não terem o Reverse Path Forwarding (RPF) ativado por predefinição. Como parte do Problema 52628 resolvido adicionado pela primeira vez com a versão 3.4.5, este comportamento foi alterado com a ativação do RPF em todas as interfaces LAN do Edge, sendo que os pacotes de interfaces LAN só seriam permitidos se tivessem origem na sub-rede LAN configurada.
Agora, os túneis Zscaler utilizam o IKEv2
Assim que um Orchestrator e os Gateways forem atualizados para a versão 4.3.0 ou posterior, os túneis de todos os Destinos Não-SD-WAN via Gateway que utilizem um tipo Zscaler serão alterados para o IKEv2 e deixarão de utilizar o IKEv1.
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 ou posterior; 4.0.2; 4.2.0 ou posterior; ou 4.3.0, o Edge seria atualizado conforme esperado. Para obter mais informações, consulte Problema 53676 resolvido nas notas da versão 3.4.5, 4.0.2, 4.2.0 ou 4.3.0.
Limitação com a automatização da WAN Virtual do Azure e do BGP através de IPsec no Edge e no Gateway.
A funcionalidade do BGP através de IPsec no Edge e no Gateway não é compatível com a automatização da WAN Virtual do Azure no Edge ou no Gateway. Apenas os caminhos estáticos são suportados ao automatizar a conetividade de um Edge ou Gateway para uma vWAN do Azure.
Limitação ao desativar a negociação automática nos modelos VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 e 3810
Quando um utilizador desativa a negociação automática para codificar a velocidade e o duplex nas portas GE1–GE4 num modelo VMware SD-WAN Edge 620, 640 ou 680; nas portas GE3 ou GE4 num Edge 3400, 3800 ou 3810; ou num Edge 520/540 quando um SFP com interface de cobre é utilizado nas portas SFP1 ou SFP2, o utilizador pode descobrir que, mesmo após um reinício, a ligação não aparece.
Tal deve-se ao facto de cada um dos modelos Edge indicados utilizar o Intel Ethernet Controller i350, que tem a seguinte limitação: quando a negociação automática não é utilizada em ambos os lados da ligação, não consegue detetar dinamicamente os fios adequados para transmitir e receber (MDIX automático). Se ambos os lados da ligação estiverem a transmitir e a receber nos mesmos fios, a ligação não será detetada. Se o lado do par também não suportar o MDIX automático sem a negociação automática e a ligação não aparecer com um cabo reto, será necessário um cabo Ethernet cruzado para estabelecer a ligação.
Para obter mais informações, consulte o artigo da BDC Limitação ao desativar a negociação automática nos modelos VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 e 3810 (87208).
15 de dezembro de 2021. Primeira edição
21 de dezembro de 2021. Segunda edição.
Foi adicionada uma nova compilação R431-20211217-GA do Orchestrator aos Problemas resolvidos do Orchestrator. Esta compilação do Orchestrator remedeia a CVE-2021-44228, a vulnerabilidade do Apache Log4j, ao atualizar para a versão Log4j 2.16.0. Para obter mais informações sobre a vulnerabilidade do Apache Log4j, consulte o VMware Security Advisory VMSA-2021-0028.5.
Foi adicionada às Notas importantes a seguinte nota: Limitação ao desativar a negociação automática nos modelos VMware SD-WAN Edge 520, 540, 620, 640, 680, 3400, 3800 e 3810. Esta nota aborda um problema que pode ser encontrado ao configurar uma velocidade forçada em algumas portas Ethernet dos modelos Edge indicados.
7 de janeiro de 2022. Terceira edição.
Foi adicionada uma nova compilação R431-20211221-GA do Edge à secção Problemas resolvidos do Edge. Esta compilação é a nova compilação GA do Edge para a versão 4.3.1.
Esta compilação do Edge inclui os problemas corrigidos 70933 e 76564, que se encontram documentados nesta secção.
17 de fevereiro de 2022. Quarta edição.
Foi adicionada uma nova compilação R431-20220118-GA do Edge à secção Problemas resolvidos do Edge. Esta compilação é a nova compilação GA do Edge para a versão 4.3.1.
Esta compilação do Edge inclui os problemas corrigidos 64343 e 74149, que se encontram documentados nesta secção.
Foi adicionado o Problema resolvido 72718 à secção Problemas resolvidos do Edge/Gateway da compilação GA original. Este problema foi resolvido com a compilação original, mas foi omitido das notas de lançamento originais devido a um erro interno de identificação de pedido.
25 de fevereiro de 2022. Quinta edição.
Foi adicionada uma nova compilação GA R431-20220222-GA do Orchestrator à secção Problemas resolvidos do Orchestrator.
Esta compilação do Orchestrator soluciona as vulnerabilidades do Apache Log4j CVE-2021-44228 (que foi abordada pela primeira vez na compilação R431-20211217-GA do Orchestrator com a versão 2.16.0 do Log4j) e CVE-2021-45046 ao atualizar para a versão 2.17.0 do Log4j. Para obter informações atualizadas sobre as vulnerabilidades do Apache Log4j e o respetivo impacto nos produtos VMware, consulte o VMware Security Advisory VMSA-2021-0028.9.
Esta compilação do Orchestrator adiciona também os problemas resolvidos 76036, 80613 e 81498, que se encontram documentados nesta secção.
3 de março de 2022. Sexta edição.
Foi adicionada uma nova compilação R431-20220302-GA do Edge à secção Problemas resolvidos do Edge. Esta compilação é a nova compilação GA do Edge para a versão 4.3.1.
Esta compilação do Edge inclui os problemas resolvidos 53951, 55327, 80010, 80551, 80654, 82463 e 82652, que se encontram documentados nesta secção.
Foram adicionados dois Problemas em aberto: 72925 e 83747, que estão documentados na secção Problemas conhecidos do Edge/Gateway.
Nota importante adicionada: Misturar Edges capazes de Wi-Fi e não capazes de Wi-Fi em alta disponibilidade não é suportado.
4 de março de 2022. Sétima edição.
O Problema em aberto 83747 foi removido dos Problemas conhecidos do Edge/Gateway. Este caso foi incluído erroneamente na Sexta edição da versão R431-20220302-GA do Edge devido a uma falha de comunicação sobre os sintomas deste problema e o impacto para o cliente, os quais não justificavam a inclusão nas Notas de lançamento.
23 de março de 2022. Oitava edição.
Foi adicionada uma nova compilação R431-20220316-GA do Edge à secção Problemas resolvidos do Edge. Esta compilação é a nova compilação GA do Edge para a versão 4.3.1.
A compilação R431-20220316-GA do Edge inclui os problemas corrigidos 61797, 70586, 77525 e 77625, que se encontram documentados nesta secção.
Na secção Compatibilidade, foi adicionado um novo Aviso a indicar que a versão 3.4.x do software está a chegar ao fim do suporte para o Orchestrator e o Gateway com o fim do suporte geral (EOGS) a 30 de março de 2022 e o fim da orientação técnica (EOTG) a 30 de junho de 2022. Diz apenas respeito ao Orchestrator e ao Gateway. O software 3.4.x do Edge está agendado para chegar ao fim do suporte a partir de 31 de dezembro de 2022.
Foi adicionada uma nova Nota importante, relativa à Limitação da automatização da WAN Virtual do Azure e do BGP através de IPsec no Edge e no Gateway. A nota indica: “A funcionalidade do BGP através de IPsec no Edge e no Gateway não é compatível com a automatização da WAN Virtual do Azure no Edge ou no Gateway. Apenas os caminhos estáticos são suportados ao automatizar a conetividade de um Edge ou Gateway para uma vWAN do Azure”.
Foi adicionado o Problema 84825 à secção Problemas resolvidos do Edge/Gateway.
29 de março de 2022. Nona edição.
Esta edição corrige ou adiciona vários pedidos relacionados com um sintoma em que um site implementado com uma topologia de alta disponibilidade regista um estado Ativo-Ativo que resulta em múltiplas recuperações automáticas e/ou reinícios de Edge em espera. As correções e adições são as seguintes:
Foi modificado o problema corrigido 77625 do Edge para corrigir a causa que anteriormente indicava “Supressão do thread HA” e agora indica “Prioridade do thread HA invertido” como a causa.
A causa anteriormente associada ao problema 77625 (Supressão do thread HA) foi modificada para “Suspensão do thread HA do Edge” e foi atribuída a um novo problema: 85369. Este problema foi adicionado à secção Problemas conhecidos do Edge/Gateway e continua sob investigação nesta edição.
Foi modificado o problema corrigido 67201 para proporcionar uma descrição mais precisa do sintoma e o que foi corrigido.
Foi modificado o problema corrigido 80654 para adicionar uma nota a esta correção, que está incluída na compilação R431-20220302-GA, e que mais tarde corrigirá um problema regressivo introduzido pela correção do problema 67201 na compilação GA original R431-20211208-GA.
Foram adicionados os novos problemas 79220 e 85156 à secção Problemas conhecidos do Edge/Gateway.
31 de março de 2022. Décima edição.
Foi adicionada uma nova compilação R431-20220331-GA do Edge à secção Problemas resolvidos do Edge/Gateway. Esta compilação é a nova compilação GA do Edge e do Gateway para a versão 4.3.1.
A compilação R431-20220331-GA do Edge inclui os problemas resolvidos 65695, 68923, 78003, 80897, 81517, 81575, 81920 e 82314, que se encontram documentados nesta secção.
Os problemas resolvidos do Edge/Gateway são discriminados da seguinte forma:
Correção do Edge e do Gateway: 80897
Correções apenas do Edge: 65695, 68923, 78003 e 81517.
Correções apenas do Gateway: 81575, 81920 e 82314.
14 de abril de 2022. Décima primeira edição.
Foi adicionada uma nova compilação R431-20220407-GA do Edge à secção Problemas resolvidos do Edge/Gateway. Esta compilação é a nova compilação GA do Edge para a versão 4.3.1.
A compilação R431-20220407-GA do Edge inclui os problemas resolvidos 58791, 65466, 83029, 83928, 83402 e 86103, que se encontram documentados nesta secção.
Foi adicionado o Problema pendente 62701 à secção Problemas conhecidos do Edge/Gateway, uma vez que, neste momento, este problema continua por resolver em todas as versões.
19 de abril de 2022. Décima segunda edição.
Foi adicionado o Problema resolvido 84847 adicional à compilação R431-20220407-GA do Edge. O código para esta correção foi incluído na compilação R431-20220407-GA validada, mas a equipa de engenharia não validou especificamente a correção para o 84847 e, assim, o pedido em questão foi omitido da edição de 14 de abril nas notas de versão. Desde então, a equipa de engenharia validou a correção para o 84847 da R431-20220407-GA e, nesta edição das notas de versão, está incluída como resolvida.
6 de maio de 2022. Décima terceira edição.
Foi adicionada uma nova compilação rollup R431-20220429-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 4.3.1.
A compilação rollup R431-20220429-GA do Orchestrator inclui os problemas 84152 e 84969 corrigidos, que se encontram documentados nesta secção.
Foi adicionado um novo aviso na secção Compatibilidade relativamente à versão 4.0.x, que se aproxima do fim do suporte.
12 de maio de 2022. Décima quarta edição
Foi adicionada uma nova compilação rollup R431-20220509-GA do Edge/Gateway à secção Problemas resolvidos do Edge/Gateway. Esta é a sétima compilação rollup do Edge/Gateway e é a nova compilação GA do Edge e do Gateway para a versão 4.3.1.
A compilação R431-20220509-GA do Edge inclui as correções para os problemas 81809, 83209, 84136 e 85459, que se encontram documentados nesta secção.
A compilação R431-20220509-GA do Gateway inclui as correções para os problemas 65466 e 74316. O problema 65466 pode afetar o Edge ou o Gateway. A correção do Edge foi incluída na sexta compilação rollup: R431-20220407-GA. No entanto, a correção do Gateway não estava disponível na altura.
18 de maio de 2022. Décima quinta edição
Foi adicionada uma nova compilação rollup R431-20220510-GA do Edge/Gateway à secção Problemas resolvidos do Edge/Gateway. Esta é a oitava compilação rollup do Edge/Gateway e é a nova compilação GA do Edge/Gateway para a versão 4.3.1.
A compilação R431-20220510-GA do Edge/Gateway inclui as correções para os problemas 64627 e 78568, que se encontram documentados nesta secção.
26 de maio de 2022. Décima sexta edição.
Foi adicionada uma nova compilação rollup R431-20220518-GA do Edge/Gateway à secção Problemas resolvidos do Edge/Gateway. Esta é a nona compilação rollup do Edge/Gateway e é a nova compilação GA do Edge/Gateway para a versão 4.3.1.
A compilação R431-20220518-GA do Edge/Gateway inclui as correções para os problemas 75772 e 88796, que se encontram documentados nesta secção.
Foi adicionado o problema 88796 como um novo Problema conhecido do Orchestrator. Este pedido regista o problema porque é aplicável apenas ao Orchestrator OVA, uma vez que a correção está incluída na compilação do gateway mais recente.
Foi adicionado o Problema 85461 à secção Problemas resolvidos do Edge/Gateway.
13 de junho de 2022. Décima sétima edição.
Foi adicionada uma nova Nota importante: “Potencial problema com locais que utilizam uma topologia de alta disponibilidade” relativamente a problemas em curso com locais de clientes que utilizam uma topologia de alta disponibilidade para um par de Edges. Este problema continua a ser monitorizado pelo problema 85369 localizado nos Problemas conhecidos do Edge/Gateway.
Em Compatibilidade, foram corrigidas as datas de fim de vida para o software do Edge da versão 4.2.x. O software do Edge é discriminado como um item à parte e agora indica o seguinte: “A versão 4.2.x do Edges chegará ao fim do suporte geral (EOGS) a 30 de junho de 2023 e ao fim da orientação técnica (EOTG) a 30 de setembro de 2023”. A entrada separada do Orchestrator e do Gateway mantém as mesmas datas de fim de vida como anteriormente.
Problema 53951 resolvido foi revisto na secção Problemas resolvidos do Edge/Gateway de forma a incluir outro cenário que pode afetar um cliente que encontre este problema no campo.
Problema 76016 movido da secção Problemas resolvidos do Orchestrator para a secção Problemas do Orchestrator. Este pedido foi incorretamente listado como “Resolvido”, o que não é o caso a partir desta edição das Notas da versão 4.3.1.
27 de junho de 2022. Décima oitava edição
Foi adicionada uma nova compilação rollup R431-20220608-GA do Edge/Gateway à secção Problemas resolvidos do Edge/Gateway. Esta é a décima compilação rollup do Edge/Gateway e é a nova compilação GA do Edge/Gateway para a versão 4.3.1.
A compilação R431-20220608-GA do Edge/Gateway inclui as correções para os problemas 78678, 83083 e 85369, que se encontram documentados nesta secção.
6 de julho de 2022. Décima nona edição
Foram adicionados os Problemas pendentes 88604 e 91746 à secção Problemas conhecidos do Edge/Gateway.
O problema 74149 foi movido da secção Problemas resolvidos da compilação rollup do Edge R431-20220118-GA para a secção Problemas conhecidos do Edge/Gateway. Este problema foi incluído como estando corrigido por engano. A correção do problema não foi incluída em qualquer compilação 4.3.1 do Edge e este permanece aberto na versão 4.3.1.
14 de julho de 2022. Vigésima edição
Foram adicionados os Problemas pendentes 81859, 91365 e 92676 à secção Problemas conhecidos do Edge/Gateway.
22 de julho de 2022. Vigésima primeira edição
Foi adicionada uma nova compilação rollup R431-20220715-GA do Orchestrator à secção Problemas resolvidos do Orchestrator. Esta é a terceira compilação rollup do Orchestrator e é a nova compilação GA do Orchestrator para a versão 4.3.1.
A compilação rollup R431-20220715-GA do Orchestrator inclui os problemas 76016 e 88796 corrigidos, que se encontram documentados nesta secção.
26 de agosto de 2022. Vigésima segunda edição.
Foi adicionado o Problema pendente 89217 à secção Problemas conhecidos do Edge/Gateway.
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.
9 de setembro de 2022. Vigésima terceira edição.
Foram adicionados os Problemas pendentes 72245, 81224, 87552, 89873 e 93383 à secção Problemas conhecidos do Edge/Gateway.
14 de setembro de 2022. Vigésima quarta edição.
Foi removido o problema 61797 “O retrocesso de caminho não é suportado no VMware SD-WAN Edge, o que resulta em caminhos de acessibilidade falsos” da secção Problemas resolvidos do Edge/Gateway na compilação do Edge R431-20220316-GA. Este problema foi erradamente incluído e dado que se trata de uma melhoria, está a ser completamente removido das Notas de versão, em vez de ser reposicionado em Problemas conhecidos.
28 de setembro de 2022. Vigésima quinta edição.
Foram adicionados os Problemas pendentes86098, 94204, 96441, 96888 e 98136 à secção Problemas conhecidos do Edge/Gateway.
7 de novembro de 2022. Vigésima sexta edição.
Estas notas foram revistas e republicadas com a nova ferramenta de publicação.
22 de novembro de 2022. Vigésima sétima edição.
30 de janeiro de 2023. Vigésima oitava 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. Vigésima nona 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 versão R431-20220608-GA do Edge/Gateway foi lançada em 17-05-2022 e é o oitavo rollup do Edge/Gateway para a versão 4.3.1.
Esta compilação rollup do Edge/Gateway aborda os problemas críticos abaixo desde o nono rollup do Edge/Gateway, versão R431-20220518-GA.
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.
Uma condição acionada por eventos de carga e do sistema faz com que o Edge ativo sofra atrasos no fornecimento oportuno de heartbeats de HA para o Edge em standby. O atraso faz com que o Edge em standby perca heartbeats e assuma incorretamente o papel de Ativo, o que causa o estado Ativo-Ativo. Para recuperar do estado Ativo-Ativo, o Edge em standby reinicia, possivelmente várias vezes.
Se o site se tornar Ativo-Ativo, uma configuração HA convencional sofrerá uma disrupção mínima no tráfego, dado que o Edge em standby não passa tráfego nesta topologia, mas numa implementação HA melhorada, onde o Edge em standby também está a passar tráfego, os reinícios perturbarão algum tráfego do cliente.
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 78678 resolvido: Num site implementado com uma topologia de alta disponibilidade, o VMware SD-WAN Edge que desempenha a função Standby pode ser reiniciado quando processa mensagens de sincronização do Edge ativo.
Quando o Edge de standby lida com um elevado número de mensagens de sincronização de fluxo, o serviço SD-WAN pode detetar uma condição de transbordo de buffer e desencadear um reinício do Edge de standby. Em termos de impacto, 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 versão R431-20220518-GA do Edge/Gateway foi lançada em 17-05-2022 e é o oitavo rollup do Edge/Gateway para a versão 4.3.1.
Esta compilação rollup do Edge/Gateway aborda os problemas críticos abaixo desde o oitavo rollup do Edge/Gateway, versão R431-20220510-GA.
Problema 88796 resolvido: Ao implementar um VMware SASE Orchestrator ou um VMware SD-WAN Gateway e utilizar um OVA no vSphere, as propriedades do OVF definidas como parte da implementação (palavra-passe, informações de rede, etc.) não serão aplicadas à imagem e não será possível aceder ao sistema após a implementação.
Isto só afeta o novo sistema implementado a partir do OVA que utilize propriedades OVF/vApp (por oposição à utilização de ficheiros ISO). Este problema é causado por alterações a montante ao cloud-init em atualizações recentes.
sem a correção, a solução é o operador implementar o sistema com um ficheiro ISO de dados de utilizador cloud-init.
esta correção é apenas para o Gateway OVA. O problema que afeta o Orchestrator OVA está registado com o mesmo pedido, 88796, mas na secção Problemas resolvidos do Orchestrator da compilação R431-20220715-GA.
Problema 75772 resolvido: Para um cliente que utilize o Edge Network Intelligence em que um VMware SD-WAN Edge tem a Análise ativa, o Edge pode ter uma fuga de memória que resulta no reinício do Edge para a limpar.
Quando a Análise (Analytics) está ativada e o DHCP está ativado numa interface do Edge, os eventos de conectividade do cliente fazem com que a utilização da memória aumente. Durante um período de tempo suficiente, a utilização da memória pode chegar a um limiar crítico e o Edge reiniciaria defensivamente o serviço Edge para restaurar os níveis normais de memória. Como em qualquer problema de fuga de memória, quanto menor for a pegada de memória inicial (por exemplo, um Edge 510, 520 ou 610) mais vulnerável é o reinício do Edge.
A versão R431-20220510-GA do Edge/Gateway foi lançada em 17-05-2022 e é o oitavo rollup do Edge/Gateway para a versão 4.3.1.
Esta compilação rollup do Edge/Gateway aborda os problemas críticos abaixo desde o sétimo rollup do Edge/Gateway, versão R431-20220509-GA.
Problema 78568 resolvido: Para um cliente que utilize o BGP e esteja ligado a Gateways de parceiros do VMware SD-WAN, um Gateway de parceiro pode continuar a anunciar uma sub-rede da VLAN do VMware SD-WAN Edge depois de o sinalizador de anúncio da sub-rede estar definido como Falsa.
Os caminhos continuam a ser anunciados porque, quando o Edge interrompe o estado de adjacência do vizinho BGP com um vizinho BGP L3, um dos Gateways de parceiro ligados mantém a propriedade da sub-rede da VLAN do Edge. Os caminhos obsoletos num Gateway de parceiro afetam negativamente o tráfego dos clientes e podem levar a que todos os fluxos dos clientes sejam removidos, porque o tráfego é encaminhado para caminhos agora inexistentes.
Sem uma correção, a única forma de remediar o problema e limpar os caminhos BGP obsoletos é um parceiro ou operador reiniciar o serviço do Gateway de parceiro numa janela de manutenção adequada.
Problema 64627 resolvido: Um VMware SD-WAN Gateway pode ter um reinício do Serviço dataplane com uma breve interrupção no tráfego.
Quando existe um grande número de subcaminhos configurados nas ligações WAN de um VMware SD-WAN Edge ou existem flaps frequentes dos túneis de gestão do Edge com o seu Gateway conectado, isto pode levar à exaustão dos contadores de memória do Gateway que aciona um reinício do Gateway para recuperar.
A versão R431-20220509-GA do Edge/Gateway foi lançada em 11-05-2022 e é o sétimo rollup do Edge/Gateway para a versão 4.3.1.
Esta compilação rollup do Edge/Gateway aborda os problemas críticos abaixo desde o sexto rollup do Edge/Gateway, versão R431-20220407-GA.
A compilação rollup do Gateway também aborda o problema 65466, uma correção que foi incluída na sexta compilação rollup do Edge, mas disponibilizada aqui porque a correção do gateway não estava disponível nesse momento.
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.
Problema 84136 resolvido: O cliente pode observar uma elevada utilização de CPU e um fraco desempenho do tráfego num VMware SD-WAN Edge atualizado para a versão 4.3.1.
Este problema ocorre em Edges que tenham configuradas mais de 400 regras de IP na secção Configurar > Firewall > Acesso Edge (Configure > Firewall > Edge Access) (endereços IP permitidos de acesso de suporte ou acesso SNMP). Quando o Edge tenta enviar a configuração de firewall nesse cenário, o processo de gestão esgota a CPU, excede o tempo limite e este processo repete-se.
Nas localizações dos clientes que também utilizem uma topologia de alta disponibilidade, os sintomas incluem “Eventos desconhecidos de alta disponibilidade”, porque o Edge ativo não está a enviar heartbeats dentro do período de tempo esperado.
Problema 83209 resolvido: Para os clientes que utilizem 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 o sinalizador de “Anúncio” ativado 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, ative o sinalizador Anúncio na respetiva interface (será necessário reiniciar o serviço Edge).
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 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.
A versão R431-20220407-GA do Edge foi lançada em 13-04-2022 e é o sexto rollup para a versão 4.3.1.
Esta compilação rollup do Edge aborda os problemas críticos abaixo desde o quinto rollup, versão R431-20220331-GA.
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 84847 resolvido: Os clientes que utilizam modems LTE baseados em USB ou modelos LTE VMware SD-WAN Edge (510-LTE ou 610-LTE) podem ter problemas intermitentes com túneis de criação na interface CELL após o reinício 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 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 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 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 65466 resolvido: Um VMware SD-WAN Gateway ou VMware SD-WAN Edge que processe uma grande troca de caminhos BGP pode experienciar uma falha no Serviço dataplane e reiniciar ao executar determinados comandos de depuração ou ao gerar um pacote de diagnóstico.
Um Edge ou um Gateway que processe um grande número de caminhos (por exemplo, um Edge que anuncie 50 000 caminhos BGP ou um Gateway que aprenda mais de 100 000 caminhos BGP de Edges) pode deparar-se com este problema se o comando de depuração dispcnt (com parâmetros) também for executado. O comando de depuração dispcnt é utilizado para monitorizar as quedas de capacidade e pode ser executado por um operador parceiro na CLI do respetivo dispositivo ou por um utilizador durante a criação de um pacote de diagnóstico. Quando este comando é executado num Edge ou Gateway com um grande número de caminhos e outro evento (por exemplo, eliminação de caminhos) ocorre de uma forma em que a variável original aponta para uma localização de memória que está agora obsoleta, o resultado será uma falha do Serviço dataplane devido ao acesso ilegal à memória.
Nota: A correção para o problema 65466 do Gateway está incluída na sétima compilação rollup R431-2020509-GA e posterior do Gateway. A correção do Gateway não estava disponível no momento em que o sexto rollup foi lançado.
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).
Nota: Uma versão anterior da descrição deste pedido indicou que esta era também uma correção para sites HA com operações BGP de correspondência e definição. Esta parte do problema não é corrigida neste pedido, é registada com o problema 84825.
A versão R431-20220331-GA do Edge e do Gateway foi lançada a 31-03-2022 e resolve os problemas críticos abaixo desde a versão 431-20220316-GA do Edge e da versão R431-20211208-GA do Gateway:
Problema 82314 resolvido: Quando um VMware SD-WAN Gateway é atualizado, pode apresentar uma exceção com uma perda de conetividade ao utilizar NICs baseados em passagem PCIe Intel x710.
Quando o Gateway é atualizado, parte da atualização é uma alteração do kernel, e a instalação do controlador i40e falha e não fica disponível no Gateway. Devido à indisponibilidade dos controladores i40e, todos os NICs baseados em passagem PCIe x710 não vão funcionar corretamente no Gateway, resultando numa degradação do desempenho ou numa perda de conetividade. Este problema não afeta um Gateway que utilize NICs baseados em Virtio ou VMNet.
Problema 81920 resolvido: Num VMware SD-WAN Gateway implementado com uma VM baseada em KVM que utiliza NICs baseados em SR-IOV Intel x710 pode ter problemas de conetividade após uma atualização do software do Gateway.
O problema surge porque os controladores de funções virtuais iavf do Linux não são instalados corretamente numa atualização do Gateway e, como resultado, os NICs baseados em SR-IOV x710 não funcionam no Gateway atualizado. Este problema não afeta um Gateway que utilize NICs baseados em Virtio ou VMNet.
Problema 81575 resolvido: Um VMware SD-WAN Gateway implementado com uma VM baseada em VMware OVA que utiliza NICs baseados em SR-IOV Intel x710 pode ter problemas de conetividade após uma atualização do software do Gateway.
O problema surge porque os controladores de funções virtuais iavf do Linux não são instalados corretamente numa atualização do Gateway e, como resultado, os NICs baseados em SR-IOV x710 não funcionam no Gateway atualizado. Este problema não afeta um Gateway que utilize NICs baseados em Virtio ou VMNet.
Problema 81517 resolvido: Num site implementado com uma topologia de alta disponibilidade melhorada que utiliza os modelos VMware SD-WAN Edge 6x0, o estado de ligação HA não está a ser atualizado adequadamente.
A ligação HA é a ligação que liga o par Edge HA melhorado e, se esta ligação não for atualizada corretamente, o site poderá ter problemas com o tráfego do cliente, uma vez que o Edge em standby também passa o tráfego do cliente.
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.
Nota: 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 78003 resolvido: Para um cliente que utilize uma topologia Hub/Spoke, os túneis estáticos do Edge Spoke VMware SD-WAN para um Edge Hub podem não ser formados.
Normalmente, se houver um grande número de túneis Edge a Edge dinâmicos já estabelecidos no Edge Spoke, a verificação do número máximo de túneis é atingida no Spoke para o túnel estático, e esta verificação impede a formação de túneis estáticos do Spoke para o Hub.
Problema 68923 resolvido: Na empresa de um cliente que utilize o BGP, um caminho predefinido pode ser redistribuído para um par de BGP, embora o estado de alcance para o caminho predefinido instalado seja definido como “Falso”.
Se estiver configurado um caminho estático num VMware SD-WAN Edge que aponta para qualquer interface do Edge e da qual o parceiro BGP aprende o caminho predefinido a partir do Edge e essa interface for posteriormente desativada, o que altera a flag alcançável para esse caminho para Falso, o caminho continua a ser anunciado. É igualmente verdade que um caminho que não está a ser redistribuído porque a interface não estava disponível, mas que quando a interface surge e marca o estado do caminho como “Verdadeiro” (True), o caminho continuaria a não ser redistribuído. A causa em ambos os casos é que o Edge não volta a anunciar o caminho numa mudança de estado da interface que reflete o novo estado do caminho.
Problema 65695 resolvido: Um cliente pode observar uma falha de tráfego quando este estiver destinado a uma sub-rede ligada.
O problema é que as sub-redes ligadas IPv4/IPv6 estão a ser redistribuídas para o overlay mesmo depois de o estado “Alcançável” (Reachable) mudar para Falso (False). Quando a interface principal está inativa, o serviço do Edge não recebe a notificação “inativa” (down) para as subinterfaces e, consequentemente, os caminhos ligados pertencentes às subinterfaces não são removidos. Qualquer tráfego que normalmente utiliza essas sub-redes quando estão alcançáveis fica numa condição de buraco negro e falha completamente.
A versão R431-20220316-GA do Edge foi lançada a 23-03-2022 e resolve os problemas críticos abaixo a partir da versão R431-20220302-GA do Edge:
Problema 77625 resolvido: Num site de cliente implementado com uma topologia de alta disponibilidade, o utilizador pode observar que o Edge em standby do VMware SD-WAN reinicia várias vezes.
O site entra num estado Ativo/Ativo (Split-Brain) devido à prioridade do thread HA estar invertida, um thread de prioridade inferior tem prioridade e impede um thread de prioridade superior de funcionar, o que provoca um atraso no processamento do heartbeat e leva a que o Edge em standby seja incorretamente promovido para Ativo. Num estado ativo-ativo, o tie-break vai para o Edge ativo e o Edge em standby é reiniciado para o despromover de volta ao seu estado rm standby adequado. No entanto, neste caso, o evento Ativo/Ativo é detetado várias vezes com reinícios do Edge em standby todas as vezes para recuperar o site. Quando este problema é encontrado numa topologia HA convencional, o impacto no cliente deverá ser mínimo, dado que o Edge em standby não está a passar o tráfego do cliente. Numa implementação HA melhorada, onde o Edge em standby também está a passar tráfego, os reinícios perturbarão algum tráfego do cliente.
Os problemas de campo envolveram os modelos Edge 6x0 (610, 620, 640, 680) mas o problema é agnóstico da plataforma e pode ocorrer em outros modelos Edge.
Problema 77525 resolvido: Num site que utilize uma topologia de alta disponibilidade, quando os VMware SD-WAN HA Edges são atualizados para uma nova imagem de software, o Edge em standby pode não conseguir atualizar e a IU do VMware SD-WAN Orchestrator lista incorretamente o estado do Edge em standby como “Ativo”, mesmo que não esteja.
Quando o Edge ativo deteta o Edge em standby, tenta obter a versão do software do Edge em standby e, se a versão for superior a 3.4.x, o Edge ativo copia o ficheiro de configuração da rede para o Edge em standby. Durante a obtenção da versão de software do Edge em standby, poderá ser apresentada uma exceção que não é processada pelo código HA do Edge, o que faz com que um thread de trabalho HA seja afetado e a comunicação com o Edge em standby falhe. Neste momento, o processo de gestão entre o Edge ativo e em standby foi interrompido e o que quer que se relacione com o plano de gestão, incluindo a gestão de software, o estado do Edge em standby e as alterações da configuração, não será sincronizado entre o Edge ativo e em standby. Isto resulta no facto de o Edge em standby ser falsamente detetado como ativo e aparecer como um estado de “split brain” ativo/ativo no Orchestrator, o que não acontece, já que o Edge em standby continua a desempenhar a função adequada.
Se ocorrer uma recuperação automática HA e o Edge em standby for promovido a ativo, o Edge ficará com um conjunto de configurações e software incompatíveis. O Orchestrator detetará a incompatibilidade da configuração e emitirá a configuração atualizada para este Edge, ao mesmo tempo que também completará a atualização do software que anteriormente falhou no Edge em standby. Como uma atualização do software do Edge requer um reinício, o cliente observaria outra falha enquanto o novo Edge ativo fosse reiniciado e, em seguida, despromovido de volta para o estado em standby.
Este problema não é encontrado de forma consistente quando um site HA atualiza o software dos Edges. Além disso, este problema também pode ocorrer quando se cria um novo site HA, ou quando um site autónomo é colocado em Alta Disponibilidade, sempre que o Edge em standby tem de atualizar o respetivo software. Contudo, estes cenários secundários são mais raros quando comparados com Edges HA submetidos a uma atualização do software.
Sem a correção, um cliente que observasse este problema teria de reiniciar o serviço Edge ou acionar uma recuperação automática HA para resolver o problema.
Problema 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.
A versão R431-20220302-GA do Edge foi lançada a 03-03-2022 e resolve os problemas críticos abaixo desde a versão R431-20220118-GA do Edge:
Problema 80551 resolvido: Nos modelos VMware SD-WAN Edge que incluem um modem LTE interno (Edge 510-LTE e Edge 610-LTE), os túneis LTE através de uma ligação IPV6 tornam-se INSTÁVEIS quando o endereço IPv6 na interface CELL muda.
Sempre que o endereço IPv6 numa interface CELL muda (por exemplo, devido à expiração da concessão DHCP), os túneis IPv6 tornam-se INSTÁVEIS. Isto porque os túneis continuam a utilizar o antigo endereço IPv6 em vez do novo.
Sem a correção, a única forma de remediar o problema é reiniciar o serviço do Edge.
Problema 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 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 possível condição race 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 80654 resolvido: Num site configurado com uma topologia de alta disponibilidade melhorada, um utilizador pode verificar quedas de tráfego intermitentes nas ligações WAN do VMware SD-WAN Edge em standby.
Quando há flaps de caminho frequentes (caminhos adicionados e eliminados frequentemente), a ligação TCP entre os Edges ativo e em standby é reposta em determinados cenários de tempo, provocando quedas de pacotes relativas ao tráfego que atravessa uma ligação WAN no Edge em standby.
Nota: A correção para este problema corrige uma regressão introduzida na correção 67201 na compilação GA original R431-20211208-GA.
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 55327 resolvido: A ligação SSH de um VMware SD-WAN Gateway a um VMware SD-WAN Edge pode não funcionar se ocorrerem flaps contínuos no túnel do Edge para o Gateway.
Caso ocorram flaps contínuos no túnel do Edge para o Gateway, a entrada do caminho instalada no Edge para permitir a ligação SSH a partir do Gateway pode ser eliminada e causar a falha da ligação SSH.
Problema 53951 resolvido: Um VMware SD-WAN Edge pode deparar-se com uma falha de tráfego enviada diretamente para a Internet ou uma perda de conetividade ao VMware SD-WAN Orchestrator e o Edge é marcado como inativo.
Este problema pode afetar um Edge num de dois cenários:
Para um Edge que utiliza ligações WAN públicas, quando ocorre um flap (a ligação fica inativa e, em seguida, ativa) numa ligação WAN, o impacto para o cliente neste cenário é que o tráfego que é direcionado para a ligação afetada e também é classificado como Direto é ignorado. Este problema afeta especialmente um site onde as regras da política empresarial são configuradas para forçar determinado tráfego a utilizar uma ligação WAN apenas enquanto também for enviado como Direto.
Ao ativar a HA num Edge com ligações WAN PPPoE, ocorre uma alteração na mudança do IP da interface PPPoE: o caminho próprio antigo é eliminado, mas, com o novo endereço IP PPPoE, o novo caminho próprio não é adicionado. Como resultado, a comunicação entre o Orchestrator e o Edge deixa de funcionar.
Sem a correção, a forma de corrigir temporariamente o problema é reiniciar o serviço do Edge para garantir que o tráfego Direto é enviado na ligação WAN pública afetada ou reiniciar o Edge (onde são utilizadas ligações PPPoE), o que recupera o caminho para o Orchestrator.
A versão R431-20220118-GA do Edge foi lançada a 26/01/2022 e resolve o problema crítico abaixo desde a versão R431-20211221-GA do Edge:
Problema 64343 resolvido: Os caminhos BGP aprendidos com um par não são identificados como caminhos de transmissão, apesar de os caminhos de transmissão estarem configurados para o vizinho BGP correspondente.
Os caminhos remotos anunciados para outros VMware SD-WAN Edges e Gateways não têm a configuração do flag de transmissão nos respetivos caminhos BGP. Ou são aprendidos novos caminhos BGP ou os caminhos BGP são atualizados pelo vizinho BGP e são anunciados na rede de overlay.
Nota: a correção para este problema requer uma compilação do VMware SD-WAN Orchestrator que inclui a correção para o problema 77101. Esta correção está incluída na compilação R450-20220215-GA atualizada do Orchestrator 4.5.0 lançada a 17/02/2022.
A versão R431-20211221-GA do Edge foi lançada a 24-12-2021 e resolve os problemas críticos abaixo desde a versão R431-20211208-GA do Edge:
Problema 76564 resolvido: Num site configurado com uma topologia de alta disponibilidade, quando a interface WAN do VMware SD-WAN Edge é ativada ou desativada com a IU do VMware SD-WAN Orchestrator, o site pode sofrer um estado de “split-brain” Ativo/Ativo que é prejudicial para o tráfego do cliente.
Quando as definições WAN de um Edge são alteradas, o serviço de rede do Edge é reiniciado, o que leva à perda temporária de pacotes HA. Tal faz com que o Orchestrator considere que o Edge ativo está inativo e promova o Edge em standby para ativo, o que, por sua vez, leva ao estado de “split-brain” Ativo/Ativo.
Problema 70933 resolvido: Após a migração de um perfil de configuração, um VMware SD-WAN Edge com a Alta Disponibilidade ativada pode sofrer vários reinícios.
Durante a migração de um perfil de configuração, apenas a configuração das definições do dispositivo é sincronizada imediatamente com o Edge em standby. As restantes configurações são sincronizadas apenas em resposta a um heartbeat do Edge em standby. Quando um Edge ativo reinicia para aplicar a configuração mais recente antes de receber o heartbeat do Edge em standby, o resultado será uma incompatibilidade na configuração entre o Edge ativo e o Edge em standby, o que causará vários reinícios do Edge para sincronizar as configurações de ambos os Edges HA.
Os problemas abaixo foram resolvidos a partir da versão R430-20211007-GA-61583-69704-59629-72423 do Edge e da versão R430-20211020-GA-VCG do Gateway.
Problema 21293 resolvido: Num site que utilize uma topologia de alta disponibilidade melhorada, as secções do Diagnóstico remoto (Remote Diagnostic) não mostram informações adequadas sobre a interface presente no VMware SD-WAN Edge em standby (a interface utilizada no modo HA melhorado).
Certas secções do Diagnóstico remoto (Remote Diagnostic) que contêm informações ou ações específicas para interfaces (como Estado da interface [Interface status] e Limpar cache ARP [Clear ARP cache]) não mostram informações sobre a interface no Edge em standby utilizada no modo HA melhorado.
Problema 40268 resolvido: Quando um utilizador altera a configuração de um VMware SD-WAN Hub ou uma configuração Edge a Edge via Hub, o Edge Spoke instala caminhos que são marcados como “Falsos” (False).
O Edge Spoke instala caminhos na FIB que são marcados como falsos (uma vez que não há nenhum túnel do Hub para esses caminhos) e os mesmos permanecem na FIB por ~2 minutos antes de serem limpos. Nesse tempo, estes caminhos falsos podem causar perturbações em algumas redes.
Problema 44256 resolvido: Numa empresa onde dois sites diferentes implementam os seus VMware SD-WAN Edges como Hubs, ao mesmo tempo que utilizam uma topologia de alta disponibilidade, e cada site utiliza o outro site do Hub como um Hub no seu perfil, se um dos sites do Hub desencadear uma recuperação automática HA, pode demorar até 30 minutos para ambos os Hub Edges restabelecerem os túneis entre si.
Numa recuperação automática HA, ambos os Hub Edges tentam iniciar um túnel entre si ao mesmo tempo e nenhum responde ao par, a troca de pacotes entre ambos os Hubs ocorre, mas o IKE nunca se sucede. Isto leva a um impasse que se verificou demorar até 30 minutos para se resolver por si só. O problema é intermitente e não ocorre após cada recuperação automática HA.
Sem esta correção, a única forma de evitar que este problema ocorra é utilizar uma solução alternativa onde o cliente configura apenas um dos dois sites do Hub de HA para utilizar o outro site do Hub como um Hub para si mesmo. Por exemplo, se existirem dois sites do Hub de HA, o Hub1 e o Hub2, o Hub1 pode ter o Hub2 como Hub para si no seu perfil, mas o Hub2 não deve utilizar o Hub1 como Hub no seu perfil.
Problema 46489 resolvido: Se diferentes perfis com Gateways de parceiro ativados forem atribuídos a vários VMware SD-WAN Edges, os Edges vão reter entradas de routing obsoletas para os Gateways de parceiro do VMware SD-WAN não atribuídas nos seus perfis.
Se diferentes perfis com Gateways de parceiro ativados forem atribuídos a vários Edges, o Edge reterá as entradas de routing aprendidas de outros Gateways e estes caminhos serão considerados entradas obsoletas. O impacto para o cliente consiste em tráfego que não é encaminhado corretamente porque o Edge está a tentar enviar tráfego para caminhos inválidos para esse perfil.
Problema 49787 resolvido: Um utilizador que navegue para a página Diagnóstico remoto (Remote Diagnostics) de um VMware SD-WAN Edge na IU do VMware SD-WAN Orchestrator pode observar a IU a processar o pedido, mas a página de diagnóstico do Edge não é carregada.
O problema pode ocorrer num Edge em que os certificados foram desativados e é o resultado de a ligação do VMware SD-WAN Edge ser continuamente reposta porque o Edge renova repetidamente o respetivo certificado.
Problema 50422 resolvido: O endereço MAC do par pode ser aprendido incorretamente via ARP ao utilizar interfaces encaminhadas e etiquetadas como VLAN.
Se tiver uma etiqueta VLAN atribuída a uma interface encaminhada e o hop seguinte enviar pedidos ARP não etiquetados, levará à aprendizagem do MAC não etiquetado e poderá fazer com que o tráfego seja colocado numa condição de buraco negro dependendo da entrada que é aprendida primeiro. Sem esta correção, a única alternativa será filtrar os pedidos ARP não etiquetados do próximo hop se tiver uma etiqueta VLAN na interface encaminhada.
Problema 52628 resolvido: Os pacotes com origem desconhecida são permitidos na interface LAN de um VMware SD-WAN Edge.
Com este problema, os pacotes provenientes de uma sub-rede diferente da sub-rede LAN são autorizados a passar pelo Edge. Isto deve-se ao facto de as interfaces LAN do Edge não terem o Reverse Path Forwarding (RPF) ativado. A correção ativa o RPF em todas as interfaces LAN do Edge e faz com que os pacotes de interfaces LAN só sejam permitidos se forem provenientes da sub-rede LAN configurada.
Problema 53359 resolvido: 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.
Problema 54001 resolvido: Um VMware Edge não pode enviar tráfego depois de uma fila Tx ficar bloqueada nas interfaces SFP.
Em casos raros, quando o Edge envia um pacote de tamanho inválido (com menos de 17 bytes ou mais de 1526 bytes) para o DPDK, a fila de transmissão fica paralisada, o que impede o Edge de encaminhar qualquer tráfego adicional. Reiniciar o Edge corrige temporariamente o problema, mas este poderá ocorrer novamente quando um pacote de tamanho inválido for enviado do serviço Edge para o DPDK. Apenas a atualização para um nível com a correção evita este problema.
Problema 54157 resolvido: O utilizador pode observar redução de tráfego num VMware SD-WAN Gateway para o tráfego a partir de um servidor de centro de dados para um cliente legado anunciado através do BGP sobre IPsec a partir do Gateway.
Na versão 4.4.x e anteriores, não é possível distribuir caminhos legados associados ao Edge do fornecedor (PE) para um Destino Não-SD-WAN (NSD) através dos caminhos NSD e Gateway para o PE. A versão 4.5.0 proporciona suporte ao pipeline de dados entre destinos associados ao PE e um NSD via Gateway. Isto também inclui a função de redistribuição de caminhos entre PG-BGP e NSD-BGP.
Problema 54846 resolvido: Os MIBs SNMP do VMware SD-WAN utilizam contadores para distorção, latência e perda de pacotes.
Em MIBs SNMP do VMware, a latência, a distorção e a perda de pacotes são definidas como Counter64, o que não é apropriado para estes tipos. Os contadores devem ser utilizados para tipos de dados cujos valores aumentam constantemente e que nunca são repostos no SNMP, como bytes Tx/Rx. Em contrapartida, a latência, a distorção e a perda de pacotes nunca têm valores de aumento constante, mas sim valores ajustados dinamicamente, e não devem utilizar contadores.
Problema 56218 resolvido: No site de um cliente implementado com uma topologia de alta disponibilidade ou onde a HA acaba de ser ativada, quando os Edges são atualizados de 3.2.x para 3.4.x, o Edge em espera pode ficar inativo.
Quando a HA (alta disponibilidade) está ativada ou os Edges HA são atualizados de 3.2.2 para 3.4.x após a configuração de uma definição WAN com a IU local, a interface HA (por exemplo, LAN1 ou GE1 dependendo do modelo Edge) será removida do Edge em espera e o estado HA será definido para HA_FAILED no VMware SD-WAN Orchestrator.
Problema 57011 resolvido: Num site configurado com uma topologia de alta disponibilidade, sempre que os segmentos são adicionados e, em seguida, eliminados nesse site, um dos Edges de HA pode sofrer uma falha do Serviço dataplane e se a falha de serviço estiver ativada no Edge ativo, o site também sofrerá uma recuperação automática da HA.
Quando os segmentos são adicionados e, em seguida, eliminados de um site HA, existe o potencial para segmentos obsoletos (por outras palavras, os segmentos eliminados podem ainda aparecer num dos Edges do par de HA). Devido a esta incompatibilidade nas informações de segmento entre os Edges HA, qualquer evento destinado ao segmento obsoleto pode ser enviado para o outro Edge, resultando numa falha do serviço dataplane e na recuperação automática de HA se a falha de serviço estiver no Edge ativo, e na geração de um despejo de memória que será encontrado num pacote de diagnóstico obtido após a falha.
Problema 58259 resolvido: Em alguns casos, um cliente pode observar um túnel VMware de Destino Não-SD-WAN inativo no lado do Gateway com um par Zscaler.
Existem alguns casos em que a extremidade do par Zscaler elimina a associação de segurança (SA) de Fase 2, mas o VMware SD-WAN Gateway ainda retém a SA. Nestes casos, o túnel é eliminado e o cliente não consegue passar tráfego.
Sem a correção, a solução alternativa é utilizar um script phase2_sa_check.py que passa sobre a tabela SA de fase 2 e verifica se existe uma SA de fase 2 para a qual a SA de fase 1 está em falta. Se encontrar uma, o Gateway restabelece o túnel.
Problema 58453 resolvido: Alguns pacotes do Office365 são classificados incorretamente como pacotes SSL pelo VMware SD-WAN Edge.
O motor de Inspeção Profunda de Pacote (DPI) do VMware SD-WAN está por vezes a classificar erradamente os pacotes que devem ser classificados como Office365 em vez de SSL. O impacto é que estes fluxos vão ser tratados como fluxos SSL em vez de fluxos Office365 e isso pode significar que são tratados com uma prioridade menor, impactando a experiência do utilizador.
Problema 59236 resolvido: Em sites que utilizem uma topologia de alta disponibilidade (HA) melhorada, os túneis não serão formados se a ligação WAN associada ao Edge em standby for um Metanoia SFP e este comportamento persistirá mesmo após uma recuperação automática HA.
Para HA melhorada, as portas WAN estão bloqueadas no Edge em standby (por outras palavras, o Edge não permite TX nas suas interfaces WAN). Para apresentar uma interface Metanoia SFP, tem de ocorrer uma troca de pacotes entre o hardware. Dado que o Edge não permite TX, a inicialização da interface não é bem-sucedida.
Problema 59629 resolvido: No site de um cliente implementado com uma topologia de Alta Disponibilidade, o utilizador pode observar que o Edge em standby do VMware SD-WAN reinicia várias vezes.
Tanto o Edge ativo como o Edge em standby perdem o heartbeat HA e ambos os Edges se tornam Ativo/Ativo (também conhecido como “Split-Brain”). Para desfazer o impasse, o recém-promovido Edge ativo (o anterior Edge em standby) será submetido a um reinício com um evento de registo: “Pânico Ativo/Ativo” (Active/Active Panic). A correção para este problema envolve a promoção da prioridade do thread de heartbeat Edge HA de modo a minimizar o atraso no processamento dos heartbeats que podem ser observados como heartbeats em falta e que provocam o estado Ativo/Ativo.
Problema 60010 resolvido: Num site que utilize VMware SD-WAN Edges com VNF implementado numa topologia de alta disponibilidade, o VNF no Edge em standby não está acessível através de SSH após um flap da porta do lado da LAN.
A interface do lado da LAN no VNF em standby encontra-se, normalmente, num estado desativado. Devido ao flap da porta do lado da LAN, este move-se para um estado de routing , o que resulta num mapeamento da porta do endereço MAC errado na interface de ponte, o que resulta na inacessibilidade do VNF.
Problema 60073 resolvido: Os pacotes DNS através de uma interface PPPoE do VMware SD-WAN Edge não são processados.
Os pacotes DNS passados através da interface PPPoE do Edge não são processados e são eliminados. Devido a isto, a funcionalidade de DNS através de PPPoE é afetada e o cliente observa, por exemplo, problemas como os túneis CSS não surgirem após uma atualização para a versão 4.2.0 ou posterior.
Problema 60184 resolvido: Um VMware SD-WAN Edge de ramo instala caminhos marcados como comunidade de transmissão a partir de um Edge Hub sem perfil (ramo a ramo dinâmico) e dá preferência a estes caminhos em comparação com qualquer outro.
O Edge Hub sem perfil é tratado como um Edge de ramo quando o ramo a ramo dinâmico é utilizado. Desta forma, quando existe uma criação dinâmica de um túnel, o problema ocorre conforme descrito. A única solução alternativa é adicionar Hubs a todos os perfis, mas não é possível dimensionar isto em redes de maior dimensão onde existem mais de 20 Edges Hub devido ao enorme número de caminhos que seriam criados.
Problema 60367 resolvido: As regras de firewall com estado não eliminam o primeiro pacote num fluxo que vai para o IP do VMware SD-WAN Edge mesmo com uma regra de eliminação específica da VLAN em vigor.
O envio de um ping para um IP VLAN do Edge é bem-sucedido mesmo com regras de eliminação da firewall com estado específicas da VLAN. Com regras de eliminação da firewall com estado específicas da VLAN, o comportamento não é consistente entre o ping para um anfitrião VLAN e o IP VLAN do Edge. O ping para um IP VLAN do Edge é bem-sucedido. A correção não permite o ping para o anfitrião VLAN ou o IP VLAN do Edge.
root@vc-client1:~# ping 10.0.2.1
PING 10.0.2.1 (10.0.2.1) 56(84) bytes of data.
64 bytes from 10.0.2.1: icmp_seq=1 ttl=62 time=1.37 ms
From 10.0.2.1 icmp_seq=2 Destination Net Unreachable
64 bytes from 10.0.2.1: icmp_seq=83 ttl=62 time=53.6 ms
From 10.0.2.1 icmp_seq=84 Destination Net Unreachable
64 bytes from 10.0.2.1: icmp_seq=173 ttl=62 time=126 ms
From 10.0.2.1 icmp_seq=174 Destination Net Unreachable
--- 10.0.2.1 ping statistics ---194 packets transmitted, 3 received, +3 errors, 98% packet loss, time 193216ms
rtt min/avg/max/mdev = 1.373/60.671/126.962/51.510 msVemos também uma única resposta às consultas SNMP:
$ snmpwalk -c public -v 2c 10.100.30.1
iso.3.6.1.2.1.1.1.0 = STRING: "VeloCloud EDGE5X0"
Timeout: No Response from 10.100.30.1O pkt_tracker mostra os pacotes ignorados e os pacotes permitidos:
21/03/26 00:22:33.283011,072|7|27428/5|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "tun_send", count 20 path "2 3 5 11 20 47 48 49 54 58 60 65 74 "
21/03/26 00:22:34.282824,192|7|27416/63|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "vcmp_inb_fw_drop", count 19 path "2 11 47 48 49 54 58 60 74 "
21/03/26 00:22:35.283832,832|7|27416/64|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "vcmp_inb_fw_drop", count 18 path "2 11 47 48 49 54 58 60 74 "
21/03/26 00:22:36.284884,480|7|27416/65|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "vcmp_inb_fw_drop", count 17 path "2 11 47 48 49 54 58 60 74 "
21/03/26 00:22:37.286092,544|7|27416/66|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:5201 <-> 10.0.4.25:44647 proto 6, app 1461, class 7, policy "User Default", reason "vcmp_inb_fw_drop", count 16 path "2 11 47 48 49 54 58 60 74 "
21/03/26 00:22:54.623312,128|7|27428/6|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:40125 <-> 10.0.4.25:53 proto 17, app 216, class 21, policy "User Default", reason "tun_send", count 15 path "2 3 5 11 20 47 48 49 54 58 60 65 72 74 "
21/03/26 00:22:54.623384,576|7|27424/3196|vc_pkt_print_track:187 dir: lan_to_wan, 10.0.2.1:40125 <-> 10.0.4.25:53 proto 17, app 216, class 21, policy "User Default", reason "cloud_to_edge_drop", count 14 path "7 31 32 34 71 74 "
21/03/26 00:22:55.622983,680|7|27416/68|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:40125 <-> 10.0.4.25:53 proto 17, app 216, class 21, policy "User Default", reason "vcmp_inb_fw_drop", count 13 path "2 11 47 48 49 54 58 60 74 "
21/03/26 00:22:56.624076,544|7|27416/69|vc_pkt_print_track:187 dir: wan_to_lan, 10.0.2.1:40125 <-> 10.0.4.25:53 proto 17, app 216, class 21, policy "User Default", reason "vcmp_inb_fw_drop", count 12 path "2 11 47 48 49 54 58 60 74 "Problema 61344 resolvido: Quando um VMware SD-WAN Edge tem tráfego > 180 Mbps a fluir através do mesmo, ocorre lentidão no novo tráfego seguinte iniciado através do Edge.
Quando tráfego > 180 Mbps está a fluir através de um Edge, o novo tráfego é colocado em memória intermédia no VMware SD-WAN Gateway e não é processado pelo Gateway no tempo esperado. Desta forma, o tráfego sofre latência.
Problema 61361 resolvido: Ao aplicar uma atualização de software para atualizar um VMware SD-WAN Edge 3400, 3800 e 3810 para a versão 3.4.5, 4.0.2 ou 4.2.1 do Edge, existe a possibilidade de os modelos Edge não arrancarem imediatamente após a atualização.
As versões 3.4.5, 4.0.2 e 4.2.1 incluem uma atualização de firmware específica para o dispositivo lógico programável complexo (CPLD) e a atualização aciona um reinício que, por vezes, pode ficar “preso”, exigindo um ciclo de energia manual para reiniciar o sistema.
Sem a correção, um utilizador local deve passar manualmente um ciclo de energia ao Edge para concluir a atualização.
Problema 61403 resolvido: Num site implementado com uma topologia de alta disponibilidade em que os VMware SD-WAN Edges são modelos LTE (por outras palavras, o Edge 510-LTE ou o Edge 610-LTE), os túneis não se formam na ligação LTE do Edge em standby quando a HA está ativada.
Quando um Edge em standby não ativado com uma ligação LTE tem uma imagem 3.4.4, 4.0.1 ou 4.2.0 e a HA está ativada, os túneis não se formam na ligação LTE do Edge em standby depois de o Edge ser ativado e atualizado após a ativação da HA.
Problema 61502 resolvido: Durante a ativação de um VMware SD-WAN Edge, a transferência da nova imagem de software a ser aplicada é adiada indefinidamente.
Num ambiente com conetividade de rede pouco fiável ou certos tipos de estrangulamento de tráfego, a transferência HTTPS da nova imagem de software pode ficar presa. Sem esta correção, caso este cenário ocorra, desligue e volte a ligar o Edge e aguarde alguns minutos. A transferência deve reiniciar automaticamente, no entanto, começa do zero.
Problema 61583 resolvido: Se um cliente ativar a Alta Disponibilidade para um site, o VMware SD-WAN Edge ficará offline, o site ficará inativo e todo o tráfego do cliente será interrompido.
Quando a AD é ativada, o Edge ficará, no mínimo, offline durante cerca de 5 minutos, com o tráfego do cliente interrompido durante esse período. O Edge poderá conseguir voltar à configuração anterior e retomar o funcionamento após esse período de cerca de 5 minutos, embora esse Edge continuar a funcionar como independente com a AD não seja possível. No entanto, se o Edge não voltar com êxito à última configuração, permanecerá inativo até que um utilizador local efetue uma reposição de fábrica seguida de uma reativação de RMA (com a AD não ativada) para restaurar a conetividade naquele site.
Para obter mais informações, consulte o artigo BDC Ativar a Alta Disponibilidade num VMware SD-WAN Edge com a versão 4.3.0 GA ou 4.4.0 GA pode fazer com que o Edge fique offline. (84396)
Problema 61657 resolvido: O SNMP num VMware SD-WAN Gateway é afetado quando são configurados caminhos IPv6 para atributos como publicIpAddr, localIpAddr, nextHop e peerIp, o que resulta em erros ao executar um percurso do SNMP para esse Gateway.
O SNMP depende da análise dos endereços IP com “.” como delimitador. No caso de um endereço IPv6, existe também um delimitador “:” e isso resulta em falhas nos percursos do SNMP. A correção deste problema altera a lógica de análise no SNMP.
Problema 61725 resolvido: Num site que utilize uma topologia de alta disponibilidade onde são utilizadas ligações USB WAN, a execução do diagnóstico remoto “Informações de HA” (HA Info) resultará em erros.
Quando um modem USB/LTE está presente ou esteve anteriormente presente apenas no Edge ativo do VMware SD-WAN e não no Edge standby, o Edge ativo tenta obter detalhes da interface USB/LTE no Edge standby e o resultado é que o Edge lança um erro, dado que a interface USB/LTE não está presente no Edge em standby.
Problema 61759 resolvido: O nome ISP e a largura de banda são apresentados como vazios na IU local do VMware SD-WAN Edge (página Visão geral [Overview] e página Propriedades de interface encaminhada [Routed Interface Properties]).
Se uma interface encaminhada tiver mais do que uma sobreposição, espera-se que a IU local apresente os detalhes da interface que tem o valor “última ativação” (last active) mais recente (dado que foi concebida para apresentar os detalhes de apenas um). Quando o utilizador abre a página Visão geral/Detalhes (Overview/Details) da IU local, os valores de largura de banda e ISP para interfaces encaminhadas com várias sobreposições são apresentados como vazios.
Problema 62197 resolvido: Um VMware SD-WAN Gateway pode reiniciar o seu Serviço dataplane.
O Gateway encontra uma fuga de memória que ocorre enquanto sincroniza caminhos de si próprio para o VMware SD-WAN Orchestrator. Quando o consumo de memória atinge níveis críticos, o serviço dataplane do Gateway é reiniciado para limpar a memória, causando uma breve perturbação no tráfego do cliente que utiliza o Gateway.
Problema 62280 resolvido: A subinterface LAN do VMware SD-WAN Edge não é apresentada num traceroute a partir de um anfitrião encaminhado para um cliente ligado através de Edge a Edge.
Quando o traceroute é realizado a partir de um anfitrião (não diretamente ligado ao Edge) para um cliente numa topologia Edge a Edge, o IP da interface do Edge não é apresentado em o/p. Isto só acontece quando uma configuração do VMware SD-WAN Gateway não é realizada na interface Edge no caminho para o anfitrião.
Sem a correção, a única solução alternativa é ativar a configuração do Gateway na interface do Edge que liga a esse anfitrião traceroute.
Problema 62373 resolvido: Ao chamar um site de alta disponibilidade configurado para um endereço MAC único, o vMAC é programado a partir de uma interface encaminhada para uma interface comutada.
O endereço MAC exclusivo não será programado para o Edge HA quando o tipo de interface for alterado de uma interface WAN para uma interface comutada e isto levará à perda de tráfego.
Sem a correção, a solução alternativa para resolver este problema é reiniciar os Edges HA, o que programará o MAC correto na interface agora comutada.
Problema 62897 resolvido: Se um utilizador operador iniciar sessão num VMware SD-WAN Gateway e executar o comando tcpdump em eth0 ou eth1, os resultados não são fornecidos corretamente.
tcpdump é um comando de depuração de Gateway crítico para os operadores e a falta de saída correta prejudica significativamente os seus esforços. Existe uma forma de obter a saída correta sem a correção, que consiste em utilizar um comando que canaliza a saída de tcdump para cat, por exemplo: tcpdump -nnplei eth0 | cat
Problema 62552 resolvido: Um site pode registar períodos intermitentes de perdas elevadas de pacotes e problemas de conetividade.
Este erro é causado pela API que verifica a resolução ARP, indicando ao Edge que existe uma resolução ARP bem-sucedida para um dispositivo enquanto entrega um endereço MAC de 00:00:00:00. Este endereço é mantido na cache ARP e quaisquer pacotes destinados ao dispositivo com o MAC listado como zero são ignorados. Neste problema, muitas destas instâncias de ARPs bem-sucedidos com endereços MAC zero são entregues, o que provoca problemas de conetividade e perda elevada de pacotes.
Nota: existe um problema anterior (60130) com o mesmo comportamento e causa subjacentes, mas que inclui uma resolução diferente do 62552. Com o 60130, a resolução foi uma solução alternativa defensiva, enquanto o 62552 inclui uma correção completa que impede qualquer recorrência deste problema.
Problema 62685 resolvido: Se o NAT do lado LAN estiver configurado com o mesmo IP externo para diferentes sub-redes LAN com tipo NAT como origem, o tráfego destinado à Cloud não funcionará.
Para o IP externo utilizado nas regras NAT do lado LAN, configuramos um caminho estático e anunciamo-lo nos ramos remotos. Para que o tráfego de retorno seja encaminhado para a sub-rede LAN correta, a pesquisa de caminho deve ser realizada com base no IP Interno configurado na regra NAT do lado LAN em vez do próximo hop no caminho estático. Mas para o tráfego de retorno na cloud, a pesquisa de caminho é realizada com base no próximo hop no caminho estático e o tráfego pode ser encaminhado para a sub-rede LAN errada.
Problema 62736 resolvido: Num VMware SD-WAN Edge baseado em hardware, quando o utilizador está a aceder à interface de utilizador local, na página Propriedades de interface encaminhada (Routed Interface Properties) da IU local, para interfaces PPPoE, o campo Endereço MAC (MAC address) é apresentado como vazio e o campo Endereço IP (IP address) apresentado está errado.
A partir da versão 4.3.x, os detalhes de interface na IU local são obtidos a partir de eventos NETLINK em vez de consultar constantemente quanto a atualizações. Dado que as próprias interfaces PPPoE não têm endereços MAC (as interfaces de base têm), o endereço MAC é apresentado como vazio. Adicionalmente, estava a ser utilizado um parâmetro errado do NETLINK para comunicar o endereço IP (IFA_ADDRESS em vez de IFA_LOCAL). As interfaces DHCP/estáticas não têm este problema, dado que o valor de ambos os campos é idêntico.
Problema 63056 resolvido: Um VMware SD-WAN Edge pode sofrer uma emergência do kernel, que resultará num reinício do núcleo.
O processo mutex mon falha com SIGXCPU e um núcleo é acionado. A correção para este problema é permitir que todos os threads utilizem ambos os núcleos, juntamente com deslocar a comunicação do Serviço de dataplane do Edge < > frr para sockets de domínio Unix, o que proporciona todos os benefícios dos sockets TCP sem a sobrecarga do núcleo e com um melhor desempenho.
Problema 63141 resolvido: Num site que utilize uma topologia de alta disponibilidade melhorada onde os módulos Metonia ADSL2+ SFP estão a ser utilizados, no caso de uma recuperação automática, os módulos ADSL2+ SFP não surgem.
Quando um Edge HA melhorado falha ou se a rede for reiniciada, um Edge com uma configuração ADSL2+ não surgirá.
Problema 63359 resolvido: Num site configurado com uma topologia de alta disponibilidade e OSPF e onde os VMware SD-WAN Edges estão a utilizar uma compilação IP MGMT do Edge, quando estes Edges são atualizados de uma compilação IP MGMT 3.4.x para 4.2.x, a conetividade OSPF pode ser interrompida após a atualização.
Quando os Edges HA são atualizados para uma compilação IP MGMT 4.2.x, os sistemas HA podem definir o ID de router como 169.254.2.2. Este não é o comportamento esperado, dado que a seleção do Edge do ID de router não deve ter em conta o endereço IP da interface HA. Este ID de router interrompe a conetividade OSPF e ocorre uma desconexão completa, dado que a troca de caminhos já não acontece.
Sem a correção, a única solução alternativa é reiniciar o serviço Edge (acionando uma recuperação automática de HA), pois isto irá forçar uma nova seleção do ID de router, que deve ser o correto após o reinício.
Problema 63362 resolvido: Num site que utilize uma topologia de alta disponibilidade melhorada, uma interface ativada por DHCP/PPPoE para de enviar tráfego após o Edge em standby ser reiniciado ou passar o ciclo de energia.
Numa topologia de HA melhorada, se o DHCP/PPPoE estiver ativado numa interface de proxy (isto é, o estado da ligação de HA está definido como USE_PEER), não obtém um endereço do servidor após o Edge em standby ser reiniciado ou passar o ciclo de energia.
Sem a correção, a única solução alternativa é alterar o endereço dinâmico para um tipo de endereço estático ou realizar uma recuperação automática de HA forçada para obter um endereço IP do servidor.
Problema 63513 resolvido: Para um cliente que utilize o VMware Edge Network Intelligence, a versão de software apresentada para o VMware SD-WAN Edge não é atualizada após uma atualização do software do Edge.
O Edge foi efetivamente atualizado para a versão mais recente do Edge Network Intelligence, mas comunica o número de versão mais antigo ao VMware SD-WAN Orchestrator e é isso que o cliente observa. O cliente encontra o problema após atualizar um Edge. Depois de o Edge ser atualizado de uma versão mais antiga para a mais recente, o cliente continuará a ver a versão mais antiga do Edge Network Intelligence.
Problema 63645 resolvido: Um VMware SD-WAN Edge pode ter problemas de memória, como danos, o que resulta numa falha do Serviço dataplane no Edge durante um flap do túnel.
A contagem de referências é utilizada para evitar que o sistema multi-threaded do Edge aceda à memória já libertada. Num dos cenários, adicionar a contagem de referências a uma das estruturas internas de dados que contêm informações do Gateway pode fazer com que a memória do Edge seja danificada.
Problema 63692 resolvido: Num VMware SD-WAN Gateway em que os Federal Information Processing Standards (FIPS) forem ativados durante o cloud-init, as sessões BGP não aparecem.
Se um utilizador ativar os FIPS no Gateway durante o cloud-init e, em seguida, configurar o BGP, observará que a vizinhança BGP não aparece.
Problema 63725 resolvido: Para um cliente que implementa um Destino Não-SD-WAN (NSD) via Gateway onde também foram configurados VMware SD-WAN Gateways redundantes, quando é efetuada a recuperação automática do tráfego do NSD do Gateway principal para o Gateway secundário, o tráfego falha.
Este problema é provocado pela falta de um caminho para o destino do par no Gateway secundário. Quando é efetuada a recuperação automática do tráfego para o Gateway secundário, o Gateway envia o tráfego diretamente, uma vez que o Gateway secundário não tem um caminho para o destino do par do NSD. Como o tráfego é enviado diretamente quando se tenta ligar ao destino do par, todo o tráfego do NSD via Gateway falha.
Problema 63752 resolvido: Num VMware SD-WAN Gateway em que os Federal Information Processing Standards (FIPS) estejam ativados, se um utilizador tentar gerar um pacote de diagnóstico, a tentativa falhará ou excederá o tempo limite.
Um Gateway configurado para um modo de funcionamento FIPS aplica perfis de segurança de aplicações que impedem a recolha de alguns dados de diagnóstico no sistema e isso faz com que a geração do pacote de diagnóstico falhe.
Problema 63983 resolvido: Se um parceiro estiver a utilizar uma ferramenta de monitorização (por exemplo, o Prometheus) para recolher métricas de utilização da CPU e da memória de um VMware SD-WAN Gateway, o utilizador desta ferramenta também verá saídas relativas à utilização da CPU e da memória do Orchestrator.
Como não é adicionado nenhum prefixo para diferenciar as estatísticas da CPU e da memória, a ferramenta de monitorização recolhe a utilização da CPU e da memória do Gateway e do Orchestrator.
Problema 64078 resolvido: Se um parceiro estiver a utilizar uma ferramenta de monitorização (por exemplo, o Prometheus) para recolher métricas de débito de um VMware SD-WAN Gateway e um determinado Gateway utilizar uma interface ligada, as estatísticas de débito desse Gateway serão imprecisas.
O Gateway está a exportar apenas contadores de débito de interfaces eth, e não a exportar estatísticas de interfaces ligadas, o que é um grande problema, uma vez que muitos Gateways utilizam interfaces ligadas.
Problema 64184 resolvido: Quando um utilizador ativa a alta disponibilidade num site que utilize dois Edges de hardware VMware SD-WAN, o utilizador pode observar que, quando o ponto de atualização do software do Edge em standby é atingido, a atualização do Edge não ocorre e o Edge em standby permanece num estado inativo.
Este problema ocorre raramente nas condições acima referidas, mas, quando ocorre, a causa é o encerramento de um thread de trabalhador de HA no Edge ativo durante a ação de invocação da atualização da imagem do Edge em standby após a ativação da HA. O encerramento deste thread de trabalhador HA leva a que o Edge em standby fique num estado inativo.
Problema 64205 resolvido: O utilizador observa um elevado número de Handoff Queue Drops de dados VCMP para um VMware SD-WAN Gateway, o que causa uma má experiência do utilizador.
Quando existem eventos contínuos de criação de fluxos, o processamento de pacotes no thread de dados do VCMP (Protocolo de gestão do VeloCloud) torna-se mais lento. Esta correção reduz a carga do thread de dados VCMP, redirecionando as mensagens de controlo VCMP para um thread diferente e eliminando algumas das mensagens de registo contínuas.
Problema 64713 resolvido: No site de um cliente que utilize uma topologia de alta disponibilidade melhorada, se um utilizador reiniciar o serviço Edge ou efetuar uma alteração de configuração que resulte no reinício do serviço Edge, o cliente poderá observar que o reinício demora muito mais tempo do que o esperado antes da recuperação do Edge.
Quando este problema ocorre, existe uma condição race entre o processo Edge e outros processos concorrentes que resulta no atraso do arranque. Nos registos do pacote de diagnóstico, o utilizador veria uma linha com a frase “FATAL: Não é possível obter informações hugepage” (FATAL: Cannot get hugepage information).
Problema 64951 resolvido: Um cliente que utilize o Zscaler como Serviço de Segurança na Cloud (CSS) pode observar eventos ZSCALER_MONITOR_FAILED na página de eventos do VMware SD-WAN Orchestrator quando for realizada uma verificação de estado de funcionamento de L7.
Estes eventos são falsos e o túnel Zscaler está, na verdade, intacto, o que causa confusão para o utilizador.
Problema 64633 resolvido: Um cliente que utilize um destino Não-SD-WAN (NSD) via Gateway para ligar a um VMware Cloud (VMC) no par AWS pode observar uma queda de tráfego intermitente com uma duração de ~30 segundos de cada vez.
Este problema é observado apenas com o VMware Cloud (VMC) no AWS. O par inicia uma recodificação da IKE 30 segundos antes da expiração da associação de segurança (SA) e, depois de cada recodificação, o par retém a SA antiga e utiliza-a até à respetiva expiração, enquanto o VMware SD-WAN Gateway elimina a SA de entrada. A eliminação da SA de entrada causa a queda de tráfego com este par. A frequência deste problema depende da política de recodificação do par. Se o par for recodificado a cada 45 minutos, significa que este problema ocorre a cada 45 minutos. Se for recodificado a cada 12 horas, significa que ocorre a cada 12 horas. O tráfego recupera automaticamente após ~30 segundos, quando o par mudar para a nova SA.
Problema 64961 resolvido: Um VMware SD-WAN Edge pode encontrar uma falha do Serviço dataplane e reiniciar esse serviço se estiver a processar pacotes IP que incluem opções.
O processamento de pacotes IP com opções poderá resultar numa falha do Serviço dataplane devido a uma análise incorreta dos campos de opções (a análise continua para além do fim da lista de opções). A falha do Serviço dataplane é acionada por mon mutex. Sem esta correção, a única forma de minimizar o risco deste problema é evitar definir opções que não o Caminho de registo (Record Route) (RR) e Sem opção (No Option) (NOP) nos pacotes IP de tráfego de utilizador.
Problema 65037 resolvido: O estabelecimento de uma ligação HTTPS/SSL pode falhar devido a um certificado corrompido caso o certificado tenha caracteres especiais ou espaços no campo de nome comum SSL (SSL common name).
O VMware SD-WAN Edge inspeciona todo o tráfego do utilizador que passa por ele, para que possa identificar a aplicação à qual o tráfego pertence. É necessário para a aplicação correta das políticas empresariais e também para que o VMware SD-WAN Orchestrator apresente as estatísticas por aplicação na página Monitorização (Monitoring) do Edge. No entanto, um problema no código de identificação da aplicação faz com que um byte no nome comum SSL seja substituído caso o nome comum SSL contenha caracteres especiais ou espaços, sendo, desta forma, corrompido.
Problema 65186 resolvido: No site de um cliente que utilize várias ligações WAN, se existir uma política empresarial configurada para utilizar uma ligação com uma política preferencial ou obrigatória, a carga do tipo de tráfego abrangido pela política empresarial continuará a ter balanceamento de carga em todas as ligações disponíveis.
Mesmo que a política empresarial esteja configurada para encaminhar o tráfego para uma ligação WAN com uma configuração obrigatória ou preferencial, a carga do tráfego incluirá balanceamento de carga em várias ligações WAN.
Problema 65219 resolvido: Um VMware SD-WAN Gateway do tipo KVM SR-IOV com um controlador i40evf eliminar pacotes de clientes com 1500 bytes ou mais.
Os dados com um tamanho inferior a 1496 B não serão ignorados. Se um utilizador tentar um protocolo SSH no anfitrião do Gateway, irá observar uma suspensão com base na condição descrita.
Problema 65293 resolvido: O desempenho do débito de um VMware SD-WAN Gateway implementado no AWS e que está a ser executado com o controlador do Elastic Network Adapter (ENA) da Amazon fica degradado ao utilizar a versão 4.x.
Este problema ocorrerá se o Gateway for atualizado para uma compilação 4.x (a partir de 3.x) ou numa nova implementação através de uma compilação 4.x. Os Gateways que utilizem a versão 4.0.0 ou posterior têm o DPDK v19.11 e, a partir do DPDK v19.02, o controlador do ENA da Amazon utiliza uma fila de baixa latência (LLQ). No entanto, para que a LLQ funcione de forma eficiente, a combinação de gravação para a definição de memória tem de estar ativada de acordo com o guia de referência do ENA. Se o mapeamento de memória não tiver a combinação de gravação, o Gateway implementado no AWS apresentará uma elevada utilização da CPU, o que afeta significativamente o débito. A correção deste problema ativa a combinação de gravação no adaptador ENA para Gateways implementados no AWS.
Problema 65432 resolvido: Um traceroute a partir de um cliente que está ligado do lado da LAN a um VMware SD-WAN Edge para um servidor DC através do VMware SD-WAN Gateway não apresenta o IP do Gateway na saída do traceroute.
Ao iniciar um traceroute a partir do cliente LAN para o DC que é alcançável através do Gateway, o traceroute mostra todos os hops, exceto o IP do Gateway.
Problema 65521 resolvido: Um VMware SD-WAN Edge pode encontrar uma falha do Serviço dataplane e, como resultado, reiniciar.
Um reinício do serviço Edge irá perturbar o tráfego do cliente durante ~5 a 10 segundos. O Serviço dataplane do Edge falha ao processar uma mensagem de controlo inesperada durante um handshake de criação de túnel de protocolo de gestão VeloCloud (VCMP). Este problema não depende da topologia de rede, do número de fluxos ou do débito. É uma situação rara e aleatória, mas tem o potencial de ocorrer em qualquer tipo de cliente empresarial.
Problema 65526 resolvido: O VMware SD-WAN Orchestrator gera Alertas e Eventos para um VMware SD-WAN Edge num estado “Degradado” que nunca atinge um estado “Offline/Inativo”.
Quando um VMware SD-WAN Edge perde inicialmente a conetividade ao Orchestrator (numa verificação de heartbeat), estado é designado “Degradado”. Se a perda de conetividade do Edge ao Orchestrator continuasse, o Edge seria, em seguida, marcado como Offline/Inativo e este segundo estado ocorreria quando um Evento “Edge inativo” (Edge Down) fosse publicado na página Monitorizar > Eventos (Monitor > Events) do Orchestrator e um Alerta correspondente fosse enviado conforme adequado para a configuração de Alertas de um cliente. No entanto, o Orchestrator está a gerar um Evento e a enviar um Alerta para um Edge num estado Degradado, o que resulta num número possivelmente grande de Eventos de Edge inativo e notificações de Alertas indevidos para o cliente.
Problema 65539 resolvido: Uma sessão BGP estabelecida entre dois dispositivos entre dois ramos diferentes não surge quando o cliente atualiza os seus VMware SD-WAN Edges para a versão 4.2.x.
Quando um cliente atualiza os respetivos Edges de uma versão inferior para a versão 4.2.x, as sessões BGP entre 2 dispositivos LAN de ramos diferentes estabelecidas sobre túneis VCMP não surgirão.
Problema 65839 resolvido: Para os fluxos iniciados a partir de clientes atrás de um VMware SD-WAN Hub Edge para a LAN atrás de um Edge Spoke, o tráfego de retorno do spoke é encaminhado através do Gateway de parceiro se o caminho predefinido for o anunciado a partir do Gateway de parceiro.
O comportamento esperado é que um fluxo com origem num Edge Hub também regresse através do Edge Hub. Se não existir um caminho predefinido ou um caminho Edge a Edge anunciado do Edge Hub para o Edge Spoke, a procura do caminho no Edge Spoke para o tráfego de retorno corresponde ao caminho predefinido do Gateway de parceiro e o tráfego de retorno é encaminhado para o Gateway de parceiro em vez do Edge Hub.
Problema 65929 resolvido: Quando um utilizador ativa a Alta Disponibilidade na IU do VMware SD-WAN Orchestrator para o site de um cliente que utiliza Edges físicos, o Edge pode ficar offline imediatamente e não é transmitido nenhum tráfego para o mesmo.
Durante o arranque, um Edge HA bloqueará o tráfego até o serviço dataplane do Edge ser iniciado. No entanto, o dataplane precisa de algumas informações do processo de gestão para ser iniciado e o próprio processo de gestão pode bloquear ao tentar resolver um nome DNS para o Orchestrator (porque a respetiva consulta está bloqueada pelo anterior). Tem de fazer uma resolução assíncrona do endereço do Orchestrator para não impedir o arranque do serviço dataplane do Edge.
Problema 65985 resolvido: Para um cliente que utilize o Edge a Edge dinâmico, um VMware SD-WAN Edge na sua rede pode eliminar abruptamente todos os túneis e, em seguida, não ser capaz de construir túneis para quaisquer outros locais da rede.
Assim que o site elimina todos os seus túneis, o valor máximo do túnel do Edge fica corrompido e apresenta um valor negativo para o número máximo de túneis. Este valor corrompido impede que o Edge forme novos túneis Edge a Edge dinâmicos para outros Edges. O impacto é grave, dado que o Edge não consegue comunicar com qualquer outro site na rede.
Sem a correção, a única forma de resolver este problema é realizar um reinício do serviço Edge ou uma recuperação automática HA para locais HA.
Problema 66119 resolvido: Um VMware SD-WAN Edge Virtual implementado numa região remota do mundo pode não ser ativado quando se utiliza o cloud-init.
Se a latência da rede entre o Edge e o VMware SD-WAN Orchestrator for superior a 1 segundo, a ativação automática do Edge Virtual através do cloud-init falhará durante a implementação inicial.
Problema 66325 resolvido: O tráfego de um cliente que deveria corresponder a um caminho aprendido BGP é, em vez disso, correspondido a uma política empresarial com o potencial de perturbar o tráfego do cliente.
Se a empresa de um cliente utilizar uma política empresarial que configura a Origem como o IP de um cliente encaminhado e o destino como Internet, o tráfego que deveria corresponder a um caminho aprendido BGP utilizará, em vez disso, a política empresarial, incluindo qualquer que seja a classificação de tráfego para essa política (por exemplo, Tempo real), o que pode causar perturbações no tráfego do cliente.
Problema 66355 resolvido: para um cliente em que a firewall com estado está ativada e pelo menos uma regra NAT (Muitos:1) do lado da LAN está configurada, os fluxos entre VLANs não funcionam.
Com regras NAT do lado da LAN Muitos:1, o estado TCP não é mantido corretamente para o tráfego entre VLANs e, com a firewall com estado também ativada, os pacotes serão eliminados.
Problema 66366 resolvido: Para um cliente que utilize multicast com um número elevado de vizinhos, um VMware SD-WAN Edge pode encontrar uma falha no Serviço dataplane e reiniciar, provocando uma breve perturbação no tráfego do cliente.
Um “número elevado de vizinhos” é definido como ~1600 vizinhos PIM. No caso de este problema ocorrer enquanto o tráfego está em execução para um grupo de 1600 Edges Spoke para um recetor atrás de um Edge Hub, o serviço PIM falha e isso, por sua vez, faz com que o serviço Edge também falhe, causando o reinício.
Problema 66636 resolvido: O VMware SD-WAN Edge não cumpre a configuração da interface de origem para o tráfego de autenticação RADIUS quando a origem é uma interface de retorno.
Quando um utilizador configura o RADIUS num Perfil ou Edge e especifica uma interface de retorno como a interface de origem pretendida para o tráfego de autenticação de saída, o Edge não cria uma regra NAT como esperado devido a um erro de análise decorrente de uma inconsistência no tipo esperado em comparação com o tipo real do parâmetro “porta” para o serviço de autenticação que é distribuído a partir do VMware SD-WAN Orchestrator. Este valor deve ser um número inteiro e a lógica de validação da API do Orchestrator foi alterada em conformidade.
Problema 66676 resolvido: Quando um NAT de política empresarial estiver configurado, pode não ocorrer NAT do tráfego de retorno do VMware SD-WAN Gateway para o IP de origem original.
Durante a inserção da entrada NAT no código, espera-se que elimine as entradas mais antigas. No entanto, devido à não utilização de todas as chaves para a procura da tabela hash, as entradas mais antigas não eram eliminadas em algumas situações e isso estava a provocar o erro de inserção de entrada NAT.
Problema 66714 resolvido: O utilizador não consegue utilizar um nome de anfitrião para a Opção DHCP 150 num VMware SD-WAN Edge.
Se um utilizador configurar um nome de anfitrião para a Opção DHCP 150, a tentativa de obter um endereço IPv4 a partir do Edge com um cliente DHCP resultará em mensagens de erro dnsmasq nos registos do Edge que se referem ao nome de anfitrião como um endereço IP incorreto e o cliente DHCP não obterá nenhum endereço IP do serviço DHCP no Edge. Embora o RFC 5859 tenha sido concebido para utilizar endereços IPv4 em vez de um nome de anfitrião, outros dispositivos de rede atuais permitem a utilização de um nome de anfitrião para a Opção 150. Assim, os clientes que utilizassem nomes de anfitrião noutros dispositivos teriam de acomodar os dispositivos Edge para que o serviço DHCP no Edge não falhasse.
Problema 66794 resolvido: Se um VMware SD-WAN Orchestrator for atualizado para a versão 4.3.0, os utilizadores poderão não conseguir configurar as regras de Encaminhamento de porta ou de NAT 1:1 para um VMware SD-WAN Edge.
Para um Edge onde a firewall está ativa mas não tem regras configuradas, na página Configuração > Firewall (Configure > Firewall) do Edge, se o utilizador configurar uma regra de Encaminhamento de porta ou uma regra de NAT 1:1 e tentar guardar essa regra, o VMware SD-WAN Orchestrator não guardará a regra e, em vez disso, apresentará um erro “networkSegments não é iterável” (networkSegments is not iterable) na página. Este problema é provocado pelo facto de o Orchestrator utilizar o segmentID como índice de matrizes para a matriz networkSegments.
Problema 66801 resolvido: No site de um cliente que utilize uma topologia de alta disponibilidade e um VNF, o cliente pode não ser capaz de se ligar a um VNF para efetuar o estabelecimento de confiança a partir de um servidor de gestão.
O problema é observado em locais HA quando as interfaces encaminhadas têm o DHCP ativado e não existe um caminho predefinido presente na tabela de caminhos do núcleo. Neste caso, o núcleo responde com “Destino ICMP inalcançável” (ICMP destination unreachable).
Sem a correção, a solução alternativa para evitar este problema é adicionar um caminho predefinido no Edge em standby para que o Edge não envie “ICMP inalcançável” (ICMP Unreachable) de volta para a VM VNF, fazendo com que a ligação SSH seja reposta.
Problema 66901 resolvido: Quando um cliente atualiza os respetivos VMware SD-WAN Edges para a versão 3.2.2, pode observar que alguns dos Edges não aparecem após a atualização.
O problema ocorre muito raramente, mas, quando ocorre, o cliente vê nas mensagens de eventos do Orchestrator (e nas mensagens de registo) do utilizador o processo a terminar e encerrar no Edge, mas o Edge não se liga depois de desligar. Em vez disso, o Edge é desativado e o Orchestrator mostra o estado do mesmo como “Inativo” (Down) com uma mensagem de evento de “Edge inativo” (Edge down).
Sem a correção, a forma de remediar este problema é voltar a ligar o Edge e efetuar uma reposição de fábrica manual. Após a reposição, o Edge funcionará como antes e terá de ser reativado para o site do cliente.
Problema 67060 resolvido: O VMware SD-WAN Edge pode apresentar uma grande utilização da memória, o que pode potencialmente provocar um reinício do serviço Edge caso seja suficientemente elevada.
O problema é uma fuga de memória que se manifesta como um aumento lento e contínuo da utilização da memória. O problema ocorre quando vários pacotes de pedido HTTP são enviados para um único fluxo; a fuga de memória ocorre especificamente enquanto o Edge está a analisar os pacotes de pedido HTTP.
Problema 67083 resolvido: Um VMware SD-WAN Edge pode encontrar uma falha do Serviço dataplane e, como resultado, reiniciar com uma breve perturbação do tráfego do cliente.
Em alguns cenários, o pacote de dados do protocolo de gestão VeloCloud (VCMP) é processado com os parâmetros errados (por exemplo, um pacote de dados é incorretamente classificado como um pacote de controlo), o que aciona uma exceção e o reinício do serviço.
Problema 67173 resolvido: Quando o mesmo caminho é aprendido a partir de vários vizinhos IBGP, o segundo melhor caminho selecionado a partir do processo BGP está a ser utilizado pelo VMware SD-WAN Edge, o que resulta na colocação de determinado tráfego do cliente numa condição de buraco negro.
Devido a um problema no conjunto de routing de intervalo livre (Free Range Routing – FRR), o IBGP estava a enviar vários hops seguintes para o Edge e a escolher o segundo melhor (último na ordem de hop seguinte) para atualizar a base de informações de encaminhamento (FIB). A correção inclui um comando no processo BGP para enviar apenas o melhor hop seguinte para o Edge.
Problema 67191 resolvido: Para um cliente que utilize um Serviço de Segurança na Cloud (CSS), a verificação do estado de funcionamento da camada 7 devolve uma falha errada e os túneis CSS são eliminados.
Quando existe um grande número de túneis do Destino Não-SD-WAN (NSD) num VMware SD-WAN Gateway, o IP da Interface do Túnel Virtual (VTI) pode sair do intervalo da máscara de sub-rede /24, cuja definição permite que as sondas sejam processadas pelo Serviço dataplane do Gateway. Isto é o que provoca uma falha errada da verificação do estado de funcionamento da L7. A correção atualiza a máscara para /16 para aceitar a L7 para o processamento no serviço dataplane do Gateway.
Sem a correção, a única solução é que um operador com acesso ao Gateway altere manualmente o ficheiro /opt/vc/bin/gwd_ip_setup.sh para refletir a alteração da máscara (169.254.0.0/24 para 169.254.0.0/16), seguindo-se um reinício do serviço de Gateway.
Problema 67197 resolvido: Uma rede de cliente pode sofrer perturbações periódicas do serviço multicast em implementações com mais de 1500 origens associadas a um grupo multicast.
Um problema de software na lógica de processamento de mensagens de unir/eliminar conjuntos PIM falha com uma exceção ao processar atualizações de unir/eliminar em implementações com mais de 1500 origens associadas a um grupo multicast.
Sem a correção, a única forma de evitar este problema é limitar o número total de origens multicast a 1000.
Problema 68785 resolvido: O software VMware SD-WAN Edge descarta os pacotes DHCP INFORM quando são recebidos numa interface configurada como um reencaminhamento DHCP.
Os clientes DHCP podem solicitar informações adicionais de rede, como o servidor DNS ou o endereço do Gateway, com a mensagem DHCP INFORM após a aquisição de um endereço IP. Quando o Edge é configurado como um agente de reencaminhamento, estas mensagens INFORM devem ser encaminhadas para o servidor DHCP, mas, em vez disso, são descartadas.
Problema 68829 resolvido: Nos modelos VMware SD-WAN Edge LTE (por outras palavras, o Edge 510-LTE ou o Edge 610-LTE), os caminhos IPv6 não são formados através das respetivas interfaces LTE.
Os pacotes udp6 são enviados com uma soma de verificação de 0, fazendo com que sejam descartados no próximo hop. Isto resultava na colocação dos caminhos de gestão SD-WAN num estado INIT. O comportamento correto é preencher a soma de verificação para os pacotes udp6.
Problema 68840 resolvido: Para um cliente que utilize uma topologia de alta disponibilidade, a consulta de SNMP não consegue obter informações de LAN e WAN do VMware SD-WAN Edge em standby.
Para HA SNMP GET, a contagem de LAN/WAN em standby (vceHaStandbyLanItfNum e vceHaStandbyWanItfNum) é apresentada parcialmente ou não é apresentada.
Problema 67201 resolvido: Num site que utilize uma topologia de alta disponibilidade, o cliente pode observar vários reinícios do VMware SD-WAN do Edge em standby com uma potencial disrupção do tráfego do cliente.
Quando o Edge em standby é detetado, o Edge Ativo sincroniza todas as informações de caminho para o Edge em standby. No entanto, quando existe um número elevado de mensagens de sincronização de caminho, a forma como o Edge processa estas mensagens de sincronização de caminho pode levar a uma falha do Serviço dataplane no Edge em standby ou a uma inversão da prioridade do thread, o que causará um atraso no processamento do heartbeat, enquanto o processamento pode levar a um estado Ativo/Ativo. Em qualquer situação, numa topologia HA convencional, o impacto do cliente deverá ser mínimo, dado que o Edge em standby não está a passar o tráfego do cliente. No entanto, numa implementação HA melhorada, onde o Edge em standby também está a passar tráfego, os reinícios perturbarão algum tráfego do cliente. Um Edge HA que inclui esta correção melhorou o caminho do código de processamento de informações para evitar que o problema ocorra.
Problema 67694 resolvido: Um cliente pode encontrar uma falha no túnel do Serviço de Segurança na Cloud (CSS) porque as sondas de Verificação de estado de funcionamento de L7 do estado de funcionamento são interligadas condicionalmente.
As sondas de Verificação de estado de funcionamento de L7 do estado de funcionamento nunca devem ser sistematicamente interligadas e falham quando isto acontece, o que faz com que os túneis CSS sejam erradamente marcados como desativados.
Problema 67259 resolvido: O fluxo de tráfego multicast é perturbado quando o processo PIM reinicia várias vezes e o vizinho PIM não surge.
Numa configuração à escala com 1600 vizinhos PIM, ao reiniciar o processo PIM várias vezes enquanto o tráfego está em execução de 700 Edges Spoke para um recetor atrás de um Edge Hub, após um dos reinícios, apenas 570+ vizinhos PIM surgiam dos 1600 vizinhos PIM. A única forma de resolver este problema é reiniciar o serviço Edge.
Problema 67745 resolvido: Um VMware SD-WAN Edge que tem uma ligação WAN a alguns routers fornecidos pelo ISP poderá enfrentar problemas de tráfego do cliente se esse caminho do ISP ficar inativo e, em seguida, for reativado.
Quando uma ligação WAN do Edge a alguns routers do ISP (este problema foi encontrado com um router do ISP utilizado pela Spectrum) fica inativa ou o router do ISP fica inativo e, em seguida, é reativado, o router do ISP executa um diagnóstico que inclui a atribuição breve de um IP privado ao Edge na sub-rede 192.168.100.0/24 e, depois disso, atribui o endereço IP público. No entanto, o Edge instala o caminho ligado para 192.168.100.0/0 e este não é limpo depois de obter o endereço IP público.
Problema 67790 resolvido: Na empresa de um cliente que utilize o BGP ou o OSPF e configurou os filtros de entrada para ignorar certos caminhos, quando o Cálculo dinâmico de custos (DCC) estiver ativado nesta empresa, os filtros de entrada deixarão de estar em vigor e o tráfego tentará utilizar esses caminhos.
Antes de o DCC ser ativado, a base de informações de encaminhamento (FIB) não incluirá os caminhos que foram definidos para IGNORAR (IGNORE) no filtro de entrada BGP/OSPF. Depois de o DCC ser ativado, a FIB inclui agora estes caminhos e o tráfego tentará utilizá-los com o potencial para uma perturbação significativa do tráfego para a empresa do cliente.
Sem a correção, a única solução alternativa é reiniciar o OSPF/BGP para que o filtro de entrada seja corretamente aplicado.
Problema 67869 resolvido: Quando um VMware SD-WAN Hub Edge tiver sido configurado previamente como pilha única IPv4 e, mais tarde, é alterado para pilha dupla IPv6 preferencial, o túnel IPv4 mais antigo não será desligado.
Quando este problema se manifesta, o cliente observa uma contagem incorreta de túneis porque os túneis IPv4 não estão a ser desativados. Com efeito, o número de túneis duplica.
Problema 67889 resolvido: A consulta de SNMPv3 pode não funcionar corretamente para um cliente que consulte vários VMware SD-WAN Edges.
O problema é que o VMware SD-WAN permite que o snmpd gere um engine_id aleatório para cada Edge e, em muitos casos, este engine-id é duplicado para vários Edges. Quando isso acontece, um dos Edges com o mesmo engine-id não comunica estatísticas ao coletor.
Problema 67947 resolvido: Com o NAT do lado LAN configurado, o tráfego entre VLANs não funciona após uma atualização da versão do caminho.
A regra NAT do lado LAN é ignorada para o tráfego entre VLANs, mas quando a versão do caminho é atualizada, a procura de caminho ocorre com o IP errado e isso pode fazer com que o tráfego falhe.
Problema 68994 resolvido: Os clientes que implementem um túnel de Destino Não-SD-WAN (NSD) a partir de um VMware SD-WAN Edge com um VMware SD-WAN Gateway podem observar instabilidade no túnel.
Este problema é observado no estabelecimento do túnel ou na recodificação da IKE. O Edge ou o Gateway elimina as associações de segurança (SAs) com base em IKESAID=0, o que provoca a instabilidade no túnel. O túnel estabiliza automaticamente, mas o tempo necessário para o fazer não é consistente e tal pode aumentar o impacto no tráfego do cliente para o NSD.
Problema 69194 resolvido: Se um utilizador mover um modem USB de uma porta USB para uma porta diferente num VMware SD-WAN Edge, o Edge poderá encontrar uma falha no Serviço dataplane e reiniciar como resultado.
As portas USB são incorretamente associadas aos controladores DPDK AF_PACKET. Este controlador não suporta a remoção de portas e pode fazer com que o serviço dataplane do Edge falhe quando o dongle USB é movido de uma porta para outra.
Problema 69497 resolvido: Os MIBs do VMware SD-WAN mostram o objeto SNMP vceLinkVpnState, apesar de o mesmo já não ser um objeto válido.
O VMware SD-WAN já não mostra um estado de VPN diferenciado no VMware SD-WAN Orchestrator, mas, ainda assim, expõe isto no SNMP. Mais especificamente, o coletor SNMP procura o SNMP OID 1.3.6.1.4.1.45346.1.1.2.3.2.2.1.26, o que já não deveria fazer.
Problema 69681 resolvido: Se um VMware SD-WAN Edge estiver configurado com ligações WAN de reserva dinâmica e também utilizar a consulta de SNMP, o utilizador observará erros do SNMP.
A mensagem de erro seria semelhante à seguinte:
ERROR [oids (10028:MainThread:10028)] [VCE.Path]<update>: Path failed update buffer: KeyError('HOTSTANDBY_IDLE',) INFO [oids (10028:MainThread:10028)] [VCE]<update_if_stale>: Current MIB buffer size: 217 DEBUG [oids (10028:MainThread:10028)] [VCE.Link]<ip2octet>: Failed to convert IP to Octet for caller <class 'vcsnmp.oids.Link'>[publicIpAddress] on []: ValueError("invalid literal for int() with base 10: ''",), used default value[00 00 00 00] instead
A causa do problema é que os estados do caminho SNMP não incluem estados de ligação de reserva dinâmica e isso causa problemas do SNMP, incluindo mensagens de erro.
Problema 69704 resolvido: Ativar a alta disponibilidade num site com uma plataforma VMware SD-WAN Edge 6x0 (610, 620, 640, 680) pode interromper a comunicação do Edge com o VMware SD-WAN Orchestrator.
Depois de ativar a HA, devido a certas condições de tempo relacionadas com o tempo que as interfaces 6x0 demoram a surgir, a comunicação com o Orchestrator é interrompida. Deste modo, a HA não ocorre e o Edge perde a conetividade total com o Orchestrator, o que significa que o Orchestrator irá marcar o Edge como inativo, não sendo possível efetuar mais alterações de configuração.
Problema 70041 resolvido: Um parceiro que atualize os respetivos VMware SD-WAN Gateways para a versão 4.3.0 observa que já não pode enviar um ping para o endereço IP VRF do Gateway.
Quando o ping falha, o contador route_drop é incrementado. O envio de pings ao endereço IP VRF de uma interface de handoff foi desativado com a versão 4.3.0 e é restaurado com a correção encontrada na versão 4.3.1.
Problema 70154 resolvido: Na empresa de um cliente em que a Firewall com estado está ativada, o utilizador observará pacotes ignorados ao enviar pings bidirecionais entre clientes de ramos com o mesmo ID ICMP.
Se for iniciado um ping do Cliente A no Ramo 1 para o Cliente B no Ramo 2 e vice-versa, os estados do ICMP de ambos os pings serão rastreados com o mesmo objeto de fluxo se o ID ICMP for o mesmo e isso poderá levar a vários pacotes ignorados devido à verificação do número de sequência.
Sem esta correção, a solução é desativar a Firewall com estado ou gerar ping com IDs ICMP diferentes.
Problema 70310 resolvido: Para um cliente que utiliza vários segmentos, quando um ou mais segmentos são eliminados ou desativados, um VMware SD-WAN Edge pode sofrer uma falha no Serviço dataplane e reiniciar esse serviço, provocando uma breve perturbação no tráfego do cliente.
Quando um segmento é eliminado, o Edge não limpa completamente a memória associada ao mesmo. Existem cenários em que o Edge ativo sincroniza eventos para o Edge em standby, fazendo referência a tais segmentos, o que resulta numa falha de serviço no Edge em standby, uma vez que estes segmentos não estão presentes.
Problema 70349 resolvido: Em casos raros, o tráfego NAT deixa de funcionar num VMware SD-WAN Gateway. Reiniciar o serviço do Gateway limpará a condição.
Devido a uma condição race no processo dataplane do Gateway, o Gateway poderá não conseguir estabelecer ligação com o natd (o daemon no Gateway que gere as alocações de NAT) e, assim, não será capaz de alocar entradas NAT. Isto fará com que todos os fluxos NAT através do Gateway falhem.
Problema 70416 resolvido: O VMware SD-WAN Gateway pode apresentar uma carga elevada da CPU, o que resulta em perda de pacotes e latência para os Edges que o utilizam como o seu Gateway principal.
Este problema é causado por threads de caminho rápido do Gateway (IKE, dados VCMP, etc.), que gastam entre 15 e 20% dos seus ciclos a realizar operações InetNtop. A correção para este problema remove as operações InetNtop e substitui-as por um processo de formatação de dados mais eficiente.
Problema 70438 resolvido: Os clientes que têm tráfego que depende da NAT podem sofrer perturbações do mesmo quando um VMware SD-WAN Gateway é atualizado para a versão 4.3.0 ou é reiniciado durante a execução da versão 4.3.0.
No arranque do Gateway, pode existir uma condição race que elimina a entrada NAT de “gwd_cloud_read”, apesar de a entrada NAT já poder estar colocada em cache no fluxo (fc->nat_tup) na direção SEND_TO_WAN. Apesar de a entrada NAT ser eliminada, o fluxo continuará a utilizar o nat_tup em cache para a aplicação de NAT. Enquanto isso, outro fluxo pode ter a mesma porta de origem atribuída com uma nova entrada NAT.
Problema 70590 resolvido: Uma tentativa de gerar um pacote de diagnóstico num VMware SD-WAN Gateway com a versão 4.3.0 pode falhar.
Os pacotes de diagnóstico gerados num Gateway com a versão 4.3.0 falham porque o pacote de diagnóstico excede o limite de tamanho configurado no Orchestrator. O tamanho excessivo do pacote de diagnóstico é causado pelo tamanho dos registos de auditoria, que crescem ao longo do tempo.
Sem esta correção, a única forma de gerar com êxito um pacote de diagnóstico num Gateway é um utilizador operador iniciar sessão no Gateway e, antes de ativar o pacote de diagnóstico no Orchestrator, eliminar os ficheiros de registo de auditoria no diretório /var/log/audit do Gateway.
Problema 70789 resolvido: O cliente pode sofrer situações em que o tráfego é aleatoriamente eliminado devido à deteção antirreprodução do IPSec.
Se um VMware SD-WAN Edge ou VMware SD-WAN Gateway receber dois pacotes em que cada um deles atualiza o número de sequência de entrada em cache, é possível que o primeiro pacote atualize incorretamente a janela de reprodução, o que pode acionar a deteção antirreprodução do IPsec e fazer com que o pacote IPsec seja eliminado.
Problema 70855 resolvido: Um VMware SD-WAN Gateway pode perder tráfego proveniente do VMware SD-WAN Orchestrator, podendo impedir alguma atualização da configuração do Gateway a partir do Orchestrator.
Quando a carga do Gateway é elevada (por exemplo, cerca de 1,6 milhões de fluxos no Gateway com uma contagem de objetos NAT de cerca de 800 mil), o número de memórias intermédias de pacotes no sistema será esgotado e isso pode, por vezes, fazer com que o tráfego do Orchestrator seja ignorado no Gateway. Assim que o Gateway entrar neste estado, o tráfego do Orchestrator é sempre ignorado, mesmo que as memórias intermédias de pacotes fiquem disponíveis.
Sem a correção, a única solução para este problema é reiniciar o Gateway.
Problema 70954 resolvido: O VMware SD-WAN Edge poderá sofrer várias falhas do Serviço dataplane se tiver uma política empresarial configurada com uma ligação obrigatória a um Serviço de Segurança na Cloud Zscaler e a interface dessa ligação obrigatória falhar.
O Edge deveria descartar o tráfego para o Zscaler quando a interface obrigatória falhasse, em vez de sofrer uma falha de serviço.
Problema 71052 resolvido: Quando o número de empresas de cliente a estabelecer ligação a um VMware SD-WAN Gateway é superior a 285, o Gateway experiencia uma falha do serviço dataplane. A partir do Gateway versão 4.3.0, a capacidade do Gateway de monitorizar clientes foi melhorada ao adicionar novos contadores para rastrear as informações relacionadas com o fluxo e o pacote ao nível da empresa do cliente. O problema é que o número de contadores inicializados para as empresas de cliente esgota-se após 285 empresas de cliente e a inicialização de contadores para qualquer novo cliente adicional irá falhar, o que provoca a falha do Serviço de dataplane do Gateway e força um reinício do serviço.
A partir do Gateway versão 4.3.0, a capacidade do Gateway de monitorizar clientes foi melhorada ao adicionar novos contadores para rastrear as informações relacionadas com o fluxo e o pacote ao nível da empresa do cliente. O problema é que o número de contadores inicializados para as empresas de cliente esgota-se após 285 empresas de cliente e a inicialização de contadores para qualquer novo cliente adicional irá falhar, o que provoca a falha do Serviço de dataplane do Gateway e força um reinício do serviço.
71513: Um utilizador que consultasse o separador Gateways > Monitor na IU de um VMware SD-WAN Orchestrator observaria que as Handoff Queue Drops mostram sempre um valor de 0 para um VMware SD-WAN Gateway com a versão 4.3.0.
Os Gateways com a versão 4.3.0 ou superior não comunicam Handoff Queue Drops ao Orchestrator devido a formatação incorreta e isto impede que o operador obtenha uma imagem clara deste ponto de dados específico de resolução de problemas.
Problema 71977 resolvido: quando um utilizador ativa o VMware Edge Network Intelligence num VMware SD-WAN Edge, o Edge sofre uma falha do Serviço dataplane e gera um núcleo.
Este problema ocorrerá se o número de sessões criadas dinamicamente no Edge exceder o limite máximo permitido.
Problema 72100 resolvido: Num site que utiliza uma topologia de alta disponibilidade melhorada em que um par do VMware SD-WAN Edge 610 é utilizado para essa implementação, os túneis não serão estabelecidos através da ligação WAN no Edge 610 em standby.
O problema só é observado no caso do modelo Edge 610 em que os túneis não estão a ser estabelecidos através do Edge em standby. Antes de ativar a HA, se a VLAN na interface GE1 não tiver um endereço IP, o serviço SD-WAN não mapeará a porta de comutação de hardware para o GE1 após a ativação da HA. Como resultado, os pacotes serão descartados no Edge em espera.
Sem a correção, a solução para este problema é adicionar um endereço IP à VLAN para que a interface GE1 seja mapeada para uma porta no comutador de hardware.
Problema 72567 resolvido: Se um utilizador configurar deliberadamente o routing assimétrico através de um underlay (MPLS sem overlay WAN) no caminho de routing através de uma política empresarial fixed_link e, em seguida, através de um overlay (por exemplo, um Edge Hub) no caminho inverso, o fluxo será interrompido e o tráfego desse fluxo não será bem-sucedido.
Trata-se de um routing assimétrico de fluxos da cloud por design, em que o Edge tem uma política empresarial para forçar a saída dos fluxos do underlay (INTF_ROUTED). O Edge remoto encaminha a resposta de volta através de um Edge Hub (overlay). O Edge remoto vê o fluxo como um novo fluxo iniciado localmente e envia uma sincronização QoS para atualizar os parâmetros de routing de fluxo, o que leva a uma interrupção do mesmo. Na correção, a sincronização QoS é rejeitada para evitar que o link_mode configurado seja substituído.
Problema 72688 resolvido: O VMware SD-WAN Edge reinicia aleatoriamente o seu serviço dataplane, o que resulta em interrupções do serviço.
Os pacotes afixados a um thread de desencriptação são rejeitados pelo thread não proprietário quando flutuam para outro thread de desencriptação. No processo de rejeição dos pacotes, a referência criptográfica QAT associada era incorretamente libertada, causando exceções no Serviço dataplane, assim como uma falha e um reinício.
Problema 72703 resolvido: Uma interface encaminhada do VMware SD-WAN Edge configurada com uma sub-interface permite fluxos cujos caminhos pertencem às sub-interfaces da interface.
Um fluxo que corresponda a um caminho pertencente a uma sub-interface é permitido com sucesso na respetiva interface principal cujo modo de reverse path forwarding (RPF) está definido como “específico” (specific). A causa principal deve-se à procura source_route ignorar a VLAN no conjunto de correspondências.
Problema 72718 resolvido: No site de um cliente que utilize um Destino Não-SD-WAN (NSD) via Edge, em que o backhaul da Internet está configurado para encaminhar o tráfego através do NSD via Edge, o tráfego falha para destinos com a regra de backhaul.
O backhaul para um NSD via Edge falha devido a um problema decorrente do facto de o ID de destino não ter sido substituído. O tráfego anterior que não estava a ser interligado ao NSD corresponde a um caminho da cloud predefinido cujo destino é o Gateway. O serviço SD-WAN não substitui o destino do caminho da cloud mais antigo com o ID lógico do NSD mais recente e, portanto, o tráfego falha durante a correspondência de regra de backhaul.
Problema 72939 resolvido: Um utilizador pode observar a contagem de fluxos obsoletos de um VMware SD-WAN Gateway a aumentar constantemente até atingir os fluxos máximos suportados para as especificações desse Gateway e, assim, deixam de ser criados novos fluxos, o que causa perturbações para os utilizadores ligados a esse Gateway.
A contagem crescente de fluxos obsoletos está associada a sites que enviam tráfego de um Destino Não-SD-WAN para um handoff de Gateway de parceiro. Foram adicionadas duas funções, “gw_nvs_to_pg_pkt” e “gw_send_nvs_pkt”, quando as contagens de fluxos não são libertadas após a procura.
Sem a correção, a única solução é reiniciar o serviço do Gateway.
Problema 73251 resolvido: Os utilizadores que necessitem de efetuar a autenticação via RADIUS podem descobrir que não o conseguem fazer porque o tráfego fragmentado não está a ser enviado do VMware SD-WAN Edge.
O tráfego RADIUS é sempre fragmentado e este problema afeta ainda mais os utilizadores que tentam efetuar a autenticação numa ligação sem fios. Quando este problema ocorre, a contagem de pacotes fragmentados é superior àquela com que o DPDK consegue lidar na interface específica afetada. A correção repõe proactivamente a contagem de fragmentação para evitar perturbações no tráfego.
Problema 73320 resolvido: Quando a interface de um VMware SD-WAN Edge é configurada com um tipo de endereço DHCP e o endereço IP atribuído à interface é atualizado, alguns dos fluxos diretos podem falhar devido à falha de NAT.
Quando a concessão de DHCP expira, o endereço IP é removido para a interface. Antes de um novo IP ser atribuído à interface, são criadas entradas NAT para quaisquer novos fluxos com “0.0.0.0” como o IP NAT de origem e os pacotes são eliminados. Uma vez atribuído um endereço IP válido à interface, a entrada NAT existente não é eliminada e uma nova entrada NAT não é criada com um IP válido, o que faz com que o tráfego seja descartado.
Problema 73987 resolvido: Um VMware SD-WAN Edge pode encontrar uma falha no Serviço dataplane ao tentar gerar um pacote de diagnóstico.
A parte principal do pacote de diagnóstico que está a causar o problema é quando o Edge precisa dos registos para “vcdgbdump -r remote_routes”. Neste cenário, quando há um grande número de caminhos remotos, existe tráfego que utiliza esses caminhos e é acionada uma recolha de pacotes de diagnóstico, existe o potencial de contenção de bloqueios.
Problema 74313 resolvido: No site de um cliente que utilize um modelo LTE de um VMware SD-WAN Edge (por outras palavras, o Edge 510-LTE ou o Edge 610-LTE), o Edge perderá a comunicação com o VMware SD-WAN Orchestrator após o reinício do Edge se tiver apenas uma ligação WAN LTE.
A conectividade entre o Orchestrator e o Edge será perdida, uma vez que a acessibilidade do caminho predefinido através da interface LTE torna-se falsa após o reinício do Edge. Como resultado, o Edge será marcado como inativo pelo Orchestrator, embora o tráfego do cliente ainda esteja a passar na ligação WAN LTE.
Sem a correção, a única forma de recuperar a acessibilidade do Edge é efetuar um reinício do serviço Edge.
Problema 74482 resolvido: Para um cliente que utilize uma topologia de rede Hub-Spoke, o caminho de um VMware SD-WAN Spoke Edge não é aprendido num Hub Edge se esse Hub Edge também for um Spoke para um Hub Edge diferente.
Para que este problema ocorresse, o cliente também teria o Edge a Edge via Hub configurado. Quando as implementações do cliente têm um Edge implementado como um Hub para determinados Spokes e um Spoke para determinados Hubs, esse Edge não recebe os caminhos do Spoke do VMware SD-WAN Gateway. Este problema tem um grande impacto numa rede com esta topologia devido aos caminhos em falta.
Sem esta correção, a única forma de evitar este problema é desativar o Edge a Edge via Hub nos Spoke Edges.
Problema 75309 resolvido: Um utilizador pode observar uma queda de tráfego multicast num grupo específico num VMware SD-WAN Edge Spoke.
O tráfego multicast num grupo específico não é recebido no Edge Spoke quando é proveniente de um Edge Hub. Os grupos IGMP não estão preenchidos na tabela de grupos IGMP do Edge Spoke, o que leva à perda de tráfego. Isto pode ser observado nos registos de pacotes de diagnóstico do Edge Spoke para o igmp.
Problema 75968 resolvido: Quando um utilizador configura o handoff de um endereço IP local para um VMware SD-WAN Gateway e, em seguida, remove esse handoff, o handoff não é removido do Gateway, o que faz com que o caminho do túnel fique inativo.
Este problema pode causar grandes perturbações, uma vez que o Gateway não pode criar um novo túnel.
Sem a correção, o utilizador terá de reiniciar o Gateway para resolver o problema.
Problema 76726 resolvido: Um VMware SD-WAN Gateway pode encontrar uma falha no Serviço dataplane e gerar um núcleo.
A causa da falha do serviço do Gateway e do núcleo prende-se com o facto de o pacote ctrl do protocolo de gestão ser trocado entre um Edge e o Gateway. O Gateway poderá falhar devido às afirmações e isso poderá causar uma paragem para vários clientes. Este problema é resolvido ao remover as afirmações e configurar o processamento adequado de erros.
A versão R431-20220715-GA do Orchestrator foi lançada em 22-07--2022 e é o terceiro rollup do Orchestrator para a versão 4.3.1.
Esta compilação de rollup do Orchestrator aborda os problemas críticos abaixo desde o segundo rollup do Orchestrator, versão R431-20220429-GA.
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 Orchestrator que não incluísse a correção, o Operador teria de implementar o sistema com um ficheiro ISO cloud-init user-data.
Nota: esta entrada regista apenas o Orchestrator OVA. A correção para o Gateway OVA está registada com o mesmo pedido 88796, mas na secção Problemas resolvidos do Edge/Gateway da compilação de Gateway R431-20220518-GA.
Problema 76016 resolvido: Quando um handoff de Gateway de parceiro é configurado após a atualização de um VMware SD-WAN Orchestrator para a versão 4.3.0 ou posterior, os subcomponentes no handoff, como os caminhos estáticos/BGP/BFD, não podem ser eliminados a partir da API ou IU do Orchestrator por um Administrador de parceiro.
Este problema ocorria devido a uma regressão na lógica de processamento da configuração de subcomponentes para eliminação no back-end do Orchestrator. Anteriormente, foi adicionada uma correção para conjuntos de Gateways mistos (Gateways de cloud + parceiro) em que, se um Administrador de parceiro modificasse um Gateway de parceiro, tal não afetava a configuração de handoff do Gateway de cloud. No entanto, esta correção não tinha em conta os casos que envolviam a eliminação de subcomponentes.
Num Orchestrator que não inclui esta correção, existem duas soluções alternativas:
O parceiro pode pedir a um utilizador operador (por exemplo, Suporte VMware) para efetuar a eliminação sem problemas, uma vez que este problema apenas afeta os utilizadores parceiros.
O utilizador parceiro pode remover todo o handoff do Gateway de parceiro e voltar a criá-lo com a configuração revista.
A versão R431-20220429-GA do Orchestrator foi lançada em 05-05-2022 e é o segundo rollup do Orchestrator para a versão 4.3.1.
Esta compilação de rollup do Orchestrator aborda os problemas críticos abaixo desde o primeiro rollup do Orchestrator, versão R431-20220222-GA.
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 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”.
A versão R431-20220222-GA do Orchestrator foi lançada em 23-02-2022 e é o primeiro rollup do Orchestrator para a versão 4.3.1.
Esta compilação rollup do Orchestrator soluciona as vulnerabilidades do Apache Log4j CVE-2021-44228 (que foi abordada pela primeira vez na compilação R431-20211217-GA do Orchestrator com a versão 2.16.0 do Log4j) e CVE-2021-45046 ao atualizar para a versão 2.17.0 do Log4j. Para obter informações atualizadas sobre as vulnerabilidades do Apache Log4j e o respetivo impacto nos produtos VMware, consulte o VMware Security Advisory VMSA-2021-0028.9
Além disso, esta compilação rollup do Orchestrator aborda também o seguinte problema crítico desde a compilação de GA do Orchestrator original, versão R431-20211217-GA.
Problema 81498 resolvido: Quando um VMware SD-WAN Edge que execute a versão 4.2.x e que também esteja configurado com um IP de gestão não predefinido substituído é atualizado para a versão 4.3.x ou superior num VMware SD-WAN Orchestrator com a versão 4.3.x ou superior, o Edge pode perder o IP de gestão substituído configurado.
O Orchestrator que execute a versão 4.3.x ou superior não está automaticamente a criar a interface de retorno, enquanto mantém também o IP de gestão não predefinido substituído para um Edge quando o Edge é atualizado da versão 4.2.x para uma versão 4.3.x ou uma compilação posterior.
Problema 80613 resolvido: Num VMware SD-WAN Orchestrator configurado para a recuperação após desastre (DR), a replicação pode falhar entre os Orchestrators ativos e em standby, com o utilizador a observar o estado A copiar DB (Copying DB) como “Falhado” (Failed) na IU do Orchestrator.
Desde a versão 8.0.26 do MySQL, a opção de dados principais foi descontinuada no comando mysqldump. Foi substituída pela opção de dados de origem. Este problema ocorre porque o processo DR do Orchestrator utiliza o comando mysqldump com a opção de dados principais. No entanto, com a atualização do MySQL para a versão mais recente, esta opção já não funciona e, por isso, interrompe a DR. Para resolver este problema, o Orchestrator com esta correção utiliza a opção de dados de origem em vez da opção de dados principais para o comando mysqldump durante o processo de DR.
Problema 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).
A página Visão geral do Parceiro (Partner Overview) e/ou uma página Configurar > Cliente (Configure > Customer) para um cliente suportado por esse parceiro pode não ser carregada 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.
A versão R431-20211217-GA do Orchestrator foi lançada a 20-12-2021. Esta compilação do Orchestrator remedeia a CVE-2021-44228, a vulnerabilidade do Apache Log4j, ao atualizar para a versão Log4j 2.16.0. Para obter mais informações sobre a vulnerabilidade do Apache Log4j, consulte o VMware Security Advisory VMSA-2021-0028.5.
Os problemas abaixo foram resolvidos a partir da versão R430-20211112-GA do Orchestrator.
Problema 77116 resolvido: O VMware SD-WAN Orchestrator mantém os registos durante menos de 12 meses.
Atualmente, o Orchestrator mantém os registos durante 6 meses, mas alguns clientes precisam de, pelo menos, 12 meses de histórico de registos.
Problema 75879 resolvido: Em alguns casos, o VMware SD-WAN Orchestrator não responde aos eventos de routing de um VMware SD-WAN Edge e isso resulta num aumento da carga no Orchestrator.
Quando um Orchestrator não responde aos eventos de routing de um Edge, o Edge tenta utilizar repetidamente os caminhos, causando o aumento da carga no Orchestrator. Esta é a correção permanente para este problema.
Problema 75656 resolvido: Em alguns casos, depois de processar os eventos de routing de um VMware SD-WAN Edge, o VMware SD-WAN Orchestrator responde com um ack vazio (que é tão mau quanto uma não resposta) e isso resulta num aumento da carga no Orchestrator.
Quando um Orchestrator envia um ack vazio para os eventos de routing de um Edge, o Edge tenta utilizar repetidamente os caminhos, causando o aumento da carga no Orchestrator.
Problema 74450 resolvido: O VMware SD-WAN Orchestrator não exporta contadores de marca de água para uma aplicação externa, como o Telegraf ou o Prometheus.
Este pedido está ligado ao problema 74446, cuja correção cria contadores de marca de água para Handoff Queue Drops do Gateway. Este pedido garante que essas métricas podem ser recolhidas por uma aplicação como o Telegraf ou o Prometheus.
Problema 74446 resolvido: Os contadores de Handoff Queue Drop do Gateway não estão a servir o propósito de identificar picos de tráfego quando observados na IU do VMware SD-WAN Orchestrator.
O Handoff Queue Drop do Gateway não é suficientemente granular para identificar picos de tráfego. A correção deste problema adiciona novos contadores de marca d’água: wmark_1min e wmark_5mins, que darão a profundidade máxima de uma fila de handoff dentro de 1 minuto e 5 minutos, respetivamente.
Problema 72841 resolvido: O VMware SD-WAN Orchestrator é inconsistente ao gerar eventos “Gateway ativo” (Gateway up). Sempre que o estado do Gateway é alterado de OFFLINE para LIGADO (CONNECTED), o evento “Gateway ativo” (Gateway up) não é registado em todos os casos.
O problema ocorre de forma inconsistente, mas quando ocorre, existem mais de dois Gateways e o updateStateChange é ativado para ambos ao mesmo tempo. Quanto mais Gateways estiverem disponíveis, se todos sofrerem uma alteração de estado ao mesmo tempo, mais provável será a ocorrência do problema.
Problema 71399 resolvido: Num VMware SD-WAN Orchestrator implementado numa configuração de recuperação após desastre (DR), o utilizador operador pode observar que o Orchestrator em standby não conseguiu sincronizar com o Orchestrator ativo.
Na IU do Orchestrator na página Replicação (Replication), um utilizador observaria todas as atividades de sincronização como falhadas no Monitor de atividade (Activity Monitor). A falha de sincronização DR ocorre no handshake inicial em que o Orchestrator ativo não consegue copiar a base de dados de configuração para o Orchestrator em standby.
Problema 70018 resolvido: Um VMware SD-WAN Orchestrator com a versão 4.3.0 ou superior pode não ser capaz de formar um par de recuperação de desastres.
A causa impede o Orchestrator de obter o espaço livre no disco necessário para a recuperação de desastres e, por conseguinte, a recuperação de desastres pode falhar.
Problema 69534 resolvido: Para um cliente que utilize o VMware Edge Network Intelligence, quando um utilizador clica em qualquer lugar na página Monitorização (Monitoring) principal do cliente na nova IU do Orchestrator, as ligações de “Análise de aplicação” (Application Analytics) e “Análise de ramo” (Branch Analytics) desaparecem.
Se o utilizador recarregar a página, essas ligações reaparecerão até o utilizador clicar em qualquer lugar na mesma página e, em seguida, desaparecerão novamente. Devido a isto, o utilizador não conseguirá ver os dados de monitorização de “Análise de aplicação” (Application Analytics) e “Análise de ramo” (Branch Analytics), a menos que saiba que tem de recarregar a página.
Problema 69514 resolvido: A geração de relatórios pode falhar com o erro “Falha ao atualizar os dados de blobs para PDF” (Failed to update blob data for PDF).
Quando o utilizador tenta criar um relatório offline, a geração do relatório falha com um erro interno. Isto acontecia devido a uma versão incorreta da biblioteca de geração de gráficos.
Problema 69273 resolvido: Num VMware SD-WAN Orchestrator a utilizar a versão 4.3.0, quando um cliente implementou um Serviço de Segurança na Cloud (CSS) e consulta a página Monitorizar > Serviços de rede (Monitor > Network Services), o utilizador observa que o IP público do CSS é truncado e não mostra o IP completo ao pairar o cursor sobre o balão de estado.
A largura do IP público não é suficiente para mostrar o endereço IP completo, por exemplo: 255.255.255.255. O parâmetro da IU do Orchestrator apresenta um erro não definido ao mostrar o estado geral.
Problema 69196 resolvido: Quando um cliente tem um site com uma ligação WAN configurada como backup e também utiliza um Serviço de Segurança na Cloud (CSS), é possível que um utilizador observe eventos de túnel CSS para a ligação de backup.
Se o utilizador tiver ligações WAN de backup onde estão configurados túneis CSS, verá eventos relacionados com essas ligações, juntamente com ligações ativas e de reserva dinâmica. Uma vez que a ligação de backup é, por definição, inativa, estes eventos são falsos e desagradáveis para o cliente.
Problema 69181 resolvido: Se um utilizador configurar um Gateway secundário protegido por IPsec na secção Definições do dispositivo > Handoff de Gateway (Device Settings > Gateway Handoff) do VMware SD-WAN Orchestrator, o túnel IPsec não será estabelecido com o Gateway secundário protegido por IPsec.
O utilizador não observaria a configuração IPsec aplicada e presente ao consultar debug.py --gateways.
Problema 69162 resolvido: A carga útil do teste de amostra para um alerta Webhook não tem o nome do cliente quando o teste é iniciado por um administrador de parceiro.
Quando um utilizador com a função Administrador de parceiro inicia um teste de alerta Webhook em nome de um cliente utilizando um modelo de carga útil que inclui a palavra-chave especial “cliente” (customer), o VMware SD-WAN Orchestrator substitui incorretamente o nome do cliente por uma cadeia vazia.
Problema 69046 resolvido: Num VMware SD-WAN Orchestrator, os VMware SD-WAN Edges ligados podem não receber as respetivas atualizações de routing e, como resultado, continuar a tentar utilizar rotas antigas.
Quando os Edges colocam na fila de entrega mais de 250 ficheiros num espaço de 15 segundos e todos estes ficheiros são pequenos, contendo apenas um ou dois eventos de rota, a tarefa de colocação na fila de entrega de eventos de routing não está a criar tarefas para os consumidores consumirem. Como resultado, a contagem de ficheiros continua a aumentar na fila de entrega de processamento de ficheiros e a tarefa de colocação na fila de entrega torna-se demorada à medida que a contagem de ficheiros aumenta para um grande número. Ao deparar-se com este problema, existem muitos ficheiros de eventos de routing pendentes com a contagem a aumentar constantemente. Apesar de o processo de carregamento do Orchestrator que trata dos pedidos de routing estar a responder com ACKs para todos os eventos de routing de imediato, os Edges não estão a receber os ACKs. Em vez disso, são apresentadas as mensagens “A ligação excedeu o limite de tempo” (Connection timed out) nos registos do Edge. Isto afeta não só os Edges, que não obtêm os eventos de routing, mas também coloca pressão no processamento do Orchestrator.
Problema 68702 resolvido: Num VMware SD-WAN Orchestrator a executar a versão 4.3.0, a configuração de uma função de utilizador para negar a permissão para o privilégio “Atualizar definições multicast do dispositivo de perfil” (Update Profile Device Multicast Settings) ou “Atualizar definições do Edge do cliente” (Update Customer Edge Settings) não é aplicada pelo Orchestrator.
O Orchestrator 4.3.0 não inclui os privilégios para “Atualizar definições multicast do dispositivo de perfil” (Update Profile Device Multicast Settings) ou “Atualizar definições do Edge do cliente” (Update Customer Edge Settings).
Problema 68531 resolvido: Os administradores de cliente com funções de Superutilizador, Padrão e Rede empresarial não conseguem ver “Estado de Vizinho Gateway BGP (para BGP em IPsec via Gateway)” (BGP Gateway Neighbor State [for BGP on IPsec via Gateway]) na página Monitorização (Monitoring) do Edge de um VMware SD-WAN Orchestrator a utilizar a versão 4.3.0.
A versão 4.5.0 adicionou um privilégio para os Administradores de cliente com funções de Superutilizador, Padrão e Rede empresarial poderem ver “Estado de Vizinho Gateway BGP (para BGP em IPsec via Gateway)” (BGP Gateway Neighbor State [for BGP on IPsec via Gateway]) na página Monitorização (Monitoring) do Edge, mas este não foi incluído para os Orchestrators da versão 4.3.0.
Problema 68387 resolvido: Quando um utilizador tenta criar um novo utilizador operador ou administrador de cliente com um tipo não nativo (por outras palavras, um utilizador que não utilize um nome de utilizador/palavra-passe, mas sim a autenticação SSO ou RADIUS), o VMware SD-WAN Orchestrator continua a exigir a introdução de uma palavra-passe para o novo utilizador.
Quando um utilizador tenta criar um novo utilizador operador ou cliente, a IU do Orchestrator não limpa o campo de palavra-passe. Por seu lado, em vez de verificar primeiro se o tipo de utilizador é não nativo, o back-end executará uma verificação de força da palavra-passe e gerará um erro.
Problema 68321 resolvido: Um cliente cuja empresa utiliza uma topologia de Hub e Spoke observaria uma grande quantidade de eventos “Sessão BGP estabelecida para vizinho edge” (BGP session established to edge neighbor) entregue a cada minuto aquando da atualização do VMware SD-WAN Orchestrator utilizado por essa empresa para a versão 4.3.0.
Os Edges Hub enviam estes eventos de alteração de estado BGP várias vezes por minuto e a página Eventos (Events) do cliente seria inundada com os mesmos, o que tornaria muito mais difícil identificar eventos significativos para esse cliente.
Problema 67701 resolvido: Ao configurar uma regra de política empresarial, a lista pendente Grupos de objetos (Object Groups) não é visível na IU do VMware SD-WAN Orchestrator quando são configurados mais de 20 grupos.
Mesmo com mais de 5 grupos de objetos (Grupo de endereços, Grupo de portas) configurados, a lista pendente Grupo de objetos (Object Group) é apresentada perto da parte inferior do ecrã do browser. Com mais de 20 regras, a lista Grupos de objetos (Object Groups) fica completamente fora do ecrã e é impossível vê-la a menos que o utilizador faça bastante zoom no browser, mas, aí, o texto é tão pequeno que também é inutilizável.
Problema 67496 resolvido: Um VMware SD-WAN Orchestrator atualizado para a versão 4.3.0 tem uma pequena regressão de desempenho no que diz respeito à utilização de recursos.
O problema não será notado pelos clientes ao nível da empresa: No entanto, o administrador do Orchestrator notará um aumento de ~10% na utilização dos recursos após a atualização para a versão 4.3.0. Os problemas de desempenho do Orchestrator foram provocados por várias consultas da base de dados. Estas consultas tiveram uma ineficiência muito pequena que poderia afetar o desempenho do Orchestrator em implementação de grande escala (mais de 6000 Edges). A correção aborda esses problemas e restaura o desempenho do Orchestrator para o esperado ou para melhor em comparação com a versão anterior.
Problema 67336 resolvido: Quando um utilizador consulta a página Monitorização (Monitoring) do Orchestrator para um VMware SD-WAN Edge, as estatísticas de transporte mostram valores muito mais baixos quando comparados com as estatísticas de aplicação para esse Edge.
O problema impede que um utilizador consiga obter uma imagem precisa do débito de um determinado Edge, uma vez que não sabe qual é o conjunto de dados correto. O problema é o resultado de as estatísticas de transporte não incluírem as estatísticas de contabilização de underlay, ao contrário das estatísticas de aplicação, que o fazem.
Problema 67153 resolvido: Os e-mails de alerta estão a ser enviados mesmo quando o VMware SD-WAN Edge reagiu dentro do intervalo de atraso configurado.
O VMware SD-WAN Orchestrator envia notificações de Edge inativo/ativo, mesmo que os eventos tenham ocorrido dentro do intervalo de atraso configurado.
Problema 66679 resolvido: Um utilizador pode encontrar um portal do VMware SD-WAN Orchestrator sem resposta depois de ser atualizado para a versão 4.3.0.
Após a atualização do Orchestrator para a versão 4.3.0, o processo de back-end não arranca conforme esperado devido a um efeito secundário da funcionalidade Orchestrator Bastião onde o Redis está a ser utilizado como intermediário para garantir que as definições do bastião foram configuradas. Isto faz com que o back-end do Orchestrator fique num ciclo infinito, uma vez que está a receber mensagens Pub/Sub nas subscrições de canal “Edge”.
Problema 66678 resolvido: Quando um VMware SD-WAN Orchestrator é atualizado para a versão 4.3.0, os túneis do Destino Não-SD-WAN via Gateway poderão ser desmontados e não ser reconstruídos.
Este problema é provocado por um defeito de validação introduzido numa funcionalidade adicionada para a versão 4.3.0. Este defeito provoca a falha do heartbeat do VMware SD-WAN Gateway, o que faz com que o Orchestrator não envie as configurações de Gateway aos respetivos Gateways. Uma vez que as configurações não são enviadas, os túneis NSD, que fazem parte da configuração de Gateway, não são propagados para os Gateways e os túneis ficam, eventualmente, inativos e não recuperam. Este problema afeta os Orchestrators que estavam a ser utilizados há muito tempo e onde alguns dos pares NSD nestes Orchestrators não estavam associados a nenhum segmento. Uma vez que a falha do heartbeat está associada a Gateways, vários clientes podem deparar-se com um problema de túnel do NSD via Gateway inativo.
Problema 66639 resolvido: Num VMware SD-WAN Orchestrator a utilizar a versão 4.3.0, quando o site de um cliente que utiliza uma topologia de alta disponibilidade sofre uma recuperação automática HA, o Orchestrator pode processar os eventos HA fora de ordem, o que resulta em alertas inconsistentes e, possivelmente, na marcação do site como inativo.
O Orchestrator depende dos eventos para determinar o estado HA de um site e, quando existe uma recuperação automática, é enviado um “Estado HA” (HA state) nos parâmetros juntamente com um evento HA_GOING_ACTIVE ao mesmo tempo. Se o Orchestrator os processar fora de ordem, o utilizador poderá observar alertas incorretos e a marcação do par HA como inativo.
Problema 66631 resolvido: A Ferramenta de migração não funciona ao tentar migrar grandes clientes empresariais.
Um grande cliente empresarial é definido como um com 100 ou mais Edges. A ferramenta de migração irá falhar no passo onde é suposto encadear todo o blob de dados e escrever para um ficheiro. Ao realizar a exportação da configuração, a ferramenta de migração estava a utilizar JSON.stringify para encadear os dados de saída e escrevê-los para o ficheiro, o que irá falhar quando a configuração tem dimensões muito elevadas.
Problema 66597 resolvido: Num VMWare SD-WAN Orchestrator onde existe um cliente com um número muito elevado de Edges implementados, ao serem adicionados vários VMware SD-WAN Gateways a um conjunto de Gateways que o cliente está a utilizar, um grande número de Edges pode ser apresentado como inativo no Orchestrator.
Este problema foi observado no terreno com um cliente que tinha ~7000 Edges ligados ao Orchestrator. Quando existe uma alteração no conjunto de Gateways desse cliente, o Orchestrator tem de emitir as alterações de configuração para todos os Edges e os novos cálculos do plano de controlo para mais de 700 Edges numa janela de 30 segundos faz com que as emissões de heartbeats/estatísticas falhem com o erro “POOL_ENQUEUELIMIT”. Devido a falhas de heartbeat, os Edges são apresentados como inativos no Orchestrator.
Problema 66177 resolvido: Alguns utilizadores parceiros não conseguem ver as estatísticas de caminho no VMware SD-WAN Orchestrator.
Isto afeta os administradores de parceiros que têm atribuídos os IDs de função 5, 6 ou 8. Essas funções traduzem-se da seguinte forma: 5 = Especialista em TI; 6 = Superutilizador; 8 = Suporte ao cliente. O motivo deste problema é que a visualização das estatísticas do caminho é um privilégio delegado. A correção completa deste problema é disponibilizada nas versões 4.4.x e superiores.
Na versão 4.3.1, o problema foi corrigido para o ID 6 da função (Superutilizador), mas não para o ID 5 ou 8.
Problema 66011 resolvido: O método linkQualityEvent/getLinkQualityEvents da API do portal do VMware SD-WAN Orchestrator opera de forma não determinante no modo “verboso”.
O método linkQualityEvent/getLinkQualityEvents da API do Orchestrator suporta uma opção “individualScores” que permite aos clientes pedir opcionalmente informações mais detalhadas sobre a ligação QoE na resposta da API. Este método opcional produz informações detalhadas por amostra de série de tempo (que é lenta e tem um desempenho de produção intensivo) no resultado. O valor predefinido deste parâmetro é falso, para evitar que este desempenho seja impactado. No entanto, aqui o servidor reporta esta informação de forma não determinante, mesmo nos casos em que o cliente não a solicitou especificamente e resulta num impacto sobre o desempenho.
Problema 65967 resolvido: Num cliente a executar uma atualização de um VMware SD-WAN Orchestrator no local para a versão 4.3.0, os serviços do Orchestrator podem não ser apresentados depois de a atualização ter sido concluída e o Orchestrator parecerá estar inativo.
Este problema é o resultado de um script de atualização que não consegue processar os dados inválidos enviados por determinadas versões de VMware SD-WAN Edges. Alguns dos serviços internos do Orchestrator não conseguem iniciar adequadamente e reiniciar o portal e os serviços de carregamento não resolve o problema. A correção para este problema inclui um patch que é redefinido para ignorar configurações inválidas e registar um Evento do Operador com todos os IDs, para que o Operador possa corrigi-los mais tarde.
Problema 65760 resolvido: Quando um utilizador operador observa a página Diagnóstico de Orchestrator (Orchestrator Diagnostics) na IU do VMware SD-WAN Orchestrator, o utilizador nota que a secção Informação de armazenamento da base de dados (Database Storage Info) tem vários grupos de dados em falta.
Faltam as seguintes secções em Armazenamento de base de dados (Database Storage): Lista de processos de base de dados (Database Process List); Variável de estado da base de dados (Database Status Variable); Variável do sistema da base de dados (Database System Variable); Estado do motor da base de dados (Database Engine Status).
Problema 65558 resolvido: Um cliente implementado num VMware SD-WAN Orchestrator com a versão 4.3.0 não consegue configurar o Syslog quando a interface de origem é uma VLAN.
Ao configurar o Syslog com uma interface de origem VLAN, a tentativa de guardar resultará no erro “A interface de origem do Syslog VLAN-xxx não existe no segmento <nome do segmento>” (Syslog source interface VLAN-xxx does not exist on Segment <segment name>) na IU do Orchestrator.
Problema 65253 resolvido: Ao configurar uma regra de firewall, a lista pendente Grupos de objetos (Object Groups) fica inutilizável na IU do VMware SD-WAN Orchestrator quando são configurados mais de 20 grupos.
Mesmo com mais de 5 grupos de objetos (Grupo de endereços, Grupo de portas) configurados, a lista pendente Grupo de objetos (Object Group) é apresentada perto da parte inferior do ecrã do browser. Com mais de 20 regras, a lista Grupos de objetos (Object Groups) fica completamente fora do ecrã e é impossível vê-la a menos que o utilizador faça bastante zoom no browser, mas, aí, o texto é tão pequeno que também é inutilizável.
Problema 64716 resolvido: O utilizador não consegue gerar relatórios no VMware SD-WAN Orchestrator.
Quando o utilizador tenta gerar um relatório, este falha e é apresentado “Erro” (Error) na coluna Estado (Status) da página Relatórios (Reports). O problema foi introduzido quando um dos pacotes dependentes foi atualizado e o pacote atualizado introduziu um defeito que fez com que todos os relatórios gerados falhassem.
Problema 64039 resolvido: Em alguns casos, um cliente pode observar o seu servidor DHCP como inativo.
O problema pode ser observado no seguinte cenário: após fornecer valores ao tipo de endereçamento, ative o servidor DHCP, atribua valores e clique no botão Atualizar (Update). Se o utilizador abrir o pop-up de subinterface, verá que o servidor DHCP aparece como inativo com todos os campos sob o servidor DHCP ocultos.
Problema 63694 resolvido: Na empresa de um cliente com uma topologia de Hub e Spoke em que o VMware SD-WAN Edge está a executar a versão 4.2.x ou anterior e está ligado a um VMware SD-WAN Gateway a executar a versão 4.3.0 ou posterior, os Edges não instalam a ordem de caminhos adequada, o que resulta em interrupções de tráfego.
O VMware SD-WAN Orchestrator não está a processar corretamente os caminhos de transmissão a partir de um Edge anterior à versão 4.2.x num lado e de um Edge posterior à versão 4.2.x no outro. De acordo com as respetivas versões, os Edges comportam-se de modo diferente na forma como enviam o flag de transmissão para o Orchestrator e isso faz com que este envie a ordem de caminhos errada para um Edge com a versão 4.2.x ou anterior.
Problema 63622 resolvido: A IU do VMware SD-WAN Orchestrator não regista nenhum evento de Gateway eliminado quando um utilizador elimina um VMware SD-WAN Gateway.
O Orchestrator deve registar um evento ao nível do operador e do Parceiro (para Gateways de parceiro assim eliminados), mas não o faz.
Problema 63556 resolvido: O utilizador tem a opção de adicionar mais de um servidor TACAC na IU do VMware SD-WAN Orchestrator.
Embora o utilizador possa adicionar mais de um servidor TACAC, esta não é uma configuração válida. O motivo para tal é que, se o primeiro servidor TACAC falhar, o segundo servidor TACAC não assumirá o controlo em situação alguma. A correção remove a opção para adicionar mais de um servidor TACAC.
Problema 63518 resolvido: Na empresa de um cliente que utilize a versão 3.3.x e atualiza para a versão 4.3.0, um VMware SD-WAN Gateway ligado a um Edge neste cliente poderá não anunciar os caminhos BGP aprendidos.
Este problema deve-se ao facto de o VMware SD-WAN Orchestrator não enviar confirmações aos caminhos aprendidos. Desta forma, em vez de responder com advertise – true e o custo correspondente, o Orchestrator enviará advertise – false ao Gateway e este não anunciará o caminho.
Problema 62958 resolvido: Num VMware SD-WAN Edge em que a automatização IPsec do Serviço de Segurança na Cloud Zscaler está ativada, quando o endereço IP da respetiva ligação WAN pública muda, o Edge pode enviar um valor inválido para o IP público como um estado transitório.
A validação para um IP público não funciona como esperado e pode causar um erro da API Zscaler devido a parâmetros inválidos. Este problema ocorre quando a ligação WAN pública do Edge entra em algum estado transitório breve. Normalmente, este problema não deverá ter qualquer impacto nos túneis CSS existentes da ligação WAN pública.
Problema 62624 resolvido: Quando um utilizador tenta desmarcar a caixa Gateway de parceiro (Partner Gateway) na página Gateways > Visão geral (Gateways > Overview) da IU do VMware SD-WAN Orchestrator, é apresentado um erro que mostra apenas um nome de perfil, sem indicação do cliente ao qual pertence o perfil.
Este é um problema significativo se for necessário alterar o estado de um VMware SD-WAN Gateway, uma vez que o utilizador não conseguirá saber que cliente ou clientes estão a utilizar esse Gateway. Tudo o que o utilizador consegue ver é o perfil, o que não significa nada sem o cliente associado ao mesmo.
Problema 62575 resolvido: O VMware SD-WAN Edge não cumpre a configuração do site de Destino Não-SD-WAN ou de Serviço de Segurança na Cloud (CSS) para segmentos não globais quando essas capacidades estão ativadas através de uma anulação específica ao Edge.
Em alguns cenários de configuração incomuns (por exemplo, um caso em que o Serviço de Segurança na Cloud foi ativado exclusivamente num segmento não global através de uma anulação específica ao Edge), o Orchestrator calculou incorretamente a configuração do plano de controlo do Edge para segmentos não globais.
Problema 62355 resolvido: O utilizador não consegue configurar as opções de BGP para um Destino Não SD-WAN com um tipo Palo Alto Networks.
Um pedido anterior removeu a capacidade de configurar o BGP dos Destinos Não-SD-WAN (NSD) que não suportavam BGP. No entanto, um NSD com um tipo Palo Alto Networks suporta BGP e a capacidade de configurar o BGP foi inadvertidamente removida deste tipo também. Esta correção restaura esses campos de configuração de BGP para o tipo Palo Alto Networks.
Problema 62058 resolvido: O VMware SD-WAN Orchestrator apresenta interfaces WLAN para modelos VMware SD-WAN Edge 510-N e 6x0-N, apesar de estes modelos não estarem equipados com Wi-Fi.
A IU do Orchestrator deveria ocultar as interfaces WLAN para os modelos Edge 510-N e 6X0-N. Um modelo Edge com um designador “-N” indica que foi criado sem um chip de Wi-Fi na placa. Quando estes modelos Edge são ativados, o número do modelo deveria ser utilizado pelo Orchestrator para ocultar as interfaces WLAN. O impacto para um cliente é mínimo, uma vez que, apesar de as interfaces WLAN serem apresentadas, o Orchestrator ignorará qualquer tentativa de as configurar.
Problema 59434 resolvido: Quando um utilizador sai da página Configurar > Edge > Dispositivo (Configure > Edge > Device) na IU do VMware SD-WAN Orchestrator, a página Web mostra um pop-up de navegação que indica “As alterações que efetuou serão perdidas se sair desta página” (The changes you made will be lost if you navigate away from this page) mesmo que o utilizador não tenha efetuado quaisquer alterações na página Definições do dispositivo (Device Settings).
O Orchestrator tem dados que mostram que foi efetuada uma alteração mesmo que não tenham sido efetuadas quaisquer alterações, pelo que é apresentado o pop-up a pedir aos clientes para guardar. Isto é o resultado de o objeto incorreto estar a ser comparado com o objeto existente para verificar as alterações. Devido a uma comparação incorreta, os dados foram considerados como modificados. A correção substitui o objeto incorreto pelo objeto correto para comparação, o que garante que não são apresentados pedidos falsos para guardar.
Problema 58070 resolvido: O utilizador não pode filtrar uma sub-rede OFC com base em segmentos ao utilizar a página OFC na IU do VMware SD-WAN Orchestrator.
O filtro de pesquisa de sub-rede OFC não funciona com um segmento, por isso, se um utilizador vir e aprender um prefixo na página OFC e, em seguida, tentar pesquisar o prefixo aprendido através de uma opção de pesquisa com um segmento, a pesquisa não devolverá resultados.
Problema 53751 resolvido: A validação do caminho ligado nas definições de caminho estático falha numa VLAN sem cidrIp e cidrPrefix.
O problema ocorre quando o utilizador cria uma VLAN sem um cidrIp e cidrPrefix.
Problema 48791 resolvido: O utilizador não consegue comutar um VMware SD-WAN Edge entre perfis quando o Edge tem uma interface configurada com a anulação do Edge.
Por exemplo, se um cliente tiver dois perfis de configuração: o Perfil 1 e o Perfil 2 e associa um Edge ao Perfil 1. Se o utilizador utilizar, em seguida, a anulação do Edge para configurar o GE2 como encaminhado e adicionar um caminho estático para o GE2, quando o utilizador tentar, posteriormente, atribuir este mesmo Edge ao Perfil 2, observará um erro onde o GE2 não existe no Perfil 2 como encaminhado. Este problema ocorre porque, quando um utilizador configura uma interface do Edge com a anulação do Edge que pertence a um perfil, o VMware SD-WAN Orchestrator não consegue mudar, dado que o Orchestrator não valida a presença da anulação do Edge.
Problema 48706 resolvido: Os utilizadores podem não conseguir guardar as alterações no separador Configurar > Edge > Dispositivo (Configure > Edge > Device) com a interface de origem selecionada sob a configuração Syslog.
O erro que o utilizador veria no VMware SD-WAN Orchestrator é “A interface de origem fornecida não está presente no segmento: <Nome do segmento>” (Provided source interface is not present in the segment on segment: <Segment Name>). Isto é provocado pelo utilizador ao criar e eliminar um determinado número de segmentos de forma que a sequência de segmentos já não seja sequencial.
Problema 45078 resolvido: Ao configurar um VNF para um cliente no VMware SD-WAN Orchestrator, se um estado VNF for configurado ao nível do perfil de uma forma e, em seguida, configurado de uma forma diferente ao nível do site através da Anulação de Edge, quando a Anulação de Edge for desativada posteriormente, o site continuará a utilizar as definições de Anulação de Edge e não voltará às definições de perfil como esperado.
Este problema ocorre ao configurar um parâmetro de inserção VNF num Perfil de configuração em que a definição oposta está configurada para um site que utiliza a Anulação de Edge e, posteriormente, a Anulação de Edge é desativada, mas a definição persiste.
Problemas em aberto na versão 4.3.1
Os problemas conhecidos são agrupados da seguinte forma:
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 25742:
O tráfego contabilizado de underlay está limitado à capacidade máxima do VMware SD-WAN Gateway, mesmo que seja inferior à capacidade da ligação WAN privada que não está ligada ao Gateway.
Problema 25758:
As ligações WAN USB podem não ser corretamente atualizadas quando são trocadas de uma porta USB para outra, até que o VMware SD-WAN Edge seja reiniciado.
Solução alternativa: reinicie o Edge após mover as ligações WAN USB de uma porta para outra.
Problema 25855:
Uma grande atualização de configuração no Gateway de parceiro (por exemplo, 200 VRFs ativados por BGP) pode provocar um aumento da latência durante cerca de 2 a 3 segundos para algum tráfego através do VMware SD-WAN Gateway.
Solução alternativa: nenhuma solução alternativa disponível.
Problema 25921:
A recuperação automática do VMware SD-WAN Hub de alta disponibilidade demora mais do que o esperado (até 15 segundos) quando existem três mil Edges de ramo ligados ao Hub.
Problema 25997:
O VMware SD-WAN Edge pode precisar de um reinício para passar corretamente tráfego numa interface encaminhada que foi convertida para uma porta comutada.
Solução alternativa: reinicie o Edge após fazer a alteração de configuração.
Problema 26421:
O Gateway de parceiro primário para qualquer 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.
Problema 28175:
O NAT de Política Empresarial falha quando o IP do NAT se sobrepõe ao IP de interface do VMware SD-WAN Gateway.
Problema 31210:
VRRP: o ARP não é resolvido no cliente LAN para o endereço IP virtual VRRP quando o VMware SD-WAN Edge é primário com um segmento CDE não global em execução na interface LAN.
Problema 32731:
Os caminhos predefinidos condicionais anunciados através de OSPF não podem ser retirados corretamente quando o caminho está desligado. Ativar e desativar novamente o caminho vai retraí-lo com sucesso.
Problema 32960:
O estado da interface de “Negociação automática” (Autonegotiation) e “Velocidade” (Speed) pode ser apresentado incorretamente na IU de Web Local para os VMware SD-WAN Edges ativados.
Problema 32981:
A velocidade de pré-programação e o duplex numa porta ativada por DPDK podem precisar de um reinício do VMware SD-WAN Edge para que as configurações entrem em vigor, uma vez que exigem a desativação do DPDK.
Problema 35778:
Quando existem múltiplas ligações WAN definidas pelo utilizador numa única interface, apenas uma dessas ligações WAN pode ter um túnel GRE para o Zscaler.
Solução alternativa: utilize uma interface diferente para cada ligação WAN que precisa de criar túneis GRE para o Zscaler.
Problema 35807:
Uma interface encaminhada por DPDK será completamente desativada se a interface for desativada e novamente ativada no VMware SD-WAN Orchestrator.
Problema 36923:
O nome do cluster não pode ser atualizado corretamente na descrição da interface de NetFlow para um VMware SD-WAN Edge que está ligado a esse Cluster como o seu Hub.
Problema 38682:
Um VMware SD-WAN Edge que atua como um servidor DHCP numa interface ativada por DPDK pode não gerar corretamente eventos de “Novo dispositivo de cliente” para todos os clientes ligados.
Problema 38767:
Quando um overlay WAN que tenha túneis GRE configurados para o Zscaler é alterado da deteção automática para definido pelo utilizador, os túneis obsoletos podem permanecer até ao próximo reinício.
Solução alternativa: reinicie o Edge para limpar o túnel obsoleto.
Problema 39134:
A estatística de estado de funcionamento do Sistema “Percentagem de CPU” (CPU Percentage) pode não ser comunicada corretamente em Monitorizar > Edge > Sistema (Monitor > Edge > System) para o VMware SD-WAN Edge e em Monitorizar > Gateways (Monitor > Gateways) para o VMware SD-WAN Gateway.
Solução alternativa: os utilizadores devem utilizar as Handoff Queue Drops para monitorizar a capacidade do Edge e não a percentagem de CPU.
Problema 39608:
A saída do “Teste de Ping” (Ping Test) de Diagnóstico Remoto pode apresentar brevemente conteúdos inválidos, antes de apresentar os resultados corretos.
Problema 39624:
O ping através de uma subinterface pode falhar quando a interface principal estiver configurada com PPPoE.
Problema 39753:
A desativação da VPN Ramo-a-Ramo Dinâmica pode fazer com que os fluxos existentes que estão atualmente a ser enviados utilizando Ramo-a-Ramo Dinâmica sejam atrasados.
Problema 40096:
Se um VMware SD-WAN Edge 840 ativado for reiniciado, existirá possibilidade de um módulo SFP ligado ao Edge parar de passar o tráfego, mesmo que as luzes de ligação e o VMware SD-WAN Orchestrator indiquem a porta como “ATIVA” (UP).
Solução alternativa: desligue o módulo SFP e, em seguida, volte a ligá-lo na porta.
Problema 40421:
O Traceroute não está a apresentar o caminho quando passa através de um VMware SD-WAN Edge com uma interface configurada como uma porta comutada.
Problema 42872:
Ativar o Isolamento de Perfil num perfil de Hub onde um cluster de Hub está associado não revoga os caminhos do Hub na base de informações de routing (RIB).
Problema 43373:
Quando o mesmo caminho BGP é aprendido a partir de vários VMware SD-WAN Edges, se este caminho for movido da saída preferencial para a saída elegível no Controlo de fluxo de overlay, o Edge não será removido da lista de anúncios e continuará a ser anunciado.
Solução alternativa: Ative o cálculo de custos distribuídos no VMware SD-WAN Orchestrator.
Problema 44526: Numa empresa onde dois sites diferentes implementam os seus VMware SD-WAN Edges como Hubs, ao mesmo tempo que utilizam uma topologia de alta disponibilidade, e cada site utiliza o outro site do Hub como um Hub no seu perfil, se um dos sites do Hub desencadear uma recuperação automática HA, pode demorar até 30 minutos para ambos os Hub Edges restabelecerem os túneis entre si.
Numa recuperação automática HA, ambos os Hub Edges tentam iniciar um túnel entre si ao mesmo tempo e nenhum responde ao par, a troca de pacotes entre ambos os Hubs ocorre, mas o IKE nunca se sucede. Isto leva a um impasse que se verificou demorar até 30 minutos para se resolver por si só. O problema é intermitente e não ocorre após cada recuperação automática HA.
Solução alternativa: para evitar que este problema ocorra, o cliente deve configurar apenas um dos dois sites do Hub de HA para utilizar o outro site do Hub como um Hub para si mesmo. Por exemplo, se existirem dois sites do Hub de HA, o Hub1 e o Hub2, o Hub1 pode ter o Hub2 como Hub para si no seu perfil, mas o Hub2 não deve utilizar o Hub1 como Hub no seu perfil.
Problema 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 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 ativar novamente a interface no VMware SD-WAN Orchestrator.
Problema 42488:
o tráfego pode ser colocado numa condição de buraco negro para o caminho ligado para interfaces do VMware SD-WAN Edge que não têm uma ligação. Se a ligação numa porta do Edge for removida e a interface não for desativada, o Edge não revogará o caminho do Gateway, fazendo com que outros Edges encaminhem o tráfego para o Edge sem ligação.
Solução alternativa: desative a interface se não existir nenhuma ligação.
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 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.
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 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 47355:
Quando o mesmo caminho é aprendido através do BGP de underlay local, do Hub BGP e/ou estaticamente configurado no Gateway de parceiro, a sequência de ordenação dos caminhos é a incorreta, com o Hub BGP a ter preferência sobre o BGP de underlay.
Problema 48166:
Um Edge Virtual do VMware SD-WAN em KVM não é suportado ao utilizar um SO de virtualização da Ciena e o Edge sofrerá falhas recorrentes do Serviço dataplane.
Problema 48175:
Um VMware SD-WAN Edge a executar a versão 3.4.2 formará uma contiguidade OSPF num segmento não global, caso o segmento não global tenha uma interface configurada no mesmo intervalo de IP que a interface configurada no segmento global.
Problema 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 permanece 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á ativado, se mais de 6000 túneis PKI tentarem ligar-se ao Gateway, os túneis poderão não surgir todos devido aos SAs de entrada não serem eliminados.
Nota: os túneis que utilizam a autenticação de chave pré-partilhada (PSK) não têm este problema.
Problema 51036:
Se a velocidade comunicar um valor de 0 para as interfaces operacionais do VMware SD-WAN Edge ao consultar o Edge através do SNMP. Este é um comportamento esperado para as portas ativadas por DPDK. Atualmente, a única forma de obter os valores de velocidade para as portas ativadas por DPDK é utilizar o comando “debug.py --dpdk_ports”. Mas o módulo SNMP em execução num Edge não depende deste comando para extrair valores de velocidade para portas ativadas por DPDK. O SNMP apenas consulta através da interface de kernel, que infelizmente não preenche os valores de velocidade para dpdk_ports.
Problema 51428:
Podem ser observadas perdas de tráfego multicast num site onde o VMware SD-WAN Edge tem uma subinterface configurada com PIM. Quando uma subinterface configurada com PIM é rapidamente movida de um segmento para outro, o pimd (o processo que gere o PIM) pode reiniciar e o site pode sofrer uma perda de tráfego multicast intermitente.
Solução alternativa: desative primeiro a subinterface e, em seguida, mova a subinterface para outro segmento. Uma vez movida, reative-a.
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 53147:
os valores limite de hop não predefinidos anunciados nos anúncios do router não são cumpridos pelo VMware SD-WAN Edge. O valor limite de hop do túnel está sempre definido como 64. O valor predefinido do limite de hop é 64. Se desejar ter um valor de limite de hop não predefinido anunciado através de anúncios do router, o Edge não processará os campos de limite de hop no pacote e os valores permanecem em 64.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 53219:
Por predefinição, o limite de hop no Edge é de 64.
Quando o limite de hop do servidor RA é definido para valores não predefinidos, este não é atualizado para o túnel.
Arquive este pedido para conrolar a limitação
edge:b2-edge1:~# edged -v VCE Informações ======== de versão: Rev. da compilação 4.2.0: Data da compilação R420-20201119-DEV-69492a5ca4: Compilação do Hash 2020-11-19_10-57-33: 69492a5ca4934d41a7ff9822f763312d014f1836
N/D
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 53687:
Quando um Edge Spoke do VMware SD-WAN tem uma preferência por um túnel IPv6/v4, a MTU dos túneis v4/v6 não preferenciais também influenciará a MTU que é vista nos túneis preferenciais. Um Edge (Spoke ou Hub) mantém uma MTU de nível de sistema, que é o mínimo de todas as MTU de ligação e esta MTU é trocada como a MTU anunciada. Dado que uma MTU de ligação não preferencial ainda pode ser considerada para determinação da MTU de nível do sistema, pode ser anunciada uma MTU inferior e, em seguida, a MTU de caminho real.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 53830: Num VMware SD-WAN Edge, alguns dos caminhos na vista BGP podem não ter a preferência correta e anunciar valores quando o sinalizador DCC está ativado provocando uma sequência de ordenação incorreta no FIB do Edge.
Quando o Cálculo de custos distribuídos (DCC) é ativado num cenário à escala com um grande número de caminhos num Edge, ao analisar o pacote de diagnóstico do Edge para o registo bgp_view alguns dos caminhos podem não ser corretamente atualizados com os valores de preferência e anúncio. Este problema, caso seja encontrado, pode potencialmente ser encontrado em alguns Edges que fazem parte de uma grande empresa (mais de 100 Spoke Edges ligados a Edges Hub ou Clusters de Hub).
Solução alternativa: Este problema pode ser corrigido reaprendendo os caminhos BGP de underlay ou executando a opção “Atualizar” (Refresh) na página OFC do VMware SD-WAN Orchestrator para os caminhos afetados. Tenha em atenção que ao realizar a “Atualização” (Refresh) de um caminho vai reaprender os caminhos de todos os Edges na empresa.
Problema 53934: Numa empresa onde está configurado um cluster do VMware SD-WAN Hub, se o Hub principal tiver uma vizinhança BGP multihop no lado LAN, o cliente poderá sofrer situações de tráfego ignorado num Spoke Edge quando existe uma falha do lado LAN ou quando o BGP está desativado em todos os segmentos.
Num cluster de Hub, o Hub principal tem a vizinhança BGP multihop com um dispositivo de par para aprender caminhos. Se a interface física no Hub, através da qual a vizinhança do BGP é estabelecida, ficar inativa, os caminhos da BGP LAN não poderão ser zero, apesar da vista BGP estar vazia. Isto pode fazer com que o reequilíbrio do Cluster de Hub não ocorra. O problema também pode ser observado quando o BGP é desativado para todos os segmentos e quando existe uma ou mais vizinhanças BGP multihop.
Solução alternativa: reinicie o Hub que teve a falha do lado da LAN (ou BGP desativado).
Problema 54099: Os pacotes IPv6 fragmentados serão ignorados pelo VMware SD-WAN Edge.
Os pacotes IPv6 fragmentados ser ignorados pelo Edge.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 54378: A verificação de deteção de endereço duplicado (DAD) da interface ativada de endereço estático IPv6 falha devido a um NA ignorado.
A verificação DAD de endereço estático não ocorrerá e, se existir um endereço duplicado na rede para os endereços estáticos configurados, este não será detetado.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 54536: A verificação da deteção de endereços duplicados (DAD) não é ativada após um reinício do VMware SD-WAN Edge.
Se existir um endereço duplicado na rede, não será detetado se esta verificação DAD não for realizada após o reinício.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 54687: a mensagem de solicitação DHCPv6 não é enviada por um VMware SD-WAN Edge após ser proporcionada ao servidor uma configuração de valores T1 superiores a T2.
Se um servidor DHCPv6 fornecer inicialmente um valor T1 superior ao valor de T2, o Edge não aceitará o prefixo fornecido, mas mesmo depois desta configuração ter sido corrigida no servidor, o Edge não enviará nenhuma mensagem de solicitação DHCPv6 após três tentativas. Neste ponto, só quando o Serviço dataplane Edge é reiniciado é que o problema será eliminado.
Solução alternativa: reinicie o serviço Edge.
Problema 54731: as mensagens de renovação são enviadas com uma elevada frequência até que seja atingido o tempo de reenlace (t2) quando um utilizador altera o valor do intervalo de endereços IPv6 no servidor.
Quando um endereço IP que foi atribuído a um VMware SD-WAN Edge é removido do intervalo válido de endereços fornecidos por um servidor, o cliente continua a enviar mensagens de renovação para o servidor até que o tempo T2 seja alcançado. Isto pode resultar num utilizador cliente observar uma grande quantidade de tráfego DHCPv6.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 56454: quando configura ligações IPv4 e IPv6 como ligações de deteção automática numa interface e, em seguida, tem túneis formados através da ligação não preferencial. As estatísticas de ligação não apresentam informações consolidadas de uma ligação IPv4 e IPv6.
Quando uma interface tem sobreposições IPv4 e IPv6 configuradas como túneis e sobreposições de deteção automática formadas através de ambas as ligações, as estatísticas das ligações refletem apenas o estado da ligação preferencial. As informações de tráfego ou o estado da ligação não preferencial não são corretamente refletidas. Como resultado, as estatísticas vistas para a ligação na página Edge > Monitorização (Edge > Monitoring) que incluem a largura de banda e o débito, devem ser utilizadas como uma diretriz para medir o desempenho dos túneis formados apenas através da família de endereços IP preferidos.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 57957: Se uma interface DPDK for alterada de Autonegociar=ligado (Autonegotiate=on) para Autonegociar=desligado (Autonegotiate=off), o Edge descarregará o controlador KNI e carregará o controlador Linux para essa interface durante a sequência de reinício do Serviço do Edge (a partir de vc_dpdk.py).
Após carregar a nova interface Linux e dar-lhe o nome, vc_dpdk.py, também será necessário invocar “set_interface_neg.py” para aplicar as definições de negociação automática. No entanto, devido às novas definições de negociação automática e ao controlador de Linux ser recarregado, a interface de base já não está sob o controlo do DPDK.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 59970: o cliente observará a queda de tráfego de um VMware SD-WAN Edge para o centro de dados através de um Zscaler IaaS ao mudar de um gateway primário para um secundário.
Quando o Gateway principal fica inativo e o Orchestrator muda para o Gateway secundário, o fluxo de tráfego atual inverte o caminho de um Nó de Imposição do Zscaler (ZEN) e não funciona.
Solução alternativa: a solução alternativa seria reiniciar todo o fluxo de tráfego. O Zscaler é notificado sobre este problema e é confirmado que o caminho do tráfego inverso não está a funcionar corretamente do seu lado.
Problema 61882: Quando for efetuada uma alteração à configuração do parâmetro de segurança (por exemplo, alteração do tempo de vida de SA) no VMware SD-WAN Orchestrator, o cliente poderá observar tráfego ignorado durante um certo período de tempo.
Isto foi visto numa implementação em larga escala com mais de 1000 Edges numa topologia Hub/Spoke. Se os parâmetros de segurança (tempo de vida, algoritmos de criptografia, modo de autenticação) forem alterados, os túneis atuais serão desatualizados e posteriormente recriados. Numa implementação em larga escala, pode levar a problemas com a estabilidade do tráfego. O lado do dispositivo de resposta (Edge Hub) pode não ser capaz de lidar com todos os túneis a tempo e isto pode levar a que o tráfego seja ignorado. Eventualmente, os túneis serão estabelecidos, mas pode demorar algum tempo com base no número de túneis existentes.
Solução alternativa: recomenda-se a realização de alterações à configuração numa janela de manutenção, dado que o tempo de recuperação é desconhecido com base no número de túneis existente.
Problema 62685: Se o NAT do lado LAN estiver configurado com o mesmo IP externo para diferentes sub-redes LAN com tipo NAT como origem, o tráfego destinado à Cloud não funcionará.
Para o IP externo utilizado nas regras NAT do lado LAN, configuramos um caminho estático e anunciamo-lo nos ramos remotos. Para que o tráfego de retorno seja encaminhado para a sub-rede LAN correta, a pesquisa de caminho deve ser realizada com base no IP Interno configurado na regra NAT do lado LAN em vez do próximo hop no caminho estático. Mas para o tráfego de retorno na cloud, a pesquisa de caminho é realizada com base no próximo hop no caminho estático e o tráfego pode ser encaminhado para a sub-rede LAN errada.
Solução alternativa: utilize um IP externo diferente para sub-redes LAN diferentes.
Problema 62701: Para um VMware SD-WAN Edge implementado como parte de um cluster de Edge Hub, se a VPN de cloud não estiver ativada no segmento global, mas estiver ativada num segmento não global, uma atualização do plano de controlo enviada pelo Orchestrator pode fazer com que todas as ligações WAN fiquem instáveis no Edge Hub.
As ligações WAN do Edge Hub que fiquem inativas e, em seguida, ativas numa sucessão rápida (instabilidade) afetam o tráfego em tempo real, como chamadas de voz. Este problema foi observado numa implementação de clientes em que a VPN de cloud não estava ativada no segmento global do Edge Hub, mas a configuração do cluster estava ativada, o que significa que este Edge Hub fazia parte de um cluster (e a configuração de um cluster é aplicável a todos os segmentos). Quando uma alteração da configuração é emitida para o Edge Hub, o dataplane do Edge Hub inicia a análise dos dados e começa com o segmento global, onde verá que a VPN de cloud não está ativada, e o Edge Hub assume erradamente que o clustering está desativado neste segmento global. Como resultado, o Edge Hub derruba todos os túneis das ligações WAN do Hub, o que provoca instabilidades de ligação em todas as ligações WAN desse Edge. Para qualquer incidente deste tipo, as ligações WAN só ficam inativas e recuperam uma vez por atualização do plano de controlo.
A causa principal deste problema continua sob investigação.
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 62725: Um VMware SD-WAN Edge numa rede que utilize o BGP pode sofrer uma utilização elevada de memória em determinadas condições raras.
Se um Edge aprender um caminho BGP com um endereço IP de próximo hop, que é diferente do endereço IP de par, o próximo hop será rastreado quanto a acessibilidade pelo módulo de Rastreamento de próximo hop (NHT) do Edge. em seguida, se o BGP for desativado quando o endereço IP rastreado estiver inacessível no Edge, o NHT rastreado não poderá ser eliminado. Nos casos raros em que existem muitas entradas NHT obsoletas, pode ser observada uma elevada utilização da memória do Edge.
Solução alternativa: reinicie o Edge para eliminar as entradas NHT com fugas de memória.
Problema 62897: O comando de depuração tcpdump não funciona corretamente num VMware SD-WAN Gateway.
Execute o comando tcpdump na interface eth0 ou eth1 do Gateway. A saída não está correta. tcpdump.sh e vctcdump também não estão a funcionar. Foi tentada uma correção, em que é adicionado um perfil de reclamação AppArmor para vctcpdump (com base no perfil tcpdump) que permite ao tcpdump herdar o confinamento de vctcpdump, mas o tcpdump ainda não está a funcionar. Essencialmente, o AppArmor faz com que o Stdout deixe de funcionar para tcpdump. Este é um problema conhecido com o AppArmor.
Solução alternativa: “pipe tcpdump output to cat., por exemplo, tcpdump -nnplei eth0 | cat”
Problema 63125: Quando a MTU é aumentada para qualquer interface/ligação num VMware SD-WAN Hub Edge, esta não será refletida na MTU de caminho no Spoke Edge (para caminhos com esse Edge Hub).
Se o utilizador aumentar a MTU de uma interface ou ligação num Hub, o caminho do Spoke Edge não captará a definição da MTU alterada.
Solução alternativa: reinicie o Edge Spoke, a MTU aumentada será refletida na MTU de caminho no Spoke.
Problema 65885: Para um cliente que tenha implementado um Destino Não-SD-WAN (NSD) via Gateway e que esteja a utilizar uma configuração de Gateway redundante, se o Gateway principal ficar inativo, ocorrerá uma condição race em que antes de o intercâmbio de PG-BGP no Gateway principal surgir, o NSD já anunciará as rotas antigas aprendidas através do Gateway redundante para o Gateway principal.
Uma vez que não são suportados multicaminhos do BGP, a rota que o Gateway principal deveria aprender através da interface de handoff parece ser aprendida como centro de dados do NSD. Apesar de estes caminhos serem válidos, isto não deveria acontecer, uma vez que o tráfego deve passar por NSD > Gateway principal > Interface de handoff (NSD > Primary Gateway > Handoff Interface) quando o Gateway principal está ativo. O impacto para o cliente não é em termos de desempenho, uma vez que o tráfego ainda chega ao destino, mas tem um impacto negativo na gestão de rede do cliente. O cliente espera que o tráfego chegue através de um caminho e instalará políticas de QoS para o gerir, mas o tráfego está a passar por outro caminho não esperado na política de QoS.
Solução alternativa: o cliente deve filtrar os caminhos de saída no Destino Não-SD-WAN via Gateway para que este não anuncie um caminho aprendido através de um Gateway redundante para um Gateway principal.
Problema 67458: Quando um VMware SD-WAN Hub Edge com um grande número de Edges Spoke é atualizado para a versão 4.2.1 ou posterior, alguns túneis para outros Edges Spoke não aparecerão para o Edge Hub.
Entende-se por um grande número de Edges Spoke ~1000 ou mais. Este problema não é consistente, mas, geralmente, ~1/3 dos túneis do Protocolo de gestão do VeloCloud (VCMP) não são estabelecidos entre o Edge Hub e os Edges Spoke ligados. Isto é causado pelo Hub Edge ignorar o MP_INITs dado que o número de TDs meio abertos excede o limite superior do Edge Hub.
Solução alternativa: o reinício do Serviço Edge restabelecerá a conetividade total do túnel.
Problema 72245: Se um VMware SD-WAN Hub Edge for utilizado como fuga da Internet de uma rede MPLS, os túneis de gestão (VCMP) da interface privada de um Edge Spoke ligado para quaisquer Gateways públicos podem ficar inativos ou não aparecer.
Os pacotes de gestão (VCMP) da interface privada de um Edge Spoke para o Gateway público são enviados através do Edge Hub. Neste cenário, o Hub considera este fluxo como um fluxo direto e emite estes pacotes para a Internet através de uma interface pública. No entanto, devido a problemas de routing, estes fluxos podem ser marcados como “Via Gateway”, o que provocaria o problema descrito acima.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 72925: para um cliente que utiliza consultas SNMP para monitorizar a sua empresa e implementa modelos inferiores de VMware SD-WAN Edges (por exemplo, os modelos Edge 510, 520 ou 610) que estão a executar uma versão de software 4.x, as consultas SNMP demoram bastante tempo a processar e podem, inclusivamente, exceder o limite de tempo.
Este problema reduz significativamente a eficácia das consultas SNMP para monitorização de redes ao utilizar Edges das séries 510, 5x0 e 6x0. Este problema é causado pelo SNMPagent da versão 4.x, que demora bastante tempo a percorrer a lista de comandos de depuração, o que não é efetivamente necessário para o processo SNMP.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 74149: Para um cliente que utilize um Serviço de Segurança na Cloud do tipo Zscaler, em que a verificação de estado de funcionamento de L7 está ativada, se um VMware SD-WAN Edge for reiniciado enquanto uma ligação WAN também estiver inativa, o processo de verificação de estado de funcionamento de L7 pode não enviar sondas para o serviço Zscaler mesmo depois de o Edge e as ligações WAN estarem totalmente restaurados.
Este problema não é consistente e raramente acontece, mesmo quando são cumpridas as condições indicadas. Quando o Edge está a ser reiniciado e a verificação de estado de funcionamento de L7 estiver ativada e se a interface WAN do Edge for submetida a uma transição de estado Ativa/Inativa, durante o tempo de reinicialização e inicialização, o Edge pode falhar no envio de sondas L7.
Solução alternativa: Sem a correção, a única forma de fazer com que o Edge retome o envio de sondas L7 é desativar/reativar (desativar, guardar as alterações e, depois, reativar e guardar as alterações) a verificação de estado de funcionamento de L7.
Problema 76292: Um VMware SD-WAN Edge configurado como um Spoke não prefere um caminho de transmissão com o melhor atributo BGP mesmo depois de formar um túnel dinâmico.
Um cliente poderá ser afetado por este comportamento se o caminho de transmissão através de um túnel dinâmico for utilizado para encaminhar o tráfego. Nesse caso, não funcionará e todo o tráfego deste caminho será encaminhado para o Hub.
A ideia subjacente aos caminhos de transmissão era criar um caminho especial para fugir do Edge Hub, e não ser utilizados em qualquer outro caso. Estes são os caminhos externos que o VMware SD-WAN não pretende anunciar como outros caminhos VCRP. Estes devem ser anunciados pelos Hubs aos respetivos Spokes, o que significa apenas através de túneis estáticos.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 79220: Num site implementado com uma topologia de alta disponibilidade, o cliente pode observar vários reinícios do VMware SD-WAN do Edge em standby com uma potencial disrupção do tráfego do cliente.
Uma enchente de eventos do Edge Ativo para o Edge em standby pode sobrecarregar alguns threads no Edge em standby, o que iria atrasar o processamento do heartbeat e leva a que o Edge em standby seja incorretamente promovido a Ativo. Num estado ativo-ativo, o tie-break vai para o Edge ativo e o Edge em standby é reiniciado para o despromover de volta ao seu estado rm standby adequado. Quando este problema é encontrado numa topologia HA convencional, o impacto no cliente deverá ser mínimo, dado que o Edge em standby não está a passar o tráfego do cliente. Numa implementação HA melhorada, onde o Edge em standby também está a passar tráfego, os reinícios perturbarão algum tráfego do cliente.
Neste pedido, foram realizadas algumas otimizações ao Edge para processar eventos de forma mais eficiente a partir dos Edges em standby e Edges ativos, para minimizar o número de eventos, ao impedir que alguns eventos inválidos sejam sincronizados de Ativo para Em standby.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 81224: Num site implementado com uma topologia de alta disponibilidade, quando ocorre no site uma recuperação automática de HA, as etiquetas de caminho OSPF podem não propagar a recuperação automática de HA posterior.
Numa recuperação automática de HA, os LSA externos de OSPF (anúncios de estado de ligação) não têm uma etiqueta de caminho, o que leva a um routing impróprio com um efeito adverso no tráfego do cliente.
Solução alternativa: o OSPF tem de ser reiniciado nos Edges que não recebem a etiqueta de caminho correta.
Problema 81859: Ao ativar um VMware SD-WAN Edge 610-LTE, a interface CELL pode não aparecer após o Edge concluir a sua ativação.
Este problema não é consistente, mas, quando ocorre, pode ter um grande impacto se a única ligação pública do Edge 610-LTE for a ligação CELL móvel, uma vez que o Edge estará efetivamente inativo e a intervenção para o mesmo terá de ser local, consistindo em desligar e ligar Edge para o recuperar.
Solução alternativa: se encontrar este problema e o 610-LTE tiver outras ligações WAN públicas com fios, o utilizador terá de reiniciar o serviço Edge através do Orchestrator com Ações remotas > Reinício do serviço (Remote Actions > Service Restart) numa janela de manutenção adequada ou reiniciar o modem do Edge para restaurar a interface CELL.
Se o 610-LTE utilizar apenas uma interface CELL para a Internet, alguém no local onde se encontra o Edge terá de desligar e ligar o Edge, dado que este estará inacessível através do Orchestrator.
Se o Edge 610-LTE que está a ser ativado utilizar apenas CELL para a Internet, o Edge deve ser ativado com alguém presente para, potencialmente, o desligar e ligar caso fique inativo após a conclusão da ativação.
Problema 82104: Em casos raros, os VMware SD-WAN Edges ativados numa topologia de alta disponibilidade podem não ser capazes de comunicar com um VMware SASE Orchestrator que marcará o site como inativo e impedirá qualquer intervenção através do Orchestrator para o site.
Este problema apenas ocorre quando uma configuração incomum e inválida é aplicada aos Edges HA. A configuração especifica que a porta HA está configurada como “ramal” (trunk) (o que não deve ser permitido), com zero VLANs (que também não deve ser permitido), mas onde “todas as VLANs” (all VLANs) estão definidas. Em vez de acionar um erro nesta configuração e impedir um utilizador de ativar a HA para os Edges, o Orchestrator permite-o e esta configuração ativa uma falha do plano de gestão nos Edges de HA que já não enviam um heartbeat ao Orchestrator e o Orchestrator marca o site como inativo.
Solução alternativa: Evite utilizar a configuração descrita acima.
Problema 84825: Num site implementado com uma topologia de alta disponibilidade onde o BGP está configurado, se o site tiver configuradas mais de 512 regras BGPv4 correspondência/definição, o cliente poderá observar o par Edge HA a falhar continuamente sem nunca recuperar.
Mais de 512 regras BGPv4 de correspondência e definição são compreendidas como o cliente configurar mais de 256 regras no filtro de entrada e 256 regras no filtro de saída. Este problema seria disruptivo para o cliente, dado que a recuperação automática repetida causaria fluxos de tráfego em tempo real, por exemplo, chamadas de voz que falham continuamente e, em seguida, são recriadas. Quando os Edges HA registam este problema, o processo que sincroniza os threads da CPU do Edge falha, fazendo com que o Edge reinicie para recuperar, mas o Edge promovido também regista o mesmo problema e reinicia por sua vez sem que nenhuma recuperação chegue ao site.
Solução alternativa: Sem uma correção para este problema, o cliente deve garantir que não estão configuradas mais de 512 regras BGPv4 de correspondência e definição para um site de HA.
Se um site estiver a registar este problema e tiver configuradas mais de 512 regras BGP/v4 de correspondência e definição, o cliente deverá reduzir imediatamente o número de regras para 512 ou menos para recuperar o site.
Em alternativa, se o cliente tiver configuradas mais de 512 regras BGPv4 de correspondência e definição, poderá mudar para a versão 3.4.6 dos Edges HA, onde este problema não é encontrado, mas perderá as funcionalidades do Edge presentes nas versões posteriores. Esta mudança só poderá ser realizada se o modelo Edge for suportado na 3.4.6. O cliente deverá confirmar isso antes de mudar para uma versão anterior.
Problema 85156: Num site implementado com uma topologia de alta disponibilidade, o cliente pode observar vários reinícios do VMware SD-WAN do Edge em standby com uma potencial disrupção do tráfego do cliente.
A lógica de processamento de sincronização de dados de controlo HA no Edge em standby para os dados recebidos através de TCP pode levar a que os dados só sejam lidos parcialmente. Isto pode fazer com que estas mensagens curtas sejam processadas no modo em standby, o que tornar mais lento o nó em standby. Nas plataformas Edge no limite inferior (por exemplo, modelos Edge 510, 520, 610 e 620), esta lentidão pode ter um impacto significativo no processamento heartbeat entre Ativo e Em standby, o que leva ao Edge em standby a ser incorretamente promovido a Ativo. Num estado ativo-ativo, o tie-break vai para o Edge ativo e o Edge em standby é reiniciado para o despromover de volta ao seu estado rm standby adequado. Quando este problema é encontrado numa topologia HA convencional, o impacto no cliente deverá ser mínimo, dado que o Edge em standby não está a passar o tráfego do cliente. Numa implementação HA melhorada, onde o Edge em standby também está a passar tráfego, os reinícios perturbarão algum tráfego do cliente.
Este pedido adiciona melhorias à lógica de processamento da mensagem TCP do Edge, para melhorar o desempenho no Edge em standby e evitar a lentidão do sistema.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 85461: Se um VMware SD-WAN Edge for utilizado para encaminhar o DNS e os dispositivos LAN ligados ao Edge estiverem a utilizar o Edge para o routing do DNS, todo o tráfego do DNS pode falhar.
Todo o tráfego de routing do DNS é afetado e não apenas o DNS condicional. Consoante o software do Edge, este problema pode ser encontrado num Edge da seguinte forma:
Se o Edge estiver a utilizar a versão 4.2.2, o Edge poderá deparar-se com este problema se o Edge estiver a utilizar portas LAN encaminhadas sem um endereço IP especificado. As portas LAN comutadas + VLANs não são afetadas na versão 4.2.2.
Se o Edge estiver a utilizar a versão 4.3.0/4.3.1, 4.5.0/4.5.1 ou 5.0.0.x, o Edge poderá deparar-se com o problema se o Edge estiver a utilizar portas LAN comutadas e VLANs ou se o Edge estiver a utilizar portas LAN encaminhadas sem um endereço IP especificado.
Para interfaces comutadas, a causa do problema decorre da depreciação e remoção da interface do IP de gestão para dar lugar a uma interface de retorno nas versões 4.3.x, 4.5.x, 5.0.0.x e posteriores. Como o DNS utiliza o NAT do segmento, o pacote DNS não tem qualquer entrada correspondente para o IP de destino quando o Edge faz uma procura na tabela do NAT do segmento e o Edge ignora o pacote.
Para interfaces encaminhadas, a falta de um IP do Gateway significa que o pacote DNS é encaminhado para o Edge como o próximo hop e o Edge não prossegue com o routing do pacote DNS.
Solução alternativa: a solução para este problema é não utilizar o Edge para encaminhar o DNS, ou...
Quando utilizar a versão 4.2.2 do Edge: utilize portas LAN comutadas ou portas LAN encaminhadas que incluam um endereço IP do Gateway.
Quando utilizar a versão 4.3.x ou 4.5.x: utilize apenas portas LAN encaminhadas com um endereço IP do Gateway especificado.
Problema 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 87552: num site que utilize um Destino Não-SD-WAN (NSD) via Edge, o Serviço dataplane do VMware SD-WAN Edge pode sofrer periodicamente uma falha e reiniciar quando os túneis Edge para NSD estiverem instáveis.
Quando um túnel Edge para NSD fica inativo, é executada a versã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.
Solução alternativa: limitar um NSD via Edge a uma ligação WAN diminuirá a probabilidade de este problema ocorrer.
Problema 88604: Num site que utilize uma topologia de alta disponibilidade, caso uma interface WAN fique inativa e, depois, fique operacional num VMware SD-WAN Edge em espera, o evento não é registado no VMware SASE Orchestrator.
Um utilizador não tem visibilidade sobre os eventos da interface do Edge em espera, o que é especialmente impactante nas implementações de HA melhorada em que o Edge em espera também está a transmitir tráfego.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 89217: Um VMware SD-WAN Edge na linha de modelo 6x0 (610, 610N, 610-LTE, 620, 620N, 640, 640N, 680, 680N) pode desligar-se subitamente sem motivo.
O 6x0 Edge teria todas as luzes apagadas, tanto o LED de estado frontal como as luzes traseiras da porta Ethernet, e só pode ser recuperado através de um arranque manual do Edge.
A causa do problema tem origem num microcontrolador PIC, exclusivo da linha Edge 6x0, que utiliza a versão de firmware de PIC de v20M ou anterior (v20L, v20K, v20J). Este problema só pode ocorrer quando o Edge 6x0 utiliza uma versão de PIC de v20M ou anterior. Contudo, mesmo com esta versão, as probabilidades de se deparar com o problema de desligamento são raras (aproximadamente 1/1000). O problema não pode ocorrer num Edge 6x0 com uma versão de firmware de PIC de v20N ou posterior.
Nota: é possível determinar um firmware Edge 6x0 que inclua a versão de PIC num Orchestrator que utilize 5.x ao aceder à página Monitor > Edge > Visão geral(Monitor > Edge > Overview) desse Edge e clicar na caixa de informações pendente ao lado do nome do Edge que inclui as Informações do Edge, a Versão do Dispositivo e o Firmware do Dispositivo. No entanto, funciona apenas em Edges que utilizem a versão 4.5.1.
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.
Solução alternativa: para recuperar o Edge do estado problemático:
Desligue o Edge da fonte de alimentação.
Espere 20 segundos.
Volte a ligar o Edge à fonte de alimentação.
Se não pretender atualizar o firmware da plataforma, o utilizador poderá garantir que a energia para o Edge é consistente e não apresentará instabilidade rápida ou consistente. Uma boa forma de garantir uma fonte de energia fiável é ligar o Edge 6x0 a uma fonte de alimentação ininterrupta (UPS).
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 91365: Para um cliente que utilize o Edge Network Intelligence, um VMware SD-WAN Edge no qual a Análise está configurada sofre uma fuga de memória, o que faz com que o Edge acione um reinício do Serviço Edge para limpar a memória.
Quando a função Análise está ativada num Edge, o serviço de Dataplane do Edge começa a vazar memória a uma taxa constante, o que resultará na necessidade de acionar um reinício de serviço não agendado por parte do Edge para limpar a fuga de memória quando atingir um nível crítico (utilização da memória de 60% durante mais de 90 segundos). Um reinício do Serviço Edge provoca uma interrupção de 10-15 segundos no tráfego do cliente. No terreno, o tempo necessário para acionar um reinício do Serviço Edge tem sido de aproximadamente 3 a 4 dias e, depois de limpa a memória, a fuga é retomada com a mesma janela de tempo geral no próximo reinício do Serviço Edge. O período em que o Edge atinge um nível crítico de utilização da memória depende do modelo Edge e da quantidade de informações que a funcionalidade Análise está a registar para esse Edge.
Solução alternativa: o cliente tem duas opções, a) desativar temporariamente a Análise no Edge até que seja disponibilizada uma compilação do Edge corrigida; ou b) monitorizar a memória do Edge. Quando a utilização da memória atingir os 40% e o Orchestrator registar um Evento de aviso de memória, agende um reinício manual do Serviço Edge numa janela de manutenção para limpar a memória e garantir um impacto mínimo no cliente.
Problema 89873: 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.
Solução alternativa: A única forma de evitar que este problema 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 91746: Um VMware SD-WAN Edge que utilize a autenticação 802.1x com fios ou sem fios (por exemplo, RADIUS, Cisco ISE) pode sofrer falhas de autenticação de certificados e todo o tráfego que exige esta autenticação é descartado no Edge.
O problema é provocado pela alteração inadequada dos cabeçalhos L4 dos pacotes fragmentados do IP por parte do Edge, o que faz com que os pacotes fiquem danificados antes de saírem do Edge. O problema afeta principalmente os pacotes UDP e, visto que estes pacotes são utilizados para a autenticação de certificados 802.1x, tem o potencial de fazer com que os clientes com fios ou sem fios 802.1x falhem.
Solução alternativa: num Edge onde este problema ocorra, as soluções são a) desativar a autenticação 802.1x ou b) reverter o Edge para uma compilação de software do Edge anterior, na qual a autenticação 802.1x funcionava corretamente porque este problema não existia.
Problema 92676: numa implementação de cliente na qual um Destino Não VMware SD-WAN (NSD) via Gateway esteja configurado para utilizar túneis e Gateways redundantes e também esteja a utilizar BGP através de IPsec, caso os Gateways principais e secundários anunciem um prefixo com um caminho AS igual ao dos túneis NSD principais e secundários, o túnel NSD principal irá preferir um caminho do Gateway redundante em vez do Gateway principal.
O impacto de o túnel NSD principal via Gateway preferir o caminho do Gateway redundante em vez do Gateway principal só é sentido para o tráfego de retorno do NSD para o Gateway.
Solução alternativa: configure uma métrica mais alta (3 ou mais) no Gateway redundante para o prefixo interessado, pois tal ajudará o túnel principal do NSD a escolher o Gateway principal para o tráfego de retorno.
Problema 93383: Sintoma: 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. 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.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 94204: Um utilizador pode observar que as tentativas para gerar um pacote de diagnóstico para um VMware SD-WAN Edge falham.
Falha na conclusão dos pacotes de diagnóstico do Edge, dado que o Edge fica sem espaço em disco. Isto poderá ocorrer 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.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 96441: 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.
Solução alternativa: não existe uma solução alternativa para este problema.
Problema 96888: 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.
Solução alternativa: se um Edge estiver a ter este problema, o cliente poderá contactar o Suporte VMware para obter assistência ou atualizar o Edge para a versão 4.5.1, compilação R451-20220916-GA ou posterior.
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 Spoke Edge que sofre 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 Spoke Edge 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 32913:
Após ativar a Alta Disponibilidade, os detalhes de Multicast para o VMware SD-WAN Edge não são apresentados na Página de Monitorização. Uma recuperação automática resolve o problema.
Problema 35667:
Quando um VMware SD-WAN Edge é movido de um perfil para outro perfil que tem a mesma definição de CSS, mas um nome GRE CSS diferente (os mesmos pontos finais), alguns túneis GRE não vão aparecer na monitorização.
Solução alternativa: desative e, em seguida, ative novamente o GRE ao nível do Edge para resolver o problema.
Problema 35658:
Quando um VMware SD-WAN Edge é movido de um perfil para outro que tem uma definição CSS diferente (por exemplo, IPsec no perfil1 para GRE no perfil2), as definições CSS ao nível do Edge continuarão a utilizar as definições CSS anteriores (por exemplo, IPsec em comparação com GRE).
Solução alternativa: desative e, em seguida, ative novamente o GRE ao nível do Edge para resolver o problema.
Problema 36665:
Se o VMware SD-WAN Orchestrator não conseguir ligar-se à Internet, as páginas de interface do utilizador que requerem acesso à API do Google Maps poderão não conseguir carregar completamente.
Problema 38056:
O ficheiro export.csv de licenciamento do Edge não mostra os dados da região.
Problema 38843:
Ao fazer push a um mapa de aplicação, não existe nenhum Evento do operador e o Evento do Edge é de utilidade limitada.
Problema 39633:
A hiperligação Supergateway não funciona após um utilizador atribuir o Gateway alternativo (Alternate Gateway) como o Supergateway (Super Gateway).
Problema 39790:
O VMware SD-WAN Orchestrator permite a um utilizador configurar uma interface encaminhada do VMware SD-WAN Edge para que tenha mais do que as 32 subinterfaces suportadas, criando o risco de um utilizador configurar 33 ou mais subinterfaces numa interface, o que pode provocar uma falha do Serviço dataplane Edge.
Problema 41691:
O utilizador não pode alterar o campo “Número de endereços” (Number of addresses), embora o conjunto DHCP não esteja esgotado na página Configurar > Edge > Dispositivo (Configure > Edge > Device).
Problema 43276:
O utilizador não consegue alterar o tipo de segmento quando um VMware SD-WAN Edge ou Perfil tem um Gateway de parceiro configurado.
Problema 47820:
Se uma VLAN estiver configurada com o DHCP desativado ao nível do perfil, enquanto também tem uma Anulação de Edge para esta VLAN nesse Edge com o DHCP ativado e existe uma entrada para o campo de servidor DNS definido para nenhum (nenhum IP configurado), o utilizador não poderá fazer qualquer alteração na página Configurar > Edge > Dispositivo (Configure > Edge > Device) e receberá uma mensagem de erro de “endereço IP inválido []” (invalid IP address []) que não explica nem indica o verdadeiro problema.
Problema 48085:
O VMware SD-WAN Orchestrator permite que um utilizador elimine uma VLAN que esteja associada a uma interface.
Problema 49225:
O VMware SD-WAN Orchestrator não impõe um limite de 32 VLANs totais.
Problema 50531:
Quando dois operadores com privilégios diferentes utilizam a mesma janela do browser para aceder à nova IU na versão 4.0.0 do VMware SD-WAN Orchestrator e o Operador com menos privilégios tenta iniciar sessão depois do Operador com mais privilégios, esse Operador com menos privilégios observará vários erros a indicar, o “utilizador não tem privilégios” (user does not have privilege).
Nota: não existe escalamento de privilégios para o Operador com privilégios mais reduzidos, apenas a apresentação de mensagens de erro.
Solução alternativa: o próximo operador poderá atualizar essa página antes de iniciar sessão para evitar ver os erros ou cada Operador pode utilizar janelas diferentes do browser para evitar este problema de apresentação.
Problema 51722: Na versão 4.0.0 do VMware SD-WAN Orchestrator, o seletor do intervalo de tempo não é superior a duas semanas para qualquer estatística nos separadores Monitorizar > Edge (Monitor > Edge).
O seletor de intervalo de tempo não apresenta opções superiores a “Últimas 2 semanas” (Past 2 Weeks) nos separadores Monitorizar > Edge (Monitor > Edge), mesmo que o período de retenção para um conjunto de estatísticas seja largamente superior a 2 semanas. Por exemplo, as estatísticas de fluxo e ligação são mantidas durante 365 dias por predefinição (isto é configurável), enquanto as estatísticas de caminho são mantidas apenas durante 2 semanas por predefinição (também configurável). Este problema está a fazer com que todos os separadores de monitorização estejam em conformidade com o tipo de estatística retida mais baixa versus permitir que um utilizador selecione um período de tempo consistente com o período de retenção para essa estatística.
Solução alternativa: um utilizador pode utilizar a opção “Personalizado” (Custom) no seletor de intervalo de tempo para ver dados durante mais de 2 semanas.
